Auditer le code généré par IA : la checklist pour consolider les bases

Le vrai problème n’est pas que « ça marche »

Le vibe coding a rendu la création logicielle accessible : on décrit, l’IA génère, ça tourne. Le problème n’est pas là. Il arrive six mois plus tard (ou parfois bien avant), quand l’application plie sous la charge, qu’une faille dort dans un formulaire, ou qu’ajouter une fonctionnalité prend trois fois plus de temps que prévu parce que personne ne comprend vraiment le code.

Un code généré par IA « a l’air de marcher » quand on l’essaie seul. Il craque ailleurs : sous l’afflux d’utilisateurs (la charge), quand plusieurs personnes agissent au même instant (deux clients qui réservent la dernière place à la seconde près), et le jour où il faut le faire évoluer. Ce sont précisément les dimensions que l’IA optimise le moins. Quand on nous confie une application codée par IA à consolider, voici les points qu’on déroule, dans l’ordre.

1. Tenue en charge et performance

• Une requête à chaque frappe. L’IA branche volontiers une recherche qui interroge la base à chaque touche. On filtre plutôt une liste préchargée en mémoire, ou on debounce ; la recherche serveur passe par une URL paramétrée (bon pour le cache et le référencement), pas par un appel par caractère.
• Pas de cache. On pose de l’ISR (revalidate) avec une revalidation ciblée quand le contenu change, au lieu de servir du périmé pendant des heures. Et on chasse les N+1 : une requête agrégée plutôt que cent petites.
• Rate limiting en mémoire. Sur du serverless, un compteur en mémoire vit par instance : inopérant contre un brute-force distribué. Il faut un stockage partagé, posé avant l’ouverture publique (auth, formulaires, API).

2. Logique et état

• useEffect mal placé. Mettre à jour un état dans un effet pour en dériver un autre déclenche des re-renders en cascade. On dérive pendant le rendu ; pour un état externe (media-query, scroll, storage), on utilise useSyncExternalStore. Et chaque effet se nettoie dans son return, sinon fuite mémoire.
• Race conditions. Lire puis écrire côté application (stock, réservation, paiement) autorise le surbooking. On fait un décrément atomique en base, ou un verrou. Les callbacks de paiement sont idempotents et vérifient la signature avant tout effet : la notification serveur-à-serveur peut arriver plusieurs fois.
• Le happy path uniquement. L’IA gère le cas nominal et oublie le reste. On ajoute une dégradation gracieuse (une section optionnelle qui échoue ne casse pas la page), on gère explicitement le vide, le null, le timeout.

3. Ressources système

• Fuites mémoire. Listeners, timers, observers, contextes WebGL, souscriptions : tout ce qui s’ouvre doit se fermer. Invisibles en dev, elles s’accumulent sur une longue session, surtout mobile.
• Connection pooling. Un new PrismaClient() par requête sature le pool Postgres en serverless. On garde une instance unique et une connexion poolée, avec un timeout.

4. Conception et sécurité

C’est là que « l’IA ne saisit pas les implications critiques ».

• Cohérence avec l’architecture. Du code qui ignore les conventions du projet (couche d’accès données, prédicats partagés) crée une dette de refactoring. On impose les patterns du dépôt : une source de vérité unique, pas de logique dupliquée.
• Injection SQL : requêtes paramétrées, jamais de concaténation d’input.
• XSS : on assainit tout HTML riche avant de l’injecter ; on ne rend jamais du HTML utilisateur brut.
• Secrets : en variables d’environnement, jamais en clair dans le code, les logs ou une sortie de commande.
• Auth : un contrôle côté serveur non contournable à l’endpoint, pas seulement en interface. Une jauge de force de mot de passe est de l’UX (contournable), pas un filtre de sécurité.
• En-têtes : X-Frame en DENY, nosniff, Referrer-Policy, une CSP appliquée. Le durcissement se documente : sur un site statique, forcer un nonce impose le rendu dynamique et coûte la performance ; si la surface XSS est déjà fermée, c’est un arbitrage assumé, pas une négligence.

5. La discipline, pas seulement le code

Un audit sérieux ne juge pas que les lignes, mais la méthode.

