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

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

Construire le patrimoine de connaissances à l’ère de l’IA

Que produisent les équipes à l’ère de l’IA avant le code ?

Résumé de la première partie

Si vous avez manqué la première partie, retenez une idée essentielle : l'intelligence artificielle agentique ne signe pas la fin de l'agilité ; elle en accélère l'évolution. À mesure que les agents automatisent une part croissante du développement logiciel, la création de valeur se déplace de l'exécution vers la compréhension du métier, la qualité des décisions et l'orchestration des agents.

Les équipes deviennent plus réduites, plus expérimentées et davantage centrées sur la modélisation, l'architecture et la supervision. Leur taille dépend désormais moins du volume de code à produire que de la complexité des domaines métiers. Loin de remettre en cause l'agilité et le Domain-Driven Design*, l'IA en renforce l'importance en faisant de la connaissance métier, du contexte partagé et du jugement humain les principaux leviers de performance.*

La connaissance devient le nouvel actif stratégique du développement logiciel

L'Homme de Vitruve symbolise l'équilibre, les proportions et l'harmonie qui fondent toute conception.

Cette seconde partie explore les activités qui deviennent le cœur du développement logiciel à l'ère de l'IA générative. À mesure que les agents automatisent l'écriture du code, la création de valeur se déplace vers la compréhension du métier, la structuration des connaissances et la qualité des décisions.

Nous suivrons, au sein d'un Bounded Context, le fil conducteur qui relie le Domain-Driven Design (DDD), le Behavior-Driven Development (BDD) et le Spec-Driven Development (SDD). Loin de s'opposer, ces approches se complètent et s'inscrivent dans une même démarche. Le Domain-Driven Design construit une compréhension partagée du métier afin de maîtriser la complexité au cœur du logiciel. Le Behavior-Driven Development en explicite les comportements attendus, puis le Spec-Driven Development rassemble et consolide cette connaissance dans une spécification vivante, qui devient le principal référentiel partagé entre les équipes et les agents d'intelligence artificielle.

Cette progression montre comment la connaissance métier se transforme progressivement en un contexte explicite, partagé et exploitable, qui devient la véritable source de vérité du produit.

La nouvelle économie du développement logiciel

Unsplash - Getty Images

Chaque grande révolution technologique transforme les outils ; les plus importantes transforment aussi la manière de créer de la valeur. L'intelligence artificielle générative appartient à cette seconde catégorie. Après les langages, les frameworks, le cloud et l'intégration continue, elle franchit une étape décisive : pour la première fois, la production de code devient largement automatisable.

L'arrivée, en 2024, des premiers agents capables de concevoir des applications à partir d'instructions en langage naturel a laissé croire que le développement logiciel se résumerait bientôt à la génération de code. Les retours d'expérience sur des systèmes complexes révèlent pourtant une autre réalité : la difficulté ne disparaît pas, elle se déplace vers la compréhension du métier, l'explicitation des règles de gestion, la cohérence de l'architecture et la qualité des décisions prises en amont.

La connaissance métier comme nouvelle source de valeur

Pendant plusieurs décennies, produire du code constituait l'essentiel de l'effort de développement. En automatisant une grande partie de cette activité, l'IA déplace la création de valeur vers la connaissance : comprendre le métier, modéliser le domaine, concevoir l'architecture et construire des spécifications de qualité.

Ce changement réhabilite les fondamentaux du génie logiciel. Le Domain-Driven Design structure la connaissance métier, le Behavior-Driven Development en explicite les comportements, et le Spec-Driven Development la transforme en spécifications exploitables par les agents. La véritable révolution n'est donc pas seulement technologique : elle est organisationnelle. Les organisations les plus performantes seront celles qui sauront transformer leur compréhension du métier en un contexte fiable, partagé et exploitable par les équipes comme par les agents.

Avant l'ère agentique, le code source constituait l'aboutissement du processus de développement et son principal actif. Avec le développement assisté par l'IA, la valeur se déplace vers la connaissance du métier. Les équipes doivent désormais la découvrir, la structurer et l'enrichir afin de permettre aux agents de concevoir et de faire évoluer des logiciels de qualité, sous le jugement des humains.

Pendant trente ans, nous avons optimisé l'exécution

Pour comprendre l'impact de l'intelligence artificielle sur les organisations, il est utile de revenir sur l'évolution du développement logiciel. Depuis plusieurs décennies, toutes les grandes innovations poursuivent le même objectif : permettre aux équipes de transformer plus rapidement une idée en logiciel de qualité.

