04. La compétence est une propriété du système

Le confort d'être indispensable

Toutes les organisations en ont. Et c'est difficile s'en défaire.

Le gourou.
Le superhéros.
La rock star.

La personne qu'on va toujours voir.
Celle qui règle les incidents à 2 h du matin.
Celle à qui on confie "les choses importantes".

Chez JPSoftWorks, on les connaît bien. Soyons honnêtes: plusieurs d'entre nous ont déjà été cette personne‑là. Et on le dit au passé, parce que personne ne le reste longtemps.

Et au début, ça fait du bien.
Reconnaissance. Statut. Sécurité.

Mais voici la vérité, apprise parfois à nos dépens:

Une personne indispensable ne rend pas un système fort. Elle le rend fragile.

Plus une organisation se dit "DevOps", plus cette fragilité devient dangereuse: parce qu'elle est en contradiction directe avec ce qu'on prétend construire. Un système résilient.

Pensée systémique: Les humains peuvent être des contraintes

Dans le tenet précédent, on parlait des contraintes.
Pas comme des excuses, mais comme des réalités structurelles.

Certaines contraintes sont techniques:

• Pipelines lents
• Tests manuels
• Environnements instables

D'autres ont un visage humain.

Si:

• Une seule personne peut déployer en prod sans stress
• Une seule personne comprend vraiment l'architecture
• Une seule personne sait répondre à un incident majeur
• Une seule personne maîtrise la sécurité

Alors cette personne est la contrainte.

Pas parce qu'elle est lente, pas parce qu'elle est malicieuse.
Mais parce que le système a été conçu, en dépendant d'elle.

Le bus factor: Appelons les choses par leur nom

Chez JPSoftWorks, on ne tourne pas autour du pot.

