Estimer l'ampleur de la remise en état d'une base de code générée par IA : signaux d'alerte

Ce que vous estimez, et pourquoi ça compte

L'ampleur de la remise en état est une estimation de ce qu'il faut pour rendre une base de code sûre, stable et prête pour de vrais utilisateurs. Elle couvre l'effort (heures ou jours), le risque (ce qui peut casser pendant que vous réparez) et les inconnues (zones qu'on ne peut pas croire avant d'inspecter ou tester).

La première vraie décision n'est généralement pas « quel bug corriger en premier ? » mais « réparons‑nous ce qui existe, ou reconstruisons‑nous les mêmes fonctionnalités sur une base plus propre ? » Choisir la mauvaise voie peut vous faire passer une semaine à colmater des problèmes qui réapparaissent dès que vous ajoutez une fonctionnalité de plus.

Les bases de code générées par IA ont souvent l'air impeccables en démo, mais elles peuvent être inégales. Vous pouvez voir une UI polie posée sur une logique fragile. Un fichier suit de bons patterns, le suivant contient des secrets en dur, saute les vérifications d'entrée ou mélange requêtes DB et code UI. Ce n'est pas forcément « mauvais », mais cela peut cacher des endroits dangereux.

Cette rubrique est conçue pour la vitesse. Vous essayez de répondre à deux questions précoces :

• Peut‑on rendre ceci prêt pour la production avec des réparations ciblées, ou est‑il plus rapide et sûr de recommencer ?
• Où le travail est‑il susceptible d'exploser (auth, données, sécurité, architecture) ?

Considérez le résultat comme une fourchette, pas un chiffre unique. Une estimation rapide et honnête aide à fixer les attentes et à décider si vous avez besoin d'un second avis avant de vous engager dans des semaines d'incertitude.

Entrées et approche rapide et limitée dans le temps

Pour estimer l'ampleur, il vous faut juste assez d'information pour répondre à une question : peut‑on rendre ce code sûr et fiable sans tout réécrire ?

Rassembler le minimum d'informations (avant d'ouvrir le code)

Demandez ces éléments en amont. Si des pièces clés manquent, votre estimation restera surtout de la supposition.

• Accès au repo (source complète, pas une archive de build)
• Configuration de l'environnement (variables d'env, méthode de gestion des secrets, et un modèle .env exemple)
• Détails de la base de données (schéma, migrations et un petit échantillon de données si disponible)
• Cible de déploiement (où ça doit tourner et contraintes éventuelles comme régions ou VPC)
• Une courte liste de flux « doit fonctionner » (inscription, paiement, admin, etc.)

Limitez le temps pour la première passe. 60 à 120 minutes suffisent généralement pour repérer les risques majeurs sans basculer en audit complet.

Un flux simple marche bien : passez ~15 minutes pour le faire démarrer, 30 minutes pour suivre le parcours utilisateur principal de bout en bout, puis 15 à 45 minutes pour scanner les gros signaux d'alerte (auth, modèle de données, sécurité, architecture).

Ce à quoi « fait » ressemble : une page d'une seule vue : problèmes principaux, fourchette d'effort approximative et un appel clair (refactor vs rebuild).

Les blocages stricts comptent. Si vous n'avez pas le code source, ne pouvez pas l'exécuter localement ou dans un environnement propre, ou si personne ne peut expliquer à quoi ressemblent les données de production, marquez l'estimation comme bloquée.

Triage de première passe : est‑ce que ça tourne et fait‑il le travail principal ?

Avant de noter quoi que ce soit, tentez d'utiliser l'app comme un vrai utilisateur. Vous n'essayez pas de déboguer chaque problème. Vous vérifiez si la base de code est globalement vivante ou en panne avant d'atteindre le flux principal.

Commencez par un run de bout en bout : pouvez‑vous démarrer le serveur, ouvrir l'app, vous inscrire, vous connecter et accomplir l'action centrale (créer la ressource, réserver, envoyer) ? Si une étape est bloquée par un crash, un écran blanc ou une route cassée, l'ampleur augmente généralement parce que vous réparez des fondations, pas du polish.

