AI SDLC : ce que les agents IA changent au cycle de développement des produits digitaux

Avec les agents IA, le cycle de développement logiciel change de forme : les agents écrivent une bonne partie du code, les équipes fixent l’intention et valident chaque étape. Ce nouveau cycle, l’AI SDLC, bouscule Scrum comme l’organisation des équipes produit et tech, et il oblige à regarder ce qui se passe avant et après le code. Renaud Chevalier, notre CTO, en détaille les implications, du choix de ce qu’on construit jusqu’à la mise en production.

• Qu'est-ce que l'AI SDLC ?
• Quelle différence avec le SDLC classique ?
• AI SDLC, agentic SDLC, développement agentique : s'y retrouver dans le vocabulaire
• Ce qui reste une décision humaine
• L'AI SDLC dans le PDLC : pourquoi regarder au-delà du code
• Anthropic, AWS, BMAD : faut-il suivre un modèle ?
• Par où commencer ?

Qu'est-ce que l'AI SDLC ?

L'AI SDLC (pour AI Software Development Life Cycle) est le cycle de développement logiciel réorganisé autour des agents IA : les agents produisent le code et une bonne partie des artefacts, les humains fixent l'intention et valident chaque étape. C'est ce cycle qui organise le développement agentique, c'est-à-dire le fait de développer avec des agents, à l'échelle d'une équipe puis de toute une organisation.

Pour Renaud Chevalier, notre CTO, le changement touche d'abord la façon de travailler ensemble : “On est sur un nouveau mode de collaboration pour faire du logiciel avec des agents intégrés, qui disrupte complètement les réflexes et les cadres existants. Le plus symbolique, c'est Scrum.” Les rôles et les artefacts changent, et les cérémonies perdent leur raison d'être quand un cycle ne dure plus que quelques jours. D'où l'expression qu'il emploie volontiers : “On est en train de poser un nouveau Scrum, avec un nouveau cadre, de nouveaux gestes, de nouveaux rôles et de nouveaux artefacts.”

Ce nouveau Scrum ressemble pourtant beaucoup à l'ancien, tel qu'il est écrit. Le Scrum Guide décrit une petite équipe pluridisciplinaire, qui réunit toutes les compétences nécessaires pour créer de la valeur à chaque sprint et décide elle-même de qui fait quoi. Avec des agents, une équipe de trois ou quatre personnes peut couvrir seule tout le chemin jusqu'à la production. C'est en ce sens que Renaud voit dans l'IA le moyen de faire enfin du Scrum : “Si on relit le Scrum Guide, c'est exactement ce que l'IA nous permet de faire.”

Quelle différence avec le SDLC classique ?

Le SDLC classique s'organise autour d'une ressource rare, le temps des développeurs. Dans l'AI SDLC, écrire du code ne coûte presque plus rien : le goulot d'étranglement se déplace vers l'intention de départ, la revue de ce que produisent les agents et le chemin jusqu'à la production.

Toutes les entreprises qui utilisent des agents n'en sont pas là, et Renaud distingue deux phases. Si votre entreprise a commencé par équiper ses développeurs d'agents de code, elle est sans doute dans la première, celle que beaucoup vivent depuis 2025 : on intègre l'IA dans le SDLC existant. Le flux reste le même, de la stratégie à la production, et on ajoute des agents aux étapes qui ralentissent. Le temps de cycle baisse, mais la théorie des contraintes s'applique : lever un bouchon en fait apparaître un autre plus loin, qu'on traite à son tour avec un nouvel agent, et les agents finissent par s'empiler comme autant de rustines. Pour notre CTO, le schéma est connu : “C'est ce qu'on a fait pendant quinze ans avec l'agilité : de l'optimisation locale. Sauf que là, on le fait avec des agents.”

Dans la seconde phase, on part d'une petite équipe, que Renaud compose ainsi : “Je prendrais un profil Produit, un Product Designer, un Tech Lead et sans doute un QA, et je les mettrais côte à côte au quotidien pour construire.” Ensemble, ils portent un produit de bout en bout. Donnez-leur une intention claire et un environnement où les agents sont outillés et encadrés, ce que les équipes techniques appellent le harness engineering, et selon lui, “une toute petite équipe resserrée prend une intention, un objectif business, et elle est capable d'aller en production avec un très bon niveau de qualité, dans un temps record”. C'est aussi le pari de l'AI-DLC d'AWS, construit autour de micro-squads. Et quand le produit est trop gros pour une seule équipe, Renaud continue de s'appuyer sur les Team Topologies pour le découper entre plusieurs équipes : le modèle de Matthew Skelton et Manuel Pais organise des équipes alignées chacune sur un flux de valeur, épaulées par des équipes d'enablement, des équipes de sous-système complexe et des équipes plateforme.

