Razowski ! Tu as oublié de mettre à jour ton ticket Jira !

Les processus, c'est bien, mais parfois...réfléchir c'est mieux.

“Je ne peux pas regarder ton problème tout de suite. Il faut d’abord que tu crées un ticket Jira, que tu l’assignes au bon Epic, et qu’on le vote au prochain sprint planning.”

15h, un vendredi.

Tout le monde est en mode déploiement. Des semaines de préparation. Une équipe qui a mis les bouchées doubles. Un client qui attend.

Et là, le CAB rejette ta demande.

Motif : l’approbation client n’est pas dans le billet.

Sauf qu’on le sait, nous, que le go est là. Le client a confirmé. Verbalement, dans des réunions, dans le contexte du projet. Tout le monde autour de la table est au courant.

Il manque juste l’email. Le bon email, avec les bons mots, dans la bonne boîte, archivé au bon endroit.

15h10. La course commence. On appelle le client. On explique la situation. On attend. On relance. On tourne en rond dans un corridor imaginaire pendant que le chrono tourne et que le weekend de déploiement se raccourcit à vue d’oeil.

On a fini par avoir l’email. On a déployé. Tout s’est bien passé.

Mais j’y ai repensé longtemps après. Pas à cause de ce déploiement-là. À cause de ce que cette scène révélait sur comment on fonctionne dans nos organisations.

Le CAB n’avait pas tort d’exiger une approbation client. C’est une bonne pratique, dans le sens premier du terme, avant qu’on en fasse un slogan vide.

Le problème, c’est qu’à aucun moment dans ce processus, quelqu’un n’avait eu le mandat de dire : “On connaît la situation. On sait que le client est ok. Qu’est-ce qu’on fait?”

Personne n’avait le droit de penser. Juste de vérifier que les cases étaient cochées.

Le contexte qu’on n’ose pas nommer

Les processus, à la base, c’est une réponse à de vrais problèmes.

ITIL existe parce que des systèmes critiques ont planté faute de coordination. Agile existe parce que des projets ont dérivé pendant des années sans livrer de valeur. Les CAB existent parce que des déploiements mal planifiés ont causé des pannes en production.

Ce n’est pas ça, le problème.

Le problème, c’est ce qui arrive quand le processus perd son créateur original et tombe entre les mains de gens qui ne savent plus pourquoi il existe.

Dans la majorité des organisations TI que j’ai traversées au Québec depuis 2010, les processus ne servent plus vraiment à coordonner le travail. Ils servent à gérer la trace.

Qui a approuvé quoi. Qui a signé. Qui peut prouver qu’il a fait sa part.

Un ticket Jira ouvert, c’est une preuve d’existence. Un formulaire rempli dans ServiceNow, c’est une absolution anticipée. Une porte de gouvernance franchie dans les règles, c’est une assurance-responsabilité.

Les processus sont devenus des boucliers.

Et un bouclier, par définition, n’est pas conçu pour avancer. Il est conçu pour protéger. Pour ne pas bouger.

Ce glissement n’est pas annoncé. Il arrive progressivement, pendant des années, à travers des centaines de petites décisions qui semblent raisonnables prises séparément. Et un matin, tu te retrouves dans une organisation où plus personne n’a vraiment le droit de penser.

Juste de suivre.

L’anthropologue David Graeber, qui a passé sa carrière à étudier la bureaucratie, décrit un mécanisme précis pour ce genre de situation. Une procédure anodine, en apparence neutre, peut créer une forme d’aveuglement volontaire chez ceux qui l’appliquent. Pas par méchanceté. Par confort.

C’est exactement ce qui s’est passé un vendredi à 15h. Personne au CAB n’était de mauvaise foi. Tout le monde appliquait la règle telle qu’écrite. Et c’est précisément ça qui rend la chose invisible. La coercition ne ressemble pas à de la coercition quand elle porte un nom de champ obligatoire dans un formulaire.

Le diagnostic

Pour comprendre pourquoi ça arrive, il faut remonter aux post-mortems.

Mais il faut aussi regarder ce que Henry Mintzberg a documenté il y a plus de cinquante ans et que personne ne lit vraiment dans les équipes TI.

Mintzberg a observé directement le quotidien de dirigeants, minute par minute, pendant des semaines.

Sa conclusion a démoli les manuels de gestion.

Le travail réel n’a presque rien à voir avec les quatre fonctions classiques qu’on enseigne encore, planifier, organiser, coordonner, contrôler.

Le vrai travail, c’est de la fragmentation. Des interruptions constantes. Des décisions prises en quelques secondes sur des dossiers qui n’ont aucun rapport entre eux.

