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

Oui, une fois qu'un ingénieur qualifié relit chaque ligne, la teste et vérifie ses dépendances. Non, à la sortie du modèle. La différence n'est pas l'IA. C'est de savoir si quelqu'un a vérifié le travail avant que votre entreprise n'en dépende.

Cette réponse est courte à dessein, parce que la question mérite d'abord une réponse franche. La suite est la version longue : ce qui tourne vraiment mal quand du code généré par IA part sans relecture, ce qu'un vrai processus de relecture attrape, et quoi demander à un prestataire avant de lui confier le sujet. Si vous arrivez de notre explication plus large sur le vibe coding et le développement assisté par IA, voici l'approfondissement d'une question qui n'y reçoit qu'un paragraphe.

La liste honnête des risques : ce qui tourne mal dans le code IA non relu

Un modèle d'IA ne connaît pas votre métier, et il ne porte aucune conséquence quand il se trompe. Il prédit du code d'apparence plausible à partir des motifs de ses données d'entraînement, et « d'apparence plausible » n'affirme ni « correct » ni « sûr ». Quatre modes de défaillance reviennent sans cesse dans le code que personne n'a relu. L'ANSSI et le BSI soulignent que les assistants de programmation basés sur l'IA peuvent induire 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 sont entraînés sur de vastes corpus de données, qui peuvent inclure du code public de qualité variable ; cette seule caractéristique ne démontre pas la présence d'une vulnérabilité dans chaque sortie. Un rapport de Veracode a signalé 45 % d'échantillons vulnérables dans son protocole de test, notamment validations d'entrée manquantes, requêtes de base de données vulnérables aux injections, identifiants codés en dur en texte clair ; ce chiffre dépend de la méthodologie, des modèles, des langages et des tâches évalués et ne doit pas être extrapolé à tout code généré par IA. Aucun de ces bugs n'est exotique. Ce sont les mêmes erreurs que les développeurs juniors ont toujours commises. Ces erreurs peuvent être produites rapidement et à grande échelle par un assistant IA ; cette formulation ne permet toutefois pas de comparer rigoureusement tous les usages humains et automatisés. Pour une entreprise française ou belge, la facture ne s'arrête pas à l'incident technique : dès que des données personnelles fuient par une de ces failles, le RGPD impose de notifier la CNIL ou l'APD, et le dossier devient juridique autant qu'informatique. En cas de violation présentant un risque pour les droits et libertés des personnes, la CNIL indique qu'une notification initiale doit être effectuée dans les meilleurs délais, si possible dans les 72 heures, avec une notification complémentaire si nécessaire, selon les mêmes principes que ceux détaillés pour la gestion des incidents et des violations.

Les dépendances hallucinées. Demandez à un modèle d'IA de résoudre un problème et il recommandera parfois un paquet logiciel qui n'existe pas. Cela ressemble à une instruction d'import normale, cela se lit comme plausible, et c'est fictif. Une étude USENIX Security de 2025, fondée sur 576 000 échantillons produits par 16 modèles selon la publication de la conférence, a estimé la proportion de paquets hallucinés à au moins 5,2 % pour les modèles commerciaux et 21,7 % pour les modèles open source dans les conditions testées. Des chercheurs décrivent un scénario de slopsquatting dans lequel un attaquant pourrait publier un paquet malveillant sous un nom halluciné ; cette possibilité constitue un risque de chaîne d'approvisionnement à vérifier, plutôt qu'une preuve que chaque nom halluciné a déjà été exploité, si bien que le développeur suivant qui « corrige » l'erreur d'import pourrait installer un malware à la place. Les chercheurs en sécurité appellent désormais cela le slopsquatting. Les sessions de vibe coding dont les sorties ne sont pas relues peuvent accroître l'exposition à ce risque, mais cette affirmation nécessite une étude spécifique pour être quantifiée.

Les erreurs de logique subtiles. Toutes les pannes ne s'annoncent pas par un plantage. Un calcul de remise qui arrondit du mauvais côté en passant du HT au TTC, un filtre de dates qui laisse tomber en silence le dernier jour du mois, un contrôle de permissions qui marche pour tous les rôles sauf celui que personne n'a testé : ces bugs passent inaperçus, tournent pendant des semaines et n'émergent que quand un client remarque que le total est faux. La génération d'une réponse plausible ne garantit pas qu'un modèle détectera les erreurs logiques subtiles ; leur détection exige des tests, une revue et, selon le contexte, des contrôles métier.

