Formaliser un processus, c’est écrire comment le travail se fait vraiment : les étapes, les données utilisées, les règles de décision et surtout les exceptions que seule la personne en poste connaît. On y arrive en l’observant traiter des cas réels, pas en lui demandant une procédure. C’est le préalable à toute automatisation fiable.
Pourquoi un processus finit par reposer sur une seule personne
Un processus se concentre sur une personne sans décision explicite : elle a réglé les cas difficiles au fil des années, construit ses propres fichiers et retenu les exceptions de tête. Tant qu’elle est là, tout fonctionne. Le risque apparaît lors d’une absence, d’un départ, ou quand on veut automatiser ce travail.
Voici un exemple illustratif, pas un cas client. La personne connaît les exceptions que la procédure ne dit pas : le client qui paie toujours en deux fois, le fournisseur dont les références changent, le contrôle qu’elle refait avant d’envoyer alors que le texte ne le mentionne pas. Ses collègues lui passent les dossiers particuliers. Le travail sort, tant qu’elle est là.
Quatre signes permettent de reconnaître cette situation. La procédure écrite ne suffit pas pour qu’une nouvelle personne reproduise le travail. Les congés bloquent les dossiers, ou ceux-ci partent sans le contrôle habituel. Un fichier Excel personnel concentre les formules, les listes et les notes, souvent sur un seul poste. Automatiser un fichier Excel sans perdre le contrôle n’intervient qu’une fois ses règles écrites. Les questions remontent toujours à la même personne, même pour des cas déjà vus.
On peut d’abord mesurer la dépendance à une personne : combien de personnes savent traiter le processus jusqu’au bout, et ce qui s’arrête pendant une absence.
Formaliser, documenter, transférer des compétences : trois démarches différentes
Documenter, c’est décrire les étapes d’un processus. Formaliser va plus loin : rendre explicites les règles de décision et les exceptions, au point qu’une autre personne ou un système puisse les appliquer. Transférer des compétences, c’est former quelqu’un par le tutorat ou le binômage. Avant d’automatiser, c’est la formalisation qui compte.
Documenter un processus
Documenter un processus, c’est écrire la procédure du cas normal : l’ordre des étapes, l’outil, parfois le responsable. Ce texte aide un nouvel arrivant. Il décrit le dossier conforme et tait l’incomplet, le contrôle ajouté après une erreur, le fichier hors de l’outil officiel. Une personne qui n’a que cette procédure reproduit la version idéale, puis elle bloque ou elle improvise.
Formaliser : les règles, les données, les exceptions, les contrôles
La formalisation des processus métier écrit la règle de décision, la donnée et sa source, l’exception et son traitement, le contrôle avant de clôturer. Une autre personne, ou un système, doit pouvoir appliquer la fiche sans redemander. Si la personne doit encore écrire pour être sûre, une règle manque sur la fiche.
Transférer des compétences
Transférer des compétences, c’est former quelqu’un. Le tutorat, le compagnonnage et le binômage placent l’apprenant à côté de la personne qui sait, sur de vrais dossiers. L’Anact indique que cette transmission se fait sur le lieu de travail, à partir des situations réelles, avec quelqu’un qui apprend et quelqu’un qui transmet. Une publication de l’Anact sur une démarche compétences décrit une petite entreprise qui a rédigé des modes opératoires, avec des photos, pour conserver des tours de main qui n’étaient pas écrits. Les deux se complètent : la fiche accélère la formation, le temps passé ensemble transmet le reste. Le binômage seul ne donne pas une règle exécutable par un système.
Préparer la formalisation : délimiter le processus et embarquer la personne
Avant de commencer, on fixe le début et la fin du processus, ce qui le déclenche et le résultat attendu. On explique à la personne qui sait pourquoi on formalise : sécuriser son travail et lui retirer les tâches répétitives, pas la remplacer. Puis on rassemble des cas réels récents, y compris ceux qui ont posé problème.
Si le processus n’est pas encore choisi, le préalable est de choisir le premier processus à automatiser. On formalise un processus déjà désigné. Décrire la comptabilité ou la relation client en entier produit un texte trop large pour être testé.
Quatre lignes se posent avant la première séance : le déclencheur (un mail, une facture, une échéance), la première action et le livrable qui clôt le cas, ce qui doit être vrai à la fin, et ce que la fiche ne couvrira pas.
L’accord de la personne et le temps qu’elle y consacre sont la condition de réussite. On ne formalise pas dans son dos : sans elle, il ne reste que la version officielle. On mélange ensuite des dossiers simples, des dossiers qui ont coincé et un dossier où elle a hésité. Une dizaine de cas récents apprend plus qu’un entretien sur le fonctionnement en général.
Faire parler la personne qui sait : observer plutôt que demander
Demander à quelqu’un de décrire son travail produit la version idéale, sans les exceptions. On obtient bien plus en la regardant traiter des cas réels et en lui faisant dire à voix haute ce qu’elle fait, ce qu’elle vérifie et pourquoi elle hésite. Les règles implicites apparaissent dans ces moments, pas dans un entretien.
Les séances sont courtes. Elles se tiennent au poste, avec des dossiers ouverts. La personne traite le cas comme elle le ferait seule. On note chaque action, chaque source consultée (un écran, un classeur, un mail, un appel) et chaque vérification. Avec son accord, on récupère le classeur, la trame et la liste des cas à surveiller : ces fichiers tiennent souvent la vraie procédure. Une heure sur trois dossiers suffit. On relit les notes le jour même, avant qu’un contresens ne devienne une règle.
Les questions qui font sortir les exceptions
Cinq questions, posées pendant qu’elle agit, font sortir ce qui n’est écrit nulle part.
Que faites-vous quand cette information manque ?
Qu’est-ce qui vous fait hésiter ici ?
Qui prévenez-vous quand ça ne colle pas ?
Quel cas vous a posé problème le mois dernier ?
Que vérifiez-vous avant d’envoyer ?
On reformule devant elle : si l’information manque, alors le dossier est suspendu et tel service est prévenu. La réponse « cela dépend » n’entre pas dans la fiche : on ouvre le dossier concerné et on écrit la règle de ce cas.
Un processus de votre entreprise ne tient que par une personne ? Montrez-le pendant un échange gratuit de 30 minutes : on regarde un cas réel avec vous.
Parlons de votre transformation
Écrire le processus : étapes, données, règles, exceptions
Le résultat tient en une fiche par processus : le déclencheur, les étapes et qui les fait, les données et leur source, les règles de décision écrites sous la forme « si, alors », les exceptions et leur traitement, les contrôles. Pour chaque étape, on note aussi si elle relève d’une règle stable, d’un contenu variable ou d’un jugement.
Le tableau qui suit est le modèle de fiche pour formaliser un processus. L’exemple d’une facture fournisseur est illustratif : il montre la forme, ce n’est pas un cas client.
| Rubrique | Ce qu’on y écrit | Exemple illustratif |
|---|---|---|
| Déclencheur | L’événement qui ouvre un cas | Une facture fournisseur arrive par mail |
| Étapes et responsables | L’ordre, et qui agit | La comptabilité rapproche, l’acheteur tranche, un responsable valide |
| Données et sources | L’information, et sa source | Montant et référence, lus sur la facture et dans l’outil de gestion |
| Règles | Une décision « si, alors » | Si l’écart de prix dépasse le seuil convenu, alors le dossier est bloqué |
| Exceptions | Le cas hors règle, et son traitement | Les références changent : on rapproche sur le bon de livraison |
| Contrôles | Ce qu’on vérifie avant de clôturer | Le relevé bancaire est comparé à celui déjà connu avant un virement |
| Nature de l’étape | Règle stable, contenu variable ou jugement | Le seuil est stable ; le libellé varie ; un litige reste un jugement |
Une règle stable pourra être codée. Un contenu variable pourra être lu. Un jugement restera à une personne. On détaille ce choix pour répartir un processus entre code, IA et validation humaine.
Tester la fiche
Une autre personne traite quelques cas réels avec la fiche seule, sans appeler celle qui sait. Chaque question est un trou. Si elle demande quoi faire lorsque le bon de commande manque, l’exception n’est pas écrite. On complète, puis on rejoue un cas semblable. On s’arrête quand les cas simples passent sans aide et que les cas à remonter sont reconnus.
Un exemple publié : le P&L par activité
Sur P&L par activité : de 20 h à 4 h maximum par mois, les échanges avec les personnes qui produisaient le P&L ont permis de reprendre les règles déjà documentées et de mettre par écrit les pratiques qui ne l’étaient pas : règles de validation, clés de répartition, seuils d’écart, contrôles de cohérence. Ce travail a précédé l’automatisation. La finance sert de preuve ; la méthode vaut pour les autres services. Le client n’est pas nommé.
La démonstration de reporting mensuel, sur des données fictives, montre la forme du résultat une fois les règles écrites. Ce n’est pas un chiffre client.
Le faire soi-même ou se faire accompagner
On peut formaliser soi-même un processus court, porté par une personne disponible, avec peu de règles. Un regard extérieur devient utile quand plusieurs services sont concernés, que les pratiques divergent, que la personne qui sait part bientôt, ou quand la fiche doit servir à chiffrer une automatisation. L’essentiel reste d’observer des cas réels.
Pour un processus court, on tient la fiche et on la fait tester par un collègue. Au-delà, le cadrage est la version accompagnée de cette méthode : on observe des cas réels, on écrit les règles et les exceptions, on restitue une fiche. Le déroulé plus large est celui de notre méthode : observer, formaliser, construire, contrôler.
Une fois le processus écrit : ce qui peut devenir automatique
Une fiche bien faite montre d’elle-même ce qui peut être automatisé : les règles stables deviennent du code, les documents et les textes variables peuvent être lus par l’IA, et les décisions restent aux personnes, avec les cas particuliers déjà isolés. La personne qui portait le processus devient celle qui valide, plutôt que celle qui recopie.
Deux suites apparaissent souvent à ce stade. L’extraction de données par IA lit des documents au format variable : c’est une lecture, pas une recopie. Une relance client automatique envoie un rappel quand une échéance est dépassée et qu’aucune contestation n’est ouverte : elle demande une règle déjà écrite. Dans les deux cas, la fiche dit ce qui peut tourner seul et ce qui doit rester une validation.
Klaryx est le partenaire de transformation IA des PME et ETI. Passer de cette fiche à un système en service, c’est formaliser un processus avant de l’automatiser, puis le faire construire.
Pour aller plus loin
Une fiche testée ouvre trois suites : vérifier que le processus était le bon candidat, mesurer le point de départ avant de construire, et ranger chaque étape entre une règle stable, un contenu variable et un jugement. Sans ces réponses, la fiche reste un document. Avec elles, on estime l’automatisation et on contrôle qu’elle applique les mêmes règles.
Le choix du candidat, le point de départ et le tri de chaque étape sont repris dans choisir le premier processus à automatiser, mesurer la dépendance à une personne et répartir un processus entre code, IA et validation humaine.
Votre fiche est écrite, ou vous bloquez sur les exceptions ? On la relit avec vous et on regarde ce qui pourrait tourner seul. L’échange dure 30 minutes et il est gratuit.