Symptôme : sur un projet e-commerce d’environ soixante scénarios E2E, deux ou trois échouaient chaque semaine, jamais les mêmes, jamais pour la même raison apparente. Relancer le job de CI suffisait presque toujours à faire passer le test au vert. L’équipe avait pris l’habitude de relancer sans même regarder le message d’erreur, une habitude qui a fini par masquer une vraie régression pendant près de deux semaines.
Ce sont les tests dits « flaky », instables sans lien avec une modification du code testé. Ils sont pires que des tests qui échouent systématiquement : un test toujours rouge se remarque et se corrige vite ; un test flaky s’installe dans le paysage, l’équipe apprend à l’ignorer, et la confiance dans toute la suite s’érode avec lui.
Diagnostic : quatre familles de causes
Avant de corriger quoi que ce soit, il faut identifier la famille du problème, car les remèdes ne se ressemblent pas. Sur nos projets, quasiment tous les cas de flakiness se rangent dans l’une de ces catégories.
Attentes implicites ou trop courtes
Le cas le plus fréquent : le test clique sur un bouton qui déclenche une requête AJAX, puis vérifie immédiatement le résultat, sans attendre que la réponse soit revenue et que le DOM soit mis à jour. Sur une machine de CI chargée, la latence varie d’une exécution à l’autre, et le test échoue une fois sur cinq sans raison apparente dans le code métier.
Animations et transitions CSS
Un panneau qui glisse, une notification qui s’estompe, un accordéon qui se déplie : si le test interagit avec un élément pendant sa transition CSS, le clic peut atterrir au mauvais endroit ou être ignoré par le navigateur qui considère l’élément encore en mouvement.
Données partagées entre scénarios
Deux tests qui créent un article avec le même titre, ou qui modifient le même utilisateur administrateur par défaut, se marchent dessus dès qu’ils s’exécutent en parallèle ou dans un ordre différent d’une exécution à l’autre.
Dépendances externes réelles
Un test qui appelle une passerelle de paiement de test, un service d’emailing, ou une API tierce non maîtrisée hérite directement de l’instabilité de ce service, hors du contrôle de l’équipe.
Remplacer les délais fixes par des attentes explicites
La correction la plus rentable, presque toujours en premier lieu : traquer tous les sleep ou waitForTimeout à durée fixe dans la suite, et les remplacer par des attentes conditionnelles qui patientent jusqu’à ce qu’un état précis soit atteint. Avec Playwright, cela prend la forme suivante plutôt que d’un délai arbitraire :
// À éviter : dépend de la vitesse de la machine
await page.waitForTimeout(2000);
await page.click('#ajouter-au-panier');
// Préférable : attend un état vérifiable
await page.click('#ajouter-au-panier');
await page.waitForSelector('.panier-notification', { state: 'visible' });
await expect(page.locator('.panier-count')).toHaveText('1');Cette seule pratique, appliquée systématiquement, a réduit de plus des deux tiers le taux d’échecs aléatoires sur le projet e-commerce évoqué plus haut.
Isoler les données de chaque scénario
Chaque test E2E doit créer ses propres données de test avec des identifiants uniques, typiquement en suffixant les titres et les emails par un horodatage ou un identifiant aléatoire généré au lancement du scénario, plutôt que de réutiliser des fixtures partagées entre tests. Sur WordPress, cela veut dire créer l’article, le produit ou l’utilisateur nécessaire au début du test via WP-CLI ou l’API REST, et le supprimer explicitement à la fin, même en cas d’échec du test lui-même.
- Générer un préfixe unique par exécution de la suite, réutilisé dans tous les titres créés
- Nettoyer les données en fin de test dans un bloc systématiquement exécuté, y compris après un échec d’assertion
- Éviter absolument de dépendre de l’ordre d’exécution des tests entre eux : chaque scénario doit pouvoir tourner seul
Neutraliser les animations pendant les tests
Une astuce simple et souvent négligée : injecter une feuille de style qui désactive globalement les transitions et animations CSS pendant l’exécution des tests, via une règle appliquée uniquement lorsqu’un paramètre ou un en-tête spécifique au test est détecté. Cela élimine une source de flakiness sans toucher au comportement réel observé par les utilisateurs.
Un test qui doit patienter « juste un peu » pour être fiable n’est pas fiable : il est simplement lent à révéler son instabilité.
Mesurer plutôt que supposer
Avant de corriger à l’aveugle, on gagne à instrumenter la CI pour repérer les tests réellement instables : la plupart des runners E2E permettent de relancer automatiquement un test échoué une seule fois et de marquer le résultat comme « flaky » distinctement d’un échec confirmé s’il passe à la deuxième tentative. Ce marquage, cumulé sur plusieurs semaines, fait ressortir objectivement les scénarios à traiter en priorité plutôt que de se fier à l’impression subjective de l’équipe.
Notre verdict
Un test flaky ignoré coûte plus cher qu’un test supprimé : il consomme du temps de relance, use la confiance de l’équipe, et finit par masquer de vraies régressions. La discipline qui paie durablement tient en trois règles simples : attentes explicites plutôt que délais fixes, données isolées par scénario, et mesure continue du taux d’instabilité plutôt qu’une tolérance silencieuse. Aucune de ces règles n’est spectaculaire, mais appliquées ensemble elles transforment une suite E2E qu’on redoute en un outil qu’on consulte réellement avant de merger.
