70 % des développeurs savent que l'IA écrit du code bancal — et le déploient quand même en production

Une nouvelle étude met au jour un paradoxe : 70 % des développeurs jugent le code de l'IA peu sûr, mais 30 % d'entre eux le déploient quand même en production, sans vérification supplémentaire.

Des chiffres sans sensationnalisme

L'enquête portait sur des développeurs qui utilisent activement des assistants IA, comme GitHub Copilot, ChatGPT, Claude et d'autres outils. Le tableau est constant : la plupart sont conscients des risques, mais la pression des délais et l'illusion de fiabilité l'emportent.

70 % reconnaissent que l'IA produit régulièrement du code contenant des vulnérabilités, des erreurs de logique, des schémas de sécurité obsolètes ou carrément une mauvaise architecture. Un sur trois déploie ce code dans des environnements de production, sans relecture, sans analyse statique et parfois sans tests. Ce ne sont pas des cas isolés de négligence, mais le symptôme d'un problème systémique.

L'auteur d'une chronique sur Habr, passé par l'équipe de PVS-Studio, le dit sans détour : pour lui, ce n'est pas une découverte. Il évoquait déjà il y a un an les attentes surévaluées envers les outils d'IA. Ce qui est nouveau, c'est que le secteur se met soudain à débattre du problème comme s'il était inattendu.

Pourquoi le code de l'IA paraît fiable

La racine du problème tient à la nature même des modèles de langage. L'IA génère du code avec assurance, sans réserve. La syntaxe est correcte, la structure familière, le linter reste muet. Le développeur voit un résultat qui « a l'air de fonctionner » et relâche son esprit critique. C'est un phénomène psychologique bien étudié : plus la source fait autorité, plus le scepticisme faiblit.

L'IA fournit le résultat instantanément, ce qui renforce l'impression que « le modèle a déjà tout vérifié ». En pratique, ce n'est pas le cas.

« Les attentes sont surévaluées, et la confiance accordée au code généré est excessive, comme celle accordée aux textes en général. »

Un modèle de langage ne connaît pas la logique métier d'un système donné et ne sait pas quelles données arriveront en exploitation réelle. Il peut reproduire des schémas vulnérables, comme les injections SQL, les valeurs par défaut non sécurisées ou l'absence de validation des entrées, simplement parce qu'ils étaient fréquents dans son corpus d'entraînement. Les hallucinations dans le code ne sont pas rares : elles sont la règle.

Le progrès des outils eux-mêmes aggrave le problème. Les développeurs constatent des améliorations d'un mois sur l'autre et ont tendance à extrapoler : « avant, il faisait des erreurs, maintenant c'est nettement mieux ». Mais « mieux » ne veut pas dire « sûr », et c'est dans cet écart que naissent les incidents.

Les questions qu'il aurait fallu poser plus tôt

Le secteur est aujourd'hui engagé dans une remise en question tardive. Les équipes se posent des questions qui auraient dû être soulevées dès l'adoption des assistants IA :

• Faut-il une checklist dédiée à la relecture du code généré par IA ?
• Comment configurer le CI/CD pour détecter automatiquement les erreurs typiques des générateurs ?
• Comment former les juniors qui ont déjà pris l'habitude de faire confiance à l'autocomplétion ?
• Quel rôle les analyseurs statiques doivent-ils jouer dans un pipeline avec IA ?
• Comment expliquer à la direction que « généré en 10 secondes » ne veut pas dire « prêt à déployer » ?

La plupart des équipes cherchent des réponses par tâtonnements, parfois au prix de vrais incidents en production.

Ce que cela signifie

Le problème n'est pas l'IA en tant que technologie. Le problème, c'est le positionnement : les outils sont vendus comme un remplacement du développeur, mais fonctionnent comme un brouillon qui exige une vérification. Tant que les équipes n'auront pas instauré une culture de la relecture obligatoire du code d'IA, les statistiques ne feront qu'empirer.

La solution est ancienne et ennuyeuse : analyse statique, code review obligatoire, couverture de tests et conscience claire que la vitesse de génération n'est pas synonyme de qualité du résultat. Les outils existent depuis longtemps. Reste la discipline pour les appliquer.