Organiser une équipe de développement à l’ère de l’IA - Part III

Organiser une équipe de développement à l’ère de l’IA - Part III

Comment organiser une équipe de développement à l’ère de l’IA ?

Résumé des parties précédentes

La deuxième partie de cette série était consacrée à la construction du patrimoine de connaissances à l’ère de l’IA générative. Nous y avons exploré les activités qui constituent désormais une part essentielle du travail des équipes de développement augmentées, en suivant le fil conducteur qui relie naturellement le Domain-Driven Design (DDD), le Behavior-Driven Development (BDD) et le Spec-Driven Development (SDD).

Loin d’être concurrentes, ces trois disciplines forment un continuum de transformation de la connaissance. Le DDD permet d’explorer et de structurer la connaissance métier ; le BDD en explicite les comportements attendus à travers des exemples concrets ; le SDD rassemble et organise ces connaissances au sein de spécifications vivantes, directement exploitables par les équipes comme par les agents d’intelligence artificielle.

Si vous avez manqué la partie II, l’article — relativement long — a été publié en deux volets :

• Partie II.1 : https://blog.octo.com/organiser-une-equipe-de-developpement-a-l'ere-de-l'ia-partie-ii
• Partie II.2 : https://blog.octo.com/organiser-une-equipe-de-developpement-a-l'ere-de-l'ia-part-ii.2

Cette progression fait de la connaissance métier un actif central du projet. À l’ère de l’IA générative et agentique, la spécification n’est plus seulement une documentation de référence destinée aux humains : elle devient un support de collaboration entre les experts métier, les équipes produit et de développement, et les agents d’intelligence artificielle. Elle contribue ainsi à préserver et à transmettre l’intention métier tout au long du processus qui conduit de l’opportunité au logiciel.

Mais construire ce patrimoine de connaissances ne suffit pas. Une question demeure : comment organiser l’ensemble du cycle de vie du logiciel lorsque l’intelligence artificielle prend en charge une part croissante des activités d’ingénierie ?

Comment articuler la découverte, la conception, la construction, la validation, le déploiement et l’apprentissage lorsque humains et agents collaborent tout au long du processus ?

C’est précisément l’objet de cette troisième partie, consacrée à une relecture du Software Development Life Cycle (SDLC) à l’ère de l’IA agentique.

SDLC - un cadre de gouvernance intemporel

L'ambition du Software Development Life Cycle (SDLC) est d'organiser l'ensemble du cycle de vie d'un logiciel, de la découverte du besoin jusqu'à son exploitation et son amélioration continue. Pourquoi, alors, lui accorder une telle importance aujourd'hui alors qu'il existe depuis plus de soixante ans ?

Unsplash - Shubham Dhage

La réponse tient à l'émergence du développement agentique. Les premiers retours d'expérience ont rapidement montré que l'IA ne remplace pas les pratiques d'ingénierie ; elle les rend plus nécessaires que jamais. Produire un logiciel de qualité dans un domaine complexe exige un cadre de gouvernance, un cycle de développement rigoureux et un accompagnement des équipes à tous les niveaux de l'organisation.

Comme toute technologie émergente, l’IA appliquée au développement logiciel a d’abord connu une période d’expérimentation relativement peu structurée. Le vibe coding, souvent pratiqué avec peu de contrôle et de garde-fous, a parfois conduit à la production rapide d’un code difficile à comprendre, à maintenir ou à faire évoluer — un phénomène parfois qualifié d’AI slop.

De nombreuses entreprises ont d'abord abordé l'IA agentique comme un simple changement d'outillage. Elles ont mis des agents à la disposition des développeurs sans faire évoluer leurs pratiques, leur organisation ni leur patrimoine de connaissances. Les résultats ont souvent été décevants : une consommation importante de ressources (tokens), des implémentations incohérentes, une qualité difficile à maîtriser et, dans certains cas, l'abandon pur et simple des initiatives en raison de leur coût.

Sans cadre explicite, les équipes se tournent naturellement vers des usages ponctuels fondés sur de simples prompts. La contextualisation reste limitée, les mêmes informations sont répétées d'un échange à l'autre, la consommation de tokens augmente et la qualité des résultats demeure aléatoire. À l'inverse, un SDLC propose des étapes claires permettant de quantifier les activités de chacune.

Les orgines du Software Development Life Cycle

Le Software Development Life Cycle (SDLC) est l'un des premiers cadres structurés du développement logiciel. Apparu dans les années 1960, il répondait au besoin d'apporter davantage de rigueur à la conduite des projets informatiques. Son principe est simple : organiser le développement d'un logiciel autour d'un ensemble d'activités cohérentes, depuis l'émergence d'une idée jusqu'à sa mise en production, son exploitation et son amélioration continue.

Souvent associé au modèle Waterfall, le SDLC est pourtant indépendant de toute méthode de développement. Il ne décrit pas un processus strictement séquentiel, mais les grandes activités qui jalonnent le cycle de vie d'un logiciel. Les méthodes agiles, le DevOps, le Continuous Delivery et, plus récemment, les approches de développement assisté par l'IA n'ont jamais remis en cause ce cadre. Elles en ont profondément renouvelé la mise en œuvre afin de favoriser des cycles plus courts, itératifs et incrémentaux.

Dans sa forme originelle, le Software Development Life Cycle (SDLC) décrit une chaîne complète de développement logiciel, structurée autour de six grandes étapes. Si ce découpage reste remarquablement pertinent, la terminologie employée reflète en revanche le contexte dans lequel il a été élaboré, au début des années 1960.

À cette époque, le développement logiciel reposait sur une organisation largement séquentielle. Les spécifications étaient généralement rédigées par un nombre restreint d'analystes, parfois une seule personne, avant d'être transmises aux équipes de développement. Le dialogue entre les experts métier et les développeurs demeurait limité, chacun intervenant principalement à son étape du processus. La mission des développeurs consistait avant tout à implémenter les fonctionnalités décrites dans les spécifications, tandis que leur conformité était vérifiée lors des phases de tests et de validation.

