Supprimer en toute sécurité les fonctionnalités hallucinées dans les dépôts générés par l'IA

Ce que sont les fonctionnalités hallucinées (et pourquoi elles nuisent)

Les fonctionnalités hallucinées sont des parties d'une base de code qui ressemblent à du travail produit réel, mais qui n'ont jamais été de vraies exigences. Dans les dépôts générés par l'IA, elles apparaissent souvent sous la forme d'écrans supplémentaires, de routes, d'endpoints API ou de tables de base de données ajoutés parce que l'outil a deviné ce qu'une "application complète" devrait contenir.

Concrètement, cela peut être une page Paramètres soignée que personne n'atteint, une API "admin" qui n'est jamais appelée, ou une table "subscriptions" dans laquelle rien n'écrit. Tout compile, mais la fonctionnalité n'est pas connectée à de réels besoins utilisateurs ou à des flux opérationnels.

Le coût n'est pas seulement de la confusion. Chaque page, endpoint et table en plus augmente la surface d'attaque de votre application. Cela signifie plus d'endroits où des bugs peuvent apparaître, plus de façons de fuiter des secrets, et plus de chemins déroutants pour qui que ce soit qui maintiendra le projet plus tard.

Les fonctionnalités fantômes augmentent le risque et le coût parce qu'elles :

• Ajoutent du bruit pendant le débogage et masquent le problème réel.
• Élargissent l'exposition sécurité via des endpoints supplémentaires, des contrôles d'auth incomplets et des valeurs par défaut dangereuses.
• Ralentissent les changements parce qu'on craint de casser des dépendances inconnues.
• Induisent en erreur les décisions produit parce que le dépôt suggère des capacités que vous n'avez pas réellement.
• Augmentent le travail de maintenance (tests, migrations, refactors) pour des choses que personne n'utilise.

Ces fonctionnalités proviennent souvent de scaffolds IA qui génèrent des modules "standard", de snippets de templates copiés, ou de threads de prompts où une fonctionnalité a été commencée puis oubliée. Parfois l'idée était raisonnable, elle n'a simplement jamais été intégrée dans un vrai parcours utilisateur.

L'objectif est simple : garder ce qui sert de vrais utilisateurs et supprimer ce qui ne sert pas, sans casser les flux critiques. Un scénario courant est un MVP généré par IA avec trois écrans de connexion différents, deux dashboards admin et un schéma de facturation qui ne fait rien. Nettoyer cela rend l'app plus facile à sécuriser et moins coûteuse à faire évoluer.

Les trois types principaux : pages mortes, API inutilisées, tables factices

Quand vous supprimez des fonctionnalités hallucinées, la majeure partie du risque se concentre dans trois endroits. Elles restent silencieuses dans le dépôt, mais elles ajoutent une surface d'attaque, de la confusion et du travail de maintenance futur.

1) Pages mortes (routes inaccessibles)

Les pages mortes sont des écrans qui existent dans le routeur, mais que les vrais utilisateurs n'atteignent jamais. Elles apparaissent souvent comme des flux abandonnés tels que "Team Settings", "Billing" ou "Admin" qui ont été générés tôt puis oubliés.

Elles comptent quand même parce que des utilisateurs curieux peuvent les découvrir, les partager, les indexer ou les ouvrir directement. Même une page à moitié terminée peut divulguer des données internes, générer des erreurs bruyantes ou exposer des flags de fonctionnalité et des indices d'environnement.

2) API inutilisées (endpoints sans appel réel)

Les API inutilisées sont des routes serveur qui n'ont pas d'appelants frontend réels, ou qui ne sont sollicitées que par une page de test ou un script d'exemple laissé là. Ces endpoints sont faciles à déployer par accident, surtout quand tout vit sous un dossier API générique.

Le danger n'est pas seulement du code en trop. Les endpoints inutilisés sautent souvent les contrôles d'auth, acceptent des entrées trop larges ou renvoient plus de données qu'ils ne devraient. Cela en fait une cible facile.

3) Tables factices (structure de base de données fictive)

Les tables factices donnent l'impression de progrès, mais ce sont souvent des coquilles vides : colonnes génériques, pas de contraintes, pas d'index, et aucune lecture/écriture réelle depuis l'app.

Elles induisent aussi en erreur le travail futur. Quelqu'un voit la table et suppose que la fonctionnalité existe, puis bâtit dessus. C'est ainsi que des schémas "temporaires" deviennent une dette permanente.

D'autres signes communes de fonctionnalités hallucinées incluent des modules principalement remplis de TODOs, des écrans admin démo qui contournent les permissions, une authentification factice qui accepte n'importe quel email, et des fichiers de config pour des services que vous n'utilisez pas.

