IA et qualité

L'IA dans le code : ce que nous savons des bugs et du fardeau du contrôle qualité

L’adoption de l’IA pour la programmation progresse, mais les chiffres concernant davantage de bugs proviennent principalement de perceptions et ne démontrent pas de causalité. Ce que les enquêtes montrent réellement et comment le mesurer en équipe.

4 novembre 2026 10 min de lecture

L'adoption est élevée, mais les mesures comptent

L'enquête 2025 de Stack Overflow a révélé que 84 % des personnes interrogées utilisaient ou prévoyaient d'utiliser des outils d'IA dans leur processus de développement ; Parmi les développeurs professionnels, 51 % déclarent les utiliser quotidiennement. La question couvre les outils d'IA en général : elle ne prouve pas que ce pourcentage génère du code, ni ne décrit spécifiquement les équipes d'assurance qualité.

Pour regarder de l’autre côté du flux, DeviQA a publié sa propre enquête en juillet 2026 auprès de 300 professionnels de l’assurance qualité, SDET et leaders des tests. 52 % ont déclaré avoir perçu une augmentation des bugs depuis que le développement a commencé à utiliser l'IA et 58 % ont perçu une charge de test accrue. Il s’agit d’un signal pertinent à enquêter, et non d’une estimation représentative du secteur : il s’agit d’un échantillon interne de fournisseurs, basé sur des réponses et des expériences autodéclarées.

L'enquête de DeviQA s'interroge sur les changements que les participants associent temporellement à l'adoption de l'IA ; il ne compare pas les référentiels équivalents avec et sans IA, et ne contrôle pas non plus la taille des modifications, l'expérience, la vitesse de livraison ou la politique de révision. Cela peut également avoir pour conséquence que davantage de défauts soient désormais détectés ou signalés. Il n’est donc pas approprié de conclure que l’IA, à elle seule, provoque une augmentation générale des bugs.

DORA 2025 propose de lire l'IA comme un amplificateur du système de travail existant : un feedback rapide, des plateformes internes et des priorités claires aident ; Les processus faibles et les changements difficiles à évaluer sont également amplifiés. La recherche rapporte des associations, et non une règle causale universelle. Le message pratique est de mesurer l’ensemble du flux, et non d’attribuer la variation à un seul outil.

Que mesurer avant de modifier le processus

Enregistrez sur plusieurs itérations le nombre de modifications apportées et leur taille ; combien de défauts apparaissent avant et après la publication ; sa gravité ; combien de fois un dossier est rouvert ; combien de temps il faut au contrôle qualité pour recevoir et répondre ; et combien de travail est répété. Séparez les modifications apportées à l’aide de l’IA uniquement si l’équipe peut les identifier de manière cohérente et sans surveiller chaque personne.

Comparez soigneusement les périodes : utilisez les mêmes définitions, notez les changements de produits ou d'équipements et examinez à la fois ce que les tests détectent et quelles alertes s'avèrent fausses. Si davantage de modifications sont publiées, le nombre total de défauts peut augmenter même si chaque modification en comporte moins. Comparer les défauts avec le nombre et l’ampleur des changements permet de comprendre ce qui s’est passé.

Imaginez cela avant que l'équipe ne publie dix modifications par semaine et ne trouve quatre défauts ; Après avoir ajouté un assistant, il publie vingt modifications et en trouve six. Le total a augmenté, mais le taux est passé de 0,4 à 0,3 défauts par changement. Sans le dénominateur, le titre « il y a plus de bugs » mélange volume de livraison et qualité unitaire. La détection peut également augmenter parce que des tests ont été ajoutés, de meilleurs journaux ou un examen plus approfondi. Dans ce cas, constater davantage d’échecs peut révéler que le système fonctionne mieux, et non que le produit s’est détérioré.

Il convient de séparer quatre mesures : les défauts constatés avant la publication ; les défauts qui ont atteint la production ; gravité et impact ; et le coût de leur enquête et de leur correction. Trouver davantage de problèmes mineurs lors des tests n’équivaut pas à avoir davantage d’incidents utilisateur. À l’inverse, un taux stable peut cacher un risque plus élevé si le nombre de modifications augmente ou si les échecs se concentrent sur les paiements, les autorisations ou les données. Décidez de ce que vous allez dire avant de comparer.

