Cette statistique circule souvent en deux parties, et les gens citent systématiquement la plus rassurante. Les LLM produisent du code qui compile avec succès environ 90 % du temps. L’autre moitié : environ 45 % de ce code contient des vulnérabilités de type Top 10 OWASP, la liste standard de l’industrie des failles de sécurité les plus courantes et graves, comme des contrôles de connexion contournables et des bugs d’injection. Il est important d’être précis sur ce que cela signifie (et ne signifie pas) avant que cela ne provoque la panique ou ne soit ignoré.
Ce que ce chiffre ne signifie pas
Ce n’est pas l’affirmation que 45 % des applications créées par IA sont piratées, ni que le code généré est intrinsèquement pire ; les développeurs humains écrivent aussi du code vulnérable, c’est d’ailleurs pour cela que la liste OWASP existe. Ce n’est pas non plus un argument pour dire que les outils de codage IA sont inutiles, car un développeur qui examine le résultat détecte l’essentiel de ces failles dans le cours normal de son travail.
Ce que cela signifie : pour chaque génération, jouez-la à pile ou face, et c’est approximativement la probabilité que le code contienne une faille issue du catalogue des vulnérabilités les plus connues, tout en compilant et en fonctionnant parfaitement en démo. La faille n’a aucun impact sur le comportement visible. C’est là que se trouve le piège.
Pourquoi un code qui fonctionne n’est pas forcément un code sûr
Les modèles d’IA optimisent le succès visuel rapide, car c’est ce que le prompt demande et ce que le créateur peut vérifier d’un coup d’œil. La sécurité est précisément la propriété que l’on ne peut pas voir dans la fenêtre de prévisualisation, et les modes de défaillance documentés suivent cette logique. Le contrôle d’accès est implémenté dans le navigateur plutôt que sur le serveur, permettant à un utilisateur de contourner la vérification en modifiant le code sur sa propre machine ; l’application semble identique dans les deux cas. Les permissions de base de données sont configurées de manière trop large pour que tout fonctionne du premier coup, laissant les données exposées si une autre partie de l’application est compromise. Des secrets sont codés en dur dans les fichiers car la gestion des variables d’environnement est exactement le genre de corvée invisible que les modèles et les débutants ignorent, et ces identifiants se retrouvent ensuite sur des dépôts GitHub publics. Enfin, les flux utilitaires qui ont un réel poids sécuritaire (récupération de mot de passe, vérification OTP, gestion de session) ne sont tout simplement pas créés, car personne ne les présente en démo.
La position de confiance du créateur aggrave les choses. Un opérateur non technique ne peut pas lire le code généré pour vérifier tout cela, et les tests manuels explorent le scénario idéal, pas le contournement. L’application qui « fonctionne parfaitement » et l’application qui fuit toutes les données clients peuvent être la même application.
Ce qu’il faut vérifier avant que les vrais utilisateurs ne se connectent
Un audit minimal, en termes simples. Premièrement, l’application côté serveur : confirmez que ce qu’un utilisateur peut voir est décidé sur le serveur ou dans les règles de la base de données, et non en cachant des boutons dans l’interface. Deuxièmement, la posture de la base de données : les règles doivent refuser l’accès par défaut et l’accorder de manière restrictive ; pour les outils basés sur Supabase comme Lovable, cela signifie lire réellement les politiques RLS, et non faire confiance au prompt. Troisièmement, l’hygiène des secrets : recherchez les clés et chaînes de connexion codées en dur dans le dépôt, surtout si le projet a été synchronisé avec un dépôt public. Quatrièmement, les flux oubliés : vérifiez que la réinitialisation du mot de passe, l’expiration de session et les restrictions d’inscription existent et fonctionnent. Cinquièmement, le test du second utilisateur : créez deux comptes et essayez d’accéder aux données d’un utilisateur depuis la session de l’autre, y compris en modifiant directement les URLs. Rien de tout cela n’est exotique ; c’est précisément tout ce que la génération ignore.
Et notez la clause de maintenance : ce n’est pas une vérification ponctuelle. Chaque régénération est un nouveau lancer de dés, ainsi la boucle de correction sur une fonctionnalité liée à l’authentification implique de revérifier la couche que vous aviez déjà validée, et de payer pour le tour qui la revérifie. Ce fardeau de re-vérification est l’un des aspects du problème du Jour Deux : l’audit que vous effectuez aujourd’hui est celui que vous devrez refaire après le prochain changement.
Le choix de l’honnêteté
Cette liste d’audit représente le coût réel de ce chiffre de 45 %, et il n’y a que deux façons de le payer. Assumer la revue : vous, ou un développeur de confiance, relisez le code généré à chaque itération, en traitant l’IA comme un développeur junior rapide dont le travail de sécurité doit systématiquement être vérifié. C’est une approche viable pour des développeurs, mais une pure fiction pour tous les autres. Ou alors, éliminer la couche problématique : pour les applications métier comme les portails et les outils internes, appuyez-vous sur une plateforme telle que Softr, où l’authentification, les permissions et les règles d’accès aux données sont configurées visuellement au sein de l’infrastructure de la plateforme plutôt que via du code généré par projet. Ainsi, la « loterie des 45 % » ne s’applique jamais à la couche la plus critique. Ce qui n’est pas une option viable, c’est la troisième voie, très répandue : générer, jeter un œil à la démo, et mettre en production. Cette statistique existe précisément parce que c’est ce que fait la majorité des gens.