Organiser une équipe de développement à l’ère de l’IA - Part II.2

Organiser une équipe de développement à l’ère de l’IA - Part II.2

Construire le patrimoine de connaissances à l’ère de l’IA (suite)

Dans la première partie, nous avons montré qu’à l’ère de l’IA, la valeur se déplace du code vers la connaissance et la qualité des décisions*. Le DDD structure cette connaissance métier, le BDD en explicite les comportements et le SDD la transforme en* un contexte exploitable par les équipes et les agents*. Dans cette seconde partie, nous poursuivons cette réflexion en détaillant concrètement* comment construire et structurer ce patrimoine de connaissances pour le rendre aussi explicite que possible.

Clarifier les comportements du métier

Unsplash - Vitaly Gariev

Le Domain-Driven Design structure le domaine métier en identifiant ses concepts, son langage ubiquitaire et les responsabilités qui organisent le système. Mais un logiciel ne se contente pas de représenter le métier : il en exprime aussi les comportements. Réserver une place, calculer un risque ou valider un paiement consiste à appliquer des règles métier en réponse à des événements. C'est cette dimension active que le Behavior-Driven Development (BDD) met en lumière.

Le BDD place la conversation au cœur du développement. À partir d'une User Story, experts métier, Product Managers, développeurs et testeurs clarifient collectivement les règles de gestion, les cas particuliers et les critères d'acceptation.

Longtemps, cette connaissance est restée portée par les échanges et l'expérience des équipes. Avec l'arrivée des agents d'intelligence artificielle, elle doit désormais être capturée, structurée et pérennisée. Les conversations deviennent ainsi un patrimoine de connaissances directement exploitable, aussi bien par les équipes que par les agents.

Quand le BDD devient le langage des agents

L'arrivée des agents d'intelligence artificielle transforme profondément le rôle du Behavior-Driven Development. Pendant longtemps, le BDD avait pour vocation de faciliter la collaboration entre les experts métier, les Product Managers, les développeurs et les testeurs afin de construire une compréhension commune des comportements attendus. Aujourd'hui, il répond à un enjeu supplémentaire : fournir aux agents d'intelligence artificielle une description explicite du comportement du système.

Contrairement aux humains, les agents ne participent pas aux ateliers de découverte. Ils ne posent pas de questions, ne confrontent pas leurs hypothèses et ne compensent pas les ambiguïtés grâce à leur expérience. Ils ne raisonnent qu'à partir des connaissances explicitement présentes dans leur contexte. Toute règle métier implicite, toute exception non documentée ou tout comportement laissé à l'interprétation devient une source potentielle d'erreur.

Expliciter les comportements métier pour les agents

L’atelier d'Example Mapping prend ainsi une importance nouvelle. Ils ne servent plus uniquement à aligner les équipes ; ils transforment les conversations en connaissances comportementales. Les règles métier, les exemples, les contre-exemples, les cas limites et les questions ouvertes deviennent autant d'informations structurées qui réduisent progressivement les ambiguïtés.

Cartographie et grammaire de l’Example Mapping

Rendre les comportements métier explicites pour les agents

Cette connaissance est ensuite formalisée grâce à la syntaxe Gherkin 6. Les scénarios ne constituent plus seulement des critères d'acceptation destinés aux tests : ils deviennent un véritable langage d'instruction pour les agents. Chaque scénario décrit, sans ambiguïté, les conditions initiales, les événements déclencheurs, les décisions attendues et les résultats observables. Les agents disposent ainsi d'une représentation explicite du comportement du système, sans avoir à l'inférer à partir du code ou de suppositions.

La qualité de cette description devient alors essentielle. Un scénario imprécis ou incomplet ne dégrade plus seulement la qualité des tests d'acceptation : il appauvrit directement le contexte sur lequel raisonnent les agents. Les principes BRIEF prennent ainsi une dimension nouvelle. Employer le langage du métier (Business Language), utiliser des données réalistes (Real Data), révéler clairement l'intention (Intention Revealing), ne conserver que les informations essentielles (Essential) et décrire un seul comportement (Focused) permettent de produire une connaissance précise, cohérente et directement exploitable par les agents.

