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

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

La valeur métier dimensionne les équipes

Une question anime aujourd'hui toutes les directions informatiques : comment l'IA va-t-elle transformer l'organisation des équipes de développement ?

Afin de faciliter la lecture de ces articles, nous proposons ci-dessous quelques définitions des principaux concepts issus du Domain-Driven Design (DDD). Elles permettront de clarifier le vocabulaire utilisé dans les chapitres qui suivent :

• Sous domaine métier : Un sous-domaine métier est une partie cohérente logique d'un domaine métier qui regroupe un ensemble de capacités, de règles de gestion et de connaissances concourant à un même objectif métier. Par exemple les périmètres de facturation, réservation, billetterie sont des sous domaines appartement à la gestion des spectacles pour un théâtre.

Chaque sous domaine métier, contient un ou plusieurs Bounded Contexts.

• Bounded Context : un Bounded Context est une frontière explicite, à la fois organisationnelle et technique, à l'intérieur de laquelle un modèle métier, un langage ubiquitaire et un ensemble de règles de gestion sont cohérents et partagés par une même équipe autonome. Cette cohérence se reflète directement dans le code, qui constitue l'implémentation fidèle du modèle métier.

Par exemple, le sous-domaine métier Réservation d'un théâtre peut être découpé en deux Bounded Contexts distincts : Suggestion des places, chargé de proposer les meilleures places selon différents critères, et Réservation des places, responsable de la réservation, du blocage et de la confirmation des sièges. Bien qu'ils appartiennent au même sous-domaine métier, ces deux Bounded Contexts disposent chacun de leur propre modèle métier et peuvent évoluer de manière indépendante.

Un problème difficile à résoudre

Depuis l'arrivée de l'IA agentique dans les équipes de développement, de nombreuses interrogations émergent quant à l'évolution des organisations de travail. Les modèles d'équipe qui se sont imposés au cours des vingt dernières années, largement façonnés par les approches agiles, sont désormais remis en question par la capacité des agents à automatiser une part croissante des activités d'analyse, de conception, de développement et de validation.

L'année 2025 marque ainsi l'apparition des premières organisations expérimentales entièrement conçues autour de l'IA agentique. Dans ces structures, les équipes sont volontairement très réduites et un même expert peut être amené à assumer plusieurs responsabilités : compréhension du métier, architecture, développement, qualité et exploitation. Les progrès spectaculaires des modèles d'IA, combinés à l'émergence du Spec-Driven Development (SDD), rendent désormais cette polyvalence structurée réaliste. En prenant en charge une grande partie des activités d'exécution, les agents permettent à un expert senior d'intervenir efficacement sur plusieurs disciplines tout en conservant une vision d'ensemble du produit.

L'année 2026 confirme cette trajectoire. Les agents de développement franchissent un nouveau cap en matière de raisonnement, d'autonomie et de fiabilité. Une pratique émerge alors avec succès : la réinvention d'applications existantes à partir de leur rétro-documentation. Après avoir reconstitué le modèle métier, les règles de gestion et l'architecture d'un système existant, les agents sont désormais capables de proposer une nouvelle implémentation cohérente, ouvrant la voie à des stratégies de modernisation jusqu'alors difficilement envisageables.

Chez OCTO, cette polyvalence est souvent illustrée par la métaphore « squad râteau ». Le manche du râteau représente le domaine d'expertise principal de chaque membre de l'équipe, tandis que les dents symbolisent les compétences secondaires qu'il est capable de mobiliser. L'IA agentique renforce précisément cette capacité : elle ne transforme pas un spécialiste en expert universel, mais lui permet d'élargir son champ d'action en s'appuyant sur les agents pour exécuter les tâches les plus opérationnelles. Chaque expert conserve ainsi une spécialité forte tout en développant une polyvalence suffisante pour collaborer efficacement avec les autres disciplines de l'équipe.

Cette concentration des responsabilités n'est toutefois pas sans contrepartie. Si elle renforce l'autonomie des équipes et réduit les coûts de coordination, elle accroît également la charge cognitive. Passer en permanence des problématiques métier aux enjeux d'architecture, de développement, de qualité ou d'exploitation exige une expertise approfondie, une grande discipline et une forte capacité à changer rapidement de perspective. Sans une répartition équilibrée des responsabilités, cette surcharge mentale peut rapidement devenir un facteur d'épuisement, voire conduire au burnout.

