I. Introduction Stratégique : L’Impératif de l’Alignement Structurel

L’Inconfortable Vérité : Lorsque la Structure d’Équipe Dévore l’Architecture

Le monde du développement logiciel est souvent confronté à un phénomène d’une frustrante régularité : une fonctionnalité simple et rapide se transforme en un long et coûteux « relai à trois équipes » (three-team relay), exigeant des handoffs constants, allongeant les standups qui se muent en théâtre de statut, et multipliant les dépendances . Ce coût caché des dépendances ralentit non seulement la livraison, mais déstabilise également les feuilles de route et pousse les équipes à adopter des frameworks de plus en plus lourds pour tenter de gérer une complexité qui est, fondamentalement, organisationnelle.

La vérité fondamentale est que la frontière entre les équipes modèle inéluctablement la frontière du logiciel. La structure de l’organisation a une incidence structurelle sur l’architecture, un phénomène connu sous le nom de Loi de Conway.¹ L’organisation tend à gagner ce combat. Par conséquent, la question cruciale à laquelle font face les responsables technologiques n’est pas de choisir entre une architecture en microservices ou un monolithe, mais plutôt : « Comment organiser nos équipes pour que l’architecture que nous désirons puisse émerger naturellement et sans friction? ».

Le problème central n’est pas imputable aux individus ou aux rituels Agile, mais à la direction des dépendances. Lorsque l’optimisation se fait autour de la propriété technique plutôt que de la manière dont la valeur client circule (le flow), les dépendances prennent le contrôle du processus de livraison. Ce rapport propose une approche stratégique, articulée autour du concept de Flux de Valeur et du cadre Team Topologies, qui permet de concevoir l’organisation pour éliminer les dépendances structurelles, rendant les processus de coordination lourds superflus.

II. Le Fondement Théorique : De la Loi de Conway à l’Ingénierie Organisationnelle

Déconstruction de la Loi de Conway : Une Contrainte Système et Communicationnelle

Énoncée initialement par Melvin Conway en 1967, la loi stipule qu’« une organisation qui conçoit un système concevra un système dont la structure est une copie de la structure de communication de l’organisation ».¹ Cette loi est plus qu’une simple observation ; elle constitue une contrainte système.

Le principe s’applique de manière vaste, englobant non seulement les applications logicielles elles-mêmes, mais tous les « systèmes », y compris les pipelines intégrés de livraison et de déploiement, ce qui la rend intrinsèquement liée aux méthodologies DevOps.² Lorsqu’une organisation produit une architecture jugée bancale, ou un code structurellement chaotique, cela révèle souvent un problème de communication profonde et collective entre toutes les parties prenantes – développeurs, managers, clients, chefs de projet – plutôt qu’un simple défaut de compétence technique.¹

La reconnaissance que la structure du code reflète la structure des communications d’équipe déplace la responsabilité architecturale vers le management. Le management et l’organisation des équipes deviennent des décisions d’ingénierie critiques. Si l’on ne peut pas simplement blâmer les développeurs pour un système défaillant, il est impératif de restructurer l’environnement de communication pour faciliter le travail et permettre une architecture saine. C’est ici qu’intervient l’alignement délibéré.

L’Alignement sur le Flux de Valeur (Value Stream Management – VSM)

Pour contrer les effets négatifs de la Loi de Conway, il est nécessaire d’optimiser l’organisation pour le flux de valeur. Le Value Stream Management (VSM) est la pratique métier qui consiste à planifier, aligner et améliorer continuellement la valeur fournie au client, de l’idée initiale à sa concrétisation mesurable.³

Historiquement, de nombreuses organisations informatiques ont opté pour des équipes fonctionnelles (Frontend, Backend, Data). Sans surprise, ce type de structure produit des architectures en « monolithe en couches » qui reflètent ces fonctions, car le travail s’arrête à la frontière technique de l’équipe . Une requête client traverse inévitablement les silos, transformant les équipes subséquentes (comme le Data Engineering) en goulots d’étranglement .

