Hériter d’un parc de tests automatisés arrive plus souvent qu’on ne le croit : un départ, un changement de prestataire, une réorganisation, une acquisition. Le réflexe naturel est de tout faire repasser au vert. C’est la meilleure façon de perdre six semaines sur des scénarios qui ne servaient déjà plus à personne.
L’ordre des opérations compte plus que l’effort fourni.
Étape 1, inventorier ce qui tourne vraiment
Trois colonnes suffisent : le scénario, sa dernière exécution réussie, son état actuel.
Ce que vous cherchez, ce sont les scénarios désactivés. Ils ne sont pas un actif, ils sont une dette, et ils racontent l’histoire du parc : on désactive toujours ce qui fait trop de bruit, c’est-à-dire souvent ce qui couvre les parcours les plus complexes, donc les plus importants.
Notez pour chacun la raison de la mise en pause si elle existe. Si elle n’existe nulle part, c’est déjà une information sur la gouvernance du parc.
Étape 2, mesurer l’instabilité avant de réparer quoi que ce soit
Deux chiffres à sortir.
Le taux d’échec sur les trente derniers jours, parc entier.
Le taux de rejeu vert : la part des scénarios en échec qui repassent au vert au rejeu suivant sans qu’aucune modification n’ait été faite. C’est votre niveau d’instabilité réel.
Ce second chiffre conditionne tout le reste. Un parc à fort taux de rejeu vert n’a pas un problème de scénarios, il a un problème d’environnement, de données ou d’attentes. Réparer les scénarios un par un ne réglera rien, et vous recommencerez dans trois semaines.
Étape 3, classer par criticité métier
Pas par ordre alphabétique, pas par ancienneté, pas par facilité de réparation.
La bonne question est celle du coût d’une panne non détectée. Un tunnel de commande, une authentification, un formulaire de demande de contact qui porte la génération de leads. Sur un site sans transaction en ligne, ce sont souvent les formulaires qui constituent le vrai parcours critique, et ils sont rarement testés.
Trois niveaux suffisent : bloquant pour l’activité, gênant, cosmétique.
Étape 4, réparer le haut de la liste, supprimer le bas
C’est l’étape qui demande du courage, parce qu’elle consiste à jeter du travail fait par quelqu’un d’autre.
Un parc de 80 scénarios fiables vaut mieux qu’un parc de 300 dont personne ne croit les résultats. Un parc auquel on ne croit plus ne sert à rien, quelle que soit sa couverture. La couverture, d’ailleurs, ne dit pas grand-chose de la capacité à détecter un défaut : une étude publiée en juin 2026 sur des bugs réels en Python montre des taux de détection très différents à couverture de code quasi identique.
Pour chaque scénario du bas de liste, deux options seulement : supprimer, ou réécrire plus tard depuis zéro. Pas de troisième voie où on le garde en pause en se disant qu’on y reviendra.
Étape 5, documenter les données avant de toucher aux scénarios
C’est la première cause d’échec des reprises. Les scénarios sont lisibles, mais personne ne sait quel compte utiliser, lequel est bloqué, quel code promo est expiré, ni quelles données sont partagées avec la recette manuelle.
Une page suffit : la liste des comptes, leur usage, leur mode de renouvellement, et ce qui ne doit jamais être utilisé.
Combien de temps ça prend
Cela dépend de deux variables et de deux seulement : le format des scénarios, et l’état des données de test. La taille du parc arrive loin derrière.
Un parc lisible par des profils non développeurs, avec des données documentées, se reprend en quelques jours. Un parc codé sans conventions partagées, avec des données inconnues, demande d’abord une phase d’archéologie dont personne ne peut prédire la durée. C’est pourquoi il vaut mieux mesurer avant de s’engager sur un délai.
Sur le chiffrage de la charge d’entretien une fois la reprise faite, voyez notre guide sur le coût réel de la maintenance des tests automatisés.
Ce qu’il ne faut pas faire
Tout réparer avant de comprendre. On répare des symptômes et on recommence au déploiement suivant.
Réécrire le parc entier au motif qu’il n’est pas à votre goût. Cela arrive souvent à l’arrivée d’un nouveau responsable, et cela coûte un trimestre pour un gain de qualité rarement démontré.
Garder les scénarios en pause. Ils créent une illusion de couverture dans les rapports.
Questions fréquentes
Comment reprendre un parc de tests automatisés existant ?
Inventorier ce qui tourne réellement, mesurer le taux d’instabilité, classer par criticité métier, réparer le haut de la liste et supprimer le bas, documenter les données de test. Dans cet ordre.
Faut-il tout réparer avant de repartir ?
Non. Un petit parc fiable rétablit la confiance plus vite qu’un grand parc à moitié rouge, et c’est la confiance qui décide si les résultats seront regardés.
Par quoi commencer quand on hérite d’un parc sans documentation ?
Par le taux de rejeu vert. Il dit si vous avez un problème de scénarios ou un problème d’environnement, et ces deux problèmes n’appellent pas le même plan.
