Du prompt au résultat : construire la chaîne de preuve du delivery agentique

Index

• Pourquoi l’activité agentique ne suffit plus à piloter le delivery
• Quand la télémétrie devient elle-même un risque de décision
• La chaîne de preuve : intention, contexte, exécution, contrôle, livraison, résultat
• Pourquoi le coût et le contexte font partie de la preuve
• Ce que cette logique change pour le Product Management
• Les anti-patterns à éviter
• Les indicateurs à suivre

Piloter l’agent par son activité crée une illusion de maîtrise

Les agents de développement élargissent rapidement leur champ d’action. Ils peuvent analyser un élément de backlog, consulter du contexte documentaire, modifier du code, lancer des tests, corriger une erreur et préparer une proposition de changement. Cette continuité réduit certains handoffs humains. Elle crée aussi un nouveau problème : une grande partie du travail devient moins visible dans les artefacts finaux.

Une pull request peut être le résultat de dizaines d’actions intermédiaires. À l’inverse, une longue exécution agentique peut produire beaucoup d’activité sans livrer un changement exploitable.

La distinction devient donc fondamentale entre activité, livrable, conformité et résultat.

L’activité décrit ce qui a été exécuté. Le livrable décrit ce qui a été produit. La conformité indique ce qui a été contrôlé. Le résultat décrit ce qui a réellement changé pour le produit, le système ou les utilisateurs.

Ce problème n’est pas spécifique à l’intelligence artificielle. Les organisations confondent depuis longtemps volume d’activité et performance. Mais l’agentique augmente l’écart potentiel entre les deux : le coût marginal d’une nouvelle analyse, d’un nouveau patch ou d’un nouveau cycle de tests diminue, alors que la capacité humaine à vérifier la pertinence, le risque et la valeur reste limitée.

Une plateforme de développement décrit désormais explicitement le besoin de relier les changements de l’idée jusqu’à la production, avec une identité, des politiques et des preuves communes. Elle présente cette traçabilité comme une condition pour comprendre comment un changement a été réalisé et pour mesurer l’impact réel des investissements dans l’IA. [1]

Cette promesse fournisseur ne prouve pas que toutes les organisations disposent déjà d’une telle chaîne. Elle indique en revanche que le problème devient suffisamment structurant pour être traité comme une capacité de plateforme.

Le risque stratégique apparaît lorsque l’organisation mesure ce que l’agent fait sans pouvoir expliquer pourquoi ce travail a été déclenché, sur quel contexte il s’est appuyé, ce qui a été vérifié, quelle version a réellement été livrée et quel effet a ensuite été observé.

Une métrique peut être correcte techniquement et fausse pour la décision

Le 6 octobre 2026, une anomalie de télémétrie a fourni un exemple particulièrement instructif. Plusieurs environnements de développement avaient déplacé certaines sessions d’agents vers un SDK commun. Ces sessions n’identifiaient plus correctement leur environnement d’origine. Une partie de l’activité a alors disparu des rapports, tandis qu’une autre a été attribuée à un client différent. [2]

La facturation n’était pas affectée. Les métriques d’activité, elles, l’étaient.

Le point le plus important est que les données manquantes ne peuvent pas être reconstituées rétroactivement. L’activité a bien eu lieu, mais une partie de la chaîne d’observation a perdu l’information nécessaire pour l’attribuer correctement. [2]

Cet incident illustre un principe plus général : une métrique n’est jamais seulement un nombre ; elle dépend d’un système de collecte, d’une définition, d’une version logicielle et d’une règle d’attribution.

Une baisse soudaine du nombre d’interactions agentiques pourrait donc être interprétée comme un recul d’adoption alors qu’elle reflète un changement d’instrumentation. Une hausse apparente d’un canal pourrait provenir d’une erreur d’attribution. Une série historique peut devenir difficile à comparer lorsque les événements qui la composent changent de définition.

Pour le pilotage produit, la conséquence est directe : avant d’utiliser une métrique pour arbitrer, il faut être capable de répondre à trois questions.

Que mesure-t-elle exactement ?

Il faut distinguer requête, session, action, ligne de code générée, ligne acceptée, changement mergé, déploiement ou effet produit. Ces événements ne sont pas interchangeables.

Comment est-elle collectée ?

Une donnée client, une donnée serveur et une donnée issue du système de production n’ont pas les mêmes angles morts.

Sa définition est-elle restée stable ?