En revanche, la VSM exige la mise en place d’équipes interfonctionnelles alignées sur le parcours client (customer journey) pour briser ces silos opérationnels.³ L’objectif est de s’assurer que l’équipe est organisée autour de la séquence complète d’étapes qui transforment une idée en valeur concrète.³ Cela permet de repérer et d’éliminer les goulots d’étranglement, et de mesurer l’efficacité réelle du flux (débit, durée du flux).³

La Stratégie Délibérée : La Manœuvre de Conway Inversée

L’approche Team Topologies repose sur l’exploitation stratégique de la Loi de Conway, connue sous le nom de « Manœuvre de Conway inversée ».⁴ Au lieu de subir la conséquence involontaire de la structure, l’organisation conçoit délibérément sa structure d’équipe pour obtenir l’architecture logicielle désirée.⁵

Cette manœuvre nécessite de travailler simultanément sur la conception organisationnelle et l’architecture du système, en recherchant des divisions logiques dans le domaine métier qui se reproduiront dans l’architecture logicielle (par exemple, des microservices).⁵ Les auteurs de Team Topologies se sont appuyés sur cette manœuvre pour créer un modèle pragmatique.⁴

Toutefois, il est essentiel de noter que la Manœuvre de Conway inversée n’est pas sans risques. Une réorganisation est coûteuse en termes humains et financiers. Son succès est fortement corrélé à la rétention des connaissances et à la proximité hiérarchique du pouvoir de décision par rapport aux ingénieurs qui implémentent les composants, garantissant ainsi le maintien de la qualité.⁶

III. Le Langage Structurant : Les Quatre Topologies Fondamentales

Team Topologies fournit un vocabulaire précis et un ensemble de quatre types d’équipes, comparables à des composants utilisés pour composer une architecture ⁷, qui servent de blocs de construction pour l’ingénierie organisationnelle.

Les Quatre Types d’Équipes

Équipes Orientées Flux (Stream-aligned teams)

Ces équipes sont alignées sur une source continue de travail (un flux de valeur, un produit ou un parcours client). Elles sont propriétaires de l’intégralité du cycle de vie, de la conception au déploiement, pour leur segment de valeur . Leur objectif principal est l’optimisation pour le flux continu (continuous flow), ce qui minimise les transferts de responsabilités (handoffs). Elles constituent la majorité des équipes dans une organisation bien alignée et sont la pierre angulaire de la livraison de valeur client .

Équipes Plateformes (Platform teams)

Leur mandat est de fournir des services internes réutilisables, des outils et des infrastructures qui réduisent la charge cognitive des autres équipes . Le but ultime de l’ingénierie de plateforme est de permettre aux équipes Orientées Flux d’être auto-suffisantes . Ces services sont consommés idéalement via le mode X-as-a-Service (XaaS), fournissant des abstractions claires et fiables, telles que l’Authentification-as-a-Service (AaaS) ou le Network-as-a-Service (NaaS).⁸

Équipes Sous-systèmes Complexes (Complicated-Subsystem teams)

Ces équipes possèdent les parties du système qui sont soit trop spécialisées, soit mathématiquement complexes, nécessitant une expertise rare (par exemple, un moteur d’optimisation complexe ou un composant d’apprentissage automatique – ML) . En isolant ce travail de haute complexité, elles protègent le flux des équipes Orientées Flux qui ne devraient pas avoir à porter cette charge cognitive et cette expertise profonde .

Équipes Habilitantes (Enabling teams)

Elles agissent comme des coachs temporaires. Leur rôle est d’aider d’autres équipes (principalement Orientées Flux) à améliorer leurs compétences, adopter de nouvelles pratiques (comme l’observabilité) ou maîtriser des technologies spécifiques . Leur objectif est de supprimer les goulots d’étranglement basés sur les connaissances et d’élever les capacités, sans jamais prendre en charge le travail de livraison permanent.⁹ Leur mode d’interaction privilégié est la Facilitation.