Avant de supprimer : décidez ce que "sûr" signifie pour votre app

Supprimer du code n'est sûr que si vous êtes d'accord sur ce qui ne doit pas changer.

Commencez par les flux clés, pas par les fichiers. Pour la plupart des apps, il s'agit de l'inscription, connexion, réinitialisation de mot de passe, déconnexion, et toute action liée à l'argent ou aux données comme le checkout, la création d'un enregistrement, l'export ou l'invitation d'un coéquipier. Si votre équipe utilise quotidiennement un écran admin interne, incluez-le.

Soyez honnête sur qui utilise l'app aujourd'hui. Les utilisateurs payants exigent le plus de précautions. Une démo interne utilisée par deux personnes peut tolérer davantage de changements. Si personne ne l'utilise encore, "sûr" peut simplement signifier : garder la démo fonctionnelle tout en coupant tout ce qui augmente le risque.

Une règle de décision simple évite les débats interminables :

• Supprimer maintenant : pas d'utilisateurs, pas de références, placeholder clair ou risque évident.
• Archiver : pourrait revenir plus tard, mais ne doit pas être déployé ou exécuté en production.
• Conserver mais marquer : utilisé aujourd'hui, mais a besoin d'un propriétaire ou d'une réécriture.

Votre règle d'acceptation peut être simple : "Aucun changement de comportement sur les flux clés." Même boutons, mêmes pages qui se chargent, mêmes données qui aboutissent au même endroit. Si le comportement doit changer, ce n'est plus de la suppression, c'est une refonte.

Avant de toucher quoi que ce soit, préparez un rollback. Gardez un commit connu bon, confirmez comment le redéployer, et décidez qui peut approuver un rollback si quelque chose casse.

Comment trouver les pages mortes et les routes orphelines

Les pages mortes sont des écrans présents dans le dépôt mais pas dans le produit. Les routes orphelines sont des URLs qui fonctionnent techniquement, mais vers lesquelles rien dans l'app ne pointe.

Commencez par ce sur quoi un utilisateur peut réellement cliquer. Ouvrez chaque menu de navigation, header, footer, barre latérale et dropdown de profil, et listez les URLs de destination. Comparez cela à votre configuration de routes (fichiers de router, dossiers pages, tableaux de routes). Tout ce qui est dans les routes mais non atteignable depuis la navigation est un candidat.

Des endroits rapides à vérifier :

• Routes jamais référencées par un composant de menu.
• Pages/composants qui n'apparaissent que dans des commentaires, du JSON mock ou des données de seed.
• Chemins "temporaires" comme /admin, /debug, /test, /demo, /old, /v2, /settings-2.
• Routes conditionnées par des conditions qui ne peuvent pas arriver (un flag toujours faux, un rôle jamais assigné).

Si vous avez des analytics ou des logs serveur, servez-vous-en comme vérification terrain. Une route avec zéro hits sur plusieurs semaines est un signal fort, surtout si ce n'est pas un workflow admin. Sans logs, faites un crawl manuel : parcourez les flux principaux, puis essayez quelques URLs probables directement.

Exemple : un MVP construit par IA peut inclure /team/invite et /billing/upgrade parce que le prompt mentionnait "SaaS". Si ces pages n'ont pas de liens, pas de tests et pas de liaison backend, elles sont généralement sans risque à supprimer ou à mettre en quarantaine.

Comment trouver les endpoints API inutilisés ou risqués

Les dépôts générés par IA contiennent souvent des endpoints qui semblaient utiles en prototype mais ne sont jamais devenus des parties du produit. Commencez par établir un inventaire, puis prouvez quels composants appellent chaque endpoint.

D'abord, listez chaque endpoint depuis le backend (fichiers router, controllers, fonctions serverless, et tout dossier api). Scannez aussi la config pour des rewrites qui pourraient exposer des handlers.

Puis retracez les appelants. Recherchez dans le frontend les appels fetch ou axios, vérifiez les jobs en arrière-plan et les queues, et cherchez des handlers de webhooks appelés par des tiers. Si vous avez des logs, cherchez les chemins d'endpoint sur les 7 à 30 derniers jours. L'absence de trafic n'est pas une preuve absolue, mais c'est un indice solide.

Avant de supprimer quoi que ce soit, marquez les endpoints risqués. Parmi les signaux d'alarme : routes de debug accessibles en production, contournements d'auth (tokens admin codés en dur, userId dans les query params), CORS trop permissif sur des routes sensibles, absence de validation, et endpoints qui renvoient des secrets ou des erreurs internes détaillées.