Contexte structurel et comportemental

Unsplash - Courtney Smith

Le Domain-Driven Design répond à une première question fondamentale : « Que représente le métier ? » Il décrit les concepts, leurs responsabilités, leurs relations, leurs frontières, leurs invariants et l'architecture qui structure le système.

Le Behavior-Driven Development répond à une question complémentaire : « Comment le métier se comporte-t-il ? » Il explicite les règles de gestion, les scénarios métier, les cas limites et les comportements attendus.

Ces deux approches sont indissociables. Le DDD fournit le contexte structurel ; le BDD le contexte comportemental. Ensemble, ils produisent une représentation explicite du métier que les agents d'intelligence artificielle peuvent comprendre et exploiter. Contrairement à un développeur expérimenté, les agents ne disposent ni d'intuition métier ni de connaissances tacites : ils raisonnent à partir du contexte qui leur est fourni.

Cette évolution transforme profondément le rôle des ateliers DDD et BDD. Ils ne produisent plus seulement des artefacts destinés aux équipes de développement ; ils construisent progressivement le patrimoine de connaissances de l'organisation, directement exploitable par les agents tout au long du cycle de vie du logiciel.

L'étape suivante consiste naturellement à rassembler ce patrimoine dans une spécification vivante, cohérente, versionnée et directement exploitable, qui devient la véritable source de vérité du projet. C'est précisément l'ambition du Spec-Driven Development.

Ancrer la connaissance dans une spécification vivante

À ce stade, l'équipe en charge du Bounded Context dispose d'un patrimoine de connaissances riche et structuré. Le Domain-Driven Design construit un modèle partagé du métier, le Behavior-Driven Development en explicite les comportements, tandis que les décisions d'architecture, les exigences de qualité et les contraintes techniques complètent progressivement ce patrimoine. Les invariants portés par l’ agrégat sont ensuite déclinés en User Stories, puis précisés au travers de scénarios BDD décrivant les comportements attendus du système.

L'enjeu n'est alors plus de produire davantage d'informations, mais d'organiser ces connaissances dans une spécification vivante, cohérente, versionnée et directement exploitable. C'est précisément l'ambition du Spec-Driven Development (SDD). La spécification devient la nouvelle source de vérité du projet : le code n'est plus la référence, mais la conséquence d'une connaissance explicitement structurée.

Le DDD structure le métier, le BDD formalise ses comportements et le SDD réunit l'ensemble dans un référentiel partagé qui guide aussi bien les équipes que les agents d'intelligence artificielle.

Découvrir l'écosystème Spec Kit

Le Spec-Driven Development (SDD) propose une nouvelle manière de concevoir le développement logiciel. Plutôt que de demander à un agent de générer du code à partir d'un simple prompt, il lui fournit un contexte riche, structuré et continuellement enrichi. La spécification devient ainsi le point de départ du développement et le principal support de collaboration entre les équipes et les agents.

Des initiatives comme Kiro (AWS), GitHub Spec Kit ou Tessl mettent cette vision en pratique. Développé en open source par GitHub, Spec Kit s'appuie sur une chaîne d'artefacts décrivant le besoin métier, les décisions d'architecture, la stratégie d'implémentation et les critères de qualité. Les besoins sont clarifiés, les ambiguïtés levées et les choix d'architecture explicités avant toute génération de code.

Les spécifications, plans, tâches et décisions d'architecture sont versionnés dans Git sous forme de fichiers Markdown. Le dépôt devient ainsi la mémoire vivante des connaissances du projet.

Une fois le projet initialiséf, le workflow de Spec Kit repose sur trois commandes. /specify décrit le quoi et le pourquoi du projet. /plan transforme cette spécification en un plan d'implémentation cohérent avec l'architecture retenue. Enfin, /tasks décompose ce plan en tâches exploitables pour guider la mise en œuvre.

Au-delà de l'outillage, le Spec-Driven Development introduit un changement de paradigme : les agents ne génèrent plus du code à partir d'un prompt, mais raisonnent à partir d'une connaissance explicite et partagée.

