AI-DLC, épisode 1 : quand le besoin arrive à l'oral, l'IA accélère le désalignement

SECTION 1

Une phrase confiée à un agent

Un responsable d'exploitation résume son besoin en une phrase : « Il nous faudrait un portail où tout le monde suit les interventions. » L'équipe ouvre un agent de code, colle la phrase, et l'agent se met immédiatement au travail.

En une heure à peine, il produit un portail qui fonctionne. Il a aussi pris, de son propre chef, une série d'arbitrages que personne ne lui a demandés : tous les utilisateurs voient toutes les interventions ; les urgences sont triées par simple ordre d'arrivée ; rien n'est historisé ; l'application exige une connexion permanente ; la technologie retenue n'est pas celle de l'équipe ; et les tests sont remis à plus tard.

Le code n'est pas mauvais. Le problème est ailleurs : personne n'a demandé à l'agent de poser ses questions avant d'écrire. L'équipe gagne une heure, puis passe plusieurs jours à détricoter des choix d'architecture et de métier tranchés à sa place.

Ce scénario est imaginé, et volontairement simplifié. C'est pourtant le point de départ de la saison 1 de notre série : une demande orale, brute, et la méthode qui empêche l'agent de décider à la place du métier.

SECTION 2

Le problème : un agent qui ne pose pas de questions

Le cadrage du besoin n'est pas une difficulté née avec l'IA. En 2014 déjà, une étude du Project Management Institute établissait que, lorsqu'un projet n'atteint pas ses objectifs, une gestion inexacte des exigences en est la cause principale près d'une fois sur deux (47 %).

L'IA change la vitesse à laquelle ce défaut produit ses effets. Un besoin mal compris par une équipe se révélait au fil des semaines ; un agent, lui, le transforme en code en quelques heures. Avec l'IA, un besoin mal cadré ne ralentit plus seulement le projet : il accélère le désalignement, et l'écart avec le besoin réel se découvre plus tard, en revue ou en production.

Les travaux de DORA (Google Cloud), publiés en septembre 2025, vont dans le même sens. L'attention portée à l'utilisateur final amplifie l'effet positif de l'IA sur la performance des équipes ; en son absence, l'adoption de l'IA peut au contraire la dégrader. Les équipes risquent alors, selon DORA, d'avancer vite dans la mauvaise direction.

La plupart des équipes encadrent déjà leur agent par un fichier d'instructions : choix du langage, conventions de nommage, obligation d'écrire des tests. Ce sont des préférences de style. Elles ne disent pas à l'agent quand il a le droit d'écrire du code, quelles questions poser d'abord, ni quels documents faire valider avant de commencer.

SECTION 3

L'AI-DLC en bref

L'AI-DLC (AI-Driven Development Life Cycle) est une méthode de développement publiée par AWS en juillet 2025. Elle repose sur un principe : l'IA rédige les plans, pose les questions et exécute ; les humains arbitrent et prennent les décisions critiques, parce qu'eux seuls connaissent le contexte métier. Ce qu'elle change par rapport au cycle classique, des bolts à la place des sprints et trois phases, Inception, Construction et Operations, est détaillé dans notre épisode 0. Cet épisode s'attache à ce que la méthode impose concrètement à l'agent.

Ce qui change par rapport à un agent laissé à lui-même

• L'ordre : pas de code avant que les exigences soient analysées et validées.
• Les questions : l'agent les écrit dans un fichier, avec des choix de réponse, au lieu de supposer.
• Les documents : chaque étape produit un document dans le dépôt du projet, sur lequel s'appuie l'étape suivante.
• Les validations : l'agent s'arrête à la fin de chaque étape et attend un accord humain explicite avant de poursuivre.
• La trace : chaque décision est horodatée dans un journal d'audit, conservé avec le code.

Un outillage qui impose le déroulé

L'outillage officiel, publié en source ouverte par AWS et arrivé en version 2.11.1 en octobre 2026, ajoute deux phases en amont des trois de la méthode : une initialisation automatique, qui prépare le dossier de travail et détecte si le projet part de zéro ou reprend du code existant, et une phase d'idéation, qui formalise l'intention avant d'en tirer des exigences. Au total, 33 étapes, que onze plans prédéfinis combinent selon le type de travail : de la correction d'une anomalie en 5 étapes au projet en contexte réglementé en 29.

SECTION 4

Étude de cas : un projet dans l'énergie