À long terme, un tel fonctionnement n'est pas soutenable. Ces premières expérimentations ont néanmoins joué un rôle déterminant. Elles ont permis d'explorer de nouvelles formes de collaboration entre les experts et les agents IA, d'en mesurer les bénéfices comme les limites, et de mieux comprendre les conditions nécessaires à l'émergence d'organisations réellement pérennes.

L'IA agentique a-t-elle sonné le glas de l'agilité ?

Certains rôles ont été progressivement effacés par l'intelligence artificielle

On remarquera également que certains rôles traditionnellement associés aux organisations Scrum, notamment ceux de Product Owner et de Scrum Master, deviennent moins visibles dans les équipes fortement augmentées par l'IA. L'accélération des cycles de développement, la capacité des agents à produire des incréments en quelques minutes et la réduction des délais de feedback diminuent le besoin de certaines cérémonies et de mécanismes de coordination formels.

Dans des équipes plus restreintes, où les échanges sont directs et les circuits de décision particulièrement courts, les responsabilités ne disparaissent pas ; elles se distribuent. Le Product Manager et l’UX Designer, portent la vision du produit, les objectifs métier et les priorités stratégiques, tandis que les membres de l'équipe partagent davantage les responsabilités de planification, de coordination et d'amélioration continue avec l'appui des agents spécialisés.

Cette évolution ne remet donc pas en cause les fonctions d’expert métier (Product Manager) ou de facilitation. Elle conduit plutôt à leur intégration au sein d'une organisation plus légère, où une partie des activités de coordination est automatisée et où les décisions peuvent être prises beaucoup plus rapidement. L'IA agentique ne supprime pas la nécessité de collaborer ; elle réduit le coût de cette collaboration et permet aux équipes de consacrer davantage de temps aux arbitrages métier et aux décisions à forte valeur ajoutée.

Product Manager vs Product Owner

L'émergence de l'IA agentique conduit de nombreuses organisations à s'interroger sur la pertinence de certains rôles historiques issus des méthodes agiles. Parmi eux, celui de Product Owner (PO) est particulièrement questionné. Il ne s'agit pas de considérer que le rôle disparaît, mais plutôt de constater que les responsabilités qu'il portait évoluent profondément. Dans ce nouveau contexte, le Product Manager (PM) apparaît comme un rôle plus adapté aux organisations de développement fortement augmentées par l'IA.

La première raison tient au déplacement de la valeur. Pendant de nombreuses années, une part importante du travail consistait à transformer des besoins métier en backlog, à rédiger des User Stories, à préparer les critères d'acceptation et à répondre aux questions des développeurs.

Les agents IA capables de générer des spécifications, de proposer des scénarios de tests, de produire du code et même d'affiner automatiquement un backlog, ces activités deviennent progressivement automatisables. La valeur ne réside donc plus dans la gestion du backlog, mais dans la capacité à identifier les bons problèmes à résoudre.

C'est précisément le cœur du métier du Product Manager. Son rôle consiste à comprendre le marché, les utilisateurs, les enjeux économiques et les objectifs stratégiques de l'entreprise afin de définir une vision produit cohérente. Là où le Product Owner est historiquement centré sur le quoi produire, le Product Manager se concentre avant tout sur le pourquoi. Or, à mesure que l'exécution s'accélère grâce à l'IA, la qualité des décisions devient bien plus déterminante que la vitesse de production.

Cette évolution renforce également la nécessité d'une proximité permanente entre les équipes de développement et les experts métier. Dans une organisation agentique, les échanges ne portent plus uniquement sur la priorisation d'un backlog, mais sur la compréhension du domaine, la modélisation des règles métier, l'identification des opportunités et la validation des hypothèses. Le Product Manager devient alors un partenaire quotidien de l'équipe, capable d'alimenter en continu le contexte métier dont les agents ont besoin pour produire des résultats pertinents.

Les approches telles que le Domain-Driven Design renforcent naturellement cette évolution. Plus les agents gagnent en autonomie, plus la qualité des décisions qu'ils prennent dépend de la richesse du modèle métier, du langage ubiquitaire et des connaissances qui leur sont transmises. Le Product Manager contribue directement à cette construction en collaborant avec les experts du domaine et les équipes techniques afin de faire émerger une compréhension partagée du métier.

