Reprendre un projet React généré par IA : la méthode

En 2026, une part croissante des MVP sont générés par IA. Des outils comme v0, Lovable, Bolt ou Cursor produisent en quelques jours une application React ou Next.js qui tourne, parfois sans qu'un développeur ait écrit une ligne. Pour une démo ou une levée, c'est suffisant. La difficulté arrive juste après : premiers utilisateurs réels, premières données sensibles, deuxième fonctionnalité à ajouter, premier client qui paie.

Reprendre un tel projet pose un problème particulier. C'est du code que personne dans l'équipe n'a écrit, souvent sans historique Git ni documentation, et qui n'a jamais été pensé pour la production. La génération optimise pour « ça marche », pas pour « ça se maintient » : le code tourne, mais il manque de structure, de tests et de conventions. Réécrire est rarement la bonne réponse, car cela efface les fonctionnalités qui marchent déjà. Le travail utile consiste à fiabiliser l'existant. Cet article décrit cette méthode, étape par étape.

Dans cet article :

• Pourquoi un projet généré par IA n'est pas prêt pour la production
• Comment cartographier et faire tourner un code que vous n'avez pas écrit
• Comment poser les garde-fous automatiques avant d'ajouter du code
• Comment nettoyer les dépendances et casser les monolithes
• Comment fiabiliser sans réécrire, par incréments testés

Pourquoi un projet généré par IA n'est pas prêt pour la production

Un modèle de langage génère le code le plus probable pour répondre à une demande isolée. Il n'a pas de mémoire de l'architecture globale ni de contrainte de cohérence entre deux générations successives. Chaque écran fonctionne séparément, mais l'ensemble n'a pas d'architecture commune.

Les conséquences sont récurrentes : logique dupliquée d'un écran à l'autre, "use client" posé par défaut sous Next.js, dépendances installées pour des besoins triviaux, aucun test. En démo, rien de tout cela ne se voit. En production, chaque ajout de fonctionnalité devient plus lent et plus risqué, faute d'une structure pour absorber le changement.

Le mécanisme par lequel l'IA amplifie la dette, et les quatre signaux qui indiquent qu'il faut agir, sont détaillés dans dette technique et IA : 4 signaux d'alerte. Cet article se concentre sur l'étape suivante : la méthode concrète pour reprendre le code une fois la décision prise.

Les symptômes récurrents d'un projet généré par IA

Un projet généré présente presque toujours les mêmes défauts. Les nommer permet de les traiter dans le bon ordre.

Les étapes qui suivent prennent ces symptômes dans l'ordre où il faut les traiter : d'abord comprendre et faire tourner le code, puis poser les garde-fous, puis nettoyer, enfin refactorer sous protection des tests.

Étape 1 : Cartographier et faire tourner le code

Avant toute modification, deux prérequis : comprendre la structure du projet, et pouvoir l'exécuter de façon reproductible. Sur du code exporté d'un outil de génération, aucun des deux n'est acquis.

• Faire tourner le projet localement. Un export de no-code IA ne démarre pas toujours du premier coup : variables d'environnement non documentées, version de Node non figée, services externes câblés en dur. Reconstituez un .env.example, figez la version de Node (.nvmrc ou engines), et vérifiez que next build passe. Sans build vert au départ, vous ne saurez jamais si c'est vous qui l'avez cassé ensuite.
• Cartographier les flux critiques. Ne cherchez pas à tout comprendre. Suivez de bout en bout les deux ou trois parcours qui portent la valeur (inscription, paiement, création de la ressource principale) : composant, appel réseau, route API, accès aux données. Ce sont ceux que vous protégerez en priorité à l'étape 6.
• Lire l'historique, quand il existe. Si le projet a un historique Git, les fichiers les plus modifiés signalent les points chauds. Un export généré d'un bloc n'a souvent aucun historique : la cartographie manuelle des flux critiques prend alors le relais.

Étape 2 : Poser les garde-fous automatiques

C'est l'étape à faire en premier après le diagnostic, et c'est celle qu'on saute le plus souvent. La raison est simple : l'IA va continuer de générer du code sur ce projet, et vous aussi. Sans filet automatique en place, chaque nouvelle génération rajoute de la dette au rythme où vous la remboursez.

Le socle minimal, dans cet ordre :

• ESLint : détecte les erreurs et les anti-patterns automatiquement. Configuré avec les règles React et les Rules of Hooks, il attrape la majorité des problèmes que l'IA introduit.
• Prettier : impose un formatage uniforme et supprime le style incohérent d'un fichier à l'autre.
• Husky et lint-staged : lancent lint et formatage à chaque commit, pour qu'aucun code non conforme n'entre dans le dépôt.
• Une intégration continue : rejoue lint, tsc --noEmit et le build à chaque push, transformant toute erreur silencieuse en échec visible.