Jetez aussi un coup d'œil rapide à la configuration. Les variables d'environnement sont‑elles documentées ? Voyez‑vous des clés API, tokens ou mots de passe en dur dans des fichiers ou dans le code client ? Même un secret exposé peut transformer un « quick fix » en un nettoyage de sécurité plus large.

Notez aussi le signal des tests. Pas de tests est courant dans les prototypes, mais cela augmente le risque dans votre estimation. Même quelques smoke tests réduisent l'incertitude. Des tests significatifs autour de l'auth et des flux centraux peuvent réduire le temps de remédiation.

Capturez les inconnues immédiatement, car elles pilotent souvent l'ampleur plus que les bugs visibles :

• Quelle étape a échoué et quelle erreur avez‑vous vue ?
• Quelles parties du flux principal sont floues ou incohérentes ?
• Quelles données sont créées ou modifiées, et où sont‑elles stockées ?
• Qu'est‑ce qui doit fonctionner en production (paiements, emails, uploads) ?

Signaux d'alerte sur l'auth qui font vite monter l'ampleur

Les problèmes d'auth ne sont rarement « juste un bug ». Ils touchent le routage, les données, le stockage de session et chaque fonctionnalité protégée. Dans les projets générés par IA, l'auth est aussi l'endroit où le copier‑coller et les vérifications serveur manquantes apparaissent.

Un signal rapide est de savoir si les bases fonctionnent de bout en bout. Si les emails de réinitialisation n'arrivent jamais, les sessions expirent au hasard, ou l'UI affiche « connecté » alors que l'API rejette les requêtes, vous regardez généralement plus qu'une simple correction. Ces symptômes signifient souvent que l'état d'auth est fragmenté entre frontend, backend, base de données et cookies sans source de vérité unique.

Signaux à surveiller

Ces schémas tendent à faire monter l'ampleur rapidement :

• Flux cassés (liens de réinitialisation qui échouent, déconnexion qui ne déconnecte pas vraiment, sessions qui meurent au rafraîchissement)
• Vérifications de rôle manquantes ou incohérentes (un utilisateur normal peut charger des écrans admin ou appeler des endpoints admin)
• OAuth partiel (routes de callback en erreur, tokens stockés « quelque part », flux de refresh peu clair)
• Autorisation appliquée seulement dans l'UI (les pages sont cachées, mais le serveur renvoie toujours les données)

Une petite grille de sévérité aide à rester honnête dans l'estimation :

• Faible : un flux casse, mais l'approche est cohérente (un bug)
• Moyen : l'approche est incohérente (session et JWT mélangés, logique dupliquée) et nécessite une refonte
• Élevé : rôles et autorisations côté serveur non sûrs ou flous (candidat à la reconstruction)

Exemple : si un prototype « protège » les fonctions admin en cachant les boutons, mais qu'on peut toujours appeler l'API admin depuis le navigateur, considérez‑le comme haute sévérité. Le corriger implique de définir les permissions, les appliquer côté serveur et retester chaque fonctionnalité touchant les données utilisateur.

Signaux sur le modèle de données : où la complexité cachée se loge

Si une app générée par IA « fonctionne en grande partie » mais casse de manière étrange, le modèle de données est souvent la raison. Des problèmes de schéma apparemment petits créent une grosse ampleur parce que chaque fonctionnalité dépend des mêmes tables, relations et règles.

Un signal rapide est le mismatch de schéma : le code lit ou écrit des champs qui n'existent pas en DB, ou la base contient des colonnes qu'aucun code n'utilise. Vous verrez des erreurs de colonne manquante, des nulls là où l'UI suppose une valeur, ou des blobs JSON « temporaires » qui sont devenus permanents.

Un autre amplificateur d'ampleur est l'absence de source de vérité pour les IDs, relations et propriété. Une commande peut référencer un user par email à un endroit, par userId ailleurs et par un champ « owner » quelque part. À ce stade, les corrections ne sont plus locales. Il faut décider ce que l'app signifie, puis mettre à jour le code, les requêtes et les données existantes.

