Il y a une objection raisonnable à tout le discours sur la refonte des processus et des rôles, et il vaut la peine de la prendre au sérieux, parce que la plupart du temps elle a raison. Qui propose de revoir le processus propose presque toujours de ralentir. Il ajoute une étape d’approbation, un document à remplir, un comité qui se réunit le jeudi, et il le fait au pire moment, c’est-à-dire quand une équipe a enfin trouvé un rythme. Toutes les méthodologies des trente dernières années se sont présentées comme de la qualité et ont été livrées comme de la bureaucratie. Les pages de gouvernance de l’intelligence artificielle produites depuis deux ans sont en grande partie du théâtre, et elles servent à pouvoir dire à un conseil d’administration que le sujet est couvert. Si quelqu’un arrive avec une proposition de réorganisation en main, la méfiance est saine.
Une panne qui ne lève aucune exception
Ce que l’objection ne couvre pas, c’est une classe de pannes qui ne produit aucune erreur. Elle ne génère pas de ticket, ne fait pas échouer de pipeline, n’apparaît sur aucun tableau de bord. Le symptôme n’a pas la forme d’un incident mais celle d’une phrase dite en rétrospective, en général vers le troisième ou quatrième mois d’usage d’un outil agentique, quand quelqu’un observe que le modèle s’est dégradé.
La lecture naturelle est que le fournisseur a dégradé quelque chose, ou que l’enthousiasme initial était gonflé. Ce n’est presque jamais ce qui s’est passé. Ce qui s’est passé, c’est que le fichier d’instructions du projet a grossi au-delà du seuil où l’agent parvient encore à tout tenir ensemble, et qu’il a commencé à écarter en silence la moitié qui comptait. Ou bien que la description d’une procédure automatique a dérivé de reformulation en reformulation jusqu’à se déclencher sur n’importe quoi, ce qui équivaut à ne plus se déclencher du tout. Aucune de ces deux pannes ne lève d’exception. Il n’existe pas de stack trace pour un échafaudage qui se défait, et faute d’erreur l’équipe attribue la baisse à l’outil plutôt qu’à sa propre charpente.
Le statut de la configuration personnelle
C’est la première manifestation d’un principe qui, une fois vu, se reconnaît dans trois ou quatre endroits différents de la même entreprise. Ce qui se dégrade sans faire de bruit est exactement ce que personne n’est tenu de vérifier.
Le code applicatif a une défense contre la dégradation silencieuse, et cette défense est que quelqu’un a écrit un test qui se met en colère. Les instructions avec lesquelles nous pilotons un agent, les prompts sauvegardés, les conventions de projet, les automatisations censées se déclencher toutes seules, tout ce matériel devenu en deux ans une infrastructure de production, a hérité du statut de la configuration personnelle. Il vit dans le dossier d’un projet sans propriétaire déclaré, sans changelog, sans personne qui réponde de sa maintenance. En pratique, l’échafaudage le plus jeune et le plus fragile de toute la chaîne de livraison est aussi le seul que nous n’avons pas pensé à mettre sous vérification.
Le mot « fait »
La deuxième manifestation concerne un mot que nous tenons pour défini en entreprise et qui ne l’est pas. Ce mot est « fait ». Un an et demi d’adoption d’outils génératifs a accéléré beaucoup de choses, et l’une de celles qu’il a le plus accélérées est la déclaration d’achèvement. Un agent arrive au bout d’une tâche avec une assurance qui n’a pas d’équivalent dans la vérification, et la formule par laquelle il conclut est indiscernable de celle d’un travail réellement terminé.
Si la définition de fait est écrite en prose, dans une page de conventions internes que tout le monde a lue une fois, elle est respectée quand il y a du temps et sautée quand il n’y en a pas, c’est-à-dire quand cela compte. Elle n’est pas sautée par négligence. Elle est sautée parce qu’une règle en prose entrera toujours en concurrence, et toujours en perdant, avec une livraison qui a une date. La différence entre une règle écrite et un contrôle déterministe qui bloque la déclaration d’achèvement quand un fichier source a changé après le dernier test passé n’est pas une différence de rigueur. C’est la différence entre une intention et une contrainte, et sous pression seule la seconde survit.
Entre-temps le coût n’a pas disparu, il s’est déplacé. Il s’est déplacé sur la review, sur le rework, sur la réouverture de tâches déjà marquées comme closes, et sur aucune de ces trois lignes personne ne le mesure, parce que la métrique que nous regardons continue d’être la vitesse à laquelle les choses sont déclarées terminées.
L’inventaire que personne ne régénère en milieu de sprint
La troisième manifestation est celle que je connais le mieux, parce que je travaille depuis des années avec des clients de la santé et de l’administration publique, où la conformité n’est pas un sujet de réputation mais une condition d’admissibilité. La conformité réglementaire n’échoue pas par ignorance. Personne, dans aucune entreprise qui a lu un appel d’offres ces trois dernières années, ne doute qu’il faille une nomenclature des composants logiciels. Le point est que personne ne la régénère en milieu de sprint, parce que rien n’oblige ce moment à exister : il y a une release à boucler, et régénérer l’inventaire des dépendances entre en concurrence avec cette release pour l’attention de quelqu’un et perd, chaque fois, jusqu’au jour où un auditeur la demande et où elle n’existe pas. J’ai développé cet argument en soutenant que la compliance n’échoue pas par manque de normes, et depuis je n’ai pas trouvé un seul contre-exemple.
La panne est identique aux deux précédentes. Ce n’est pas une lacune de compétence, c’est l’absence d’un moment obligé. La différence est qu’ici l’horloge est publique et non négociable, parce que les obligations de signalement des vulnérabilités du Cyber Resilience Act s’appliquent dès le 11 septembre 2026, le règlement entre en plein régime le 11 décembre 2027, et l’European Accessibility Act est en vigueur depuis le 28 juin 2025. Le frottement qui coûtait hier encore une figure de style en réunion coûte désormais une non-conformité.
Acheter de la capacité au lieu de diagnostiquer
Il vaut la peine d’ajouter une quatrième occurrence, plus petite mais diagnostique, parce qu’elle montre à quel point on se trompe facilement de remède. Quand une équipe commence à buter contre les limites d’usage des outils agentiques, la conclusion immédiate est qu’il faut un forfait plus large ou un autre modèle. Dans la grande majorité des cas, le facteur de coût n’est pas le modèle choisi, c’est le contexte accumulé au fil d’une session longue, et la solution ne réside pas dans l’achat mais dans la manière de découper le travail.
C’est la même erreur à échelle réduite : face à une panne invisible, nous achetons de la capacité au lieu de diagnostiquer le mécanisme, parce qu’acheter de la capacité est une action que l’on peut décider en dix minutes, et diagnostiquer un mécanisme non.
Ceux qui savent dire non
À partir d’ici la question cesse d’être technique et devient une question de rôles, et c’est pour cela qu’elle m’intéresse. Si le goulot d’étranglement se déplace de la production vers la vérification, la ressource rare n’est plus qui écrit vite. C’est qui sait dire non avec une motivation, et sait le dire à propos d’un artefact qui a toutes les apparences de la correction. C’est la même migration de valeur que j’ai appelée ailleurs dette de spécification, vue du côté de la sortie plutôt que de l’entrée.
Dans les petites équipes, cela produit un effet que j’ai observé de près : une personne junior accompagnée d’un agent livre un output avec la surface d’un travail senior, sans le jugement qui accompagne d’habitude cette surface, et la charge de revue se concentre sur deux ou trois personnes qui deviennent la contrainte de tout le reste. La réaction instinctive est de demander à ces deux ou trois personnes de relire plus vite. La bonne réaction est de se demander quelle part de leur jugement était en réalité une règle que personne n’avait jamais écrite, et de l’écrire sous une forme qui se déclenche d’elle-même.
La formation et le plancher sont deux investissements
C’est ici que formation et baseline se séparent, et qu’elles doivent être financées comme deux investissements distincts, parce qu’elles répondent à des questions différentes. La formation sert à élever les personnes, à élargir ce qu’elles savent voir, à déplacer quelqu’un du niveau de l’exécution à celui de la spécification et de la vérification. Mais la formation produit des résultats au-dessus d’un plancher, et dans une équipe de dix personnes ce plancher n’existe pas par défaut. Il existe seulement si quelqu’un le construit, le met sous versionnement et le traite comme un artefact entretenu au lieu d’un dossier de notes.
Sans cet étage du dessous, l’élévation des personnes reste un propos de présentation institutionnelle : chacun travaille à son propre niveau de rigueur, la variance entre une livraison et l’autre dépend de qui l’a prise en charge, et personne ne parvient à distinguer une amélioration due à la méthode d’une amélioration due à une seule personne particulièrement scrupuleuse. Le plancher ne sert pas à limiter les bons éléments. Il sert à rendre visible leur contribution, qui sinon se confond avec le bruit.
Ce qu’aucune machine ne peut déclarer valide
Il reste un dernier passage, et il reprend le point d’où je suis parti il y a quelques jours en écrivant sur le niveau qui ne se délègue pas. Toute cette architecture de vérifications automatiques a une limite structurelle, et cette limite est qu’aucune d’elles ne peut déclarer valide son propre résultat. Une machine peut inventorier, peut générer, peut signaler une lacune, peut bloquer une déclaration d’achèvement. Ce qu’elle ne peut pas faire, c’est marquer son propre travail comme accepté, conforme ou validé, et non parce que ce serait techniquement impossible mais parce que dans ce geste se trouve la seule chose qu’un ordre juridique reconnaisse, à savoir une personne qui répond. Sur ce point, la régulation européenne a cessé depuis longtemps d’être une opinion et s’est mise à écrire l’organigramme à notre place.
La valeur n’est pas de produire plus d’artefacts, elle est de produire de la preuve au lieu de la confiance. Un rapport qui, pour chaque item, dit présent, lacune ou non applicable, avec un pointeur ou une motivation, est utilisable dans un contradictoire. Un rapport qui dit que tout semble en ordre ne l’est pas, et la différence entre les deux n’est pas de ton, elle est d’admissibilité.
C’est pourquoi j’ai publié en open source, sous licence MIT, la baseline que j’utilise : treize procédures plus un contrôle qui, à la fin de la session, bloque la déclaration d’achèvement quand un fichier source a changé après le dernier test passé. Il y a les tests qui vérifient les procédures, 1 111 contrôles dans dix-neuf suites, et un dépôt de test construit pour échouer exprès sur chaque surface que l’audit de l’échafaudage contrôle, parce qu’un échafaudage dont on affirme la solidité sans la montrer tombe exactement dans la classe de pannes qu’il prétend prévenir. Cela se trouve sur oltrematica.github.io/oltrematica-skills, et qui le veut peut le contester ligne par ligne, ce qui est la seule manière sérieuse d’offrir une chose de ce genre.
Deux questions pour le conseil d’administration
Mais la partie utile à un conseil d’administration n’est pas le dépôt. Ce sont deux questions à mettre à l’ordre du jour de la prochaine réunion de direction, et leur utilité tient à ce que répondre n’exige aucune instruction préalable.
La première : qui, dans l’entreprise, est tenu de vérifier que notre échafaudage fonctionne encore, et avec quelle preuve. La seconde : de ce que nous appelons aujourd’hui fait, quelle part est tenue par une contrainte et quelle part par une intention. Si à la première ne correspond aucun nom et à la seconde aucun contrôle, ce n’est pas un problème d’outils, et aucun achat ne le résoudra.
Ce qu'il faut retenir
Il existe une classe de pannes qui ne produit aucune erreur : un fichier d’instructions grossi au-delà du seuil d’attention de l’agent, la description d’une automatisation qui a dérivé jusqu’à se déclencher sur tout. Il n’y a pas de stack trace pour un échafaudage qui se défait, et faute d’erreur l’équipe accuse le modèle.
Ce qui se dégrade sans faire de bruit est exactement ce que personne n’est tenu de vérifier. Le code applicatif a une défense contre la dégradation silencieuse, et cette défense est un test qui se met en colère. Les instructions avec lesquelles nous pilotons les agents ont hérité du statut de la configuration personnelle : aucun propriétaire, aucun changelog, aucune maintenance.
Une définition de « fait » écrite en prose entrera toujours en concurrence avec une livraison qui a une date, et perdra toujours. Un contrôle déterministe qui bloque la déclaration d’achèvement quand un fichier source a changé après le dernier test passé n’est pas plus rigoureux : c’est une contrainte au lieu d’une intention, et sous pression seule la contrainte survit.
Formation et baseline sont deux investissements distincts. La formation produit des résultats au-dessus d’un plancher, et dans une équipe de dix personnes ce plancher n’existe pas par défaut : il existe si quelqu’un le construit, le versionne et l’entretient. Sans cet étage du dessous, la variance entre deux livraisons dépend de qui les a prises en charge.
Aucune vérification automatique ne peut déclarer valide son propre résultat, et pas pour une raison technique : dans ce geste se trouve la seule chose qu’un ordre juridique reconnaisse, une personne qui répond. La valeur n’est pas de produire plus d’artefacts, elle est de produire de la preuve au lieu de la confiance.
Questions & réponses
Pourquoi est-il sain de se méfier de qui propose de revoir le processus ?
Parce que la plupart du temps il propose de ralentir, et il le propose au pire moment, quand une équipe a enfin trouvé un rythme. Toutes les méthodologies des trente dernières années se sont présentées comme de la qualité et ont été livrées comme de la bureaucratie, et une bonne part des pages de gouvernance de l’intelligence artificielle produites depuis deux ans sert à pouvoir dire à un conseil d’administration que le sujet est couvert. La méfiance est saine. Simplement, elle ne couvre pas les pannes qui ne produisent aucune erreur.
Pourquoi un agent semble-t-il se dégrader après quelques mois ?
Presque jamais parce que le fournisseur a dégradé le modèle. Plus souvent, le fichier d’instructions du projet a grossi au-delà du seuil où l’agent parvient encore à tout tenir ensemble, et il a commencé à écarter en silence la moitié qui comptait ; ou bien la description d’une procédure automatique a dérivé de reformulation en reformulation jusqu’à se déclencher sur n’importe quoi, ce qui équivaut à ne plus se déclencher du tout. Aucune des deux pannes ne lève d’exception, et faute d’erreur la baisse est attribuée à l’outil plutôt qu’à l’échafaudage.
Quelle différence fait un contrôle déterministe par rapport à une règle écrite ?
Une règle en prose, par exemple une définition de « fait » dans une page de conventions internes, est respectée quand il y a du temps et sautée quand il n’y en a pas, c’est-à-dire quand cela compte. Non par négligence : parce qu’elle entrera toujours en concurrence, et toujours en perdant, avec une livraison qui a une date. Un contrôle qui bloque la déclaration d’achèvement quand un fichier source a changé après le dernier test passé n’est pas une différence de rigueur, c’est la différence entre une intention et une contrainte. Sous pression, seule la seconde survit, et le coût qui semble économisé se déplace sur la review, le rework et la réouverture de tâches déjà marquées closes.
Pourquoi personne ne régénère l’inventaire des dépendances en milieu de sprint ?
Pas par ignorance. Aucune entreprise qui a lu un appel d’offres ces trois dernières années ne doute qu’une nomenclature des composants logiciels soit nécessaire. Le point est que rien n’oblige ce moment à exister : il y a une release à boucler, et régénérer l’inventaire entre en concurrence avec cette release pour l’attention de quelqu’un et perd, chaque fois, jusqu’au jour où un auditeur le demande et où il n’existe pas. La différence avec les autres pannes, c’est qu’ici l’horloge est publique : les obligations de signalement des vulnérabilités du Cyber Resilience Act s’appliquent dès le 11 septembre 2026, le règlement entre en plein régime le 11 décembre 2027 et l’European Accessibility Act est en vigueur depuis le 28 juin 2025.
Pourquoi financer séparément la formation et la baseline ?
Parce qu’elles répondent à des questions différentes. La formation sert à élever les personnes, à élargir ce qu’elles savent voir, à déplacer quelqu’un de l’exécution vers la spécification et la vérification. Mais elle produit des résultats au-dessus d’un plancher, et dans une équipe de dix personnes ce plancher n’existe pas par défaut : il existe seulement si quelqu’un le construit, le met sous versionnement et le traite comme un artefact entretenu au lieu d’un dossier de notes. Sans cet étage du dessous, chacun travaille à son propre niveau de rigueur et personne ne parvient à distinguer une amélioration due à la méthode d’une amélioration due à une seule personne particulièrement scrupuleuse.
L'auteur
