Reprendre un produit construit avec Claude Code : par où commencer

Reprendre du code généré par IA ne se fait pas au hasard. C’est une opération délicate, parce que le code en question a une propriété particulière : il a été écrit pour faire marcher une démonstration, pas pour encaisser la durée. Il fonctionne, c’est indéniable, mais il fonctionne d’une façon qu’aucun développeur n’aurait choisie s’il avait eu à penser à la maintenance.

La tentation, face à ce constat, est de tout réécrire proprement. C’est compréhensible, et c’est presque toujours une erreur. Un produit qui tourne et qui a des utilisateurs est un actif rare. Le jeter pour repartir d’une feuille blanche, c’est troquer un problème de dette technique contre un problème de survie : le nouveau code devra d’abord rattraper tout ce que l’ancien faisait déjà. Nous détaillons ce tri dans reprendre un produit : ce qu’on garde et ce qu’on réécrit.

L’ordre d’une reprise compte plus que la reprise elle-même. Commencer par le mauvais bout transforme une reprise en refonte, et une refonte en échec. Voici l’ordre qui tient la route.

D’abord, protéger ce qui tourne

Avant de toucher une seule ligne de code, il faut regarder la production. Ce qui tourne, c’est ce qui rapporte, et c’est la première chose à protéger. Les questions sont simples et décisives : les données sont-elles sauvegardées ? Le paiement est-il fiable ? Y a-t-il des mots de passe en clair, des clés API exposées, des accès qui ne devraient pas exister ?

Cette étape n’a rien de glorieux, et c’est justement pour ça qu’on la saute trop souvent. On veut refactorer, structurer, faire propre. Mais si la production tombe pendant qu’on refactore, toute la propreté du monde ne ramènera pas les clients partis. La première priorité est de sécuriser ce qui existe : sauvegardes, secrets, accès, points de défaillance visibles. Sur les stacks fréquentes des produits générés par IA, cela veut dire vérifier les règles d’accès (Row Level Security) d’une base Supabase, sortir les clés API du code et de l’historique Git, et contrôler les variables d’environnement sur Vercel ou l’hébergeur utilisé.

C’est aussi l’étape qui donne le plus de sérénité pour la suite. Une fois qu’on sait que les données sont à l’abri et que le paiement ne peut pas tomber, on peut travailler sur le reste sereinement, modification après modification.

Poser le filet

La deuxième étape est de poser un filet : des tests. Pas des tests partout, ce qui serait irréaliste sur un code qui n’en a jamais eu. Des tests sur les chemins critiques : ce qui rapporte de l’argent, ce qui traite des données sensibles, ce qui casse le plus souvent. Playwright pour les parcours utilisateur, Vitest ou Jest pour la logique métier, le tout exécuté dans GitHub Actions à chaque modification. Claude Code lui-même aide à écrire ces tests, relus par un développeur.

Sans filet, chaque modification est un pari. On change une chose ici, on ignore ce qui casse là-bas, et on découvre les dégâts en production, au pire moment. Avec un filet, même partiel, la modification redevient un geste ordinaire : on change, les tests tournent, on voit tout de suite ce qui a bougé.

Le filet a un second effet, moins visible mais tout aussi important : il rend le code reprenable. Un développeur qui arrive sur un code sans tests ne sait pas ce qu’il a le droit de toucher sans tout casser. Des tests, même imparfaits, dessinent la carte du territoire. C’est ce qui permet, plus tard, de déléguer, d’embaucher, de passer la main.

Traiter ce qui bloque la croissance

Une fois le produit stable et testé, on peut s’attaquer aux goulots : la requête qui prend quatre secondes, la table sans index, le déploiement manuel qui mange une journée. C’est là que la reprise se transforme en croissance, parce que c’est là que le produit cesse de freiner.

Cette étape se traite par la mesure. On ne devine pas où le temps passe, on le constate. On regarde les requêtes les plus lentes (EXPLAIN sous PostgreSQL), les erreurs remontées par un outil comme Sentry, les opérations les plus coûteuses, et on corrige dans l’ordre. Les gains sont souvent immédiats et sans risque, parce qu’on optimise sans changer le comportement. Les causes les plus fréquentes sont passées en revue dans optimiser une API lente.

C’est une propriété importante à comprendre : une optimisation n’est pas une refonte. Elle ne change pas ce que fait le logiciel, seulement la vitesse à laquelle il le fait. C’est le travail le plus sûr qu’on puisse faire sur un code fragile, et c’est pourquoi il vient avant la restructuration.

Ce qui peut attendre

Le reste, il faut le laisser attendre. Le code peu élégant qui fonctionne, la techno qui n’est pas la plus récente, les fonctions dupliquées, les noms mal choisis : si ça ne bloque pas la croissance, on n’y touche pas, ou on n’y touche que plus tard, quand la valeur de le faire dépassera le risque de le faire. Le moment venu, le refactoring de code généré par IA suit lui aussi un ordre précis.

C’est la règle la plus difficile à respecter, parce qu’elle va contre l’instinct du développeur. Un développeur qui voit du code mal écrit veut le nettoyer, c’est un réflexe. Mais nettoyer du code qui fonctionne, c’est du risque sans bénéfice immédiat, et un produit en production n’a pas les moyens de prendre ce risque gratuitement.

La discipline consiste à traiter la dette technique comme une dépense : on ne la paie que quand elle bloque quelque chose de plus précieux qu’elle. Tout le reste peut attendre, et la plupart du temps, il faut le laisser attendre.

Le passage d’un prototype généré à un produit exploitable est aussi analysé dans du projet vibe coded au produit en production.

En pratique : reprendre un produit généré par IA

Cette discipline, l’ordre d’une reprise, s’acquiert en l’ayant déjà menée. La méthode est la même que le produit sorte de Claude Code, de Cursor, de Lovable, de Bolt ou de v0 : stabiliser, poser le filet, traiter les goulots, laisser le reste.

Concrètement, on commence par regarder réellement le code et la production, et on rend un rapport qui dit ce qu’on garde, ce qu’on renforce et ce que ça coûte. La reprise se fait ensuite dans l’ordre, sans big bang, à côté de votre production, avec un basculement une fois que c’est solide.

Si votre produit a décollé et que vous n’osez plus le modifier, c’est le moment de faire le point. L’Audit de reprise à 750 €, en 3 jours, est fait pour ça.