Le vibe coding permet aujourd’hui de lancer des applications React extrêmement rapidement.
Avec des outils comme Lovable, Bolt, Cursor ou Claude Code, on peut aisément générer une interface fonctionnelle, brancher une base de données et mettre une application en ligne en quelques jours.
Le problème, c’est qu’entre un prototype qui fonctionne et une application maintenable, il y a souvent un écart important.
Chez theTribe, nous commençons à voir arriver des projets React vibe-codés, qui doivent ensuite être repris, stabilisés et industrialisés pour continuer à évoluer correctement.
Et dans beaucoup de cas, les mêmes problèmes reviennent.
Comment reconnaître un projet React vibe-codé ?
Quelques signaux reviennent souvent :
- une ancienne version de React ou des dépendances déjà obsolètes ;
- un déploiement entièrement géré via Vercel, sans véritable pipeline CI/CD ;
- peu d’historique Git, ou des commits générés quasi exclusivement par des agents IA ;
- une architecture inexistante ou très approximative ;
- de la logique métier directement dans les composants React ;
- une gestion du state dispersée ;
- des composants énormes qui mélangent affichage, logique et appels API ;
- une authentification bricolée ou difficile à suivre.
Évidemment, tous les projets générés avec des outils IA ne ressemblent pas à ça.
Mais lorsqu’une application a surtout été construite par itérations successives de prompts, sans réelle réflexion d’architecture, ces symptômes apparaissent très vite.
1. Commencer par comprendre ce qui fonctionne réellement
Première étape : vérifier que l’application fonctionne réellement en dehors de l’environnement dans lequel elle a été générée.
Beaucoup de projets créés avec Lovable ou d’autres outils similaires reposent fortement sur leur écosystème : configuration implicite, variables d’environnement, intégrations automatiques ou scripts générés.
À ce stade, l’objectif n’est pas encore de “nettoyer”, mais déjà d’obtenir une vision fiable de l’existant.
Avant toute refonte, il faut donc comprendre précisément ce qui tourne réellement, ce qui est utilisé et ce qui peut être supprimé.
2. Mettre en place une vraie validation de code
Dans beaucoup de projets générés rapidement, les garde-fous sont quasiment inexistants : pas de lint strict, donc très peu de contrôles automatiques sur la qualité et la cohérence du code, parfois aucun test (unitaire, fonctionnel ou E2E).
Or, c’est généralement une des premières choses à remettre en place.
Cela passe souvent par :
- une configuration TypeScript plus stricte ;
- la remise en place d’ESLint pour contrôler la qualité et la cohérence du code ;
- Prettier pour uniformiser le formatage ;
- des validations automatiques dans la CI ;
- et quelques premiers tests critiques.
L’objectif est aussi de corriger les erreurs et warnings déjà présents dans la console avant de continuer à faire évoluer le projet.
3. Stabiliser les dépendances avant de tout upgrader
La tentation est souvent forte de tout mettre à jour immédiatement, mais dans la pratique, c’est rarement une bonne idée.
Sur un projet déjà instable, mieux vaut commencer par comprendre les dépendances réellement utilisées, supprimer les packages inutiles et privilégier d’abord les mises à jour patch et mineures.
Les migrations majeures viendront ensuite, une fois la base assainie.
4. Reprendre la gestion du state
La gestion du state, c’est-à-dire la manière dont les données et les états de l’application sont stockés, partagés et mis à jour, est souvent l’un des premiers points qui dérivent sur ce type de projets.
On retrouve rapidement du state local partout, plusieurs stores différents (c’est-à-dire plusieurs endroits distincts où l’état global de l’application est stocké), des données dupliquées et des effets de bord difficiles à suivre.
Avant que le projet grossisse davantage, il est important de remettre en place une stratégie claire : où vivent les données, quels états sont globaux et comment circule l’information dans l’application. Sinon, le comportement de l’application devient vite difficile à suivre.
6. Découper les composants et isoler la logique métier
Autre problème fréquent : les composants React deviennent rapidement énormes.
Affichage, logique métier, appels API, gestion du state et validation se retrouvent mélangés dans les mêmes fichiers : et c’est généralement là que la maintenabilité s’effondre.
La reprise passe souvent par :
- un découpage en composants plus petits ;
- une séparation claire entre présentation et logique métier ;
- une couche de services pour les appels externes ;
- une gestion de données plus propre ;
- et une bibliothèque de composants cohérente.
Le but n’est pas de transformer le projet en usine à gaz, mais juste de remettre des frontières claires dans le code. Sinon, à terme, chaque nouvelle feature devient plus coûteuse à intégrer que la précédente.
7. Nettoyer la gestion de l’authentification
Sur les projets générés rapidement, l’authentification est souvent un point sensible.
Certaines intégrations sont mises en place de manière très implicite : tokens stockés côté client, règles d’accès peu lisibles ou logique d’authentification mélangée aux composants.
Or, avec la multiplication des projets vibe-codés mis en ligne très rapidement, les problèmes de sécurité deviennent de plus en plus fréquents : gestion approximative des permissions, secrets exposés, règles d’accès mal configurées ou dépendances vulnérables.
Ces sujets deviennent encore plus sensibles dès que l’application manipule des données personnelles ou des données métier critiques, avec des enjeux évidents de sécurité et de conformité RGPD.
Avant toute montée en charge, il faut donc reprendre ces sujets sérieusement. Ce n’est pas parce qu’un projet fonctionne qu’il est correctement sécurisé.
7. Monter les dépendances majeures au bon moment
Une fois le projet stabilisé, il devient possible d’envisager des montées de version majeures sur les bibliothèques importantes.
Faire l’inverse est souvent une erreur : en effet, migrer React, Next.js ou une librairie de state alors que l’architecture reste fragile complexifie énormément la reprise et augmente le risque de régressions.
Mieux vaut d’abord remettre de la structure, des validations et des conventions claires avant d’attaquer les migrations lourdes.
Pour aller plus loin
Une fois la base technique stabilisée, plusieurs pratiques permettent d’améliorer fortement la maintenabilité du projet et l’efficacité des futurs développements.
Structurer la collaboration design / développement
Beaucoup de projets vibe-codés démarrent sans véritable workflow design.
Remettre en place un design system cohérent via Figma ou Claude Design permet de retrouver de la stabilité et d’éviter les dérives UI au fil des itérations.
Les connexions entre les outils de design et les environnements de développement deviennent aussi particulièrement utiles sur ce type de projet, notamment via MCP.
Documenter l’architecture du projet
Sur beaucoup de projets générés avec l’IA, la connaissance de l’architecture reste implicite.
Le contexte existe surtout dans les prompts, les conversations ou l’historique des itérations.
Mettre en place un document ARCHITECTURE.md ou CLAUDE.md permet de formaliser les choix techniques, les conventions et les règles importantes du projet.
Cela facilite aussi énormément les futures reprises et évolutions du projet.
Reprendre un projet vibe-codé, ce n’est pas tout refaire
Le réflexe classique consiste souvent à vouloir repartir de zéro, mais dans la pratique, avec l’amélioration des outils de génération de code comme Claude Code, c’est de moins en moins nécessaire.
La plupart de ces projets contiennent déjà beaucoup de valeur : des écrans fonctionnels, des workflows validés et une logique métier existante. Le vrai challenge est surtout de transformer un prototype accéléré en base technique maintenable.
Cela passe donc rarement par un grand “rewrite”. Le plus souvent, il s’agit surtout de remettre progressivement de la structure, des validations automatiques et des conventions de développement solides.
En savoir plus :
- Notre expertise développement IA
- Notre expertise refonte applicative