Duplication et noms incohérents à travers les tables (users vs user vs app_users) signifient souvent que le modèle a grandi par copier‑coller. Cela mène à des rapports qui ne correspondent jamais, à des bugs qui reviennent après « correction » et à une logique qui bifurque en plusieurs versions.

L'absence d'histoire de migrations est un autre signal d'alerte. S'il n'y a pas de moyen reproductible de modifier le schéma en sécurité, chaque changement devient une édition manuelle risquée et les déploiements peuvent casser la production.

Signes de haut risque qui poussent souvent les estimations : validations sautées, suppressions sans contraintes, frontières multi‑locataires manquantes, relations appliquées seulement côté frontend, et « une table pour tout » remplie de champs optionnels. Si vous en voyez plusieurs à la fois, il peut être moins coûteux de reconstruire la couche données proprement et de reconnecter l'app que de chasser les bugs table par table.

Signaux de sécurité qui vous orientent vers une reconstruction

Les problèmes de sécurité ne sont pas tous équivalents. Certains sont des corrections rapides « verrouillez la porte ». D'autres signalent que le projet entier a été construit sans limites de base. Dans les estimations, la seconde catégorie rend souvent la reconstruction plus sûre (et parfois plus rapide) que le patching.

Commencez par les secrets. Si des clés API ou mots de passe DB apparaissent dans le repo, les logs ou un bundle front‑end, considérez‑les comme déjà compromis. La rotation des clés n'est que la première étape. Si le code a encore besoin de secrets dans le navigateur pour fonctionner, c'est un problème de conception, pas seulement de nettoyage.

Le risque d'injection est un autre multiplicateur d'ampleur. Si vous voyez du SQL brut collé dans l'app, des requêtes construites par concaténation de chaînes, ou des entrées « accepter tout », vous ne pouvez pas corriger un endpoint isolé. Il faut mettre en place un pattern cohérent de validation et d'accès DB dans tout le projet.

Les signaux qui penchent vers une reconstruction incluent souvent : secrets côté client « pour faire simple », endpoints sans contrôles d'accès, requêtes construites à partir de texte utilisateur à plusieurs endroits, gestion de session qui casse au rafraîchissement ou sur timeouts, et pas de frontière claire entre données publiques et privées.

Les bases manquantes comme la limitation de débit, la protection CSRF et des contrôles d'autorisation fiables sont patchables si l'architecture est propre. Mais si chaque route est un cas spécial, le durcissement devient un jeu de whack‑a‑mole.

Signaux d'architecture : douleur de refactor vs redémarrage propre

L'architecture, c'est là où les raccourcis prototype deviennent des gouffres de temps. C'est souvent le facteur décisif entre un refactor ciblé et une reconstruction propre.

Un signe courant est « tout est partout » : la même règle métier apparaît dans un composant UI, une route API et un helper, chacun légèrement différent. Quand l'accès aux données, le traitement des requêtes et le rendu sont mélangés, chaque changement risque de casser plusieurs endroits.

Signaux qui signifient généralement une douleur de refactor

Cherchez des patterns qui rendent le code difficile à comprendre et à tester :

• Logique cœur dupliquée dans plusieurs fichiers sans source de vérité
• Appels DB éparpillés dans l'UI ou les handlers de route sans couche de données claire
• Plusieurs façons d'accomplir la même tâche (deux vérifs d'auth, trois helpers de facturation)
• Chemins lents intégrés (boucles de fetch répétées, gros boulot côté client, N+1 évidents)
• État stocké en mémoire ou en singletons en supposant un seul serveur

Quand vous voyez plusieurs de ces choses dans la même fonctionnalité, la refactorisation s'étend souvent. Vous corrigez un bug et découvrez que la « vraie » logique vit ailleurs.

Quand une reconstruction est l'option la plus humaine

Une reconstruction devient attrayante quand il n'y a pas de frontières dignes d'être préservées. Un prototype qui « marche sur ma machine » mais qui repose sur des sessions en mémoire, mélange des écritures DB dans des événements UI et répète les mêmes fetchs à travers les composants peut être patché, mais chaque patch ajoute plus de colle.

Une règle pratique : si vous ne pouvez pas dessiner un diagramme simple en boîtes (UI, API, couche données) et pointer où chaque règle vit, l'ampleur est probablement plus importante qu'elle n'en a l'air.

