Point clé
Quand des agents écrivent le code, l'unité de livraison n'est plus le code, c'est un jalon dont quelqu'un répond : des critères d'acceptation écrits, une décision d'architecture avant le développement, des points de revue là où les erreurs coûtent cher, et une seule personne nommée responsable du résultat.
Les agents de code ont changé ce qui coûte cher en livraison logicielle. Cet article s’adresse aux CTO et aux responsables de l’ingénierie qui veulent la vitesse des agents sans hériter de code dont personne ne répond. On y présente le jalon encadré, un plan de production d’une page et les quatre questions à poser à toute équipe qui livre avec des agents.
Écrire le code, c’était la partie lente et coûteuse. Aujourd’hui, un agent peut produire une fonctionnalité qui marche, tests compris, dans le temps qu’il faut pour rédiger le billet. C’est réel, et on ne reviendra pas en arrière.
Ce qui n’a pas baissé, c’est tout ce qui entoure le code. Décider de l’architecture. Vérifier que les tests valident le bon comportement. Repérer la faille de sécurité que personne n’a mentionnée. Répondre du résultat quand ça casse en production six mois plus tard. Ç’a toujours été les parties difficiles. Les agents en ont simplement fait les seules.
Dans un texte de mai 2026 sur l’IA agentique en génie logiciel, Deloitte décrit le passage du SDLC traditionnel (cycle de vie du développement logiciel) à un « cycle de vie du développement orchestré par des agents », où l’ingénieur passe de bâtisseur à superviseur humain dans la boucle. La phrase qui compte le plus pour quiconque achète ou dirige de la livraison est courte : les humains sont responsables de l’architecture, de la validation et de l’imputabilité. Deloitte prévient aussi que les lacunes de gouvernance peuvent effacer les gains de productivité.
Notre position : dès que la génération de code n’est plus la contrainte, l’unité de livraison n’est plus le code. C’est un résultat dont quelqu’un répond. Un jalon avec des critères d’acceptation écrits, révisé aux moments qui comptent, avec une seule personne nommée qui en est responsable.
Où le logiciel bâti par des agents dérape-t-il?
Plus tard, discrètement, et d’une façon difficile à retracer. Le code écrit par un agent compile généralement, passe ses propres tests et fait bonne figure en démo. Les problèmes apparaissent des mois après, et ce sont des problèmes de gouvernance plus que de modèle.
La dérive architecturale. Chaque session d’agent prend des décisions locales raisonnables. Au fil de dizaines de sessions, le code accumule plusieurs façons de gérer l’authentification, une gestion d’erreurs incohérente et un modèle de données que personne n’a vraiment conçu. Deloitte classe la dérive architecturale parmi les risques principaux pour la même raison.
Des tests qui confirment au lieu de vérifier. Les agents écrivent des tests qui décrivent ce que le code fait. Un test qui vérifie ce que le code devrait faire a besoin d’une spécification écrite. Sans elle, la couverture grimpe et la confiance, non.
La sécurité par omission. Une validation d’entrée manquante, un rôle IAM (gestion des identités et des accès) trop large, des secrets dans un fichier de configuration. Personne n’a choisi ça. Ce n’était juste pas dans la requête.
L’atrophie des connaissances. Si personne dans l’équipe ne comprenait le code quand il a été écrit, personne ne le comprendra quand il plantera. L’agent ne se souvient pas de la session.
La responsabilité diluée. « L’équipe » en est responsable, ce qui veut dire en pratique que personne ne l’est. Quand l’incident arrive, personne ne peut expliquer les choix de conception.
Un meilleur agent réduit le nombre d’erreurs. Il ne décide pas qui répond de celles qui restent.
Qu’est-ce qu’un jalon encadré?
C’est un morceau de travail bâti par des agents, entouré de six éléments qui le rendent révisable et lui donnent un responsable. On recommande cette structure à toute équipe qui livre avec des agents, et l’ordre compte autant que les éléments.
1. Un résultat circonscrit. Une phrase sur ce qui existera à la fin et qui n’existe pas aujourd’hui. « Les clients peuvent exporter leurs données d’utilisation en CSV et recevoir un webhook quand un seuil mensuel est franchi. » Pas « améliorer les rapports ».
2. Des critères d’acceptation écrits. Des conditions précises et vérifiables, convenues avant d’écrire la moindre ligne de code. Elles deviennent la spécification que les agents suivent et la liste que les humains utilisent pour accepter le travail. L’ambiguïté à cette étape est la plus grande source de reprises.
3. Une décision d’architecture avant le développement. Un ingénieur principal décide comment le travail s’intègre au système existant : modèle de données, interfaces, authentification, environnement d’exécution. La décision est consignée dans un court registre. Les agents bâtissent à l’intérieur de ces décisions au lieu d’inventer les leurs.
4. Un développement par agents aux limites définies. Les agents s’occupent de l’implémentation, des tests unitaires et des ébauches de documentation, en suivant les critères d’acceptation et le registre d’architecture. Leur accès se limite au dépôt et aux environnements dont le jalon a besoin.
5. Des points de revue là où les décisions coûtent cher à défaire. Pas une revue ligne par ligne de tout. Des points ciblés, chacun avec un réviseur nommé.
6. Un seul responsable nommé. Une personne d’expérience qui répond du jalon du début à la fin : il respecte les critères, il est maintenable et il est sûr. Pas un comité. Un nom que le client peut appeler.
Les critères d’acceptation et l’architecture viennent en premier parce que ce sont eux qui rendent le travail des agents révisable. Sans eux, les réviseurs jugent le code d’après leurs propres suppositions sur l’intention.
De quels points de revue le code écrit par des agents a-t-il besoin?
Cinq, placés là où une mauvaise décision coûte le plus cher à défaire. Chacun a un réviseur nommé et une liste de vérification précise.
| Point de revue | Quand | Ce que le réviseur vérifie |
|---|---|---|
| Architecture | Avant le développement | Arrimage au système existant, modèle de données, conception des interfaces |
| Sécurité | Avant la fusion | Authentification et permissions, traitement des entrées, secrets, risque des dépendances |
| Pertinence des tests | Avant la fusion | Les tests valident les critères d’acceptation et les cas limites, au-delà du scénario idéal |
| Acceptation | Avant la mise en production | Chaque critère démontré, cibles de performance atteintes |
| Exploitabilité | Avant la passation | Journalisation, alertes, guide d’exploitation, plan de retour arrière |
Que doit contenir un plan de production pour du travail bâti par des agents?
Une page par jalon. C’est ce qu’un CTO devrait voir de n’importe quel fournisseur, nous compris, avant que le travail commence.
| Section | Contenu |
|---|---|
| Résultat | Une phrase |
| Critères d’acceptation | Liste numérotée et vérifiable |
| Notes d’architecture | Décisions clés, systèmes touchés, interfaces utilisées ou créées |
| Travail des agents | Ce que les agents bâtissent : composants, tests, documentation |
| Travail humain | Décision d’architecture, chaque point de revue, intégration aux systèmes du client, acceptation |
| Points de revue et réviseurs | Point, moment, réviseur nommé |
| Responsable | Un nom |
| Livrables | Ce que le client reçoit (voir plus bas) |
| Prix et date du jalon | Fixes, selon le résultat |
Si un fournisseur ne peut pas produire cette page pour un travail circonscrit, la vitesse qu’il promet ne repose sur rien.
Que devriez-vous recevoir à la livraison d’un jalon bâti par des agents?
Le code, plus la preuve qu’il est correct et ce qu’il faut pour l’exploiter. La vitesse des agents ne sert à rien si la passation se résume à un lien vers un dépôt et un au revoir. Un ensemble complet comprend :
- Le code source dans votre dépôt, selon vos conventions, avec son historique.
- Des tests associés aux critères d’acceptation, pour que votre équipe voie quel test prouve quelle exigence.
- Le registre de décision d’architecture et les spécifications d’interface, s’il y a lieu.
- Un registre de revue : chaque point, qui l’a fait, ce qui a changé en conséquence.
- Le matériel d’exploitation : étapes de déploiement, configuration, alertes, guide d’exploitation et plan de retour arrière.
- Une courte présentation avec l’ingénieur qui en sera responsable chez vous.
Le registre de revue est la pièce qu’on saute le plus souvent, et celle qui compte le plus plus tard. C’est votre piste d’audit et votre réponse à « pourquoi l’a-t-on bâti comme ça? »
Quand la fonctionnalité elle-même utilise l’IA, une couche de gouvernance distincte s’ajoute : tests de biais, explicabilité, journaux d’audit. On en parle dans la gouvernance de l’IA pour les équipes produit.
À quoi ça ressemble sur un vrai item du backlog?
Voici un item qui passe de « un jour » à un jalon daté. L’exemple est illustratif. Il montre la structure, pas un mandat client précis.
L’item. Les plus gros clients d’une entreprise SaaS B2B demandent depuis plus d’un an des exports d’utilisation et des alertes de seuil. L’équipe produit est d’accord que c’est important. L’item a glissé de quatre planifications trimestrielles parce que l’équipe principale est prise par la feuille de route de la plateforme.
Le plan de production, en résumé.
- Résultat : les administrateurs peuvent exporter 12 mois d’utilisation en CSV et enregistrer un webhook qui se déclenche quand l’utilisation mensuelle dépasse un seuil configurable.
- Critères d’acceptation : huit items, dont : l’export se termine en moins de 30 secondes pour le plus gros locataire; le webhook est signé avec un secret partagé et relancé avec délai progressif; l’isolation entre locataires est vérifiée par un test; la fonctionnalité est derrière un drapeau.
- Notes d’architecture : lecture des agrégats d’utilisation existants par un nouveau point de terminaison en lecture seule; webhooks envoyés par un petit répartiteur basé sur une file d’attente; aucune écriture dans les tables de facturation principales.
- Travail des agents : point de terminaison d’export, répartiteur, composants d’interface d’administration, tests unitaires et d’intégration, ébauche de documentation d’API.
- Travail humain : décision d’architecture, revue de sécurité de la signature des webhooks et de l’isolation des locataires, revue de la pertinence des tests, démo d’acceptation avec le responsable produit du client, séance de passation.
- Responsable : un ingénieur principal, nommé dans le plan.
- Livraison : jalon fixe, prix basé sur le résultat, livré derrière un drapeau de fonctionnalité dans le dépôt du client.
Ce qui a changé pour le CTO. L’item a obtenu une date sans retirer personne de la feuille de route. L’équipe du CTO a mis du temps à deux endroits : approuver la décision d’architecture et assister à la démo d’acceptation. Tout le reste est arrivé avec une piste de revue.
À plus grande échelle. Une entreprise SaaS du voyage de taille moyenne prévoyait deux ans et 16 développeurs pour un produit multiagent. Une équipe Chrono de huit personnes, où des ingénieurs seniors dirigeaient des groupes d’agents et répondaient chacun de ce que leurs agents produisaient, l’a rendu prêt pour la production en neuf mois : 72 mois-équipe d’effort contre une prévision de 384 mois-développeur. Rien n’était livré sans passer la vérification de cet ingénieur, sur la qualité et sur le résultat demandé par le client. L’histoire complète est dans comment un SaaS a livré 15 mois plus tôt.
Les points de revue tiennent aussi sur de petits projets. Pour un agent IA pour créateurs mis en ligne en moins de trois semaines, rien n’était fusionné sans une suite verte de 398 tests automatisés et un déploiement de prévisualisation propre à chaque demande de fusion.
Que demander à un fournisseur qui livre avec des agents IA?
Quatre questions. Elles distinguent une livraison dont quelqu’un répond d’une simple génération rapide de code, et elles valent autant pour un fournisseur que pour une équipe plateforme interne ou votre propre processus.
- Quels sont les critères d’acceptation, par écrit, avant le début du travail? Une réponse vague ici annonce des reprises plus tard.
- Où les ingénieurs principaux font-ils la revue, et que vérifient-ils exactement? « Tout est révisé » veut souvent dire que rien de précis ne l’est.
- Qui est la seule personne responsable de ce jalon? Si la réponse est une équipe ou un processus, continuez de demander.
- Que contiennent les livrables? Le code seul ne suffit pas. Demandez les tests associés aux critères, le registre de décision et le registre de revue.
Les agents devraient-ils bâtir pour vous ou avec votre équipe?
Ça dépend de la proximité du travail avec votre plateforme principale. Les deux modèles suivent le même principe : les agents tapent davantage, les personnes répondent des décisions et du résultat.
On le bâtit pour vous. Vous décrivez ce dont vous avez besoin. On le découpe en jalon encadré avec un prix ferme. Des agents IA font le développement, supervisés par des ingénieurs principaux qui répondent de l’architecture, des revues et du résultat. Ça convient au travail circonscrit que votre équipe n’arrive pas à faire : un item du backlog, un outil interne, une nouvelle gamme de produits à tester sans détourner vos ingénieurs. Voyez comment on bâtit des produits.
On le bâtit avec vous. Des ingénieurs IA d’expérience participent à vos mêlées et travaillent dans votre code, pour que votre équipe développe la compétence à leurs côtés. Ça convient au travail étroitement lié à votre plateforme principale. On décrit ce modèle dans à quoi ressemblent les équipes IA intégrées.
Vous intégrez des agents dans votre propre produit plutôt que dans votre processus de livraison? Les enjeux de production sont différents. Voyez l’architecture des agents IA en production.
Questions fréquentes
Qui est responsable du code écrit par un agent de code IA?
Un ingénieur principal nommé, pas l’agent ni « l’équipe ». Cette personne approuve l’architecture, s’assure que chaque point de revue a lieu et répond du jalon en production.
Les agents de code IA éliminent-ils le besoin de revue de code?
Non, ils changent l’endroit où elle se fait. Réviser tout ligne par ligne ne tient pas à grande échelle, alors la revue se concentre sur des points ciblés : l’architecture avant le développement, la sécurité et la pertinence des tests avant la fusion, l’acceptation avant la mise en production, l’exploitabilité avant la passation.
Pourquoi les critères d’acceptation comptent-ils davantage avec des agents IA?
Les agents bâtissent exactement ce que dit la spécification et écrivent des tests qui décrivent ce qu’ils ont bâti. Des critères écrits donnent à l’agent et au réviseur une référence à vérifier, et des critères vagues sont la plus grande source de reprises.
Quel item du backlog confieriez-vous à des agents demain?
Choisissez celui qui glisse sans cesse. Pas besoin de réorganiser votre service d’ingénierie pour tester ce modèle.
Envoyez-le-nous. On le transforme en plan de production avec la portée, les critères d’acceptation, ce que font les agents, où les ingénieurs principaux révisent et qui répond du résultat. Vous verrez si le modèle vous convient avant de vous engager. Planifiez un jalon avec nos ingénieurs.