IA agentique : un cadre en 6 étapes pour réduire l’erreur

L’industrialisation par agents multiplie l’impact d’une mauvaise hypothèse. Un cadre structuré en six documents courts vise à aligner parties prenantes et systèmes, à décider au bon niveau et à rendre les arbitrages traçables. Objectif : réduire l’incertitude avant la mise en œuvre, là où rectifier coûte le moins.

Gouvernance et décisions explicites encadrent le changement

Les désaccords doivent être arbitrés par un propriétaire de décision, plutôt que de rester sans réponse. La cinquième étape du cadre établit formellement cette organisation décisionnelle indispensable à la construction, au lancement et à l’exploitation, sous la forme d’un accord explicite. Ce mécanisme fonctionne de façon séquentielle sans suivre un modèle en cascade : une découverte survenant par la suite peut remettre en cause une décision prise précédemment, auquel cas l’artefact concerné est actualisé et la nouvelle décision est explicitement consignée. L’objectif n’est pas de bloquer l’évolution, mais de supprimer les modifications qui ne seraient pas identifiées. Chaque étape génère un document court, utilisable par humains et agents, qui rend les décisions explicites et durables. Ces éléments forment un enregistrement partagé, que les parties prenantes peuvent consulter, avec hypothèses, interprétations et raisonnements.

Avec des agents, l’erreur se propage vite et plus loin

L’introduction d’agents amplifie les risques : là où une journée d’erreur d’un ingénieur isolé a un impact limité, la même erreur déployée par une flotte d’agents s’étend plus vite et plus largement. Une hypothèse incorrecte peut être dupliquée dans chaque modification générée touchant le même modèle avant toute relecture humaine. Le goulot d’étranglement se déplace ainsi en amont, vers la définition précise du problème, le contexte et la validation : aller vite dans la mauvaise direction conduit simplement plus vite au mauvais résultat. La capacité accrue de mise en œuvre rend possible des centaines de changements erronés à faible coût si le besoin initial est mal cadré.

Quand appliquer le cadre et à quelle intensité

Il n’est pas nécessaire de produire six documents pour chaque modification : une correction mineure, un script interne limité ou un prototype destiné à être jeté ne requièrent généralement pas un tel niveau de préparation, qui deviendrait alors source de lourdeur administrative si appliqué à chaque changement. Ce cadre prend tout son sens lorsque l’impact d’une erreur d’orientation devient important : coordination entre plusieurs équipes, ambiguïté sur le problème ou le résultat, dépendances marquées à des systèmes et données existants, choix d’architecture ou de données difficiles à revenir en arrière, travaux simultanés menés par plusieurs personnes ou agents, enjeux financiers, opérationnels, réglementaires ou de réputation, ou encore ampleur du projet rendant les ajustements matériels coûteux en cas d’erreur. Le niveau de détail est modulable : quelques pages suffisent pour un petit périmètre, alors qu’un programme complexe demandera des découvertes et discussions substantielles. L’objectif n’est pas de cocher six cases, mais de réduire l’incertitude qui compte avant d’implémenter, lorsque coordination et coût de l’erreur le justifient. Le cadre n’exclut pas l’expérimentation : en cas d’hypothèse incertaine, un prototype ou un spike peut être le moyen le plus rapide de réduire l’incertitude, à condition d’intégrer ensuite le résultat dans l’étape concernée plutôt que de dévier silencieusement la trajectoire.

Concentrer l’effort là où l’erreur coûte cher

Le principe central est de proportionner l’analyse au coût de réversibilité des décisions. Une étiquette de bouton est hautement réversible et peut être tranchée rapidement, puis ajustée. À l’inverse, un contrat de données, une frontière système ou une architecture d’intégration sont coûteux à corriger et doivent donc faire l’objet d’un examen poussé. Il ne s’agit pas de tout prédire, mais d’investir la préparation sur les points où une mauvaise décision se paierait cher, en gardant volontairement le reste flexible.

Les six livrables structurent problème, solution, rôles et séquence

Le cadre s’articule autour de six artefacts. Les prérequis commerciaux (PID.md) alignent sur le problème, la portée, l’organisation et les objectifs. Les prérequis informatiques (discovery-report.md) éclairent données, systèmes, faisabilité, risques et contraintes. Les exigences fonctionnelles (functional-requirements.md) définissent ce que la solution doit faire, et les exigences techniques (technical-requirements.md) comment elle fonctionnera. La gouvernance (governance.md) précise qui est impliqué, qui décide et qui est responsable. La planification (roadmap.md) fixe quand, dans quel ordre et par qui. Les quatre premières étapes posent ce qui est connu et ce que l’on entend construire et impliquent déjà des décisions et leur propriété.

Exemples : éviter le faux besoin et tester la faisabilité amont

La première étape vise à éviter l’échec coûteux de s’attaquer au mauvais problème. Dans un cas, un client a sollicité en urgence un webhook ; l’équipe s’est exécutée, avant de découvrir que le besoin réel était une API. Une solution impeccable a ainsi ciblé un problème inexistant. La leçon : le client porte le problème, le fournisseur la solution ; un bref entretien sur les objectifs aurait décelé l’écart. Le PID.md doit donc formaliser problème, objectifs, utilisateurs et indicateurs de succès. Côté faisabilité, presque toute solution doit s’intégrer à l’existant. Une équipe a consacré plusieurs sprints à un tableau de bord en temps réel, avant de constater que la source ne livrait qu’un lot toutes les 12 heures : la contrainte amont rendait le temps réel indisponible. D’où l’intérêt d’une découverte précoce sur données, systèmes et dépendances, pour que chacun sache ce qui est possible avant de coder.

Un dépôt GitHub centralise fiches et retours d’expérience

Le cadre réduit l’incertitude en traitant un domaine de décision après l’autre, chaque étape s’appuyant sur la précédente tant que le coût du changement reste faible. Un dépôt GitHub, Project Preparation Framework Repository, propose des fiches d’une page pour chaque étape et des retours d’expérience, avec l’intention d’en faire un projet communautaire ouvert aux contributions. L’ambition affichée est double : construire la bonne chose, de la bonne manière et aussi efficacement que possible, en créant un alignement durable entre humains et agents pour éviter conjectures, retouches et mauvaises surprises.