AI SDLC, agentic SDLC, développement agentique : s'y retrouver dans le vocabulaire

Le sujet étant jeune, chaque acteur arrive avec ses propres mots.

Mieux vaut ne pas choisir son camp sur la base du vocabulaire, prévient Renaud, au risque “d'adopter le vocabulaire d'une solution qu'on n'utilisera peut-être plus dans six mois”. Ceux qui ont vécu les querelles autour des frameworks agiles à l'échelle connaissent la chanson. En 2013, Ken Schwaber, cocréateur de Scrum, avait intitulé son billet sur SAFe “unSAFe at any speed”. Dean Leffingwell, à l'origine de SAFe, lui avait répondu pour défendre son framework. Pour notre CTO, il ne faut surtout pas rejouer ce match avec l'IA : “Il ne faut pas tomber dans les faux débats. On l'a vécu avec l'agilité : des guerres de tranchées sur les frameworks et le vocabulaire, complètement stériles.”

Changer de mots peut quand même aider la conduite du changement : pour que les gens changent leur façon de travailler, il faut parfois appeler les choses autrement, et c'est tout l'intérêt de son “nouveau Scrum”. L'essentiel, pour lui, c'est qu'on garde la main sur la façon dont on organise sa propre chaîne de valeur, quel que soit le vocabulaire de l'éditeur.

Ce qui reste une décision humaine

Dans l'AI SDLC tel qu'Anthropic et AWS le décrivent, l'humain valide à chaque passage de phase : l'agent produit, une personne relit et décide de passer à l'étape suivante. Ces playbooks précisent, geste par geste, ce que fait l'humain et ce que fait l'agent. Ce partage n'est pas encore adopté partout, mais pour Renaud, “les premières briques qu'on a sont assez pertinentes, et l'humain reste aux commandes”.

Les métiers changent en conséquence. Le Product Designer fait designer un agent, puis relit ce qu'il a produit ; le Product Owner et le Développeur suivent le même chemin. “Nous, les humains, on devient des validateurs de ce que génère l'IA. On est des reviewers”, résume Renaud Chevalier. Et ça vaut pour tout ce que l'IA produit, le code comme les specs ou les maquettes. Encore faut-il avoir l'expertise pour challenger le résultat et ne pas se laisser embarquer dans la mauvaise direction. Côté code, ce qui part en production sans que personne l'ait vraiment compris finit par alimenter la dette technique créée par l'IA.

Sur un produit qui existe déjà, l'exigence monte encore. Travailler avec des agents ne demande pas le même effort selon qu'on part de zéro ou de l'existant : pour vérifier qu'un agent qui refactorise respecte ce qui existait avant, il faut connaître le produit et sa stack. Le cas le plus délicat reste le vieux code, que Renaud associe d'ailleurs spontanément au brownfield. Avant de moderniser du code legacy avec des agents, il faut savoir ce que ce code fait vraiment, et ce n'est pas toujours écrit quelque part.

Bien relire suppose aussi de savoir comment les agents fonctionnent et où sont leurs limites. “Il faut avoir conscience qu'ils peuvent mentir et qu'ils sont très assertifs”, prévient notre CTO, qui conseille de ne jamais les croire sur parole. Encadrer des agents devient une compétence de management à part entière : savoir ce qu'on peut leur confier, puis vérifier ce qu'ils rendent. Le rôle d'Engineering Manager en sort transformé, puisque manager une équipe tech qui travaille avec des agents, c'est aussi apprendre à manager les agents eux-mêmes.

Cette attention se dose selon l'enjeu. Les agents permettent de mener plusieurs chantiers en parallèle, au prix d'une charge mentale plus forte. Sur un sujet secondaire, on accorde plus facilement sa confiance à ce que propose l'agent ; sur un sujet critique, on prend le temps d'une vraie revue. En pratique, c'est la criticité du sujet qui fixe jusqu'où l'agent avance seul.

L'AI SDLC dans le PDLC : pourquoi regarder au-delà du code

