Cet incident de 2 heures du matin t'a coûté bien plus qu'un simple temps d'arrêt

Il est 2 h 14 du matin. Une alerte sur son bipeur réveille un ingénieur de garde à cause d’un échec de paiement qui touche une partie des clients. Le temps qu’il récupère les bons journaux, qu’il recoupe l’historique des déploiements et qu’il parvienne enfin à reproduire le bug sous ses yeux, le soleil commence à se lever. 

Le rapport d’incident indiquera deux heures d’indisponibilité. Il ne dira rien de la journée que cet ingénieur vient de perdre, ni du fait que personne dans ton équipe n’aurait pu te dire à l’avance combien de temps cette étape de reproduction allait prendre.

La facture que tu ne vois pas sur la page d’état

Point clé : l’indisponibilité, c’est le coût que les clients voient ; le temps de reproduction, c’est le coût que ton équipe absorbe en silence.

Le délai de résolution est suivi sur chaque tableau de bord d’incident. Le temps de reproduction ne l’est presque jamais, alors qu’il est généralement le plus long des deux. Avant que quiconque puisse corriger quoi que ce soit, quelqu’un doit reproduire le bug exprès, avec à peu près les bonnes données et à peu près le bon trafic, sur à peu près la bonne combinaison de versions de service qui n’existe qu’en production. Rien de tout ça n’apparaît sur un tableau de bord. C’est pourtant là que passe la majeure partie du temps.

La reproduction est le goulot d’étranglement, pas le diagnostic

Point clé : la majeure partie du temps est consacrée à faire réapparaître le bug, pas à le corriger une fois qu’il est là.

Une fois que le bug se reproduit de manière fiable, la correction est généralement rapide. Ce qui prend du temps, c’est tout ce qui précède : chercher un instantané de données, scruter les différences entre l’environnement de préproduction et la production pour essayer de repérer ce qui a changé, ou simplement attendre que le bug se reproduise tout seul. Les environnements locaux sont censés refléter l’environnement de production. En pratique, c’est rarement le cas, et c’est dans cet écart que les heures s’envolent discrètement. 

Ça se voit aussi dans les chiffres : le rapport « State of DevOps » 2024 de DORA indique que les équipes d’élite mettent moins d’une heure à se remettre d’un déploiement raté, tandis que celles qui sont moins performantes mettent entre une semaine et un mois. C’est surtout la vitesse de reproduction qui fait la différence entre ces deux chiffres, et l’écart ne se réduit pas. Les données de DORA montrent que la part des équipes peu performantes est passée de 17 % à 25 % entre 2023 et 2024, tandis que celle des équipes très performantes a reculé de 31 % à 22 % sur la même période.

Ce que coûte réellement le changement de contexte à la feuille de route

Point clé : l’interruption coûte doublement, une première fois quand l’ingénieur abandonne sa tâche, et une seconde fois quand il doit se replonger dans le contexte pour la reprendre.

Être appelé pour un incident ne te fait pas forcément perdre du temps comme tu pourrais le penser. Dans une étude sur le travail interrompu, Gloria Mark et ses collègues de l’UC Irvine et de l’université de Humboldt ont découvert que les personnes interrompues en plein milieu d’une tâche la terminaient en fait plus vite que celles qui travaillaient sans interruption, non pas parce que l’interruption ne coûtait rien, mais parce qu’elles compensaient en travaillant plus vite et en écrivant moins. 

Cette compensation avait un coût réel : le groupe interrompu a fait état d’un niveau de stress, de frustration, de pression temporelle et d’effort nettement plus élevé que le groupe qui n’avait pas été interrompu. Rien de tout ça n’apparaît dans les statistiques sur le temps d’achèvement, et rien de tout ça ne se retrouve non plus dans l’analyse rétrospective.

Pourquoi l’expression « ça marche sur ma machine » persiste

Point clé : offrir aux équipes expérimentées un moyen sûr de reproduire l’environnement de production élimine les conjectures qui, en réalité, les ralentissent.

Même les équipes expérimentées se heurtent à ce mur. Leurs outils ne leur fournissent pas de copie sûre et jetable de l’environnement de production pour effectuer des tests ; elles n’ont donc d’autre choix que de lire les logs en espérant que le bug réapparaisse. 

Un environnement de test, un clone complet de l’environnement de production lancé à la demande, c’est ce qui élimine vraiment les conjectures, un point c’est tout.

Découvre comment un environnement de test full-stack se lance en quelques secondes. 

Foire aux questions (FAQ)

Pourquoi le coût d’un incident semble-t-il plus élevé après coup qu’au moment où il se produit ? 
Le compte à rebours du temps d’indisponibilité s’arrête vite. Mais celui de la reproduction et du changement de contexte continue de tourner bien après que la page d’état ait affiché « résolu ».

Est-ce un problème d’outils ou de processus ? 
Principalement d’outils. Un bon processus ne peut que contourner une étape de reproduction lente, il ne peut pas la supprimer.

Qu’est-ce qui réduit réellement le temps de reproduction ? 
Un environnement de test qui reproduit à la demande les données et la configuration de production, au lieu de deviner localement ou d’attendre que le bug se reproduise.