La sécurité du code généré par IA : pourquoi on ne livre pas un site sans relecture

L''IA écrit du code plus vite que n''importe quel développeur, et une bonne partie de ce code est vulnérable. La sécurité du code généré par IA n''est pas un détail théorique : quand un assistant a le choix entre une implémentation sûre et une implémentation risquée, il choisit la mauvaise dans près d''un cas sur deux. Sur un site web exposé publiquement, cette statistique se traduit en portes d''entrée bien réelles.

Le piège n''est pas que l''IA produise du code qui ne compile pas — au contraire, il tourne, les tests passent, la démo est convaincante. Le problème, c''est ce qui ne se voit pas : une requête SQL concaténée, une validation d''entrée absente, une clé d''API en dur, une dépendance qui n''existait pas la semaine dernière. Du code plausible et cassé, la pire combinaison pour la sécurité.

Cet article passe en revue les risques de sécurité concrets du code généré par IA sur un site web en production — chiffres à l''appui — et la seule discipline qui les neutralise réellement. Sans angélisme, mais sans diaboliser un outil qu''on utilise nous-mêmes tous les jours.

Un assistant IA ne raisonne pas sur la sécurité, il complète le motif statistiquement le plus probable à partir de son entraînement. Or son corpus, ce sont des milliards de lignes de code public — dont une masse d''exemples pédagogiques simplifiés, de vieux tutoriels et de snippets Stack Overflow écrits pour illustrer une idée, pas pour résister à une attaque. Le modèle reproduit donc fidèlement les mauvaises pratiques les plus répandues.

Cela explique un résultat contre-intuitif du rapport GenAI de Veracode : augmenter la taille du modèle n''améliore pas la sécurité du code produit. Ce n''est pas un problème de puissance qu''on réglera avec la génération suivante, c''est un problème structurel. Un modèle plus grand écrit un code plus élégant, mieux commenté, plus convaincant — et tout aussi vulnérable. La qualité perçue augmente pendant que la qualité réelle stagne, ce qui rend le danger plus difficile à repérer, pas moins.

Sur un site web, cette mécanique frappe précisément là où ça fait mal : gestion des entrées utilisateur, requêtes base de données, authentification, manipulation de fichiers. Les zones les plus sensibles sont aussi celles où l''IA a le plus d''exemples médiocres à imiter.

Le chiffre vient d''une étude Veracode de 2025 portant sur 80 tâches de code réparties sur plus de 100 modèles de langage. Verdict : quand une tâche offre le choix entre une méthode sûre et une méthode vulnérable, les modèles retiennent la version non sécurisée dans 45 % des cas. Autrement dit, presque une fois sur deux, l''IA introduit une faille alors qu''une alternative sûre existait juste à côté.

Deux nuances aggravantes. D''abord, le code généré par IA contient environ 2,74 fois plus de vulnérabilités que le code écrit par un humain sur les mêmes tâches. Ensuite, la répartition par langage n''épargne personne côté web : JavaScript se situe autour de 40 à 45 % de taux d''échec, et beaucoup de ces failles appartiennent au Top 10 OWASP — injection, mauvaise gestion des sessions, exposition de données.

Ces chiffres ne disent pas « n''utilisez jamais l''IA ». Ils disent : le code sortant d''un modèle est un brouillon, jamais un livrable.

Voici le risque le plus sournois, parce qu''il ne vit pas dans votre code mais dans votre chaîne d''approvisionnement. Les modèles hallucinent régulièrement des noms de paquets qui n''existent pas. Une étude USENIX Security 2025 a généré 2,23 millions d''échantillons de code : les modèles open source inventent un paquet inexistant dans 21,7 % des cas en moyenne, les modèles commerciaux autour de 5,2 %.

// L''IA suggère un import plausible... qui n''existe sur aucun registre.
// Si un attaquant a publié ce nom entre-temps, votre npm install
// exécute son code pendant le build, avec vos accès CI.
import { sanitizeHtml } from 'react-safe-sanitizer'

Le mécanisme d''attaque, baptisé slopsquatting, est direct : l''attaquant observe quels noms l''IA hallucine, enregistre ces paquets sur npm ou PyPI, et y place du code malveillant. Comme 43 % des paquets hallucinés réapparaissent de façon prévisible sur des prompts similaires, ce sont des cibles fiables. Le développeur copie l''import suggéré, lance l''installation, et le mal est fait — souvent dès l''étape de build, dans un pipeline qui détient vos secrets de déploiement.