{
	"scripts": {
		"prepare": "husky"
	},
	"lint-staged": {
		"*.{ts,tsx}": ["eslint --fix", "prettier --write"]
	}
}

L'objectif n'est pas de tout corriger d'un coup, mais d'endiguer l'accumulation : à partir de là, le code qui entre respecte les règles. La mise en place détaillée de cette chaîne est décrite dans automatiser la qualité du code avec ESLint, Prettier et Husky.

Étape 3 : Faire le ménage dans les dépendances

L'IA a tendance à installer une librairie dès qu'un besoin apparaît, sans vérifier si le projet en a déjà une équivalente ni si le standard du langage suffit. Un projet généré accumule ainsi des dépendances lourdes, redondantes ou vulnérables.

Trois commandes donnent l'état des lieux :

# Vulnérabilités connues des dépendances installées
npm audit
 
# Dépendances déclarées mais jamais importées
npx depcheck
 
# Fichiers, exports et dépendances inutilisés (graphe complet)
npx knip

En 2026, knip est l'outil de référence : il construit le graphe complet des modules et détecte le code mort aussi bien que les dépendances superflues. Chaque librairie retirée réduit la surface d'attaque, le poids du bundle et la charge de maintenance.

Étape 4 : Casser les monolithes et la duplication

Un composant de 500 lignes qui gère l'affichage, l'appel réseau, la validation et l'état local est difficile à faire évoluer et impossible à tester. C'est le format que produit une génération écran par écran. Le corriger consiste à séparer les responsabilités : extraire la logique dans des hooks, isoler les appels de données, découper l'affichage en composants plus petits.

La duplication est le second problème récurrent. Faute de mémoire entre deux générations, la même logique est recopiée à chaque écran. Un correctif de sécurité doit alors être appliqué à dix endroits, et il en reste toujours un d'oublié. jscpd détecte le code copié-collé.

# Détecte le code dupliqué dans le projet
npx jscpd src/

On factorise en priorité la logique dupliquée sur les parcours critiques (paiement, authentification), là où un bug coûte le plus cher. Le principe de responsabilité unique et les anti-patterns à corriger sont détaillés dans les anti-patterns React en 2026.

Étape 5 : Retirer les "use client" inutiles

Sous Next.js, c'est le symptôme le plus systématique du code généré. L'IA place "use client" en haut de presque chaque fichier, parce que c'est le choix qui fonctionne sans risque. Le coût est direct : un composant client est du JavaScript envoyé au navigateur, même s'il n'a aucune interactivité. Un projet entièrement en "use client" alourdit le bundle et dégrade l'INP.

Commencez par mesurer l'ampleur du problème :

# Compte les fichiers marqués "use client"
grep -rl "use client" src/ | wc -l

La correction consiste à garder les composants côté serveur par défaut et à isoler l'interactivité dans de petits îlots clients (un bouton, un champ de recherche), plutôt que de marquer tout un arbre. C'est souvent le plus gros levier de performance sur un projet généré. La méthode de diagnostic complète est dans pourquoi votre application React est lente.

Étape 6 : Poser un filet de tests avant d'évoluer

Un projet généré par IA arrive sans tests. Avant de refactorer ou d'ajouter une fonctionnalité, il faut un filet : un test de caractérisation capture le comportement actuel du code, sans le juger, pour détecter toute régression quand vous le modifierez ensuite.

La démarche est contre-intuitive : on fige le comportement existant même s'il paraît imparfait. L'objectif à ce stade n'est pas de corriger, mais de sécuriser les modifications à venir.

import { expect, it } from "vitest"
import { computeOrderTotal } from "./pricing"
 
// Test de caractérisation : on fige le comportement ACTUEL, sans le juger
it("calcule le total d'une commande avec remise et TVA", () => {
	const total = computeOrderTotal({
		items: [{ price: 100, quantity: 2 }],
		discountRate: 0.1,
		vatRate: 0.2,
	})
 
	expect(total).toBe(216)
})

On priorise ces tests sur les parcours critiques identifiés à l'étape 1, en testant les entrées et sorties observables plutôt que les détails internes. Cette approche est celle décrite dans tester les comportements, pas l'UI. Une fois le comportement critique sous filet, chaque refactoring devient vérifiable.

C'est aussi le moment de relire ce que l'IA a produit avec un regard critique. Les patterns à refuser en revue de code généré sont recensés dans 7 patterns que je refuse en review de code IA.

