Refactoring d’un Site Codé par IA Sauver Votre Investissement sans Tout Refaire

Le code généré par IA : promesse, réalité, et angles morts

Les outils de génération de code par IA ont franchi un seuil en 2024-2025. Lovable, v0 Vercel, Bolt StackBlitz, Replit Agent, Cursor, Claude Code, GitHub Copilot Workspace — chacun avec sa philosophie, mais une promesse commune : permettre à un non-développeur (ou à un développeur sous contrainte de temps) de livrer un site fonctionnel sans écrire chaque ligne à la main.

Selon le Stack Overflow Developer Survey 2025, 76% des développeurs professionnels utilisent ou prévoient d’utiliser des outils d’assistance IA dans leur workflow, contre 70% en 2024. La progression est nette. Et au-delà des développeurs, une vague entière de “vibe coders” — fondateurs, designers, product managers — produisent désormais leurs propres applications sans passer par une équipe technique.

Là où ça se corse : un site IA livré en mode démo n’est pas un site IA prêt pour la production. La différence se joue sur six axes invisibles à l’utilisateur final mais critiques pour la survie du produit : la qualité du typage, la robustesse de l’état applicatif, la couverture de tests, la gestion des erreurs, l’observabilité, et la maintenabilité long terme.

L’IA optimise pour le résultat visible. Elle ne sait pas — encore — anticiper le scénario où trois utilisateurs simultanés stressent votre handler de paiement, ni le moment où votre table Supabase de 800 lignes atteindra 80 000 lignes. Elle produit un code qui marche à la démo, pas un code qui résiste au monde réel.

Les patterns récurrents qu’on retrouve dans 90% des projets IA

Après plus de 40 audits de projets générés par Lovable, v0, Bolt, Replit Agent ou Cursor depuis dix-huit mois, on identifie une cartographie quasi systématique des problèmes. Pas tous présents dans tous les projets, mais la combinaison est récurrente. Voici les huit patterns qui reviennent le plus souvent.

1. Le composant monstre. Un fichier de page (souvent HomePage.tsx, Dashboard.tsx ou App.tsx) qui dépasse 800 lignes — et qu’on a vu monter à 1700 dans certains cas. Toute la logique métier, l’UI, la gestion d’état, les appels API et les effets de bord cohabitent dans un seul gros bloc. C’est l’effet “IA qui continue à empiler du code dans le même fichier sans jamais le scinder”.

2. La duplication silencieuse. Trois variantes du même bouton, quatre versions légèrement différentes de la fonction fetchUser(), deux fonctions utilitaires qui font exactement la même chose avec des noms différents. L’IA, sans contexte global de votre codebase, recrée à chaque fois ce dont elle a besoin localement.

3. Le typage absent ou cosmétique. Du TypeScript qui ressemble à du TypeScript mais qui est en réalité du JavaScript déguisé : any partout, types unknown non narrowés, props sans interface explicite, retours de fonction non typés. Le compilateur passe, mais aucune sécurité réelle.

4. L’état applicatif fragile. Des useState qui auraient dû être un useReducer. Des données dérivées stockées en state au lieu d’être calculées. Des dépendances manquantes dans les useEffect. Des courses de rendu (race conditions) qui se déclenchent au pire moment.

5. Zéro error boundary. Une erreur dans un composant fait sauter toute l’application. Pas de fallback UI, pas de log, pas de récupération. L’utilisateur voit un écran blanc et part chez le concurrent.

6. Zéro test. Pas de tests unitaires, pas de tests d’intégration, pas de tests end-to-end. On déploie en espérant. Quand un bug apparaît, on n’a aucun filet de sécurité pour vérifier que la correction ne casse rien d’autre.

7. L’absence d’observabilité. Pas de logs structurés, pas de monitoring d’erreurs (Sentry, LogRocket), pas de tracking des Web Vitals. Quand un utilisateur signale un bug, vous n’avez aucun moyen de reproduire ce qu’il a vu. L’observabilité est l’angle mort par excellence des projets IA.

8. Le couplage caché. Des composants qui dépendent silencieusement d’un contexte global, des modifications d’état qui déclenchent des chaînes de re-render imprévues, des effets de bord planqués dans des hooks personnalisés. Toucher à un fichier en casse trois autres.

Refaire ou refactorer : la décision rationnelle

La première question qu’on entend en rendez-vous est presque toujours la même : “Vous pensez qu’il faut tout refaire ?”. Et la réponse est presque toujours non. Pas parce qu’on est romantiques avec le code existant, mais parce que les chiffres ne mentent pas.