Les entreprises ont ainsi investi dans des méthodes, des outils et des pratiques toujours plus efficaces. Les langages sont devenus plus expressifs, les frameworks ont automatisé les tâches répétitives, les environnements de développement se sont enrichis, tandis que le cloud et les chaînes d'intégration et de déploiement continus ont considérablement accéléré la mise en production.

L'amélioration continue de la fabrique logicielle

Parallèlement, les organisations ont profondément transformé leur manière de travailler. Les approches agiles ont remplacé les cycles séquentiels par des itérations courtes favorisant un dialogue continu entre les équipes techniques et les métiers. Les cérémonies Scrum n'étaient pas une fin en soi : elles visaient à réduire les pertes d'information, améliorer la coordination et accélérer la prise de valeur.

Cette recherche d'efficacité dépassait le cadre de l'agilité. Le Software Craftsmanship plaçait la qualité technique au cœur du développement : le Test-Driven Development sécurisait les évolutions, le refactoring limitait la dette technique, tandis que l'intégration et le déploiement continu fluidifiait la mise en production. Toutes ces pratiques poursuivaient un même objectif : rendre le développement plus fiable et plus efficace.

Le Behavior-Driven Development s'inscrivait dans cette continuité. En favorisant les échanges entre experts métier, développeurs et testeurs, il réduisait les ambiguïtés avant même l'implémentation. Les ateliers Example Mapping, les critères d'acceptation et les scénarios Gherkin n'avaient pas pour but de produire davantage de documentation, mais d'éviter les erreurs d'interprétation qui freinent ensuite le développement.

Une organisation construite autour de l'écriture du code

La connaissance circulait principalement au travers des conversations, des ateliers, des revues de code et des cérémonies agiles. Les spécifications restaient souvent incomplètes, mais les développeurs compensaient naturellement ces imprécisions grâce à leur expérience, aux échanges avec les experts métier et à leur capacité d'interprétation. Une part importante de la connaissance demeurait ainsi implicite, portée par les interactions plutôt que formalisée.

Cette manière de travailler reposait sur une hypothèse simple : la principale difficulté du développement logiciel résidait dans la production d'un code de qualité. La performance dépendait donc de la collaboration des équipes et de leur compréhension partagée du métier.

Certains reprochent à l'IA d'imposer un effort supplémentaire pour comprendre le métier, structurer les connaissances et formaliser les règles de gestion. Cette critique est pourtant trompeuse. L'analyse et la modélisation ont toujours été indispensables ; seule une partie de cette connaissance pouvait autrefois rester implicite, les développeurs la reconstituant au fil des échanges. Les agents, eux, ne disposent pas de cette capacité d'interprétation. Ce qui pouvait rester implicite doit désormais être explicite. L'intelligence artificielle ne crée donc pas un nouveau travail : elle révèle celui qui était déjà essentiel.

La remise en cause d'une organisation historique

Dans ce modèle, le code constituait l'aboutissement d'un long processus de compréhension, de collaboration et de prise de décision. Les gains de productivité provenaient principalement de l'optimisation de l'exécution : produire, intégrer, tester et livrer plus rapidement.

Pendant des années, l'industrie du logiciel a investi dans la qualité des applications grâce aux méthodes agiles, au Software Craftsmanship, au Behavior-Driven Development (BDD) et au Domain-Driven Design (DDD). En parallèle, elle a accéléré la livraison avec la livraison continue, le DevOps et des approches organisationnelles comme Team Topologies.

L'intelligence artificielle ne remet pas en cause ces acquis ; elle en déplace la valeur. À mesure que la génération de code s'automatise, les gains de productivité proviennent désormais de la qualité des décisions qui précèdent le développement : comprendre le métier, construire un modèle partagé, expliciter les règles de gestion et fournir aux agents un contexte riche et fiable.

L'hypothèse d'un code coûteux à produire s'estompe progressivement.

Lorsque le code cesse d'être chronophage

Cette accélération a d'abord laissé croire que la modélisation, la spécification ou l'architecture deviendraient secondaires. Les premières expérimentations, fondées sur une simple conversation avec l'IA (Vibe Coding), se sont révélées très efficaces pour produire des prototypes. Mais sur des systèmes complexes, leurs limites sont rapidement apparues : incohérences fonctionnelles, architectures fragiles et dette technique.

Le problème ne vient pas des modèles, mais du contexte qui leur est fourni. Un agent ne connaît ni le métier, ni les décisions d'architecture, ni les conventions de l'équipe. Il exécute les informations dont il dispose. Si elles sont incomplètes ou ambiguës, elles le seront également dans le logiciel produit.

La performance dépend donc moins de la vitesse de génération du code que de la qualité des connaissances mises à leur disposition.