L’utilisation de cette nomenclature précise est un mécanisme puissant pour réduire l’ambiguïté organisationnelle. En nommant explicitement le type d’équipe et le mode d’interaction attendu, l’organisation établit des limites et des attentes claires, réduisant ainsi la friction et l’effort de coordination .

Synthèse des Quatre Topologies d’Équipe et de leurs Mandats

Topologie	Raison d’Être	Priorité d’Optimisation	Mode d’Interaction Privilégié	Impact sur l’Architecture
Orientée Flux (Stream-aligned)	Délivrer une valeur client de bout en bout.	Flux Continu (Débit et TTM)	Consommation (X-as-a-Service)	Propriété complète (Design to Deployment)
Plateforme (Platform)	Réduire la Charge Cognitive des autres équipes.	Expérience Développeur (DevEx)	Fourniture (X-as-a-Service)	Abstraction des préoccupations transversales (e.g., BaaS, NaaS) 8
Sous-système Complexe (Complicated-subsystem)	Isoler les domaines spécialisés ou complexes.	Stabilité et Expertise Approfondie	Collaboration (Temporaire)	Délimitation claire des interfaces entre systèmes complexes et le reste.
Habilitante (Enabling)	Augmenter les capacités et la maturité technique.	Amélioration des Compétences	Facilitation (Coaching temporaire)	Standardisation et Adoption des Bonnes Pratiques Architecturales.

IV. Le Facteur Oublié : Protéger la Charge Cognitive

Charge Cognitive et Efficacité des Équipes

Un facteur fondamental dans la conception de l’organisation et de l’architecture est la charge cognitive.¹⁰ Elle représente la quantité totale d’effort mental nécessaire pour comprendre, maintenir et faire évoluer le système. Une charge cognitive excessive, due à une complexité inutile du système, à un manque de documentation, ou à la nécessité de maîtriser un trop grand nombre de technologies transversales, affecte directement la capacité d’une équipe à opérer efficacement.¹⁰ L’un des principes fondamentaux de Team Topologies est de respecter ces limites cognitives.

Lorsqu’une équipe Orientée Flux est submergée par une charge cognitive trop élevée, elle est ralentie, les erreurs augmentent, et sa capacité à se concentrer sur l’innovation ou la livraison de valeur client est saturée. L’architecture est donc un driver direct de la charge cognitive des équipes.¹⁰ Le découpage des équipes doit être conçu pour limiter cette charge afin de maximiser le débit.

Stratégies Architecturales pour la Réduction de la Charge Cognitive

L’approche Team Topologies structure l’organisation pour externaliser et isoler la charge cognitive.

L’Ingénierie de Plateforme joue un rôle clé. Son objectif principal est d’accélérer le flux de valeur en réduisant au minimum la complexité du système à l’échelle de l’organisation.¹¹ En fournissant des services robustes et matures via X-as-a-Service, l’équipe Plateforme absorbe la charge liée à l’infrastructure et aux préoccupations transversales, libérant ainsi l’énergie mentale des équipes Orientées Flux pour qu’elles se concentrent sur la logique métier.⁹ Le succès d’une plateforme est mesuré par la réduction effective de la charge cognitive qu’elle procure à ses clients internes.

De même, l’Équipe Sous-système Complexe est chargée d’isoler la complexité dite « essentielle » (celle qui ne peut être évitée).¹⁰ Elle permet d’éviter que la gestion d’une expertise pointue ou d’un domaine mathématiquement difficile ne s’infiltre et ne pèse sur la performance des autres équipes .

Si une organisation est contrainte par les ressources et ne peut pas dédier une équipe distincte à chaque domaine, une solution peut consister à fusionner les domaines en un seul domaine complexe, formant un monolithe bien géré, ou à utiliser intensivement les équipes Sous-systèmes Complexes pour isoler des portions de travail spécifiques et coûteuses en expertise.¹⁰

V. La Mécanique des Dépendances : Les Trois Modes d’Interaction comme API Inter-Équipes

