Scénario illustratif. Un cabinet comptable veut qu'un agent rapproche les encaissements de ses clients. On demande à Marta, qui le fait depuis douze ans, comment elle s'y prend. « C'est simple, dit-elle, tu fais correspondre le relevé et les factures. » On construit l'agent sur cette description et, dès les premières semaines, il échoue pile là où Marta ne s'arrêtait jamais pour réfléchir : le client qui règle trois factures en un seul virement, le montant qui arrive toujours minoré d'une remise accordée de vive voix, la clôture de trimestre où l'on ne touche à rien tant qu'un e-mail n'est pas arrivé. Rien de tout cela n'était écrit. Marta ne savait même pas qu'elle le savait.
La thèse en une ligne : avant d'automatiser un processus, il faut sortir de la tête de celui qui l'exécute ce qui n'a jamais été écrit, et cette étape apporte souvent plus que l'automatisation elle-même.
Pourquoi documenter les processus avant d'automatiser avec l'IA ?
Parce qu'un agent exécute ce que tu lui racontes, pas ce que l'entreprise fait vraiment. L'écart entre les deux, c'est le savoir tacite : des critères, des exceptions et des raccourcis que la personne applique sans s'en rendre compte, et donc sans savoir les expliquer. Demande-lui « comment tu fais ? » et tu obtiens la version officielle, celle qui tient en une phrase. L'agent se construit sur cette version et casse sur tout le reste.
Ce n'est pas un détail de déploiement. L'analyse de RAND sur les raisons de l'échec des projets d'IA, fondée sur des entretiens avec des ingénieurs et des data scientists, range parmi les causes les plus fréquentes le fait que le problème à résoudre a été mal compris ou mal communiqué (RAND, 2024). C'est le même schéma que nous décrivons dans pourquoi les projets d'automatisation par l'IA échouent : le projet n'échoue pas pendant la démo, il échoue dans l'écart entre ce que chacun croyait acquis.
Comment savoir qu'un processus n'existe que dans la tête d'une personne ?
Il existe des signes assez fiables, et pas besoin d'audit pour les voir.
- Deux personnes le font différemment et toutes deux disent bien le faire. Chacune applique son propre critère et personne ne les a jamais mis côte à côte.
- Quand cette personne est absente, le processus s'arrête ou se dégrade. Si les congés de quelqu'un sont un risque opérationnel, le processus vit dans sa tête (le même problème, vu du côté de l'agent, dans ce qui arrive à ton agent quand celui qui l'a monté s'en va).
- L'explication commence par « ça dépend ». Quand chaque étape traîne un « ça dépend » et que personne ne sait de quoi, il y a des règles non écrites.
- Les exceptions se règlent par téléphone ou par message. Ce qui se décide hors du système n'entre pas dans le système, et l'agent ne voit que le système.
Comment extraire le vrai processus en une semaine ?
Pas avec un questionnaire ni une réunion de deux heures. Avec des cas réels, observés par quelqu'un qui n'est pas celui qui fait le travail. Une méthode qui tient en cinq jours :
- Lundi : choisis un processus et une personne. Un seul processus, celui qui tourne le plus, et celle ou celui qui l'exécute au quotidien. Dis-lui dès le départ qu'on ne l'évalue pas : il s'agit de comprendre, pas d'auditer.
- Mardi : observe des cas, ne demande pas comment on fait. Assieds-toi à côté pendant qu'elle traite des cas réels, y compris les cas bizarres, et note chaque décision. Un échantillon des derniers cas vaut mieux que n'importe quelle description.
- Mercredi : demande pourquoi à chaque décision. « Pourquoi celui-ci et pas l'autre ? », « qu'aurait-il fallu avec un autre montant ? ». C'est là que sortent les critères qu'elle croyait évidents.
- Jeudi : écris la règle métier, pas les clics. Condition, exception et qui on prévient, une page par processus. Le format est dans comment documenter ses automatisations.
- Vendredi : confronte avec des cas qu'elle n'a pas vus. Donne-lui de nouveaux cas sans montrer la règle et compare sa décision à ce qui est écrit. Chaque écart est une règle qui manquait.
| Ce que dit la version officielle | Ce que fait vraiment la personne | Comment ça remonte |
|---|---|---|
| « Je rapproche le relevé et les factures » | Regroupe des paiements, applique des remises convenues de vive voix et met certains clients en attente | En observant des cas réels, pas en les entendant décrits |
| « C'est validé si ça respecte la politique » | Valide des choses hors politique quand elle connaît le client | En demandant pourquoi à chaque exception |
| « On relit avant d'envoyer » | Ne vérifie que ce qui semble louche, au flair, sans pouvoir le nommer | En lui donnant de nouveaux cas et en comparant sa décision à la règle écrite |
Regarde la dernière colonne : dans aucun cas la solution n'est de demander plus, c'est de regarder plus. Celui qui décrit son travail décrit l'idéal ; celui qui le fait devant toi montre le réel. Et le réel est le seul qu'un agent va rencontrer lundi matin, avec les cas que personne n'avait prévus à la réunion de lancement.
Et si, en documentant, tu découvres qu'il ne faut pas l'automatiser ?
Ça arrive plus qu'on ne l'admet. Documenter fait apparaître des incohérences entre personnes, des étapes dont personne ne se rappelle la raison et des décisions qui reposent sur un jugement impossible à réduire à des règles. Il reste trois sorties : simplifier le processus avant de toucher à quoi que ce soit, n'automatiser que la partie qui est déjà une règle et laisser la part de jugement à une personne, ou décider que ce processus n'est pas fait pour un agent (le raisonnement de fond est dans quand ne pas automatiser avec l'IA). N'importe laquelle coûte moins cher que de le découvrir avec l'agent déjà en production.
Et la part de jugement ne disparaît pas : elle fixe l'autonomie que tu peux donner à l'agent. Cela se décide avec les niveaux d'autonomie d'un agent, et seulement si tu sais d'abord où se trouve le jugement.
Quand documenter d'abord le processus ne vaut-il pas la peine ?
Quand le processus est court, réversible et peu coûteux à rater : trois étapes, ni argent ni données personnelles en jeu. On teste directement et on corrige en route. Cela ne vaut pas non plus la peine de documenter si finement un processus qui change tous les mois ; dans ce cas, on écrit les principes stables, pas chaque étape (plus dans automatiser un processus qui change tous les mois).
Si tu as plusieurs candidats et ne sais pas par lequel commencer, auditer tes processus pour l'IA dit d'abord lequel mérite l'effort ; l'exercice de cette semaine, c'est ce que tu fais ensuite, avec celui que tu as choisi.
La ligne à retenir : le processus que tu vas automatiser n'est pas celui du manuel, c'est celui que la personne exécute, et tant qu'il n'est pas écrit, l'agent se construit sur une supposition.
Sources (consultées le 28 octobre 2026) : « The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed », RAND Corporation (2024), utilisée de façon qualitative. Le scénario d'ouverture est illustratif, pas un cas réel.