Cette organisation traduit une vision où la connaissance progresse d'une étape à la suivante selon un flux essentiellement descendant. Les intitulés des différentes phases reflètent naturellement cette manière de concevoir le développement logiciel. Avant de les comparer à celles d'un SDLC augmenté, il est donc important de les replacer dans leur contexte historique. On comprend alors que ces étapes répondaient avant tout aux contraintes techniques, organisationnelles et méthodologiques de leur époque.

Le cycle de développement logiciel découpé en six étapes fondamentales

1. Analyser — Analyser les besoins métier.
2. Concevoir — Concevoir l'architecture et la solution.
3. Développer — Développer les fonctionnalités.
4. Assurance qualité — Vérifier la conformité du logiciel par les tests.
5. Déployer — Déployer l'application en production.
6. Support et maintenance — Assurer le support, les corrections et la maintenance de l'application.

L’objectif du SDLC traditionnel ne consiste pas seulement à ordonner les activités du développement logiciel, mais à assurer leur continuité afin que chaque décision contribue à la création de valeur.

Cette continuité est essentielle. Une compréhension incomplète du besoin fragilise la conception, une architecture inadaptée complique le développement, des tests insuffisants augmentent les risques lors des mises en production, tandis qu'une maintenance essentiellement réactive alimente progressivement la dette technique. Les ruptures entre ces différentes activités ralentissent les équipes, accroissent les coûts et réduisent durablement la capacité de l'organisation à faire évoluer son système d'information.

La valeur d'un SDLC ne se mesure donc pas uniquement à la vitesse de développement. Elle repose sur un équilibre entre trois objectifs complémentaires :

• Livrer rapidement les fonctionnalités créatrices de valeur.
• Préserver durablement la qualité du logiciel et maîtriser les risques grâce à une gouvernance claire.
• Une meilleure traçabilité des décisions et un pilotage fiable des évolutions.

La question se pose alors naturellement

• Ce cadre reste-t-il pertinent à l'ère de l'intelligence artificielle ?

À mes yeux, le principe même du SDLC constitue une excellente base pour accompagner cette transformation. Il offre aux organisations un cadre de gouvernance stable et rassurant tout en laissant aux équipes la liberté de choisir les pratiques d'ingénierie les plus adaptées à leur contexte. Cette indépendance vis-à-vis des méthodes constitue d'ailleurs l'une de ses principales forces : le SDLC ne prescrit ni Scrum, ni DevOps, ni le Domain-Driven Design ; il fournit un cadre dans lequel ces approches peuvent s'articuler de manière cohérente.

Il répond toutefois davantage à la question du « quoi » que du « comment ». Il identifie les grandes activités qui structurent le cycle de vie d'un logiciel, sans préciser les pratiques permettant d'en garantir la qualité lorsque les agents prennent progressivement en charge une part croissante des activités d'exécution.

À l'ère de l'IA agentique, il ne suffit donc plus d'énumérer les étapes du SDLC ; il devient indispensable d'expliciter la manière dont elles sont mises en œuvre. C'est en analysant le fonctionnement du SDLC traditionnel que l'on peut identifier les adaptations nécessaires à un développement assisté par des agents. Ceux-ci accélèrent considérablement les activités d'exécution, mais la performance ne dépend plus principalement de la vitesse de production du code. Elle repose désormais sur la qualité du contexte qui leur est fourni, sur la structuration des connaissances et sur la capacité des équipes à orchestrer efficacement l'ensemble du cycle de vie.

La création de valeur se déplace ainsi progressivement de la production de code vers la compréhension du métier, la structuration des connaissances, la qualité des décisions et l'amélioration continue. Chaque cycle de livraison ne produit plus seulement du logiciel ; il enrichit également un patrimoine de connaissances partagé, réutilisable par les équipes comme par les agents d'intelligence artificielle. Le développement devient ainsi un processus de capitalisation continue des connaissances, où chaque évolution contribue autant à enrichir la compréhension du domaine qu'à faire progresser le produit.

Le SDLC retrouve ainsi toute son actualité. Plus qu'un simple cadre d'organisation du développement, il devient un véritable cadre de gouvernance de la connaissance. Sa vocation n'est plus seulement d'orchestrer la production du logiciel, mais également la découverte, la structuration, le partage et l'enrichissement continu des connaissances qui guideront les équipes et les agents tout au long du cycle de vie. Dans cette perspective, le logiciel n'est plus l'unique produit du développement : la connaissance devient elle aussi un livrable stratégique, continuellement enrichi au fil des cycles de livraison.

L'évolution du développement logiciel jusqu'à l'arrivée de l'IA

Unsplash - Planet Volumes

Au cours des trente dernières années, le génie logiciel s’est progressivement enrichi de nombreuses approches qui ont introduit de nouveaux niveaux d’abstraction tout en faisant évoluer les modes de collaboration entre les équipes. Les méthodes agiles ont repensé la gestion des projets, le DevOps et le Continuous Delivery ont profondément transformé les chaînes de développement et de livraison, tandis que le Domain-Driven Design (DDD), le Behavior-Driven Development (BDD), Team Topologies ou, plus récemment, le Spec-Driven Development (SDD) ont renouvelé les pratiques de conception, l’organisation des équipes et la manière de faire évoluer durablement les systèmes d’information.

Parmi ces évolutions, deux approches jouent un rôle particulièrement structurant lorsqu’il s’agit de penser l’organisation du développement : le DDD stratégique et Team Topologies. Loin de s’opposer, elles sont complémentaires. Le DDD stratégique aide à découper le système selon les frontières du métier, à identifier les sous-domaines et les Bounded Contexts. Team Topologies permet ensuite de réfléchir à l’organisation des équipes, à leur charge cognitive et aux interactions nécessaires pour faire évoluer durablement le logiciel.

Pourquoi évoquer ces approches ?

La performance d’un cycle de développement ne dépend pas uniquement des pratiques d’ingénierie. Elle repose également sur la manière dont les responsabilités sont réparties, les équipes organisées et les interactions structurées tout au long du cycle de vie du logiciel.