Le SDD ne signifie pas que tout le code doive être généré automatiquement. Le niveau d'autonomie accordé aux agents dépend de la nature du sous-domaine. Dans les Generic Domains, les agents peuvent produire une grande partie des implémentations. À l'inverse, dans les Core Domains, où se concentre la différenciation de l'entreprise, les équipes restent responsables du modèle métier, des invariants, de la qualité du design et des choix d'architecture. Une démarche de Deep Modeling, fondée sur un refactoring itératif orienté métier, complète alors naturellement le Spec-Driven Development. La spécification demeure un support vivant qui guide les agents sans jamais se substituer à l'expertise humaine.

Les agents IA, partenaires de réflexion

Les ateliers font régulièrement émerger des questions auxquelles les participants ne peuvent pas répondre immédiatement. Certaines nécessitent des recherches complémentaires, la consultation d'experts ou une analyse plus approfondie. Dans ce contexte, un agent d'intelligence artificielle enrichi du contexte du projet devient un véritable assistant de facilitation.

Les questions ouvertes d'un Example Mapping, ainsi que les Hot Spots, douleurs et opportunités identifiés lors d'un EventStorming, peuvent lui être soumis en temps réel. En s'appuyant sur le modèle métier, le langage ubiquitaire, les spécifications et les décisions d'architecture, il peut rappeler des règles existantes, détecter des incohérences, mettre en évidence des impacts ou suggérer des pistes d'investigation.

L'agent ne remplace ni l'intelligence collective ni les décisions des participants. Il enrichit les échanges en accélérant l'exploration, en réduisant les zones d'incertitude et en mobilisant les connaissances accumulées par l'équipe.

Organisations pilotées par la connaissance

Une conclusion s'impose. Si la création de valeur ne réside plus principalement dans la production de code, mais dans la connaissance qui guide les agents, et si la spécification vivante devient la source de vérité du logiciel, alors les équipes de développement ne peuvent plus être organisées comme elles l'étaient jusqu'à présent.

Cette évolution ne résulte pas de l'apparition des agents d'intelligence artificielle, mais du déplacement de la création de valeur. Pendant plusieurs décennies, les organisations ont optimisé leur capacité à produire du code. Désormais, leur avantage concurrentiel repose sur leur aptitude à comprendre le métier, structurer les connaissances, prendre les bonnes décisions et fournir aux agents un contexte riche, cohérent et fiable.

Les équipes agentiques ne sont donc pas à l'origine de cette transformation ; elles en sont la conséquence. Elles constituent la réponse organisationnelle à un développement logiciel où la connaissance devient le principal levier de performance.

Des équipes plus petites, des responsabilités accrues

Dans la première partie, nous avons montré que l'essor de l'IA agentique conduit à l'émergence d'équipes plus resserrées, mais aussi plus expérimentées. La création de valeur ne repose plus principalement sur la production de code, mais sur la capacité à comprendre le métier, structurer les connaissances, concevoir une architecture cohérente et orchestrer efficacement les agents.

Les activités d'exécution, génération de code, production de tests, documentation, modernisation ou refactoring, sont progressivement confiées aux agents. Les équipes humaines concentrent désormais leurs efforts sur ce qui relève du jugement : explorer le métier, prendre des décisions, lever les ambiguïtés, arbitrer les compromis et maîtriser les risques.

Cette évolution dépasse largement les équipes de développement. Product Managers, experts métier, UX Designers, architectes et spécialistes de la qualité ou de la sécurité contribuent désormais à construire un patrimoine commun de connaissances, qui devient le principal contexte de travail des agents. Les organisations évoluent ainsi vers de véritables systèmes de production de connaissances, où la valeur repose autant sur la qualité des modèles métier, des spécifications et des décisions que sur la capacité à produire du code.

Spec-Driven Development et les comportements métiers

Le Spec-Driven Development (SDD) propose une nouvelle manière de concevoir le développement logiciel. Plutôt que de demander à un agent de générer du code à partir d'un simple prompt, il lui fournit un contexte riche, structuré et continuellement enrichi. La spécification devient ainsi le point de départ du développement et le principal support de collaboration entre les équipes et les agents d'intelligence artificielle.

