Je suis arrivé dans une société où le logiciel tombait trois fois par jour. Pas une fois par semaine, trois fois par jour.

Comment ils le savaient ? Parce que les clients se plaignaient et que le responsable de projet cliquait toute la journée pour savoir si ce n’était pas cassé.

Ceci n’est pas une blague : il n’y avait aucun indicateur en production… ou plutôt si, il y en avait, qui arrivaient par mail le lendemain. Une fortune avait été dépensée pour un logiciel de supervision, qui ne couvrait pas vraiment ce produit pour d’obscures raisons de licences et de coûts.

On voit rien

À chaque plantage, le même drama : il faut appeler les Ops pour dire que ça vient de planter et qu’ils redémarrent. Dès lors, le pourquoi était perdu. Quel est l’état du système ? C’est un problème de mémoire, de processeur, de disque. On ne sait pas. Pire, un redémarrage efface toute visibilité.

Pas de métriques fiables. Pas d’alerting exploitable. Pas de vision de ce qui casse, ni quand, ni pourquoi.

Organisation solide

Par contre, la structure est complète et solide: des rôles clairs, des périmètres définis, des circuits de validation, une hiérarchie fonctionnelle bien en place, avec toutes les réunions d’instance possibles qui vont avec, avec toutes les difficultés à mettre les gens autour d’une table qui vont avec.

Sauf que l’on n’a pas besoin de mettre les gens autour d’une table, on a besoin de les mettre face à un ordi, un écran de supervision (oui, un bête htop) en temps réel et des logs qu’on peut ajuster et faire défiler pour comprendre quand ça tombe.

Tout était en place, sauf le lien avec le réel.

Pas un problème d’organisation

Là où ça se complique, c’est que personne ne « fait mal son travail », vraiment. Tout le monde respecte son rôle et chacun protège son “périmètre”. Et ce n’est pas mal, c’est logique. Mais c’est aussi précisément pourquoi rien ne bouge.

C’est peut-être nul, dit comme cela, mais, si personne ne voit l’incident officiellement (au sens où on décide, dans l’entreprise, de le nommer et de lui donner une existence), il n’est sur aucun tableau de bord, il ne déclenche pas d’alerte officielle, alors « officiellement » ce n’est pas un sujet.

Donc personne n’est responsable explicitement ou bien les responsabilités sont diluées, donc inexistantes. C’est quoi ? des ops ? du dev ? Je vous assure qu’il y a de quoi devenir fou. Les ops diront « ça vient du logiciel on gère pas », les devs diront « on voit pas ce qui se passe en prod », la sécurité dira « oui mais seuls les ops peuvent regarder la prod ». Mais si personne ne peut ou sait quoi regarder, on fait comment ? Alors on “échange” de manière abstraite, on valide, on arbitre mais on n’a plus les pieds sur terre.

La structure a remplacé les faits.

Allez dire ça au chef de projet qui clique sur son logiciel toutes les heures pour savoir s’il est vivant…

Sortir de l’impasse

À ce stade, chercher « qui décide » ne sert plus à rien. Redéfinir l’organigramme ne sert à rien, ce n’est même pas le problème. Ajouter une couche de gouvernance ne fait qu’augmenter le délai entre le problème et l’action.

Et au passage n’oublions pas : ça plante trois fois par jour !

La seule chose utile, c’est de réintroduire le réel.

Il faut que les chutes soient visibles, tout comme leur fréquence, leur impact. Il faut aussi arrêter de parler de « ce qui est censé se passer » et de se dire « c’est pas normal ». Il faut se mettre à regarder ce qui se passe réellement et que cela devienne le sujet.

C’est souvent là que les tensions apparaissent.

Je me souviens quand un RSSI bloquait toute intervention directe sur la prod, par principe. Par principe il a raison, certes, mais le risque est théorique. Le blocage, lui, est réel.

La discussion n’a pas porté sur le rôle, ni sur l’autorité. C’était :

Si tu ne veux pas prendre de risque, une solution simple est de t’asseoir avec nous et superviser ce que l’on fait réellement et en direct.

À partir du moment où le rôle défensif entre dans l’exécution :

• soit il devient utile, parce qu’il y a réellement un risque réel et mesurable,
• soit il arrête de bloquer, parce que le risque abstrait ne tient plus face au réel.

Dans les deux cas, on arrête de parler, on bouge.

La structure ne peut pas tout modéliser

Ce n’est pas une remise en cause des rôles. C’est qu’ils doivent tenir face à la réalité.

Les titres sont faits pour structurer un système stable. Cette structure, ce n’est qu’un dessin abstrait de ce que l’on décide quand tout va bien, quand tout est stable, quand tout est “comme maintenant”.

Dès qu’il y a un problème à résoudre ou une évolution à porter, une nouveauté à imaginer, la structure ne tient pas. Si c’est pas dessiné dedans, cela ne peut pas exister. La structure, les titres, la hiérarchie deviennent des obstacles, par inertie.

Il faut alors ne plus parler que des faits. Le reste, on oublie.

On voit la même chose partout :

• on a des développeurs front et back, mais l’interface, les contrats d’API, la cohérence métier, ça appartient à qui ?
• on a des devs et des admin, mais la config réelle, les versions, les secrets, la charge en prod, ça appartient à qui ?
• et on peut enchaîner entre responsables sécurité et devs, architectes et PO, PO et BA, etc.

Les titres ça découpe, le réel ça traverse.

Alors, lâchons les titres quand ça brûle : on a besoin de réel, de feedback et d’action.

Les titres on les remettra après.