Team Topologies et conception sociotechnique

La conception des équipes est un travail d’architecture

Le chapitre 3 a montré que la loi de Conway n’est pas une curiosité mais une force : le système qu’un groupe d’équipes construit tend à reproduire la manière dont ces équipes communiquent. Si c’est vrai, alors décider comment les équipes sont formées, de quoi chacune est responsable et comment elles interagissent est une décision architecturale, aux conséquences aussi durables que le choix d’une base de données ou d’un style d’intégration. La discipline qui consiste à concevoir ensemble la structure du logiciel et celle des équipes s’appelle l’architecture sociotechnique.

Le cadre pratique le plus influent pour y parvenir est Team Topologies, de Matthew Skelton et Manuel Pais (IT Revolution, 2019 ; deuxième édition 2025). Il part d’un objectif simple, le flux rapide (fast flow) : un courant régulier et soutenable de petits changements, de l’idée à la production, avec peu d’attente entre les équipes. Il propose ensuite un petit vocabulaire pour concevoir des organisations qui l’atteignent : quatre types d’équipes, trois modes d’interaction, une limite appelée charge cognitive de l’équipe, et une technique pour trouver les lignes de découpe le long desquelles le logiciel et les équipes peuvent être divisés.

Plusieurs prémisses traversent l’approche. L’équipe, et non l’individu, est l’unité de livraison : le travail est confié à des équipes, la responsabilité appartient aux équipes, et les équipes sont durables, afin d’accumuler la connaissance de leur domaine et de leur code au lieu d’être assemblées pour un projet puis dispersées. Les équipes sont petites, généralement de cinq à neuf personnes, car la confiance et la compréhension partagée déclinent vite au-delà de cette taille (les auteurs s’appuient sur les recherches de Robin Dunbar sur la taille des groupes). Et les frontières des équipes doivent être conçues pour le flux des changements, pas pour la commodité des lignes hiérarchiques ni d’après l’historique de qui a construit quoi.

Pour les architectes, cela change le métier. Une frontière de service proposée n’est bonne que si une équipe peut en être entièrement responsable ; une équipe proposée n’est viable que si le code dont elle est responsable lui permet de travailler sans demander la permission à trois autres équipes. L’architecte qui dessine des boîtes sans se demander qui sera responsable de chacune ne conçoit que la moitié du système.

Les quatre types d’équipes fondamentaux

Team Topologies soutient que presque toutes les équipes d’une organisation logicielle devraient relever de l’un de quatre types. L’intérêt d’avoir si peu de types est la clarté : chaque type a un objectif différent, une manière différente de mesurer la réussite et une relation différente avec les autres équipes, si bien que connaître le type d’une équipe indique à tous ce qu’ils peuvent en attendre.

Une équipe orientée flux (stream-aligned team) est alignée sur un flux de changements : un produit, un parcours client, un groupe d’utilisateurs ou une capacité métier. Elle est responsable de sa partie de bout en bout, de la découverte à l’exploitation en production en passant par la construction, et doit pouvoir livrer la plupart des changements sans attendre personne. Les équipes orientées flux sont le cas par défaut et doivent constituer la grande majorité ; les trois autres types existent pour alléger leur charge.

Une équipe plateforme fournit des services internes (pipelines de déploiement, environnement d’exécution, observabilité, infrastructure de données) sous la forme d’un produit que les équipes orientées flux consomment en libre-service. Une bonne plateforme se juge à la vitesse de ses utilisateurs, pas à sa propre liste de fonctionnalités. Une équipe facilitatrice (enabling team) se compose de spécialistes qui aident d’autres équipes à acquérir une capacité qui leur manque, comme l’automatisation des tests, les pratiques d’observabilité ou un nouveau framework, puis passent à autre chose ; sa réussite se mesure au fait que l’autre équipe n’a plus besoin d’elle. Une équipe sous-système compliqué est responsable d’une partie qui exige une expertise rare, comme un moteur de tarification reposant sur des modèles actuariels, un solveur d’optimisation d’itinéraires ou un codec vidéo, afin que les équipes orientées flux puissent l’utiliser sans avoir à la maîtriser. Le livre insiste sur le fait que ce type doit être utilisé avec parcimonie, et seulement là où la spécialité est réelle.

Trois modes d’interaction

Les types d’équipes disent ce que sont les équipes ; les modes d’interaction disent comment elles travaillent ensemble. Skelton et Pais soutiennent que l’interaction ambiguë et improvisée entre équipes est une source majeure de retard, car chaque conversation non planifiée est une dépendance. Ils recommandent donc que chaque paire d’équipes qui doivent interagir choisisse délibérément l’un des trois modes, pour une période déterminée.

