Le code généré par IA est-il sûr ? Comment l'auditer

« Le code généré par IA est-il sûr ? » est la mauvaise question, et elle produit une réponse inutile : parfois. La version utile est : qu'est-ce que le code généré rate, de façon prévisible, et comment le vérifier ?

Car les défaillances ne sont pas aléatoires. Un modèle écrit du code qui ressemble à celui dont il a appris, c'est-à-dire la moyenne de tout ce qui est publié en ligne. Cette moyenne contient beaucoup de logiciels qui fonctionnent et beaucoup de raccourcis de tutoriel, et le modèle ne peut pas les distinguer par le seul contexte. Il optimise pour ça s'exécute, pas pour ça résiste à un attaquant.

Les failles se regroupent donc — ce qui les rend auditables. Voici la liste, dans l'ordre où nous la parcourons.

1. L'autorisation sur chaque endpoint qui reçoit un identifiant

C'est la plus importante, et il faut le dire clairement : une application peut passer tous les tests fonctionnels et livrer malgré tout les données d'un client à un autre.

Le schéma : un endpoint vérifie que vous êtes connecté mais jamais que l'enregistrement demandé est le vôtre. Le code généré fait cela en permanence, parce que dans la consigne il n'y a jamais eu qu'un seul utilisateur.

Nous avons détaillé le mécanisme et un test en 60 secondes dans ce qui casse à 1 000 utilisateurs. Pour un audit, la vérification est mécanique : listez chaque route acceptant un identifiant, et confirmez que chacune filtre par l'utilisateur ou l'équipe en cours. Pas la plupart. Chacune.

2. Les secrets côté client

Cherchez dans le bundle front-end compilé tout ce qui ressemble à une clé. Clés d'API, jetons de service, URL de base de données, identifiants d'administration : tout cela se retrouve avec une régularité inquiétante dans du JavaScript lisible par le navigateur, parce que le modèle a placé l'appel là où la donnée était nécessaire, pas là où le secret était protégé.

Deux règles : les secrets vivent dans des variables d'environnement côté serveur, et toute clé ayant un jour figuré dans du code client est déjà compromise — elle doit être renouvelée, pas simplement déplacée.

3. Les dépendances, y compris celles qui n'existent pas

D'abord les vérifications classiques : lancez l'audit de votre gestionnaire de paquets, mettez à jour tout ce qui fait l'objet d'une alerte, supprimez les paquets que rien n'importe.

Ensuite le problème plus récent. Les modèles inventent parfois des noms de paquets — des bibliothèques plausibles qui n'ont jamais été publiées. Normalement l'installation échoue. Le risque est que des attaquants surveillent ces noms hallucinés et les enregistrent : un paquet inexistant le mois dernier se résout aujourd'hui, et l'installer exécute leur code avec les privilèges de votre build.

La défense est simple mais doit être délibérée : vérifiez que chaque dépendance que vous n'avez pas choisie vous-même existe réellement et correspond à ce qu'elle prétend être. Regardez le dépôt, le nombre de téléchargements, l'historique de publication. Un paquet avec quelques dizaines de téléchargements et deux semaines d'existence, dans un fichier que vous n'avez pas écrit, mérite la méfiance.

4. L'injection à la frontière des chaînes

Le code de base de données généré est généralement paramétré, ce qui est bien. Les exceptions se concentrent toujours aux mêmes endroits : recherche, filtrage, tri, et tout ce qui comporte un nom de colonne ou de table dynamique. Ceux-là sont construits par concaténation, car le paramétrage ne les couvre pas proprement.

Cherchez dans le code les requêtes assemblées avec des littéraux de gabarit ou des +. Chacune est une candidate. Le même raisonnement vaut pour les commandes shell et les chemins de fichiers construits à partir d'entrées utilisateur.

5. Les réglages par défaut que personne n'a changés

Rapides, à forte valeur, souvent oubliés :

• Limitation de débit sur la connexion, la réinitialisation de mot de passe, l'inscription et tout endpoint coûteux. Sans elle, le bourrage d'identifiants est gratuit.
• CORS configuré sur une origine précise, pas un joker copié d'un tutoriel.
• Mode debug et erreurs verbeuses désactivés en production. Une trace d'appels est une carte de votre application.
• Comptes administrateur par défaut supprimés.
• En-têtes de sécurité présents — HSTS, X-Content-Type-Options, une politique de référent raisonnable.
• Téléversements validés par type et par taille, et stockés hors de la racine web.

6. Est-ce que ça échoue en mode fermé ?

La catégorie la plus subtile, et celle qui distingue un vrai audit d'une check-list.

Quand une vérification de permission lève une erreur, la requête est-elle refusée ou acceptée ? Quand le service d'authentification expire, le middleware bloque-t-il ou laisse-t-il passer ? La gestion d'erreurs générée penche vers garder l'application fonctionnelle, ce qui est exactement l'inverse de ce qu'il faut pour un contrôle de sécurité.

Relisez chaque catch entourant un chemin d'autorisation ou d'authentification et confirmez que le mode de défaillance est le refus.

Ce que tout cela ne signifie pas

Cela ne signifie pas qu'il ne faut pas utiliser l'IA pour écrire du code. Nous le faisons chaque jour, et le gain de productivité est réel. L'idée que le code IA serait uniquement dangereux est surtout défendue par des gens qui vendent autre chose.

Cela signifie que le code généré a besoin d'une revue de sécurité comme tout autre code — à la différence près que, contrairement au code écrit par un ingénieur qui pensait aux attaquants, cette revue n'a jamais eu lieu pendant l'écriture. Le travail n'a pas été sauté par malveillance. Il n'a jamais été demandé.

Un bon cadrage : traitez la sortie d'un modèle comme le premier jet d'un prestataire compétent livré sans cahier des charges. Probablement correct. Certainement non relu.

Mener l'audit

Parcourez la liste de haut en bas ; elle est à peu près ordonnée par dégâts évités par heure. Les points 1 et 2 concentrent les défaillances qui peuvent tuer une entreprise, et tous deux se vérifient généralement en une après-midi.

Rendez-le ensuite répétable : audit de dépendances dans la CI, détection de secrets sur les commits, et une étape de revue qui demande explicitement « qui a le droit de faire cela ? » pour chaque nouvel endpoint. Une fois cette habitude installée, l'origine du code cesse d'importer — ce qui est le vrai objectif.

Si vous préférez confier cet audit à notre agence, c'est un travail que nous faisons. Découvrez notre approche des applications propulsées par l'IA, ou envoyez-nous le dépôt et nous reviendrons avec une liste priorisée.