Pourquoi le code généré mérite une revue spécifique

Les modèles apprennent sur des quantités de code public qui contiennent aussi de mauvaises pratiques, et ils optimisent pour un résultat qui « marche ». Ils oublient facilement ce que la demande ne précisait pas : vérifier que la facture demandée appartient bien à l’utilisateur connecté, limiter la taille d’un fichier envoyé, échouer proprement quand un service ne répond pas.

Deux risques sont propres à l’IA. D’abord les dépendances inventées : un assistant peut recommander un paquet qui n’existe pas, et le CERT-FR signale que des attaquants enregistrent ces noms pour piéger la chaîne logicielle. Ensuite le traitement non sécurisé des sorties, dixième risque du Top 10 OWASP LLM 2026 : une application qui affiche ou exécute directement ce que produit un modèle hérite de toutes ses erreurs. Le NIST a publié en 2024 un profil de son cadre de développement sécurisé, le SP 800-218A, consacré à l’IA générative.

Les failles à chercher en priorité

L’OWASP Top 10:2025 reste la meilleure grille de relecture. Les catégories qui reviennent le plus dans le code généré :

  • A01 – Contrôle d’accès défaillant : chaque requête doit vérifier que la ressource appartient à l’utilisateur, sinon un simple changement d’identifiant dans l’URL donne accès aux données d’un autre client.
  • A02 – Mauvaise configuration : mode débogage actif, CORS ouvert à tous, en-têtes de sécurité absents, politique CSP manquante.
  • A03 – Défaillances de la chaîne d’approvisionnement : dépendances inutiles, non épinglées, inexistantes ou abandonnées.
  • A04 – Défaillances cryptographiques : secrets en dur, mots de passe mal hachés, données sensibles non chiffrées.
  • A05 – Injection : SQL ou NoSQL construit par concaténation, commandes système composées avec une saisie, XSS par affichage non échappé.
  • A07 – Défaillances d’authentification : sessions sans expiration, absence de limite de tentatives, réinitialisation de mot de passe prévisible.
  • A08 – Intégrité des logiciels et des données : désérialisation de données non fiables, fichiers envoyés exécutés ou servis sans contrôle.
  • A10 – Mauvaise gestion des cas exceptionnels, nouvelle dans l’édition 2025 : erreurs qui révèlent des détails internes ou qui laissent passer au lieu de bloquer.

Une méthode de vérification en cinq passes

  1. Lire le diff, pas seulement le résultat. Repérer chaque endroit où une donnée externe entre, où un droit est vérifié, où un secret ou une dépendance apparaît.
  2. Tester les refus. Ajouter des tests où l’utilisateur A tente d’accéder aux données de B, où un champ est trop long, où un fichier a le mauvais type. Un test qui ne vérifie que le cas nominal ne prouve rien sur la sécurité.
  3. Analyser automatiquement. Détection de secrets, analyse des dépendances et de leurs vulnérabilités connues, analyse statique ; vérifier que chaque paquet proposé existe, est le bon et est maintenu.
  4. Contrôler la configuration. En-têtes, CORS, cookies, mode débogage, variables d’environnement, séparation test et production.
  5. Éprouver les cas d’erreur. Service tiers indisponible, base lente, entrée inattendue : l’application doit échouer de façon sûre, sans révéler d’informations internes.

Demander du code plus sûr dès le départ

La meilleure revue reste celle qu’on n’a pas besoin de faire. Une mission précise produit un code plus sûr : préciser le modèle d’autorisation (qui peut voir et modifier quoi), exiger des requêtes paramétrées et l’échappement des sorties, interdire toute nouvelle dépendance sans justification, demander les tests de refus d’accès et une liste des risques identifiés. Notre guide sur les assistants de code explique comment encadrer l’agent pendant qu’il travaille.

Exemple : un export CSV dans une application en production

Ajouter un export CSV des factures paraît anodin. Points à vérifier : l’export ne contient que les factures de l’utilisateur ou de son organisation ; les cellules qui commencent par =, +, - ou @ sont neutralisées pour éviter l’injection de formules à l’ouverture dans un tableur ; la taille de l’export est limitée ou traitée par lots ; l’action est journalisée sans copier le contenu ; un test vérifie qu’un autre client ne peut pas obtenir l’export ; la modification passe par un environnement de test et peut être annulée.

Ce que Prompt OS ajoute à la mission

Prompt OS inscrit ces exigences dans la mission avant que la première ligne soit écrite : validation des entrées et des sorties, sécurité des API, authentification et sessions, en-têtes web, sécurité de la base de données, dépendances et chaîne d’approvisionnement, traitement des erreurs, selon le profil du projet. Chaque mission se termine par les tests et preuves attendus. Pour un regard extérieur sur un site existant, AXDIA propose un audit de sécurité web au périmètre défini avant toute intervention.

Conclusion

Le code généré par l’IA n’est ni meilleur ni pire par principe : il est plus abondant et plus confiant. Une revue méthodique — accès, injections, secrets, dépendances, configuration, erreurs — transforme ce volume en avantage plutôt qu’en dette de sécurité.