La sécurité code IA change surtout votre niveau de contrôle : un outil comme Copilot, ChatGPT ou Claude peut accélérer un développement, mais il peut aussi proposer du code vulnérable, des dépendances douteuses ou une logique trop permissive. En 2025/2026, Veracode indique que 45 % des tâches de code généré testées introduisaient des failles connues. Pour un projet PME, le gain de délai n’a de valeur que si la revue sécurité est prévue dès le devis.
Sécurité code IA : le vrai risque n’est pas l’IA, c’est la validation
L’intention derrière une recherche sur la sécurité code IA est rarement académique. Un dirigeant veut savoir si l’usage d’outils d’IA par son prestataire met son site, son application mobile ou ses données clients en danger. La réponse courte : pas forcément, mais seulement si le code généré est traité comme une proposition, jamais comme une livraison.
Les modèles de langage (LLM, des IA entraînées sur de grands volumes de texte et de code) écrivent souvent du code plausible. C’est leur force. C’est aussi leur faiblesse. Ils peuvent produire une fonction qui marche lors d’un test rapide, tout en oubliant l’échappement des entrées utilisateur, la gestion des permissions ou une dépendance maintenue.
Veracode a testé plus de 100 LLMs en 2025 sur Java, Python, C# et JavaScript. Son benchmark couvre 80 tâches de codage et plusieurs catégories CWE, c’est-à-dire des familles de faiblesses logicielles documentées, comme l’injection SQL CWE-89 ou le Cross-Site Scripting CWE-80. Le résultat global, confirmé dans une mise à jour Spring 2026, reste stable : environ 55 % de code jugé sécurisé, 45 % vulnérable.
Ce chiffre ne veut pas dire que presque un projet sur deux sera piraté. Il dit autre chose, plus utile : sans consigne de sécurité claire et sans vérification, l’IA introduit trop souvent des erreurs déjà connues. Des erreurs banales. Donc évitables.
Ce que les chiffres récents disent aux décideurs
Sonar a interrogé plus de 1 100 développeurs professionnels en 2026. Selon cette enquête, le code généré ou assisté par IA représenterait déjà 42 % du code commité, avec une projection à 65 % en 2027 selon les répondants. Autrement dit, même si vous ne demandez pas explicitement d’IA, il est probable qu’elle apparaisse dans la chaîne de production.
Le problème n’est pas son usage. C’est l’écart entre méfiance et discipline. Sonar rapporte que 96 % des développeurs ne font pas pleinement confiance au code généré par IA, mais seulement 48 % vérifient toujours ce code avant de l’envoyer dans le dépôt. Cette contradiction est très concrète pour un budget : une heure gagnée à coder peut devenir trois heures de correction si la faille est détectée tard.
Veracode donne aussi des écarts par langage. Java affiche 72 % d’échecs aux tests de sécurité dans son échantillon, contre 38 % pour Python, 43 % pour JavaScript et 45 % pour C#. Ces résultats ne classent pas les langages du meilleur au pire dans l’absolu. Ils rappellent plutôt qu’une pile technique, un framework et des habitudes de revue pèsent autant que l’outil d’IA.
| Source et année | Indicateur | Ce que ça change pour un projet |
|---|---|---|
| Veracode 2025/2026 | 45 % des tâches de code IA testées vulnérables | Prévoir une revue sécurité systématique, pas seulement des tests fonctionnels |
| Veracode 2025 | XSS/CWE-80 non défendu dans 86 % des échantillons concernés | Vérifier l’affichage de données utilisateur dans les interfaces web |
| Sonar 2026 | 42 % du code commité serait généré ou assisté par IA | Demander comment l’agence trace et relit le code assisté |
| Sonar 2026 | 48 % des développeurs vérifient toujours avant commit | Formaliser la validation dans le workflow, pas dans les intentions |
| GitHub 2026 | CodeQL/Copilot autofix couvre plus de 90 % des types d’alertes en JavaScript, TypeScript, Java et Python | Automatiser une partie de la détection, sans remplacer la revue humaine |
Les failles à chercher en priorité dans du code généré
Les erreurs les plus dangereuses ne sont pas toujours spectaculaires. Une injection SQL permet à un attaquant de détourner une requête à la base de données. Un XSS, ou Cross-Site Scripting, injecte du script dans une page vue par un utilisateur. Une fuite d’information sensible expose une clé API, un token ou une donnée personnelle.
OWASP, la référence communautaire en sécurité applicative, liste dans son Top 10 for Large Language Model Applications des risques liés à l’usage des LLMs : mauvaise gestion des sorties, vulnérabilités de chaîne d’approvisionnement, confiance excessive, divulgation d’informations sensibles et autonomie excessive des agents. Ces risques valent aussi pour les projets web classiques dès qu’un assistant IA participe au développement.
Un piège fréquent tient aux dépendances. Une dépendance est une brique logicielle externe ajoutée au projet, par exemple un package npm en JavaScript ou une librairie Python. Cloudsmith a alerté en 2026 sur les packages halluciné par IA et le “slopsquatting”, une pratique où un nom de paquet plausible ou proche d’un vrai paquet peut conduire vers un composant non fiable. Pour un non-technicien, c’est invisible dans une démonstration.
Sur les projets que nous menons, nous voyons souvent le même arbitrage : l’IA aide très bien à produire du code répétitif, des tests unitaires ou une première version d’interface, mais elle est moins fiable dès qu’il faut gérer les droits, les paiements, les données personnelles ou la sécurité serveur. À ce niveau, mieux vaut aller moins vite que corriger une faille en production.
La checklist de vérification avant mise en production
Une bonne gouvernance ne consiste pas à interdire l’IA. Elle consiste à savoir où elle est utilisée, sur quelles parties du code, avec quelles barrières. Pour un dirigeant, la question à poser au prestataire est simple : “quelles preuves de contrôle me fournissez-vous avant livraison ?”
- Identifier les parties générées ou fortement assistées par IA, surtout sur l’authentification, les formulaires, les paiements et l’administration.
- Lancer une analyse SAST (analyse statique du code, sans exécuter l’application) avec des outils comme SonarQube, GitHub CodeQL ou Semgrep.
- Contrôler les dépendances avec npm audit, pip-audit, Dependabot, Snyk ou un registre d’artefacts comme Cloudsmith.
- Vérifier les secrets : aucune clé API, aucun mot de passe, aucun token dans GitHub, GitLab ou Bitbucket.
- Tester les entrées utilisateur : formulaires, recherche, commentaires, upload de fichiers, paramètres d’URL.
- Relire les permissions métier : un client ne doit pas voir les données d’un autre client, même si l’interface ne le montre pas.
- Documenter les alertes acceptées, corrigées ou reportées, avec une raison lisible par un décideur.
GitHub indique en 2026 que CodeQL et Copilot code-scanning autofix couvrent plus de 90 % des types d’alertes en JavaScript, TypeScript, Java et Python, avec une correction possible de plus des deux tiers des vulnérabilités supportées avec peu ou pas d’édition. C’est précieux. Mais un correctif automatique ne sait pas toujours si une règle métier est correcte.
Si votre projet utilise des agents IA connectés à vos outils, le sujet devient plus large que le code. Le Model Context Protocol, ou MCP, standardise par exemple la connexion d’agents à des données et services ; son intérêt est réel, mais les permissions doivent être cadrées, comme expliqué dans notre analyse du MCP pour connecter les agents IA aux données. Plus un agent peut agir, plus ses limites doivent être explicites.
Budget, délais : combien coûte une revue sécurité sérieuse ?
Un contrôle de sécurité raisonnable a un coût, mais il reste souvent inférieur au coût d’un incident. En France, selon les prestataires et la taille du périmètre, comptez autour de 800 à 2 500 € HT pour une revue légère d’un petit site ou d’un module applicatif, plutôt 3 000 à 8 000 € HT pour un audit applicatif plus complet avec analyse du code, dépendances et rapport exploitable. Un test d’intrusion cadré sur une application métier dépasse fréquemment 5 000 à 15 000 € HT.
Le délai dépend du moment où la revue intervient. Avant mise en production, une passe outillée plus une relecture ciblée peut prendre deux à cinq jours ouvrés sur un projet PME bien organisé. Après livraison, avec une base de code peu documentée, les mêmes vérifications peuvent doubler. Honnêtement, économiser cette étape sur une application qui manipule des données clients n’est pas un bon calcul.
Le meilleur rapport coût/bénéfice consiste à intégrer les contrôles dans la chaîne CI/CD, c’est-à-dire le processus automatique qui teste et déploie le logiciel. Un scan à chaque modification coûte peu une fois configuré. Une faille découverte au moment de la recette, elle, perturbe le planning, le budget et parfois le lancement commercial.
Les obligations réglementaires renforcent cette logique. Le RGPD, applicable depuis 2018, impose de protéger les données personnelles par des mesures adaptées. Le Cyber Resilience Act européen crée aussi de nouvelles exigences pour certains logiciels et composants ; pour anticiper ce cadre, vous pouvez lire notre point sur les obligations du Cyber Resilience Act pour les logiciels et plugins. Si votre activité entre dans le champ de NIS2, la sécurité du site ou de l’application ne peut plus être traitée comme un supplément tardif ; notre guide sur NIS2 appliquée à WordPress depuis octobre 2024 détaille ce changement.
Quand l’IA accélère vraiment, et quand elle devient un mauvais choix
L’IA est pertinente pour générer des squelettes de composants, proposer des tests, traduire un bout de logique d’un langage vers un autre ou documenter du code existant. Elle peut aussi aider à repérer des incohérences simples. Sur un projet au budget serré, c’est utile si le temps gagné finance une meilleure recette et une meilleure sécurité.
La solution évidente devient mauvaise quand l’équipe demande à l’IA de produire vite une fonctionnalité sensible sans cadre. Authentification, paiement Stripe, export de données personnelles, synchronisation avec un CRM, back-office administrateur : ces zones méritent une conception humaine, puis éventuellement une assistance IA sous surveillance. Un code qui “semble marcher” n’est pas une preuve de sûreté.
Le choix technique compte aussi. Un projet JavaScript moderne peut s’appuyer sur Node.js, Deno ou Bun, avec des modèles de dépendances et de maturité différents ; ce type d’arbitrage est abordé dans notre comparaison des runtimes JavaScript en 2026. Côté IA hébergée, la souveraineté et la confidentialité comptent également : pour les PME françaises, l’usage d’outils comme Mistral doit être évalué sous l’angle RGPD, comme dans notre guide sur Le Chat de Mistral et la protection des données.
Côté agence, le réflexe est de séparer ce qui peut être accéléré de ce qui doit être sécurisé dès la conception. Cette frontière évite beaucoup de débats inutiles : l’IA n’est ni interdite, ni acceptée partout. Elle est encadrée.
Qu’exiger d’un prestataire qui utilise l’IA pour coder ?
Un prestataire sérieux n’a pas besoin de cacher l’IA. Il doit expliquer comment il l’utilise, comment il relit, quels outils automatisés sont en place et quelles limites sont posées. La transparence vaut mieux qu’une promesse vague de productivité.
Demandez un dépôt de code versionné, un historique de validation, un rapport d’analyse statique, un état des dépendances et une politique de gestion des secrets. Si l’application traite des données personnelles, demandez aussi où les prompts et les extraits de code sont envoyés. L’étude arXiv publiée en avril 2026 sur les discussions de sécurité autour de GitHub Copilot identifie justement quatre préoccupations récurrentes : fuite de données, licences de code, attaques adversariales ou prompt injection, et suggestions de code non sécurisé.
La sécurité code IA est donc moins une affaire d’outil qu’une affaire de méthode. Cadrer ce type de projet en amont évite la plupart des mauvaises surprises ; c’est souvent là qu’un regard extérieur fait gagner du temps, en transformant un risque flou en points de contrôle vérifiables.
FAQ sur la sécurité du code généré par IA
Le code généré par IA est-il toujours moins sécurisé ?
Non. Il peut être correct, surtout sur des tâches simples et bien spécifiées. Le risque vient du fait qu’il peut aussi produire du code vulnérable avec beaucoup d’assurance, d’où la nécessité d’une revue systématique.
Quels outils utiliser pour vérifier du code IA ?
Les plus courants sont SonarQube, GitHub CodeQL, Semgrep, Dependabot, Snyk, npm audit ou pip-audit. Ils détectent des failles connues, des dépendances risquées et des erreurs de qualité, mais ne remplacent pas une revue métier.
Faut-il interdire ChatGPT ou Copilot aux développeurs ?
Dans la plupart des PME, l’interdiction totale est peu réaliste. Mieux vaut définir les usages autorisés, exclure les secrets et données sensibles des prompts, puis imposer des contrôles avant chaque intégration.
Combien de temps ajouter au planning pour sécuriser du code IA ?
Pour un petit périmètre, prévoyez souvent deux à cinq jours ouvrés de vérifications ciblées. Sur une application métier avec authentification, rôles et données personnelles, la revue doit être intégrée tout au long du développement.