Refaire un site de zéro, c’est trois à six mois de delivery, du budget, et surtout la perte de toute la connaissance produit accumulée. Toutes les micro-décisions de design, de copy, de flux utilisateur, d’edge cases déjà traités — toute cette information disparaît dans le grand efface-tout du “on recommence proprement”. Et statistiquement, le nouveau code accumulera sa propre dette technique en six à douze mois.

Refactorer, en revanche, c’est garder l’asset existant — le produit qui tourne, les utilisateurs, le SEO, les intégrations — et travailler par incréments contrôlés. Vous continuez à livrer pendant que vous nettoyez. Et chaque tranche de refactoring est mesurable : tant de fichiers passés en TypeScript strict, tant de composants découpés, tant de pourcent de couverture de tests gagné.

Il existe néanmoins trois cas où refaire devient rationnel. Premièrement : la stack initiale est inadaptée au cas d’usage long terme (par exemple un Bolt en React qui devrait être un site statique pour 95% de ses pages). Deuxièmement : moins de 30% du code généré a une valeur réelle — c’est-à-dire que l’IA a essentiellement produit du boilerplate qu’on retrouverait dans n’importe quel template gratuit. Troisièmement : un risque sécurité majeur structurel impossible à patcher (typiquement une architecture client-only qui expose des clés API).

Dans tous les autres cas — la grande majorité — refactorer est la décision économique et technique la plus solide. Et c’est précisément la méthode qu’on documente ci-dessous.

La méthode Snack Groupe : refactorer en tranches

Notre approche tient en une phrase : on type la surface, on extrait les fonctions pures, on isole les effets de bord, on ajoute de l’observabilité, on ajoute des tests, on refactore en tranches. Six gestes, dans cet ordre. Pourquoi cet ordre ? Parce que chaque étape sécurise la suivante.

Geste 1 — Typer la surface. Avant de toucher à quoi que ce soit, on durcit le périmètre. On force TypeScript en mode strict. On supprime les any de la frontière de l’application : props des composants exposés, retours d’API, formats de données entrants. À ce stade, beaucoup d’erreurs cachées apparaissent automatiquement — c’est le but. Mieux vaut les voir maintenant que mardi prochain à 23h.

Geste 2 — Extraire les fonctions pures. Une fonction pure prend des entrées, retourne une sortie, et ne touche à rien d’autre. C’est la brique la plus facile à tester et la plus stable dans le temps. On parcourt les gros fichiers et on extrait toutes les sous-fonctions qui peuvent l’être : calculs, transformations de données, formattages, validations. Chaque extraction réduit la complexité cognitive du fichier d’origine.

Geste 3 — Isoler les effets de bord. Les appels API, les écritures en base, les manipulations du DOM, les localStorage, les analytics — tout ce qui sort du périmètre purement fonctionnel. On les regroupe dans des modules dédiés (services/api.ts, services/storage.ts, etc.). Cela rend les tests possibles et les bugs traçables.

Geste 4 — Ajouter l’observabilité. Sentry pour les erreurs runtime côté client, un système de logs structurés côté serveur, un outil de session replay (LogRocket, FullStory ou équivalent) pour reproduire les bugs utilisateurs. À partir de cette étape, vous arrêtez de deviner. Quand un bug est signalé, vous savez ce qu’il s’est passé.

Geste 5 — Ajouter des tests sur les zones critiques. Pas une couverture de 100% — ce serait du gaspillage. On cible les zones critiques : tunnels de paiement, flux d’authentification, parties qui touchent les données utilisateur sensibles. Vitest pour l’unitaire, Playwright pour l’end-to-end. Chaque test ajouté est un filet qui empêche un crash futur.

Geste 6 — Refactorer en tranches. Une fois les cinq premières étapes posées, on peut découper en sécurité. On cible un composant ou un module à la fois, on le découpe en sous-composants, on le déplace dans une structure de dossiers cohérente, on remplace les patterns problématiques. Chaque tranche est livrée, testée, déployée — puis on passe à la suivante.

Les 5 piliers d’un refactoring qui ne casse rien

Le protocole pratique : 30 jours pour stabiliser

Voici comment se déroule, concrètement, une mission de refactoring Snack Groupe sur un site généré par IA. Le calendrier type est d’environ trente jours ouvrés pour un site de taille moyenne (8 à 25 routes, une dizaine de tables Supabase ou équivalent, 1 à 3 intégrations tierces).

Semaine 1 — Audit et stabilisation d’urgence. Lecture froide du code, audit automatisé, identification des bugs critiques en production, hotfix des problèmes bloquants si nécessaire. À la fin de la semaine 1, vous avez un rapport complet, un plan d’action priorisé, et les bugs P0 sont éteints.