Notre étude de cas* se déroule dans l'énergie, chez un acteur qui intervient chaque jour sur le réseau électrique : raccordements, entretien, dépannages d'urgence. C'est un secteur sous pression. En France, le principal gestionnaire du réseau de distribution d'électricité prévoit 5,5 milliards d'euros d'investissement en 2027 (en euros de 2021), puis plus de 5 milliards par an jusqu'en 2032, contre 4,4 milliards en 2022, surtout pour raccorder les énergies renouvelables et les bornes de recharge.

Derrière ces montants, il y a des raccordements à planifier, des pannes à réparer après une tempête ou une crue, et des techniciens habilités à envoyer au bon endroit, au bon moment. Chaque intervention doit aussi pouvoir être justifiée après coup : qui l'a décidée, qui l'a réalisée, dans quel ordre, et pourquoi. Dans un secteur essentiel, les exigences de traçabilité et de cybersécurité vont dans le sens d'un renforcement, avec la transposition de la directive NIS2, adoptée au Sénat et toujours en attente d'examen à l'Assemblée nationale à la date de cet article.

Le projet de la saison 1

La saison 1 suit la construction, à partir de zéro, d'un portail de suivi d'interventions pour cet acteur. Le travail est mené pour de vrai, étape par étape, et mesuré.

La demande, telle qu'on nous la confie

Le projet commence par quelques phrases du responsable d'exploitation, sans cahier des charges ni maquette :

Remplacez les interventions par des livraisons, des dossiers ou des sinistres, et les techniciens par des chauffeurs, des conseillers ou des experts : la demande reste la même. Des outils dispersés, des équipes qui manquent d'information, des clients qui relancent, et le souhait d'une vue commune.

SECTION 5

Les questions cachées dans la demande

Pour un responsable d'exploitation, tout est dit. Pour un agent, presque rien n'est encore défini. Prenons les mots de la demande un par un : chacun cache au moins une question à laquelle l'agent devra obtenir une réponse avant d'écrire la moindre ligne de code.

Une équipe expérimentée devinerait une partie des réponses. Un agent, lui, choisira une interprétation et la réalisera vite et proprement, sans prévenir.

Quatre familles de questions, pour tout projet

Ces questions ne sont pas propres au cas. Nous recommandons de passer toute demande au crible de quatre familles avant de la confier à un agent :

1. Qui : qui utilise l'outil, avec quels droits, qui voit quoi, et qui accède aux données sensibles ?

2. Quoi d'abord : quelle règle décide de ce qui passe en premier, et qui la fixe ?

3. Quelle trace : que faut-il conserver, combien de temps, pour qui, et qu'est-ce qui fera preuve en cas d'audit ou de litige ?

4. Dans quelles conditions : que doit faire l'outil quand les conditions se dégradent, sans connexion ou quand deux personnes modifient la même donnée ?

Une question sans réponse n'est pas un blocage. C'est une décision qui revient au métier, avant que l'agent ne la prenne à sa place.

SECTION 6

Notre approche : rendre le besoin vérifiable

Notre conviction tient en une phrase : avec l'IA, la valeur d'un projet se joue avant le code. Le travail ne consiste pas à écrire une meilleure invite pour l'agent, mais à transformer un besoin exprimé à l'oral en un besoin vérifiable, que l'agent peut réaliser et que l'équipe peut contrôler.

Faire monter le cadrage, un niveau à la fois

Notre référentiel de maturité décrit ce chemin en cinq niveaux pour l'étape « Cadrage et besoin ». Chacun n'ajoute que son incrément et suppose le précédent acquis :

1. Absent : le besoin est exprimé à l'oral, sans gabarit. C'est le point de départ de notre projet.

2. Initié : chaque demande prend la même forme, grâce à des gabarits communs d'Epic, de Feature et de Story.

3. Structuré : un contrôle « Ready to Dev » vérifie la complétude d'une demande avant qu'elle n'entre en développement.

4. Industrialisé : le temps passé en amont est mesuré, et chaque demande renvoyée au métier l'est pour une raison tracée.

5. Piloté : l'agent repère lui-même une demande incomplète et la renvoie au métier avec ses questions ; la décision reste humaine.

Nous recommandons de ne pas sauter de niveau. Un agent capable de cadrer seul n'apporte rien si les demandes n'ont pas de forme commune ; il ne fait qu'accélérer le désordre.

Trois principes que nous recommandons