Afin d’éviter la multiplication des dépendances informelles et des frictions, Team Topologies définit trois modes d’interaction qui servent de contrats clairs, ou d’« API organisationnelles », entre les équipes.⁹ Ces modes sont délibérément choisis pour atteindre l’autonomie, débloquer les dépendances, réduire le temps perdu et éviter les goulots d’étranglement.¹²

Collaboration : Le Mode Découverte (Bande Passante Élevée)

La Collaboration implique un travail intensif et rapproché entre deux équipes pour une période strictement définie afin d’atteindre un objectif spécifique ou de découvrir de nouvelles interfaces (API, pratiques).⁷ Ce mode, caractérisé par une bande passante élevée et un coût élevé en temps, est nécessaire pour la co-création complexe, comme le développement initial d’un nouveau composant ML (géré par une équipe Sous-système Complexe) avec l’équipe Orientée Flux qui en sera le premier consommateur . Il est impératif que la Collaboration reste temporaire et ciblée ; si elle se prolonge indéfiniment, elle se transforme en un goulot d’étranglement permanent.

X-as-a-Service (XaaS) : Le Mode Abstraction (Faible Coût)

Le mode X-as-a-Service, ou Anything-as-a-Service (XaaS), est la forme d’interaction privilégiée pour les équipes Plateformes.⁷ Il implique qu’une équipe fournit un service qu’une autre équipe consomme via un contrat clair, sans nécessiter de connaissance des mécanismes internes.⁹ Cette approche est cruciale pour la gestion des dépendances car elle établit une relation fournisseur/consommateur avec des limites claires et une interaction minimale, ce qui réduit considérablement le coût de coordination.⁹ L’exemple typique est la consommation d’un service d’identité et d’accès (Authentication-as-a-Service) qui permet aux équipes Orientées Flux d’être autonomes sur la livraison sans se soucier de l’infrastructure sous-jacente.⁸

Facilitation : Le Mode Coaching (Temporaire et Focalisé)

La Facilitation est le mode utilisé principalement par les Équipes Habilitantes.⁹ Une équipe aide et encadre temporairement une autre pour améliorer ses pratiques ou son adoption technologique.⁷ Ce mode est ciblé et axé sur l’élimination des obstacles.⁹ Par exemple, si une équipe Orientée Flux éprouve des difficultés à intégrer les pratiques d’observabilité, l’équipe Habilitante peut intervenir en mode Facilitation pour lui transmettre l’expertise nécessaire. En renforçant les compétences internes, ce mode réduit la dépendance future de l’équipe à l’aide externe, augmentant ainsi son autonomie et gérant plus efficacement la complexité.⁹

Le succès du cadre réside dans l’utilisation délibérée de ces modes. En faisant correspondre le mode à la maturité du service et à la nature du travail, l’organisation remplace les mandats ambigus (« Nous devons mieux coordonner ») par des contrats clairs, ce qui permet de diagnostiquer rapidement si une interaction est saine ou si elle génère de la friction.

VI. Le Guide Pratique en Quatre Étapes : Exécuter le Réalignement

La transition vers un modèle Team Topologies ne nécessite pas l’introduction de couches de processus supplémentaires, mais plutôt un design structurel délibéré effectué en quatre étapes pragmatiques .

Étape 1 : Cartographier l’Architecture des Équipes Actuelles

La première action à haut levier consiste à documenter la structure existante en utilisant le langage Team Topologies. Cela implique de créer un diagramme simple, où chaque équipe est représentée par une boîte et étiquetée avec la topologie de facto qu’elle incarne (Orientée Flux, Plateforme, Sous-système Complexe ou Habilitante). Il est également crucial de noter le principal mode d’interaction avec les autres équipes .

Cet exercice révèle immédiatement les désalignements : où se trouvent les équipes qui se désignent comme « Plateforme » mais qui agissent comme des produits non servis? Où les équipes Habilitantes sont-elles en réalité absorbées par du travail de livraison permanent? Où sont les équipes qui devraient être Orientées Flux mais sont coupées de la chaîne de valeur complète? .