En collaboration, deux équipes travaillent étroitement ensemble vers un objectif commun, avec des responsabilités floues, par exemple pendant qu’elles découvrent comment une nouvelle capacité doit être découpée. Ce mode produit un apprentissage rapide mais coûte aux deux équipes de la capacité et de la charge cognitive : il doit donc être limité dans le temps. En X en tant que service (X-as-a-Service), une équipe fournit quelque chose (une API, une capacité de plateforme, une bibliothèque) qu’une autre consomme avec peu ou pas de collaboration ; ce mode passe bien à l’échelle, mais ne fonctionne qu’une fois la frontière bien comprise et l’interface de bonne qualité. En facilitation, une équipe, généralement une équipe facilitatrice, en aide une autre à apprendre ou à lever un obstacle.

Les modes sont faits pour changer. Une séquence courante consiste à découvrir puis à stabiliser : une équipe plateforme collabore avec une équipe orientée flux pendant quelques semaines pour concevoir une nouvelle capacité, puis la transforme en offre en libre-service et passe en X en tant que service. Les modes servent aussi de mécanisme de détection. Si une équipe censée consommer un service en tant que service a sans cesse besoin de réunions, l’interface ou la frontière est probablement mauvaise ; si deux équipes collaborent depuis un an, elles ne forment peut-être en réalité qu’une seule équipe, ou la séparation entre elles est peut-être mal placée.

La charge cognitive comme contrainte de conception

L’idée de charge cognitive vient de la psychologie de l’éducation. La théorie de la charge cognitive de John Sweller, publiée pour la première fois en 1988, partait de l’observation que la mémoire de travail humaine ne peut retenir et traiter que quelques éléments nouveaux à la fois, si bien que l’enseignement doit être conçu pour ne pas la surcharger. La théorie distingue la charge intrinsèque (la difficulté inhérente à la matière), la charge extrinsèque (la difficulté causée par la manière dont la tâche est présentée) et, dans des travaux ultérieurs, la charge pertinente (l’effort qui construit une compréhension durable). Les chercheurs débattent encore de la question de savoir si la charge pertinente est une catégorie distincte, et Team Topologies utilise les trois comme une heuristique pratique plutôt que comme une mesure.

La section 3.7 a présenté la version de cette idée appliquée aux équipes : le total qu’une équipe doit avoir en tête pour construire, exploiter et faire évoluer ce dont elle est responsable. Ce qui compte ici, c’est la manière de l’utiliser comme contrainte de conception. Quand une architecture confie à une équipe plus qu’elle ne peut comprendre, les effets sont prévisibles : une livraison plus lente, des corrections superficielles, des astreintes fragiles, des connaissances concentrées chez une ou deux personnes et, à terme, des départs. Ce sont les mêmes symptômes que l’on impute souvent à de mauvais ingénieurs ou à du mauvais code.

Le livre propose des règles empiriques pour dimensionner les responsabilités d’une équipe selon la complexité du domaine : confier chaque domaine à une seule équipe ; une équipe peut généralement gérer deux ou trois domaines simples ; une équipe responsable d’un domaine complexe ne devrait être responsable de rien d’autre ; et aucune équipe ne devrait avoir deux domaines compliqués. On peut aussi interroger directement les équipes, par exemple avec un court questionnaire sur leur degré de compréhension de leurs systèmes, leur confiance pendant les astreintes et le temps consacré à l’outillage plutôt qu’au domaine. Des files de tickets qui s’allongent, de longs délais d’intégration des nouveaux arrivants et des transferts fréquents vers la seule personne qui comprend un composant sont des signaux indirects utiles.

Les réponses architecturales reflètent les trois types de charge. Réduisez la charge extrinsèque avec des plateformes, de l’automatisation, des chemins balisés (paved paths) et une bonne documentation. Bornez la charge intrinsèque en traçant les frontières des services et des modules de sorte que la part du domaine de chaque équipe soit cohérente et d’une taille gérable, et en plaçant les spécialités pointues derrière des interfaces de sous-systèmes compliqués. Protégez la charge pertinente en laissant du temps pour l’apprentissage ; c’est là que les équipes facilitatrices aident.

Les API d’équipe et la plateforme viable la plus fine

Si les équipes interagissent selon des modes délibérés, chaque équipe a besoin d’un visage clair face au reste de l’organisation. Team Topologies l’appelle l’API de l’équipe (team API) : tout ce que l’équipe offre et attend. Elle comprend l’API technique (endpoints, événements, bibliothèques, avec leurs règles de versionnage et de dépréciation), mais aussi l’interface humaine : la documentation et les guides de prise en main, la feuille de route et les priorités actuelles de l’équipe, ses pratiques de travail, les canaux par lesquels on peut la joindre, la manière de lui demander du travail et les délais de réponse à attendre.