Étape 7 : Centraliser l'UI avec un design system léger

Dernier symptôme : chaque écran ayant été généré indépendamment, les boutons, les champs et les espacements diffèrent d'une page à l'autre. Au-delà de l'incohérence visuelle, cela signifie qu'un changement de style doit être répété partout.

La correction n'est pas de bâtir un design system complet d'emblée, ce qui serait de la sur-ingénierie sur un jeune produit. Elle consiste à extraire progressivement les éléments récurrents : d'abord les tokens (couleurs, espacements, typographie), puis les composants les plus réutilisés (bouton, champ, carte). On centralise au fil des besoins réels, pas par anticipation. Les critères pour démarrer sans sur-investir sont dans Design System React en monorepo.

Les erreurs à éviter

• Réécrire au lieu de fiabiliser. Le code généré marche déjà en partie. Repartir de zéro efface les fonctionnalités et les règles métier qui fonctionnent.
• Ajouter des fonctionnalités avant les garde-fous. Sans linter, tests et CI, chaque génération suivante ajoute de la dette au rythme où vous la remboursez.
• Faire confiance au code sans le relire. L'IA génère du code plausible, pas du code sûr. La revue reste indispensable, en particulier sur la sécurité et les accès aux données.
• Optimiser au jugé. « Ce code est mauvais » ne priorise rien. Les outils (knip, jscpd, npm audit, Lighthouse) donnent des cibles précises.
• Construire un design system complet trop tôt. Sur un jeune produit, extraire les tokens et quelques composants suffit. Le reste est prématuré.
• Laisser "use client" partout. C'est du JavaScript envoyé au navigateur pour rien, et souvent le premier frein aux performances.

FAQ

Faut-il réécrire un projet généré par IA ou le reprendre ?

Le reprendre, dans la grande majorité des cas. Le code généré est souvent fonctionnel : il lui manque la fiabilité (tests, structure, conventions), pas la logique métier. Une réécriture efface les fonctionnalités qui marchent et les règles apprises en production. La fiabilisation progressive coûte moins cher et présente moins de risques. La réécriture ne se justifie que si l'architecture empêche physiquement l'évolution demandée.

Comment savoir si mon MVP généré par IA est prêt pour la production ?

Mesurez quatre points : sécurité des dépendances, présence de tests sur les parcours critiques, validation des accès aux données, et performances. Un MVP généré passe la démo mais échoue souvent sur ces quatre axes. Un audit de code objective l'écart entre l'état actuel et un niveau production, et le chiffre au lieu de le supposer.

Un projet exporté de Lovable ou Bolt peut-il passer en production ?

Oui, à condition de le fiabiliser d'abord. Ces outils produisent une base fonctionnelle, mais le code exporté partage les mêmes défauts : peu de tests, "use client" généralisé, dépendances non maîtrisées, parfois pas d'historique Git. La méthode reste la même que pour tout code repris : cartographier, poser les garde-fous, nettoyer, tester, puis faire évoluer.

Le code généré par IA est-il moins performant ?

Souvent, oui, à cause de deux réflexes de génération : "use client" posé partout et des dépendances lourdes ajoutées sans nécessité. Ce sont des choix par défaut orientés « ça marche », pas des défauts de l'IA en soi. Retirer les "use client" inutiles et nettoyer les dépendances corrige l'essentiel, sans réécriture.

Par où commencer pour reprendre un projet généré par IA ?

Par le faire tourner en local et cartographier ses parcours critiques. Un export d'outil IA ne démarre pas toujours du premier coup, et n'a souvent aucune documentation. Une fois le projet exécutable et le build vert, on pose les garde-fous automatiques, puis on nettoie et on refactore sous protection des tests.

Conclusion

Un MVP généré par IA n'est pas un mauvais point de départ : c'est un prototype qui fonctionne, obtenu vite. Le faire passer en production relève de la méthode : structurer, tester et sécuriser l'existant plutôt que le jeter. Le code a besoin de fiabilité, pas d'être réécrit.

Points clés

1. Ne réécrivez pas : le code généré marche déjà en partie, la réécriture efface ce travail.
2. Cartographiez et faites tourner le code avant d'y toucher, car vous ne l'avez pas écrit.
3. Posez les garde-fous automatiques (ESLint, Prettier, Husky, CI) avant d'ajouter la moindre ligne.
4. Nettoyez les dépendances, cassez les monolithes et la duplication, retirez les "use client" inutiles.
5. Posez un filet de tests de caractérisation, puis fiabilisez par incréments avant de faire évoluer.