C'est pourquoi le Domain-Driven Design, le Behavior-Driven Development et le Spec-Driven Development prennent une position encore plus stratégique. Le DDD structure le métier, le BDD en explicite les comportements et le SDD rassemble ces connaissances dans une spécification vivante qui devient la source de vérité du projet. À l'ère des agents, la qualité du logiciel dépend moins de la capacité à écrire du code que de la capacité à transmettre fidèlement l'intention métier.

Pourquoi insister sur DDD, BDD et SDD ?

Unsplash - Zuzana Ruttkay

Le problème est plus profond. À chaque transmission, la connaissance métier est soumise à un phénomène que l'on pourrait qualifier d'entropie de la connaissance. Comme un signal qui se dégrade lorsqu'il traverse plusieurs relais, l'intention métier perd progressivement de sa précision à mesure qu'elle est reformulée, résumée ou interprétée.

Le besoin exprimé par l'expert métier est discuté, synthétisé en User Stories, interprété par les développeurs, puis traduit en code. À chaque étape, une partie du contexte peut disparaître : une règle implicite, une exception, une contrainte réglementaire ou une décision de conception.

Pendant longtemps, cette perte était largement compensée par l'intelligence collective des équipes, capables de retrouver le contexte au travers des échanges et de leur expérience. Les agents d'intelligence artificielle ne disposent pas de cette faculté. Ils raisonnent uniquement à partir des informations qui leur sont fournies. Chaque ambiguïté ou connaissance manquante se traduit directement par un risque de divergence entre l'intention métier et le logiciel produit.

Le Domain-Driven Design, le Behavior-Driven Development et le Spec-Driven Development répondent précisément à cet enjeu. Leur objectif n'est plus seulement de faciliter la collaboration entre les équipes, mais de préserver la fidélité de la connaissance métier tout au long de sa transformation, afin que les agents implémentent le produit tel qu'il a été conçu, et non tel qu'ils l'ont interprété.

Ce que nous apprend réellement l'étude du MIT

Les premières démonstrations d'IA générative sont spectaculaires : développement d'applications en quelques minutes, génération massive de code et automatisation d'une grande partie du cycle de développement. On pourrait en conclure que produire plus de code crée mécaniquement plus de valeur. Les travaux de Mert Demirer et de ses coauteurs au MIT montrent une réalité plus nuancée : si l'IA améliore nettement la productivité des développeurs, cette accélération ne se traduit pas automatiquement par davantage de valeur pour l'entreprise.

À mesure que la génération de code s'automatise, la création de valeur se déplace vers les décisions qui la précèdent. Une organisation peut développer deux fois plus vite… mais aussi développer deux fois plus vite une fonctionnalité inutile, une architecture inadaptée ou une dette technique. L'intelligence artificielle agit avant tout comme un amplificateur : elle accélère aussi bien les bonnes que les mauvaises décisions.

Cette observation confirme un point essentiel : la valeur d'un logiciel dépend moins de la quantité de code produite que de la qualité des connaissances et des décisions qui guident sa conception. C'est pourquoi le Domain-Driven Design, le Behavior-Driven Development et le Spec-Driven Development deviennent des leviers stratégiques. Leur rôle est de fournir aux équipes comme aux agents un contexte suffisamment riche et cohérent pour orienter efficacement leurs décisions.

La leçon de l'étude du MIT est simple : la vélocité ne crée pas la valeur ; elle amplifie la qualité des décisions qui la précèdent.

Les compétences techniques conservent toute leur importance

Mettre l'accent sur le contexte métier ne diminue en rien l'importance du contexte technique. Architecture, design, Clean Code, tests, sécurité et décisions d'architecture demeurent indispensables à la construction d'un logiciel robuste, maintenable et évolutif.

L'IA agentique ne remet pas en cause les fondamentaux du génie logiciel ; elle en renforce au contraire l'importance. Si la spécification vivante guide les décisions des agents, la qualité de l'architecture conditionne directement la fiabilité de leurs implémentations.

Une architecture modulaire, des composants faiblement couplés, des frontières explicites entre les Bounded Contexts et un code bien structuré réduisent leur espace de recherche, limitent les effets de bord et rendent leurs interventions plus sûres. Les tests automatisés vérifient le comportement attendu, mais ne garantissent ni la qualité de la conception ni l'évolutivité du système. Ils valident le résultat ; l'architecture et le design permettent plus souvent d'obtenir une solution juste dès le premier essai.

