Je vais vous raconter une histoire que nous vivons régulièrement — avec des variantes, mais un fond commun.
Une scale-up en croissance rapide. Une équipe engineering solide. Une base de code qui s’étend, des features qui s’enchaînent, des clients qui attendent. Et une automatisation des tests qui, sur le papier, est “bien avancée”.
En pratique ? Un pipeline qui prend plus de trois heures. Des tests flaky que personne ne corrige vraiment parce que tout le monde est trop occupé. Une confiance dans les résultats automatisés qui s’est doucement érodée. Et des releases qui nécessitent encore une phase de validation manuelle non négligeable.
Ce n’est pas un échec. C’est la trajectoire naturelle d’une organisation qui a grandi plus vite que sa gouvernance.
Le contexte
Note : par respect de la confidentialité, les données ont été légèrement agrégées. Les ordres de grandeur sont exacts.
L’entreprise : une scale-up SaaS B2B, environ 80 personnes, dont une vingtaine en engineering. Produit en croissance, stack moderne, équipe QA de 4 personnes dont 2 automation engineers.
Leur situation au démarrage :
– 2 400+ cas de test automatisés (Playwright + API testing)
– Durée pipeline CI/CD : 3h15 en médiane, jusqu’à 4h40 en P95
– Taux de stabilité : ~79% (21% de tests considérés comme “flaky ou instables”)
– Ratio maintenance : ~28% du temps des automation engineers
– Cadence de release : toutes les 2 semaines, avec des glissements fréquents vers 3 semaines
Leur perception au départ : “On automatise bien, mais c’est lent et fragile.” Leur vraie situation : une maturité d’automatisation mesurable, avec des leviers d’amélioration précis.
La différence entre les deux, c’est la mesure.
La méthode : mesurer avant d’agir
La première étape n’a pas consisté à changer des outils ou à réécrire des tests. Elle a consisté à mesurer objectivement l’état de leur automatisation sur les 4+1 dimensions d’Automate Score© :
Fréquence : combien de fois le pipeline s’exécute par rapport à la cadence de delivery cible ? Leur score révélait que le pipeline ne tournait qu’une fois par jour en moyenne, alors qu’ils visaient du continuous testing.
Stabilité : 79% de stabilité nette. Le seuil de confiance opérationnelle que nous considérons comme minimum est 90%. 21% de tests instables, c’est suffisant pour qu’une équipe commence à ignorer les résultats en rouge.
Durée : 3h15 médiane, c’est trop long pour une intégration dans le flux de PR review. Les résultats arrivent après la fenêtre d’attention des développeurs.
Maintenance : 28% du temps engineering QA absorbé par la maintenance. Chaque feature nouvelle génère une dette de maintenance qui ralentit les itérations suivantes.
AI Readiness : infrastructure de données partiellement en place, mais sans baseline de métriques historiques exploitables pour l’IA.
Cette mesure n’a pris que deux semaines. Et elle a transformé la conversation avec le management : on ne parlait plus d'”améliorer la QA” en général. On parlait de leviers précis, avec des impacts estimés.
Les trois priorités identifiées
Sur la base de la mesure, nous avons construit un plan d’action en trois axes, séquencés pour maximiser l’impact visible rapidement.
Axe 1 — Stabilisation (mois 1-2) : remonter à 92%+ de stabilité
La flakiness est le problème le plus visible, le plus démotivant, et souvent celui qu’on repousse parce qu’il semble secondaire face aux nouvelles features.
Nous avons mis en place un protocole simple :
– Quarantaine immédiate de tout test en dessous d’un seuil de stabilité sur 10 exécutions consécutives
– Sprint dédié de deux semaines : les deux automation engineers adressent uniquement la dette de stabilité, aucune nouvelle feature
– Revue hebdomadaire des métriques de stabilité avec le lead engineering
Résultat à fin mois 2 : taux de stabilité à 93,4%. Le nombre de “red runs” injustifiés a chuté de 67%. Les développeurs ont recommencé à faire confiance aux résultats automatisés.
Effet collatéral non anticipé : la réduction du bruit a libéré du temps d’analyse. Les vrais bugs identifiés par l’automatisation étaient mieux visibles et traités plus rapidement.
Axe 2 — Durée (mois 2-3) : descendre à moins de 90 minutes en médiane
La durée du pipeline était le deuxième frein identifié. 3h15 de médiane rend impossible l’intégration des résultats dans une PR review standard.
Les actions prises :
– Identification des 20% de tests qui représentaient 60% de la durée totale
– Réarchitecture de la parallélisation sur les suites critiques
– Séparation des suites “smoke / critique” (30 min) et “régression complète” (90 min), avec des triggers différenciés
Résultat à fin mois 3 : durée médiane à 87 minutes pour la suite complète, 28 minutes pour la suite smoke critique. La suite smoke tournait désormais sur chaque PR.
Axe 3 — Cadence (mois 3-5) : passer à une fréquence quotidienne + PR gate
Avec la stabilité restaurée et la durée réduite, la suite smoke pouvait devenir un gate de PR réel. Ce qui n’était pas possible avant — trop instable, trop long — devenait opérationnel.
En parallèle : réduction du ratio maintenance grâce aux pratiques introduites en axe 1. En mois 5, le ratio maintenance était descendu à 14%.
Les résultats à 5 mois
| Indicateur | Avant | Après 5 mois | Évolution |
|---|---|---|---|
| Durée pipeline (médiane) | 3h15 | 87 min | −55% |
| Taux de stabilité | 79% | 94% | +15 pts |
| Ratio maintenance | 28% | 14% | −50% |
| Cadence de release | ~2,5 sem. | ~1,5 sem. | −40% cycles |
| Couverture automatisée | 2 400 tests | 2 710 tests | +310 tests |
| Confiance équipe | ⚠️ Faible | ✅ Haute | — |
La réduction de 40% des cycles de release n’est pas venue d’une refonte de l’architecture. Elle est venue de la restauration de la confiance dans les pipelines existants — ce qui a permis de réduire les phases de validation manuelle qui allongeaient chaque cycle.
Ce que cette expérience m’a appris
Trois enseignements que je retrouve dans la plupart des organisations que nous accompagnons.
L’outillage n’est presque jamais le problème. Les équipes qui ont des difficultés avec leur automatisation utilisent souvent de bons outils — Playwright, pytest, Cypress, des pipelines CI/CD solides. Le problème est rarement l’outil. Il est dans la façon dont on pilote ce que l’outil produit.
La mesure crée l’alignement. Avant la mesure, les conversations sur l'”état de l’automatisation” étaient floues. Management, QA engineers et développeurs avaient des perceptions divergentes. La mesure objective a mis tout le monde sur la même page. Elle a aussi rendu les arbitrages — par exemple le sprint dédié à la dette de stabilité — plus faciles à justifier.
Les résultats visibles créent l’adhésion. Le premier impact visible a été la chute des faux positifs en fin de mois 2. Ce résultat a été perçu immédiatement par les développeurs — sans aucune communication forcée. C’est ce moment-là qui a créé l’adhésion au programme de transformation.
La suite
Cette scale-up travaille aujourd’hui sur l’axe AI Readiness — le “+1” de notre modèle. Avec des métriques de baseline solides et une infrastructure de données propre, les prochaines étapes (génération assistée de tests, priorisation IA du périmètre de régression) deviennent accessibles.
Ce qui aurait été impossible à envisager 5 mois plus tôt, quand le pipeline était trop instable pour être fiable.
La gouvernance d’abord. L’IA ensuite. Dans cet ordre.
Vous reconnaissez des patterns similaires dans votre organisation ? Nous proposons une session d’évaluation de 45 minutes pour mesurer objectivement votre situation. Découvrez Automate Score© sur automatescore.com.
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.