80 % des projets d’automatisation des tests n’atteignent pas leurs objectifs initiaux.
Pas 20 %. Pas 40 %. Quatre projets sur cinq.
Ce chiffre revient dans les études sectorielles depuis dix ans. Il est confirmé par ce que j’observe sur le terrain depuis que j’accompagne des équipes d’ingénierie en France et en Europe : les équipes automatisent, investissent, et se retrouvent un ou deux ans plus tard avec une suite de tests qui fait plus de bruit qu’elle ne donne confiance.
Pourquoi ? Ce n’est pas l’outil. Ce n’est presque jamais l’outil.
Le diagnostic que personne ne veut entendre
Quand un projet d’automatisation échoue, la première réaction est de changer d’outil. On passe de Selenium à Playwright. De Cypress à une solution SaaS. Ou on rajoute une couche d’IA, en espérant que ça règle le problème.
Parfois ça aide à la marge. Le problème central reste intact.
Le vrai problème, c’est qu’on automatise sans gouverner.
Une suite de tests est un actif logiciel. Elle vieillit, elle accumule de la dette, elle nécessite de l’entretien. Si vous n’avez pas de processus pour mesurer son état de santé — stabilité, vitesse, coût de maintenance — vous ne savez pas si votre investissement se valorise ou s’érode.
La plupart des équipes n’ont pas ce processus. Elles savent combien de tests elles ont créés. Elles ne savent pas combien tournent réellement, à quelle fréquence, avec quel taux de confiance.
Les trois raisons réelles de l’échec
1. On a confondu couverture et confiance
“On a 1 200 tests automatisés” est une information. Ce n’est pas une garantie de qualité.
Ce qui compte, c’est le taux de stabilité. Une suite à 70 % de stabilité génère 360 faux positifs sur 1 200 tests. Ces faux positifs ont un coût : triage, investigation, perte de confiance des développeurs. Rapidement, l’équipe commence à ignorer les alertes. La qualité gate devient du décor.
J’ai vu des équipes avec 2 000 tests automatisés qui publiaient moins souvent qu’avant d’automatiser — parce qu’elles ne faisaient plus confiance à leur suite.
2. On n’a jamais défini ce que “ça marche” veut dire
Avant de lancer un programme d’automatisation, il faut répondre à une question : quel est le signal de succès dans 12 mois ?
Si la réponse est vague (“améliorer la qualité”, “aller plus vite”), le programme n’a pas de cap. Chaque responsable a sa propre définition du succès. Les priorités divergent. Les budgets sont remis en question dès le premier obstacle.
Les équipes qui réussissent commencent par définir des critères mesurables : réduire les bugs en production de 40 %, passer à 2 releases par mois, descendre sous 20 minutes de pipeline. Ces objectifs permettent de piloter, d’ajuster, de défendre le budget.
3. Le ROI n’est jamais calculé — donc il n’existe pas
Si vous ne mesurez pas le retour sur investissement de votre automatisation, vous n’avez aucune défense quand quelqu’un coupe le budget.
Et les budgets QA sont parmi les premiers à être challengés, parce que leur valeur est rarement rendue visible. L’automatisation protège de la régression silencieusement — jusqu’au jour où elle ne le fait plus, et là c’est un bug en production qui rend la valeur visible, mais dans le mauvais sens.
Ce que font différemment les 20 % qui réussissent
Les équipes dont les programmes d’automatisation créent vraiment de la valeur ont trois comportements en commun.
Elles mesurent avant de scaler. Avant d’étendre la couverture, elles savent où en est leur suite : quelle est la stabilité par domaine fonctionnel, quelle est la fréquence d’exécution réelle, où est la dette de maintenance. Elles n’automatisent pas plus avant de gouverner ce qu’elles ont déjà.
Elles lient l’automatisation aux KPIs business. Pas “X tests créés par sprint”. Plutôt : délai de release, bugs échappés en production, temps de cycle. Elles parlent le langage du business, pas le langage technique. Ça change la conversation avec la direction.
Elles traitent leur suite comme un produit. Avec un owner clairement désigné, un backlog de maintenance, des revues régulières de santé. Une suite qui n’a pas d’owner finit par n’appartenir à personne — et par se dégrader en silence.
La question à poser ce soir
Si vous ne pouvez pas répondre avec des chiffres précis à ces trois questions, votre programme d’automatisation est probablement en train de s’éroder :
- Quel est le taux de stabilité de votre suite aujourd’hui ?
- Combien d’heures par semaine votre équipe consacre-t-elle à la maintenance des tests ?
- Quel a été l’impact de votre automatisation sur le cycle de release des six derniers mois ?
Ce n’est pas un reproche. C’est un diagnostic. La bonne nouvelle : ces trois métriques sont mesurables, souvent à partir de données déjà présentes dans votre CI/CD.
La mauvaise nouvelle : si vous n’avez pas les outils pour les agréger et les interpréter, vous pilotez à vue.
Automate Score© a été construit précisément pour répondre à ces trois questions — en continu, automatiquement, à partir de vos données réelles. Parce que gouverner une suite de tests ne devrait pas demander des heures de reporting manuel. Ça devrait être un signal clair, chaque semaine, sur l’état de santé de votre investissement.
80 % des projets échouent parce que personne n’a décidé de mesurer. Commencez par là.
Je suis Reda Ennasr, CEO & Cofondateur d’In Value. Ces 5 dernières années, j’ai recruté et accompagné plus d’une centaine d’ingénieurs en Automatisation des tests. Ma mission : Transformer l’automatisation en avantage compétitif. Éditeur de la plateforme Automate Score© : l’IA qui mesure et optimise la performance de l’automatisation des tests.