Il aurait regardé nos tableaux Jira avec leurs colonnes bien propres, à faire, en cours, en test, terminé.

Et il aurait dit ce qu’on sait déjà sans oser le nommer.

Ces outils reposent sur l’illusion que le développement logiciel est un fleuve tranquille et linéaire. Ce n’est pas une description du travail réel. C’est une fiction rassurante pour les gens qui ne font pas le travail.

Et quand la fiction devient la norme, voici ce qui arrive concrètement. L’équipe passe plus de temps à nourrir la bête qu’à livrer. Mettre à jour les tickets. Justifier les heures. Ajuster les statuts pour que les graphiques de vélocité soient présentables en comité.

Ce n’est pas une impression isolée. Sur les forums de discussion entre développeurs, le même constat revient depuis deux ans, presque mot pour mot. Des ingénieurs qui passent plus de temps à expliquer un ticket Jira qu’à écrire du code. Agile, qui devait fluidifier le travail, a fini par créer sa propre couche de surcharge administrative. La valeur s’est déplacée du code vers la justification du code.

Jira cesse d’être un outil d’organisation. Il devient un instrument de micro-gestion qui documente l’activité sans jamais mesurer ce qui compte.

Pour comprendre pourquoi les équipes en arrivent là, il faut revenir aux post-mortems eux-mêmes.

Quelqu’un a fait un déploiement sans suivre le processus. Ça a mal tourné. La rétrospective a conclu : on aurait dû suivre le processus. La leçon gravée dans la culture : ne jamais dévier.

L’équipe SRE de Google, qui a probablement rédigé plus de post-mortems que n’importe quelle autre organisation au monde, a documenté ce piège précisément.

Tant qu’un post-mortem cherche un coupable plutôt que les raisons systémiques pour lesquelles une équipe disposait d’une information incomplète, l’organisation n’apprend rien.

On ne répare pas les gens. On répare les systèmes.

Le terme qu’ils utilisent, “sans blâme”, est mal compris presque partout où je l’ai vu appliqué. Ça ne veut pas dire qu’il n’y a pas de conséquences. Ça veut dire qu’on part du principe que tout le monde, dans la salle, avait de bonnes intentions et a agi avec la meilleure information disponible sur le moment.

Ce qu’on n’a jamais dit dans nos rétrospectives à nous : le processus était peut-être inadapté à la situation. Ou la personne manquait de contexte, pas de permission. Ou le vrai problème était technique et pas procédural, mais blâmer le manque de rigueur est tellement plus propre politiquement.

Alors on ajoute une étape. Une approbation supplémentaire. Un champ obligatoire de plus dans le formulaire. Une notification automatique si quelqu’un essaie de sauter une case.

Chaque couche nouvelle semble raisonnable. Prises ensemble, elles construisent une cage.

Il y a aussi quelque chose de plus difficile à nommer, mais que j’ai vu souvent.

Les gestionnaires qui ne maîtrisent pas le fond technique de ce que fait leur équipe utilisent les processus pour masquer ce vide.

Si tu ne comprends pas vraiment ce qui se passe dans le code, dans l’architecture, dans les dépendances système, tu ne peux pas exercer de jugement sur les cas limites. Alors tu t’accroches aux règles. Tu exiges que le processus soit suivi parce que le processus, au moins, tu le comprends.

Le processus devient une prothèse intellectuelle pour quelqu’un qui a perdu confiance en sa propre capacité à lire la situation.

De l’autre côté, les développeurs et les analystes apprennent vite. Si sortir des sentiers battus coûte de l’énergie politique, si justifier une décision de bon sens nécessite trois niveaux d’approbation, ils arrêtent d’essayer. Ils ouvrent des tickets. Ils attendent. Ils font ce qui est demandé, pas ce qui est nécessaire.

Ce n’est pas de la paresse. C’est de la rationalité dans un système qui punit le jugement.

Le miroir

Mintzberg dirait que le vrai travail de l’expert, c’est précisément de naviguer le chaos. De répondre aux urgences non planifiées. De s’adapter quand un déploiement plante un vendredi après-midi.

On ne peut pas coder l’imprévisible.

Alors voici la question que je veux te poser.

La dernière fois que tu as suivi un processus qui n’avait manifestement pas de sens dans ton contexte, qu’est-ce que tu t’es dit pour le justifier?

“C’est pas moi qui ai inventé cette règle.” “Au moins, j’ai le ticket.” “Si ça tourne mal, j’ai une trace que j’ai suivi le processus.”

Est-ce que tu travailles pour ton outil, ou est-ce que ton outil travaille pour toi?