À l’ère de l’IA agentique, cette articulation devient encore plus importante. Un SDLC performant ne repose plus seulement sur de bonnes pratiques techniques : il suppose également une organisation capable de produire, structurer, partager et faire évoluer les connaissances qui permettront aux humains comme aux agents de travailler efficacement.

Il serait donc réducteur de reprendre le Software Development Life Cycle (SDLC) tel qu’il a été formalisé il y a plusieurs décennies sans tenir compte des progrès réalisés depuis dans notre compréhension du produit, des organisations et de l’ingénierie logicielle.

L’enjeu n’est pas d’abandonner le SDLC, mais de le revisiter à la lumière de ces apprentissages et des nouvelles capacités offertes par l’IA.

L’IA renforce l’importance de la découverte

Afin d’obtenir des résultats pertinents, il est essentiel de fournir aux agents d’intelligence artificielle un contexte riche, explicite et structuré. La qualité de leur travail dépend directement de la qualité des informations qui leur sont accessibles : intentions métier, besoins utilisateurs, règles, contraintes, décisions ou encore connaissances propres au domaine.

Or, depuis plusieurs années, les pratiques issues du Product Management et de l’UX ont profondément renouvelé notre manière de construire cette connaissance. L’une des évolutions majeures concerne la façon de découvrir les opportunités métier, d’explorer les problèmes à résoudre et de comprendre les besoins réels des utilisateurs.

Cette démarche s’éloigne des longues phases d’analyse réalisées en amont qui caractérisent les approches séquentielles traditionnelles. La connaissance n’est plus considérée comme quelque chose qu’il faudrait acquérir intégralement avant de commencer à construire le produit : elle se développe progressivement par l’exploration, l’expérimentation et l’apprentissage.

Aujourd’hui, cette découverte s’appuie sur des démarches collaboratives et itératives telles que le Product Discovery, le Design Thinking, l’UX Research ou encore l’EventStorming. Elles permettent de réunir des perspectives différentes — métier, produit, utilisateurs et technologie — afin de faire émerger collectivement une compréhension plus riche du problème et du domaine.

Ces démarches ne se limitent d’ailleurs pas à la seule découverte. Selon leur nature et le contexte dans lequel elles sont utilisées, elles contribuent également à l’idéation, à l’exploration du modèle métier, à la clarification des comportements attendus et à la conception de la solution.

À l’ère de l’IA agentique, leur rôle devient encore plus important : la connaissance produite collectivement ne sert plus uniquement à aligner les humains. Une fois explicitée, structurée et rendue accessible, elle constitue également le contexte dont les agents ont besoin pour raisonner, proposer des solutions et agir de manière pertinente.

La découverte devient ainsi le point de départ de la constitution d’un patrimoine de connaissances partagé entre humains et agents, qui sera progressivement enrichi tout au long du SDLC.

L’objectif n’est donc plus de figer un besoin avant de commencer le développement, mais de construire progressivement une compréhension partagée du métier, confronter les hypothèses au terrain et affiner continuellement les décisions.

La découverte et l’idéation ne constituent plus une phase isolée située au début d’un projet. Elles deviennent des activités continues qui accompagnent l’ensemble du cycle de vie. Les connaissances produites alimentent la conception et la construction du logiciel, tandis que les enseignements issus de son utilisation viennent à leur tour enrichir la compréhension du problème.

Mais pour que cette connaissance puisse circuler efficacement tout au long du cycle de vie, encore faut-il organiser les équipes autour de périmètres cohérents.

Le « comment » à l’ère de l’IA

Le Domain-Driven Design (DDD) stratégique ne se limite pas à structurer le logiciel. Il fournit également un cadre permettant à une audience diversifiée — experts métier, Product Managers, UX Designers, développeurs, architectes et autres parties prenantes — de construire collectivement une compréhension du domaine, puis d’identifier les frontières au sein desquelles les concepts, les règles et les comportements métier forment un ensemble cohérent.

Par nature, un domaine métier peut être décomposé en plusieurs sous-domaines correspondant à des problématiques distinctes. Le DDD permet notamment d’identifier des Bounded Contexts, chacun disposant de son propre modèle métier, de son langage ubiquitaire et de responsabilités clairement délimitées.

Ces frontières métier constituent ensuite un point d’appui pour organiser les équipes autour de responsabilités cohérentes et suffisamment autonomes. Le découpage du système et celui de l’organisation peuvent ainsi évoluer conjointement : plutôt que de structurer les équipes selon des fonctions ou des couches techniques, on cherche à les aligner sur des périmètres métier dont elles peuvent maîtriser le cycle de vie de bout en bout.

Cette organisation s’inscrit naturellement dans la continuité de la loi de Conway, selon laquelle les systèmes logiciels tendent à refléter les structures de communication des organisations qui les conçoivent. Agir sur les frontières organisationnelles devient dès lors également une manière d’agir sur l’architecture du système.

L’objectif est donc de rechercher une cohérence entre les frontières métier, les frontières du logiciel et les frontières organisationnelles. Les Bounded Contexts fournissent à cet égard des repères particulièrement utiles pour définir les responsabilités des équipes, sans pour autant imposer une correspondance systématique entre un Bounded Context et une équipe.

Une équipe peut prendre en charge plusieurs Bounded Contexts lorsque leur complexité et la charge cognitive associée restent maîtrisables. À l’inverse, les domaines les plus complexes ou stratégiques peuvent justifier qu’une équipe concentre son attention sur un périmètre plus restreint.

De la frontière métier à la charge cognitive

Cette vision est prolongée par Team Topologies, qui place la notion de charge cognitive au cœur de l’organisation des équipes.

Une équipe ne devrait pas être dimensionnée uniquement en fonction du volume de fonctionnalités qu’elle doit produire, mais également en fonction de la complexité qu’elle est capable de comprendre, de faire évoluer et de maîtriser durablement.