Une évolution d’IDE, de modèle, de SDK ou de pipeline peut rompre la comparabilité sans modifier le comportement réel des équipes.

Cette discipline peut sembler technique. Elle est en réalité produit : une décision fondée sur une mesure non comparable peut modifier les priorités, le staffing ou les investissements alors que le phénomène supposé n’existe pas.

Le delivery agentique multiplie les ruptures possibles entre intention et résultat

Plus un workflow est automatisé, plus il devient important de distinguer les transitions qui doivent rester démontrables.

Un élément de backlog peut être suffisamment clair pour déclencher un agent, mais reposer sur une hypothèse produit obsolète. Un agent peut produire un patch conforme au ticket, mais sur une version de la documentation qui n’est plus la référence. Les tests peuvent réussir sur un commit différent de celui finalement déployé. Un déploiement peut être techniquement vert sans résoudre le problème utilisateur.

Chaque étape peut être correcte localement alors que la chaîne globale est incohérente.

La réponse n’est pas de conserver un journal exhaustif de chaque pensée du modèle ou de chaque appel d’outil. Une telle approche créerait du bruit, augmenterait les coûts et pourrait exposer inutilement des informations sensibles.

L’objectif est différent : conserver les preuves minimales permettant de vérifier les transitions importantes.

On peut représenter cette chaîne par six maillons :

1. Intention. Quel problème cherche-t-on à résoudre ? Quel résultat attendu justifie le travail ? Qui possède la décision ?

2. Contexte. Quelles sources, versions, contraintes et autorisations ont été utilisées ? Les informations de référence étaient-elles à jour ?

3. Exécution. Quel agent, quel modèle ou quel outil a produit le changement ? Quels artefacts ont été modifiés ?

4. Contrôle. Quels tests, revues, analyses de sécurité ou validations humaines ont été appliqués ? Sur quelle version exacte ?

5. Livraison. Quelle version a réellement atteint l’environnement cible ? La preuve concerne-t-elle bien ce candidat ?

6. Résultat. Quel signal permet de déterminer si le problème initial a été réduit, déplacé ou inchangé ?

L’intérêt de cette chaîne n’est pas documentaire. Il est décisionnel.

Si le résultat n’est pas conforme, elle aide à localiser le maillon qui a échoué : hypothèse produit, contexte, implémentation, vérification, déploiement ou mesure.

Sans cette continuité, l’organisation ne dispose que d’une collection d’artefacts « verts » qu’elle doit réinterpréter après coup.

Le contexte connecté améliore l’exécution, mais il ne crée pas automatiquement une vérité

Un autre mouvement du marché consiste à connecter les agents au graphe de travail de l’entreprise : code, tickets, décisions, documents, conversations, standards et sources tierces. Une publication fournisseur décrit cette couche de contexte comme la fondation d’un cycle de développement agentique et rapporte, dans ses tests internes, jusqu’à 44 % d’amélioration de qualité de réponse et jusqu’à 48 % de réduction de jetons pour certaines configurations. [3]

Ces chiffres sont des résultats internes au fournisseur. Ils ne doivent pas être généralisés à tous les environnements.

Le point stratégique est ailleurs : donner plus de contexte n’élimine pas le besoin de gouverner ce contexte.

Un graphe peut relier deux documents contradictoires. Il peut retrouver une décision remplacée mais toujours accessible. Il peut exposer une architecture historique qui n’est plus applicable. Il peut fournir une politique dont la date d’effet est dépassée.

L’accès à l’information et l’autorité de l’information sont deux choses différentes.

Une organisation qui veut confier davantage de travail aux agents doit donc traiter certaines propriétés documentaires comme des éléments opérationnels : source de vérité, version, propriétaire, date de validité et relation avec la décision qu’un document remplace.

Cette exigence change le rôle de la documentation. Elle ne sert plus seulement à transmettre des connaissances aux humains. Elle devient une partie de l’environnement dans lequel des systèmes automatisés prennent des décisions d’exécution.

Cela implique également de préserver les permissions. Un agent capable de lire une information n’est pas nécessairement autorisé à exécuter toutes les actions qui pourraient logiquement en découler. Le contexte doit informer l’action sans abolir les frontières de responsabilité.

Le coût doit être relié au livrable accepté, pas seulement à l’exécution

Le delivery agentique rend aussi visible une limite économique.

Une exécution autonome peut consommer des ressources sans produire de résultat utilisable. Un agent peut relancer une recherche, répéter un cycle de correction, multiplier des tests ou explorer plusieurs pistes qui seront finalement abandonnées.