Le classique indémodable, c''est l''entrée utilisateur qu''on fait confiance. Une IA génère volontiers une requête où les données du formulaire arrivent directement dans le SQL ou dans le rendu HTML, sans couche de validation ni d''échappement. Le code marche en démo parce que personne ne tape de charge malveillante dans le champ « nom ».

La parade n''est pas de demander à l''IA d''être prudente, c''est d''imposer une frontière de validation que le code — quelle qu''en soit l''origine — doit franchir. Valider et typer chaque entrée au bord de l''application avec un schéma strict transforme une donnée hostile en erreur propre plutôt qu''en injection. C''est exactement le rôle qu''on détaille dans notre guide sur la validation des données avec Zod dans Next.js. Une entrée non validée est une faille par défaut, et l''IA ne posera pas cette frontière à votre place si vous ne la lui imposez pas dans le prompt et dans la revue.

Le principe se généralise : tout ce qui traverse la frontière entre l''extérieur et votre serveur — corps de requête, paramètres d''URL, en-têtes, fichiers uploadés — doit être traité comme hostile jusqu''à preuve du contraire. L''IA ne connaît pas cette règle ; c''est à l''architecture de l''appliquer.

Deuxième famille de dégâts : la gestion des accès. Les assistants placent régulièrement une clé d''API, un token ou une chaîne de connexion directement dans le code pour que « ça marche tout de suite ». Sur un dépôt partagé, ce secret part dans l''historique Git et n''en sort plus jamais vraiment, même après suppression. C''est l''une des fuites les plus fréquentes et les plus coûteuses.

Côté authentification, l''IA propose souvent l''implémentation la plus simple, pas la plus sûre : cookies sans attribut HttpOnly, absence de protection CSRF, sessions sans expiration, vérification de rôle oubliée sur une route sensible. Chacun de ces défauts est invisible tant que personne ne les teste. Le choix d''une brique d''authentification robuste et de ses réglages relève d''une décision d''architecture, pas d''une autocomplétion — un sujet qu''on traite dans notre comparatif sur l''authentification dans Next.js App Router. L''IA peut câbler la plomberie, mais c''est à vous de décider ce qui protège l''accès.

La limite fondamentale est là : un modèle génère du code hors sol. Il ignore quelles données de votre site sont sensibles, quelles routes sont publiques, quel utilisateur a le droit de voir quoi, quelles obligations légales pèsent sur vos traitements. La sécurité d''un site web n''est pas une propriété locale d''une fonction — c''est une propriété du système entier, de la façon dont les morceaux s''assemblent.

Or l''IA n''a de vue que sur le fragment qu''on lui montre. Elle écrira une fonction impeccable qui, replacée dans votre contexte, expose une donnée qu''elle ne pouvait pas savoir sensible. Aucune quantité de prompt ne compense l''absence de ce modèle de menace : c''est une connaissance métier et architecturale qui appartient à l''équipe, pas au modèle. C''est précisément pour ça que l''IA accélère l''écriture sans remplacer la responsabilité de conception.

La sécurité du code généré par IA se résume à une règle de travail simple : traiter toute production d''un modèle comme un brouillon signé par un stagiaire brillant mais inconscient du danger. On garde la vitesse — l''IA reste un formidable accélérateur — mais on refuse le raccourci qui consiste à livrer sans relecture. Concrètement : revue humaine systématique des zones sensibles, validation stricte de toutes les entrées, vérification de chaque dépendance suggérée, secrets sortis du code, et analyse de sécurité automatisée dans le pipeline. Le même soin que celui qu''on applique au caching et à la configuration de production.

Le vrai risque n''est pas l''IA elle-même, c''est la confiance qu''elle inspire. Un code qui a l''air propre, qui compile et qui passe les tests désactive la vigilance au moment précis où il faudrait la doubler. Sur un site en production, cette baisse de garde se paie en fuite de données ou en compromission de serveur. La discipline de revue n''est pas un frein à la productivité : c''est ce qui rend l''usage de l''IA soutenable au lieu de dangereux.

Chez Kreio, agence Next.js basée à Évreux (Normandie), on utilise l''IA au quotidien mais on ne livre aucun code sensible sans revue de sécurité. Besoin d''un audit de votre application ou d''un renfort tech ? Parlons-en.

1. 2025 GenAI Code Security Report — Veracode
2. We Have a Package for You! Package Hallucinations by Code-Generating LLMs — USENIX Security 2025
3. Slopsquatting: AI Code Hallucinations Fuel Supply Chain Attacks — Cloud Security Alliance
4. OWASP Top 10 — OWASP Foundation