Étape 2 : Cartographier l’Architecture du Système

Parallèlement, il faut construire une vue de contexte de haut niveau des principaux composants techniques du système et de leurs interdépendances. L’objectif n’est pas de produire une documentation exhaustive, mais d’identifier les grands patterns de couplage technique et les relations entre les composants .

Étape 3 : Comparer les Deux Cartes : Identifier les Points de Friction

En superposant les cartes de l’organisation (Étape 1) et du système (Étape 2), les points de friction apparaissent clairement. Il s’agit des endroits où les dépendances techniques sont aggravées par les frontières organisationnelles .

Les désalignements typiques comprennent :

• Une équipe Orientée Flux qui dépend de trois autres équipes pour exécuter la majorité de ses changements, signalant un fort couplage structurel .
• Une équipe Plateforme qui nécessite de la Collaboration pour une simple consommation routinière, indiquant que son service n’est pas assez mature pour être un véritable X-as-a-Service .
• Un sous-système complexe dont la complexité essentielle (le « hard math ») est mal isolée et déborde sur les équipes Orientées Flux, augmentant leur charge cognitive .

Chaque point de friction identifié représente une opportunité de repenser la frontière, qu’elle soit organisationnelle, technique, ou liée au mode d’interaction .

Étape 4 : Réaligner Autour du Flux : Transformer les Coutures

Le réalignement doit être un processus incrémental, où une seule « couture » (frontière) est modifiée à la fois. Le but est d’éliminer les goulots d’étranglement identifiés à l’étape précédente.

Les axes stratégiques de réalignement incluent :

1. Consolidation : Regrouper le travail pour qu’une seule équipe Orientée Flux détienne une tranche de valeur client de bout en bout .
2. Carvage de Plateforme : Créer un véritable service Plateforme (XaaS) là où plusieurs équipes « empruntent » actuellement des experts, afin de standardiser et d’abstraire les préoccupations transversales .
3. Quarantaine de la Complexité : Mettre en place une équipe Sous-système Complexe pour isoler les parties du système nécessitant une expertise rare, protégeant ainsi le flux des autres équipes .
4. Transformation de l’Architecture : Demander au groupe d’architecture d’opérer en mode Habilitation/Facilitation, en fournissant du coaching, des implémentations de référence et des garde-fous, plutôt qu’en mode contrôle (gatekeeping).¹³

Le tableau suivant résume les principaux désalignements et les solutions structurelles proposées par Team Topologies :

Analyse des Désalignements Fréquents et Solutions Team Topologies

Désalignement (Point de Friction)	Symptôme Organisationnel	Solution T.T. Recommandée (Étape 4)
Dépendance Inter-équipes Élevée	La livraison d’une fonctionnalité impacte trois composants possédés par trois équipes différentes.	Consolider le travail dans une seule Équipe Orientée Flux pour posséder la tranche de valeur end-to-end.
Plateforme Immature	Le service de la Plateforme est instable ou nécessite des appels constants à ses experts.	Reclasser temporairement en mode Collaboration (haute bande passante) jusqu’à ce que le service soit mûr pour le X-as-a-Service.
Surcharge Cognitive	Les équipes Orientées Flux doivent gérer les dépendances logicielles complexes ou l’infrastructure non abstraite.	Carvage d’une Équipe Plateforme ou Sous-système Complexe pour assumer cette charge (principe d’isolation de la complexité).10
Architecture Stagnante	Les nouvelles pratiques architecturales (ex: observability) ne sont pas adoptées uniformément.	Mise en place d’une Équipe Habilitante en mode Facilitation pour le coaching ciblé et temporaire.

La comparaison des cartes n’est pas une fin en soi, mais le début d’une boucle de rétroaction continue. En rendant les problèmes inter-équipes visibles et interprétables à travers le prisme de Team Topologies, les organisations transforment les frictions en signaux précieux pour l’évolution continue de leur modèle, se rapprochant de l’idéal d’une organisation auto-dirigée.¹⁴

