La suite de tests qui a mangé la livraison : quand relever le délai cache la cause

Un vendredi à 19 h 05, la nouvelle version du site institutionnel n'est pas sortie : le build tournait depuis 99 minutes sur un plafond de 100, et à la 100e minute le système l'a coupé.

Le build, c'est le pipeline de livraison : il compile, exécute la suite de tests automatisés et prépare la version. Aucun test n'a échoué. Ils n'ont simplement pas fini à temps, et la chaîne de livraison a fait ce qu'elle devait faire : s'arrêter. La version contenait une modification de texte et une correction du formulaire de contact, et le marketing en avait besoin ce jour-là : une campagne démarrait le lundi.

Dans le canal de l'équipe, quelqu'un a écrit ce que tout le monde pensait : « Et si on le montait à 120 ? »

La question qui vous concerne est autre : combien de fois votre équipe a-t-elle relevé un délai maximal cette année, et combien de fois quelqu'un a-t-il demandé pourquoi c'était nécessaire ?

Une précision avant de commencer : ceci est un scénario hypothétique et illustratif. L'équipe, le site et les chiffres sont inventés et ne décrivent aucun client de Hábil. Le schéma apparaît dans de nombreuses équipes et commence souvent de la même manière : un défaut de conception masqué par un correctif qui semble raisonnable. Ce qui provient de sources publiées porte son numéro de référence ; lorsqu'il s'agit de notre propre lecture, nous le disons.

En 1 minute

• Le risque : traiter la durée des tests comme un problème de configuration : chaque fois que la livraison approche de la limite, quelqu'un relève la limite et la cause continue de grandir.
• Le cas : en cinq semaines, le plafond du build est passé de 30 à 100 minutes. La cause était là dès le premier jour : chaque fichier de test reconstruisait le site entier avant de vérifier sa propre partie. Aucun correctif ne l'a touchée.
• Ce que coûte l'inaction : une livraison bloquée le jour où le métier en avait besoin, une campagne sans sa page et une équipe qui cesse de faire confiance à ses propres alarmes. Pour la validation qui s'exécute à chaque changement, Fowler reprend une règle d'environ dix minutes [1] et DORA, une limite d'environ 10 minutes pour les tests [2] ; dans cette équipe, l'étape de tests a fini à environ 58 minutes et le plafond à cent.
• Ce que vous devez décider lundi : que la durée des tests ait un budget et soit comparée d'une version à l'autre, et qu'aucun correctif ne soit accepté s'il n'explique pas la cause, qu'il soit proposé par une personne ou par un assistant d'intelligence artificielle.

Dans cet article

1. Que s'est-il passé le vendredi où la livraison n'est pas sortie ?
2. Comment en est-on arrivé à cent minutes en cinq semaines ?
3. Quelle était la vraie cause ?
4. Pourquoi aucun correctif n'a-t-il résolu le problème ?
5. Que dit la pratique du secteur sur la durée d'une livraison ?
6. Quelles trois règles changent l'histoire ?
7. Quel rôle a joué l'intelligence artificielle ?
8. À quoi ressemble la version ennuyeuse de cette histoire ?
9. À retenir
10. Que fait Hábil ?
11. Questions fréquentes

Que s'est-il passé le vendredi où la livraison n'est pas sortie ?

La livraison ne s'est pas arrêtée à cause d'une erreur dans le code : elle s'est arrêtée parce que les tests ont pris plus de temps que celui qui leur était accordé.

Mieux vaut distinguer deux horloges dès le départ, car dans cette histoire on les confond facilement :

Le plafond est une permission. La durée est un fait. Relever la permission ne change pas le fait ; cela change seulement le moment où vous l'apprenez.

Le site était le site institutionnel d'une entreprise de taille moyenne : quelques pages en espagnol et en anglais, un formulaire et une rubrique d'actualités. Rien de critique. C'est pourquoi le cas est utile : le même schéma peut toucher des systèmes plus critiques, avec un impact qui dépend de leur architecture, de la capacité disponible et de la conception de leurs tests.

En semaine 5, l'étape de tests tournait autour de 58 minutes dans des conditions normales ; le reste du build complet s'ajoutait à ce chiffre. Ce vendredi-là, en plus, un autre pipeline occupait la même machine d'intégration : le build complet, avec toutes ses étapes et l'attente de ressources, a atteint les 100 minutes du plafond et s'est arrêté. La machine partagée a été la poussée, pas la cause : une suite saine aurait pris plus de temps, mais loin du plafond. Celle-ci vivait déjà si près de la limite que n'importe quelle charge supplémentaire suffisait à la franchir.

Comment en est-on arrivé à cent minutes en cinq semaines ?

Par cinq décisions qui, une à une, avaient du sens, et dont aucune n'a demandé pourquoi cela prenait autant de temps.

