Le code généré par IA est-il sûr ? Les vrais risques et ce que change la relecture

Oui, dès qu’un ingénieur compétent relit chaque ligne, la teste et vérifie ses dépendances. Non, dès sa sortie du modèle. La différence ne tient pas à l’IA, mais au fait que quelqu’un ait validé le travail avant que votre entreprise ne s’y appuie.

Cette réponse est volontairement concise, car la question appelle d’abord une réponse claire. Notre article sur le vibe coding et le développement assisté par IA ne lui consacre qu’un paragraphe. Les risques, la relecture qui les intercepte et les questions à poser à un prestataire demandent davantage de place.

Les risques concrets du code IA non relu

Un modèle d’IA ne connaît pas votre métier, et il n’assume aucune conséquence en cas d’erreur. Il génère du code plausible à partir des motifs de ses données d’entraînement, mais « plausible » ne signifie ni « correct » ni « sûr ». Quatre types de défaillances reviennent systématiquement dans le code non relu. L’ANSSI et le BSI soulignent que les assistants de programmation basés sur l’IA peuvent introduire de nouveaux risques de sécurité et recommandent de les utiliser avec prudence.

Les vulnérabilités de sécurité. Les modèles de langage ont appris sur du code public, erreurs comprises. Un rapport de Veracode a constaté que le code généré par IA introduisait une faille de sécurité connue dans 45 % des tâches testées : requêtes SQL exposées aux injections, cross-site scripting, injection dans les journaux, cryptographie faible. Aucune de ces failles n’est nouvelle : ce sont les mêmes erreurs que commettent les développeurs juniors depuis toujours. La différence ? Un assistant IA peut les produire à grande échelle et en un temps record. Pour une entreprise française ou belge, les conséquences dépassent l’incident technique : une fuite de données personnelles via l’une de ces failles déclenche une notification à la CNIL ou à l’APD, et le dossier bascule dans le juridique. En cas de violation présentant un risque pour les droits et libertés, la CNIL précise qu’une notification initiale doit être faite dans les meilleurs délais, si possible sous 72 heures, avec une mise à jour si nécessaire, selon les principes détaillés dans sa gestion des incidents et violations.

Les dépendances hallucinées. Demandez à un modèle de résoudre un problème, et il peut vous suggérer un paquet logiciel qui n’existe pas. L’instruction ressemble à un import classique, elle semble crédible… et elle est fictive. Une étude présentée à USENIX Security en 2025, basée sur 576 000 échantillons produits par 16 modèles (comme le détaille la publication de la conférence), estime la proportion de paquets hallucinés à au moins 5,2 % pour les modèles commerciaux et 21,7 % pour les modèles open source. Un attaquant peut publier un paquet malveillant sous un nom halluciné : c’est le slopsquatting. Le développeur qui « corrige » l’erreur d’import en installant le premier paquet venu télécharge alors un malware, et les sessions de vibe coding non relues sont le terrain idéal de cette attaque.

Les erreurs de logique subtiles. Toutes les pannes ne se manifestent pas par un crash. Un calcul de remise qui arrondit mal en passant du HT au TTC, un filtre de dates qui ignore silencieusement le dernier jour du mois, un contrôle d’accès qui fonctionne pour tous les rôles… sauf un : ces bugs passent inaperçus, tournent pendant des semaines, et ne remontent qu’au moment où un client constate une incohérence. Un modèle n’a aucune raison de les repérer : il a déjà produit une réponse qui a l’air terminée.

La dette de maintenabilité. Un code que personne ne comprend devient un passif, même s’il fonctionne aujourd’hui. Les modèles d’IA dupliquent souvent la logique au lieu de la factoriser, car chaque prompt génère une réponse indépendante, sans mémoire de la base de code existante. Cette duplication et cette opacité augmentent les risques de régression et compliquent la maintenance. L’équipe qui débogue plus tard n’aura personne à qui demander pourquoi le code initial faisait ce qu’il faisait.

Rien de tout cela ne condamne le code généré par IA. Chacun de ces problèmes est précisément ce qu’une étape de relecture est conçue pour détecter. Et aucun ne nécessite d’outils exotiques : juste une personne qui examine le résultat avant la mise en production.

Ce qui change quand le code IA est relu

Un code assisté par IA et relu n’a rien à voir avec une production issue du vibe coding, même si le même modèle en est à l’origine. Deux pratiques font toute la différence.

Un ingénieur humain relit chaque ligne. Pas un échantillon, pas les parties « à risque » : chaque ligne, avant toute fusion. Les choix d’architecture, les limites de sécurité et les cas limites restent des décisions humaines, jamais déléguées au modèle. Cette seule étape repère une clé codée en dur, une validation manquante ou un import pointant vers un paquet inexistant. Notre propre mise en œuvre de cette pratique, sprint après sprint, est détaillée dans notre processus de cadrage, de build et de relecture.

L’analyse des dépendances tourne à chaque build. Chaque push et chaque pull request déclenche une analyse automatisée des dépendances, Dependabot et un audit intégré au pipeline CI, de sorte qu’un paquet signalé comme vulnérable (niveau modéré ou supérieur) bloque le build au lieu d’atteindre la production. C’est là que sont détectées les dépendances hallucinées ou compromises, même si un relecteur les a manquées dans le diff.

Une précision s’impose, car les prestataires ne sont pas toujours transparents sur ce point. Nous n’incluons pas de test d’intrusion dans nos livraisons standard. Si un projet en a besoin, nous l’identifions dès le cadrage et aidons à le mettre en place, avec la même transparence que celle affichée sur notre page sécurité.

