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à.
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.
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 sans avoir la boule au ventre à chaque 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.
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, les pages les plus chargées, 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.
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 moche 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.
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 moche veut le nettoyer, c’est viscéral. 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.
L’accompagnement Agenticiel pour reprendre un produit généré par IA
Cette discipline, l’ordre d’une reprise, s’acquiert en l’ayant déjà menée, et c’est là qu’une équipe habituée à ce type de chantier apporte le plus. Agenticiel reprend des produits construits avec Claude Code, bolt ou v0, et la méthode est toujours la même : stabiliser, poser le filet, traiter les goulots, laisser le reste.
Le point de départ est un audit facturé 1 500 euros, déduit du devis si le chantier part. On regarde réellement le code et la production, et on rend un rapport qui dit exactement 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.
Cette reprise est menée par des développeurs offshore francophones, à Madagascar. La sous-traitance de développement permet de confier un produit sensible sans perdre la langue ni le fuseau, à un coût maîtrisé. C’est un point décisif quand on reprend un produit qui a déjà des utilisateurs et qu’on n’a pas le droit de casser.
Notre approche consiste à ne jamais jeter ce qui marche : on protège la production, on pose le filet, on traite ce qui bloque, et on laisse le reste attendre son heure.