L'équipe utilisait des assistants d'intelligence artificielle pour générer une bonne partie du code et des tests, et chaque nouvelle fonctionnalité arrivait avec son test. Cela ressemblait à de la discipline. Chaque ligne du tableau avait une explication qui sonnait juste : « la suite a grandi », « les gros fichiers sont lents », « la machine étouffe ». Et personne n'a posé la seule question qui comptait : pourquoi cela prend-il autant de temps ?

Quelle était la vraie cause ?

Chaque fichier de test reconstruisait le site entier avant de vérifier sa propre partie : un coût qui devait être payé une fois l'était deux cent trente fois.

L'indice était dans le tableau depuis le début. Regardez la semaine 5 : presque les mêmes tests, environ 18 minutes de plus. Comme le périmètre des tests avait peu changé, l'hypothèse raisonnable était que ces minutes venaient de la manière dont ils étaient exécutés, et non de ce qui était testé. Une hypothèse se confirme en mesurant : en séparant le temps de préparation, le temps de test et l'attente de ressources. Dans le scénario, cette mesure montre que presque tout était de la préparation.

Pour vérifier qu'un bouton affichait « Send » dans la version anglaise, le fichier de test faisait tout ceci : compiler le site, générer toutes ses pages dans les deux langues, le mettre en marche et, seulement alors, regarder le bouton. Le fichier suivant, celui du même bouton en espagnol, répétait tout depuis zéro. Et le suivant. Environ deux cent trente fois.

C'est comme reconstruire l'immeuble avant de vérifier chaque ampoule.

Avec 60 fichiers, ce coût répété ne faisait pas mal, et comme personne ne mesurait la part de la préparation et celle du test, personne ne l'a vu. Avec chaque nouveau fichier, il grandissait en proportion. C'est le défaut de naissance : ce n'était pas un problème de la semaine 5, c'était une conception qui, dès la semaine 1, intégrait un coût répété appelé à grandir avec chaque nouveau fichier.

Avec cela en main, chaque correctif se lit autrement :

• Découper 4 fichiers en 13 a transformé 4 reconstructions du site en 13.
• Réduire le parallélisme a fait que ces reconstructions s'exécutent davantage à la file et moins en même temps.
• Relever le plafond a donné plus de corde à tout ce qui précède.

Les échecs « sans raison » de la semaine 3 ont aussi une autre lecture. Dans le scénario, ils étaient compatibles avec une machine saturée. Google a documenté en 2016 que, parmi plusieurs causes possibles des tests qui tantôt passent, tantôt échouent avec le même code, figurent la concurrence (plusieurs tests qui se disputent la même ressource au même moment) et les problèmes d'infrastructure [3] ; le confirmer dans un cas concret exige des métriques et des journaux d'exécution. Leur donner plus de temps sans mesurer ne les a pas guéris : cela les a fait taire.

Pourquoi aucun correctif n'a-t-il résolu le problème ?

Parce que tous s'attaquaient au symptôme (l'horloge) et aucun au travail qui se répétait.

Aucun correctif n'était faux en soi ; à tous, il a manqué de mesurer avant de décider.

Un délai maximal fonctionne comme un détecteur de fumée. Si on le relève chaque fois qu'il sonne, il n'y a pas moins de feu : il y a moins d'alerte.

Google le décrit avec des chiffres tirés de sa propre activité : environ 1,5 % de toutes ses exécutions de tests signalaient un résultat instable, et près de 16 % de ses tests présentaient un certain degré d'instabilité [3]. Le plus pertinent pour vous est la conséquence qu'ils soulignent : avec autant de faux positifs, il est courant que des échecs légitimes soient ignorés [3]. Et ils avertissent qu'écarter automatiquement les tests instables peut facilement masquer une véritable erreur du code [3]. Tolérer une alarme a un prix, même s'il n'apparaît sur aucune facture.

C'est pourquoi la morale de cette histoire n'est pas « la suite a grandi jusqu'à casser ». Elle est plus inconfortable : elle est née avec le défaut, et chaque correctif qui n'a pas mesuré la cause l'a rendue plus lente.

Que dit la pratique du secteur sur la durée d'une livraison ?

Que la validation qui s'exécute à chaque changement doit tourner autour de dix minutes, et que lorsqu'elle commence à grandir on agit immédiatement, pas quand elle ne tient plus.

Martin Fowler, dans son article sur l'intégration continue, reprend la règle de l'extreme programming (XP) d'un build de dix minutes et affirme que, pour la plupart des projets, elle est parfaitement raisonnable [1]. Il demande aussi de surveiller les temps de build et d'agir dès qu'ils commencent à dépasser la règle des dix minutes [1]. Il observe également que, du moins dans les applications d'entreprise, le goulot d'étranglement habituel, ce sont les tests [1].