Une grille de notation simple à appliquer en 30–60 minutes

Utilisez cette grille quand vous avez besoin d'une estimation rapide et défendable. L'objectif est de réduire les reconstructions surprises.

Étape 1 : Notez quatre domaines de risque (1 à 5)

Notez chaque domaine de 1 (propre, prévisible) à 5 (haut risque, problèmes qui se cumulent) : authentification, modèle de données, sécurité et architecture.

• 1–2 : Fonctionne globalement, les changements restent locaux, peu de surprises
• 3 : Fonctionne par endroits mais a des arêtes vives et du couplage caché
• 4–5 : Casse souvent, les corrections créent de nouveaux bugs, difficile à raisonner

Étape 2 : Ajoutez un score « inconnues » (1 à 5)

Les inconnues explosent les estimations. Notez la documentation manquante, les tests absents, des étapes de reproduction instables ou une équipe qui ne peut pas expliquer les flux centraux.

Étape 3 : Séparez les bloqueurs des irritants

Avant d'additionner, étiquetez les constats en bloqueurs ou irritants.

Bloqueurs stoppent l'usage en production : les utilisateurs ne peuvent pas se connecter, les données sont corrompues, des secrets sont exposés.

Irritants sont survivables : UI incohérente, pages lentes, noms de dossiers désordonnés.

Étape 4 : Mappez le total à une action

Additionnez les cinq scores (auth + données + sécurité + architecture + inconnues) et appliquez une règle empirique :

• 5–9 : Correction rapide (changements ciblés, mise en production rapide)
• 10–14 : Refactor (améliorer la structure tout en gardant le cœur)
• 15–19 : Reconstruction partielle (reconstruire un sous‑système, garder le reste)
• 20–25 : Reconstruction complète (plus rapide que de courir après les pannes)

Étape 5 : Transformez‑le en déclaration d'ampleur

Rédigez trois lignes courtes : À corriger maintenant, Différer, Hors périmètre.

Exemple : « À corriger maintenant : flux de connexion, gestion des secrets, contraintes DB. Différer : polish UI admin. Hors périmètre : nouvelles fonctionnalités de facturation. »

Pièges courants qui faussent les estimations

Une UI propre peut cacher des fondations fragiles. Les apps générées par IA ont souvent l'air finies parce que les écrans sont faciles à générer, mais les parties à risque se cachent derrière : auth, permissions, règles de données et gestion des secrets.

Autre erreur : considérer « ça marche en local » comme preuve que le travail est mineur. Le succès local peut dépendre de sessions en cache, d'une DB locale sans données réelles, de clés en dur qui ne survivront pas au déploiement réel ou d'absence de limites de taux.

La sécurité est souvent ce qui tue l'estimation. Si vous prévoyez de « patcher la sécurité à la fin », le calendrier glisse habituellement parce que la sécurité touche authentification, accès aux données, design d'API et stockage.

Il est aussi facile de refactorer trop tôt. Si vous réorganisez des dossiers ou « nettoyez l'architecture » avant de comprendre qui possède quelles données et ce que chaque rôle peut faire, vous pouvez rendre le code plus joli tout en laissant les règles centrales cassées.

Un contrôle rapide intuitif :

• Ne considérez pas le polish UI comme un indicateur de qualité du backend
• Ne prenez pas les runs locaux pour de la préparation production
• Ne repoussez pas les décisions de sécurité
• Ne refactorez pas avant que le modèle de permissions soit clair
• N'ignorez pas le travail de déploiement

La préparation au déploiement est souvent sous‑estimée : variables d'environnement, étapes de build, migrations DB, journalisation basique et monitoring simple. Ce travail peut transformer un « fix de deux jours » en une semaine.

Checklist rapide : signaux les plus rapides de l'ampleur

Lorsque vous avez besoin d'une estimation express, cherchez des signaux qui prédisent du retravail, pas seulement des bugs. Si vous ne pouvez pas répondre clairement à l'une des questions, traitez‑la comme un multiplicateur d'ampleur.