Les Stream-aligned Teams, alignées sur les flux de valeur du métier, peuvent ainsi être soutenues par des Platform Teams, des Enabling Teams et des Complicated Subsystem Teams. Leur rôle est notamment de permettre aux équipes de rester concentrées sur leur domaine en leur fournissant des plateformes, des capacités spécialisées ou un accompagnement adapté.

À l’ère de l’IA agentique, cette question prend une importance nouvelle. Les agents augmentent considérablement la capacité d’exécution des équipes, mais produire plus vite ne signifie pas nécessairement que les humains peuvent maîtriser davantage de complexité.

L’IA peut générer du code, produire des tests, analyser une base de code, proposer des solutions, documenter un système ou exécuter simultanément plusieurs tâches. Mais les équipes restent responsables de la compréhension du domaine, de la cohérence des décisions, des arbitrages et, finalement, du logiciel produit.

La question du dimensionnement des équipes évolue donc elle aussi. Si deux ou trois personnes augmentées par des agents peuvent désormais accomplir une quantité de travail qui nécessitait auparavant une équipe plus importante, la limite ne se situe plus nécessairement dans la capacité d’exécution, mais dans la charge cognitive que l’équipe est capable d’absorber.

L’IA peut donc conduire à des équipes plus petites et plus autonomes, sans pour autant faire disparaître la question de la charge cognitive. Au contraire : moins de personnes peuvent désormais produire davantage, mais elles doivent également comprendre, contrôler et assumer davantage de décisions et de transformations réalisées avec les agents.

Plus l’autonomie des agents progresse, plus la qualité du modèle métier, la clarté des responsabilités et la maîtrise du périmètre deviennent déterminantes.

De l’autonomie des agents au besoin de contrôle

Les premières expérimentations autour du développement assisté par l’IA ont parfois donné l’impression que la capacité à générer rapidement du code pouvait suffire à accélérer considérablement le développement.

Le vibe coding, lorsqu’il est pratiqué sans contrôle suffisant, en a également montré les limites : accumulation de code difficile à comprendre, incohérences architecturales, duplication ou encore dette technique générée à grande vitesse — ce que certains qualifient désormais d’AI slop.

Une prise de conscience s’est progressivement imposée : générer davantage de code ne signifie pas nécessairement produire un meilleur logiciel.

La vitesse apportée par l’IA peut même amplifier les problèmes lorsque les intentions, les règles d’architecture, les critères de qualité et les mécanismes de validation ne sont pas suffisamment explicites.

Le développement agentique entre ainsi dans une nouvelle phase de maturité. Il ne s’agit plus simplement de demander à un agent de produire du code, mais de construire un environnement capable d’encadrer son travail : spécifications explicites, conventions, tests automatisés, règles d’architecture, revues, outils de validation, boucles de feedback et contrôles de qualité.

Cette évolution conduit aujourd’hui à parler de « harnais IA » (AI harness) : un ensemble de mécanismes destinés à guider, contraindre et vérifier le travail des agents afin qu’ils puissent gagner en autonomie sans que l’équipe perde la maîtrise du logiciel produit.

Un principe commence ainsi à émerger :

plus les agents deviennent autonomes, plus l’environnement dans lequel ils évoluent doit être explicite, structuré et vérifiable.

On passe progressivement d’une logique de génération assistée par l’IA à une véritable ingénierie du développement agentique, dans laquelle l’autonomie des agents repose, paradoxalement, sur davantage de structure, de rigueur et de contrôle.

Le SDLC comme cadre de gouvernance du développement agentique

C’est précisément dans ce contexte que le vénérable Software Development Life Cycle (SDLC) retrouve toute sa pertinence.

Face à des agents capables d’intervenir sur une part croissante des activités de développement, il devient nécessaire de disposer d’un cadre permettant d’organiser, de coordonner et de contrôler leur intervention sur l’ensemble du cycle de vie, depuis l’exploration d’une opportunité métier jusqu’à l’exploitation et à l’évolution du logiciel.

Mais il ne s’agit ni de réintroduire un SDLC centralisé organisant l’ensemble de l’entreprise, ni de revenir à une succession de phases confiées à des équipes spécialisées fonctionnant en silos.

Dans une organisation découplée, chaque équipe alignée sur un périmètre métier maîtrise son propre cycle de vie de bout en bout. Elle découvre les opportunités, approfondit le domaine, conçoit la solution, construit le logiciel, le valide, le déploie, observe son comportement en production et utilise ce qu’elle apprend pour enrichir à nouveau sa compréhension du métier.

Le SDLC devient ainsi un cadre de gouvernance local à l’équipe, permettant d’orchestrer la collaboration entre experts métier, Product Managers, UX Designers, ingénieurs et agents d’intelligence artificielle autour d’un même périmètre de responsabilité.

Son rôle évolue également. Il ne s’agit plus seulement d’organiser la fabrication du logiciel : le SDLC orchestre désormais la création, la structuration, la transformation, la validation et l’enrichissement continus du patrimoine de connaissances dont les humains et les agents ont besoin pour travailler ensemble.

Réinventer le SDLC à l’ère de l’IA : le SDLC augmenté

Cette évolution nous conduit à proposer une relecture du SDLC adaptée à l’ère de l’IA agentique.

Les activités du cycle de vie ne sont plus envisagées comme une succession d’étapes prises en charge par des équipes fonctionnant en silos. Elles s’inscrivent dans un processus continu porté par des équipes alignées sur le métier, qui collaborent avec les experts métier, les Product Managers, les UX Designers et les agents d’intelligence artificielle.

Ensemble, humains et agents construisent, structurent, transforment et enrichissent progressivement une compréhension commune du domaine.

Cette connaissance ne constitue plus une documentation périphérique au logiciel. Elle devient une matière première du développement, directement mobilisable par les humains comme par les agents pour comprendre, concevoir, produire, vérifier et faire évoluer le système.

