2026-09-15
Le test qui certifiait la panne
Sur notre plateforme, le bouton « Lancer maintenant » d'une automatisation a répondu par un refus pendant près de six semaines, du 22 juillet au 31 août 2026, pour tous les clients. Les exécutions programmées, elles, tournaient normalement. L'intégration continue est restée verte pendant toute la panne, parce que le test qui couvrait ce chemin vérifiait précisément la valeur fautive.
Une chaîne de caractères écrite en dur
Le lancement à la demande envoyait au routeur de modèles un nom de modèle écrit en dur dans le code, un alias que ce routeur n'a jamais servi. Le point d'entrée concerné transmettait ce nom tel quel, sans le résoudre comme le fait l'autre point d'entrée. Chaque lancement mourait donc avant son premier jeton, sur un refus d'accès au modèle. Nous l'avons confirmé sur l'ensemble de la plateforme en essayant la clé d'une automatisation qui comptait 1 081 exécutions programmées réussies : elle était refusée elle aussi, sur ce chemin seulement.
Pourquoi la panne est restée invisible
Deux raisons, dont la conjonction fait la durée. Les exécutions programmées passaient par le planificateur du système, qui résout lui-même le modèle configuré : l'historique continuait de se remplir à l'heure, et la surveillance ne voyait rien d'anormal. Et le test unitaire du lancement à la demande affirmait exactement la valeur écrite en dur : il vérifiait que le code envoyait ce nom-là. Le test était vert parce que le bogue était en place.
La correction, et le test corrigé
Le code lit désormais le nom du modèle dans la configuration, comme le planificateur. Le test vérifie contre cette configuration, et refuse nommément les deux noms qui ont causé la panne. Le chemin a été rejoué de bout en bout le 31 août : déclenchement, exécution, rapport, enregistrement de l'exécution.
La règle que nous en gardons
Un test qui fixe une valeur littérale prouve la valeur, pas le comportement. Quand la valeur est fausse, il certifie la panne, et la surveillance qui regarde ailleurs ne la verra pas. Depuis, un test de ce type vérifie contre la source de vérité, la configuration ou le contrat, et nomme les valeurs qui ont déjà trompé.
Un test qui fixe une valeur littérale prouve la valeur, pas le comportement : pendant six semaines, le nôtre a certifié la panne.