Votre documentation vient de devenir un organe d'exécution

La plupart des entreprises croulent déjà sous les organigrammes, les procédures, les référentiels et les modes opératoires. Personne n'attend l'IA pour formaliser. Ce que Bertrand Duperrin décrit dans un article publié le 25 août n'est donc pas un appel à documenter davantage. C'est le constat d'un changement de statut :

Dès lors qu'une représentation ne sert plus seulement à expliquer comment l'entreprise fonctionne mais contribue à son fonctionnement, elle cesse d'être un simple patrimoine documentaire pour devenir une composante du système d'exécution lui-même.

La conséquence est immédiate et rarement tirée : une approximation qui passait autrefois inaperçue peut désormais conduire un agent à prendre une mauvaise décision, à propager une règle obsolète, ou à automatiser un fonctionnement qui n'aurait jamais dû l'être.

Formaliser n'est pas documenter

Le mot documentation traîne une mauvaise réputation méritée : des procédures jamais consultées, des référentiels jamais à jour, des dossiers produits pour satisfaire un audit. Beaucoup d'organisations en ont conclu que le problème venait de la documentation elle-même.

C'est une confusion. L'objectif n'a jamais été de produire des documents mais de construire une représentation partagée du fonctionnement de l'entreprise. Cette représentation existe de toute façon, formalisée ou non - dispersée entre les habitudes, les conversations, les tableurs, les tickets de support et les décisions prises au fil des situations. Le coût apparaît le jour où ces versions cessent d'être compatibles : un départ, une arrivée, un changement d'échelle.

Formaliser, c'est rendre cette représentation discutable. Une procédure n'a pas d'abord pour fonction d'imposer une manière de faire, mais d'établir un référentiel que chacun peut comprendre, contester et faire évoluer. Sans elle, impossible de distinguer une pratique locale pertinente d'une innovation, d'une erreur, ou d'une simple interprétation différente de la même consigne.

L'IA change l'économie de la formalisation

Pendant des années, le retour sur investissement de la formalisation était réel mais indirect : intégrer un nouveau collaborateur, limiter la perte de connaissances à un départ, préparer un audit. Difficile à défendre en arbitrage budgétaire.

Ce qui change, c'est la fréquence d'usage. Une représentation structurée n'est plus consultée le jour où quelqu'un décide d'aller chercher une information : elle est interrogée en permanence par des systèmes qui s'en servent pour comprendre un contexte, préparer une action, orienter une décision ou vérifier une règle. La formalisation cesse d'être une mémoire passive pour devenir un élément actif de l'environnement opérationnel.

Elie Nehmé, qui a construit une application d'entreprise presque entièrement avec un agent, formule la même idée depuis le terrain, en une phrase qui mérite d'être affichée :

Une documentation ne reste correcte que si quelque chose la consomme.

Et il en tire le revers, tout aussi vrai : cela rend une documentation fausse beaucoup plus dangereuse. Si l'agent lit une règle erronée, il produit du code erroné. Mais cela rend aussi la documentation beaucoup plus précieuse - une règle consommée tous les jours a bien plus de chances de rester juste qu'une règle rangée dans un classeur.

Attention au contresens, que Duperrin prend soin d'écarter : il ne s'agit pas de tout codifier. Le jugement, l'expérience et le savoir tacite n'entrent pas dans un fichier de règles. L'enjeu est de rendre explicite ce qui doit être transmis, coordonné ou exécuté de manière fiable - et de représenter aussi les limites de cette formalisation : les situations où une règle suffit, celles où il faut du contexte, celles où une décision humaine reste indispensable.

Trois exécutants au lieu de deux

Pendant longtemps, la répartition du travail était binaire : les personnes faisaient ce qui demandait du jugement, les logiciels exécutaient des traitements déterministes à partir de règles fixées à l'avance. La frontière n'était pas parfaite, mais elle suffisait à structurer les processus et les responsabilités.

L'agent n'entre dans aucune des deux cases. Il interprète un objectif, mobilise des connaissances, choisit une séquence d'actions, appelle des outils, et adapte son comportement à ce qu'il reçoit. Un processus cesse alors d'être une suite de tâches attribuées à des postes pour devenir un assemblage de capacités mobilisées selon leur nature. Une même activité peut passer d'un collaborateur à un agent, revenir à un humain quand une exception apparaît, puis repartir vers un système.

Ce qui compte n'est donc plus seulement de savoir quel métier réalise une activité, mais quelle capacité est nécessaire pour l'exécuter, dans quelles conditions, et avec quel niveau d'autonomie.

Le COO devient l'architecte du système d'exécution

Si la représentation de l'entreprise devient une composante de son exécution, quelqu'un doit en assurer la cohérence. Ce quelqu'un n'est pas l'IT : le sujet touche à la manière dont le travail est conçu, distribué, exécuté et amélioré. C'est historiquement le terrain des opérations, et la thèse de l'article est que l'IA ne crée pas un nouveau métier mais élargit le périmètre de celui qui existe déjà.

Quatre responsabilités en découlent, et elles se lisent comme une feuille de route :

• Le discovery. Avant de représenter le fonctionnement de l'entreprise, il faut comprendre comment elle fonctionne réellement : observer les pratiques, repérer les contournements devenus permanents, distinguer l'exception du fonctionnement normal. C'est le principe du process mining - partir de l'exécution réelle plutôt que des intentions affichées.
• L'architecture. Arbitrer la granularité, expliciter les règles, représenter les dépendances, rendre lisibles les interfaces entre humains, applications et agents. Pas décrire tout ce qui existe : produire un modèle assez fidèle pour être utile, assez simple pour être maintenable, assez précis pour être exécuté.
• La cohérence. Maintenir l'alignement entre la représentation et le réel, accepter les évolutions pertinentes, éliminer les modèles devenus obsolètes.
• La gouvernance. Qui a le droit de modifier une règle ? Comment une évolution est-elle validée ? À quel moment une pratique locale devient-elle un standard ? Quels garde-fous encadrent les décisions d'un agent ?