Qu'ajoute la révision du code généré, en plus de l'exécution de tests

Ce n’est pas parce que tous les tests réussissent qu’un changement est facile à maintenir, respecte les règles du projet ou fait l’objet de tests suffisants. Lors d'une enquête menée en 2026, METR a demandé à quatre responsables de trois projets d'examiner 296 modifications préparées par des agents et approuvées par une évaluation automatisée. En moyenne, les responsables ont accepté moins de changements que l'évaluateur : la différence était de 24 points de pourcentage. L'échantillon était limité et les agents n'ont pas pu corriger leurs propositions après avoir reçu des commentaires ; Le résultat fait une distinction claire : « les tests réussis » et « l’équipe est prête à intégrer le changement » ne veulent pas dire la même chose.

Par conséquent, en plus de vérifier que la fonction fait ce qui est attendu, vérifiez si le changement affecte d'autres fonctions, comment elle gère les erreurs, si elle respecte la sécurité et si les nouveaux tests détectent réellement le problème. Un test généré peut répéter la même erreur que le code. Il demande à chaque test de se rapporter à une exigence et vérifie qu'il échoue lorsque la fonction qu'il était censé protéger est supprimée.

Pendant quatre à six semaines, enregistrez une référence avec des définitions stables et sélectionnez des changements comparables par taille, risque et composant. Si l’équipe utilise l’IA, étiquetez le changement volontairement et au niveau du poste, et non au niveau de la personne. Comparez les groupes ou les périodes lorsque cela est possible, notez les changements simultanés (nouvelle couverture, refactorisation, roulement d'équipe) et normalisez par les changements, les lignes modifiées ou l'exposition. Ne vous fixez pas un seul pourcentage comme objectif : cela pourrait inciter à cacher des défauts ou à réduire la couverture.

Un tableau de bord utile montre combien de défauts apparaissent, quelle est leur gravité et à quel stade ils sont détectés ; combien atteignent la production ou rouvrent ; combien de temps il faut à l'équipe pour recevoir une réponse ; et combien d'alertes automatisées une personne confirme. Gardez des exemples pour comprendre d’où viennent les problèmes. Si l’équipe travaille plus vite, mais que des défauts plus graves surviennent en production ou que les retouches augmentent, le processus ne s’est pas amélioré. Si vous en capturez plus avant de publier et que vous arrivez moins en production, vous rencontrerez peut-être mieux les problèmes maintenant.

Une enquête récente signale une hausse de la charge de travail en QA

Une enquête distincte de DeviQA, publiée en septembre 2026 et menée auprès de 4 000 professionnels de l'assurance qualité, permet de décrire l'autre extrémité du flux. 65 % ont déclaré que les fonctions sont testées plus tôt ; 64 % ont indiqué que davantage de fonctions arrivaient en même temps ; 55 % ont observé une queue d’assurance qualité plus longue ; et 52 % ont signalé davantage de cycles test-correct-retest. Ces chiffres ne doivent pas être confondus avec l'enquête précédente menée auprès de 300 personnes : ce sont des instruments, des échantillons et des questions différents. Ils ne mesurent pas non plus les défauts par modification et ne prouvent pas que l’IA en est la cause. Ils montrent une tension concrète qu'une équipe peut contrôler : un déploiement plus rapide n'élimine pas la révision, la régression ou la coordination, et peut concentrer le travail reçu par l'assurance qualité.

La conséquence pratique est de ne pas attribuer davantage de tests aveugles. Il convient de se demander où se forme la file d'attente : attente d'environnement, exigences incomplètes, révision tardive, données difficiles à préparer, échecs intermittents ou trop d'alertes non acquittées. Chaque cause nécessite une réponse différente. Si l'équipe ne sait pas quand une livraison arrivera ou ce qui a changé, un deuxième outil d'IA peut ajouter du bruit ; Si vous connaissez la différence, le risque et le résultat attendu, vous pouvez mieux prioriser. Il mesure le temps d’attente séparé du temps effectif de test : c’est ainsi qu’on distingue un problème de capacité d’un problème de flux.

Un décompte absolu indique combien de défauts ont été trouvés ; cela n’indique pas à lui seul si chaque changement est pire. Supposons qu’une équipe examine dix modifications et trouve quatre défauts, puis en examine vingt et en trouve six. Le total a augmenté, mais le taux de change a baissé. Même ce taux peut être trompeur si les nouveaux changements sont plus importants, touchent différents composants ou bénéficient d’une plus grande couverture. Utilisez différents dénominateurs en fonction de la décision : modifications révisées pour la charge de tri, la taille et le risque pour comparer l'exposition, les exécutions pour la stabilité et les utilisateurs ou les transactions pour estimer l'impact. Ne transformez pas les lignes de code en une mesure universelle de qualité : elles servent de contexte et ne remplacent pas le risque fonctionnel.

Il sépare également la gravité, le moment de la détection et le coût. Un défaut bloquant détecté avant la libération peut être le signe que les tests fonctionnent ; un problème mineur en production peut être moins grave qu'un échec d'autorisation, même si les deux comptent comme « un bug ». Enregistrez si le problème concernait les exigences, la mise en œuvre, l'intégration, les données ou l'environnement. Cette classification sert à corriger le processus et non à blâmer l'auteur ou l'outil. Conservez des exemples représentatifs et examinez ce qui a changé entre les périodes ; une métrique sans explication du cas peut pousser l’équipe à optimiser le mauvais numéro.

Comment évaluer un outil avec des critères pour le rejeter

Avant d'ajouter l'IA au cycle, définissez une question qui permet une réponse négative : par exemple : « Les tests basés sur des histoires réduisent-ils les omissions sans augmenter le temps de révision ? » Choisissez un flux limité, définissez une référence et convenez de ce qui compte comme un saut, une duplication, une alerte valide et une retouche. Comparez plusieurs itérations et changements de risque similaire. Si possible, alternez les tâches ou les équipes ; Dans le cas contraire, notez les changements de couverture, de personnel, de version et d'outils qui pourraient expliquer une différence. N'attribuez pas de causalité à une comparaison avant/après s'il y a eu d'autres changements en même temps.

Les tests contrôlés nécessitent également une règle d’arrêt. Si l'outil ne dispose pas d'un contexte suffisant, utilise des données réelles sans autorisation, modifie un environnement non isolé ou produit des résultats que personne ne peut reproduire, il doit être arrêté et en attente d'exécution. L'examen humain se concentre sur les risques pertinents, sans accepter tout ce que le modèle génère. À la clôture, il présente les résultats ainsi que les limites d'échantillon, les faux positifs, les défauts échappés et le coût du temps d'examen. Si les données ne soutiennent pas une conclusion, celle-ci est valable : l’étape suivante consiste à améliorer la mesure, et non à déclarer le succès.

Une alerte automatique est une observation qui n’a pas encore été classée. Il peut s’agir d’un nouveau défaut, d’une régression connue, d’une différence visuelle non impactante, d’un problème environnemental ou encore d’un test qui ne représente plus un comportement attendu. Si le tableau de bord additionne tout comme « bugs », l'outil semblera trouver plus de problèmes même si la plupart d'entre eux sont des doublons ou du bruit. Maintient des statuts distincts pour les résultats reçus, examinés, reproductibles, confirmés, dupliqués et rejetés ; Il enregistre également la raison du rejet. De cette façon, l’équipe peut mesurer la précision et le coût du triage sans cacher un signal valide en dessous d’une moyenne.

L’analyse doit également porter sur le temps. Un défaut détecté en quelques minutes n'a pas le même coût qu'un rapport qui apparaît à la fin d'une suite nocturne ; Une alerte correcte que personne ne voit avant la diffusion n’améliore pas non plus la prévention. Notez combien de temps il a fallu au système pour générer un rapport, quand quelqu'un l'a examiné et quand il a été fermé. Si le nombre brut d’alertes augmente mais que le pourcentage confirmé diminue et que le temps d’examen augmente, la prochaine expérience devrait améliorer la sélection et le contexte, et non générer encore plus de cas. Si la détection précoce des défauts pertinents augmente et que les retouches ultérieures diminuent, le signal d’utilité est plus fort.