Mesurer uniquement le nombre d’appels, de jetons ou de minutes d’agent donne une vision du coût, pas de la valeur.

Une plateforme de delivery annonce désormais des fonctions visant à analyser les coûts et les résultats par équipe, tâche ou modèle dans le même environnement que les contrôles de production. [1]

Cette évolution invite à distinguer plusieurs niveaux :

• coût d’exécution : ressources consommées pour une tentative ;
• coût du livrable accepté : ressources nécessaires pour obtenir un changement qui franchit les contrôles ;
• coût des reprises : ressources consommées pour corriger une mauvaise hypothèse, une erreur ou une non-conformité ;
• coût du résultat utile : investissement rapporté à un effet métier ou utilisateur observable.

Le dernier niveau est le plus difficile.

Une amélioration de conversion, une baisse d’incidents ou une réduction du délai de traitement dépend rarement d’un seul facteur. Attribuer automatiquement un résultat à l’agent parce qu’il a contribué au code constituerait une causalité non démontrée.

La discipline consiste donc à séparer contribution observée et causalité établie.

L’agent peut avoir produit le changement. Les tests peuvent confirmer sa conformité. La production peut démontrer son déploiement. Seule une méthode d’évaluation adaptée peut déterminer si ce changement a effectivement contribué au résultat attendu.

Synthèse systémique

Cette grille n’est pas un standard officiel. Elle synthétise les risques mis en évidence par les sources et les traduit en questions de pilotage.

Exemple pédagogique : prouver un correctif plutôt que compter les actions

Considérons un scénario fictif. Une équipe produit observe des échecs intermittents lors de la validation d’un panier. Elle utilise plusieurs agents pour analyser les incidents, proposer un correctif et exécuter les contrôles.

Le Sprint Goal est : réduire les échecs de validation du panier sans augmenter les erreurs de paiement ni le temps de réponse.

L’équipe fixe avant l’exécution trois critères de décision pour la Sprint Review :

• poursuivre le déploiement si le taux d’échec baisse d’au moins 20 % sur un volume suffisant ;
• revenir au comportement précédent si un indicateur de paiement se dégrade au-delà d’un seuil de sécurité prédéfini ;
• considérer l’hypothèse comme non démontrée si les données de production ne permettent pas une comparaison fiable.

Ces pourcentages sont des critères pédagogiques de décision, pas des résultats observés.

L’agent d’analyse peut produire un diagnostic. L’agent de développement peut générer un correctif. Les tests peuvent être verts. Pourtant, aucune de ces preuves ne suffit isolément à affirmer que le problème utilisateur est résolu.

La chaîne complète doit relier l’incident initial, la version des données analysées, le commit testé, la version réellement déployée et la mesure de production retenue pour la Review.

Si la télémétrie change pendant l’expérience, la bonne décision peut être de suspendre la conclusion plutôt que de déclarer une réussite ou un échec sur des données non comparables.

Ce comportement est plus important que l’automatisation elle-même : l’équipe protège la qualité de sa décision, même lorsque le système peut produire très vite une réponse techniquement plausible.

Ce que cette logique change pour le Product Management

Le Product Owner n’a pas vocation à auditer chaque appel d’outil d’un agent.

Sa responsabilité se situe plus haut : rendre explicites le problème, les résultats attendus, les contraintes importantes et les critères qui permettront d’apprendre.

Dans un système fortement agentique, cette clarté devient encore plus importante parce que l’ambiguïté peut être exécutée rapidement.

Un backlog contenant des demandes formulées comme des solutions sans hypothèse explicite produit déjà du risque avec une équipe humaine. Avec des agents capables d’enchaîner le travail automatiquement, il peut produire du volume avant que l’organisation ne découvre que la question initiale était mal posée.

Le Product Management doit donc renforcer quatre disciplines.

Définir le résultat avant le mécanisme.

Un agent peut optimiser une solution. Il ne devrait pas déterminer implicitement quel résultat métier justifie le travail.

Identifier les décisions irréversibles.

Plus une action est difficile à annuler, plus la preuve exigée avant exécution doit être forte.

Définir la mesure avant la livraison.

Choisir l’indicateur après avoir vu le résultat favorise les interprétations opportunistes.

Inspecter les preuves lors des revues.

Une démonstration de fonctionnalité est utile, mais elle ne remplace pas la vérification du problème traité, de la qualité du candidat et des premiers signaux de résultat.

