Comment savoir si votre produit IA a dépassé son code

Il y a un moment précis dans la vie d’un produit où le code qui l’a fait décoller devient la chose qui l’empêche de grandir. Ce moment est rarement spectaculaire. Il se manifeste par une lenteur nouvelle, une erreur qui revient, un déploiement qu’on repousse. Le fondateur, lui, est souvent le dernier à le voir, parce qu’il est trop occupé à maintenir la machine en marche pour regarder si elle tient encore la route.

Ce phénomène touche en particulier les produits construits vite, souvent avec des outils comme Lovable, Bolt, v0, Cursor ou Claude Code. Ces outils permettent à un solopreneur ou à une toute petite équipe de passer de l’idée au produit en quelques semaines. C’est une force considérable. Mais le code produit à cette vitesse a une propriété particulière : il est optimisé pour la démonstration, pas pour la durée. Il fait la chose attendue dans le cas heureux, et n’a pas été pensé pour les cent cas qui n’arrivent qu’à l’échelle.

Cette façon de construire a fait ses preuves pour lancer vite. Il s’agit ici de reconnaître le moment où la première version a fait son travail et où il faut passer à un code qui encaisse, une base qui répond, un déploiement serein.

Le crash au pic, le signal le plus visible

Le premier signe est rarement subtil : le service tombe au moment où il compte le plus. Un lancement, un post LinkedIn qui prend, une campagne qui ramène du trafic, et le serveur tombe. On redémarre à la main, souvent la nuit. Sans outil de suivi des erreurs comme Sentry, on découvre la panne par les messages des clients.

Il faut comprendre ce que ce crash dit réellement. Ce n’est presque jamais un problème de « pas assez de RAM », même si ajouter de la RAM le repousse un temps. C’est un problème d’architecture : des connexions qui s’empilent faute de file d’attente, des opérations synchrones qui devraient être asynchrones, un cache absent là où il aurait tout changé. Tant qu’on traite le symptôme plutôt que la cause, le mur se déplace, il ne disparaît pas.

Un scénario typique aide à le voir. Prenons un SaaS de facturation construit par une seule personne, dont le serveur tombe chaque fois qu’une mention passe sur LinkedIn. Le correctif immédiat consiste à redémarrer l’instance et à augmenter sa taille. Ça tient quelques semaines, puis le pic suivant arrive et ça retombe. Le vrai problème est ailleurs : chaque requête de paiement déclenche une série d’opérations lourdes en série, sans file d’attente, et la moindre montée de trafic sature le tout. Une fois ces opérations mises en file (une file Redis, par exemple) et rendues asynchrones, le même serveur encaisse nettement plus de trafic.

Quand déployer devient un pari

Le deuxième signe se joue dans la tête du fondateur avant de se jouer dans le code : il a peur de déployer. Chaque nouvelle fonctionnalité risque de casser autre chose, quelque part, de façon imprévisible. Alors il accumule les changements, repousse les mises en ligne, et finit par tout lâcher d’un coup, ce qui casse encore plus.

Cette peur a une cause très précise : l’absence de filet. Pas de tests, pas d’intégration continue, pas de retour automatique. Sans cela, chaque déploiement est un pari à l’aveugle. Et un produit dont le fondateur n’ose plus déployer arrête d’itérer.

La solution n’est pas de tout tester d’un coup, ce qui serait irréaliste sur un code qui n’a jamais été écrit pour ça. Elle est de commencer par les chemins critiques : ce qui rapporte de l’argent, ce qui touche aux données des utilisateurs, ce qui casse le plus souvent. On pose des tests sur ces chemins-là d’abord (des parcours Playwright de bout en bout suffisent souvent pour commencer), on branche un déploiement automatisé dessus avec GitHub Actions ou les environnements de prévisualisation de Vercel, et le filet existe (par où commencer la CI/CD d’un projet IA). À partir de ce moment, déployer redevient un geste ordinaire.

La base de données qui ralentit tout

Le troisième signe est plus sournois parce qu’il ne se voit pas directement : la base de données devient le goulot. Les pages mettent trois secondes à répondre, les requêtes s’allongent, et la facture cloud grimpe alors que le trafic, lui, reste modeste.