À l'inverse, le rôle de Product Owner est intimement lié au cadre Scrum. Il répondait à un besoin d'organisation où la coordination entre les parties prenantes, les développeurs et le backlog constituait un enjeu majeur. Dans des équipes augmentées plus réduites, composées d'experts seniors capables d'orchestrer plusieurs agents, les circuits de décision deviennent beaucoup plus courts. Les responsabilités de raffinement, de planification et de clarification sont progressivement partagées entre les membres de l'équipe et largement assistées par l'IA.

Est-ce la fin des méthodes agiles ?

Probablement pas. En revanche, il est fort probable que nous assistions à la fin de certaines pratiques agiles telles qu'elles ont été conçues au début des années 2000.

Les méthodes agiles sont nées dans un contexte où le développement logiciel demeurait largement manuel et où les équipes avaient besoin de synchroniser régulièrement leurs travaux. Les itérations de deux ou trois semaines répondaient à cette contrainte : elles permettaient de limiter les risques, de recueillir rapidement les retours des utilisateurs et de maintenir un rythme de livraison soutenable.

La nouvelle équation pour composer une équipe

L'IA agentique modifie profondément cette équation. Une équipe augmentée est désormais capable de concevoir, produire, tester, documenter et faire évoluer un logiciel à une vitesse sans précédent. Les tâches autrefois réparties entre plusieurs développeurs peuvent être exécutées en parallèle par plusieurs agents spécialisés, sous la supervision d'un nombre réduit d'experts. Les premiers retours d'expérience montrent qu'il devient possible d'accélérer significativement les cycles de livraison tout en mobilisant des équipes plus restreintes.

Les expérimentations menées au cours des derniers mois ont fait émerger de nouveaux modes d'orchestration des agents. L'été 2025 constitue un véritable point d'inflexion, marqué par la convergence de deux avancées majeures : l'apparition du Spec Driven Development (SDD) et les progrès rapides des modèles d'IA. Des modèles comme Sonnet ont notamment permis à des outils tels que Claude Code, GitHub Copilot ou Cursor de suivre des raisonnements complexes sur la durée, en conservant un contexte riche et cohérent sans se perdre au fil des interactions. Cette évolution a profondément transformé la manière de concevoir des systèmes multi-agents et ouvert la voie à des formes de collaboration beaucoup plus sophistiquées entre agents spécialisés.

Cette combinaison a constitué une étape déterminante dans l'apparition des premières architectures agentiques. En proposant un cadre structuré pour concevoir, coordonner et faire collaborer plusieurs agents spécialisés autour d'une même spécification, le SDD a ouvert la voie à de nouvelles formes d'organisation, dans lesquelles des agents autonomes coopèrent sous la supervision d'un orchestrateur humain.

Les développeurs les plus curieux se sont rapidement emparés de cet outil pour expérimenter de nouvelles compositions d'agents, explorer différents modèles d'orchestration et concevoir des systèmes capables de répartir les tâches entre plusieurs agents autonomes.

Réinvention Agentique

L'un des exemples les plus marquants concerne la modernisation des applications existantes. Longtemps perçue comme une activité consistant à faire évoluer progressivement un patrimoine logiciel, elle tend désormais à devenir un véritable processus de réinvention. Après une phase de rétro-documentation approfondie, destinée à reconstruire le contexte métier, les règles de gestion, les décisions d'architecture et les contraintes techniques, les agents sont capables de repartir de cette connaissance pour concevoir et développer une nouvelle application. Il ne s'agit plus simplement de migrer ou de refactorer le code existant, mais de reconstruire le système sur des bases plus saines, en s'appuyant sur une compréhension approfondie du domaine métier plutôt que sur l'implémentation historique.

Parallélisation des agents

La parallélisation des agents s'appuient sur la combinaison de plusieurs pratiques complémentaires : les Git Worktrees, qui permettent à plusieurs agents de travailler simultanément sur une même base de code, les capacités de planification des modèles les plus avancés, ainsi qu'une structuration rigoureuse du contexte sous la forme d'une arborescence de fichiers Markdown. Cette dernière rassemble l'ensemble des connaissances nécessaires au développement : raison d'être du produit, règles métier, décisions d'architecture, spécifications fonctionnelles, conventions de développement, compétences spécialisées des agents et bonnes pratiques d'ingénierie.

Un développeur orchestre plusieurs agents d'IA travaillant en parallèle sur différentes fonctionnalités d'un même produit.