Plusieurs initiatives, comme Kiro (AWS), GitHub Spec Kit ou Tessl, mettent cette vision en pratique. Développé en open source par GitHub, Spec Kit s'appuie sur une chaîne d'artefacts décrivant le besoin métier, les décisions d'architecture, la stratégie d'implémentation et les critères de qualité. Le développement progresse par enrichissement continu de la connaissance : les besoins sont clarifiés, les ambiguïtés levées et les choix d'architecture explicités avant toute génération de code.

Cette approche repose sur des artefacts simples, spécifications, plans, tâches et décisions d'architecture, versionnés dans Git sous forme de fichiers Markdown. Le dépôt ne conserve plus seulement le code source ; il devient également la mémoire vivante des connaissances et des décisions du projet.

Au-delà de l'outillage, le Spec-Driven Development introduit un véritable changement de paradigme : les agents ne génèrent plus du code à partir d'un simple prompt, mais raisonnent à partir d'une connaissance explicite, partagée et continuellement enrichie.

Le SDD ne signifie toutefois pas que tout le code doive être généré automatiquement. Son objectif est de fournir un cadre de travail où les décisions sont explicites, traçables et continuellement enrichies. Le niveau d'autonomie accordé aux agents dépend alors de la nature du sous-domaine métier.

Préparer la transformation agentique

Unsplash - Getty Images

À l'échelle de l'entreprise, cette transformation ne peut être improvisée. L'IA générative est une technologie de rupture qui transforme l'organisation du travail, les modes de collaboration et les compétences.

À mesure que les agents automatisent une part croissante de l'exécution, la qualité du contexte devient le principal facteur de performance. Les entreprises doivent donc rapprocher les experts métier et les équipes techniques afin de construire un patrimoine de connaissances partagé, explicite et continuellement enrichi.

Cette évolution favorise des équipes plus resserrées et des échanges plus directs entre le métier et l'IT. Une nouvelle chaîne de valeur émerge : la qualité des conversations façonne les connaissances ; les connaissances guident les décisions des agents ; les décisions des agents déterminent la qualité des logiciels produits.

Des pratiques adaptées à chaque sous-domaine

Le Core Domain, qui concentre les avantages concurrentiels de l'entreprise, justifie un investissement important dans les approches DDD, BDD et SDD. Le code généré par les agents y fait l'objet d'une revue attentive afin de garantir la qualité du design, la préservation des invariants métier et la cohérence de l'architecture.

Dans ces domaines, le Spec-Driven Development se combine naturellement avec les pratiques de Deep Modeling et de Supple Design issues du DDD tactique. Par une exploration itérative du métier, les équipes affinent progressivement le modèle, font émerger une conception souple et explicite, puis s'appuient sur cette connaissance pour guider les agents. L'automatisation ne remplace donc pas le travail de conception ; elle en amplifie les bénéfices.

Certains Supporting Domains peuvent également bénéficier de ces pratiques lorsque leur complexité le justifie. À l'inverse, les Generic Domains, dont les règles sont largement standardisées, se prêtent davantage à une automatisation poussée, voire à l'adoption de solutions existantes. Le Spec-Driven Development demeure pertinent dans tous les cas ; seul le niveau d'autonomie confié aux agents varie en fonction du caractère stratégique et de la complexité du domaine.

L'enjeu n'est donc pas d'appliquer les mêmes pratiques partout, mais d'investir au bon niveau selon la nature du domaine. À l'ère de l'IA agentique, la qualité du contexte fourni aux agents devient un avantage concurrentiel. Il est donc naturel de concentrer cet effort sur les domaines où il crée le plus de valeur.

L'humain au cœur du développement augmenté

L'intelligence artificielle ne retire pas l'humain du processus de développement ; elle en renforce les capacités. De l'exploration du domaine à la validation du code, l'humain reste au cœur d'une démarche Spec-Driven Development.

Loin d'un cycle en cascade, cette démarche est profondément itérative : à chaque cycle, la compréhension du métier, le modèle et les spécifications s'enrichissent pour guider toujours plus efficacement les agents.

