Vous avez fait construire une application avec Lovable, Bolt, Cursor ou ChatGPT. Elle fonctionne, quelques collaborateurs l'utilisent, et la question arrive : peut-on la mettre entre les mains de vrais clients ? Personne dans l'équipe ne sait répondre, parce que personne n'a écrit ce code ligne à ligne.
C'est exactement le rôle d'un audit de code généré par IA : transformer une inquiétude diffuse en une liste de faits vérifiables. Pas un avis de développeur sur la qualité du travail d'un autre développeur, mais un diagnostic sur quatre plans — ce qui expose vos données, ce qui vous met hors la loi, ce qui coûtera cher à faire évoluer, et ce qui vous empêchera de dormir la nuit du lancement.
Cet article détaille la grille que nous appliquons. Vous pouvez l'utiliser telle quelle pour interroger votre prestataire, ou pour savoir quoi exiger d'un rapport d'audit.
En bref
- Un audit de code généré par IA évalue quatre plans distincts : sécurité applicative, données et conformité, dette technique, exploitabilité en production.
- Les modèles d'IA réussissent bien là où les checklists regardent (injection SQL, cryptographie) et échouent massivement ailleurs : le taux de code sécurisé tombe à 15 % sur les failles XSS et 13 % sur l'injection de logs (Veracode, mars 2026).
- La dette technique du code assisté par IA prend une forme précise : la duplication. Les blocs dupliqués ont augmenté de 81 % depuis 2023, et la part de code refactorisé est tombée de 21 % à 3,8 % (GitClear, janvier 2026).
- Un audit débouche sur l'un de trois verdicts seulement : réparer, refondre par morceaux, ou repartir. Le plus fréquent est le premier.
« Ça marche » ne veut pas dire « ça tient »
Un prototype est jugé sur une seule question : est-ce que la démonstration passe ? Une application en production est jugée sur des questions que personne ne pose pendant la démo. Que se passe-t-il quand deux utilisateurs modifient la même fiche ? Quand la base grossit de deux ordres de grandeur ? Quand un utilisateur curieux change un identifiant dans l'URL ?
Les modèles génératifs sont excellents pour produire du code qui satisfait la première question. Rien dans leur entraînement ne les pousse à traiter les autres, sauf si on le leur demande explicitement — et on ne le leur demande presque jamais, parce qu'on ne sait pas qu'il faut le faire.
L'écart entre les deux n'est pas une question de talent. C'est une question de mandat. C'est aussi pourquoi l'audit précède la décision d'industrialiser, et non l'inverse : notre article sur la manière d'industrialiser un prototype IA jusqu'à la production décrit le chantier qui suit, une fois le diagnostic posé.
Ce que couvre un audit de code généré par IA : les quatre plans
Un audit sérieux sépare quatre familles de risques, parce qu'elles n'ont ni les mêmes conséquences ni les mêmes délais de correction.
1. Sécurité applicative
On cherche ce qui permet à quelqu'un d'obtenir ce à quoi il n'a pas droit. Les points de contrôle systématiques : secrets et clés d'API présents côté navigateur, contrôle d'accès vérifié côté serveur et pas seulement masqué dans l'interface, validation des entrées utilisateur, gestion des sessions, et dépendances vulnérables non mises à jour.
Le plus fréquent, et de loin, reste le contrôle d'accès appliqué uniquement à l'affichage : le bouton est caché, mais l'appel qu'il déclenche répond quand même à qui le formule directement.
2. Données et conformité
La sécurité d'une application IA ne s'arrête pas au code : elle englobe l'endroit où vivent les données. On vérifie où la base est hébergée, quels sous-traitants y accèdent, si les traitements sont documentés, si les durées de conservation existent, et si les personnes concernées peuvent exercer leurs droits.
La conformité RGPD d'une application générée en quelques jours est rarement acquise par accident. Le point de rupture typique : un service tiers américain intégré parce que le modèle l'a proposé comme le plus simple, sans qu'aucune base légale de transfert n'ait été examinée. Un hébergement souverain, en Europe, règle une partie du sujet — pas la totalité, mais celle qui bloque la mise en production.
3. Dette technique
Il ne s'agit pas de juger l'élégance du code, mais d'estimer ce que coûtera la prochaine évolution. On mesure la duplication, l'absence de tests, le couplage entre les couches, et la cohérence des conventions.
4. Exploitabilité
Le plan que tout le monde oublie. Existe-t-il des sauvegardes, et ont-elles déjà été restaurées au moins une fois ? Sait-on qu'un incident se produit avant que le client n'appelle ? Une autre équipe peut-elle réinstaller le projet à partir du seul contenu du dépôt ? Sans ces trois réponses, une application n'est pas exploitable, quelle que soit la qualité de son code.
Faites auditer votre application avant de la mettre en production. Nous réalisons un audit offert de votre projet généré par IA : nous déroulons la grille ci-dessus sur votre code et votre hébergement, et nous vous remettons un état des lieux écrit, avec les points bloquants séparés de ce qui peut attendre. → Demander l'audit offert de mon application
Pourquoi un scan de sécurité générique passe à côté de l'essentiel
C'est le résultat le plus contre-intuitif du sujet, et celui qui justifie un audit spécifique plutôt qu'un outil automatique.
Veracode a testé plus de 150 modèles de langage sur 80 tâches de développement, réparties sur quatre langages et quatre familles de vulnérabilités. Résultat publié en mars 2026 : 55 % seulement des générations produisent du code sécurisé. Mais la moyenne cache l'essentiel. Le détail par type de faille donne 82 % de réussite sur l'injection SQL et 86 % sur la cryptographie — et 15 % sur les failles XSS, 13 % sur l'injection de logs.
Autrement dit : les modèles sont bons précisément là où les scanners classiques et les checklists de sécurité regardent en premier, et mauvais là où personne ne pense à vérifier. Un outil automatique qui ne remonte rien sur votre projet n'est donc pas une bonne nouvelle : c'est une information de faible valeur.
L'écart par langage mérite aussi d'être connu si votre application a été générée sur une stack imposée : 62 % de réussite en Python, 57 % en JavaScript, et 29 % en Java.
La dette technique qui n'apparaît qu'à la première modification
Le second angle mort est économique. La dette technique du vibe coding ne ressemble pas à celle qu'on connaît : ce n'est pas du code mal écrit, c'est du code écrit plusieurs fois.
GitClear a analysé 623 millions de modifications de code entre 2023 et 2026. La duplication de blocs est passée de 40,3 à 73,0 par million de lignes modifiées, soit +81 %. Sur la même période, la part de code déplacé — l'indicateur du refactoring, donc de la consolidation — s'est effondrée de 21 % en 2022 à 3,8 % début 2026, pendant que le copier-coller montait de 9,4 % à 15,7 %.
Ce que cela signifie concrètement pour vous : votre application fonctionne, et elle continuera de fonctionner. Le coût n'apparaît pas au premier bug, il apparaît à la première évolution. Le jour où vous demandez de modifier une règle de calcul, elle existe en cinq exemplaires dans cinq fichiers, et l'équipe doit tous les retrouver. C'est ce facteur — pas la sécurité — qui explique la majorité des devis de maintenance jugés incompréhensibles.
L'avis de Laurent, Lead Développeur, spécialiste back-end & IA chez EpickOne : "Quand un dirigeant me demande si son application générée par IA est « bonne », je réponds toujours par une autre question : combien de temps vous reste-t-il avant la prochaine évolution ? Un code dupliqué ne se voit pas tant qu'on n'y touche pas. C'est pour ça que je fais toujours le même test en début d'audit : je prends la règle métier la plus susceptible de changer — un taux, un seuil, une condition — et je compte combien d'endroits il faudrait modifier. Ce chiffre-là prédit mieux le coût des trois prochaines années que n'importe quelle métrique de qualité."
Audit de code généré par IA : trois verdicts possibles
Un audit qui se termine par une liste de deux cents remarques n'a pas fait son travail. Il doit trancher entre trois options, et une seule.
Réparer. La logique métier est saine, les problèmes sont localisés : secrets à déplacer, contrôles d'accès à poser côté serveur, hébergement à rapatrier. C'est le cas le plus fréquent, et le moins coûteux — l'essentiel du code fonctionnel est conservé.
Refondre par morceaux. Le cœur métier vaut d'être gardé, mais une couche entière est à reprendre : l'accès aux données, l'authentification, ou le modèle de permissions. On remplace cette couche sans jeter le reste.
Repartir. Rare, et réservé aux cas où le prototype a servi à découvrir le besoin plus qu'à le résoudre : périmètre devenu très différent de l'intention initiale, ou technologie inadaptée à l'usage réel. Dans ce cas, ce qui est précieux n'est pas le code, c'est la spécification qu'il constitue.
Un prestataire qui annonce le troisième verdict avant d'avoir ouvert le projet ne vous audite pas, il vous vend une réécriture.
Ce que doit contenir le rapport que vous recevez
Exigez ces cinq éléments, quel que soit le prestataire :
- Une séparation nette entre bloquant et améliorable, avec la conséquence concrète de chaque point bloquant — pas une note globale sur dix.
- La localisation exacte de chaque problème, vérifiable par une autre équipe que celle qui a produit le rapport.
- Un chiffrage par lot, pour que vous puissiez arbitrer et étaler dans le temps.
- La liste des dépendances et des services tiers, avec le pays d'hébergement des données de chacun.
- Le verdict, explicite, parmi les trois ci-dessus.
Si l'un de ces éléments manque, le rapport ne vous permet pas de décider — et c'est pourtant sa seule raison d'être.
Questions fréquentes
Combien coûte un audit, et combien de temps prend-il ?
Sur une application issue d'un prototype, le diagnostic se mène en quelques jours, pas en semaines : le périmètre est petit par nature. Chez EpickOne, l'audit initial est offert précisément parce qu'il conditionne tout le reste — c'est lui qui transforme une inquiétude en devis chiffré. Les ordres de grandeur du chantier qui suit sont détaillés dans notre article sur le coût d'un projet d'intégration IA.
Faut-il auditer avant ou après avoir choisi son prestataire d'industrialisation ?
Avant, sans hésitation. L'audit est ce qui vous donne le vocabulaire pour comparer deux propositions. Sans lui, vous comparez des prix appliqués à des périmètres différents, ce qui n'a aucun sens.
Et si l'audit conclut qu'il faut tout reprendre ?
Demandez la démonstration, point par point, sur le code. Ce verdict existe, mais il est minoritaire, et il doit s'appuyer sur des éléments vérifiables par un tiers. Un audit honnête vous dit aussi ce qui va bien.
Décider sur des faits, pas sur une intuition
Une application générée par IA n'est ni un jouet ni un produit : c'est une hypothèse qui a été validée par l'usage. La question n'est pas de savoir si le code est « beau », mais si vous pouvez le confier à des clients sans exposer vos données ni hypothéquer vos trois prochaines années de budget.
C'est ce que produit un audit : trois pages de faits, un verdict, un chiffrage. Le reste — la stratégie d'ensemble, le choix des cas d'usage à traiter en priorité — relève d'une réflexion plus large, que nous déroulons dans notre guide de l'intégration de l'IA pour les dirigeants. Pour la partie technique, vous pouvez aussi consulter le détail de nos prestations IA ou échanger avec l'équipe qui reprend ces applications au quotidien.
Votre application générée par IA est-elle prête pour la production ? Nous déroulons la grille de cet article sur votre projet et vous remettons un état des lieux écrit — points bloquants, chiffrage par lot, verdict. L'audit est offert. → Faire auditer mon application générée par IA