Situation réelle

“Alice est en vacances ? On attend son retour, elle est la seule à comprendre ce système.” Alice n’est pas valorisée, elle est prisonnière. Et l’organisation est fragile.

Ce que j’ai observé : les organisations créent involontairement des prisonniers de la connaissance. “Expert indispensable” sonne comme une valorisation, c’est souvent une cage.

Le faux problème

Le faux problème serait de croire que l’expertise concentrée est un atout. En réalité, c’est un risque majeur (bus factor = 1) et une injustice pour l’expert.

Un autre faux problème : penser que la rotation crée de l’inefficacité. En réalité, elle crée de la résilience et de l’opportunité de croissance.

Le vrai enjeu CTO

Le vrai enjeu est de distribuer la connaissance sans perdre l’expertise :

Les 4 types de silos toxiques :

Silo 1 - L’expert prisonnier : Pattern : une personne seule comprend système critique. Conséquences : impossible de partir en vacances sereinement, pas d’évolution de carrière (remplaçant introuvable), burn-out (pression constante). Cause : pas de documentation, pas de formation, rétention de connaissance (volontaire ou non).

Silo 2 - L’équipe cloisonnée : Pattern : équipe A ne comprend rien au domaine équipe B. Conséquences : dépendances bloquantes, frustration, guerre de territoire, lenteur. Cause : absence de rotation, pas de partage cross-équipe.

Silo 3 - Le legacy abandonné : Pattern : système legacy que personne ne veut toucher. Conséquences : dette technique, risque sécurité, innovation bloquée. Cause : connaissance perdue (départs), pas de transmission.

Silo 4 - La documentation morte : Pattern : doc existe mais obsolète ou incompréhensible. Conséquences : documentation ignorée, connaissance reste dans têtes. Cause : doc écrite une fois, jamais maintenue.

Le framework de rotation :

Niveau 1 - Rotation des astreintes : Principe : astreinte tourne entre 3-5 personnes minimum. Bénéfice : distribution connaissance production, pas de burn-out astreinte. Durée : rotation hebdomadaire ou mensuelle. Préparation nécessaire : runbooks, playbooks, formation.

Niveau 2 - Rotation des responsabilités techniques : Principe : ownership code/système tourne tous les 6-12 mois. Bénéfice : distribution expertise, opportunité apprentissage, pas de prisonnier. Durée : 6-12 mois par rotation. Préparation nécessaire : documentation, période overlap, formation.

Niveau 3 - Rotation cross-équipe : Principe : devs passent 10-20% temps à aider autre équipe. Bénéfice : compréhension système global, collaboration renforcée. Durée : 1 jour/semaine ou 1 sprint/trimestre. Préparation nécessaire : accords inter-équipes, objectifs clairs.

Niveau 4 - Rotation de rôle : Principe : dev fait du product 20%, product fait du code 20%. Bénéfice : empathie, compréhension contraintes, meilleure collaboration. Durée : 1 jour/semaine pendant 1-3 mois. Préparation nécessaire : volontariat, accompagnement.

Cadre de décision

Voici comment je structure la rotation :

1. Identifier les silos critiques Audit : qui est seul sur quoi ? Quel bus factor = 1 ? Ces données révèlent fragilités.

2. Prioriser par risque Critère : impact si personne part × probabilité départ. Commencer par risque le plus élevé.

3. Créer plan de distribution Pour chaque silo : documentation (pourquoi, comment), formation (1-2 personnes), rotation (ownership change tous les 6-12 mois). Ce plan systématise distribution.

4. Mesurer bus factor Métrique : bus factor minimum 2 sur systèmes critiques, idéal 3. Tracker trimestriellement. Cette mesure force action.

5. Valoriser le partage Évaluation inclut : “A-t-il documenté son domaine ? Formé des backups ?” Ce critère change comportements.

Retour terrain

Ce que j’ai observé dans différentes organisations :

Le prisonnier révolté : Alice, experte base de données, seule à comprendre. Impossible partir en vacances, impossible évoluer (irremplaçable). Démission brutale. Résultat : 6 mois de chaos, incident majeur.

La rotation qui libère : Bob, expert infra. CTO impose : “Tu formes 2 backups ce trimestre. C’est dans tes objectifs.” Documentation créée, 2 personnes formées. 6 mois plus tard : Bob prend nouveau rôle architecture, serein. Résultat : Bob évolue, équipe résiliente.

L’exemple cross-équipe : Dev backend passe 1 jour/semaine avec équipe front. Après 3 mois : comprend contraintes front, APIs mieux designées, collaboration fluide. Résultat : efficacité globale augmente.

Le bus factor qui force action : Audit révèle : 5 systèmes critiques bus factor = 1. Actions : documentation obligatoire + formation 2 backups/système + rotation 12 mois. 1 an plus tard : bus factor minimum 2 partout. Résultat : organisation résiliente.

Erreurs fréquentes

Valoriser l’indispensabilité “Alice est indispensable.” Résultat : Alice prisonnière, organisation fragile.

Rotation sans préparation Changer ownership sans doc ni formation. Résultat : chaos, baisse qualité.

Pas de mesure bus factor Ne jamais auditer. Résultat : découverte tardive lors départ.

Documentation sans maintenance Doc écrite une fois, jamais mise à jour. Résultat : doc inutilisable, connaissance reste dans têtes.

Si c’était à refaire

Avec le recul, voici ce que je ferais différemment :

Audit bus factor trimestriel Identifier systèmes bus factor = 1. Prioriser actions. Cette régularité détecte fragilité tôt.

Objectif partage dans évaluations Critère éval : “A documenté domaine ? A formé backups ?” Cette valorisation change comportements.

Rotation astreinte obligatoire Minimum 3 personnes par astreinte, rotation mensuelle. Cette distribution évite burn-out.

Time budget documentation 10-15% temps dédié documentation et partage connaissance. Ce temps budgété évite “pas le temps”.

Pour approfondir

Le livre "Être ou ne pas être CTO" explore comment créer une organisation résiliente sans silos.

Pour approfondir, tu peux aussi consulter l’article "Former sans infantiliser" ou les autres contenus du pilier "Culture & management".