Cette logique rapproche le delivery agentique de l’empirisme : une hypothèse est formulée, un changement est réalisé, ses effets sont observés et la décision suivante dépend de ces observations.

L’IA peut accélérer plusieurs étapes de cette boucle. Elle ne supprime pas la nécessité de savoir quelle observation serait suffisamment fiable pour modifier la décision.

Anti-patterns à éviter

« L’agent a beaucoup travaillé, donc il a créé de la valeur. »

→ Distinguer activité, livrable accepté et résultat observé.

« Le dashboard le montre, donc la tendance est réelle. »

→ Vérifier la définition, la collecte et les ruptures de télémétrie avant toute comparaison.

« Tous les documents sont accessibles, donc le contexte est bon. »

→ Définir les sources de vérité et marquer les décisions remplacées ou périmées.

« Les tests sont verts, donc le changement est sûr. »

→ Vérifier que les preuves concernent exactement le candidat déployé et couvrent les risques pertinents.

« Le KPI s’améliore après la livraison, donc l’agent a causé l’amélioration. »

→ Parler de contribution ou d’association tant qu’une méthode ne permet pas d’établir la causalité.

« Il faut tout tracer. »

→ Conserver les preuves nécessaires aux décisions et aux risques, pas une accumulation indiscriminée de logs.

Indicateurs utiles

Complétude de la chaîne de preuve.

Part des changements pour lesquels intention, candidat contrôlé, version déployée et mesure de résultat peuvent être reliés.

Taux de métriques comparables.

Part des indicateurs clés dont la définition et la collecte sont restées stables sur la période analysée.

Taux de reprise après validation.

Part des livrables ayant franchi les contrôles mais nécessitant ensuite une correction liée à une preuve insuffisante ou mal attribuée.

Délai de décision après livraison.

Temps nécessaire pour obtenir un signal suffisamment fiable afin de poursuivre, adapter ou annuler l’hypothèse.

Coût par livrable accepté.

Ressources agentiques consommées rapportées aux changements ayant réellement franchi les contrôles définis.

Ces indicateurs ne doivent pas devenir de nouveaux objectifs locaux. Leur rôle est de rendre visibles les points où l’organisation perd la capacité d’expliquer ou de vérifier son propre delivery.

Conclusion

Le delivery agentique ne crée pas uniquement un problème de vitesse. Il crée un problème de continuité de la preuve.

Quand les agents peuvent analyser, modifier, tester et proposer des changements à grande vitesse, il devient facile de produire davantage d’activité que l’organisation ne peut réellement interpréter.

L’incident de télémétrie documenté dans les sources montre qu’une activité réelle peut devenir partiellement invisible lorsque sa chaîne de mesure se rompt. Les offres de plateforme qui cherchent à relier contexte, gouvernance, coûts et livraison montrent en parallèle que la traçabilité devient une capacité structurante du logiciel moderne. Les études fournisseurs sur les cycles de développement agentiques montrent enfin que le contexte et la mesure sont désormais traités comme des fondations, pas comme des fonctions périphériques.

La maturité ne se mesurera donc pas seulement au nombre d’agents déployés ni au volume de code qu’ils produisent.

Elle se mesurera à la capacité de l’organisation à répondre simplement à cinq questions : pourquoi ce travail a-t-il été déclenché, sur quel contexte, qu’a-t-on réellement vérifié, quelle version a été livrée et qu’avons-nous appris du résultat ?

Plus le système devient autonome dans l’exécution, plus cette chaîne doit rester explicite.

L’objectif n’est pas de ralentir l’IA par des validations permanentes. Il est de préserver la capacité humaine à prendre une décision fondée sur des preuves lorsque la production, elle, accélère.

Sources

[1] GitLab — “GitLab Announces the Foundation for the Governed Software Factory”, 6 octobre 2026. Source primaire sur la traçabilité de l’idée à la production, les politiques communes, les contrôles et la mesure des coûts et impacts du delivery agentique. Source officielle

[2] GitHub — “Update your IDE to restore agent activity in Copilot usage metrics”, 6 octobre 2026. Source primaire sur l’anomalie d’attribution de télémétrie, l’impossibilité de reconstituer certaines données historiques et les limites des métriques clientes. Source officielle

[3] Atlassian — “Atlassian brings the AI-native SDLC from playbook to production”, 7 octobre 2026. Source primaire sur le rôle du contexte et de la mesure dans le SDLC agentique, avec résultats d’enquête et benchmarks internes explicitement attribués au fournisseur. Source officielle