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

70 % des développeurs savent que l'IA écrit du code non sécurisé — Et le déploient quand même en production

Une nouvelle recherche révèle un paradoxe : 70 % des développeurs considèrent le code de l'IA comme non sécurisé, mais 30 % d'entre eux le déploient toujours en production — sans vérifications supplémentaires.

Les chiffres sans sensation

L'enquête a couvert les développeurs qui utilisent activement les assistants d'IA — GitHub Copilot, ChatGPT, Claude et d'autres outils. Le tableau est cohérent : la plupart reconnaissent les risques, mais la pression des délais et l'illusion de fiabilité l'emportent. 70 % admettent que l'IA produit systématiquement du code avec des vulnérabilités, des erreurs de logique, des modèles de sécurité obsolètes ou une architecture clairement mauvaise.

Chaque tiers d'entre eux déploie ce code dans des environnements de combat — sans examen, sans analyse statique, parfois sans tests. Ce ne sont pas des cas isolés de négligence — c'est le symptôme d'un problème systémique. L'auteur d'une chronique sur Habr, un ancien de l'équipe PVS-Studio, parle directement : pour lui, ce n'est pas une découverte.

Il avait des conversations sur les attentes gonflées envers les outils d'IA il y a un an. Ce qui est nouveau, c'est que l'industrie a soudainement commencé à discuter du problème comme de quelque chose d'inattendu.

Pourquoi le code de l'IA semble fiable

La racine du problème réside dans la nature même des modèles de langage. L'IA génère du code avec assurance, sans réserves. La syntaxe est correcte, la structure est familière, le linter est silencieux. Le développeur voit un résultat « semble fonctionner » — et baisse la perception critique. C'est un phénomène psychologique bien étudié : plus la source est autoritaire, plus le scepticisme est faible. L'IA produit des résultats instantanément — ce qui crée en outre l'impression que « le modèle a déjà tout vérifier ». En pratique, ce n'est pas le cas.

«

Les attentes sont gonflées et il y a une confiance excessive dans le code généré — tout comme pour les textes en général ».

Un modèle de langage ne connaît pas la logique métier d'un système particulier, ne comprend pas quelles données arriveront lors de l'exploitation réelle. Il peut reproduire des modèles vulnérables — injections SQL, valeurs par défaut non sécurisées, absence de validation d'entrée — simplement parce qu'ils apparaissaient fréquemment dans le corpus d'entraînement. Les hallucinations dans le code ne sont pas rares mais une conséquence naturelle. Le problème est aggravé par le progrès des outils eux-mêmes. Les développeurs observent des améliorations mois après mois et ont tendance à extrapoler : « avait l'habitude de faire des erreurs, maintenant sensiblement mieux ». Mais « mieux » n'est pas égal à « sécurisé » — cet écart même est la source d'incidents.

Les questions qui auraient dû être posées plus tôt

Maintenant, l'industrie subit une reconsidération tardive. Les équipes se posent les questions qui auraient dû être soulevées lors du premier déploiement des assistants d'IA :

• Une liste de vérification séparée pour l'examen du code généré par l'IA est-elle nécessaire ?
• Comment configurer CI/CD pour détecter automatiquement les erreurs typiques des générateurs ?
• Comment enseignez-vous aux juniors qui se sont déjà habitués à faire confiance à l'autocomplétion ?
• Quel rôle les analyseurs statiques doivent-ils jouer dans un pipeline avec l'IA ?
• Comment expliqueriez-vous à la direction que « généré en 10 secondes » n'est pas la même chose que « prêt pour le déploiement » ?

La plupart des équipes tâtonnent en cherchant les réponses par essai-erreur — parfois au prix d'incidents réels en production.

Ce que cela signifie

Le problème n'est pas avec l'IA en tant que technologie. Le problème est avec le positionnement : les outils sont vendus comme un remplacement du développeur, mais ils fonctionnent comme une ébauche nécessitant une vérification. Jusqu'à ce que les équipes développent une culture d'examen obligatoire du code d'IA — les statistiques ne vont faire que s'aggraver. La solution est vieille et ennuyeuse : analyse statique, examen du code obligatoire, couverture des tests et compréhension claire que la vitesse de génération n'est pas égale à la qualité du résultat. Les outils pour cela existent depuis longtemps. La question est dans la discipline de leur application.