La dette de maintenabilité. Un code que personne ne comprend est un passif même quand il fonctionne aujourd'hui. Les modèles d'IA dupliquent régulièrement la logique au lieu de la réutiliser, parce que chaque prompt reçoit une réponse neuve, sans mémoire de ce que la base de code contient déjà. La duplication et la faible compréhension du code peuvent augmenter les risques de maintenance et de régression, et l'équipe qui débogue peut n'avoir aucun auteur à qui demander pourquoi le code d'origine faisait ce qu'il faisait.

Rien de tout cela n'est un argument contre le code écrit par IA. Chacun de ces quatre problèmes est exactement ce qu'une étape de relecture existe pour attraper, et aucun n'exige un outillage exotique : juste une personne qui lit le résultat avant la mise en ligne.

Ce qui change quand le code généré par IA est relu

Un code assisté par IA et relu est un produit différent d'une production vibecodée, même quand le même modèle a écrit les deux. Deux pratiques font le vrai travail.

Un ingénieur humain lit chaque ligne. Pas un échantillon, pas les parties « qui ont l'air risquées » : chaque ligne, avant la fusion. Les décisions d'architecture, les frontières de sécurité et les cas limites restent des décisions de relecture, jamais acceptées sur la parole du modèle. Cette seule étape attrape la clé codée en dur, la validation manquante et l'import qui pointe vers un paquet inexistant. Notre propre version de cette pratique, sprint après sprint, est décrite en détail dans comment nous cadrons, construisons et relisons.

L'analyse des dépendances tourne à chaque build. Chaque push et chaque pull request déclenche une analyse automatisée des dépendances, Dependabot plus un audit des dépendances dans le pipeline CI, de sorte qu'un paquet porteur d'un avis de sécurité de niveau modéré ou supérieur fait échouer le build au lieu d'atteindre la production. C'est là qu'une dépendance hallucinée ou compromise est attrapée, même si un relecteur l'a manquée dans le diff.

Une chose mérite d'être dite franchement, parce que les prestataires ne le sont pas toujours. Nous ne proposons pas de test d'intrusion dans une construction standard. Si un projet a besoin d'une évaluation de sécurité indépendante, nous le nommons au cadrage et aidons à l'organiser, la même transparence que notre page sécurité affiche en entier.

Cette franchise est le point central. Un prestataire qui vous dit exactement quels contrôles tournent, et lesquels ne tournent pas, est un prestataire dont vous pouvez croire les autres affirmations. Un prestataire qui agite une « sécurité de niveau entreprise » sans nommer une seule pratique vous demande le même saut de foi qu'un modèle d'IA non relu prend déjà sur sa propre production.

Comment évaluer les vraies pratiques de sécurité d'un prestataire

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