Pour chaque endpoint, choisissez une issue : le supprimer, le restreindre (retirer le routage public, restreindre l'accès), ou le garder et le corriger correctement avec auth, validation et limites de taux.

Comment repérer les tables factices et la structure de base de données inventée

Les dépôts générés par IA livrent parfois une base de données qui semble complète mais est en partie imaginaire. Les tables factices trompent les développeurs, masquent de vrais bugs et augmentent le risque quand des tables "temporaires" commencent subrepticement à contenir des données utilisateurs.

Commencez par lister chaque table et colonne, puis retracez ce qui l'utilise réellement. Une table est généralement réelle si l'app la lit, l'écrit, et qu'elle a des relations claires avec des tables centrales (users, orders, projects). Si elle n'apparaît que dans une migration et nulle part ailleurs, considérez-la comme suspecte.

Signes qu'une table est probablement factice

Quelques signaux fiables :

• Noms comme sample_*, demo_*, temp_*, test_*, mock_*, staging_*, placeholder_*.
• Pas de clés étrangères et pas d'index, alors qu'elle devrait être reliée à d'autres tables.
• Colonnes génériques comme data JSON, value TEXT, meta TEXT, notes TEXT sans signification claire.
• Données factices (lorem ipsum, emails faux, IDs fixes comme user_id = 1).
• Duplications (deux versions de "subscriptions", "payments" ou "profiles").

Inspectez aussi les migrations pour des expériences abandonnées : une migration crée une table, une autre crée une version différente, et rien ne nettoie l'ancienne. Si plusieurs tables représentent le même concept, ralentissez et vérifiez quel schéma l'app en production attend.

Quand vous décidez, choisissez une voie : la supprimer, la fusionner ou la reconstruire correctement. La suppression est la plus sûre seulement après avoir confirmé qu'il n'y a ni lectures, ni écritures, ni jobs de reporting qui l'utilisent.

Étape par étape : supprimer des fonctionnalités hallucinées sans casser l'app

Supprimer la mauvaise chose peut casser la connexion, les permissions ou la facturation. Traitez chaque fonctionnalité suspecte comme une petite demande de changement, même si vous êtes sûr qu'elle est fausse.

Pour chaque page morte, endpoint inutilisé ou table factice, notez trois choses : ce qui doit se passer après suppression, comment vous vérifierez qu'aucune dépendance importante n'en dépendait, et qui peut approuver la décision.

Un ordre d'opérations à faible risque :

• Supprimez d'abord les pages cachées et l'UI inutilisée.
• Ensuite retirez les handlers API inutilisés (et les helpers qui existent uniquement pour cette fonctionnalité).
• Nettoyez la base de données en dernier (migrations, modèles ORM, tâches cron).

Après chaque suppression, build l'app, lancez les tests si vous en avez, et parcourez manuellement les flux clés. Re-scannez aussi les frontières d'auth. Il est possible de supprimer du code d'une façon qui contourne malencontreusement un middleware ou modifie un contrôle de permission.

Erreurs courantes qui provoquent des régressions ou des problèmes de sécurité

Les cassures surviennent souvent quand un dépôt paraît propre dans le navigateur, mais que des parties cachées tournent encore en production. Pensez à ce qui peut être appelé sans cliquer : jobs, webhooks, tâches cron et requêtes HTTP directes.

Un piège courant est de supprimer une page ou un bouton mais de laisser l'API derrière. L'écran admin peut avoir disparu, mais l'endpoint accepte toujours des requêtes. Si l'auth est faible, cet endpoint devient une cible facile.

Une autre erreur est de supposer qu'un endpoint est inutilisé parce qu'il n'est pas lié dans l'UI. Les workers en arrière-plan, les tâches planifiées et les intégrations tierces peuvent encore l'appeler. Exemple : vous supprimez /api/email/weekly-summary parce qu'il n'apparaît sur aucune page, mais un job nocturne l'appelle encore, il échoue et génère des retries et des logs bruyants.

Le nettoyage de la base de données est l'endroit où l'on perd des données. Supprimer des tables "placeholder" sans vérifier les backups, l'ordre des migrations et l'usage en production peut casser des déploiements ou effacer des enregistrements réutilisés plus tard.

Avant de supprimer quoi que ce soit, vérifiez bien :

• Vous avez retiré l'accès, pas seulement l'UI (routes/controllers non accessibles publiquement).
• Vous avez cherché l'utilisation par des jobs/workers et des appels tiers.
• Vous avez validé les backups et la séquence des migrations.
• Vous avez supprimé les routes de debug, clés de test et logins admin temporaires de la production.

Checklist rapide avant de supprimer quoi que ce soit

Avant de supprimer du code, confirmez que vous n'enlevez pas quelque chose qui tient un flux ensemble silencieusement.

Commencez par l'atteignabilité. Si un utilisateur normal ne peut pas atteindre une page en cliquant normalement (pas en tapant une URL cachée), c'est un bon candidat. Confirmez néanmoins que vous ne coupez pas un chemin secondaire comme l'onboarding, la réinitialisation de mot de passe ou la configuration admin.

Vérifications rapides :

• Un utilisateur normal peut-il y accéder sans URL spéciales, comptes de test ou toggles dev-only ?
• Si c'est un endpoint API, est-il protégé (auth) et encadré (validations basiques, limites), ou est-il grand ouvert ?
• Si cela touche des données, trouvez-vous un vrai chemin de code qui lit ou écrit dans cette table en production ?
• La suppression changera-t-elle les rôles, permissions, invitations, accès à la facturation ou les étapes d'onboarding ?
• Avez-vous supprimé les secrets, clés d'exemple et configs réservées aux tests qui accompagnaient la fonctionnalité ?

Planifiez un rollback rapide. Même des suppressions prudentes peuvent casser des builds, des migrations ou des jobs d'arrière-plan. Taggez une release, conservez des commits propres, et assurez-vous de pouvoir redéployer la version précédente rapidement.

Exemple : nettoyage d'un MVP IA avec des fonctionnalités en trop

Un fondateur livre un MVP généré par IA. Le flux central fonctionne (inscription, création de projet, upload d'un fichier), mais le dépôt contient aussi "Teams" et "Billing". Personne ne les a demandés et personne ne les utilise, mais ils ajoutent des routes, endpoints et tables qui peuvent casser plus tard.

La première étape est de prouver que ces éléments sont hallucinations, pas simplement cachés. Cherchez des preuves d'utilisation réelle :

• Aucun lien de navigation ou bouton ne mène aux pages (seule une URL directe fonctionne).
• Aucun log backend ne montre d'appels aux endpoints concernés dans de vraies sessions.
• Le frontend n'appelle jamais les APIs.
• Les tables DB sont vides ou ne contiennent que des données de seed.
• Le code est plein de copies placeholder comme "TODO", "Coming soon" ou des paliers de plan factices.

Une fois que vous êtes confiant, réduisez la surface dans un ordre sûr : UI d'abord, API ensuite, schéma en dernier. Si vous n'êtes pas prêt à tout supprimer, gardez un stub clairement étiqueté (par exemple une page inoffensive qui dit "Billing n'est pas encore disponible") et évitez de laisser des endpoints à moitié finis ou des écritures DB incomplètes.

Le résultat est immédiat : moins de composants en mouvement, une surface d'attaque réduite, des revues de code plus rapides et une feuille de route plus claire pour ce que l'app fait réellement.

Étapes suivantes : garder le dépôt propre et réduire le risque dans la durée

Supprimer les fonctionnalités hallucinées est une victoire. Les empêcher de revenir est le vrai bénéfice.

Gardez un petit backlog de nettoyage pour tout ce que vous n'avez pas encore supprimé. Notez pourquoi cela est resté ("pourrait être utilisé plus tard", "nécessite une décision produit", "bloqué par des tests manquants") et ajoutez une action claire suivante. Cela empêche le scaffolding temporaire de devenir un risque permanent.

Quelques garde-fous légers :

• Faire échouer le CI sur les placeholders évidents (routes TODO, clés sample, flags de demo de données).
• Exiger pour chaque nouvelle page et endpoint une note d'usage ou un test.
• Revoir les routes/endpoints inutilisés en staging à intervalles réguliers.
• Maintenir une courte allowlist des vraies tables et migrations, et signaler tout ce qui en sort.

Si le dépôt est en désordre, ne commencez pas par supprimer des fichiers au hasard. Commencez par cartographier ce qui est atteignable dans l'UI, ce qui est atteignable sur le réseau, et quelles données sont réellement utilisées. Cette carte évite l'échec classique où vous supprimez une fonctionnalité "morte" qui soutenait silencieusement l'auth, la facturation ou l'onboarding.

Si vous avez hérité d'un prototype généré par IA et souhaitez un plan structuré de démantèlement, FixMyMess (fixmymess.ai) se concentre sur le diagnostic et la réparation des bases de code générées par IA, y compris l'identification des pages mortes, des endpoints risqués et des schémas factices avant toute suppression.