Humain
5. Les personnes et la culture
Pour : managers d’équipe · direction et DSIPrérequis : Aucun.
La plateforme se déploie en quelques mois ; la culture qui la fait vivre prend des années. Ce décalage explique beaucoup d’échecs : les tableaux de bord sont prêts, les SLO documentés, mais en crise les équipes reviennent à leurs anciens réflexes. Cette leçon se concentre sur ce qui est propre à l’observabilité. Deux partis pris : la transformation avance par petites cohortes et aucun outil ne remplace la conversation managériale directe.
Du gardien au médecin
Section intitulée « Du gardien au médecin »Pendant longtemps, l’exploitation a fonctionné sur un modèle de gardien : surveiller des indicateurs de santé, réagir aux alertes, escalader. La virtuosité tenait à la connaissance intime de l’infrastructure. Ce modèle se heurte à trois évolutions. Le cloud d’abord : on ne voit plus l’intérieur de la machine, on voit une API. Puis les architectures distribuées : on ne connaît pas intimement des centaines de composants. Enfin des cycles de livraison plus courts.
Le nouveau métier ressemble à celui d’un médecin : équipé de traces, de métriques et de logs corrélés, il raisonne par hypothèses et éliminations. Il sait lire le système plutôt que le connaître par cœur et il documente pour que l’équipe apprenne. Les compétences qui deviennent centrales : lire un tableau de bord, interroger des logs structurés, comprendre des dépendances, raisonner en percentiles et en SLO.
La résistance à ce changement n’est pas un manque de volonté, c’est un signal de sens : une identité professionnelle construite sur un savoir tacite est remise en cause. Trois phrases à éviter : « il faut vous adapter », « ce n’est pas si différent », « c’est l’avenir ». Trois phrases qui ouvrent : « je comprends que cette transition soit inconfortable », « ton savoir reste précieux, voici comment on le valorise », « quelles sont tes craintes concrètes ? ».
Quatre archétypes à accompagner
Section intitulée « Quatre archétypes à accompagner »| Archétype | Ce qui le motive | Trajectoire possible | Risque principal | Leviers |
|---|---|---|---|---|
| Administrateur système senior | la reconnaissance de son expertise | SRE senior, ingénieur plateforme | départ qui emporte un savoir non écrit | binôme avec un SRE plus jeune, reconnaissance publique, formation OpenTelemetry, rôle dans les SLO des systèmes historiques |
| Responsable de la supervision | l’utilité opérationnelle, moins de bruit | SRE de production, responsable d’incident | épuisement avant la transformation | astreinte saine, formation à l’ingénierie de fiabilité, valorisation du travail de réduction du bruit |
| Chef de projet infrastructure | la structure et la maîtrise | responsable produit de la plateforme, chef de projet observabilité | se retrouver sans rôle défini | mission de transformation explicite, objectifs, formation au management de produit |
| Architecte système | la cohérence et la pérennité des choix | architecte plateforme, ingénieur staff | freiner par scepticisme | l’associer tôt aux choix, en faire l’arbitre technique, lui donner une parole publique |
Le post-mortem sans blâme
Section intitulée « Le post-mortem sans blâme »Dans une organisation saine, un incident est un cadeau coûteux : il révèle un angle mort du système. Dans une organisation malade, c’est une faute à attribuer et les équipes finissent par cacher les incidents. Le post-mortem sans blâme est le rituel qui fait passer de l’une à l’autre.
Quatre règles :
- On cherche ce qui a rendu l’erreur possible, pas un coupable. Une personne qui s’est trompée en production a montré que l’erreur était possible.
- Le récit est factuel : chronologie horodatée, faits distingués des interprétations, pas de « il aurait fallu ».
- Les actions sont peu nombreuses et attribuées : quelques actions avec un porteur, une date et un critère de réussite valent mieux que cinquante sans porteur.
- Le document circule en interne, pour que les autres équipes en profitent.
Le rôle du DSI est décisif. Il doit dire publiquement qu’il ne sanctionnera pas une erreur de bonne foi commise pendant un incident. Puis il doit le prouver au premier incident sérieux, y compris en défendant l’opérateur devant le comité de direction.
Structure type : résumé, chronologie, analyse des causes, facteurs aggravants, actions correctives, enseignements et ce qui a bien fonctionné.
Une astreinte soutenable
Section intitulée « Une astreinte soutenable »Une équipe d’astreinte épuisée décide plus mal en crise, rétablit plus lentement et finit par partir. Cette dette se mesure aussi bien que la dette technique.
Des repères. Le livre Site Reliability Engineering de Google, au chapitre consacré à l’astreinte, donne trois ordres de grandeur souvent repris. Au plus 25 % du temps d’un ingénieur passé d’astreinte. Au plus deux incidents par période de douze heures. Une rotation d’au moins huit personnes pour une équipe sur un seul site (six par site sur deux sites). Ce sont des repères, pas des normes ; l’important est de choisir les vôtres et de les mesurer.
Des règles.
- Compenser. En France, le Code du travail impose que les périodes d’astreinte soient compensées, financièrement ou en repos (article L3121-9). Au-delà du droit, une astreinte non reconnue fait partir les meilleurs.
- Limiter le bruit. Une alerte la nuit doit être exceptionnelle et exiger une action humaine immédiate. Le simulateur de fatigue d’alerte estime la charge réelle d’une semaine d’astreinte.
- Respecter la déconnexion. Une personne qui n’est pas d’astreinte n’est pas appelée ; les exceptions sont écrites et compensées.
- Suivre la charge ressentie. Un indicateur subjectif mensuel, partagé en équipe, repère les dérives avant l’épuisement.
- Décompresser. Après un incident majeur, l’équipe impliquée récupère, sans avoir à se justifier.
Le DSI lui-même est en astreinte de crise permanente. Il a besoin d’un adjoint de confiance, de vraies périodes déconnectées et de protocoles d’escalade écrits.
La plateforme comme produit
Section intitulée « La plateforme comme produit »Le platform engineering traite l’infrastructure d’observabilité comme un produit dont les développeurs sont les utilisateurs. L’équipe centrale cesse de répondre à des tickets ; elle construit des outils en libre-service. Un portail développeur interne rassemble la documentation des services, les modèles d’instrumentation, les tableaux de bord types et les procédures. Exemples : Backstage, créé par Spotify et aujourd’hui projet de la CNCF, ou des solutions commerciales.
Quatre indicateurs pour piloter la plateforme, avec des cibles à fixer chez vous :
| Indicateur | Ce qu’il mesure |
|---|---|
| Délai avant le premier tableau de bord | temps entre la création d’un service et son premier tableau de bord exploitable |
| Satisfaction des développeurs | recommandation de la plateforme, mesurée chaque trimestre |
| Taux de libre-service | part des demandes résolues sans intervention de l’équipe plateforme |
| Coût par service instrumenté | dépense de la plateforme divisée par le nombre de services couverts |
Recruter, former, retenir
Section intitulée « Recruter, former, retenir »Recruter. Le marché des profils SRE et observabilité reste tendu. Pour les salaires, appuyez-vous sur une enquête de rémunération récente de votre bassin d’emploi plutôt que sur un chiffre lu dans une formation : ils évoluent trop vite. Trois canaux fonctionnent. La cooptation, avec une description de poste claire et un processus court. La reconversion interne d’administrateurs formés à l’observabilité : moins coûteuse qu’un recrutement, elle préserve la connaissance du SI. L’alternance, à condition d’un vrai encadrement.
Retenir. Cinq facteurs pèsent. Les trois premiers : la qualité de l’outillage, une culture de fiabilité où les incidents ne débouchent pas sur des sanctions, l’équilibre de l’astreinte. Viennent ensuite des parcours de carrière écrits (SRE, staff, principal, management, avec critères et rémunération). Enfin la reconnaissance, y compris publique : laisser publier, intervenir en conférence, écrire.
Exercices
Section intitulée « Exercices »- Cartographie des archétypes (deux heures) : listez les dix à vingt personnes clés de votre exploitation, rattachez chacune à un archétype, notez risques et leviers et programmez un entretien avec les deux dont le départ coûterait le plus.
- Audit d’astreinte (une demi-journée) : pour chaque rotation, relevez la taille, la fréquence de garde, les alertes nocturnes par semaine, la compensation, l’existence d’un temps de récupération. Comparez aux repères ci-dessus.
- Post-mortem rejoué (deux heures en équipe) : reprenez un incident passé, refaites le post-mortem avec les quatre règles, comparez au document d’origine. Les différences mesurent votre maturité culturelle.
Une feuille de route RH sur deux ans
| Période | Actions |
|---|---|
| Trimestre 1 | cartographie des archétypes, entretiens individuels, fiches de poste mises à jour, premier audit d’astreinte |
| Trimestre 2 | plans de formation individuels des profils seniors, post-mortem sans blâme sur deux équipes pilotes |
| Trimestre 3 | premier recrutement ciblé, premier cycle de reconversion interne, mentorat dans les deux sens |
| Trimestre 4 | revue des départs, publication des parcours de carrière, premier bilan du post-mortem sans blâme |
| Année 2 | extension à toutes les équipes, portail développeur, alternance renforcée, grille de rémunération consolidée |
Liste de contrôle du DSI
- Je connais nommément les dix personnes les plus critiques de mon exploitation
- Les archétypes et leurs trajectoires sont cartographiés
- Le post-mortem sans blâme est instauré dans au moins une équipe
- Chaque rotation d’astreinte est dimensionnée, compensée et mesurée
- Les parcours de carrière SRE et plateforme sont écrits, rémunération comprise
- Chaque profil senior a un budget et un plan de formation
- Les départs des profils SRE et plateforme sont suivis
- Je passe du temps chaque mois à écouter directement les équipes d’exploitation
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Le plan humain et le simulateur de fatigue d’alerte.
- Le budget d’erreur : des alertes multi-fenêtres qui réveillent moins souvent pour rien.