Tu avances vite. Les tâches disparaissent du board. Les messages Slack reçoivent une réponse instantanée. Les deploys partent dès que le code compile. Ça ressemble à de la vélocité. Ça a l'air d'être du progrès.

La plupart du temps, c'est du vent.

Il y a un adage qui vient des opérations militaires : ' Lentement mais sûrement, on va plus vite. ' L'idée : se précipiter génère des erreurs, les erreurs génèrent du rework, et le rework prend plus de temps que de bien faire les choses du premier coup. Agir délibérément — pas lentement, délibérément — produit des résultats plus rapides que l'agitation frénétique.

J'étais sceptique. Puis j'ai mesuré. 🧘

La taxe de la précipitation

En octobre 2025, j'ai loggué chaque tâche pendant un mois. Chacune a reçu deux timestamps : quand je l'avais ' terminée ' et quand elle était réellement terminée — plus de follow-ups, plus de bug fixes, plus de ' ah mince, j'avais oublié ce cas limite. '

L'écart entre ' terminé ' et ' réellement terminé ', c'est ce que j'appelle la taxe de la précipitation.

Type de tâche Temps pour ' finir ' Taxe (rework) Temps total Si fait délibérément
Feature dev 4 heures 2,5 heures (bugs) 6,5 heures 5,5 heures
Changements de config 15 min 45 min (mauvais env) 60 min 25 min
Réponses par email 2 min 15 min (clarifications) 17 min 8 min
Deploy 10 min 90 min (rollback + fix) 100 min 20 min
Documentation 30 min 3 heures (corrections) 3,5 heures 1,5 heure

Le pattern : se précipiter économisait 20–40 % sur la première passe et coûtait 50–200 % en rework.

Regarde la ligne deploy. Un deploy — pousser du code sur le serveur de production pour que les utilisateurs voient les changements — ça prend 10 minutes quand tu rushes, ça casse quelque chose, et ça coûte 100 minutes au total avec le rollback. Un deploy délibéré de 20 minutes avec les vérifications adéquates coûte 20 minutes. La version rushée est 5 fois plus lente.

Sur le mois complet, la taxe de la précipitation totalisait environ 12 heures par semaine. Soit 30 % du temps productif passé à réparer des dégâts auto-infligés. Le rapport DORA State of DevOps confirme ce pattern à grande échelle : les équipes avec une fréquence de deploy élevée mais des garde-fous solides surpassent systématiquement celles qui poussent vite en croisant les doigts. ⚙️

La règle des trois respirations

Après avoir vu ces chiffres d'octobre, j'ai commencé quelque chose de simple : avant toute action qui touche à la production — le système live dont dépendent les vrais utilisateurs — ou qui envoie un message à plus de 5 personnes, ou qui commit du code, je prends trois respirations. Dix secondes. Pas de la méditation. Juste une pause.

Pendant ces dix secondes, une seule question : ' Qu'est-ce que je m'apprête à faire, et qu'est-ce qui pourrait mal tourner ? '

Entre octobre 2025 et mars 2026, cette règle a empêché quatre incidents :

  • Novembre 2025, avant un deploy : ' Attends — je n'ai pas lancé les migrations en local. ' Une migration — un script qui modifie la structure de la base de données — avait un bug qui aurait supprimé définitivement une colonne de données du système de production.
  • Décembre 2025, avant un email client : ' Ça sonne agressif. Je reformule le deuxième paragraphe. ' Cette pause a sauvé la relation.
  • Janvier 2026, avant un changement de config : ' C'est la config de prod, pas de staging. ' Le staging, c'est la copie de test de ton système. J'étais sur le point de pousser des paramètres de test sur le vrai système. Le service serait tombé.
  • Mars 2026, avant de merger une PR : Une PR (pull request), c'est une modification de code en attente d'approbation par l'équipe. Quatorze fichiers modifiés, j'en avais reviewé huit. J'ai terminé la review — et trouvé une injection SQL dans le fichier 11. C'est une vulnérabilité qui permet à un attaquant de manipuler ta base de données via les champs de saisie.

Quarante secondes de pause. Ça a évité plus de vingt heures de rework. Voilà le calcul.

Pourquoi la vitesse donne une impression de productivité

La vitesse génère de l'activité visible. Les tâches se cochent. Les messages fusent. Le code arrive. Le tableau de bord des items complétés grimpe. On a l'impression de gagner.

