Dans beaucoup de PME, un processus critique tient dans la tête d’une seule personne. Tant qu’elle est là, tout va bien. Le jour de son départ en congés — ou de son départ tout court — l’entreprise découvre ce qu’elle ignorait savoir faire.
La réponse habituelle est de « tout documenter ». Elle produit en général un classeur de quatre-vingts pages que personne n’ouvre. Le problème n’est pas l’idée, c’est le format.
Une procédure utile tient sur une page
Le critère est simple : une procédure doit permettre à quelqu’un qui ne connaît pas la tâche de la réaliser correctement. Si elle demande vingt minutes de lecture, elle sera contournée.
Ce qui doit y figurer :
- Le déclencheur : à quel moment on applique cette procédure ;
- Les étapes, numérotées, une action par ligne, à l’infinitif ou à l’impératif (« Vérifier que… », « Envoyer… ») ;
- Qui fait quoi, quand plusieurs personnes interviennent ;
- Les cas particuliers, regroupés en fin de document — pas dispersés dans le fil ;
- Un contact en cas de blocage.
Ce qui ne doit pas y figurer : l’historique du service, la justification de chaque règle, les copies d’écran d’une version d’outil qui aura changé dans six mois.
Faites-la écrire par celui qui fait
C’est contre-intuitif, mais l’encadrement rédige souvent la procédure telle qu’elle devrait se dérouler, pas telle qu’elle se déroule. Or l’écart entre les deux est justement l’information intéressante.
Une méthode qui marche : la personne exécute la tâche pendant qu’un collègue prend des notes. Le collègue étant novice, il pose les questions que l’expert ne se pose plus — c’est là que sortent les tours de main non écrits.
Le test du nouvel arrivant
Une procédure ne se valide pas en relecture, mais à l’usage : donnez-la à quelqu’un qui ne fait pas la tâche et regardez-le faire sans intervenir. Chaque fois qu’il hésite, il manque une information. C’est le seul test qui compte, et il prend une demi-heure.
Standardiser d’abord, automatiser ensuite
L’ordre a son importance. Automatiser un processus flou revient à figer le désordre dans un outil, en plus cher et en moins souple. Écrire le mode opératoire fait apparaître les étapes inutiles, les doubles contrôles et les allers-retours : bien souvent, une partie du gain est obtenue avant d’avoir touché à un logiciel.
Une fois le processus stabilisé et écrit, il devient un bon candidat à l’automatisation ou à un outil low-code.
Pour aller plus loin sur la méthode, voyez par où commencer.