Le PDLC (Product Development Life Cycle) couvre tout le cycle du produit, de la stratégie et de la discovery jusqu'à ce qu'on apprend après la livraison. Le SDLC n'en est qu'un segment, celui qui démarre une fois qu'on sait à peu près quoi construire.

Le PDLC, le cycle du produit entier

Les agents accélèrent le développement, mais ils ne disent pas quoi développer : le facteur limitant devient le choix de ce qu'on construit. Pour Renaud, “le SDLC commence à partir du moment où on sait à peu près ce qu'on veut faire”. La stratégie et la discovery, qui précèdent, comme l'apprentissage après livraison, qui suit, restent hors de son périmètre. Or, insiste notre CTO, “produire vite des choses qui ne sont utiles à personne, ça ne sert à rien”. Une organisation qui automatise tout son SDLC sans toucher au reste devient une software factory : elle livre des fonctionnalités en continu, sans que personne vérifie leur valeur, au risque de noyer les utilisateurs sous les nouveautés.

Ce que les playbooks laissent de côté

Renaud a vérifié jusqu'où vont les modèles existants en plaçant les frameworks et les plugins de skills (Anthropic, AWS, BMAD, Spec Kit, OpenSpec) sur une chaîne de valeur Produit complète. La plupart laissent des trous aux deux bouts : en amont, sur la stratégie et le choix de ce qu'on construit, et en aval, sur ce qu'on apprend de ce qu'on a livré. Le playbook de l'AI-SDLC d'Anthropic en donne un bon exemple : il démarre avec un fichier d'intention sans dire comment on décide de ce qu'il contient, et son étape de maintenance ne traite ni du coût ni du produit.

En aval, les équipes mesurent bien sûr leurs livraisons, avec les DORA metrics par exemple. Ces indicateurs suivent la vitesse et la stabilité des mises en production. La valeur de ce qu'on livre, elle, se lit dans l'usage réel des fonctionnalités et dans le retour sur investissement de ce qu'on a construit.

En amont : brancher le cycle sur la data

Comment la partie Produit peut-elle tenir le rythme ? “Pour moi, le sujet, c'est la data : aller identifier la valeur le plus tôt possible”, répond Renaud. L'idée, c'est de croiser les données de marché (études, recherche utilisateur) avec celles de l'entreprise. Branchés sur ces sources par des connecteurs, des agents peuvent les analyser en continu et faire remonter ce qui mérite d'être construit : le cycle AI SDLC démarre alors sur une intention étayée, dont on vérifie la valeur une fois livrée.

Avec des clients du luxe, nos équipes travaillent sur ce principe : un agent croise en temps réel des données sectorielles pour enrichir la connaissance client et permettre de se positionner plus vite que la concurrence. Sans ce branchement, l'identification de la valeur reste manuelle, avec toute la latence que ça suppose, et l'équipe la plus rapide du monde se retrouve à attendre qu'on lui dise quoi construire. “On a des Ferrari qui attendent qu'on leur mette de l'essence”, résume Renaud.

Autour du cycle : plateforme, gouvernance et coûts

Pour que des agents produisent en sécurité, l'organisation doit aussi leur fournir une plateforme : l'ensemble des outils et services internes qui sécurisent le code produit, encadrent l'usage de la data, surveillent ce qui tourne et vérifient la conformité aux normes du secteur.

C'est aussi dans cette plateforme que la gouvernance doit se loger. Les comités qui approuvent à intervalles réguliers et les validations qui ne sont écrites nulle part ralentissent un cycle qui se compte désormais en jours, et pour Renaud, c'est sur ce point que beaucoup de transformations vont buter : “Pour fonctionner à ce rythme-là, il faut que la gouvernance soit encodée dans la plateforme. Si des équipes sont capables de produire en un ou deux jours des produits très pointus, mais qu'il faut attendre trois semaines pour avoir un environnement de test et trois mois pour une mise en production, ça ne sert strictement à rien.”

Les agents ont enfin un coût. Chaque itération consomme des tokens, et cette dépense se pilote comme celle du cloud avant elle, avec les méthodes du FinOps.

Anthropic, AWS, BMAD : faut-il suivre un modèle ?

Aucun modèle d'AI SDLC ne s'impose aujourd'hui : “Il n'y a pas de choix clair”, estime notre CTO. Les entreprises déjà clientes d'AWS se tournent assez naturellement vers l'AI-DLC, d'autant qu'elles disposent déjà de ses outils, comme Bedrock et Kiro.

