Votre pipeline de CI est instable et l'équipe a pris l'habitude de relancer les builds rouges sans les lire. Comment corrigez-vous ça ?

Traitez l'instabilité comme un incident de production, parce qu'un pipeline auquel personne ne fait confiance n'apporte aucune sécurité. Mesurez d'abord : suivez le taux de réussite et mettez en quarantaine les tests qui échouent par intermittence pour que main redevienne verte. Puis corrigez les tests en quarantaine par cause, en général de l'état partagé, des hypothèses de timing, ou une vraie condition de course. Imposez une règle : la quarantaine est temporaire, avec un responsable et une échéance, pour qu'elle ne devienne pas un cimetière.

Le danger, ce n'est pas le temps perdu, c'est que les gens ont appris que rouge ne veut pas dire cassé, donc le jour où une vraie régression arrive, elle passe aussi à coups de relances. Je commence par mesurer, parce que les opinions sur quels tests sont instables sont en général fausses. Relancez la suite plusieurs fois sur un commit inchangé, ou suivez le taux de réussite par test sur quelques centaines d'exécutions, et vous obtenez une liste classée. Puis mettez les pires hors du chemin bloquant pour que main soit verte et que rouge redevienne un signal, mais une quarantaine avec un responsable et une date d'expiration, sinon ça devient un cimetière que personne ne regarde. Pour les corriger, les causes se regroupent : des tests qui partagent de l'état via une base ou un singleton, des sleeps à la place de vraies attentes, et de la dépendance à l'ordre d'exécution. Et certains sont de vrais bugs. J'ai un jour poursuivi un test qui échouait une fois sur cinquante et c'était une vraie condition de course dans un pool de connexions, qui aurait donné un problème de production intermittent que personne n'aurait su reproduire.