Les Team Topologies en Pratique : Choisir la Bonne Structure d'Équipe
"Team Topologies" de Skelton et Pais (2019) a donné au leadership d'ingénierie un vocabulaire partagé pour la structure des équipes. Mais j'ai vu des organisations lire le livre, renommer toutes leurs équipes pour correspondre aux quatre types, et ne rien changer à la façon dont le travail circule réellement. D'autres créent des équipes de plateforme avant d'avoir quoi que ce soit à platformifier.
Voici comment l'appliquer vraiment en pratique, y compris quand restructurer et quand laisser les choses telles quelles.
Les Quatre Types d'Équipes : Un Rappel Rapide
Si vous avez lu le livre, passez à la section suivante. Sinon, voici le modèle central.
Les équipes stream-aligned sont les unités primaires de livraison de valeur. Elles possèdent un flux de travail — un produit, un ensemble de fonctionnalités, un domaine métier. Cross-fonctionnelles et capables de livrer de bout en bout. La plupart de vos ingénieurs devraient être ici.
Les équipes enabling aident les autres équipes à adopter de nouvelles technologies ou capacités. Elles ne construisent pas des choses pour les autres équipes — elles aident les autres équipes à construire par elles-mêmes. Temporaires par conception.
Les équipes de plateforme fournissent des services internes que les équipes stream-aligned consomment en libre-service. CI/CD, déploiement, infrastructure partagée. Si les équipes doivent créer un ticket et attendre, vous avez construit un goulot d'étranglement, pas une plateforme.
Les équipes de sous-système complexe possèdent des composants nécessitant une connaissance spécialisée profonde — modèles ML, pipelines de données en temps réel, moteurs financiers complexes. Créées quand la charge cognitive est trop élevée pour qu'une équipe stream-aligned la porte.
Quand Créer Chaque Type d'Équipe
L'erreur la plus courante est de créer les quatre types en même temps parce que le livre décrit quatre types. En pratique, vous les introduisez au fur et à mesure que le besoin se manifeste.
Stream-Aligned : Commencez Ici, Toujours
Chaque organisation d'ingénierie commence avec des équipes stream-aligned, qu'elles les appellent ainsi ou non. Si vous avez une équipe construisant un produit, c'est une équipe stream-aligned.
Au fur et à mesure que vous grandissez, la question devient : comment diviser ? La réponse devrait suivre vos frontières de domaine, pas vos couches techniques. Divisez par parcours utilisateur, domaine métier ou zone de produit — pas par frontend/backend/infrastructure.
Quand créer une nouvelle équipe stream-aligned : Quand la charge cognitive sur une équipe existante est trop élevée — elles possèdent trop de domaines, le changement de contexte est constant, et l'équipe est occupée tout le temps mais livre lentement.
Plateforme : Pas Avant d'Avoir une Demande Réelle
C'est là où je vois le plus d'erreurs. La conversation va : "On devrait avoir une équipe de plateforme." "Qu'est-ce qu'ils construiraient ?" "Tu sais... la plateforme."
Une équipe de plateforme a du sens quand :
- Plusieurs équipes stream-aligned construisent la même chose indépendamment. Trois équipes construisant chacune son propre pipeline de déploiement ou sa configuration de logging signale qu'une capacité de plateforme partagée ferait gagner du temps.
- Les équipes stream-aligned passent un temps significatif sur du travail non-différenciant. Si les équipes produit passent 30% de leur temps sur la maintenance d'infrastructure ou CI/CD, une équipe de plateforme peut absorber cette charge.
- Le modèle de libre-service est viable. Si la "plateforme" nécessite un travail personnalisé pour chaque consommateur, vous avez une file d'attente de services partagés, pas une plateforme.
Ne créez pas une équipe de plateforme quand : Vous avez moins de 4-5 équipes stream-aligned, ou quand la "plateforme" n'est vraiment que les besoins d'infrastructure d'une équipe déguisés en initiative partagée. Commencez par de la documentation et des bibliothèques partagées. Si la demande pour une vraie plateforme grandit, vous le saurez.
Enabling : Le Type le Plus Sous-Utilisé
La plupart des organisations n'ont pas d'équipes enabling, et elles devraient. L'équipe enabling est la réponse à une question que j'entends constamment : "Comment faire en sorte que toutes nos équipes adoptent X ?"
X pourrait être :
- L'observabilité (logs, métriques, traces)
- Un nouveau framework de tests
- Les meilleures pratiques de sécurité
- Une migration d'une base de données à une autre
- Les standards de conception d'API
Sans équipe enabling, l'adoption est soit mandatée de haut en bas (créant du ressentiment) soit ne se produit pas du tout. Une équipe enabling travaille aux côtés des équipes stream-aligned comme coachs — pair-programming, ateliers, construction d'outils qui rendent l'adoption plus facile.
Principe clé : Les équipes enabling devraient avoir une durée limitée. Elles existent pour transférer une capacité, pas pour la posséder de façon permanente. Si la vôtre "aide les équipes à adopter l'observabilité" depuis 18 mois, quelque chose ne va pas.
Sous-Système Complexe : Le Type le Plus Rare
Vous avez besoin d'une équipe de sous-système complexe quand la connaissance spécialisée requise pour un composant est si profonde qu'intégrer ça dans une équipe stream-aligned surchargerait la charge cognitive de cette équipe.
Exemples :
- Un moteur de recommandations en temps réel nécessitant une expertise ML
- Un module de traitement des paiements avec des exigences réglementaires complexes
- Un pipeline de transcodage vidéo nécessitant une connaissance profonde en ingénierie média
- Un compilateur ou un runtime de langage
Le test est simple : Un ingénieur généraliste solide d'une équipe stream-aligned pourrait-il maintenir ce composant ? Si oui, vous n'avez pas besoin d'une équipe dédiée. Si la réponse est "seulement s'il passe 80% de son temps dessus," c'est votre signal.
La plupart des startups et organisations d'ingénierie à moyenne échelle ont zéro ou une équipe de sous-système complexe. Si vous en avez plus de deux, demandez-vous si vous sur-spécialisez.
Les Trois Modes d'Interaction
Les modes d'interaction sont la partie de Team Topologies que les gens sautent, et ils ne devraient pas. Comment les équipes interagissent est aussi important que comment elles sont structurées.
Mode collaboration. Deux équipes travaillent étroitement ensemble pendant une période définie. Haute bande passante, coût élevé. À utiliser pour la découverte et le travail en phase initiale, pas comme état permanent. Si deux équipes collaborent en permanence, elles devraient fusionner.
Mode X-as-a-Service. Une équipe fournit une capacité via une interface bien définie. Le mode principal entre les équipes de plateforme et les stream-aligned. Ne fonctionne que si c'est genuinement en libre-service.
Mode facilitant. Une équipe aide une autre à apprendre ou adopter une capacité. Comment les équipes enabling interagissent avec les équipes stream-aligned. L'objectif est l'autonomie.
Quand Restructurer (et Quand Ne Pas le Faire)
Les réorganisations sont coûteuses. Chaque réorg perturbe les relations et coûte des semaines de productivité.
Restructurez quand : Les équipes ne peuvent pas livrer de bout en bout sans se bloquer les unes les autres. Le périmètre d'une équipe est si large qu'elles changent constamment de contexte. Deux équipes sont en mode de collaboration permanent (fusionnez-les). Vous avez une demande claire de plateforme mais pas d'équipe de plateforme.
Ne restructurez pas quand : Vous voulez juste "essayer Team Topologies." Le problème, ce sont les personnes, pas la structure. L'équipe fonctionne bien mais ne rentre pas dans la taxonomie. Vous avez réorganisé il y a moins de 6 mois.
Erreurs Courantes
Créer une équipe de plateforme trop tôt. Construire des outils que personne n'utilise pendant que les équipes stream-aligned résolvent leurs propres besoins.
Ne pas avoir d'équipes enabling du tout. Chaque initiative d'adoption devient un mandat de haut en bas ou un effort grassroots qui fizzle.
Étiqueter les équipes sans changer comment elles travaillent. Renommer "Équipe Backend" en "Équipe Plateforme" n'en fait pas une.
Ignorer la charge cognitive. Tout le framework est construit dessus. Si vous n'évaluez pas si les équipes sont surchargées, vous ratez l'essentiel.
Chez Conectia, quand nous intégrons des ingénieurs seniors LATAM dans des organisations d'ingénierie en croissance, nous prêtons une attention particulière à la structure de l'équipe. Le bon ingénieur dans la mauvaise équipe livre moins de valeur qu'un bon ingénieur dans une équipe bien structurée. Nos ingénieurs ont l'expérience des configurations distribuées multi-équipes et comprennent comment fonctionnent en pratique les dynamiques d'équipes stream-aligned, de plateforme et enabling — pas seulement en théorie.
Vous structurez vos équipes d'ingénierie pour la croissance ? Parlez à un CTO — nous plaçons des ingénieurs seniors qui comprennent les dynamiques d'équipe et s'intègrent proprement dans votre structure de squad dès la première semaine.