À côté de ces modèles qui décrivent tout le cycle, des frameworks plus outillés proposent de structurer le travail des agents à partir de spécifications : Spec Kit, OpenSpec ou BMAD. Renaud les a testés. Il trouve les deux premiers trop légers pour structurer un vrai cycle. BMAD, à l'inverse, en fait trop : il multiplie les itérations, au point qu'on perd la maîtrise de ce qui se passe et que la consommation de tokens s'envole.

Le playbook d'Anthropic, lui, se contente de décrire les gestes du cycle, sans fournir de skills, et Renaud constate qu'il fonctionne très bien ainsi : les modèles les plus récents n'ont pas besoin de plugins pour faire correctement le travail. Il parle d'expérience, puisqu'il a lui-même passé un an à fabriquer des plugins de skills, pour un résultat qu'il juge peu concluant (nos propres skills maison se sentent un peu visés). Ce qui reste indispensable, selon lui, c'est la structure : “Il faut des gestes, une structure, parce qu'il faut de la rigueur et des validations humaines à certains moments. Sinon, c'est le chaos, surtout quand on passe à l'échelle.”

Reste à savoir jusqu'où pousser l'autonomie des agents. L'échelle de Dan Shapiro la découpe en niveaux, jusqu'à la dark factory, une usine logicielle qui tournerait sans intervention humaine. On n'en est sans doute pas encore là : aujourd'hui, l'écart entre ce qu'on spécifie, ce que l'agent décide seul en chemin et ce qu'on récupère à l'arrivée reste trop important pour qu'on retire l'humain de la boucle. Le sujet bouge vite, et certains contextes s'y prêteront plus tôt que d'autres. Pour l'instant, vu la maturité de la plupart des organisations, Renaud juge plus adaptés les modèles qui découpent le cycle en phases validées par un humain.

Par où commencer ?

Pour se lancer dans l'AI SDLC, deux chantiers passent avant les autres, selon Renaud : “Le vrai sujet pour démarrer, c'est la plateforme, et la formation des personnes qui vont travailler comme ça.” Sans plateforme, les équipes ne peuvent pas aller en production. Il leur faut aussi apprendre à travailler avec les agents, et c'est tout l'objet de la formation.

Inutile, en revanche, d'attendre une data parfaitement rangée, puisque les agents savent exploiter des données peu structurées : “Il n'y a pas besoin de passer des mois ou des années à restructurer la data pour qu'un agent puisse la consommer.” On en est à une phase de formalisation et d'apprentissage, pas encore de normalisation à grande échelle : autant démarrer avec ce qu'on a.

La formation, elle, ne ressemble pas à celles des transformations agiles, qui passaient beaucoup de temps sur l'état d'esprit et le vocabulaire. Elle se fait les mains dans le code : on apprend à rédiger une intention, à ouvrir une pull request, à relire ce que l'agent a produit, puis à fusionner et à passer à la spécification suivante. Anthropic parle de “plays” dans son playbook ; Renaud préfère le mot “gestes”, parce que c'est bien des gestes de travail qu'on transmet aux équipes.

Reste la dimension humaine, et c'est sans doute la plus délicate. “Contrairement aux autres vagues qu'on a connues, la peur est beaucoup plus importante”, constate Renaud Chevalier, et on comprend d'où elle vient. Un Product Owner qui a passé des années à tenir son backlog voit une IA connectée à la data en faire une bonne partie très vite. Côté développeurs, souvent attachés à la qualité de leur code comme des artisans, voir une IA produire du code en quantité, parfois de qualité médiocre, peut mal passer. Dans les deux cas, c'est une partie de ce qui faisait leur métier qui passe à la machine.

Renaud ne croit pas pour autant à un retour en arrière. Sa réponse passe par la pratique : mettre les gens devant le code et les accompagner pour démystifier l'outil. Les équipes voient alors assez vite le potentiel, et certains y trouvent même un second souffle, comme ces profils tech qui ne codaient plus et s'y remettent avec le plaisir de retrouver un pouvoir créatif qu'ils avaient laissé de côté.

Conclusion

L'AI SDLC concentre l'attention parce que c'est là que le travail des agents se voit le plus. Mais un cycle aussi rapide ne produit de la valeur que s'il est branché sur la data en amont et sur une plateforme qui le mène jusqu'en production. Pour Renaud, augmenter les équipes, c'est leur rendre du temps pour les décisions qui comptent, et ce temps se gagne sur tout le cycle du produit.