1. L'intention reste la référence : la demande de départ est conservée avec le code, et chaque exigence, chaque test et chaque changement doit pouvoir s'y rattacher.

2. L'IA propose, l'humain décide : l'agent rédige le plan et pose les questions ; le métier et l'équipe tranchent. Une question sans réponse reste ouverte, elle n'est pas comblée par une supposition de l'agent.

3. Une exigence, un critère vérifiable : une exigence sans critère d'acceptation ne passe pas le contrôle « Ready to Dev ». Ce critère sert ensuite à dériver les tests du comportement attendu, et non du code produit.

Ces principes supposent un métier disponible. Si le responsable d'exploitation ne peut répondre aux questions de l'agent qu'une fois tous les quinze jours, la boucle courte de l'AI-DLC redevient un cycle de deux semaines.

La séance d'élaboration collective

Le métier, l'équipe et l'agent se retrouvent devant le même écran. L'agent lit l'intention, propose un premier plan d'exigences et pose ses questions. L'équipe répond, corrige et tranche. L'agent ne travaille donc pas seul : ses questions sont posées devant le métier et l'équipe, et aucune ligne de code n'est écrite avant que les réponses soient tranchées. AWS appelle cette séance Mob Elaboration : toute l'équipe y valide les questions et les propositions de l'IA.

SECTION 7

Concrètement : l'AI-DLC dans un projet

Une méthode ne vaut que par la façon dont elle s'installe dans le quotidien d'une équipe. Voici, pas à pas, comment nous l'avons mise en place le 28 octobre 2026 pour ce projet, avec Claude Code comme agent de développement. Les captures sont celles de notre poste ; les surlignages bleus sont les nôtres.

1. Installer Claude Code

Claude Code s'installe en une commande, par Homebrew sur Mac ou par le script d'installation officiel d'Anthropic. L'outillage de l'AI-DLC s'appuie en plus sur Bun, un environnement d'exécution JavaScript, en version 1.3.8 ou plus récente.

brew install --cask claude-code

2. Récupérer l'AI-DLC sans lancer de script inconnu

La documentation propose une installation par un script téléchargé et exécuté aussitôt. Nous recommandons une autre voie, plus lente de quelques minutes : télécharger l'archive publiée sur le dépôt officiel, vérifier son empreinte, relire ce qu'elle ajoute, puis copier dans le projet le dossier prévu pour Claude Code.

shasum -a 256 aidlc-copy-runtime-2.11.1.tar.gz
tar -xzf aidlc-copy-runtime-2.11.1.tar.gz
cp -R runtime/claude/. ~/projets/cas-energie/

Cette relecture montre ce que l'outillage fait réellement. Il s'attache à 16 points d'accroche (hooks) de l'agent, et son fichier de réglages autorise d'avance une centaine de commandes de l'outil ainsi que la modification de tous les fichiers du projet. Rien de malveillant, mais un outil qui prend beaucoup de place, et qu'il faut connaître avant de l'adopter.

3. Préparer le projet

Le projet vit dans son propre dépôt git, sur une branche dédiée, avec uniquement des données créées pour l'occasion. Avant le premier lancement, nous ajoutons des réglages locaux, qui ne sont pas versionnés :

• Hors ligne : l'outil ne cherche pas seul ses mises à jour sur Internet et ne mesure pas son usage.
• Ses propres fichiers protégés : l'agent ne peut pas modifier les règles et les scripts de l'outillage.
• Pas de recherche web, pas de serveur externe : l'agent travaille avec ce que contient le dépôt.
• Les secrets hors de git : les fichiers .env sont exclus du versionnement dès le départ.

Au premier lancement de Claude Code dans le dossier, l'outillage se met en place. La commande /hooks affiche les points d'accroche qu'il installe :

4. Vérifier l'installation

L'outillage fournit son propre diagnostic, que nous lançons avant toute demande avec la commande /aidlc --doctor :

Nous gardons Claude Code dans son mode manuel, où l'agent demande avant d'agir. Les commandes et les écritures que l'outillage autorise d'avance passent toutefois sans question : c'est le prix de son automatisation, et une raison de plus de relire ses réglages.

5. Démarrer avec /aidlc, puis versionner

Le travail commence par une seule commande, suivie de la demande recopiée mot pour mot, abrégée ici :

/aidlc Portail de suivi d'interventions. Demande du responsable d'exploitation : « Aujourd'hui, on suit nos interventions […] »

