L'IA écrit votre code. Les incidents par pull request ont bondi de 242 %.
Le code généré par l'IA dépasse la revue de code : incidents par PR +242 %, bugs par développeur +54 %.Pourquoi les tests de bout en bout sont la barrière qualité qui suit le rythme.
10 min de lecturePar l'équipe de GUI Test Studio
Ce que Faros AI a mesuré
En avril 2026, Faros AI a publié The AI Engineering Report 2026: The Acceleration Whiplash.Ce n'est pas un sondage sur ce que ressentent les développeurs.Il s'agit d'environ deux ans de télémétrie de 22 000 développeurs répartis dans plus de 4 000 équipes, et il compare les périodes de plus faible et de plus forte adoption de l'IA au sein de chaque organisation.
Le premier constat plante le décor.Dans 80 % des équipes, plus de la moitié des développeurs utilisent des outils d'IA chaque semaine, et la part du code généré par l'IA que les développeurs acceptent est passée de 20 % à 60 %.
« L'IA n'assiste pas les développeurs. Dans la plupart des organisations, elle les dirige ».
La bonne nouvelle est réelle, et le rapport le dit.Avec une forte adoption de l'IA, les équipes accomplissent davantage de travail.
+66%
Epics terminés par développeur
+33.7%
Tâches terminées par développeur
+16.2%
Pull requests fusionnées par développeur
Puis vient le contrecoup.Les mêmes équipes livrent plus d'incidents et plus de bugs, et la courbe devient plus raide, pas plus plate.
Qualité en production avec une forte adoption de l'IA
Incidents par pull request
Les incidents par changement fusionné surviennent à un rythme plus de trois fois supérieur.
Incidents mensuels
Pannes, événements de sécurité et défaillances qui atteignent les utilisateurs.
Bugs par développeur, rapport 2026
Bugs par développeur, rapport 2025
Le taux de défauts s'accentue, il ne se stabilise pas.
Bugs par pull request
Pourquoi les bugs et les incidents augmentent-ils avec le code généré par l'IA ?
Un incident, c'est ce que ressent un utilisateur : une panne, un événement de sécurité, une défaillance du système.Entre une faible et une forte adoption de l'IA, le ratio d'incidents par pull request fusionnée a augmenté de 242.7 %, et les incidents mensuels ont augmenté de 57.9 %.
« Pour chaque PR fusionnée, les incidents surviennent à un rythme plus de trois fois supérieur ».
Les bugs suivent la même courbe.Le rapport 2025 de Faros, The AI Productivity Paradox, mesurait des bugs par développeur en hausse de 9 %.Dans ce jeu de données, le chiffre est en hausse de 54 %, et la page du rapport lui-même indique des bugs par pull request en hausse de 28.7 %.Plus une équipe s'appuie sur l'IA, plus les défauts augmentent vite.
Ces chiffres décrivent ce qui s'est passé, pas une cause unique, et Faros prend soin de le dire.Mais ils pointent tous dans la même direction.Davantage de code atteint la production, plus vite, et chaque changement porte plus de risque qu'avant.
Pourquoi la revue de code ne peut-elle pas suivre le rythme des agents de codage IA ?
La revue de code a été conçue pour du code écrit à vitesse humaine.Un agent de codage IA écrit une pull request en quelques minutes, et une équipe dotée de cinq agents ouvre plus de pull requests en une journée que ses ingénieurs seniors ne peuvent en lire en une semaine.
La revue de code face au volume généré par l'IA
Temps médian en revue
Temps médian jusqu'à une première revue
Pull requests fusionnées sans aucune revue
Ni une personne ni un agent IA ne les a examinées.
Faros a mesuré la file d'attente : le temps médian jusqu'à une première revue est en hausse de 156.6 %, le temps médian en revue en hausse de 441.5 %.Et la pression trouve une issue.Les pull requests fusionnées sans aucune revue, humaine ou par un agent, sont en hausse de 31.3 %.
« Le code atteint les systèmes de production sans aucune supervision à un rythme sensiblement plus élevé ».
Même une revue attentive a un angle mort.
- Un relecteur lit un diff, et un diff ne montre jamais l'application en marche.
- Un bouton masqué par un nouveau style, un total mal calculé sur la page de paiement, une boîte de dialogue qui s'ouvre derrière la fenêtre : aucun n'est visible dans le code qui l'a causé.
Qu'est-ce qui attrape les bugs que la revue laisse passer ?
La première idée est de demander plus de tests unitaires à l'agent.Faites-le, mais ne vous arrêtez pas là.Les tests écrits par l'agent qui a écrit le code partagent sa compréhension de la tâche : s'il a mal compris l'exigence, le code et ses tests sont d'accord entre eux, et les deux sont faux.
Le filet de sécurité qui suit le rythme de l'IA a trois propriétés.
| Propriété | Pourquoi c'est important avec du code généré par l'IA |
|---|---|
| Automatisé | Il s'exécute sur chaque pull request et chaque build, au rythme des agents, sans attendre un relecteur. |
| Indépendant | Une personne en est responsable, et il ne dépend ni du code ni de l'IA qui a écrit le code, si bien qu'il ne peut pas partager leurs erreurs. |
| Vérifie ce que voient les utilisateurs | Il pilote la vraie application par son interface et vérifie l'écran, là où les incidents se ressentent. |
C'est un test de bout en bout : un test de toute l'application par son interface, comme un utilisateur la parcourt, de la connexion au paiement.C'est à cela que se résume tester du code généré par l'IA, et c'est ce que demandent les chiffres de Faros : une vérification qui grandit avec le volume de changements, pas avec le nombre de relecteurs.
Un agent ouvre une PR
Quelques minutes de travail, de nombreux fichiers
Les tests unitaires réussissent
La propre compréhension de l'agent
Les tests de bout en bout s'exécutent
Ce que voit l'utilisateur, sous la responsabilité d'une personne
Fusion, ou blocage
Un échec attend un correctif
Comment faire des tests de bout en bout une barrière de qualité CI/CD ?
Définition
Une barrière de qualité est une vérification qu'un changement doit réussir avant d'être fusionné ou déployé.
- Cinq habitudes font des tests de bout en bout une barrière qu'un agent ne peut pas contourner à force d'arguments.
- 1
Lister les parcours qui ne doivent jamais casser
L'inscription, la connexion, la recherche, le paiement, le rapport que vos clients exportent chaque lundi.Cinq à dix parcours, chacun avec le résultat qu'un utilisateur attend.Cette liste est la spécification, et elle appartient à une personne, pas à l'agent.
- 2
Tester l'écran, pas le code
Vérifiez ce qu'un utilisateur lit et voit : le total, le message, le bouton, l'agencement.Un agent renomme des classes et réécrit des composants librement.Un test ancré sur l'écran survit à cela, et échoue quand même quand l'écran est faux.
- 3
Exécuter sur chaque pull request, et bloquer en cas d'échec
Un résultat qui ne fait qu'avertir est vite ignoré.Faites en sorte qu'un test de bout en bout échoué fasse échouer le build, pour que le changement attende un correctif au lieu d'atteindre les utilisateurs.
- 4
Garder les tests hors de portée de l'agent
L'agent peut exécuter les tests et lire les résultats.Une modification de ce qu'un test attend exige l'approbation d'une personne, sinon les tests dérivent vers ce que le code se trouve faire.
- 5
Rendre les échecs lisibles, et les déclarer comme bugs
Un échec doit dire quelle étape a échoué et en quoi l'écran diffère, avec des images, pour que l'agent puisse proposer un correctif et qu'une personne puisse décider.Et il doit devenir un bug dans votre outil de suivi sans que personne ne copie de captures d'écran : voir transformer les tests échoués en bugs Jira.
Un avertissement : une barrière qui échoue sans raison est pire que pas de barrière du tout, car les gens apprennent à l'ignorer.Une barrière a besoin de tests qui distinguent une vraie régression d'un bruit sans conséquence.C'est le sujet des tests instables et faux positifs.
À faire
- Des tests de bout en bout des parcours sur lesquels les utilisateurs comptent
- Une exécution échouée qui bloque la fusion
- Une personne qui approuve chaque modification de ce qu'un test attend
- Des échecs avec images et étapes, déclarés comme bugs
À éviter
- Les tests de l'agent lui-même comme seul filet de sécurité
- Fusionner quand les relecteurs sont trop occupés pour regarder
- Une exécution de bout en bout au rouge qui ne fait qu'avertir
- Des barrières si instables que personne ne leur fait confiance
Tester le code généré par l'IA à chaque build avec GUI Test Studio
GUI Test Studio est conçu exactement pour cette barrière.Il teste de bout en bout les applications web, les applications de bureau Windows, les téléphones et les jeux, par leur interface, sans code de test à écrire ni à maintenir.
Un test en quelques minutes : enregistrez-le, ou décrivez-le
Enregistrez une fois un parcours dans GUI Test Runner-Recorder, en cliquant et en tapant dans la vraie application.Ou décrivez-le dans une consigne à Claude, à ChatGPT avec Codex, ou à un modèle d'IA local, l'un des nôtres ou le vôtre, et le test est créé pour vous.Chaque assertion qu'un assistant ajoute est essayée sur-le-champ et refusée si elle ne pouvait pas réussir à l'écran à l'instant même.
Dans les deux cas, le test vérifie ce que l'écran affiche.
- Une assertion visuelle compare l'image d'un élément, une assertion de texte lit ses mots.
- Le GTS Engine + AI trouve chaque élément en interrogeant d'abord l'application, par ses informations d'accessibilité ou les propres éléments de la page web, et à vue quand l'application ne dit rien.
- Une classe renommée ou un composant réécrit ne casse pas le test.
Une barrière dans votre pipeline, avec gtr-cli
gtr-cli exécute les mêmes tests sur une machine de build Windows et répond comme un pipeline l'attend : son code de sortie fait échouer le build, un fichier JUnit remplit l'onglet des tests, et un résumé Markdown est prêt pour la pull request.Avec une seule option, un test échoué devient un ticket Jira avec les étapes pour reproduire et les images attendue et obtenue.
gtr-cli run tests --countdown 0 --format github --junit results\junit.xml ^
--summary results\summary.md --artifacts results\artifacts --jira on-failureCela fonctionne dans TeamCity, Jenkins, GitHub Actions, GitLab et Azure DevOps : voir Exécuter des tests dans votre pipeline, et Exécutez vos tests de bout en bout à chaque build pour une configuration TeamCity pas à pas.
Une vraie régression, ou un bruit sans conséquence ?
Chaque exécution se termine par un rapport de confiance : pour chaque assertion, si l'élément a été trouvé lors de la phase de recherche et s'il correspond à ce qui a été enregistré lors de la phase de vérification.
- Quand une image diffère, l'analyse intelligente par IA pose un second regard.
- Elle ignore le bruit de rendu, et attrape quand même un mot changé, un badge manquant ou un bouton devenu gris, puis dit ce qui a changé en mots simples.
L'agent peut lui aussi exécuter la barrière
Par son connecteur, l'assistant qui écrit votre code peut exécuter vos tests, lire le verdict et proposer une modification d'un test, qui attend votre confirmation.Une personne garde la main sur ce que les tests attendent.Tout le cycle est décrit dans Développement avec des agents IA (ADLC).
Points clés
- 1L'IA est désormais l'auteur principal du code. Le débit augmente, et les incidents aussi : +242.7 % par pull request fusionnée, +57.9 % par mois.
- 2Les bugs accélèrent, ils ne se stabilisent pas. Les bugs par développeur ont augmenté de 54 %, contre 9 % dans le rapport 2025.
- 3La revue a atteint sa limite. 31.3 % de pull requests en plus sont fusionnées sans aucune revue.
- 4Le filet de sécurité doit être automatisé et indépendant : des tests de bout en bout de ce que voient les utilisateurs, détenus par une personne, exécutés à chaque build.
- 5Faites-en une barrière. Un échec bloque la fusion, déclare un bug, et dit ce qui a changé.
Questions
Le code généré par l'IA cause-t-il plus de bugs ?
Le rapport AI Engineering Report 2026 de Faros AI a comparé les périodes de plus faible et de plus forte adoption de l'IA au sein de chaque organisation, sur 22 000 développeurs.Avec une forte adoption, les bugs par développeur ont augmenté de 54 % et les incidents par pull request fusionnée de 242.7 %.Le rapport mesure ce qui s'est passé, pas une cause unique, mais le taux de défauts augmente à mesure que l'adoption s'approfondit.
Pourquoi la revue de code ne suffit-elle pas pour du code généré par l'IA ?
Le temps de revue croît avec le volume de code, et l'IA multiplie le volume.Faros a mesuré un temps médian jusqu'à une première revue en hausse de 156.6 % et des pull requests fusionnées sans aucune revue en hausse de 31.3 %.Un relecteur lit d'ailleurs un diff, jamais l'application en marche, si bien qu'un écran cassé peut passer une revue attentive.
Comment tester du code généré par l'IA avant qu'il atteigne la production ?
Gardez des tests de bout en bout de vos parcours critiques, détenus par une personne, indépendants du code et de l'agent qui l'a écrit.Exécutez-les sur chaque pull request ou chaque build, et laissez un échec bloquer la fusion.Ils vérifient ce que voient les utilisateurs, quel que soit l'auteur du code.
Qu'est-ce qu'une barrière de qualité CI/CD ?
Une barrière de qualité est une vérification dans votre pipeline qu'un changement doit réussir avant d'être fusionné ou déployé.Un test de bout en bout échoué fait échouer le build, si bien que le changement attend un correctif au lieu d'atteindre les utilisateurs.
Un agent de codage IA peut-il créer et exécuter des tests GUI Test Studio ?
Oui.Claude, ChatGPT avec Codex, Copilot Chat dans VS Code, ou un modèle d'IA local, l'un des nôtres ou le vôtre, peuvent créer un test depuis une consigne et l'exécuter par le connecteur de GUI Test Studio.Dans un pipeline, gtr-cli exécute les mêmes tests sans aucun assistant.
Chiffres : Faros AI, The AI Engineering Report 2026: The Acceleration Whiplash (avril 2026), et la page de son rapport pour les bugs par pull request.Faros AI, Claude, ChatGPT, Codex, Copilot, OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps et YouTube sont des marques de leurs propriétaires respectifs.
Prêt à enregistrer votre premier test ?
Toutes les fonctionnalités, pendant 15 jours.
Vous préférez le voir sur le type d'application que vous testez ?Réservez un appel gratuit de 30 minutes avec notre équipe.