Le changement de perspective est important : le code n’est plus le principal actif produit par le cycle de développement. Il devient l’une des expressions d’un patrimoine de connaissances plus large, constitué des intentions métier, des modèles de domaine, des décisions, des spécifications, des règles, des tests, des choix d’architecture et des apprentissages issus de la production.

Dans ce SDLC augmenté, le logiciel devient ainsi l’expression exécutable d’un patrimoine de connaissances partagé, continuellement enrichi par les humains et exploité par les agents.

Cette vision s’articule autour de cinq grands moments :

• Découvrir — Comprendre le métier, les utilisateurs et identifier les opportunités.
• Concevoir — Structurer les connaissances et préparer la solution.
• Construire — Transformer les connaissances et les décisions en logiciel.
• Valider & Déployer — Vérifier la qualité et livrer continuellement.
• Apprendre & Faire évoluer — Observer, apprendre et enrichir continuellement le produit et son patrimoine de connaissances.

Ces cinq moments ne constituent pas les nouvelles étapes d’un processus séquentiel. Ils forment un cadre de référence continu, dans lequel les activités se chevauchent, interagissent et s’enrichissent mutuellement. Ce qui est appris en production peut remettre en question une hypothèse formulée lors de la découverte ; une décision de conception peut conduire à approfondir le domaine ; un test peut révéler une ambiguïté dans une spécification.

Le SDLC devient ainsi une boucle continue de transformation de la connaissance :

comprendre → expliciter → concevoir → exécuter → vérifier → apprendre → enrichir.

À l’ère de l’IA, la valeur du développement logiciel se déplace progressivement de la seule production de code vers la qualité des connaissances et des décisions qui la guident.

Les agents accélèrent considérablement la transformation de cette connaissance en logiciel. Les équipes, quant à elles, restent responsables de sa compréhension, de sa cohérence, de son évolution et des décisions qui façonnent durablement le produit.

C’est cette articulation entre connaissance humaine, capacité d’exécution des agents et apprentissage continu qui constitue le cœur du SDLC augmenté.

Découverte → Conception → Construction → Validation & Déploiement → Apprentissage & Évolution

Cette relecture ne remet pas en cause les principes fondateurs du SDLC ; elle les adapte aux pratiques modernes du développement logiciel. Conçu à une époque dominée par les architectures monolithiques, les livraisons espacées et les organisations en silos, le modèle historique s'enrichit aujourd'hui des apports des méthodes agiles, du DevOps, de l'intégration continue, du Domain-Driven Design, du Behavior-Driven Development, du Spec-Driven Development et, désormais, de l'IA agentique.

À l'ère de l'IA, le principal défi n'est plus seulement de produire du code, mais de construire, partager et faire évoluer un patrimoine de connaissances exploitable par les équipes comme par les agents. La qualité de ce contexte devient le principal facteur de leur efficacité.

Le SDLC conserve ainsi son rôle de cadre de gouvernance, tout en évoluant pour placer la connaissance au cœur du développement logiciel.

Les étapes du SDL Augmenté

Pour illustrer concrètement cette évolution, nous suivrons les différentes activités d'un SDLC augmenté, qui rassemble les pratiques d'ingénierie logicielle ayant progressivement façonné le développement moderne au XXIᵉ siècle.

1 - Découvir

Aligner la vision, identifier les opportunités et définir les critères de réussite

À l'ère de l'IA agentique, la compréhension du métier ne résulte plus d'une phase d'analyse réalisée au début d'un projet. Elle se construit et s'enrichit en continu à partir des échanges avec les utilisateurs et les experts métier, des ateliers d'EventStorming, de l'observation des usages et de l'analyse des données. Les outils d'IA peuvent désormais capturer les ateliers, transformer automatiquement les post-it en artefacts numériques, les restituer dans des outils collaboratifs tels que Miro et produire une première synthèse des connaissances acquises.

Unsplash - Karla Hernandez

Le Product Manager et l'UX Designer jouent un rôle central dans cette démarche. Ils organisent des ateliers d'idéation, confrontent, structurent et distillent les informations afin de construire une vision cohérente du métier, progressivement enrichie par les développeurs, les architectes et les experts qualité. Les échanges, les décisions et les ateliers peuvent être capturés et synthétisés par des agents afin d'alimenter automatiquement la documentation et le patrimoine de connaissances.

La découverte ne consiste pas seulement à identifier les besoins ; elle explore également les solutions possibles. Dans l'esprit du Continuous Discovery et de l'Opportunity Solution Tree (OST), les hypothèses sont rapidement confrontées à la réalité afin de réduire les risques avant tout investissement. Là encore, l'IA facilite la capitalisation des idées, des hypothèses, des expériences et des décisions, qui viennent enrichir progressivement les connaissances du produit.

L'IA agentique accélère ainsi ce cycle d'apprentissage. Les équipes produisent rapidement des maquettes ou des prototypes, tandis que les agents analysent les données, synthétisent les retours utilisateurs, identifient des tendances et mettent en évidence de nouvelles opportunités. Ils enrichissent la réflexion sans jamais se substituer au jugement de l'équipe produit et des experts métier.

À l'issue de cette activité, les équipes disposent d'une compréhension partagée du domaine, des besoins utilisateurs, des opportunités de création de valeur et des critères de réussite. Cette connaissance constitue le point de départ de l'activité Concevoir, où elle sera progressivement transformée en modèle métier, en comportements explicites puis en spécifications vivantes.

2 - Concevoir

Structurer le modèle métier, concevoir la solution et préparer les fondations techniques et organisationnelles

Une fois les besoins clarifiés, les équipes construisent un modèle métier et une architecture capables de soutenir durablement l'évolution du produit. Cette activité dépasse largement le choix des technologies : elle consiste à structurer les concepts métier, leurs responsabilités, les invariants du Bounded Context et les interactions qui assurent la cohérence du système. Dans ce cadre, L'intelligence artificielle peut compléter avec des informations non structurées, telles que des courriels, des conversations, ou des documents complémentaires avec des agents conversationnels structurés. Elle peut également assister les équipes dans leur validation en détectant les ambiguïtés, les incohérences, les omissions ou les contradictions.