Mettre par écrit l’API d’une équipe est un exercice peu coûteux et révélateur. Il oblige l’équipe à dire de quoi elle est responsable, ce qui met généralement au jour des services sans responsable et des données disputées, et il donne aux autres équipes un moyen d’interagir sans réunion. Beaucoup d’organisations la conservent sous la forme d’une courte page dans le dépôt de l’équipe, revue chaque trimestre avec la documentation d’architecture.

La plateforme mérite une attention particulière, car c’est là que les bonnes intentions tournent le plus souvent mal. Une plateforme construite comme un grand projet interne, avec une longue feuille de route et une adoption obligatoire, peut facilement ajouter de la charge cognitive au lieu d’en retirer. Skelton et Pais recommandent la plateforme viable la plus fine (thinnest viable platform) : le plus petit ensemble de services, de documentation et de normes qui accélère réellement ses utilisateurs. Pour une petite organisation, il peut s’agir d’une page bien tenue qui énumère les services du fournisseur cloud que les équipes doivent utiliser, et comment ; pour une grande, ce peut être une plateforme interne de développement. L’ingénierie de plateforme est traitée en détail au chapitre 10 ; l’essentiel ici est qu’une plateforme est un produit dont les clients sont d’autres équipes, et qu’elle doit être conçue et mesurée comme tel.

Plans de fracture : où découper le logiciel et les équipes

Quand une partie du système est devenue trop grande pour une seule équipe, il faut la découper, et le découpage doit fonctionner à la fois pour le code et pour les équipes. Team Topologies appelle plans de fracture les lignes de découpe naturelles le long desquelles le logiciel peut être divisé. Le livre en énumère plusieurs, et le premier est généralement le meilleur : un contexte délimité issu de la conception pilotée par le domaine, car une frontière qui suit le langage et les règles du métier tend à garder ensemble les changements liés.

Les autres sont utiles quand ils correspondent à une vraie différence dans la manière dont les parties du système doivent être traitées. Découper selon une frontière technologique seule (par exemple une équipe mobile et une équipe backend) est généralement le choix le plus faible, car la plupart des changements la traversent alors : c’est la structure d’équipes en couches contre laquelle met en garde la loi de Conway.

La loi de Conway, la manœuvre inversée et ses limites

Team Topologies est, en pratique, une boîte à outils pour la manœuvre de Conway inversée décrite à la section 3.7 : décider de l’architecture voulue, puis façonner les équipes et les modes d’interaction pour que la loi de Conway pousse le système vers elle. Ses apports sont pratiques. Les types d’équipes disent quel genre d’équipe doit être responsable de chaque partie ; les modes d’interaction disent quelles frontières entre équipes sont censées être minces (X en tant que service) et lesquelles sont temporairement épaisses (collaboration) ; la charge cognitive dit de combien chaque équipe peut être responsable ; les plans de fracture disent où couper.

Les limites vues à la section 3.7 s’appliquent toujours et méritent d’être rappelées dans ce contexte. Réorganiser les équipes ne restructure pas une base de code fortement couplée : pendant des mois après une réorganisation, les nouvelles équipes se battront contre l’ancienne architecture, et c’est pourquoi les changements d’équipes et les changements d’architecture doivent être planifiés comme un seul programme. Des frontières figées trop tôt dans des équipes rendent les erreurs coûteuses : beaucoup d’organisations gardent donc les frontières incertaines à l’intérieur d’une seule équipe ou d’un seul monolithe modulaire jusqu’à disposer de preuves. Et des réorganisations fréquentes détruisent la connaissance des équipes durables dont dépend l’approche.

Les praticiens ne s’accordent pas non plus sur la mesure dans laquelle il faut appliquer le cadre à la lettre. Ses partisans apprécient le vocabulaire commun, qui transforme des plaintes vagues (nous attendons sans cesse l’équipe data) en questions sur lesquelles on peut travailler en conception (quel mode d’interaction voulons-nous avec l’équipe data, et qu’est-ce qui en ferait un X en tant que service ?). Ses détracteurs avertissent que les quatre types sont souvent appliqués comme des étiquettes à une organisation inchangée, que les vraies équipes mélangent parfois les types (une équipe plateforme qui est aussi responsable d’un sous-système compliqué) et que le cadre dit peu de choses du financement, de la structure managériale ou des incitations. Les deux points sont justes : les types sont une aide à la conception, pas un organigramme, et les auteurs eux-mêmes les présentent comme un point de départ pour un ajustement continu.