• Vérifier contre le réel, pas la mémoire. Avant d’affirmer « c’est fait », on le constate : l’URL live, la base, l’état Git.
• Ne jamais exécuter à l’aveugle une opération destructrice en production sur la foi d’un état supposé.
• Types stricts (pas d’any sur les modèles et les API), tests des routes critiques (paiement, inscription), audit accessibilité, performance et métadonnées avant chaque commit.
• Tracer la dette consciente. Les choix assumés, écrits quelque part, pour qu’ils ne se transforment pas en surprise six mois plus tard.

Envie de lancer cette passe sur votre propre code, tout de suite ? Voici la checklist condensée en un fichier prêt à donner à votre assistant IA.

# Audit express d’une app codée par IA : checklist à donner à ton assistant

Colle ce fichier dans ton assistant IA (Claude, Cursor, ChatGPT…) avec accès à
ton code. Demande-lui de dérouler chaque point dans l’ordre, et pour chacun de
dire : OK, fragile ou absent, avec le fichier concerné et le correctif proposé.

## Ton rôle
Tu es un ingénieur senior chargé d’auditer une application générée par IA avant
de consolider ses bases. Tu ne te contentes pas de « est-ce que ça tourne » : tu
cherches où ça casse sous la charge, la concurrence et la maintenance. Sois
concret, cite le code, ne survends rien.

## 1. Tenue en charge
- [ ] Pas de requête à chaque frappe : liste filtrée en mémoire ou `debounce` ; la recherche serveur passe par une URL paramétrée.
- [ ] Cache en place (ISR / `revalidate`) avec revalidation ciblée ; aucune requête N+1.
- [ ] Rate limiting sur un stockage PARTAGÉ, pas un compteur par instance (inopérant en serverless), posé avant l’ouverture publique.

## 2. Logique et état
- [ ] Aucun état dérivé dans un `useEffect` ; chaque effet se nettoie dans son `return`.
- [ ] Pas de race condition : décrément atomique ou verrou sur stock, réservation, paiement.
- [ ] Callbacks de paiement idempotents, signature vérifiée avant tout effet.
- [ ] Les cas non nominaux sont gérés : vide, null, timeout, dégradation gracieuse.

## 3. Ressources système
- [ ] Tout ce qui s’ouvre se ferme : listeners, timers, observers, contextes, souscriptions.
- [ ] Une seule instance de client base de données, connexion poolée, pas un client par requête.

## 4. Conception et sécurité
- [ ] Cohérence avec l’architecture du projet ; pas de logique dupliquée, une source de vérité.
- [ ] Requêtes paramétrées, jamais de concaténation d’input ; HTML utilisateur assaini avant injection.
- [ ] Secrets en variables d’environnement, jamais en clair dans le code, les logs ou une sortie de commande.
- [ ] Contrôle d’accès côté serveur non contournable à chaque endpoint, pas seulement en interface.
- [ ] En-têtes de sécurité : `X-Frame-Options: DENY`, `nosniff`, `Referrer-Policy`, une CSP appliquée.

## 5. Discipline
- [ ] Vérifié contre le réel (URL live, base de données, état Git), pas contre une supposition.
- [ ] Types stricts (pas d’`any` sur les modèles et les API) ; tests des routes critiques (paiement, inscription).
- [ ] Aucune opération destructrice exécutée à l’aveugle en production.
- [ ] La dette assumée est tracée quelque part, pour ne pas la redécouvrir dans six mois.

---

Checklist par BetterNotCode, agence Bubble et no-code, développement assisté par IA.
Article complet : betternotcode.com/blog/audit-code-genere-ia

Consolider, ce n’est pas tout réécrire

Pour le dire sans jargon : on laisse l’IA bâtir une application qui marche, mais on ne compte jamais sur elle pour repérer où ça peut casser. Anticiper les points de rupture, c’est notre métier.

D’ailleurs, tout réécrire est rarement la réponse. On reprend d’abord les points porteurs : la sécurité, la tenue en charge, la cohérence de l’architecture. On garde ce qui tient. Tout réécrire coûte cher et rejoue souvent la même dette ailleurs.

C’est exactement notre travail : partir de ce que l’IA a produit, garder sa vitesse, et remettre des fondations sur lesquelles on peut construire pour de vrai. Si votre application vibe-codée commence à vous inquiéter, il n’est pas trop tard pour en parler.