Construit en un après-midi
Un collaborateur décrit un process à un assistant IA. Le soir même, un automatisme tourne. Personne n'a écrit de code, ni de documentation.
C'est la rupture décrite dans Agent IA ou workflow. Les automatismes ne sont pas nouveaux (voir ce que les cabinets automatisaient avant l'IA), leur nombre l'est. Reste une question : le jour où cela cassera, qui s'en apercevra ?
Six causes de casse, toutes ordinaires
Un automatisme casse rarement à cause de l'IA. Il casse parce que ce qui l'entoure change :
- Le format d'export change. Une colonne se déplace : la mauvaise donnée est lue, sans erreur.
- Le modèle change. Les réponses changent. Un modèle retiré ne répond plus.
- La consigne est retouchée. Une correction faite pour un dossier dégrade les autres.
- La personne part. Plus personne ne sait comment il marche, ni comment l'arrêter.
- Un accès expire. Mot de passe changé, compte désactivé : tout s'arrête, parfois sans prévenir.
- Une donnée imprévue arrive. Document illisible, champ vide : le modèle répond quand même.
Le retrait des modèles n'est pas une hypothèse : Anthropic, l'éditeur du modèle Claude, écrit que les requêtes vers un modèle retiré échouent Anthropic, documentation.
La panne la plus coûteuse est silencieuse. Un automatisme arrêté se remarque. Celui qui tourne sur une colonne décalée produit des résultats qui ont l'air normaux.
Que fait tourner le cabinet ? L'inventaire et la fiche
Demandez à chaque équipe : qu'est-ce qui se fait tout seul ? Qu'est-ce qui part chez un client, ou chez un modèle d'IA, sans qu'une personne l'envoie ? Chaque automatisme reçoit ensuite une fiche, avant sa mise en service. Un tableur suffit.
| Champ | Ce qu'on y écrit | Exemple |
|---|---|---|
| Finalité et niveau | Ce qu'il fait ; workflow, workflow assisté ou agent | Préparer la relance mensuelle ; workflow assisté |
| Données | Ce qu'il lit, d'où, données personnelles ou non | Pièces manquantes, nom et adresse du contact client |
| Production | Le résultat, et où il va | Un projet de courriel par client, en brouillon |
| Accès | Les outils, le compte utilisé, l'échéance | Compte du cabinet, pas celui d'un salarié |
| Versions | Le modèle, la consigne | Consigne v4, version exacte du modèle |
| Contrôle | Qui valide, avant quoi | Le collaborateur relit avant envoi |
| Journal et tests | Où ils sont, dernier passage des tests | Une entrée par relance ; un client sans adresse parmi les cas |
| Registre RGPD | La ligne concernée, ce qui y change | Fournisseur du modèle ajouté aux destinataires |
| Responsable | Une personne nommée, un suppléant | Le chef de mission, son adjoint |
| Arrêt et repli | Comment l'arrêter, comment travailler pendant l'arrêt | Désactiver le déclenchement ; relances à la main |
Plus le niveau est autonome (voir Qu'est-ce qu'un agent IA ?), plus le contrôle à la sortie doit être serré.
Qu'ont-ils fait, fonctionnent-ils encore ? Journal et cas de test
Le journal, daté et tenu en ajout seul, dit ce qu'a fait l'automatisme, sur quelles données, avec quelle version, et qui a validé. Sa conception est détaillée dans Construire des workflows fiables ; son rôle en vigilance, dans LCB-FT et IA.
Le jeu de cas de test réunit des situations réelles anonymisées et leur résultat attendu, dont chaque erreur déjà constatée. On le rejoue à chaque changement de modèle, de consigne, d'outil ou de format. Un écart bloque la mise en service.
Le texte d'un modèle varie : on vérifie des critères écrits d'avance (bonnes pièces, bon client). Le RGPD cite le même réflexe parmi les mesures de sécurité : une procédure pour tester et évaluer régulièrement leur efficacité RGPD, art. 32, § 1, d.
Qui en répond ? Un nom, et le pouvoir d'arrêter
Chaque automatisme a un responsable nommé : pas forcément celui qui l'a construit, mais celui qui connaît le process et le comprend assez pour l'arrêter. Un automatisme qu'on n'ose pas arrêter, faute de savoir refaire le travail à la main, est déjà un risque.
Un départ se prépare comme une passation de dossiers : fiche, accès et tests repris avec le successeur. Voir aussi Le métier avant la technique.
Ce que le RGPD demande déjà
Construit vite ou non, un automatisme qui traite des données personnelles relève du RGPD.
- Le registre des traitements RGPD, art. 30 décrit notamment finalités, données, destinataires, délais d'effacement et mesures de sécurité. Le fournisseur d'un modèle qui reçoit des données personnelles en devient destinataire RGPD, art. 4, point 9 : le registre doit suivre.
- Les principes RGPD, art. 5 : des données exactes, conservées pas plus que nécessaire, protégées, et un responsable capable de démontrer qu'il les respecte.
- La sécurité RGPD, art. 32 : des mesures adaptées au risque, et des mesures pour que les personnes sous l'autorité du responsable ne traitent les données que sur ses instructions.
Le registre décrit des traitements, pas des outils. C'est la fiche de chaque automatisme qui permet de le tenir à jour.
Les automatismes que personne n'a déclarés
Les informaticiens parlent de « shadow IT » : des outils construits par des collaborateurs, de leur propre initiative, sans que le cabinet le sache. Un automatisme ignoré n'a ni fiche, ni journal, ni test, et le cabinet ne peut pas donner d'instructions sur un traitement qu'il ignore.
Interdire ne fait que pousser ces automatismes à se cacher. Nous recommandons trois règles : on déclare avant de mettre en service, en remplissant la fiche ; les données de clients ne vont que dans les outils retenus par le cabinet ; le premier inventaire se fait sans reproche, sinon il ne sera jamais complet.
Une routine de revue
Aucun des textes cités ici ne fixe de calendrier. Rouage recommande, sans en faire une norme, une revue à chaque changement et une revue périodique dont le cabinet fixe la fréquence selon le risque.
Le responsable vérifie la fiche, les tests, quelques entrées du journal, les accès et le registre. Un automatisme qui ne sert plus est arrêté. La revue se note dans la fiche, datée.
Faire l'inventaire de vos automatismesRouage dresse avec vous l'inventaire de vos automatismes et conçoit leur journal, jusqu'à ce que vos équipes sachent lire le journal, rejouer un cas et reprendre après une erreur sans nous.
Prendre RDVQuestions fréquentes
Qui est responsable d'un automatisme construit par un collaborateur ?
Pour ses clients, c'est le cabinet qui produit et transmet le résultat : c'est lui qui en répond, quel que soit l'auteur de l'automatisme.
Faut-il interdire à ses équipes de construire des automatismes avec l'IA ?
Nous ne le recommandons pas : l'interdiction pousse les automatismes à se cacher. Mieux vaut exiger une déclaration avant toute mise en service.
Que faire quand la personne qui a construit un automatisme part ?
Une passation de dossiers : fiche, accès et cas de test repris avec le successeur. Si personne ne peut reprendre, on arrête l'automatisme.
À quelle fréquence revoir ses automatismes ?
Les textes cités ici n'en fixent pas. Nous recommandons une revue à chaque changement, et une revue périodique dont le cabinet fixe la fréquence selon le risque.
À lire ensuite
- L'IA n'a rien inventé : elle a ouvert les systèmes complexes à ceux qui connaissent le métierGuide
- Construire des workflows fiables : traçables, auditablesFormation
- LCB-FT et IA : pourquoi le dispositif doit rester traçableGuide
- Le métier avant la technique : la nouvelle compétence rare en cabinetGuide
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.
- Règlement (UE) 2016/679 du 27 avril 2016 (RGPD), texte publié par la CNIL : art. 4, point 9 (destinataire), art. 5 (principes relatifs au traitement), art. 30 (registre des activités de traitement), art. 32 (sécurité du traitement).
- Anthropic, « Model deprecations », documentation : retrait régulier des anciens modèles, échec des requêtes vers un modèle retiré, recommandation de tester avant la date de retrait.