Le vrai danger : automatiser trop tôt

C'est la partie de l'article qu'il faut lire deux fois, parce qu'elle prévient contre une illusion très disponible : croire qu'il suffit de mieux représenter le travail pour mieux l'exécuter.

Les chercheurs en résilience organisationnelle distinguent le work as imagined - le travail tel que les procédures le décrivent - et le work as done - ce que les opérateurs font réellement pour obtenir le résultat malgré les contraintes et les imprévus. L'écart entre les deux n'est pas un dysfonctionnement : c'est la condition de fonctionnement des organisations. Elles tiennent parce que les gens savent adapter les règles à des situations qui n'avaient pas été prévues.

Le risque d'une entreprise pilotée par des représentations explicites est de traiter cet écart comme une anomalie à éliminer, au lieu de chercher pourquoi il existe. L'organisation y gagne en homogénéité et y perd sa capacité d'apprentissage.

La formule qui résume le mieux la menace n'est pas celle qu'on attend :

Le problème n'est pas d'automatiser, mais d'automatiser trop tôt. Là où une mauvaise procédure restait parfois ignorée dans un classeur, elle peut aujourd'hui devenir la base de décisions prises à grande échelle par des agents. L'IA n'invente pas ces erreurs, elle leur donne davantage de portée.

D'où la conclusion : la représentation ne peut pas être pensée comme un livrable, mais comme un modèle vivant, continuellement confronté au réel. La responsabilité des opérations n'est pas de construire un modèle parfait - il n'existera jamais - mais d'organiser une boucle permanente entre la représentation et l'exécution, afin que chacune corrige l'autre.

Le même diagnostic, vu du produit

Cette analyse rejoint, presque mot pour mot, ce que Johnny R. Domin écrit quelques jours plus tôt à propos de l'agilité, avec une formule qui vaut d'être retenue : l'IA n'améliore pas le système auquel on l'ajoute, elle l'amplifie.

Une équipe avec un backlog confus produira plus vite un backlog confus. Une organisation incapable de distinguer output et outcome générera davantage d'output. Une entreprise qui ne sait pas qui décide pourra automatiser plus vite des décisions mal gouvernées.

Son autre point est d'ordre économique et il structure toute la question : lorsque la production devient moins chère, la décision devient plus chère. Bain estime que des équipes hybrides, humains et agents, pourraient atteindre des gains de productivité de cinq à dix fois - tout en insistant sur le fait que les pilotes et l'accélération locale ne suffisent pas, et qu'il faut repenser les workflows, l'organisation, les mécanismes de contrôle et les systèmes de mesure.

La comparaison qu'il en tire est bonne : le Toyota Production System s'est construit contre la surproduction - fabriquer trop tôt immobilise des ressources et crée des coûts avant qu'une demande n'existe. Dans l'industrie, ce stock est visible ; dans le numérique, il prend la forme de fonctionnalités peu utilisées, de code à maintenir et de complexité supplémentaire. Si l'IA permet de produire cinq fois plus vite, la réponse ne peut pas être de fabriquer cinq fois plus de fonctionnalités.

D'où le déplacement de métrique qu'il propose, et qui nous paraît juste : passer du time-to-market au time-to-learning. Une équipe qui livre une fonctionnalité en quatre heures mais attend trois mois pour découvrir qu'elle n'intéresse personne reste une équipe lente.

Ce que Survol en fait

Nous écrivons depuis longtemps que la spécification est le nouvel actif logiciel et que la difficulté n'est pas de l'écrire mais de la garder vivante. L'article de Duperrin étend le raisonnement au-delà du logiciel, et l'extension tient.

Trois choix de conception y répondent directement :

• La représentation est versionnée, pas archivée. Les contraintes techniques d'organisation sont hiérarchisées - impérative, forte, préférence - et injectées au début de chaque session. Ce sont des règles exécutées, pas un document que quelqu'un aurait dû lire.
• L'écart est tracé, pas effacé. Quand un agent conteste une contrainte, la contestation est enregistrée. C'est précisément la boucle réclamée par l'article : le système d'exécution ne se contente pas d'utiliser le modèle, il apprend de ses écarts avec le réel. Le work as done remonte au lieu de disparaître.
• Rien ne s'automatise avant d'être compris. Une demande devient une spécification validée par un humain avant de devenir une tâche d'agent. C'est notre réponse au « automatiser trop tôt » : la validation n'est pas une formalité, c'est le moment où l'on vérifie qu'on a compris le travail avant de le figer.

Reste la question que ni un outil ni un article ne tranchent à la place d'une entreprise : qui, chez vous, est propriétaire de cette représentation ? Tant qu'elle n'était lue que par des humains, l'absence de réponse coûtait cher lentement. Elle coûtera désormais cher vite.

Sources

• Bertrand Duperrin, « Le COO devient l'ingénieur du système d'exécution de l'entreprise », duperrin.com, 25 août 2026.
• Johnny R. Domin, « AI-Augmented Agile & Product », LinkedIn, 19 août 2026.
• Elie Nehmé, « AI Writes the Code. So What Is the Engineer's Job Now? », Medium, 15 août 2026.