Sécurité du code généré par IA : risques et bonnes pratiques

Les assistants de codage IA — Copilot, Claude Code, Cursor, Windsurf — ont bouleversé la productivité des développeurs. Mais cette accélération a un coût : selon le rapport Veracode 2026, 82 % des entreprises portent désormais une dette de sécurité, contre 74 % un an plus tôt. Le benchmark Opsera 2026 est encore plus explicite : le code généré par IA introduit 15 à 18 % de vulnérabilités supplémentaires par ligne, comparé au code écrit manuellement.

Cet article décortique les risques concrets et propose un cadre actionnable pour intégrer la sécurité dans votre workflow IA.

L'ampleur du problème en chiffres

Les données convergent, et elles ne sont pas rassurantes :

45 % du code IA est vulnérable — Veracode a testé 80+ tâches de codage sur 4 langages et 4 types de vulnérabilités critiques ; seuls 55 % du code produit était sécurisé.
1 brèche sur 5 est désormais causée par du code généré par IA (Aikido Security, 2026).
24 % du code en production dans le monde est généré par IA — 21 % en Europe, 29 % aux États-Unis.
Les failles à haut risque ont bondi de 8,3 % à 11,3 % en un an.

Le problème n'est pas que l'IA écrive du "mauvais" code. C'est qu'elle reproduit systématiquement les patterns vulnérables présents dans ses données d'entraînement — à grande échelle et sans discernement.

Les 5 vulnérabilités les plus fréquentes

1. Injection SQL et absence de sanitisation

C'est la faille numéro un. Les LLM génèrent régulièrement des requêtes SQL par concaténation de chaînes, un pattern omniprésent dans le code open source sur lequel ils ont été entraînés.

# Code généré par IA — VULNÉRABLE
def get_user(username):
    query = f"SELECT * FROM users WHERE name = '{username}'"
    return db.execute(query)
 
# Version sécurisée — requête paramétrée
def get_user(username):
    query = "SELECT * FROM users WHERE name = %s"
    return db.execute(query, (username,))

2. Dépendances hallucineées (supply chain attack)

Les modèles suggèrent parfois des packages qui n'existent pas. Des attaquants enregistrent ces noms sur npm ou PyPI avec du code malveillant. Si un développeur installe le package sans vérifier, l'attaquant obtient un accès complet au système.

# Le modèle suggère :
pip install flask-auth-utils  # Ce package n'existe pas
 
# Un attaquant le publie avec un payload malveillant
# → Votre CI/CD l'installe automatiquement

3. Contrôles d'accès incomplets

L'IA implémente souvent la logique métier (créer, modifier, supprimer) mais oublie de vérifier les rôles et permissions. Le résultat : des endpoints accessibles à tous les utilisateurs authentifiés, sans distinction de privilèges.

// Généré par IA — manque la vérification du rôle
app.put('/api/users/:id', async (req, res) => {
  const user = await User.findByIdAndUpdate(req.params.id, req.body);
  res.json(user);
});
 
// Version sécurisée
app.put('/api/users/:id', requireRole('admin'), async (req, res) => {
  const user = await User.findByIdAndUpdate(req.params.id, req.body);
  res.json(user);
});

4. Secrets en dur dans le code

Les modèles reproduisent des patterns de configuration avec des clés API, tokens et mots de passe directement dans le code source — un classique des fuites de données.

5. Gestion cryptographique faible

Utilisation d'algorithmes obsolètes (MD5, SHA-1 pour le hachage de mots de passe), clés de chiffrement trop courtes, ou implémentations maison de protocoles cryptographiques.

Pourquoi les développeurs ne détectent pas ces failles

Le problème est systémique. Selon les études récentes :

Moins de 50 % des développeurs relisent le code IA avant de le commiter.
La vitesse de production crée un faux sentiment de compétence — le code fonctionne, donc il doit être correct.
Les LLM ne comprennent pas le modèle de menace spécifique à votre application, ni vos standards internes de sécurité.

L'IA génère des patterns de vulnérabilités automatisés. Ce n'est plus une erreur humaine isolée, c'est un risque systémique.

Le cadre DevSecOps pour le code IA

Étape 1 : Scanner avant de merger

Intégrez des outils SAST (Static Application Security Testing) directement dans votre pipeline CI/CD. Chaque pull request contenant du code IA doit passer par une analyse automatisée.

# Exemple GitLab CI
security_scan:
  stage: test
  script:
    - semgrep --config auto --error src/
    - npm audit --audit-level=high
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Étape 2 : Verrouiller les dépendances

Utilisez des fichiers de lock (package-lock.json, poetry.lock).
Activez la vérification d'intégrité (npm ci au lieu de npm install).
Scannez les dépendances avec des outils comme Snyk, Dependabot ou Socket.

Étape 3 : Revue humaine obligatoire

Instaurez une règle : tout code généré par IA doit être relu par un humain avant le merge. Concentrez la revue sur :

La sanitisation des entrées utilisateur
Les contrôles d'accès et d'autorisation
La gestion des secrets et de la cryptographie
Les dépendances importées

Étape 4 : Configurer des garde-fous dans vos prompts

Ajoutez des instructions de sécurité dans vos fichiers de configuration d'agent (comme CLAUDE.md ou les règles Cursor) :

## Règles de sécurité obligatoires
- Toujours utiliser des requêtes paramétrées (jamais de concaténation SQL)
- Ne jamais inclure de secrets dans le code source
- Vérifier les permissions sur chaque endpoint API
- Utiliser bcrypt ou argon2 pour le hachage des mots de passe

Étape 5 : Tester en continu

Complétez les scans statiques avec des tests dynamiques (DAST) et des pentests réguliers. L'ANSSI recommande dans son rapport de février 2026 une approche de veille continue sur les vulnérabilités liées aux modèles d'IA.

Ce que recommande l'ANSSI

Le CERT-FR a publié en février 2026 un rapport dédié à l'IA générative et aux cybermenaces. Les recommandations clés :

Traiter le code IA comme du code non audité par défaut
Mettre en place une gouvernance spécifique pour l'utilisation des assistants de codage
Former les développeurs aux risques spécifiques du code généré
Intégrer les outils IA dans le périmètre de sécurité existant

Conclusion

Les outils de codage IA sont là pour rester, et leur adoption ne fera qu'accélérer. La question n'est pas de les interdire, mais de les encadrer. Avec 82 % des entreprises portant une dette de sécurité et des failles à haut risque en hausse de 36 %, ignorer la sécurité du code IA n'est plus une option.

Le cadre est simple : scanner automatiquement, verrouiller les dépendances, relire systématiquement, et former vos équipes. Les entreprises qui intègrent la sécurité dès le prompt — et pas seulement en fin de pipeline — seront celles qui tireront le meilleur parti de l'IA sans en payer le prix.