Plus de 70 % des développeurs utilisent un assistant IA en 2026. Mais cette productivité s'accompagne de risques de sécurité que la plupart sous-estiment. Du code qui compile ne signifie pas du code sûr.

Les risques réels

1. Injection de vulnérabilités classiques

Injection SQL — l'IA génère souvent des concaténations directes :

// DANGEREUX — généré par LLM
const query = `SELECT * FROM users WHERE username = '${username}'`;

// SÉCURISÉ — requête paramétrée
const query = "SELECT * FROM users WHERE username = $1";
db.query(query, [username]);

IDOR — l'IA oublie la vérification d'ownership :

// DANGEREUX — pas de vérification d'ownership
@Get(':id')
async getInvoice(@Param('id') id: string) {
  return this.invoiceService.findById(id);
}

// SÉCURISÉ — vérification de l'ownership
@Get(':id')
async getInvoice(@Param('id') id: string, @Req() req: AuthenticatedRequest) {
  const invoice = await this.invoiceService.findById(id);
  if (invoice.userId !== req.user.id) {
    throw new ForbiddenException();
  }
  return invoice;
}

2. Hallucination de packages

Les LLM inventent parfois des noms de packages. Des attaquants publient des packages malveillants correspondants. Plus de 20% des packages suggérés par les LLM n'existent pas au moment de la génération.

# Toujours vérifier avant d'installer
npm view nom-du-package
npm view nom-du-package maintainers
npm view nom-du-package time

Outils de scanning

Semgrep

pip install semgrep
semgrep scan --config=p/owasp-top-ten ./src
semgrep scan --config=p/typescript ./src

Snyk

npm install -g snyk
snyk auth
snyk test                              # Vulnérabilités dépendances
snyk code test                         # Vulnérabilités code source
snyk test --severity-threshold=high    # CI/CD : bloquer si haute sévérité

CodeQL (GitHub)

# Dans GitHub Actions
- uses: github/codeql-action/init@v3
  with:
    languages: javascript-typescript
- uses: github/codeql-action/analyze@v3

Checklist de sécurité

## Avant la génération
- [ ] Aucun secret dans le prompt
- [ ] Contraintes de sécurité explicites ("requêtes paramétrées")

## Après la génération
- [ ] Lecture complète, ligne par ligne
- [ ] Packages vérifiés : existent et sont légitimes
- [ ] Pas d'injection SQL (requêtes paramétrées)
- [ ] Pas de XSS (sanitization des données utilisateur)
- [ ] Pas d'IDOR (vérification ownership)
- [ ] Validation des entrées côté serveur
- [ ] Pas de fuite d'info dans les erreurs

## Avant le merge
- [ ] Semgrep scan passé
- [ ] Snyk test passé
- [ ] Tests unitaires couvrant les cas sécurité
- [ ] Review par un pair humain

OWASP Top 10 et code IA

A01 - Broken Access Control : l'IA oublie systématiquement les vérifications d'autorisation. Faille #1.
A03 - Injection : concaténations SQL/NoSQL, classique des LLM.
A06 - Vulnerable Components : l'IA suggère des versions de packages obsolètes.
A08 - Software Integrity Failures : l'hallucination de packages = dependency confusion.

Les vulnérabilités que l'IA introduit ne sont pas nouvelles : ce sont les mêmes failles classiques, mais générées plus vite. La solution n'est pas de rejeter l'IA, mais d'adapter nos processus : automatiser la détection, former les équipes, et appliquer la confiance zéro à chaque ligne de code.

Sécurité du code généré par l'IA : risques, audits et bonnes pratiques en 2026