Le rôle du Clean Code évolue également. Il ne vise plus seulement à améliorer la lisibilité du code, mais à offrir aux agents un environnement compréhensible, prévisible et facilement transformable. La valeur réside avant tout dans une structure qui facilite leur raisonnement et préserve les invariants métier.

Paradoxalement, à mesure que la génération de code s'automatise, la conception et les décisions d'architecture deviennent encore plus stratégiques. Elles constituent le cadre dans lequel les agents raisonnent. La bonne nouvelle est que ce patrimoine technique est largement partagé : bonnes pratiques, architectures éprouvées et frameworks matures leur offrent un socle solide.

Le contexte technique est aujourd'hui largement partagé. Le contexte métier, lui, reste propre à chaque organisation. C'est cette connaissance, unique et difficilement reproductible, qui devient le véritable actif stratégique à l'ère de l'intelligence artificielle.

La connaissance, nouvelle matière première des agents

Le véritable défi se déplace désormais vers le métier. Contrairement aux connaissances techniques, largement accessibles, le contexte métier est propre à chaque organisation. Il résulte de son histoire, de ses processus, de ses règles de gestion, de ses arbitrages et de l'expertise accumulée au fil du temps. Cette connaissance, unique et difficilement reproductible, devient la ressource la plus précieuse pour guider les agents d'intelligence artificielle.

L'IA peut toutefois en faciliter l'exploitation. Lorsqu'une organisation dispose d'un patrimoine documentaire riche — spécifications, procédures, réglementations, décisions d'architecture ou documentation métier — les modèles de langage sont capables d'en extraire les informations pertinentes, de les synthétiser et de les restituer sous une forme directement exploitable. Ils ne créent pas cette connaissance ; ils en facilitent l'accès, la structuration et la transmission.

Ce patrimoine doit néanmoins être découvert, structuré, partagé et continuellement enrichi par les experts métier, les Product Managers, les UX Designers et les équipes de développement. Il constitue désormais l'actif stratégique des organisations et le principal levier de performance des équipes augmentées par l'intelligence artificielle.

Le contexte devient le nouvel actif stratégique

L'arrivée des assistants de développement et des premiers agents d'IA bouleverse le développement logiciel. Pour la première fois, l'écriture du code cesse progressivement d'être la ressource rare. L'expérience montre pourtant que la génération de code ne suffit pas à produire des applications complexes : lorsque le contexte métier fait défaut, les incohérences apparaissent. Contrairement aux développeurs, les agents ne compensent pas les informations manquantes ; ils exécutent le contexte qui leur est fourni.

Cette évolution fait émerger une nouvelle discipline, souvent qualifiée de Harness Engineering. Son objectif n'est plus seulement de guider les agents par des prompts, mais de leur fournir un environnement de travail complet : architecture, spécifications vivantes, décisions d'architecture, conventions, tests et connaissances métier.

La création de valeur se déplace ainsi du code vers la connaissance documentée. Comprendre le métier, construire un modèle partagé, expliciter les règles de gestion et concevoir une architecture cohérente deviennent les principaux leviers de performance. Loin de remettre en cause les fondamentaux du génie logiciel, l'IA les réhabilite. Le Domain-Driven Design, le Behavior-Driven Development et le Spec-Driven Development forment désormais une démarche continue qui transforme la connaissance métier en un patrimoine explicite, structuré et exploitable par les équipes comme par les agents.

Structurer la connaissance du métier

Unsplash - rishi

Si le contexte devient le principal actif stratégique des organisations, une question s'impose : comment construire un patrimoine de connaissances suffisamment riche, cohérent et explicite pour être compris et exploité aussi bien par les équipes que par les agents d'intelligence artificielle ? La réponse ne réside pas dans l'accumulation de documentation, mais dans la structuration des connaissances métier.

Le Domain-Driven Design comme fondation

C'est précisément l'ambition du Domain-Driven Design. Depuis l'ouvrage fondateur d'Eric Evans (2003), cette approche construit, avant toute implémentation, une compréhension commune du domaine grâce à un dialogue continu entre les experts métier et les équipes de développement. Il en résulte un modèle partagé qui formalise les concepts, les règles de gestion, les responsabilités et le langage ubiquitaire.

À l'ère de l'IA agentique, cette démarche devient essentielle. Les développeurs savent souvent compenser les imprécisions d'une spécification grâce à leur expérience ; les agents, eux, raisonnent uniquement à partir du contexte qui leur est fourni. La qualité de leurs décisions dépend donc directement de la qualité des connaissances mises à leur disposition.

EventStorming, Domain Events, ADR et les décisions techniques