Unsplash - UX Indonesia

Le Domain-Driven Design constitue le socle de cette démarche. Les connaissances acquises lors des ateliers d'EventStorming Software Design sont progressivement transformées en agrégats, événements de domaine, services métier, politiques et langage ubiquitaire. L'objectif est de construire un modèle capable d'évoluer avec le métier. Les résultats de l’EventStorming Software Design, pour être numérisé afin de rejoindre les documents de connaissances.

Cette construction s'effectue par enrichissements successifs. L'EventStorming Software Design fait émerger les concepts du domaine, les CRC Cards répartissent les responsabilités, les ateliers d'Example Mapping explicitent les règles métier et les cas limites, tandis que les ateliers de Formulation transforment progressivement ces connaissances en comportements exprimés dans un langage partagé. Les User Stories organisent ensuite ces comportements en incréments fonctionnels. Après validation par les experts métier, ces comportements sont formalisés sous forme de scénarios Gherkin, qui deviennent une source de connaissances exploitable par les outils de Spec-Driven Development (SDD), tels que GitHub Spec Kit. Ils sont alors intégrés aux spécifications vivantes, où ils côtoient le modèle métier, les décisions d'architecture et les autres connaissances qui guideront les agents d'intelligence artificielle tout au long du cycle de vie du logiciel.

Les agents enrichissent cette activité en détectant les incohérences, en suggérant des cas limites, en analysant l'impact des évolutions métier ou en proposant des alternatives de conception. Ils accélèrent l'exploration des solutions, tandis que les décisions structurantes demeurent sous la responsabilité des experts métier, des architectes et des développeurs.

Le modèle métier évolue ainsi tout au long de la vie du produit. Chaque évolution métier l'enrichit, fait évoluer les comportements et, si nécessaire, l'architecture. Il constitue le patrimoine de connaissances qui guidera les activités de Construction, de Validation et d'Évolution du logiciel.

3 - Construire

Développer de manière itérative et enrichir continuellement le patrimoine de connaissances du produit

L'activité de Construction consiste à transformer progressivement les connaissances acquises lors des activités de Découverte et de Conception en un logiciel exécutable. À l'ère de l'IA agentique, cette transformation repose moins sur l'écriture manuelle du code que sur la capacité des équipes à construire un contexte riche permettant de guider les agents.

Unsplash - Josh Olalde

Le Spec-Driven Development (SDD) joue ici un rôle central. Il transforme les connaissances produites tout au long du SDLC en une source de vérité partagée, continuellement enrichie au fil du développement. Les spécifications vivantes rassemblent le modèle métier, les comportements attendus, les décisions d'architecture, les critères d'acceptation et les conventions de développement. Elles constituent le contexte de référence à partir duquel les agents conçoivent, développent, exécutent les tests unitaires, d'intégration et d'acceptation afin d'assurer la qualité du logiciel, puis le font évoluer.

À partir de ce patrimoine de connaissances, les équipes orchestrent plusieurs agents spécialisés travaillant en parallèle. Ils analysent les spécifications, produisent le code, les tests, la documentation ou les décisions d'architecture, tout en détectant les incohérences, les violations du modèle métier et les opportunités de refactoring. Ils enrichissent ainsi continuellement le patrimoine de connaissances, tandis que les décisions structurantes demeurent sous la responsabilité des développeurs, des architectes et des experts métier.

Le rôle des développeurs évolue en conséquence. Ils orchestrent les agents, arbitrent leurs propositions et garantissent la cohérence du patrimoine de connaissances. La génération de code devient ainsi la conséquence naturelle d'une connaissance explicite, partagée et continuellement enrichie. La performance d'une équipe dépend désormais autant de la qualité de ce patrimoine que de sa capacité à produire du logiciel.

4 - Valider et Déployer

Transformer les spécifications vivantes en un logiciel exécutable, validé et déployé en continu

Les spécifications vivantes décrivent le comportement attendu du logiciel ; les harnais de test (Harness Engineering) vérifient en permanence qu'il est respecté. Ensemble, ils fournissent un cadre d'exécution fiable permettant aux équipes comme aux agents de développer, valider et faire évoluer le logiciel en toute confiance.

À partir de ces spécifications, les agents produisent le code, exécutent les validations, détectent les régressions, les vulnérabilités ou les écarts par rapport aux exigences, puis orchestrent le déploiement continu. Des agents spécialisés peuvent également assurer la sécurité en analysant le code, les dépendances et les infrastructures afin d'identifier les vulnérabilités connues et de proposer les corrections nécessaires.

Unsplash - Paris Bilal

Le rôle des développeurs évolue en conséquence. Ils orchestrent les agents, analysent leurs résultats et prennent les décisions qui nécessitent une compréhension du métier ou un jugement humain. Les mises en production deviennent ainsi plus fréquentes, plus fiables et moins risquées, tandis que chaque déploiement enrichit le patrimoine de connaissances qui guidera les évolutions futures.

5 - Apprendre et faire évoluer

Observer, apprendre, s'adapter et faire évoluer continuellement le produit, les pratiques et l'organisation

Un logiciel n'est jamais véritablement terminé. Il évolue au rythme des nouveaux besoins métier, des évolutions réglementaires, des retours des utilisateurs et des avancées technologiques. À l'ère de l'IA agentique, la maintenance dépasse largement la correction des anomalies : elle devient un processus continu d'observation, d'apprentissage et d'amélioration.

Unsplash - Brett Jordan

Le SDLC forme ainsi une boucle d'apprentissage permanente. Les enseignements issus de la production alimentent la découverte de nouvelles opportunités, enrichissent le modèle métier, les spécifications vivantes et les décisions d'architecture, avant de se concrétiser en nouvelles évolutions du produit.

Les agents jouent un rôle central dans cette démarche. Connectés aux plateformes d'observabilité, ils analysent en continu la télémétrie, les performances et les usages afin de détecter les anomalies, les points de friction et les opportunités d'amélioration. Ils surveillent également la qualité technique du système, préparent les corrections et, lorsque le produit embarque des modèles d'IA, détectent les dérives des données ou des modèles.