DORA décrit l'intégration continue en des termes proches : les tests doivent s'exécuter en quelques minutes, avec une limite supérieure d'environ 10 minutes [2]. Et elle fixe une discipline d'équipe : si les tests automatisés échouent, l'équipe arrête ce qu'elle fait pour les réparer immédiatement ; si le build ne peut pas être réparé en quelques minutes, on identifie et on annule le changement qui l'a cassé [2]. DORA demande en outre que les tests soient fiables et rapides, pour fournir un retour le plus tôt possible, et propose de sortir les tests les plus longs dans un build séparé [2]. Attention à la différence : décider quels tests s'exécutent à chaque changement et lesquels à un autre moment est une décision de conception prise à l'avance ; les sortir parce qu'ils ne tiennent plus, c'est un plafond de plus qu'on relève.

Mis en regard du scénario :

Notre lecture : dix minutes n'est pas un chiffre magique, mais la pratique montre clairement que la durée se surveille et se défend comme une propriété du système, et non comme une case qu'on ajuste quand elle gêne.

Quelles trois règles changent l'histoire ?

Aucune n'est une ligne de configuration : toutes trois relèvent du jugement, et elles tiennent dans une politique d'ingénierie d'une page.

Règle 1. Ce qui est coûteux se prépare une fois et se réutilise tant que c'est sûr

Si les tests ont besoin du site construit, d'une base de données avec des données d'exemple ou d'un service démarré, identifiez ce qui peut être préparé une fois et partagé sans rompre l'isolation entre les tests.

Ce qui ne change pas, comme un site déjà construit, sert à tous les tests ; ce qui change, comme une base de données, s'isole ou se réinitialise de façon contrôlée. Personne ne reconstruit le monde pour regarder un bouton.

Ce n'est pas une idée nouvelle. Les frameworks de test modernes prévoient un emplacement pour la préparation globale : une fonction qui s'exécute une fois avant tous les tests [4][5], ou des ressources dont la portée est la session de tests complète et non chaque test individuel [6]. La documentation de l'un d'eux signale que les ressources qui nécessitent un accès réseau sont généralement coûteuses à créer [6]. Le mécanisme change d'un outil à l'autre : un autre de ces frameworks recommande de déclarer la préparation comme un projet dont dépendent les autres, plutôt que sa fonction globale, parce qu'elle s'intègre mieux à son exécuteur de tests [4].

Et ce qui a été préparé n'est pas forcément disponible de la même façon pour chaque test : l'un de ces frameworks précise que les variables globales définies dans sa préparation ne peuvent pas être lues depuis les tests [5]. Votre équipe doit le confirmer avant de considérer la correction comme acquise.

Règle 2. La suite a un budget, et elle se compare d'une version à l'autre

Tout comme un projet a un budget financier, l'étape de tests a un budget de durée, et il se surveille à chaque version.

Il ne suffit pas qu'elle « tienne dans le plafond ». La question est de savoir si elle dure autant que la version précédente et, si elle dure plus, si quelqu'un s'y attendait. Pour cela, la chaîne de livraison comporte une barrière : une règle automatique qui arrête la livraison lorsque la durée dépasse la variation permise. Par exemple, si l'étape durait 12 minutes et que la nouvelle version en dure 16 sans que personne ne l'ait anticipé, cela se voit et s'explique avant de continuer.

C'est une barrière, pas une statistique que quelqu'un consulte quand il y pense. Avec elle, cette équipe aurait pu détecter l'écart en semaine 2, et non en semaine 5, quand il a coûté une campagne. C'est la consigne de Fowler d'agir dès que le build commence à dépasser [1], transformée en contrôle automatique.

Règle 3. Relever le plafond ou découper les tests ne compte pas comme une correction

Quand la suite bute sur son budget, la première question n'est pas « combien de temps de plus lui donne-t-on ? », mais « qu'est-ce qui se répète et ne devrait pas ? ».

Relever le plafond peut être une mesure temporaire valable pour une livraison urgente, mais elle s'enregistre pour ce qu'elle est, une dette avec une date et un responsable, et l'enquête sur la cause s'ouvre le jour même. Si le plafond monte et que personne n'ouvre l'enquête, ce n'était pas une décision technique : c'était cacher la poussière sous le tapis.

Quel rôle a joué l'intelligence artificielle ?

Aucun qui la rende coupable ou innocente : les propositions répondaient à la question que posait l'équipe, et personne n'a posé celle de la cause.

Accuser l'outil ou l'absoudre n'aide pas la direction. La question que posait l'équipe était « comment je le fais passer ? », et les propositions obtenues y répondaient : plus de temps, plus de morceaux, moins de processus. Des réponses plausibles à la mauvaise question.