Cette organisation documentaire dépasse largement le rôle d'une simple base de connaissances. Elle constitue un véritable contexte de travail sémantique, conçu pour être exploité efficacement par les agents et leurs sous-agents. Chaque fichier encapsule une partie des connaissances nécessaires à une compétence ou à une responsabilité particulière, permettant aux agents de retrouver rapidement le contexte utile à leur mission sans avoir à parcourir l'ensemble de la documentation.

Cette approche améliore sensiblement la qualité des productions, renforce la cohérence des décisions et favorise une exécution fortement parallélisée, dans laquelle plusieurs agents spécialisés collaborent simultanément tout en partageant une compréhension commune du produit, de son architecture et de son domaine métier. Plus qu'une simple documentation, cette structuration constitue une véritable architecture de contexte (Context Engineering), devenue l'un des piliers des organisations agentiques les plus performantes.

Cette accélération radicale appelle une révision des organisations

Dans ce contexte, conserver les mêmes organisations, les mêmes cérémonies et les mêmes cadences de travail simplement parce qu'elles ont fait leurs preuves par le passé n'aurait guère de sens. Les organisations devront probablement repenser leurs modes de fonctionnement, leurs rôles, leurs mécanismes de décision et leurs boucles de feedback afin de tirer pleinement parti de cette nouvelle capacité d'exécution.

L'agilité ne disparaît donc pas. Ses principes fondateurs, collaboration, adaptation au changement, livraison fréquente de valeur et proximité avec les utilisateurs, demeurent plus pertinents que jamais. En revanche, les cadres de mise en œuvre évolueront inévitablement. L'enjeu ne sera plus d'organiser le travail d'une dizaine de développeurs, mais de permettre à quelques experts de piloter efficacement des dizaines d'agents spécialisés. Cette transition pourrait constituer l'une des plus profondes transformations de l'ingénierie logicielle depuis la naissance des méthodes agiles elles-mêmes.

Les premiers retours d'expérience montrent qu'une condition de succès essentielle des organisations fondées sur l'IA agentique réside dans le renforcement de la proximité entre les équipes de développement, les UX Designers et les Product Managers. Cette collaboration étroite entretient un dialogue permanent autour des besoins des utilisateurs, des enjeux métier et des priorités du produit.

À mesure que les agents accélèrent la production logicielle, la valeur se déplace vers la qualité des décisions plutôt que vers leur exécution. Cette proximité devient alors indispensable pour garantir que les arbitrages réalisés par les équipes et les agents demeurent alignés avec la vision du produit, l'expérience utilisateur et les objectifs stratégiques de l'entreprise. Plus les capacités d'exécution sont automatisées, plus la compréhension du métier, l'empathie envers les utilisateurs et la qualité des interactions humaines deviennent les véritables facteurs de différenciation.

Dans un périmètre métier, l’équipe produit collabore étroitement avec trois équipes augmentées, chacune responsable de son propre Bounded Context

On peut ainsi imaginer plusieurs équipes augmentées par l’IA, intervenant au sein d'un même sous-domaine métier. Par exemple, trois équipes distinctes peuvent collaborer sur un même périmètre fonctionnel, chacune étant responsable de son propre problème métier, matérialisé par un Bounded Context. Cette organisation permet à chaque équipe de développer une expertise approfondie de son domaine, de faire évoluer son modèle en toute autonomie et d'exploiter pleinement les capacités offertes par les agents, tout en préservant des frontières fonctionnelles claires entre les différents contextes.

Cependant, avec l'accélération apportée par l'IA agentique, il est probable que les équipes puissent prendre en charge plusieurs Bounded Contexts. Le facteur limitant ne sera plus la capacité de développement, mais la charge cognitive nécessaire pour comprendre, faire vivre et faire évoluer plusieurs modèles métiers et leurs langages ubiquitaires. C'est désormais cette capacité de compréhension qui dimensionnera les équipes, bien davantage que le volume de code à produire.

Une telle organisation favorise le passage à l'échelle sans diluer la connaissance métier. Chaque équipe construit, enrichit et fait évoluer son propre modèle tout en restant concentrée sur son contexte. Les interactions entre équipes se limitent aux contrats établis entre les Bounded Contexts, ce qui réduit les interférences, diminue la charge de coordination et renforce l'autonomie des équipes. L'IA agentique amplifie encore cette dynamique en permettant à chaque équipe de faire progresser simultanément plusieurs chantiers, sans remettre en cause la cohérence globale du système.

Pourquoi constituer une équipe produit avec le PM et l’UX Designer

