Les trois niveaux, la répartition idéale, les anti-patterns qui plombent vos équipes et la méthode concrète pour reconstruire une suite de tests rapide, fiable et rentable.
La pyramide des tests répartit vos tests en trois niveaux : beaucoup d'unitaires rapides à la base, moins d'intégration au milieu, peu d'end-to-end au sommet. La répartition de référence, popularisée par Google, est 70 % unitaires, 20 % intégration, 10 % end-to-end.
L'objectif n'est pas de respecter des quotas, mais de concentrer l'effort sur les tests rapides et fiables. L'anti-pattern le plus courant est le cône de glace : trop d'end-to-end, pas assez d'unitaires, une suite lente et fragile. Or la maintenance des scripts est le premier frein au passage à l'échelle de l'automatisation (World Quality Report 2025-26).
Entrez le nombre de tests de chaque niveau. L'outil calcule votre répartition réelle, la compare au modèle 70/20/10 et identifie la forme de votre pyramide.
La pyramide des tests est un modèle qui hiérarchise les tests automatisés selon leur portée et leur coût. Formalisée par Mike Cohn en 2009 dans Succeeding with Agile, elle recommande de construire sa suite comme une pyramide stable : une large base de tests rapides, un sommet étroit de tests lents.
La logique est économique autant que technique. Plus un test monte dans la pyramide, plus il est lent, fragile et coûteux à maintenir. Concentrer l'effort en bas permet de détecter les défauts tôt, vite et à moindre coût, c'est-à-dire exactement là où une régression se répare le plus facilement.
| Niveau | Part visée | Portée | Vitesse | Coût | Quand l'exécuter |
|---|---|---|---|---|---|
| Tests unitaires | 70 % | Une fonction, une classe, un composant isolé | Millisecondes | Faible (écriture et maintenance) | À chaque commit, en local comme en CI |
| Tests d'intégration | 20 % | Plusieurs modules ensemble : API, base de données, services | Secondes | Moyen | À chaque merge, avant le déploiement |
| Tests end-to-end | 10 % | Un parcours utilisateur complet, interface comprise | Dizaines de secondes à minutes | Élevé (lents, fragiles, coûteux à maintenir) | Sur les parcours critiques, avant release |
Ces trois niveaux s'inscrivent dans une démarche de shift-left testing : tester le plus tôt possible dans le cycle, plutôt que de tout reporter sur une recette finale.
La répartition la plus citée, popularisée par les équipes de Google, vise environ 70 % de tests unitaires, 20 % de tests d'intégration et 10 % de tests end-to-end. Ce n'est pas une règle gravée dans le marbre, mais un ordre de grandeur sain pour la majorité des applications.
Une fonction, une classe, un composant isolé.
Plusieurs modules ensemble : API, base de données, services.
Un parcours utilisateur complet, interface comprise.
L'important n'est pas le chiffre exact, mais la forme : une base large et un sommet étroit. Une suite qui respecte cette forme tourne en quelques minutes et donne un retour fiable à chaque commit.
Quand la pyramide se déforme, les symptômes sont toujours les mêmes : des tests lents, instables, dans lesquels l'équipe finit par ne plus croire. Voici les trois formes dégradées les plus fréquentes.
Une majorité de tests end-to-end, peu ou pas de tests unitaires. La suite devient lente, fragile et chère à maintenir : chaque petit changement casse des dizaines de scénarios.
Signal d'alerte : Les tests prennent des heures et tout le monde redoute de les faire tourner.
Beaucoup d'unitaires et beaucoup d'end-to-end, mais presque rien au milieu. Les bugs d'intégration (contrats d'API, erreurs de données) ne sont détectés qu'en bout de chaîne, tard et cher.
Signal d'alerte : Les tests unitaires passent, l'E2E échoue, et personne ne sait pourquoi sans débogage manuel.
Une base automatisée correcte, surmontée d'une couche épaisse de tests manuels de recette. L'automatisation ne tient pas sa promesse : le goulot reste humain à chaque release.
Signal d'alerte : La vélocité plafonne dès qu'il faut livrer vite, car la recette manuelle ne suit pas.
La pyramide a quinze ans et le paysage technique a changé. Des modèles concurrents sont apparus, et il est utile de savoir quand ils ont du sens.
Proposé par Kent C. Dodds pour les applications front modernes, il donne plus de poids aux tests d'intégration, jugés les plus rentables quand l'interface et la logique sont fortement couplées. Il complète la pyramide sur ce type d'architecture plutôt qu'il ne l'invalide.
Pensé pour les architectures microservices, il concentre l'effort sur les tests d'intégration entre services, là où se logent la plupart des défauts dans un système distribué. Pertinent si votre complexité vit entre les services, pas à l'intérieur.
Le principe de fond ne change pas : privilégier les tests rapides et fiables, limiter les tests lents aux endroits où ils apportent une vraie assurance. La bonne forme dépend de votre architecture, pas d'un dogme. C'est précisément ce que nous arbitrons dans une démarche de continuous testing.
Comptez vos tests par niveau. La forme réelle de votre pyramide est souvent une surprise : beaucoup d'équipes découvrent un cône de glace.
Priorisez les tests unitaires sur la logique métier à risque. Ce sont eux qui rendent le refactoring sûr et rapide.
Ciblez les contrats d'API, les accès aux données et les services externes. C'est là que se cachent les régressions silencieuses.
Automatisez en end-to-end les quelques parcours dont une panne coûte vraiment cher. Pas plus.
Pour aller plus loin sur la trajectoire complète, voyez notre méthode pour passer de 0 à 80 % d'automatisation sans déséquilibrer la pyramide.
Dans nos accompagnements d'industrialisation de la qualité, les mêmes pièges reviennent. Les reconnaître, c'est déjà la moitié du rééquilibrage.
C'est un modèle qui répartit les tests automatisés en trois niveaux empilés : beaucoup de tests unitaires rapides à la base, moins de tests d'intégration au milieu, et peu de tests end-to-end lents au sommet. Formalisé par Mike Cohn en 2009, il guide l'investissement vers les tests les plus rapides et les moins fragiles.
La référence la plus citée, popularisée par Google, est 70 % de tests unitaires, 20 % de tests d'intégration et 10 % de tests end-to-end. Ce ne sont pas des quotas rigides : l'idée est de concentrer l'effort sur les tests rapides et fiables, et de limiter les tests lents aux parcours critiques.
C'est l'anti-pattern le plus courant : une majorité de tests end-to-end et peu de tests unitaires. La suite devient lente, fragile et coûteuse à maintenir. La maintenance des scripts est d'ailleurs le premier frein au passage à l'échelle de l'automatisation selon le World Quality Report 2025-26.
Oui, dans son principe : favoriser les tests rapides et fiables reste valable. Des modèles alternatifs comme le « trophée de test » de Kent C. Dodds donnent plus de poids aux tests d'intégration pour les applications front modernes. Ils complètent la pyramide plus qu'ils ne la remplacent ; le bon arbitrage dépend de votre architecture.
Commencez par compter vos tests par niveau pour voir la forme réelle. Sécurisez ensuite la base unitaire sur la logique métier à risque, couvrez les intégrations clés (API, données), et ne gardez en end-to-end que les parcours critiques. Pilotez par la valeur couverte, pas par le volume.
Les répartitions indiquées sont des ordres de grandeur de référence, à adapter à votre architecture et à vos risques.
In Value rééquilibre vos tests et industrialise votre qualité, du bon niveau de couverture au pilotage par la valeur.