L'agent prépare son dossier de travail, détecte que le projet part de zéro, puis propose un plan avant d'agir :

Ce plan s'arrêtait avant l'exploitation, alors que notre saison va jusqu'à la production. Parmi les onze plans disponibles, nous avons retenu le plan « enterprise » : 29 étapes, prévu pour un contexte réglementé, avec une traçabilité complète. Il impose qu'un humain valide chaque plan et chaque résumé.

Première étape, le cadrage de l'intention. L'agent n'écrit pas de code : il écrit ses questions dans un fichier, puis demande comment l'équipe veut y répondre.

Ses douze questions retrouvent les mots de la demande : ce qui fait une urgence, pourquoi garder une trace de tout, les conditions sans réseau, les clients concernés. S'y ajoutent les indicateurs de réussite, ce que la première version ne fera pas, et qui décide du périmètre. Nous n'y avons pas encore répondu : ces réponses appartiennent à la séance d'élaboration.

Tout ce que l'agent produit, l'état d'avancement, les questions et le journal d'audit, est un fichier du dépôt. Nous l'enregistrons dans git, comme le code : six mois plus tard, on saura encore pourquoi une décision a été prise, et par qui.

Les règles de l'entreprise, appliquées à chaque projet

L'outillage permet d'ajouter les standards propres à une équipe : conventions, exigences de sécurité, règles de conformité. Nous recommandons d'y inscrire les exigences qui s'imposent à tous les projets d'un secteur réglementé, pour que l'agent les applique sans qu'on ait à les rappeler.

SECTION 8

Nos recommandations pour démarrer

Ce que nous retenons de la documentation officielle, à appliquer dès le premier projet :

• Répondre précisément : une réponse vague produit une exigence vague. « Un compte par technicien, désactivé à son départ, et un accès en lecture seule pour les clients » vaut mieux que « gestion des droits ».
• Ne pas sauter d'étape : les user stories deviennent les critères d'acceptation, puis les tests. Les sauter crée un manque qui se paie plus tard.
• Versionner les documents produits : ce ne sont pas des brouillons, mais la documentation vivante du projet.
• Écrire ses règles une fois : les exigences de sécurité et de conformité de l'entreprise doivent devenir des règles que l'agent applique à chaque projet.
• Garder le métier dans la boucle : sans réponse rapide du métier, la méthode perd son principal avantage.

SECTION 9

Conclusion

Une demande de quelques phrases. Quatre mots qui cachent chacun une décision. Et un agent qui, laissé seul, les aurait toutes prises sans demander l'avis de personne.

L'AI-DLC ne rend pas l'agent plus prudent. Il l'oblige à s'arrêter, à poser ses questions et à attendre une décision humaine, puis il garde la trace de chacune dans le dépôt, avec le code. C'est cette discipline qui fait la différence entre un agent qui accélère le projet et un agent qui accélère le désalignement.

SECTION 10

Dans le prochain épisode

La demande est posée, l'outillage est en place, et l'agent attend nos réponses à ses douze questions de cadrage. Dans l'épisode 2, nous y répondons en séance, avec le métier, et nous publions la séance telle qu'elle se déroule, jusqu'aux premières exigences.

Une question nous intéresse plus que toutes les autres : sur ces douze questions, et sur celles qui suivront avant la première ligne de code, combien l'équipe n'avait-elle pas anticipées ?

Nous y publierons :

• Les questions et nos réponses : les questions de l'agent telles quelles, et les décisions prises en séance.
• Ce qui reste ouvert : les décisions reportées faute de réponse du métier.
• Ce qui en sort : les exigences et les user stories validées, captures d'écran à l'appui.
• Les premières mesures : le temps entre la demande orale et un plan d'exigences validé, et le nombre d'exigences dotées d'un critère vérifiable.

Notre approche de l'AI-DLC est détaillée sur notre page dédiée.

À lire aussi Y a-t-il encore une place pour l'agilité avec l'AI-DLC ?

* Note méthodologique : l'entreprise, le projet et les données sont créés pour l'occasion, à partir des enjeux réels du secteur de l'énergie, et ne ressemblent à aucune entreprise existante. L'exécution, les mesures et les échecs sont réels, y compris quand ils nous sont défavorables. Le projet reste plus simple qu'un projet client, ce que nous rappellerons à chaque épisode.

FAQ

Questions fréquentes

SOURCES