Parce que si c’est toi qui passes tes vendredis à nourrir Jira plutôt que Jira qui t’aide à livrer, la réponse est là.

Et quelque part, tu la connais déjà.

L’action

Ce que tu peux faire dès lundi matin.

Quatre pistes concrètes. Pas de théorie supplémentaire. Que de l’action.

Première piste. Change la question qu’on pose face à une exception.

La prochaine fois que quelqu’un vient te voir avec une urgence qui ne rentre pas dans le processus, ne commence pas par “est-ce que le ticket est ouvert?”

Commence par : “Qu’est-ce qu’on perd si on attend? Qu’est-ce qu’on risque si on n’attend pas?”

Mets les deux faces sur la table. Le risque de la déviation et le risque du respect aveugle. Dans la majorité des cas, la réponse va être évidente. Et si tu n’es pas le décideur, escalade avec ces éléments-là, pas avec un formulaire.

Formulation exacte que tu peux utiliser.

“J’ai une situation qui ne rentre pas dans le processus standard. Voici le contexte, voici ce qu’on perd à attendre, voici ce que je propose. Est-ce que tu m’autorises à aller de l’avant?”

Deuxième piste. Rends le coût du processus aussi visible que le coût de la déviation.

Les défenseurs des processus comptent uniquement le risque de ne pas les suivre. Personne ne compte le coût de les suivre aveuglément. Heures perdues à nourrir des tickets. Clients impactés. Déploiements ratés. Talent qui part parce qu’il n’a plus le droit d’utiliser son cerveau.

Commence à documenter ce coût. Juste pour le rendre visible. Ce qui est invisible n’existe pas.

“Ce vendredi-là, la course pour obtenir un email d’approbation que tout le monde savait déjà accordé nous a coûté X heures. Le déploiement a été retardé de Y heures. Voici ce que ça a coûté au projet.”

Les gens qui défendent les processus adorent les chiffres. Donne-leur des chiffres. Les leurs, retournés contre eux.

Troisième piste. Crée une porte d’exception officielle dans le processus lui-même.

C’est la piste la plus puissante culturellement. Plutôt que de combattre le processus de front, tu l’amendes. Tu proposes d’y inscrire formellement un protocole d’urgence. Voici les critères qui définissent une urgence de niveau 1. Voici qui a l’autorité de l’approuver. Voici comment on le documente dans les 24 heures qui suivent.

L’exception devient une porte légale, pas une infraction. Ça change tout. Les gens osent l’utiliser. Les gestionnaires ne peuvent plus bloquer en disant “on n’a pas suivi le processus”, parce que suivre le processus d’exception, c’est aussi suivre le processus.

Ce n’est pas contourner le système. C’est le réécrire pour qu’il ait une sortie de secours.

Quatrième piste. Change le langage de tes post-mortems avant de changer tes processus.

Tant que ta rétrospective cherche qui a dévié, elle va produire la même conclusion à chaque fois, plus de règles. Pose plutôt la question que les équipes SRE les plus matures posent en premier : quelle information manquait à la personne, sur le moment, pour prendre une autre décision?

Si la réponse est “rien ne manquait, elle avait juste pas le droit de l’utiliser”, tu viens de trouver ton vrai problème. Et ce n’est pas un problème de discipline. C’est un problème d’autorité mal distribuée.

Identifie ensuite le propriétaire du processus qui te bloque. Pour chaque processus qui paralyse ton équipe, pose cette question : “Qui est le propriétaire de ce processus? Qui a le mandat de le modifier?”

La réponse est souvent : personne. Le processus existe parce qu’il a toujours existé. Il n’a plus de parent. Il a survécu à la personne qui l’a créé et à toutes les réorganisations depuis.

Un processus sans propriétaire est disponible à l’adoption. Quelqu’un avec de la crédibilité et un peu d’énergie peut proposer une révision, animer un atelier, et sortir avec quelque chose de plus utile.

Ce quelqu’un peut être toi.

Ce n’est pas une révolution. C’est de la maintenance organisationnelle. Et c’est précisément le genre de travail que personne ne fait parce que ça ne rentre dans aucun ticket Jira.

Si tu veux arrêter de perdre tes vendredis à nourrir des outils qui ne travaillent plus pour toi, et que tu veux ma méthode complète, le Cadre de Décision avec Friction Minimale, pour distinguer les processus qui protègent vraiment de ceux qui servent juste de boucliers organisationnels.

Mintzberg l’a écrit il y a cinquante ans. Le chaos fait partie de la job. C’est ton expertise qui permet de le dompter.

La question, c’est : dans ton organisation, qui a encore le droit d’exercer cette expertise?

Ou est-ce que tout le monde attend le prochain sprint planning?