• Créez un nouvel utilisateur et complétez le flux principal de bout en bout (pas seulement la démo happy‑path).
• Recherchez des secrets (clés API, URLs DB, secrets JWT) dans le repo et dans le code client.
• Confirmez que l'autorisation est appliquée côté serveur (pas seulement des boutons masqués).
• Vérifiez si les migrations s'exécutent proprement et si les tables/champs correspondent à ce que le code attend.
• Expliquez l'architecture en cinq phrases simples : où les requêtes arrivent, où réside l'auth, où vivent les règles métier, où les données sont stockées et comment se passe le déploiement.

Si l'inscription marche mais que l'autorisation API manque et que des secrets sont exposés, vous êtes déjà en territoire « durcissement sécurité + refactor ».

Exemple : décider refactor vs rebuild pour un prototype qui casse souvent

Un fondateur non technique apporte un prototype Lovable qui « marche en grande partie », sauf que la connexion échoue aléatoirement et les gens se déconnectent. L'objectif est d'estimer l'ampleur sans passer des jours à lire tous les fichiers.

Une passe de 30 minutes peut répondre à quatre questions : est‑ce que ça tourne, peut‑on s'inscrire et se connecter, des données sensibles sont‑elles exposées, et la DB correspond‑elle à ce que l'app pense ?

Ce qu'on vérifie d'abord

Démarrez l'app localement (ou sur son hôte actuel) et répétez le flux de connexion plusieurs fois : inscription, déconnexion, reconnexion. Ensuite, suivez l'auth de bout en bout : formulaire frontend, route API, création de session ou token, paramètres cookie, middleware.

Ensuite, balayez les secrets exposés (clés API dans le repo, secrets JWT en dur, URLs DB publiques) et vérifiez le schéma : tables, relations, migrations et types (en particulier user, org, permissions).

Voici un score d'exemple (0 = correct, 3 = sévère) :

Total : 10/12. Cela pointe généralement vers la reconstruction des fondations (auth + accès aux données) tout en réutilisant les écrans et le contenu UI.

Corrections immédiates (à faire maintenant) : remplacer l'auth par une approche cohérente, faire pivoter et supprimer les secrets exposés, ajouter une validation basique et protéger les endpoints à haut risque, rendre les migrations reproductibles et ajouter un logging minimal autour des connexions et créations d'utilisateur.

Après stabilisation, différer le nettoyage structurel (noms de dossiers, refactors plus profonds), l'optimisation des performances et les outils admin facultatifs.

La surprise vient souvent du couplage caché : des bugs de connexion « rapides » causés par la dérive du schéma ou deux IDs utilisateurs différents.

Étapes suivantes : transformer la rubrique en plan clair

Transformez votre score en une page d'ampleur que vous pouvez partager avec un coéquipier, un fondateur ou un client. Restez simple : ce qui est cassé, ce qui est risqué et ce que vous ferez en premier.

Incluez :

• Les 3 principaux risques (flux d'auth cassé, modèle de données flou, secrets exposés)
• Les 5 principales corrections (rédigées comme résultats, pas tâches)
• Votre recommandation : refactor par étapes ou reconstruction
• Le premier jalon que vous pouvez livrer en sécurité
• Ce que vous ne touchez pas encore (pour protéger le planning)

Si votre score est élevé, planifiez une reconstruction mais gardez‑la minimale. Définissez un noyau prêt pour la production : un chemin heureux, authentification réelle, schéma de DB propre et journalisation basique. Ajoutez les fonctionnalités après que les fondations soient stables.

Si votre score est intermédiaire, choisissez un refactor par étapes. Commencez par la sécurité et l'auth parce qu'elles affectent tout et sont difficiles à corriger après coup. Ensuite, attaquez le modèle de données, puis le nettoyage d'architecture.

Si vous avez hérité d'une app générée par IA et que vous êtes enterré sous les inconnues, obtenir un diagnostic externe peut être le moyen le plus rapide d'arrêter de deviner. FixMyMess (fixmymess.ai) se concentre sur la prise en charge de prototypes générés par IA pour les rendre prêts pour la production via diagnostic du code, réparation de logique, durcissement de la sécurité, refactorisation et préparation au déploiement.