• Qui lit le code, et quand ? Vous voulez un rôle nommé (un ingénieur senior, pas « l'équipe ») et une étape (avant la fusion, pas « à un moment »). « Notre processus le relit » n'est pas une réponse ; « un ingénieur lit 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, et si un contrôle en échec bloque une mise en ligne ou se contente de journaliser un avertissement.
• Que ne faites-vous pas ? Un prestataire qui nomme ses limites, pas de test d'intrusion en standard, pas de certification détenue, quelles qu'elles soient chez lui, vous dit quelque chose de vrai. Un prestataire sans aucune limite n'est relu par personne, vous compris.
• À qui appartient le code une fois livré ? Sécurité et propriété sont des questions liées. Un prestataire qui vous cède la pleine propriété du code n'a aucun intérêt à cacher un raccourci dans une base de code qu'il vous remettra entièrement.
• Où passe mon code, et où vivent 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 jamais. Un prestataire qui n'a pas la réponse n'a pas lu ses propres conditions d'utilisation, et le RGPD ne s'intéressera pas à cette excuse.
• Puis-je amener mon propre conseiller technique à l'appel ? Un prestataire sûr de ses pratiques accueille un second regard. Celui qui résiste à l'idée vous dit quelque chose aussi.

Une précision utile, parce que la confusion est répandue et coûteuse. Le règlement européen sur l'intelligence artificielle (AI Act) ne s'applique pas à votre logiciel parce qu'une IA a servi à l'écrire. Il vise les systèmes d'IA mis sur le marché : si le produit livré embarque lui-même une fonctionnalité d'IA, il tombe dans une catégorie de risque et porte les obligations qui vont avec ; si l'IA n'a été qu'un outil de développement, votre logiciel reste un logiciel ordinaire aux yeux du texte. Le RGPD, lui, s'applique dans les deux cas, dès la première donnée personnelle. Un prestataire qui mélange les deux, dans un sens ou dans l'autre, vend de la peur ou de l'insouciance, et aucune des deux ne vous sert.

Nous avons construit notre propre page sécurité autour de ce test exact : énoncer les pratiques assez clairement pour que votre conseiller puisse les vérifier, et dire clairement ce que nous ne faisons pas. Passez les affirmations de n'importe quel prestataire, les nôtres comprises, au même filtre.

Signaux d'alerte : quand un prestataire ne peut pas répondre à ces questions

Certaines réponses sont pires que pas de réponse du tout.

« Notre IA écrit du code sûr par défaut. » Aucun modèle ne le fait. Cette affirmation contredit le constat de Veracode ci-dessus et toutes les autres é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.

Une réassurance vague au lieu d'une pratique nommée. « Nous prenons la sécurité au sérieux » et « protection de niveau entreprise » ne décrivent rien de vérifiable. Demandez ce que ces formules veulent dire en pratique, et observez si la réponse devient plus précise ou plus abstraite.

Des certifications que personne ne peut produire. « Niveau bancaire » et « niveau militaire » sont des adjectifs marketing, pas des normes. Si un prestataire revendique ISO 27001, SOC 2 ou une certification comparable, demandez à la voir : un certificat porte un organisme, un numéro et une date d'expiration. S'il ne peut pas la produire, il ne la détient pas. Méfiez-vous aussi de la revendication « conforme RGPD » brandie comme un label. Le RGPD ne se certifie pas ainsi ; c'est une obligation, pas un trophée, et l'agiter comme un badge trahit souvent qu'on ne l'a pas travaillé.

Aucune réponse à « que ne faites-vous pas ». Toute vraie pratique de sécurité a une frontière. Un prestataire incapable de nommer la sienne n'est pas plus sûr. Il est moins précis, ce qui est autre chose, habillé pour y ressembler.

Le silence sur qui relit la production. Si un prestataire ne peut pas décrire son processus de relecture en une phrase claire, il n'en existe probablement pas. Cette seule lacune pèse plus que presque tout le reste de la liste, parce que c'est la pratique dont dépendent tous les autres garde-fous.

Questions fréquentes sur la sécurité du code IA

Le code généré par IA est-il sûr en production ?

Il peut l'être, une fois qu'un ingénieur relit chaque ligne, que les dépendances sont analysées et que le logiciel est testé contre de vrais critères d'acceptation. Il n'est pas sûr par défaut. Le code IA non relu part régulièrement avec exactement les vulnérabilités décrites plus haut.

Quel est le plus grand risque de sécurité du code généré par IA ?

La validation d'entrée manquante ou faible et les identifiants codés en dur sont les constats les plus fréquents. Un rapport de Veracode a signalé 45 % d'échantillons vulnérables dans son protocole de test en 2025 ; ce chiffre dépend de la méthodologie, des modèles, des langages et des tâches évalués et ne doit pas être extrapolé à tout code généré par IA. Ce sont deux erreurs anciennes et bien comprises, que tout processus de relecture de code est fait pour attraper.

Le code généré par IA peut-il contenir des dépendances fausses ou hallucinées ?

Oui. Les modèles recommandent parfois des paquets logiciels qui n'existent pas, un problème documenté que les chercheurs appellent hallucination de paquet. Des attaquants enregistrent de vrais paquets sous ces noms, donc installer le « correctif » peut installer un malware. L'analyse des dépendances et la relecture l'attrapent toutes les deux.

Les outils automatisés suffisent-ils à rendre le code généré par IA sûr ?

Aucun outil seul ne garantit la sécurité. La relecture humaine de chaque ligne et l'analyse automatisée des dépendances sont les pratiques qui font le vrai travail chez Globaprom aujourd'hui. Demandez à tout prestataire quels contrôles tournent exactement, et lesquels ne tournent pas, plutôt que de croire une liste d'outils.

Comment savoir si un prestataire relit vraiment le code généré par IA ?

Demandez qui lit le code et quand, en une phrase. Une vraie réponse nomme un rôle et une étape : un ingénieur, avant chaque fusion. Un prestataire qui ne peut pas répondre aussi précisément n'a probablement aucune étape de relecture.

Le code généré par IA est-il plus ou moins sûr que le code écrit par un humain ?

Ni l'un ni l'autre, en soi. La sécurité vient de la relecture et des tests, pas de qui ou quoi a tapé le premier jet. Le code IA relu et le code humain relu finissent sûrs pour la même raison : quelqu'un a vérifié.

Posez les questions difficiles avant de signer

La position la plus sûre avec n'importe quel prestataire, nous compris, est de demander exactement qui relit votre code et ce qui se passe quand un contrôle échoue. Décrivez ce que vous devez construire, et nous répondrons aux 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 →