Les agents automatisent l'exécution ; les équipes conservent la responsabilité de la compréhension du métier, des choix de conception, des décisions d'architecture et de la validation du logiciel. L'intelligence artificielle accélère la réalisation, mais le jugement humain demeure le garant de la pertinence du modèle, de la cohérence du système et de la création de valeur.

Le trio DDD, BDD et SDD n'est pas une solution miracle

La combinaison du Domain-Driven Design (DDD), du Behavior-Driven Development (BDD) et du Spec-Driven Development (SDD) ne constitue pas une panacée. Comme toute approche, elle peut être mal appliquée.

La sur-spécification

Une bonne spécification n'est pas forcément longue. À l'ère de l'IA, la pertinence des informations compte davantage que leur volume. Les détails d'architecture et les références peuvent être placés dans des documents dédiés afin que la spécification reste centrée sur le besoin métier.

La sous-spécification

À l'inverse, une spécification trop succincte laisse trop de place à l'interprétation. Les agents ne disposent ni d'intuition métier ni de connaissances implicites : les règles, contraintes et cas limites doivent être explicités pour produire un comportement conforme aux attentes.

La duplication des connaissances

Une règle métier ne devrait être décrite qu'à un seul endroit. Le principe de Single Source of Truth évite les divergences entre spécifications, documentation et prompts, et garantit une meilleure cohérence des implémentations.

Des spécifications figées

Une spécification perd sa valeur si elle n'évolue plus avec le logiciel. Le Spec-Driven Development repose sur des spécifications vivantes, mises à jour au même rythme que le produit et son modèle métier.

Décrire la solution plutôt que le besoin

Une spécification métier ne devrait pas imposer une implémentation. Son rôle est de décrire le problème à résoudre — comportements attendus, règles métier, contraintes et critères d'acceptation — afin de laisser à l'architecture et à l'implémentation le choix de la meilleure solution.

En définitive, la qualité d'une spécification ne dépend ni de son volume ni de son niveau de détail, mais de sa capacité à transmettre une connaissance métier claire, cohérente et exploitable, aussi bien par les équipes que par les agents d'intelligence artificielle.

Une gouvernance engagée

À l'échelle de l'entreprise, cette transformation ne peut être improvisée. L'intelligence artificielle générative ne constitue pas une simple évolution technologique : elle transforme l'organisation du travail, les modes de collaboration et les compétences attendues.

À mesure que les agents automatisent les activités d'exécution, la qualité du contexte devient le principal facteur de performance. Les entreprises doivent donc rapprocher durablement les experts métier et les équipes techniques afin de construire un patrimoine de connaissances partagé et continuellement enrichi.

Cette évolution favorise des équipes plus resserrées, centrées sur la compréhension du métier. Le Domain-Driven Design (DDD), le Behavior-Driven Development (BDD) et le Spec-Driven Development (SDD) offrent un cadre cohérent pour découvrir, structurer et faire évoluer ces connaissances afin de constituer un contexte exploitable aussi bien par les équipes que par les agents d'intelligence artificielle.

Comme toute transformation majeure, l'adoption de l'IA agentique nécessite enfin une gouvernance engagée et un accompagnement progressif pour faire évoluer les pratiques, les compétences et les modes de collaboration.

Conclusion

L'essor de l'IA agentique ne remet pas en cause les fondamentaux du génie logiciel ; il en révèle au contraire toute l'importance. À mesure que les agents automatisent l'exécution, la création de valeur se déplace vers la compréhension du métier, la qualité des modèles et la construction d'un contexte fiable sur lequel ils peuvent raisonner.

Le Domain-Driven Design, le Behavior-Driven Development et le Spec-Driven Development ne constituent pas trois approches indépendantes, mais les trois étapes d'une même chaîne de production de connaissances. Le DDD structure le métier, le BDD en explicite les comportements, et le SDD rassemble ces connaissances dans une spécification vivante exploitée par les équipes comme par les agents.

L'intelligence artificielle ne remplace donc pas l'expertise humaine ; elle en amplifie la portée. Plus une organisation construit, partage et fait évoluer son patrimoine de connaissances, plus ses agents deviennent performants. À l'ère de l'IA, ce patrimoine constitue le véritable actif stratégique et le principal moteur de l'innovation logicielle.