Cette franchise est cruciale. Un prestataire qui vous explique clairement quels contrôles sont en place, et lesquels ne le sont pas, est un prestataire dont vous pouvez croire les autres affirmations. Celui qui se contente d’agiter une « sécurité de niveau entreprise » sans détailler ses pratiques vous demande le même acte de foi qu’un modèle d’IA non relu appliqué à sa propre production.

Comment évaluer les pratiques de sécurité d’un prestataire

Toutes les boutiques de développement IA vous diront que leur code est sûr. Peu savent expliquer comment elles le savent. Posez ces questions lors d’un appel de cadrage, et écoutez les détails concrets, pas les adjectifs.

• Qui relit le code, et à quel moment ? Vous voulez un rôle précis (un ingénieur senior, pas « l’équipe ») et une étape claire (avant la fusion, pas « à un moment donné »). « Notre processus le relit » n’est pas une réponse ; « Un ingénieur relit chaque ligne avant la fusion » en est une.
• Quels outils tournent à chaque build, et que vérifient-ils vraiment ? L’analyse des dépendances est courante et vérifiable : demandez quel outil est utilisé, et si un échec de contrôle bloque la mise en production ou se contente d’émettre un avertissement.
• Que ne faites-vous pas ? Un prestataire qui assume ses limites, pas de test d’intrusion en standard, pas de certification spécifique, vous dit quelque chose de vrai. Celui qui n’en a aucune n’est relu par personne, pas même par vous.
• À qui appartient le code une fois livré ? Sécurité et propriété sont liées. Un prestataire qui vous cède la pleine propriété du code n’a aucun intérêt à y glisser des raccourcis dans une base qu’il vous remettra intégralement.
• Où passe mon code, et où sont stockées mes données ? Le prestataire envoie votre base de code à un modèle hébergé quelque part. Demandez lequel, sous quel contrat, et si vos données de production y transitent un jour. Un prestataire qui n’a pas la réponse n’a pas lu ses propres conditions d’utilisation, et le RGPD, lui, ne se satisfera pas de cette excuse.
• Puis-je inviter mon propre conseiller technique à l’appel ? Un prestataire sûr de ses pratiques accueille un second regard. Celui qui s’y oppose vous envoie un signal tout aussi clair.

Une précision utile, car la confusion est fréquente et coûteuse. Le règlement européen sur l’IA (AI Act) ne s’applique pas à votre logiciel parce qu’une IA a servi à le développer. Il cible les systèmes d’IA mis sur le marché : si le produit final intègre lui-même une fonctionnalité d’IA, il entre dans une catégorie de risque et doit respecter les obligations associées. Si l’IA n’a été qu’un outil de développement, votre logiciel reste un logiciel classique aux yeux de la loi. Le RGPD, en revanche, s’applique dans les deux cas, dès la première donnée personnelle traitée. Un prestataire qui mélange les deux, dans un sens ou dans l’autre, vend soit de la peur, soit de l’insouciance, et ni l’une ni l’autre ne vous servent.

Nous avons conçu notre page sécurité autour de ce principe : décrire nos pratiques avec assez de clarté pour qu’un conseiller technique puisse les vérifier, et assumer ce que nous ne faisons pas. Appliquez ce même filtre aux affirmations de n’importe quel prestataire, y compris les nôtres.

Signaux d’alerte : quand un prestataire ne répond pas à ces questions

Certaines réponses sont pires qu’un silence.

« Notre IA écrit du code sûr par défaut. » Aucun modèle ne le fait. Cette affirmation contredit les conclusions de Veracode et toutes les études indépendantes sur le sujet. Un prestataire qui la répète n’a pas lu la recherche, ou espère que vous ne l’avez pas lue.

Des assurances vagues au lieu de pratiques précises. « Nous prenons la sécurité au sérieux » ou « protection de niveau entreprise » ne décrivent rien de concret. Demandez ce que ces formules signifient en pratique, et observez si la réponse devient plus précise… ou plus floue.

Des certifications impossibles à produire. « Niveau bancaire » ou « niveau militaire » sont des slogans marketing, pas des normes. Si un prestataire revendique une certification ISO 27001, SOC 2 ou équivalente, demandez à la voir : un certificat valide mentionne un organisme, un numéro et une date d’expiration. S’il ne peut pas le produire, il ne la détient pas. Méfiez-vous aussi de la mention « conforme RGPD » brandie comme un label. Le RGPD n’est pas une certification, mais une obligation légale. L’agiter comme un trophée trahit souvent qu’on ne l’a pas vraiment appliqué.

Aucune réponse à « Que ne faites-vous pas ? ». Toute pratique de sécurité a des limites. Un prestataire incapable de les nommer n’est pas plus sûr : il est simplement moins rigoureux, ce qui est bien différent.

Le silence sur la relecture du code. Si un prestataire ne peut pas décrire son processus de relecture en une phrase claire, c’est qu’il n’en a probablement pas. Cette seule lacune pèse plus lourd que presque tout le reste, car c’est elle qui conditionne l’efficacité de tous les autres garde-fous.

Questions fréquentes sur la sécurité du code généré par IA

Posez les questions difficiles avant de signer

La position la plus sûre, avec n’importe quel prestataire, y compris nous, est de demander exactement qui relit votre code et ce qui se passe en cas d’échec d’un contrôle. Décrivez ce que vous devez construire, et nous répondrons à ces deux questions dès le premier appel, avec un périmètre fixe, un prix fixe et une date de livraison.

Demander un devis à prix fixe ⟶