Les mises à jour du patrimoine de connaissances peuvent être proposées automatiquement, mais leur validation demeure sous la responsabilité des équipes. La production n'est ainsi plus seulement un environnement d'exploitation ; elle devient une source permanente de connaissances qui nourrit l'évolution du produit, tandis que les agents accélèrent cette boucle d'amélioration.

SDLC augmenté est une évolution naturelle du SDL traditionnel

Pourquoi revisiter un cadre imaginé il y a plus de soixante ans ? Tout simplement parce que le développement logiciel a profondément évolué. Au fil des décennies, les méthodes agiles, le Domain-Driven Design, le Behavior-Driven Development, le DevOps, puis plus récemment le Spec-Driven Development et l'IA agentique ont transformé notre manière de concevoir, de développer et de faire évoluer les logiciels. Le SDLC augmenté que nous proposons s'inscrit dans cette continuité. Il conserve les principes fondateurs du modèle d'origine tout en intégrant ces avancées afin de fournir un cadre de gouvernance adapté aux enjeux techniques, organisationnels et humains des organisations à l'ère de l'IA.

De l'analyse à la découverte

Dans le SDLC traditionnel, la première étape consiste à analyser les besoins afin de produire des spécifications suffisamment stables pour engager la conception et le développement.

Le SDLC augmenté remplace cette logique par une démarche de découverte continue. L'objectif n'est plus de figer les besoins, mais de construire progressivement une compréhension partagée du métier. Les approches de Product Discovery, d'UX Research, de Design Thinking et d'EventStorming permettent d'explorer le domaine, de confronter les hypothèses au terrain et d'identifier les opportunités de création de valeur. La découverte devient ainsi une activité permanente qui enrichit continuellement le patrimoine de connaissances du produit.

Du design à la conception

Dans le SDLC traditionnel, la phase de design consiste principalement à définir l'architecture technique de la solution : composants, modèles de données, interfaces et mécanismes qui guideront l'implémentation.

Le SDLC augmenté élargit cette vision. Concevoir ne consiste plus seulement à définir une architecture, mais à structurer les connaissances acquises lors de la découverte. Le Domain-Driven Design construit le modèle métier, le Behavior-Driven Development en explicite les comportements et le Spec-Driven Development transforme progressivement cette connaissance en spécifications vivantes. La conception prépare ainsi le contexte que les agents d'intelligence artificielle exploiteront pour produire un logiciel cohérent.

De l'implémentation à la construction

Dans le SDLC traditionnel, l'implémentation consiste principalement à transformer les spécifications en code source.

Le SDLC augmenté remplace cette logique par une activité de construction. Construire consiste à transformer progressivement le patrimoine de connaissances du produit en logiciel tout en l'enrichissant continuellement. Les spécifications vivantes deviennent la source de vérité, les agents produisent le code, les tests et la documentation, tandis que les développeurs orchestrent leur travail et garantissent la cohérence du modèle. Le logiciel n'est plus l'unique résultat de cette activité : le patrimoine de connaissances évolue au même rythme que lui.

De la validation et du déploiement continus

Dans le SDLC traditionnel, le déploiement marque la mise en production d'une nouvelle version du logiciel, après une phase de validation destinée à limiter les risques.

Le SDLC augmenté réunit ces deux dimensions dans une même activité. Les spécifications vivantes, le Harness Engineering, les tests automatisés et les pipelines d'intégration continue vérifient en permanence que le logiciel reste conforme aux attentes métier. Déployer ne consiste plus seulement à livrer rapidement, mais à livrer en continu avec un niveau élevé de confiance.

Du support et de la maintenance à l'apprentissage et à l'évolution

Dans le SDLC traditionnel, la dernière étape est consacrée au support des utilisateurs, à la correction des anomalies et à la maintenance du logiciel.

Le SDLC augmenté transforme cette étape en une activité permanente d'apprentissage. La production devient une source continue de connaissances qui enrichit le produit, le modèle métier et les spécifications. Les données d'observabilité, les retours des utilisateurs et les incidents alimentent cette compréhension, tandis que les agents identifient des tendances ou proposent des améliorations. Les équipes conservent la responsabilité des décisions, et les enseignements issus de la production nourrissent une nouvelle phase de découverte, refermant ainsi la boucle du SDLC.

Afin de comprendre la réincarnation du SDLC, il suffit de lire les intitulés des colonnes de ce tableau récapitulatif entre le SDLC traditionnel et le SDLC augmenté.

Le SDLC Augmenté parmi les propositions de SDLC à l'ère de l'IA

Si vous recherchez des informations sur le SDLC IA ou l'ADLC (Agentic Development Lifecycle), vous serez probablement surpris par le nombre de propositions disponibles. Nous traversons une période d'enthousiasme autour de l'IA générative, où chacun imagine le cycle de vie logiciel de demain. Nombre de ces visions décrivent des agents capables de prendre en charge une part croissante des activités d'analyse, de conception, de développement, de test ou même d'architecture.

Cette perspective mérite toutefois d'être nuancée. Si votre ambition est de construire un avantage concurrentiel durable, ne confiez pas à l'intelligence artificielle les décisions qui fondent l'identité de votre produit : sa raison d'être, votre stratégie métier, l'expérience utilisateur, le modèle métier ou les choix structurants de l'architecture. Ce sont ces décisions qui constituent la véritable singularité d'une organisation et qui lui permettent de se différencier durablement de ses concurrents.

Les modèles d'IA sont entraînés sur un vaste corpus de connaissances. Ils excellent pour synthétiser, rapprocher des idées, accélérer l'exécution ou proposer des solutions pertinentes. En revanche, ils convergent naturellement vers des réponses qui reflètent les pratiques les plus répandues. Ils constituent un formidable accélérateur, mais ils ne peuvent remplacer la vision stratégique, la créativité et le jugement qui permettent à une organisation de se distinguer.

