La compétence rare a changé de camp
Un modèle de langage écrit le code et configure l'outil à partir d'une description en français. La barrière technique est tombée, comme nous l'avons montré dans L'IA n'a rien inventé.
La difficulté s'est déplacée dans la description elle-même. Un système construit sur une description floue fait ce qu'elle dit, oublis compris. Or seul le cabinet peut l'écrire correctement : un intégrateur qui découvre le métier ne sait pas ce qu'il ne sait pas.
Ce que veut dire connaître un process
Demandez à un collaborateur comment il relance un client : il décrira le cas normal en trois phrases. La connaissance réelle tient en quatre couches :
- Les règles écrites. Une procédure, un modèle de courriel. La partie visible, souvent la plus mince.
- Les exceptions. Les cas connus où l'on s'écarte de la règle : tel client envoie tout par courrier.
- Les cas limites. Là où la règle ne dit rien : une pièce illisible, une réponse par le mauvais canal.
- Qui décide. Le collaborateur peut-il suspendre une relance seul ? Cette carte des décisions est rarement écrite, et c'est elle qui protège le cabinet.
Les deux dernières couches vivent dans la tête des personnes qui font le travail. Il faut les en sortir avant d'automatiser.
Ce qu'un modèle ne peut pas inventer
Un modèle produit une réponse vraisemblable, pas nécessairement exacte. Devant une consigne incomplète, il comble les trous avec ce qui est probable dans le cas général. Or votre seuil d'alerte ou la personne qui tranche sont des choix du cabinet. Non écrits, ils sont remplacés sans que personne le voie.
Dans un workflow, l'oubli devient une branche manquante. Dans un agent, il devient une décision du modèle à chaque exécution (voir Qu'est-ce qu'un agent IA ?). Anthropic note que le schéma où un modèle produit et un autre évalue est particulièrement efficace quand les critères d'évaluation sont clairs Anthropic, 19/12/2024. Ces critères, c'est le métier qui les fournit.
Formaliser avant d'automatiser
La méthode ne demande aucun outil : un document partagé, rempli par la personne qui fait le travail et relu par celle qui en répond.
| Étape | La question | Ce qu'on obtient |
|---|---|---|
| 1. Décrire le cas normal | Que se passe-t-il quand tout va bien ? | Une suite d'étapes, avec ce qui entre et sort de chacune |
| 2. Lister les exceptions | Quand s'écarte-t-on de cette suite ? | Une liste de cas, chacun avec sa conduite à tenir |
| 3. Nommer les décisions humaines | Où une personne doit-elle trancher, et laquelle ? | Des points d'arrêt, chacun rattaché à une fonction |
| 4. Fixer ce qui se trace | Que faudra-t-il pouvoir montrer plus tard ? | Le contenu du journal : qui, quand, sur quoi, pour quel motif |
| 5. Constituer des cas de test | Sur quels dossiers réels le système doit-il répondre juste ? | Des dossiers pseudonymisés, avec la réponse attendue écrite par une personne compétente |
| Un process qu'on ne parvient pas à décrire à l'étape 1 n'est pas prêt à être automatisé. | ||
L'ordre compte : les exceptions n'apparaissent qu'une fois le cas normal écrit, et c'est presque toujours sur une exception qu'une personne tranche.
Les cas de test se tirent de vrais dossiers, pseudonymisés avant tout traitement par un modèle. Ils servent avant la mise en service, puis à chaque changement de modèle, de consigne ou d'outil (voir qui maintient les automatismes). Pour Anthropic, la clé est de mesurer les performances et d'itérer Anthropic, 19/12/2024. Pour la trace en conformité, voir LCB-FT et IA.
Exemple : la relance des pièces manquantes
Un process que tout cabinet pratique, et que les envois programmés automatisent déjà en partie (voir Ce que les cabinets automatisaient avant l'IA). Les règles ci-dessous sont des exemples : chaque cabinet fixe les siennes.
Cas normal. À date fixe, on extrait les opérations bancaires sans justificatif. Le client reçoit la liste et un lien de dépôt, puis une seconde relance après un délai fixé. Chaque pièce reçue sort de la liste.
Exceptions. Un comptable interne reçoit la relance à la place du dirigeant. Un client qui envoie par courrier n'est relancé qu'une fois le courrier traité.
Décisions humaines. Suspendre les relances d'un client : le collaborateur propose, l'associé décide.
Trace. Chaque relance (date, destinataire, liste jointe), chaque suspension avec son auteur et son motif.
Cas de test. Un client qui a tout envoyé (aucune relance ne part), une pièce illisible, un client qui écrit « ne me relancez plus » : le système transmet à une personne, il n'obéit pas.
Ainsi écrite, la description fixe le niveau de chaque étape : l'envoi relève d'un workflow, la lecture d'une réponse libre peut être confiée à un modèle sous contrôle, les suspensions restent humaines.
Comment Rouage procède. Rouage classe avec vous vos tâches répétées par niveau de contrôle, et écarte d'emblée celles qui engagent un avis ou une signature. La supervision est écrite avant toute mise en service, et le jeu de cas de test est construit avec vos dossiers, cas limites compris.
Ce que cela change pour les rôles
- Les collaborateurs décrivent et contrôlent. Ils écrivent la description, réunissent les cas de test et vérifient les sorties, sur du temps prévu au planning.
- Les associés arbitrent. Ils choisissent ce qui sera automatisé, fixent les décisions qui restent humaines et nomment la personne qui répond de chaque automatisme.
- Qui construit compte moins. Le cabinet ou un prestataire : dans les deux cas, la description reste au cabinet, et c'est elle qui fait la valeur.
Si la personne qui connaît le mieux un process part sans rien avoir écrit, le cabinet perd la connaissance et la capacité de corriger ce qui a été construit dessus. Pour la prise en main des équipes, voir Déployer l'IA dans votre cabinet.
Tout ne mérite pas d'être automatisé
Formaliser prend du temps, automatiser et maintenir davantage. Mieux vaut s'abstenir pour une tâche rare, pour un process dont les règles changent sans cesse, et pour un process que personne n'a validé : l'automatiser le fait tourner plus vite, erreurs comprises. Quand le jugement est le travail (un avis, une signature), un modèle peut préparer, une personne répond (voir Maîtriser les agents IA).
Même sans automatiser, la description garde sa valeur : elle forme les nouveaux arrivants.
Mettre un premier process par écrit avec vousRouage part de ce que vos équipes font réellement, écrit avec vous la supervision et le jeu de cas de test, puis construit ce qui en vaut la peine.
Prendre RDVQuestions fréquentes
Pourquoi la connaissance du métier devient-elle la compétence rare ?
Parce qu'un modèle de langage écrit désormais le code à partir d'une description en français. Le résultat dépend de cette description, et les règles propres au cabinet ne s'inventent pas.
Comment formaliser un process avant de l'automatiser ?
Décrire le cas normal, lister les exceptions, nommer les décisions humaines, fixer ce qui se trace, puis constituer des cas de test à partir de vrais dossiers pseudonymisés.
Faut-il de vrais dossiers pour tester un automatisme ?
Oui : ils font apparaître les cas limites qu'une description oublie. Ils sont pseudonymisés avant tout traitement par un modèle.
Qui doit décrire les process dans un cabinet ?
Les personnes qui les pratiquent, avec du temps prévu pour cela. L'associé relit et tranche les décisions qui restent humaines.
Quelles tâches ne faut-il pas automatiser ?
Les tâches rares, les process instables ou non validés, et celles où le jugement est le travail : un modèle peut préparer un avis, une personne en répond.
À lire ensuite
- L'IA n'a rien inventé : elle a ouvert les systèmes complexes à ceux qui connaissent le métierGuide principal
- Automatismes construits avec l'IA : qui les maintient ?Guide
- Chemin fixe, autonomie bornée : anatomie d'un agent de formalitésGuide
- Construire des workflows fiables : traçables, auditablesFormation
L'auteur
Quentin Charrier, fondateur de Rouage. Il travaille depuis une quinzaine d'années dans l'expertise comptable et a cofondé un cabinet de plus de 4 000 clients, dont il a organisé le juridique, la conformité et la production.
Sources
Lues le 23/10/2026.
- Erik Schluntz et Barry Zhang, « Building effective agents », Anthropic, 19 décembre 2024 : efficacité du schéma évaluateur-optimiseur quand les critères d'évaluation sont clairs, mesure des performances et itération.