%20(1).jpg)
TLDR
Nous avons chronométré une exécution CI complète d'une suite de 10 tests dans GitHub Actions. Thunders a terminé en 24 s, devant Selenium (41 s), Playwright (47 s) et Cypress (51 s). Voici les chiffres et ce qui les explique.
Chaque push déclenche une attente. Sa durée ne dépend pas de la vitesse brute des scripts, mais de l'exécution CI complète: checkout du dépôt, installation des dépendances, exécution des tests et résultat final. C'est ce temps total écoulé que mesure ce benchmark de vitesse d'automatisation des tests.
En septembre 2026, nous avons fait tourner une suite de 10 tests dans GitHub Actions avec quatre frameworks, en relevant un seul chiffre par exécution: le temps d'exécution CI complet.
Pourquoi le temps d'exécution CI complet est le chiffre qui compte
Le temps d'exécution brut (les secondes que vos scripts passent réellement à s'exécuter) ignore tout ce qui précède chaque run. Avant que le premier test puisse s'exécuter, le job CI doit checkouter le dépôt et installer les dépendances du framework. Pour les frameworks basés sur navigateur, cela inclut le téléchargement ou la localisation des binaires du navigateur.
Un développeur qui attend un feu vert attend tout cela. La merge queue aussi.
Le temps d'exécution CI complet est la métrique qui reflète cette réalité. Il court du démarrage du job jusqu'au résultat final (succès ou échec), et c'est ce chiffre qui détermine combien de fois une équipe peut pousser du code et itérer avant la fin d'une session. Pour exécuter vos tests dans votre pipeline CI efficacement, c'est la mesure à suivre.
GitHub Actions facture par minute arrondie à l'entier supérieur, ce qui veut dire qu'une exécution de 24 secondes et une exécution de 44 secondes coûtent la même chose sur la facture. La boucle de feedback développeur, elle, n'est pas facturée en minutes.
Comment ce benchmark de vitesse d'automatisation des tests a été mené
Le benchmark couvre une suite de 10 tests de bout en bout contre la même application, exécutée une fois par framework dans GitHub Actions le 14 septembre 2026. Chaque exécution est indépendante. Le chronomètre démarre au lancement du job et s'arrête à la publication du résultat final, checkout et installation des dépendances inclus.
L'ensemble des résultats est disponible dans le dépôt public du benchmark.
Une exécution datée donne un instantané précis, pas une moyenne glissante. Le benchmark est répété à chaque sprint et les résultats sont comparés au fil de leur accumulation.
Les résultats
| Framework | Exécution CI complète |
|---|---|
| Thunders | 24 s |
| Selenium | 41 s |
| Playwright | 47 s |
| Cypress | 51 s |
Exécution CI complète d'une suite de 10 tests dans GitHub Actions, septembre 2026.
Thunders: 24 s. Le plus rapide des quatre dans ce benchmark.
Selenium: 41 s. Voir Thunders face à Selenium: 41 % plus rapide sur l'exécution CI complète.
Playwright: 47 s. Thunders termine 49 % plus vite que Playwright de bout en bout.
Cypress: 51 s. Thunders termine 53 % plus vite que Cypress de bout en bout.
L'écart ne se joue pas dans les scripts de test eux-mêmes. Il se joue dans la charge que chaque framework apporte au job CI avant même qu'un seul test ne s'exécute.
Ce qui explique l'écart
Playwright, Selenium et Cypress s'exécutent dans un environnement local ou provisionné par le runner. Au démarrage d'un job CI, le runner doit installer le framework et ses dépendances. Pour les frameworks basés sur navigateur, cela implique aussi de télécharger les binaires de navigateur avant qu'un seul test ne s'exécute.
Thunders s'exécute dans le cloud. Les tests tournent dans des navigateurs gérés par Thunders, sans étape d'installation locale sur le chemin critique. La couche de génération de tests par IA résout les éléments de page à l'exécution, ce qui supprime une passe de maintenance des sélecteurs avant le démarrage du run. Les tests s'exécutent en parallèle, donc la suite se termine sans attendre la fin d'un test avant de lancer le suivant.
L'exécution cloud et le parallélisme compriment l'exécution CI complète des deux côtés: la charge de configuration avant le premier test, et la mise en file d'attente séquentielle qui, sinon, allongerait le total.
Ce que change une exécution CI plus rapide pour votre pipeline
L'effet se cumule. Un développeur qui obtient un résultat en 24 secondes plutôt qu'en 47 peut pousser, voir le résultat, corriger et repousser dans un temps plus court qu'une seule exécution Playwright.
Pour une équipe qui pousse du code à chaque pull request, des exécutions CI plus courtes signifient:
- Moins d'attente avant un merge. Le pipeline reste ouvert moins longtemps à chaque push.
- Plus d'itérations par session. Une boucle de feedback de moins de 30 secondes change la façon dont les équipes travaillent avec les tests, pas seulement la vitesse de la suite.
- Moins de merges en file d'attente. Avec plusieurs ingénieurs qui poussent en parallèle, une suite plus rapide réduit la fenêtre pendant laquelle la file d'attente s'accumule.
Conclusion
Sur la métrique qui reflète ce qu'un développeur attend réellement, Thunders a terminé une suite de 10 tests en 24 secondes dans notre benchmark GitHub Actions de septembre 2026: 41 % plus rapide que Selenium, 49 % plus rapide que Playwright et 53 % plus rapide que Cypress sur l'exécution CI complète.
L'affirmation reste précise: une métrique, une exécution datée, répétée à chaque sprint. Pour voir comment Thunders se comporte dans votre propre pipeline, demandez une démo.