L'IA ne crée donc pas l'avantage concurrentiel; elle l'amplifie. Si les équipes construisent un modèle métier riche, une expérience utilisateur différenciante et une architecture adaptée à leur contexte, les agents permettront d'aller plus vite et plus loin. À l'inverse, si elles leur délèguent ces choix, elles risquent d'obtenir un logiciel performant, mais finalement très proche de celui que leurs concurrents pourraient produire.

Cette analyse met en évidence une limite de nombreuses propositions actuelles de SDLC IA ou d'Agentic Development Lifecycle. La plupart conservent la structure du SDLC historique en ajoutant certaines étapes ou en remplaçant simplement les acteurs humains par des agents. L'attention se concentre essentiellement sur l'accélération de l'exécution, sans rendre explicites les activités qui permettent de construire une compréhension partagée du métier ni la complémentarité entre les équipes et l'intelligence artificielle.

Cette vision conduit implicitement à considérer que la performance résulte avant tout d'une automatisation toujours plus poussée. Or, les décisions qui façonnent durablement un produit ne naissent pas de l'exécution, mais de la réflexion collective. Explorer une opportunité métier, confronter des hypothèses, arbitrer entre plusieurs options de conception, construire un modèle partagé ou remettre en question une décision d'architecture sont des activités où le dialogue entre les experts métier, les Product Managers, les UX Designers, les développeurs et les architectes demeure irremplaçable. Les agents peuvent naturellement y contribuer : ils préparent les ateliers, synthétisent les échanges, proposent des alternatives, détectent des incohérences ou mettent en évidence des angles morts. Ils enrichissent la réflexion collective ; ils ne s'y substituent pas.

Du cycle de développement au cycle de la connaissance

C'est précisément cette délibération qui produit la ressource la plus précieuse à l'ère de l'IA : le patrimoine de connaissances de l'organisation. Les ateliers de Product Discovery, de Design Thinking, d'EventStorming, d'Example Mapping, de Formulation des scénarios métier ou encore les ateliers d'architecture n'ont pas pour finalité de produire du code. Leur objectif est de construire progressivement une compréhension commune du métier. Les modèles métier, les spécifications vivantes, les décisions d'architecture et les comportements qui en émergent constituent ensuite le contexte indispensable aux agents pour concevoir un logiciel cohérent et faire évoluer le système avec pertinence.

Dans sa formulation originelle, le SDLC répondait parfaitement aux contraintes de son époque. Il avait pour vocation d'organiser la production du logiciel, alors que l'écriture du code représentait l'activité la plus coûteuse et la plus difficile à automatiser. Avec l'essor de l'IA agentique, le centre de gravité du développement logiciel se déplace. La génération de code devient en grande partie automatisable, tandis que la compréhension du métier, la qualité des décisions et la construction d'un patrimoine de connaissances partagé deviennent les principaux leviers de création de valeur.

Le SDLC augmenté proposé dans cette série d'articles poursuit une ambition différente. Il ne consiste pas à introduire des agents dans un cycle de vie inchangé ; il redéfinit le cycle lui-même afin de rendre explicites les activités qui permettent de découvrir, structurer, transformer et enrichir les connaissances tout au long du développement. Celles-ci sont progressivement consolidées dans un patrimoine partagé qui alimente les décisions humaines, guide les agents et s'enrichit en continu grâce aux enseignements issus de la production.

A l’ère de l’IA la valeur naît de la capitalisation d’un patrimoine de connaissance

Le SDLC cesse ainsi d'être une simple succession d'étapes conduisant à la livraison d'un logiciel. Il devient un véritable cadre de gouvernance dont la finalité est de construire, de préserver et de faire évoluer le patrimoine de connaissances de l'organisation. Ce patrimoine constitue le socle sur lequel les équipes prennent leurs décisions, tandis que les agents s'appuient sur lui pour produire, tester et faire évoluer le logiciel.

Deux visions du développement logiciel se dessinent alors.

• La première consiste à faire exécuter le SDLC historique dans la pensée, par des agents d'intelligence artificielle toujours plus autonomes.
• La seconde, défendue dans cette série d'articles, repense le cycle de vie lui-même afin de placer la découverte, la délibération collective, la structuration et l'évolution des connaissances au cœur du développement.

Les agents n'y sont plus de simples exécutants. Ils deviennent des partenaires de réflexion, capables de produire, de consommer et d'enrichir un patrimoine de connaissances partagé. Les équipes en assurent la gouvernance et prennent les décisions qui déterminent durablement l'avenir du produit. L'accélération des livraisons n'est alors qu'une conséquence naturelle de cette nouvelle organisation. La véritable finalité reste identique à celle qui anime le génie logiciel depuis ses origines : créer toujours plus de valeur pour les utilisateurs.

Conclusion

Depuis plus de soixante ans, le Software Development Life Cycle (SDLC) constitue le cadre de référence du développement logiciel. Les méthodes agiles, le DevOps, le Domain-Driven Design, le Behavior-Driven Development ou encore le Spec-Driven Development ne l'ont jamais remplacé ; ils en ont progressivement enrichi les pratiques.

L'IA agentique ouvre une nouvelle étape. En automatisant une part croissante de l'exécution, elle déplace le centre de gravité du développement : la valeur ne réside plus principalement dans la production du code, mais dans la capacité des organisations à découvrir, structurer, partager et faire évoluer leurs connaissances.

Le SDLC augmenté proposé dans cette série d'articles ne se contente pas d'introduire des agents dans le cycle de vie historique. Il fait de la connaissance le fil conducteur du développement. Les agents deviennent des partenaires qui amplifient les capacités des équipes, tandis que celles-ci conservent la gouvernance et la responsabilité des décisions qui façonnent durablement le produit.

À l'ère de l'IA, l'avantage concurrentiel ne dépendra pas des agents les plus performants, mais de la capacité des organisations à construire, gouverner et enrichir un patrimoine de connaissances partagé. Les agents accélèrent la création de logiciels ; les équipes continueront d'en définir la vision et la direction.