L'IA peut coder votre projet — elle peut aussi le faire fuiter

Il y a une histoire que chaque fondateur se raconte en 2026 : « Je décris ce que je veux, l'IA le construit, et je mets en ligne. » Pour une landing page ou une liste de tâches, ça tient à peu près. Pour tout ce qui touche aux données d'un utilisateur, à un paiement ou à une connexion, ça s'effondre en silence — et la facture arrive plus tard, sous forme de fuite.

Nous développons des logiciels pour vivre, et nous utilisons l'IA tous les jours. Ce n'est donc pas un article « l'IA c'est mal ». C'est l'inverse : l'IA est le meilleur levier qu'un développeur ait jamais eu. Mais un levier coupe dans les deux sens. Confiez le même outil à quelqu'un qui ne sait pas lire ce qu'il produit, et vous n'obtenez pas un développeur — vous obtenez une façon très rapide de livrer des failles que vous ne voyez pas.

Voici ce que disent réellement les études.

L'IA écrit du code non sécurisé à un rythme obstinément élevé

Le rapport 2025 GenAI Code Security de Veracode a testé plus de 100 modèles sur 80 tâches de programmation. Le constat principal : 45 % du code généré par IA contenait une faille de sécurité connue. (Veracode)

Le détail qui devrait davantage vous inquiéter : ça ne s'améliore pas. « Les modèles plus récents et plus grands ne génèrent pas un code nettement plus sûr que leurs prédécesseurs. » Les modèles sont devenus spectaculairement meilleurs pour écrire du code qui fonctionne — et n'ont presque pas progressé pour écrire du code qui est sûr. Sur le Cross-Site Scripting, les modèles échouaient 86 % du temps ; sur l'injection de logs, 88 %.

Cela rejoint l'étude fondatrice de Stanford (Perry, Boneh et al.), qui a montré que les développeurs disposant d'un assistant IA écrivaient un code nettement moins sécurisé — et, pire, étaient plus convaincus qu'il était sécurisé. Voilà le piège en une phrase : l'outil qui vous rend plus rapide vous donne aussi un faux sentiment de sécurité.

« Ça marche » et « c'est sûr » sont deux affirmations différentes

Quand l'IA génère du code et que ça fonctionne, vous recevez un signal puissant et trompeur : la fonctionnalité marche, donc le travail est fini. Mais « ça marche » ne teste que le chemin nominal — l'utilisateur qui fait ce que vous attendiez. La sécurité, c'est le chemin anormal : l'utilisateur qui fait ce que vous n'attendiez pas.

Une IA vous écrira volontiers un formulaire de connexion qui authentifie parfaitement les vrais utilisateurs et qui laisse un attaquant se connecter en tant que n'importe qui via une injection SQL. Les deux comportements vivent dans les mêmes cinquante lignes. Le premier, vous le voyez en cinq secondes. Le second, vous le voyez quand c'est aux informations.

C'est déjà en train d'arriver — à grande échelle

Ce n'est pas théorique. La vague du « vibe coding » a produit une vague de fuites correspondante :

• Lovable, un grand constructeur d'applications par IA, a laissé des projets exposer leur code source et leurs identifiants de base de données pendant 48 jours après la clôture d'un signalement de bug. (The Next Web)
• Des chercheurs ont scanné des milliers d'applications « vibe-codées » déployées publiquement et ont trouvé plus de 2 000 vulnérabilités à fort impact — dont des centaines de secrets exposés et des fuites de données personnelles, de dossiers médicaux et de numéros de comptes bancaires. (TechTarget)
• GitGuardian a constaté que les dépôts avec Copilot activé fuitent des secrets à un taux 40 % plus élevé (6,4 % contre 4,6 %) que la population générale — et des chercheurs ont extrait de Copilot des milliers d'identifiants codés en dur, certains étant de vraies clés fonctionnelles. (GitGuardian)
• Une faille critique de GitHub Copilot Chat (CamoLeak, CVE-2025-59145, CVSS 9.6) a permis à des attaquants d'exfiltrer silencieusement du code source et des secrets depuis des dépôts privés. (Legit Security)

Un fil rouge traverse tout cela : une base de données mal configurée sans règles d'accès, un secret codé en dur dans le frontend, une API sans vérification d'autorisation. Rien d'exotique. Ce sont les choses qu'un développeur expérimenté vérifie par réflexe — et précisément celles qu'une IA n'ajoutera pas, sauf si vous savez déjà qu'il faut les demander.

