Que faites-vous pour éviter que l'équipe dépende trop fortement d'une seule personne ?

Question

Accepted Answer

**Un faible bus factor est un risque que je gère délibérément, de la même façon que je gère tout point de défaillance unique.** Si une seule personne peut déployer, déboguer le service de paiement ou toucher au module legacy, l'équipe est à une démission ou des vacances d'une crise. L'objectif est de diffuser la connaissance sans tout ralentir au point mort.

## Mécanismes pratiques

- **Des code reviews avec intention.** Les reviews ne sont pas que du gatekeeping ; c'est du transfert de connaissance. Je m'assure qu'aucun domaine n'est relu uniquement par celui qui l'a écrit.
- **Pairer et faire tourner sur les systèmes critiques.** J'assigne délibérément du travail dans les zones à haut risque à une deuxième personne, même quand l'expert irait plus vite. Coût à court terme, assurance à long terme.
- **De la documentation qui mérite sa place.** Pas des wikis exhaustifs que personne ne lit, mais l'essentiel porteur : runbooks, décisions d'architecture, « comment déployer », « quoi faire quand X casse ».
- **Rotation d'on-call.** Rien ne diffuse plus vite la connaissance opérationnelle que chacun prenant son tour d'être responsable de la production.
- **Talks internes / brown bags.** Le propriétaire d'un sous-système délicat le présente à l'équipe.

## Comment je trouve le risque

- Cartographier honnêtement la propriété : pour chaque système critique, demander « qui d'autre pourrait gérer ça si X était absent deux semaines ? » Si la réponse est « personne », c'est un risque signalé.
- Guetter le **pattern du héros** — la personne qui est toujours celle qu'on page, toujours la réponse. C'est un signal d'alerte, pas une force.

## Pièges

- **La rétention comme sécurité d'emploi.** Certains ingénieurs (et certains managers) aiment être indispensables. Je le recadre : être le goulot d'étranglement bloque votre propre promotion et votre temps de repos.
- Sur-corriger vers « tout le monde fait tout », ce qui détruit la profondeur. L'objectif est l'absence de point de défaillance unique, pas zéro spécialisation.
- Écrire la doc une fois et la laisser pourrir ; une doc périmée est pire que pas de doc.

## Pourquoi c'est important

Réduire le bus factor protège la livraison contre les maladies, les vacances et les démissions, et libère vos meilleurs éléments pour grandir au lieu d'être prisonniers à maintenir la chose que seuls eux comprennent. Cela rend aussi l'équipe plus saine : la propriété partagée bat l'héroïsme fragile.