VII. Pièges, Anti-Patterns et Gouvernance Stratégique

L’adoption réussie de Team Topologies exige une discipline rigoureuse pour éviter certains pièges de classification et de comportement.

Le Syndrome du “Tout Plateforme” et la Maturité du Service

Un écueil très courant est de désigner tout service interne comme une « Plateforme » en mode X-as-a-Service, même si ce service n’est pas mature . Si les consommateurs ne peuvent pas utiliser le service sans accompagnement constant ou sans devoir solliciter l’équipe Plateforme, le service est, par définition, en mode Collaboration, non XaaS . Cette mauvaise classification a un impact direct et négatif sur la charge cognitive des équipes Orientées Flux.¹¹ En effet, elles sont contraintes d’opérer dans un mode à haute bande passante (Collaboration) alors qu’elles devraient bénéficier d’une interaction à faible bande passante (XaaS). La solution est d’accepter que la plateforme doive évoluer et n’adopter le label XaaS qu’une fois la stabilité et l’interface de consommation atteintes .

De plus, une Plateforme doit être traitée comme un produit interne. Les équipes Plateformes qui ne consultent pas leurs développeurs clients risquent de créer des outils inutiles ou inefficaces, basés sur des préjugés de connaissance (Knowledge Bias), ce qui engendre de la frustration et ralentit l’adoption.¹¹

Erreurs de Classification des Équipes Supports

Il est crucial que les Équipes Habilitantes maintiennent un rôle d’encadrement temporaire. Si ces équipes sont permanentes et effectuent du travail de livraison régulier, elles ont été mal classifiées . Elles devraient être reclassées, le plus souvent en Équipe Orientée Flux si elles possèdent un domaine métier clair, ou ajustées pour revenir à un rôle de coaching. Le mandat des équipes Habilitantes est de créer de l’autonomie, pas de devenir un goulot d’étranglement d’expertise permanent.

Par ailleurs, les équipes Orientées Flux ne doivent pas être surchargées. Le fait de vouloir qu’elles gèrent des spécialisations profondes (comme des calculs mathématiques complexes ou la gestion de dépendances logicielles avancées) est une erreur d’architecture d’équipe . La mise en place d’une Équipe Sous-système Complexe pour isoler ces domaines est un mécanisme nécessaire pour maintenir le flux de l’équipe Orientée Flux.

La Gouvernance Légère : De l’Architecture comme Gatekeeper à l’Architecture comme Facilitateur

Le rôle de la fonction Architecture doit également être réaligné dans ce modèle. Elle devrait opérer en tant qu’Équipe Habilitante en mode Facilitation . Cela signifie que les architectes fournissent des orientations, définissent des garde-fous (principes architecturaux) et proposent des implémentations de référence pour accélérer les choix techniques, au lieu d’agir comme un point de contrôle (gatekeeper) qui ralentit le processus de livraison .

En conclusion, Team Topologies n’est pas un ensemble de cérémonies supplémentaires, mais un design de structure qui vise à éliminer les dépendances . Les réunions ou les standups ne peuvent pas retirer les dépendances ; seules les frontières d’équipe clairement définies le peuvent. Ce modèle est reconnu par l’industrie comme une pratique de maturité, les organisations très évoluées ayant tendance à suivre ce modèle pour optimiser le flux de valeur.¹⁵

VIII. Conclusion et Perspectives Stratégiques

L’adoption de Team Topologies permet de réaliser la Manœuvre de Conway inversée en fournissant le langage et les blocs de construction (les quatre topologies) nécessaires pour assembler l’organisation comme un système modulaire.¹³ Elle offre un double bénéfice stratégique : une accélération significative de la livraison de valeur (grâce à la réduction des handoffs et au raccourcissement des boucles de rétroaction) et l’établissement d’une architecture logicielle plus résiliente, caractérisée par une propriété de domaine claire et un couplage faible .