Ce patrimoine s'enrichit progressivement au travers des ateliers d'EventStorming, des Domain Events, du langage ubiquitaire, des glossaires, des décisions de modélisation et des autres artefacts de conception. Ensemble, ils rendent explicite une connaissance jusque-là implicite et réduisent les ambiguïtés auxquelles les agents sont confrontés.

Cette clarification du métier éclaire également l'architecture. Les principes de conception, les choix structurants, les contraintes techniques, les interactions entre composants et l'Architecture Decision Records (ADR) gagnent à être explicités et versionnés. Cette documentation devient un cadre de référence partagé qui guide les équipes comme les agents, favorise des implémentations cohérentes et contribue à préserver une architecture modulaire, soutenable et évolutive.

Fournir aux agents une lecture explicite de l'architecture métier

À titre d'illustration, lorsqu'il s'agit de modéliser finement les processus d'un Bounded Context, l'atelier EventStorming Software Design propose une grammaire qui fait émerger collectivement l'architecture de la solution. En affinant progressivement les discussions autour des Commandes, des Domain Events, des Agrégats, des Policies, des Read Models et des systèmes externes, les participants mettent en évidence les forces qui structurent le logiciel. Les composants s'organisent alors naturellement autour des comportements métier qu'ils doivent garantir et des invariants qu'ils doivent préserver.

© Source: Introducing EventStorming – Alberto Brandolini

L'agrégat (jaune pale), reçoit des commandes, applique les règles métier qui garantissent ses invariants, puis émet un ou plusieurs Domain Events décrivant les faits métier qui viennent de se produire.

L'agrégat occupe une place centrale dans cette modélisation. Il reçoit les commandes, applique les règles métier qui garantissent les invariants, afin d’émettre un ou plusieurs Domain Events décrivant les faits métier qui viennent de se produire.

À l'issue d'un atelier EventStorming Software Design, il devient pertinent de formaliser explicitement la racine de l'agrégat, les entités et objets de valeur qui le composent, leurs responsabilités, ainsi que les commandes, événements et politiques associés. L'atelier Class-Responsibility-Collaboration (CRC) Cards peut alors être utilisé pour explorer collectivement la structure de l'agrégat.

Ces décisions ne constituent plus une simple documentation : elles deviennent des connaissances directement exploitables par les agents d'intelligence artificielle. Les frontières des agrégats, les invariants métier et les responsabilités ne sont plus déduits du code ; ils guident explicitement les choix de conception des agents.

Dans ce contexte, l'architecture hexagonale prend tout son sens. En isolant le cœur métier des préoccupations techniques grâce aux ports et aux adaptateurs, elle préserve les invariants métier, réduit les dépendances technologiques et fournit aux agents un modèle autonome, stable et facile à faire évoluer.

Le Domain-Driven Design ne se limite donc plus à guider la conception d'un logiciel. Il organise et capitalise les connaissances afin de produire un contexte riche, cohérent et durable, partagé par les équipes humaines comme par les agents d'intelligence artificielle. Plus ces derniers gagnent en autonomie, plus ils dépendent d'un modèle métier explicite et stable.

Le DDD répond toutefois principalement à une première question : que représente le métier ? Il identifie les concepts, leurs responsabilités et leurs relations. Reste alors à décrire précisément comment le système doit se comporter face aux différentes situations métier. C'est précisément le rôle du Behavior-Driven Development.

Conclusion

L'émergence de l'intelligence artificielle agentique ne marque pas la fin du génie logiciel ; elle en déplace le centre de gravité. À mesure que les agents automatisent la génération de code, la création de valeur se concentre sur ce qui la précède : comprendre le métier, structurer les connaissances, prendre les bonnes décisions et construire un contexte capable de guider les agents.

Cette évolution ne rend pas obsolètes les pratiques qui ont façonné le développement logiciel moderne. Au contraire, les méthodes agiles, le Domain-Driven Design, le Behavior-Driven Development, l'architecture logicielle ou encore le Software Craftsmanship constituent plus que jamais les fondations sur lesquelles repose la qualité des logiciels produits par les agents.

Le véritable enjeu n'est donc plus seulement de produire du code plus rapidement, mais de construire un patrimoine de connaissances explicite, cohérent et continuellement enrichi. Les agents ne remplacent pas cette connaissance ; ils en amplifient la valeur.

Reste alors une question essentielle : comment construire ce patrimoine de connaissances, le faire évoluer et le rendre directement exploitable par les équipes comme par les agents ? C'est précisément l'objet de la suite de cette série, qui montrera comment le Domain-Driven Design, le Behavior-Driven Development et le Spec-Driven Development s'articulent pour transformer la connaissance métier en un véritable actif stratégique.