Mais une tâche faite puis défaite — à cause d'un bug, d'un malentendu, d'un requirement oublié — a un impact net de zéro. Elle a consommé du temps deux fois en ne délivrant de la valeur zéro fois.

Tu peux bosser 60 heures et livrer moins de valeur réelle qu'une semaine de 35 heures faite délibérément. J'ai vécu les deux. Dans la semaine de 35 heures, j'ai complété chaque tâche une fois, correctement. Dans celle de 60 heures, j'ai fait la moitié des tâches deux fois — d'abord vite, puis bien.

Les opérateurs les plus efficaces que je connaisse ont l'air lents. Ils lisent le spec en entier avant d'écrire du code. Ils posent des questions de clarification avant de commencer. Ils déploient le lundi matin, pas le vendredi soir. Ils finissent moins de choses par jour et ne refont presque rien. Sur un mois, ils livrent plus. Sur un an, y'a pas photo. 📋

La lenteur comme système

' Sois plus prudent ' ne marche pas. La prochaine crise te repoussera vers la précipitation. Le principe doit vivre dans tes outils, pas dans tes intentions.

Le chirurgien Atul Gawande a défendu cette idée pour la médecine et l'aviation dans The Checklist Manifesto. La même logique s'applique aux ops.

Des checklists de deploy. Un script — pas ta mémoire — vérifie : les tests passent, les migrations testées en local, le health check à jour, le rollback prêt. Cinq minutes. Ça prévient plus d'incidents que n'importe quelle quantité de précipitation ne pourrait rattraper.

Le délai d'envoi. Rédige tes emails et messages Slack immédiatement, programme-les pour 30 minutes plus tard. Dans cette fenêtre, tu repéreras les problèmes de ton, les pièces jointes manquantes et les chiffres erronés qui auraient nécessité des follow-ups gênants.

La période de refroidissement des PR. Aucune pull request ne se merge dans les 2 heures suivant son ouverture. Même si la review prend 10 minutes, elle attend. Des yeux frais — même les tiens — fonctionnent mieux avec du recul.

Le délai de réponse aux incidents. Quand une alerte se déclenche, attends 2 minutes avant d'agir (sauf panne totale). Le handbook SRE de Google documente le même réflexe : environ 30 % des alertes se résolvent d'elles-mêmes en quelques minutes. Réagir à une alerte qui s'auto-résout gaspille du temps et risque d'aggraver les choses. Deux minutes de patience éliminent 30 % des faux départs.

Le principe du capybara

Les capybaras ne se précipitent pas. Ils ne paniquent pas. Ils restent posés dans des sources chaudes pendant que le monde s'agite autour d'eux. Et pourtant, c'est l'une des espèces les plus prospères d'Amérique du Sud — s'épanouissant là où des animaux plus agressifs peinent.

Le capybara ne survit pas en étant rapide. Il survit en étant constant, calme et délibéré. Il ne gaspille pas d'énergie sur de l'urgence fabriquée. Il préserve sa capacité pour les moments qui requièrent vraiment une action.

Presque rien n'est aussi urgent qu'on le ressent. Le message Slack qui ' a besoin d'une réponse maintenant ' peut attendre une heure. Le bug ' critique ' est généralement important mais pas urgent. Le deploy qui ' doit sortir aujourd'hui ' doit généralement juste sortir cette semaine. La vraie urgence — service down, fuite de données, incident de sécurité actif — ça arrive peut-être une fois par mois. Tout le reste est fabriqué par une mauvaise planification, des priorités floues, ou cette croyance culturelle que plus vite veut toujours dire mieux.

Quand tu arrêtes de traiter tout comme urgent, deux choses se produisent. La qualité de ton travail augmente. Et quand quelque chose est vraiment urgent, tu as la capacité de gérer — parce que tu n'as pas cramé tes réserves en traitant des tâches routinières comme des urgences. 🍵

Agis délibérément. Construis des choses qui ne cassent pas. L'équipe qui déploie calmement le lundi surpassera toujours celle qui déploie en panique le vendredi — non pas parce qu'elle a plus de talent, mais parce qu'elle ne passe pas la moitié de sa semaine à nettoyer des dégâts auto-infligés.

Lentement mais sûrement. Et la vitesse, paradoxalement, ralentit tout. 🫶