Dans une organisation agentique, la proximité entre le Product Manager (PM) et le UX Designer devient un facteur déterminant de succès. À mesure que les agents d'IA prennent en charge une part croissante des activités de développement, la valeur se déplace vers la compréhension des besoins, la qualité des décisions et la conception de produits réellement utiles. Le PM et l'UX constituent ainsi une véritable équipe produit, responsable de transformer les attentes des utilisateurs et les objectifs stratégiques de l'entreprise en une vision claire et partagée.

Le Product Manager apporte la connaissance du marché, des enjeux économiques et des priorités métier. Il identifie les problèmes qui méritent d'être résolus, arbitre les investissements et porte la vision à long terme du produit. De son côté, l'UX Designer s'attache à comprendre les usages réels, les parcours utilisateurs, les irritants et les comportements. Ensemble, ils confrontent en permanence la valeur métier à la valeur d'usage afin de s'assurer que les fonctionnalités développées répondent à un besoin concret.

Cette collaboration est d'autant plus importante que les équipes de développement disposent désormais d'une capacité d'exécution sans précédent grâce aux agents d'IA. Une mauvaise décision produit peut être implémentée en quelques heures au lieu de plusieurs semaines. Il devient donc essentiel de valider les hypothèses, d'expérimenter rapidement et de maintenir un dialogue permanent avec les utilisateurs avant de lancer les agents dans la production de code.

Le PM et l'UX Designer ne doivent donc pas être considérés comme des fonctions externes venant ponctuellement alimenter les équipes. Ils en deviennent des partenaires permanents.

La proximité du Product Manager et de l'UX Designer avec les équipes augmentées constitue un facteur clé de réussite. Elle permet d'ajuster continuellement la vision du produit, de confronter les décisions aux réalités du métier, d'enrichir le modèle métier et de garantir que la vitesse d'exécution apportée par l'IA se transforme en valeur durable pour les utilisateurs comme pour l'entreprise.

Calibrer une équipe par la valeur

Pendant de nombreuses années, la règle de la two-pizza team, popularisée par le fondateur d'Amazon, a constitué une référence pour dimensionner les équipes. Le principe était simple : une équipe ne devait pas être plus grande que ce que deux pizzas pouvaient nourrir, soit généralement entre six et dix personnes. Cette approche visait à limiter les coûts de coordination, à accélérer la prise de décision et à renforcer l'autonomie des équipes.

À l'ère de l'IA agentique, ce repère mérite d'être profondément réévalué. Lorsqu'une équipe de deux à quatre experts est capable d'orchestrer simultanément plusieurs dizaines d'agents spécialisés, la capacité de production n'est plus directement proportionnelle au nombre de personnes. Le véritable facteur limitant n'est plus la quantité de développeurs, mais la qualité des décisions, la maîtrise du domaine métier et la capacité à piloter efficacement les agents.

La fin des méthodes empiriques ou orienté pizzas

Dès lors, comment déterminer la taille optimale d'une équipe ? Il n'existe évidemment aucune formule universelle. Le choix reposera toujours, en partie, sur une appréciation pragmatique, un « doigt mouillé » éclairé par l'expérience. L'objectif est de constituer une équipe suffisamment réduite pour préserver une communication fluide et une prise de décision rapide, tout en réunissant les compétences indispensables à la réussite du produit.

Si l'on décide d'augmenter le nombre de personnes, cette décision doit répondre à une nécessité clairement identifiée. La complexité du domaine métier constitue un premier facteur d'explication : certains secteurs, comme la finance de marché, la santé ou les télécommunications, mobilisent des connaissances tellement spécialisées qu'elles justifient la présence d'experts supplémentaires.

Un second facteur est le niveau de différenciation recherché sur le marché. Plus une entreprise fait de son logiciel un levier stratégique de différenciation face à ses concurrents, plus elle investira dans l'expertise, l'innovation et la capacité d'exploration. À l'inverse, lorsqu'un logiciel répond principalement à des besoins standardisés, une équipe plus réduite, augmentée par l'IA, peut souvent produire la valeur attendue avec une efficacité remarquable.

À l'avenir, la taille d'une équipe ne devrait donc plus être déterminée par une règle empirique comme celle de la two-pizza team, mais par un équilibre entre la complexité du domaine, l'ambition stratégique du produit et la capacité des experts à orchestrer efficacement leurs agents.

Le DDD à la rescousse

