Le scénario est devenu courant. Une idée, un week-end, un outil de génération de code par IA, et au bout de quelques jours une application qui fonctionne. Les premiers utilisateurs arrivent, l’enthousiasme aussi. Puis viennent les premiers signes : une page qui met dix secondes à charger, des données qui disparaissent, une modification anodine qui en casse trois autres, et cette impression grandissante que plus personne, pas même l’IA, ne comprend vraiment ce qui se passe dans le code. Si vous en êtes là, rassurez-vous : ce n’est ni rare, ni forcément grave. Mais ça se traite avec méthode.
Pourquoi ça marche en démo et pas en production
Les outils de génération de code sont remarquablement bons pour produire quelque chose qui fonctionne dans le cas prévu : un utilisateur, des données propres, un chemin tracé d’avance. Une démo, en somme. La production, c’est tout le reste : cent utilisateurs en même temps, une connexion qui coupe en plein paiement, un champ laissé vide, quelqu’un qui tente d’accéder aux données d’un autre. Ces cas ne se voient pas dans une démo, et un code généré sans les avoir en tête ne les traite pas. C’est précisément la distinction que nous défendons depuis le début : un produit, jamais une démo.
Les symptômes qui ne trompent pas
Certains signes reviennent sur presque toutes les applications que l’on nous confie dans cet état :
- Des correctifs qui en cassent d’autres : le code s’est construit par couches successives, sans architecture d’ensemble
- Des secrets dans le code : clés d’API ou mots de passe de base de données, visibles par quiconque inspecte l’application
- Des contrôles d’accès côté écran seulement : l’interface masque un bouton, mais le serveur accepte la requête de n’importe qui
- Des lenteurs qui grandissent avec les données : des requêtes qui chargent tout au lieu de chercher ce qu’il faut
- Aucun test, aucun historique lisible : impossible de savoir si une modification casse quelque chose avant que les utilisateurs le découvrent
Le deuxième et le troisième point méritent une attention immédiate. Une application lente coûte des utilisateurs ; une application qui laisse fuiter des données personnelles coûte bien davantage, en confiance comme au regard du RGPD.
Diagnostiquer avant de réécrire
Face à un code qu’on ne comprend plus, la tentation est de tout jeter. C’est rarement la bonne première décision. Une reprise commence par un audit : lire le code, cartographier ce qui existe, mesurer ce qui est réellement utilisé, repérer les failles de sécurité, et surtout comprendre ce que l’application fait de bien. Car un prototype généré par IA a souvent une vraie valeur : il a validé un besoin, fixé un parcours, parfois trouvé ses premiers clients. Cette connaissance-là ne se jette pas.
L’audit débouche sur une carte claire : ce qui peut rester tel quel, ce qui doit être consolidé, ce qui doit être réécrit. Dans la majorité des cas, le verdict n’est ni « tout est à jeter » ni « tout va bien », mais un chantier ciblé sur quelques zones critiques.
Consolider ou repartir de zéro
Repartir d’une page blanche se justifie dans des situations précises : quand la structure des données est fondamentalement inadaptée, quand les failles sont si diffuses qu’on ne peut plus garantir la sécurité, ou quand le produit a tellement changé de direction que le code ne correspond plus à rien. Hors de ces cas, la consolidation progressive l’emporte presque toujours : sécuriser d’abord, poser des tests sur les parcours qui comptent, puis reprendre les zones fragiles une à une, sans interrompre le service. Les utilisateurs ne voient pas le chantier, ils voient seulement l’application devenir fiable.
Le code généré par IA n’est pas le problème. Le problème, c’est un code que personne n’a relu, testé ni compris avant de le mettre entre les mains de vrais utilisateurs.
L’IA reste un bon outil, à la bonne place
Ce constat n’a rien d’un réquisitoire contre l’IA. Nous l’utilisons nous-mêmes au quotidien, pour écrire du code, le relire et explorer des pistes. La différence tient à la place qu’on lui donne : un accélérateur entre les mains de quelqu’un qui sait juger ce qu’elle produit, pas un remplaçant de ce jugement. C’est le fil de notre approche de l’IA : l’outil au service du produit, jamais l’inverse. Et pour la suite, la leçon vaut d’être retenue : un MVP au périmètre bien cadré, construit pour durer, coûte moins cher qu’un prototype rapide qu’il faut reprendre six mois plus tard.
Si votre application a été construite vite et commence à céder, ce n’est pas le moment de paniquer, ni de tout recommencer à l’aveugle. C’est le moment de faire un état des lieux honnête. C’est un travail que nous menons régulièrement en ingénierie produit : reprendre un existant, le sécuriser, le rendre maintenable, sans perdre ce qu’il a déjà prouvé. Parlez-nous de votre application : nous commencerons par vous dire ce qui, à notre avis, mérite d’être gardé.