Faites d'abord un audit : corrections ciblées si les fondations tiennent, remplacement progressif si seules certaines parties sont fragiles, réécriture en dernier recours. Ce guide s'appuie sur 10 ans de développement web, reprises d'applications comprises, et sur une pratique quotidienne des agents de code.
Publié le 13 octobre 2026 · Jean-Baptiste Thery · EURL jCode
Le code généré par IA échoue souvent aux mêmes endroits. En 2025, un chercheur a analysé 1 645 applications créées avec Lovable : environ 10 % laissaient n'importe qui lire ou modifier leurs tables, faute de règles d'accès au niveau des lignes.
Les autorisations et les règles d'accès à la base de données, les secrets présents dans le code et son historique, les dépendances, la séparation entre développement et production, puis les tests et le processus de déploiement.
Dans le rapport de GitGuardian de mars 2026, les commits publics coécrits avec Claude Code exposaient des secrets dans 3,2 % des cas, plus du double de la moyenne de 1,5 %.
Un rapport écrit qui présente les problèmes, leur risque et les travaux nécessaires, chiffrés par lot. Quand je reprends une application, cet audit au forfait en est la première étape.
Superblocks, sur la CVE-2025-48757 : superblocks.com/blog/lovable-vulnerabilities
GitGuardian, State of Secrets Sprawl 2026, mars 2026 : gitguardian.com/state-of-secrets-sprawl-report-2026
Les corrections suffisent quand les fondations tiennent et que les problèmes sont localisés.
Le modèle de données correspond au métier, les règles d'accès peuvent être ajoutées sans tout reprendre, et la plupart des anomalies se concentrent en quelques endroits.
On ferme d'abord les failles de sécurité, puis on corrige les anomalies par priorité en ajoutant des tests autour de chaque partie modifiée. L'application continue de tourner pendant tout ce temps.
Le remplacement progressif convient quand certaines parties sont saines et d'autres non.
L'application a des utilisateurs et des données à conserver, mais certains modules sont trop fragiles pour être réparés. Une interface stable peut séparer l'ancien et le nouveau.
On remplace un module à la fois derrière cette interface, on migre ses données, puis on retire l'ancien code une fois la nouvelle partie en production.
La réécriture est un dernier recours, pas un point de départ. Elle reste parfois la voie la moins coûteuse.
Le modèle de données ou les fondations de sécurité sont faux partout, personne ne sait expliquer le fonctionnement du code, et chaque correction casse autre chose.
On garde la connaissance du produit, les données et ce dont les utilisateurs dépendent, puis on reconstruit par petites versions, avec des tests et une architecture claire dès la première.
Les agents de code aident aussi à la reprise, avec les mêmes règles que pour toute autre modification.
Ils m'aident à cartographier le code, à écrire les tests manquants et à préparer des corrections sur les points relevés par l'audit. Je relis et teste chaque modification avant livraison.
Présentez ce que vous souhaitez créer ou améliorer, votre budget et l'échéance envisagée.
Décrire votre projet sur Malt
Poser une question sur LinkedIn