Aller au contenu principal

Organiser les équipes

Résumé : votre organigramme détermine votre architecture logicielle — c'est la loi de Conway, et c'est une observation empirique remarquablement robuste. Cette leçon explique cette loi, la manœuvre inverse qui consiste à s'en servir volontairement, les quatre types d'équipes du modèle Team Topologies, et les cinq anti-modèles d'organisation DevOps les plus répandus.

1. La loi de Conway​

Pourquoi cette loi est si robuste : les composants logiciels sont conçus par des personnes qui doivent se parler. Là où la communication est facile — au sein d'une équipe — les composants sont fortement couplés et cohérents. Là où elle est difficile — entre deux services distants — les composants développent des interfaces plus explicites et plus rigides.

Le corollaire qui intéresse les dirigeants : vous ne pouvez pas décider d'une architecture qui contredit votre organisation. Beaucoup d'entreprises ont tenté d'adopter les microservices tout en conservant une organisation en silos fonctionnels. Elles ont obtenu ce qu'on appelle parfois un monolithe distribué : tous les inconvénients des microservices, aucun de leurs bénéfices.

2. La manœuvre inverse de Conway​

Ce que ce raisonnement change dans la façon de conduire une transformation : la première décision d'architecture est une décision d'organisation. C'est pourquoi les transformations DevOps qui commencent par le choix des outils échouent, tandis que celles qui commencent par redéfinir les périmètres d'équipe réussissent.

Le point W est le mécanisme profond : une équipe autonome cherche naturellement à réduire ses dépendances, parce que chaque dépendance la fait attendre. Le découplage cesse d'être une exigence imposée par un architecte pour devenir un intérêt propre de l'équipe.

3. Team Topologies — les quatre types d'équipes​

Le modèle Team Topologies, publié par Matthew Skelton et Manuel Pais en 2019, est devenu la référence en matière d'organisation des équipes techniques.

Le type 4 est le plus mal compris, et c'est dommage car c'est souvent la bonne réponse. Une équipe facilitatrice n'exécute pas le travail des autres : elle les rend capables de le faire. Elle accompagne une équipe pendant quelques semaines sur l'observabilité, par exemple, puis se retire.

C'est exactement ce qu'aurait dû être la plupart des « équipes DevOps » créées dans les entreprises. Au lieu de cela, elles sont devenues permanentes et ont pris en charge le travail — reconstituant ainsi le silo qu'elles devaient supprimer.

Le type 2 mérite une précision essentielle : le mot libre-service est déterminant. Si les équipes doivent ouvrir un ticket et attendre trois jours, ce n'est pas une plateforme, c'est un service d'exploitation rebaptisé. Une plateforme se consomme à la demande, sans intervention humaine.

4. La charge cognitive — la notion centrale​

C'est l'apport le plus utile de Team Topologies, et il corrige une naïveté du DevOps des débuts. L'idée que chaque équipe doit tout maîtriser de bout en bout est séduisante mais se heurte à une limite humaine réelle. On ne peut pas être excellent en assurance, en Kubernetes, en sécurité cloud et en observabilité simultanément.

La conséquence organisationnelle : la responsabilité de bout en bout reste l'objectif, mais elle devient tenable parce que la plateforme rend la partie technique simple à consommer. L'équipe produit reste responsable de son service en production — elle n'a simplement pas à devenir experte de l'infrastructure sous-jacente.

5. Les cinq anti-modèles à éviter​

L'anti-modèle 1 est celui qui touche le plus d'organisations, et il vient d'une intention louable : créer une équipe pour « faire du DevOps ». Mais placer une équipe entre les deux autres ajoute une transmission au lieu d'en supprimer une. Si cette équipe doit exister, elle doit être facilitatrice (elle transmet la compétence puis se retire) ou plateforme (elle fournit du libre-service), jamais intermédiaire.

L'anti-modèle 5 est le plus difficile à traiter car il ressemble à une réussite. La personne concernée est efficace, appréciée, et résout tous les problèmes. Mais elle constitue un point de défaillance unique : son départ ou son absence paralyse l'organisation. La solution passe par la documentation, le partage d'astreinte et la rotation des tâches — pas par un reproche adressé à cette personne.

6. La taille des équipes​

Le calcul du point W est plus parlant qu'un principe abstrait. Avec cinq personnes, il existe dix relations bilatérales à entretenir. Avec quinze, il en existe cent cinq. La coordination devient un travail à plein temps, et c'est mécanique — cela n'a rien à voir avec la qualité des personnes.

7. Le principe « vous le construisez, vous l'exploitez »​

Les deux conditions sont essentielles et souvent oubliées. Rendre une équipe responsable de la production sans lui donner l'autonomie de déployer ni les moyens d'agir revient à lui transférer le stress sans le pouvoir. C'est une des façons les plus efficaces de faire échouer une transformation DevOps et de faire partir les meilleurs éléments.

Sur la condition 2 : une astreinte est soutenable si l'on est rarement réveillé. Si les alertes sont nombreuses, le problème n'est pas la personne d'astreinte, c'est la conception des alertes — sujet traité dans notre cours observabilité.

Retenir en 30 secondes​

  • Loi de Conway : votre logiciel finit par ressembler à votre organigramme, que vous le vouliez ou non.
  • Vouloir des microservices avec une organisation en silos produit un monolithe distribué : tous les inconvénients, aucun bénéfice.
  • Manœuvre inverse de Conway : organisez les équipes selon l'architecture souhaitée, et laissez-la émerger.
  • La première décision d'architecture est une décision d'organisation.
  • Team Topologies, quatre types : alignée sur un flux (le principal), plateforme, sous-système complexe, facilitatrice (temporaire).
  • Une plateforme doit être en libre-service. Si l'on ouvre un ticket et qu'on attend, c'est un service d'exploitation rebaptisé.
  • Charge cognitive : une équipe ne peut pas tout maîtriser. La plateforme existe pour absorber la complexité technique.
  • Cinq anti-modèles : équipe DevOps intermédiaire (le plus répandu), exploitation renommée, développeur seul sans soutien, outillage déconnecté, héros indispensable.
  • Taille d'équipe : 5 à 9 personnes. Le nombre de relations croît de façon quadratique.
  • « Vous le construisez, vous l'exploitez » fonctionne à deux conditions : autonomie réelle et astreinte soutenable.

Suivant : Devenir DevOps : compétences, salaires et certifications →