Semaine 2 — Durcissement de la surface. Activation du mode strict TypeScript, typage des frontières, isolation des appels API, mise en place de Sentry et des logs structurés. À la fin de la semaine 2, vous avez une visibilité complète sur ce qui se passe dans votre application en production.

Semaine 3 — Tests sur le chemin critique. Couverture en tests des flux critiques (authentification, paiement, opérations sensibles sur les données utilisateur). Mise en place de la CI (GitHub Actions, GitLab CI ou équivalent) pour bloquer les régressions. À la fin de la semaine 3, votre tunnel de conversion est verrouillé.

Semaine 4 — Refactoring ciblé et documentation. Découpage des composants monstres, extraction des fonctions utilitaires en modules réutilisables, élimination du code mort identifié à la semaine 1, documentation des choix d’architecture. À la fin de la semaine 4, votre codebase est saine et maintenable pour les six à douze prochains mois.

Témoignages et résultats clients

Les chiffres et les retours qu’on partage ci-dessous viennent d’interventions réelles menées par notre équipe en 2024 et 2025 sur des projets initialement générés par Lovable, v0 Vercel et Bolt StackBlitz. Identités modifiées pour respecter les NDA, contexte technique conservé.

Selon l’enquête JetBrains Developer Ecosystem 2024, 41% des développeurs ayant utilisé un générateur de code IA pour une partie significative d’un projet déclarent avoir dû refactorer ce code dans les six mois — soit pour des raisons de performance, soit de maintenabilité, soit de sécurité. La proportion grimpe à 67% pour les projets entièrement générés par IA sans intervention humaine sur l’architecture. Notre expérience terrain confirme largement ces ordres de grandeur.

Avantages et limites du refactoring incrémental

Nos services de rescue et refactoring IA

Snack Groupe est une agence basée au 188 Rue de Rivoli à Paris, fondée en 2018 et indépendante depuis 2022. Notre équipe a livré plus de 270 projets avec un taux de satisfaction client de 97%. Pour les sites générés par IA, nous avons formalisé quatre offres distinctes.

10 bonnes pratiques pour ne pas reproduire la dette technique

Une fois votre site refactoré, l’objectif est de ne pas retomber dans les mêmes ornières. Voici les dix règles qu’on installe systématiquement chez nos clients pour garder la dette technique sous contrôle, même en continuant à utiliser des outils IA.

1. Forcez le mode strict TypeScript dès le premier jour. "strict": true dans tsconfig.json. Sans exception. Un nouveau projet sans typage strict est une dette future programmée.
2. Imposez une limite de taille par fichier. 300 lignes maximum pour un composant, 500 pour un module utilitaire. Au-delà, on découpe — règle non négociable. ESLint avec la règle max-lines automatise la vérification.
3. Séparez physiquement la logique métier de la présentation. Composants UI dans components/, logique métier dans features/ ou domain/, services techniques dans services/. La séparation des concerns reste un classique pour de bonnes raisons.
4. Activez Sentry (ou équivalent) avant même le premier déploiement public. Le coût d’installation est de 30 minutes. Le bénéfice se mesure dès le premier bug remonté en production.
5. Écrivez au moins un test end-to-end pour chaque flux critique. Playwright ou Cypress. Le tunnel d’inscription, le tunnel de paiement, les actions destructives. Ces tests sont votre dernière ligne de défense.
6. Mettez en place une CI obligatoire avant merge. tsc --noEmit, eslint, tests unitaires, tests E2E sur les flux critiques. Pas de merge si la CI est rouge. Y compris pour vous-même.
7. Code review systématique, même pour les solos. Si vous êtes seul, faites passer chaque PR par Cursor, Claude Code ou GitHub Copilot en mode review. Ils détectent une partie significative des problèmes évidents.
8. Documentez les choix d’architecture, pas le code. Un fichier docs/decisions/ avec les décisions importantes (pourquoi Supabase, pourquoi tel pattern d’état, pourquoi telle librairie). Le futur “vous” remerciera l’actuel “vous”.
9. Réservez 20% du temps de dev à la qualité. Une semaine sur cinq, ou un jour sur cinq, dédié au refactoring, aux tests, aux upgrades de dépendances. Sans cette discipline, la dette repart.
10. Programmez un audit externe annuel. Une fois par an, un regard externe (le nôtre, ou un autre) sur la santé de votre codebase. C’est l’équivalent d’un bilan de santé : on prévient au lieu de guérir.

Questions fréquentes