Bus factor (le test de l'autobus): nombre de personnes qui devraient disparaître pour que le système cesse de fonctionner.

Un "bus factor" de 1 n'est pas impressionnant.
C'est un risque opérationnel majeur.

Mais ce concept est rarement présenté aussi crûment. Comme on disait plus tôt, on préfère des termes plus flatteurs:

• Gourou
• Superhéros
• Rock star
• Personne clé

Même problème. Meilleur marketing.

Pourquoi la culture des héros est si populaire

Soyons lucides: si la culture des héros persiste, c'est parce qu'elle est récompensée.

Pour les individus:

• Reconnaissance
• Sentiment d'importance
• Sécurité d'emploi
• Identité professionnelle forte

Pour les gestionnaires:

• Un seul point de contact
• Moins de coordination
• Impression de contrôle
• Résultats rapides à court terme

Tout le monde gagne… jusqu'au jour où le système commence à craquer.

Parce que la culture des héros optimise le sauvetage, pas la durabilité.

Le coût caché du héros

Avec le temps, la dette s'accumule.

On observe:

• Les incidents toujours escaladés vers les mêmes personnes
• Une charge on‑call concentrée
• Des automatisations bloquées ("seul X peut toucher à ça")
• Peu de documentation utile
• Des SLOs manqués quand le héros est absent

Puis arrivent:

• Les épuisements
• Les départs
• Ou pire: l'échec silencieux

Personne n'est mal intentionné.
Le système est simplement mal conçu.

DevOps exige une compréhension partagée du cycle de vie

C'est ici que DevOps cesse d'être une question d'outils.

Si DevOps vise à unir Dev et Ops, alors chaque préoccupation du cycle de vie doit être comprise par tous:

• Comment on construit
• Comment on déploie
• Comment ça brise
• Comment on récupère
• Comment on gère le risque

Cela ne veut pas dire que tout le monde fait tout.

Cela veut dire:

• Les développeurs comprennent l'impact opérationnel
• Les Ops comprennent les compromis de développement
• La sécurité comprend la pression de livraison
• Le produit comprend le risque technique

Les compétences se chevauchent.
Les responsabilités restent claires.

Le savoir tribal est un risque de gouvernance

Parlons gouvernance, sans détour.

Le savoir enfermé dans une tête:

• N'est pas auditable
• N'est pas testable
• N'est pas transférable
• N'est pas améliorable

"Demande à Alice" n'est pas un contrôle.
C'est une vulnérabilité.

Du point de vue d'un CISO, d'un auditeur ou d'un régulateur, le savoir tribal équivaut à de l'infrastructure non documentée.

La maturité DevOps, c'est traiter la connaissance comme un actif du système: pas comme une propriété personnelle.

Cartographier les compétences: Rendre l'invisible, visible

Assez de théorie. Parlons ingénierie.

Chez JPSoftWorks, la cartographie des compétences n'est pas un exercice RH.
C'est un outil de diagnostic systémique.

Objectif:

Identifier où le système dépend dangereusement de trop peu de personnes.

La grille de compétences (simple, mais puissante)

La grille est volontairement simple.

• Lignes: capacités, compétences dont le système dépend
• Colonnes: personnes réelles
• Cellules: score de 0 à 9 représentant la capacité réelle

Pas le potentiel.
Pas le titre.
La capacité à agir correctement aujourd'hui.

Échelle de notation

Les 9 doivent être rares.
Sinon, la grille ment. Reprenez.

Exemple de grille

Vert = sain.
Rouge = vulnérable.

Lire la grille: Ce qu'elle révèle immédiatement

• Alice est une contrainte majeure
• La réponse aux incidents a un bus factor de 1
• La sécurité dépend d'une seule personne forte
• Carol et Dave sont déconnectés de l'opérationnel

Cela explique:

• Les escalades fréquentes
• Le stress en production
• La lenteur des automatisations
• Le clivage Dev / Ops

La grille n'accuse personne.
Elle montre la réalité.

Règle culturelle nº1: Pas d'auto‑évaluation isolée

C'est essentiel.

Les scores doivent être:

• Discutés en équipe
• Ajustés collectivement
• Basés sur des faits

Sinon, l'exercice devient politique. Et inutile.

La sécurité psychologique est un prérequis absolu.

Combler les écarts: Par conception, pas par pression

Une fois les écarts visibles, la solution n'est pas "travailler plus fort".

Ce qui fonctionne réellement:

• Pairing sur du vrai travail
• Rotation on‑call progressive
• Documentation écrite pendant l'exécution
• Automatisation des zones fragiles
• Création de plateformes et de "paved roads"

Le but n'est pas de remplacer les experts.
C'est de les multiplier et de les étendre.

L'automatisation comme diffusion du savoir

L'automatisation n'est pas qu'un gain de vitesse.

C'est un mécanisme de diffusion de la connaissance.

Chaque automatisation:

• Encode une expertise
• Réduit la dépendance humaine
• Abaisse le seuil de compétence nécessaire

On ne supprime pas les humains.
On les libère de leur rôle de goulot.

Le dilemme du gestionnaire

C'est ici que la culture est mise à l'épreuve.

Les gestionnaires doivent:

• Cesser de récompenser l'indispensabilité
• Arrêter de glorifier l'héroïsme comme norme
• Protéger le partage de connaissance
• Valoriser la redondance

Oui, ça semble plus lent au début.
Et oui, ça l'est.

Mais c'est le seul chemin vers une livraison durable.

Anti‑patterns fréquents

• Promotions basées sur l'irremplaçabilité
• Documentation facultative
• Formation déconnectée du travail réel
• Héros qui empêchent l'apprentissage collectif
• Silence récompensé plus que collaboration

L'héroïsme est souvent le symptôme d'un échec systémique antérieur.

Le gain culturel

Quand les compétences se chevauchent:

• Les incidents deviennent plus calmes
• L'on‑call devient humain
• L'automatisation s'accélère
• La confiance augmente
• L'absence ne fait plus peur

C'est ça, DevOps vécu: pas vendu. Si c'était facile, tout le monde le ferait. (Merci Carl)

Mise en œuvre concrète

Ce qui fonctionne dans la vraie vie:

• Cartographie trimestrielle
• Liens clairs avec les budgets de formation
• Automatisation ciblée sur les zones rouges
• Rotation planifiée des responsabilités
• Discussion explicite du bus factor

Habitudes à changer:

• Rendre visible le partage de savoir
• Célébrer la redondance
• Traiter l'apprentissage comme de la livraison

Mot de la fin

DevOps ne crée pas des héros.
Il les rend inutiles.

Si votre système dépend de quelques personnes, il est fragile.
Si les compétences se chevauchent, il devient résilient.

Chez JPSoftWorks, on ne cherche pas qui sait le plus.
On cherche où le système est vulnérable: puis on le redessine pour que personne n'ait à le porter seul.

Si ce texte vous rend un peu inconfortable, c'est bon signe.
Ça veut dire que vous regardez le système honnêtement.

Et si vous voulez cartographier vos compétences, réduire votre bus factor ou sortir de la culture des héros, on est là.

Références