Pour les praticiens du Domain-Driven Design, cette réflexion trouve un écho particulier dans un outil de conception stratégique : le Core Domain Chart, proposé par Nick Tune.

Cet outil permet de classifier stratégiquement les sous-domaines métier en trois catégories : les sous-domaines génériques (Generic Domains), les sous-domaines de support (Supporting Domains) et les sous-domaine cœur (Core Domain). Le positionnement de chaque sous-domaine sur cette grille guide les décisions d'organisation, d'investissement et de conception, en mettant l'effort là où il crée le plus de valeur.

Cette classification guide traditionnellement les décisions d'investissement, d'organisation des équipes et de choix d'architecture.

Core Domain Chart à l’ère revisité à l’ère de l’IA

En faisant un pas de côté, il est possible d'étendre ce raisonnement au dimensionnement des équipes augmentées. Plutôt que de définir une taille unique, celle-ci peut être adaptée à la nature du sous-domaine métier pris en charge. Un Core Domain, fortement différenciant et créateur de valeur, justifie la présence d'un plus grand nombre d'experts afin d'exploiter pleinement les capacités offertes par les agents d'IA et de traiter une complexité métier élevée. À l'inverse, un Supporting Domain ou un Generic Domain, où les enjeux concurrentiels sont plus limités, peut être confié à une équipe plus restreinte, s'appuyant davantage sur l'automatisation tout en conservant la maîtrise des décisions essentielles.

Le Core Domain Chart devient ainsi bien plus qu'un outil de priorisation des investissements. À l'ère de l'IA agentique, il peut également servir de guide pour calibrer la taille des équipes, répartir les expertises humaines et déterminer où concentrer les compétences les plus rares. La structure des équipes n'est alors plus définie par une règle générique applicable à tous, mais directement par la valeur stratégique du domaine qu'elles développent.

Le core domaine chart revisité à l’ère de l’IA

Dimensionnement des équipes repose sur deux axes :complexité métier & différenciation métier

Concrètement, si une équipe intervient sur un sous-domaine cœur, représenté par l'équipe C dans notre schéma, caractérisé par une forte complexité métier et un impact déterminant sur le positionnement concurrentiel de l'entreprise, il sera généralement pertinent de distinguer clairement les rôles et de réunir des profils de forte séniorité. Le rôle d'architecte, celui d'expert qualité (QA), celui de développeur senior ou encore celui de spécialiste DevOps pourront ainsi être incarnés par des personnes différentes. Chacune apportera une expertise indispensable à la maîtrise du sous-domaine cœur, à la prise de décision et à l'orchestration des agents d'IA.

À l'inverse, lorsqu'une équipe intervient sur un sous-domaine de support, représenté par l'équipe B, où la complexité métier est plus modérée et l'enjeu stratégique moins différenciant, il est envisageable de constituer une équipe plus réduite. La séniorité reste néanmoins importante afin de garantir une bonne compréhension des règles métier, de maintenir la qualité du logiciel et de superviser efficacement les agents. L'objectif n'est pas de diminuer le niveau d'expertise, mais d'adapter les moyens à la valeur stratégique du domaine.

Enfin, pour un sous-domaine générique, illustré par l'équipe A, où les fonctionnalités reposent principalement sur des opérations de type CRUD et où le potentiel de différenciation est limité, plusieurs responsabilités pourront être regroupées entre les mains d'une même personne. Les agents d'IA prendront alors en charge une part importante des activités de conception, de développement, de test et de documentation, permettant à une équipe restreinte de délivrer efficacement la valeur attendue.

Ce n'est donc pas l'IA qui détermine la taille des équipes, mais la valeur stratégique et la complexité du domaine métier.

Le dimensionnement des équipes devient ainsi une décision stratégique. Il ne dépend plus uniquement de la charge de travail, mais de la combinaison de deux axes : la complexité du domaine métier et son niveau de différenciation stratégique. Ces deux critères permettent de calibrer simultanément le nombre de personnes, leur niveau de séniorité et la répartition des expertises au sein de chaque équipe.

Chaque type de sous-domaine métier appelle une composition d'équipe spécifique, tant en termes de taille que de niveau de séniorité. Le calibrage des équipes varie selon la nature du sous-domaine métier.