Le problème était ailleurs : l'équipe a accepté chaque correctif sans demander pourquoi. Quand une personne peu expérimentée propose de relever un délai maximal, quelqu'un de plus aguerri lui demande généralement « et pourquoi ça prend autant de temps ? ». Quand la proposition arrive instantanément et rédigée avec assurance, cette question se saute plus facilement.

La vitesse des assistants ne supprime pas le besoin de jugement : elle l'augmente, car désormais les erreurs se produisent aussi plus vite. La règle que laisse cette histoire est simple à écrire et exigeante à appliquer : un correctif qui n'explique pas la cause n'est pas accepté, qu'il vienne d'une personne ou d'un outil. La revue des changements exige des preuves de la cause, de l'impact attendu et de la mesure ultérieure, quelle que soit l'origine de la proposition.

À quoi ressemble la version ennuyeuse de cette histoire ?

C'est la même semaine 2, avec une barrière qui donne l'alarme à temps et quelqu'un qui demande pourquoi.

Dans cette version, le mardi de la semaine 2, la barrière signale que l'étape est passée de 12 à 16 minutes sans explication. La version est retenue quelques heures. Une personne de l'équipe mesure où passe le temps et découvre que presque tout est de la préparation : chaque fichier construit le site depuis zéro.

Le soir même, le site se construit une fois au départ et tous les tests l'utilisent ; la base de données d'exemple se réinitialise de façon contrôlée entre les tests. Une fois le changement validé, l'étape peut revenir au budget convenu et le plafond reste où il était.

Trois semaines plus tard, le vendredi de la campagne, un autre pipeline occupe la même machine et le build dure un peu plus. Avec une marge suffisante face à cette charge supplémentaire, le risque que la suite bloque la livraison est bien plus faible.

Voilà la version ennuyeuse. Et dans une chaîne de livraison, l'ennui est le but.

À retenir

Quatre questions pour votre prochain comité technologique :

1. Combien de temps dure aujourd'hui l'étape de tests de nos principaux systèmes, combien durait-elle il y a trois mois, et qui surveille cet écart ?
2. Combien de fois avons-nous relevé un délai maximal cette année, et combien de ces fois une enquête sur la cause a-t-elle été ouverte avec une date et un responsable ?
3. Savons-nous quelle part de la durée de nos tests est de la préparation et quelle part est du test ?
4. Quand un assistant d'intelligence artificielle propose un correctif, notre processus de revue lui demande-t-il d'expliquer la cause, ou seulement que la livraison passe ?

Que fait Hábil ?

Hábil aide à rendre votre chaîne de livraison rapide et fiable, pour que livrer un changement cesse d'être un pari.

Une suite de tests dont la durée augmente peut retarder les livraisons et générer des coûts opérationnels que personne ne voit venir. Nous travaillons avec votre équipe sur quatre fronts :

• Des tests qui mesurent ce qui compte. Que chaque test vérifie quelque chose du métier et que ce qui est coûteux se prépare une fois, pas deux cent trente.
• Un budget de durée surveillé. La durée des tests se contrôle comme n'importe quel autre budget, avec une barrière qui la compare d'une version à l'autre.
• Chaque alarme avec un responsable et une cause. Les tests intermittents et les délais maximaux sont traités comme des avertissements qu'on examine, pas comme du bruit qu'on fait taire.
• Des assistants d'IA sans perdre le jugement. Votre équipe profite de la vitesse des assistants avec une revue qui exige que chaque changement explique son pourquoi.

Nous intégrons les tests et la sécurité dans le chemin de livraison. Voir Cloud et DevSecOps.

Si votre étape de tests grandit depuis des semaines et que le plafond a déjà été relevé plus d'une fois, commençons par là. Parlons de votre cas. Le premier échange est sans frais.

Questions fréquentes

Relever le délai maximal du build, est-ce une erreur ?

Pas nécessairement. Cela peut être une mesure temporaire valable pour sortir une livraison urgente. Le problème apparaît quand on l'utilise comme correction : si le plafond monte et que personne ne mesure où passe le temps, la cause continue de grandir. C'est pourquoi chaque hausse s'enregistre comme une dette avec une date et un responsable.

Comment savoir si mon équipe a ce même défaut ?

Un signe clair est celui de la semaine 5 : la durée augmente bien plus que le nombre de tests. Un autre : découper les fichiers lents n'améliore pas le temps total. La vérification de fond consiste à mesurer, fichier par fichier, ce qui part dans la préparation de l'environnement et ce qui part dans le test. Si la préparation domine et se répète dans chaque fichier, c'est là qu'est le coût.

Sources consultées le 6 novembre 2026. Les citations de documents en anglais sont traduites.

Dorian Chávez raconte une version narrée de ce schéma, en espagnol, dans son Substack « En construcción » : https://enconstruccionmx.substack.com/p/la-suite-que-se-comio-la-entrega