C’est le symptôme d’une base qui n’a jamais été pensée pour grandir, fréquent sur les projets Supabase générés par Lovable ou Bolt : des requêtes sans index qui balaient des millions de lignes, des jointures trop larges, l’absence de pagination. Au début, tout tient en mémoire et rien ne se voit. Puis les données s’accumulent, et chaque requête devient un petit drame.

Le réflexe dangereux est de jeter du matériel sur le problème : une instance plus grosse, un plan plus cher. Ça masque sans corriger. La bonne approche consiste à regarder où le temps passe réellement, à poser les index qui manquent, à réécrire les requêtes les plus coûteuses. Sur PostgreSQL, pg_stat_statements désigne les requêtes qui coûtent le plus. Les gains sont souvent immédiats, sans changer la moindre ligne de fonctionnalité. On détaille la démarche dans notre plan d’action pour scaler une base de données.

Le code que personne ne veut reprendre

Le quatrième signe est peut-être le plus coûteux sur la durée : le fondateur se retrouve prisonnier de son propre produit. Il veut embaucher, déléguer, passer la main sur une partie du code, et il se heurte toujours à la même réponse, parfois dite poliment, parfois pas : « c’est du code généré par IA, personne ne veut y toucher ».

Le problème n’est pas que le code ait été généré par une machine. Le problème est qu’il est illisible : pas de structure, pas de documentation, des choix faits à la volée sans que personne ne puisse les expliquer. Un développeur qui arrive sur ce code ne peut pas le comprendre, donc il ne peut pas le modifier sans risque, donc il refuse.

C’est le signe qu’il est temps de reprendre le code non pas pour le réécrire, mais pour le rendre reprenable. Documenter les choix, structurer les modules, nommer les choses, poser les premiers tests. Ce travail ne change rien pour l’utilisateur final, et c’est pourtant lui qui rend le produit vendable et transmissible.

L’ordre d’une reprise : stabiliser d’abord

Face à ces quatre signes, la tentation est de vouloir tout refaire, proprement, depuis zéro. C’est presque toujours une erreur. Un produit qui a des utilisateurs, c’est le plus dur à obtenir, et c’est déjà fait. Repartir de zéro, c’est jeter cet acquis pour courir le risque de ne jamais le retrouver.

L’ordre qui fonctionne est l’inverse de l’intuition. D’abord stabiliser : arrêter les pannes, sécuriser les données, protéger ce qui rapporte. Ensuite industrialiser : tests, intégration continue, index, monitoring. Puis scaler : architecture, montée en charge, maîtrise des coûts. Enfin transmettre : documenter, former, rendre le code reprenable. Chaque étape s’appuie sur la précédente, et aucune ne suppose de tout casser pour recommencer.

Ce qui marche, on le garde. On ne réécrit que ce qui bloque, on ne touche pas à ce qui tient (on développe ce tri dans reprendre un produit : ce qu’on garde et ce qu’on réécrit). C’est plus rapide qu’une refonte, et cela ne met pas en danger un produit déjà en production.

Quand le produit trouve son marché et que le code ne suit plus, passer du prototype vibe-codé au produit en production donne des repères.

En pratique : remettre votre produit sur les rails

Si vous reconnaissez deux ou trois de ces signes, le bon premier pas n’est pas une refonte, c’est un diagnostic. C’est le rôle de notre audit de reprise à 750 €, en 3 jours : on regarde réellement le code et la production, on identifie les goulots, et on vous rend un rapport clair sur ce qu’on garde, ce qu’on renforce et ce que ça coûte. Le travail suit ensuite l’ordre décrit plus haut, de la stabilisation à la transmission, parce qu’un produit repris doit pouvoir vivre sans nous.

Une fois la base assainie, beaucoup de fondateurs veulent aller plus loin sur la partie IA elle-même : un assistant intégré, un agent qui traite les demandes, des fonctionnalités qui s’appuient sur les données du produit. C’est l’objet de l’intégration de l’IA dans un SaaS, chiffrée au cadrage et menée sur un code qui tient enfin la charge.