• Le sous-domaine cœur (Core Domain) exige un niveau d'excellence sans compromis. Sa forte complexité métier et son caractère hautement stratégique justifient une équipe composée de quatre experts expérimentés, capables de prendre les décisions les plus structurantes et d'orchestrer efficacement les agents d'IA.
• Le sous-domaine support présente une complexité intermédiaire. Une équipe de trois personnes, composée de deux profils expérimentés et d'un profil junior, permet de concilier maîtrise du domaine, montée en compétences et efficacité opérationnelle.
• Le sous-domaine générique repose généralement sur des règles métier plus simples et un faible potentiel de différenciation. Une équipe de deux personnes, composée d'un profil expérimenté et d'un profil junior, est généralement suffisante pour répondre aux besoins tout en bénéficiant de l'appui des agents d'IA.

Les équipes sont généralement constituées autour de cinq expertises complémentaires : architecture, développement, qualité (QA), DevSecOps et monitoring / observabilité.

Comme nous l'avons déjà expliqué, une équipe peut tout à fait prendre en charge plusieurs Bounded Contexts, dès lors que sa charge cognitive demeure maîtrisable.

Bounded Context et équipes

Le concept de Bounded Context ne se limite pas à délimiter un modèle métier ; il constitue également un principe d'organisation des équipes. Chaque équipe est responsable d'un ou plusieurs Bounded Contexts et approfondit les connaissances du ou des problèmes métiers dont elle a la charge. Le Domain-Driven Design n'impose d'ailleurs pas une correspondance stricte entre une équipe et un unique Bounded Context. Une même équipe peut en piloter plusieurs, à condition que la charge cognitive demeure soutenable et que la cohérence du modèle soit préservée.

En revanche, il paraît peu réaliste qu'une équipe intervenant sur un Core Domain puisse assumer simultanément plusieurs Bounded Contexts. La richesse du métier, la complexité des règles de gestion et les enjeux stratégiques exigent généralement une concentration maximale sur un périmètre restreint. À l'inverse, les équipes évoluant sur des sous-domaines support ou génériques, où les modèles sont souvent plus simples et moins différenciants, pourront plus facilement prendre en charge plusieurs Bounded Contexts sans compromettre leur efficacité.

Le dimensionnement d'une équipe ne dépend donc plus uniquement du volume de travail à réaliser. Il devient une décision stratégique fondée sur la valeur du domaine, sa complexité, les risques associés, mais également sur le niveau d'expertise humaine nécessaire pour guider, superviser et contrôler le travail des agents d'IA. L'organisation des équipes apparaît ainsi comme le prolongement naturel de la stratégie métier de l'entreprise, où la répartition des responsabilités s'aligne sur la valeur et la complexité de chaque domaine.

Conclusion

L'émergence de l'IA agentique ne marque pas la fin des organisations de développement; elle ouvre une nouvelle étape de leur évolution. À mesure que les agents prennent en charge une part croissante des activités d'exécution, la création de valeur se déplace vers la compréhension du métier, la qualité des décisions et la capacité à orchestrer efficacement des collectifs d'agents spécialisés.

Cette transformation conduit à repenser la topologie des équipes. Leur composition ne doit plus être déterminée uniquement par la charge de travail, mais être alignée sur la complexité du domaine métier et son caractère stratégique. L'objectif est de calibrer au plus juste la taille des équipes ainsi que leur niveau de séniorité, depuis des équipes très expérimentées pour les domaines les plus critiques jusqu'à des équipes plus légères lorsque les enjeux le permettent.

Les organisations les plus performantes seront celles qui sauront rapprocher durablement les équipes de développement, les Product Managers et les UX Designers afin de construire un contexte riche, partagé et continuellement enrichi.

L'agilité ne disparaît donc pas ; elle se transforme. Les principes qui ont fait son succès, collaboration, adaptation, proximité avec les utilisateurs et livraison continue de valeur, demeurent essentiels. En revanche, les rôles, les modes de coordination et les mécanismes d'organisation évoluent pour tirer pleinement parti des capacités offertes par l'IA agentique. Plus que jamais, la performance d'une équipe repose moins sur sa capacité à produire du code que sur sa capacité à prendre les bonnes décisions et à transmettre aux agents les connaissances qui feront toute la différence.

À mesure que l'exécution s'automatise, la valeur se déplace vers la compréhension du métier, la qualité du contexte transmis aux agents, le jugement humain et la prise de décision. L'ingénierie logicielle devient ainsi avant tout une discipline de collaboration, où l'expertise métier et la qualité des interactions constituent les principaux leviers pour placer durablement la création de valeur au cœur des organisations agentiques.