« Mais ce n'est qu'un petit projet »

La phrase la plus dangereuse du logiciel. Les petits projets font fuiter les données aussi efficacement que les gros — ils ont simplement moins de monde pour le remarquer. Une base de données Supabase avec la sécurité au niveau des lignes désactivée se moque que votre app ait 50 utilisateurs ; elle expose les e-mails, mots de passe et fichiers de ces 50 personnes à quiconque ouvre l'onglet réseau.

Et un petit projet reste rarement petit en périmètre, même s'il reste petit en utilisateurs. À la seconde où vous ajoutez une connexion, acceptez un envoi de fichier, stockez une adresse ou encaissez un paiement, vous héritez de toute une catégorie de problèmes — authentification, contrôle d'accès, gestion des secrets, validation des entrées, limitation de débit — qui n'apparaissent jamais dans le prompt et n'apparaîtront pas dans le résultat tant que quelqu'un ne les met pas.

Là où l'IA excelle vraiment (et là où elle échoue)

Pour être clair sur la ligne que nous traçons :

L'IA est réellement excellente pour l'échafaudage, le code répétitif, les scripts ponctuels, les composants d'interface, l'explication de code inconnu, l'écriture de tests, et pour accélérer un développeur qui sait déjà à quoi ressemble le « correct ».

L'IA est réellement dangereuse pour tout ce où le coût d'une erreur subtile est une fuite et où vous ne pouvez pas évaluer le résultat : flux d'authentification, règles d'accès aux bases de données, traitement des paiements, tout ce qui stocke des données personnelles. Tout l'intérêt de l'expertise ici, c'est de savoir ce que l'IA a omis en silence — et on ne peut pas relire à la recherche d'un risque dont on ignore l'existence.

La différence entre un développeur qui utilise l'IA et un non-développeur qui utilise l'IA, ce n'est pas la vitesse de frappe. C'est que l'un des deux sait lire la réponse.

Quoi faire à la place

Vous n'avez pas à choisir entre « aller vite avec l'IA » et « être sécurisé ». Il suffit de garder dans la boucle un relecteur capable de faire la différence.

• Utilisez l'IA pour construire — puis faites lire le résultat par quelqu'un qui connaît la sécurité avant que ça touche de vraies données.
• Ne mettez jamais en ligne une base de données, un système d'authentification ou un flux de paiement que vous ne pouvez pas auditer vous-même.
• Considérez « ça marche dans la démo » comme le début des tests, pas la fin.
• Si c'est déjà en ligne, faites une revue de sécurité avant de l'apprendre à vos dépens.

C'est exactement ce que nous faisons : nous construisons avec l'IA à pleine vitesse et nous apportons l'expérience de développeur qui sait où elle prend des raccourcis — pour que vous ayez la vélocité sans la fuite.

FAQ

L'IA peut-elle construire toute mon application sans développeur ?

Pour un site statique ou un prototype simple, souvent oui. Pour tout ce qui comporte des connexions, des paiements, des envois de fichiers ou des données personnelles stockées — non, pas en toute sécurité. Les études trouvent systématiquement qu'environ 45 % du code généré par IA contient une faille, et ces failles se concentrent précisément dans les parties qui manipulent des données sensibles.

N'est-ce pas un problème réservé aux grosses applications complexes ?

Non. Les petites applications fuitent les données tout aussi facilement — une seule base mal configurée ou une clé codée en dur expose tous vos utilisateurs. La taille de l'application ne change pas la taille de la fuite.

Utiliser un modèle d'IA plus récent et plus intelligent règle-t-il le problème de sécurité ?

Pas vraiment. Veracode a constaté que les modèles plus récents et plus grands écrivent un code plus correct mais pas plus sûr — le taux de failles est resté à peu près stable malgré l'amélioration des modèles.

Dois-je donc arrêter d'utiliser l'IA pour coder ?

Non — nous l'utilisons tous les jours. L'idée, c'est que l'IA doit accélérer un développeur, pas le remplacer. Utilisée par quelqu'un qui sait relire le résultat, c'est le meilleur outil du secteur. Utilisée à l'aveugle, c'est un moyen rapide de livrer des failles.