Ce qu'on trouve vraiment en auditant du code généré par IA
L'IA peut construire une app en un week-end. Mais qu'est-ce qu'il y a vraiment dans le code ? On a audité assez de projets vibe-codés pour voir les patterns — voici ce qui casse.
- 1. De la logique hallucinée qui passe toutes les démos
- 2. La même chose construite de trois façons différentes
- 3. Les dépendances fantômes
- 4. La gestion d’erreurs qui avale tout
- 5. Des failles de sécurité cachées derrière des features qui marchent
- 6. Pas d’architecture, juste des fichiers
- Ce que ça veut dire pour vous
- Ce qu’on fait concrètement
On reçoit un nouveau type de client ces derniers temps.
Des fondateurs, des responsables produit, parfois des CTOs qui ont hérité de quelque chose. Ils ont livré vite — très vite — avec Cursor, Copilot, Claude, ou un mix des trois. L’app fonctionne. Des utilisateurs sont dessus. Le revenu rentre. Et maintenant ils ont un problème : personne dans leur équipe ne comprend vraiment le codebase.
Ils ne l’ont pas écrit. C’est l’IA qui l’a fait. Et ils ont besoin de quelqu’un qui lit le code — pas juste qui le prompte — pour leur dire ce qu’ils ont.
C’est nous. Voici ce qu’on trouve systématiquement.
1. De la logique hallucinée qui passe toutes les démos
C’est le plus dangereux. Le code tourne. Les tests passent (quand il y en a). La feature a l’air correcte dans l’UI. Mais la logique sous-jacente ne fait pas ce que tout le monde croit.
On a audité une app fintech où la fonction de calcul d’intérêts produisait des chiffres crédibles pour le jeu de données de démo. Quand on a tracé le calcul réel, il était faux — pas de beaucoup, mais assez pour s’accumuler en vrai risque juridique sur des milliers de transactions. L’IA avait généré une formule qui ressemblait à un calcul d’intérêts composés, mais qui n’en était pas un.
Personne ne l’avait vu parce que personne n’avait lu la fonction. Ils avaient testé le résultat, vu des chiffres raisonnables, et mis en production.
Ce qu’il faut chercher : Toute fonction qui fait du calcul, de la validation, ou de la logique métier critique. Ne testez pas le résultat — lisez l’implémentation.
2. La même chose construite de trois façons différentes
Les outils IA n’ont pas de mémoire d’une session à l’autre comme votre équipe d’ingénieurs. Demandez-lui de construire l’authentification lundi, il utilise un pattern. Demandez le contrôle d’accès par rôles mercredi, il invente une approche complètement différente. Ajoutez l’auth par clé API vendredi, et vous obtenez une troisième.
On trouve régulièrement des codebases avec trois ou quatre patterns différents pour la même préoccupation : la gestion d’erreurs faite différemment dans chaque fichier, le state management réparti entre plusieurs approches, les appels API encapsulés dans des abstractions différentes selon le moment où ils ont été générés.
Le code marche. Mais le maintenir est un cauchemar parce qu’il n’y a aucune cohérence. Un ingénieur humain qui hérite de ce codebase doit apprendre trois systèmes au lieu d’un.
Ce qu’il faut chercher : Prenez n’importe quelle préoccupation transversale (gestion d’erreurs, auth, fetching de données) et tracez-la dans le codebase. Si vous trouvez plus d’un pattern, l’IA a construit en silos.
3. Les dépendances fantômes
Les outils IA sont entraînés sur des millions de packages. Ils importent des bibliothèques qui résolvent élégamment votre problème — des bibliothèques qui ne sont plus maintenues, qui ont des vulnérabilités connues, ou qui font la même chose qu’une autre bibliothèque déjà dans votre projet.
On a vu des package.json avec 80+ dépendances dont 30 pouvaient être supprimées. Des utilitaires en double qui font le même travail. Des packages importés pour une seule fonction qu’on pourrait écrire en cinq lignes. Des packages abandonnés avec des CVE ouvertes.
Chaque dépendance inutile, c’est de la surface d’attaque, du poids de bundle, et un truc de plus qui peut casser à la mise à jour.
Ce qu’il faut chercher : Lancez npm audit ou équivalent. Puis vérifiez votre liste de dépendances contre ce qui est réellement importé. Vous serez surpris.
4. La gestion d’erreurs qui avale tout
Le code généré par IA adore les try/catch. Il en met partout. Et dans le bloc catch ? Généralement console.log(error) ou, pire, rien du tout.
Résultat : votre application échoue silencieusement. Les utilisateurs voient un écran vide ou des données périmées. Votre monitoring affiche du vert. L’erreur s’est produite, a été catchée, loguée dans une console que personne ne lit, et la vie a continué — jusqu’au jour où.
On a audité une plateforme logistique où les mises à jour de statut d’expédition échouaient silencieusement pour un sous-ensemble de transporteurs. Le bloc catch loguait l’erreur et retournait le dernier statut connu. Les utilisateurs voyaient “En Transit” pour des colis livrés trois jours plus tôt. Le dashboard affichait 100% d’uptime.
Ce qu’il faut chercher : Recherchez les blocs catch vides et les catch (e) { console.log dans votre codebase. Chacun d’entre eux est un endroit où votre app vous ment.
5. Des failles de sécurité cachées derrière des features qui marchent
Les outils IA optimisent pour “est-ce que ça marche ?” pas “est-ce que c’est sécurisé ?” On trouve systématiquement :
- Des clés API codées en dur dans le code frontend
- Des requêtes SQL construites par concaténation de chaînes
- Des vérifications d’authentification absentes sur les routes API “que seul le frontend appelle”
- Des entrées utilisateur rendues sans sanitisation
- Du CORS configuré à
*parce que l’IA n’a pas trouvé la bonne origine
Ce ne sont pas des vulnérabilités exotiques. C’est le Top 10 OWASP de base. Mais l’IA ne les signale pas parce que vous lui avez demandé de construire une feature, pas de la sécuriser.
Ce qu’il faut chercher : Lancez un scan de sécurité basique (OWASP ZAP, Snyk). Puis vérifiez manuellement chaque route API pour le middleware d’auth. Les trous seront évidents.
6. Pas d’architecture, juste des fichiers
C’est peut-être le pattern le plus révélateur. Les codebases construits par des humains ont une architecture — des décisions intentionnelles sur où vont les choses, comment les couches communiquent, qu’est-ce qui dépend de quoi. Les codebases générés par IA ont des fichiers.
Des composants qui fetchent les données, les transforment, gèrent les erreurs et rendent l’UI — tout au même endroit. De la logique métier éparpillée dans des routes API sans couche de service partagée. Des requêtes base de données dupliquées dans douze endpoints différents parce que chacun a été généré indépendamment.
L’app marche aujourd’hui. Mais le jour où vous devez changer le comportement d’une entité centrale, vous éditez trente fichiers au lieu d’un.
Ce qu’il faut chercher : Essayez de répondre à “où vit la logique métier pour [entité centrale] ?” Si la réponse est “partout”, vous avez des fichiers, pas de l’architecture.
Ce que ça veut dire pour vous
Rien de tout ça ne veut dire que les outils IA sont mauvais. On les utilise nous-mêmes — beaucoup. La différence, c’est qu’on comprend ce que l’IA produit parce qu’on a passé des années à lire, écrire et débugger du code à la dure. On sait à quoi ressemble une bonne architecture parce qu’on a construit des systèmes qui tournent encore en production dix ans après.
L’IA est un outil puissant. Mais un outil puissant dans les mains de quelqu’un qui ne comprend pas le matériau, ça produit beaucoup d’output et pas beaucoup d’artisanat.
Si vous avez livré quelque chose avec l’IA et que ça marche — tant mieux. C’est plus loin que la plupart des gens. Mais avant de scaler, de recruter une équipe autour, ou de lever des fonds dessus, vous avez besoin de quelqu’un qui lit vraiment le code pour vous dire ce qu’il y a dedans.
Ce qu’on fait concrètement
Notre Bilan Technique inclut désormais une évaluation dédiée du code généré par IA — logique hallucinée, dépendances fantômes, failles de sécurité et cohérence architecturale. Deux semaines, et vous saurez exactement ce que vous avez.
Pour les codebases déjà en production, notre service Maintenance & Support inclut la remédiation continue de code IA — remplacement systématique des patterns fragiles générés par IA par du code qu’un ingénieur humain peut réellement maintenir.
Et si vous ne savez pas s’il faut continuer à construire sur ce que vous avez ou repartir de zéro, c’est exactement le rôle de Stratégie & Discovery.
Parlons-en. On vous dira franchement ce que vous avez.