Lorsque les équipes sont organisées autour de flux de valeur, la majorité des changements peuvent être gérés au sein d’une seule équipe Orientée Flux. Les services Plateformes standardisent les préoccupations transversales, tandis que les Sous-systèmes Complexes mettent en quarantaine les difficultés techniques majeures. L’effet net est une réduction spectaculaire du besoin de coordination à l’échelle de l’entreprise juste pour livrer une fonctionnalité .

La connaissance précise de l’architecture de ses équipes est la première étape la plus stratégique. En cartographiant l’organisation selon les termes de Team Topologies et en la comparant à l’architecture technique, les désalignements révèlent exactement où la livraison ralentit. En réparant ces « coutures » organisationnelles et techniques, l’organisation assure que l’architecture logicielle qu’elle désire devient la conséquence naturelle d’une structure de communication saine et orientée vers le client, raccourcissant ainsi le chemin de l’idée à la valeur concrète.

Sources des citations

1. loi de Conway – Crafting Labs le blog, consulté le octobre 21, 2025, https://blog.crafting-labs.fr/2009/04/02/loi-de-conway/
2. Ce que vos pipelines disent de votre structure organisationnelle – F5, consulté le octobre 21, 2025, https://www.f5.com/fr_fr/company/blog/what-your-pipelines-say-about-your-organizational-structure
3. Qu’est-ce que la gestion des flux de valeur ? | IBM, consulté le octobre 21, 2025, https://www.ibm.com/fr-fr/think/topics/value-stream-management
4. Team Topologies – Coach agile, consulté le octobre 21, 2025, https://coach-agile.com/produit/team-topologies/
5. 4. La loi de Conway et la recherche des bonnes limites – Permettre le succès des microservices [Book] – O’Reilly Media, consulté le octobre 21, 2025, https://www.oreilly.com/library/view/permettre-le-succes/9798341614277/ch04.html
6. Loi de Conway : lorsque les bonnes pratiques ne suffisent plus IT Zone – Java & Moi, consulté le octobre 21, 2025, https://javaetmoi.com/wp-content/uploads/2023/04/2023-04-13-Loi-de-Conway.pdf
7. Comprendre les team topologies | Lucidchart – Lucid Software, consulté le octobre 21, 2025, https://lucid.co/fr/blog/team-topologies
8. Qu’est-ce que le XaaS (Anything as a Service) ? | OVHcloud France, consulté le octobre 21, 2025, https://www.ovhcloud.com/fr/learn/what-is-xaas/
9. Key concepts and practices for applying a Team Topologies …, consulté le octobre 21, 2025, https://teamtopologies.com/key-concepts
10. Charge Cognitive un driver de l’architecture – Blog Ippon, consulté le octobre 21, 2025, https://blog.ippon.fr/2023/10/09/charge-cognitive-un-driver-de-larchitecture/
11. Revisiting Team Topologies: Misuses of Platform Teams — Team …, consulté le octobre 21, 2025, https://teamtopologies.com/news-blogs-newsletters/2024/11/24/revisiting-team-topologies-misuses-of-platform-teams
12. Topologies d’équipes DevOps – Cloud Adoption Framework – Microsoft Learn, consulté le octobre 21, 2025, https://learn.microsoft.com/fr-fr/azure/cloud-adoption-framework/ready/considerations/devops-teams-topologies
13. Réussir une Conway inversée – Compte-rendu du talk de Romain Vailleux à La Duck Conf 2021, consulté le octobre 21, 2025, https://blog.octo.com/reussir-une-conway-inversee-compte-rendu-du-talk-de-romain-vailleux-a-la-duck-conf-2021
14. Team Topologies, 2nd Edition – Fnac, consulté le octobre 21, 2025, https://www.fnac.com/livre-numerique/a21613603/Matthew-Skelton-Team-Topologies-2nd-Edition
15. Team Topologies – Organizing for fast flow of value, consulté le octobre 21, 2025, https://teamtopologies.com/