Supprimer les constantes magiques du code généré par l'IA (en toute sécurité)

Pourquoi les constantes magiques posent problème dans le code généré par l'IA

Les constantes magiques sont des valeurs disséminées dans le code sans nom ni explication. Elles prennent la forme de nombres codés en dur (comme 7 ou 10000), d'URL collées (comme un endpoint d'API), ou de chaînes qui contrôlent discrètement le comportement (comme "beta", "admin" ou "enabled"). Quand vous les voyez plus tard, vous ne savez pas pourquoi cette valeur existe ni ce qui casse si vous la changez.

Les prototypes générés par l'IA aggravent le problème parce que le code est souvent produit en petits morceaux séparés. Un composant a un timeout, un autre en a un différent, et un troisième colle une URL avec un chemin légèrement différent. L'appli fonctionne assez bien pour une démo, mais la même règle finit par être implémentée en plusieurs endroits avec de petites différences.

C'est pourquoi supprimer les constantes magiques peut sembler risqué. Une simple demande comme « augmenter la limite d'upload de 10MB à 25MB » se transforme en chasse à travers les contrôleurs, composants UI, helpers de validation et jobs en arrière-plan. En manquant un endroit, vous livrez un bug qui n'apparaît qu'en production.

Vous verrez généralement les symptômes rapidement :

• Comportements incohérents entre les pages (un écran autorise 25MB, un autre bloque à 10MB)
• Corrections qui marchent dans un flux mais échouent ailleurs
• Tests difficiles à écrire parce que les règles sont dispersées
• Hotfixes qui créent de nouveaux cas limites au fil du temps
• Tickets support confus (« ça marche parfois ») sans motif clair

Un exemple réaliste : votre appli a "https://api.example.com" codée en dur dans le flux de login, mais un autre fichier utilise "https://api.example.com/" et un troisième pointe encore vers "https://staging-api.example.com" laissé par une invite précédente. Vous changez l'un, l'auth échoue encore pour certains utilisateurs, et vous partez à la chasse aux fantômes.

C'est l'un des problèmes les plus courants que nous voyons dans les apps construites par l'IA chez FixMyMess. Le chemin le plus rapide vers des changements plus sûrs est de rendre les valeurs importantes ennuyeuses : un nom, un endroit, une source de vérité.

Ce qui compte comme une constante magique (et ce qui n'en est pas une)

Une constante magique est toute valeur incorporée dans le code dont le sens n'est pas évident, et dont la modification ultérieure exige de fouiller les fichiers et de deviner ce qu'elle affecte ailleurs. Dans les prototypes générés par l'IA, ce risque augmente parce que les mêmes valeurs sont souvent répétées dans beaucoup de fichiers.

Qu'est-ce qu'une constante magique ?

Les constantes magiques apparaissent généralement sous forme de nombres magiques, de chaînes magiques et d'URL codées en dur. Ce sont souvent des "valeurs par défaut importantes" qui contrôlent discrètement le comportement.

Exemples courants :

• Timeouts comme 3000 ou 30 (millisecondes ou secondes ?)
• Tailles de pagination comme 10, 20, 50
• Nombre de retries comme 3 ou 5
• URL de base d'API comme https://api.example.com/v1
• Toggles cachés sous forme de chaînes comme "enableNewCheckout" = true

Le problème n'est pas que ces valeurs existent. Le problème, c'est que le code n'explique pas ce qu'elles signifient. Six semaines plus tard, 3000 ressemble à une supposition, pas à une décision.

Pourquoi un « petit changement rapide » se retourne contre vous

Dans les prototypes générés par l'IA, la même constante est souvent copiée-collée dans des composants, routes et fichiers helper. Vous la changez à un endroit, les tests passent, puis un autre écran casse parce qu'il utilisait une copie légèrement différente.

Les duplicatas cachés sont particulièrement sournois : timeout = 3000 dans un fichier, timeout = 3500 dans un autre, et timeoutMs = 3000 ailleurs. Cette différence peut être intentionnelle ou dériver accidentellement. Dans les deux cas, le comportement dépend maintenant du chemin emprunté par l'utilisateur.

Ce qui NE compte PAS comme une constante magique

Toutes les valeurs littérales ne doivent pas devenir de la configuration. Certaines valeurs sont bien en ligne parce qu'elles sont explicites et peu susceptibles de changer.

Bonnes valeurs non-magiques :

• 0 ou 1 comme compteur de boucle simple
• 404 quand on retourne un statut HTTP dans un handler
• Une petite valeur d'espacement UI clairement locale à un composant

Une règle utile : si changer la valeur devrait être une décision produit délibérée (limites, URL, retries, gating), elle appartient à un endroit nommé.

Une façon simple de trouver et prioriser ce qu'il faut corriger

Le plus dur n'est pas le changement en lui-même. C'est choisir quoi attaquer en premier pour ne pas créer de nouveaux bugs.

Commencez par un inventaire rapide. Utilisez la recherche de votre éditeur pour chercher les valeurs répétées : la même URL, le même timeout, le même 10 ou 1000, la même chaîne de statut. Si une valeur apparaît dans 5+ endroits, c'est une forte candidate. Si elle apparaît seulement 2 fois mais touche l'argent ou la connexion, c'est aussi une candidate.

Concentrez-vous sur le risque, pas la perfection. Les constantes qui font le plus de mal sont celles qui peuvent casser la production ou créer des problèmes de sécurité quand elles sont erronées.

Une règle de triage rapide

Triez ce que vous trouvez en « corriger maintenant » et « corriger plus tard ». « Corriger maintenant » inclut généralement :

• Auth et identité : URL OAuth, URL de callback, durées de tokens, réglages de cookies
• Paiements et webhooks : endpoints fournisseurs, noms de secrets de signature, délais de retry
• Limites et quotas : max de requêtes, max d'uploads, tailles de pagination
• Timeouts et retries : valeurs de timeout d'API, intervalles des jobs en arrière-plan
• URL externes : toute référence à staging, localhost ou un serveur perso

Ensuite, choisissez un élément et créez une source de vérité unique avant de toucher plusieurs fichiers. Le code IA a souvent la même valeur sous des formes légèrement différentes, et des modifications rapides deviennent des refactors à moitié finis.

Donnez un nom pour que tout le monde comprenne

Utilisez des noms qui expliquent l'intention. Évitez CONST_1 ou DEFAULT_VALUE. Préférez AUTH_TOKEN_TTL_SECONDS ou PAYMENTS_WEBHOOK_BASE_URL. Indiquez les unités dans le nom (secondes vs millisecondes) pour que personne n'ait à deviner.

Exemple : si vous trouvez trois URL webhook Stripe différentes et deux valeurs de timeout à travers des handlers, créez PAYMENTS_WEBHOOK_URL et PAYMENTS_API_TIMEOUT_MS dans un seul endroit. Puis mettez à jour les points d'appel un par un, en vérifiant le comportement au fur et à mesure.

Si vous avez hérité d'un prototype cassé issu d'outils comme Bolt, v0, Cursor, Lovable ou Replit, c'est souvent la première étape de nettoyage que nous faisons chez FixMyMess : centraliser les valeurs risquées, puis faire le reste des réparations sur une base stable.

Étape par étape : centraliser limites, URL et timeouts

L'objectif est simple : mettre « les choses qui changent » en un seul endroit avec des noms clairs, pour pouvoir les mettre à jour sans chercher dans tout le code.

Une méthode pratique

Traitez ça comme une série de petits commits sûrs, pas comme une grosse réécriture.

1. Choisissez un emplacement évident pour la configuration. Créez un seul module (ou fichier) que toute l'app peut importer, comme config ou settings.

2. Ajoutez des noms lisibles et des valeurs par défaut. Préférez des noms qui expliquent l'intention, pas le type : API_BASE_URL, REQUEST_TIMEOUT_MS, MAX_UPLOAD_MB, PASSWORD_MIN_LENGTH. Utilisez des valeurs par défaut sûres pour que les runs locaux ne cassent pas.

3. Remplacez les littéraux progressivement. Choisissez un dossier ou une fonctionnalité, remplacez les littéraux par des valeurs de config, committez, et continuez. Les petits pas sont plus faciles à relire et à annuler.

4. Faites une vérification légère après chaque portion. Lancez l'app et parcourez ce que vous avez touché (login, upload, checkout). Si vous avez des tests, exécutez-les. L'objectif est un retour rapide.

5. Gardez les commits ciblés. Un commit pour « centraliser les timeouts », un autre pour « centraliser les URLs d'API ». C'est plus simple pour repérer les erreurs (secondes vs millisecondes).

Un petit exemple qui évite des bugs futurs

Supposons que votre appli appelle https://api.example.com dans cinq fichiers, et que chacun utilise un timeout différent : 2000, 5000, 15_000. Après centralisation, vous définissez API_BASE_URL et REQUEST_TIMEOUT_MS une fois. La prochaine fois que vous basculerez vers un serveur staging ou aurez besoin de timeouts plus longs en pic de trafic, vous changez un seul fichier, pas cinq.

Où stocker la config : env vars, fichiers de config et valeurs par défaut

Une fois que vous sortez les valeurs du code, il faut leur donner une maison claire. L'objectif : une source de vérité facile à modifier et sûre à livrer.

Ce qui va en env vars vs valeurs par défaut dans le code

Les variables d'environnement conviennent aux valeurs qui changent selon l'environnement ou ne devraient pas vivre dans le repo. Les valeurs par défaut dans le code conviennent aux valeurs non sensibles et qui facilitent la configuration locale.

Une répartition pratique :

• Variables d'environnement : clés API, secrets d'auth, URLs de base de DB, endpoints privés de services, secrets de webhooks tiers
• Fichiers de config (committés) : réglages non-secrets comme disponibilité de fonctionnalités, URLs publiques connues, valeurs de pagination, comptages de retry
• Valeurs par défaut dans le code : fallback qui garde l'app en fonctionnement si un réglage manque (jamais pour des secrets)

Si une valeur peut casser la prod ou exposer des données, privilégiez les env vars. Si c'est juste une valeur par défaut raisonnable (comme PAGE_SIZE=20), une valeur par défaut dans le code suffit.

Gérer local, staging et production sans surprises

Beaucoup de prototypes IA codent par erreur « l'environnement testé » par l'auteur. Au lieu de ça, rendez la config sensible à l'environnement : local utilise des variables shell locales (ou un fichier .env local), staging utilise ses propres réglages de déploiement, production utilise des secrets verrouillés.

Gardez les règles prévisibles :

• Les mêmes clés de config partout (seules les valeurs changent)
• Échouer vite si des secrets requis manquent en staging/production
• Autoriser des defaults seulement pour les valeurs non sensibles

Par exemple, vous pouvez autoriser REQUEST_TIMEOUT_MS=8000 par défaut en local, mais exiger DATABASE_URL et JWT_SECRET avant que l'app ne démarre en staging ou production.

Ne mélangez pas le chargement de config et la logique applicative

Un piège courant est de parse process.env... partout dans le code. Ça transforme la config en logique cachée. Au lieu de ça, chargez et validez la config une seule fois au démarrage (dans un module), puis passez la config aux parties de l'app qui en ont besoin.

Les feature toggles qui ne tournent pas au désastre

Les feature toggles sont des interrupteurs simples qui permettent de livrer du code sans l'exposer immédiatement à tous les utilisateurs. Dans le code généré par l'IA, les toggles apparaissent souvent comme des booléens aléatoires dispersés dans les fichiers, ce qui est une autre forme de constante magique.

Un bon toggle répond à une seule question en langage clair : « Les utilisateurs doivent-ils voir X ? ». Pour les rollouts risqués, c'est utile. Vous pouvez déployer un nouveau parcours d'inscription à une petite fraction d'utilisateurs, ou garder une page de pricing cachée jusqu'à approbation. La clé est que basculer le toggle change le comportement sans éditer plusieurs fichiers sous pression.

Nommer et structurer pour rester lisible

Choisissez un style de nommage cohérent et tenez-vous-y. Des noms descriptifs valent mieux que courts. enableNewSignupFlow vaut mieux que flag2 car n'importe qui peut deviner son effet lors d'un hotfix.

Regroupez les toggles en un seul endroit (votre module config ou fichier settings). Si la valeur doit varier selon l'environnement, mappez-la vers une variable d'environnement, mais exposez-la toujours via le même objet de config pour que le reste de l'app ne se préoccupe pas de sa provenance.

Quelques règles pour éviter la prolifération des toggles :

• Préférez enableX ou useX correspondant au comportement visible par l'utilisateur
• Un toggle par fonctionnalité, pas par fichier
• Ajoutez une date d'expiration ou une note de suppression pour les toggles temporaires
• Par défaut, désactivez les changements risqués

Décidez qui peut basculer le bouton

Les toggles peuvent causer de vrais dégâts si n'importe qui peut les changer facilement. Décidez qui peut les modifier et comment les changements sont revus.

Exemple : votre app IA a une nouvelle page de checkout derrière un toggle. Un stakeholder demande de le désactiver après une hausse de tickets support. Si le toggle est centralisé, vous pouvez inverser une valeur et être sûr de ne pas avoir raté une copie cachée du même booléen.

Un exemple réaliste : un changement, un endroit

Imaginez une startup qui a livré un prototype généré par l'IA rapidement. Ça marche pour les démos, mais le code a les mêmes valeurs copiées partout : URL d'API, timeouts, limites, et un switch « new checkout ».

Avant : petit changement, multiples edits risqués

Vous devez pointer l'app d'une API staging vers la prod. Vous cherchez https://api-staging... et la trouvez dans six fichiers : fetch frontend, client backend, handler de webhook et job worker. Vous les changez tous, vous shippez, et plus tard vous découvrez qu'un fichier pointe encore vers staging. La moitié de l'app lit des données anciennes.

Ensuite, en production, votre rate limit doit passer de 10 à 50 req/min, et un timeout doit passer de 2s à 8s. Ces nombres sont dispersés, et un endroit utilise des millisecondes tandis qu'un autre utilise des secondes. Un simple ajustement devient un jeu de devinettes.

Enfin, des erreurs explosent sur une nouvelle fonctionnalité. Le code IA a ajouté ENABLE_NEW_CHECKOUT = true dans deux modules différents. Vous mettez l'un à false, mais les utilisateurs voient encore le chemin cassé parce que l'autre constante est toujours true.

Voici à quoi ressemble souvent ce pattern désordonné :

// auth.js
const API_BASE_URL = "https://api-staging.example.com";

// orders.js
fetch("https://api-staging.example.com/orders", { timeout: 2000 });

// worker.js
const TIMEOUT_MS = 2000;
const RATE_LIMIT = 10;

// checkout.js
const ENABLE_NEW_CHECKOUT = true;

Après : une mise à jour, un seul endroit

Après centralisation, le reste de l'app importe depuis un module config unique (et utilise des variables d'environnement quand c'est pertinent).

// config.js
export const config = {
  apiBaseUrl: process.env.API_BASE_URL ?? "https://api.example.com",
  timeoutMs: Number(process.env.TIMEOUT_MS ?? 8000),
  rateLimitPerMin: Number(process.env.RATE_LIMIT ?? 50),
  features: {
    newCheckout: process.env.FEATURE_NEW_CHECKOUT === "true",
  },
};

// orders.js
fetch(`${config.apiBaseUrl}/orders`, { timeout: config.timeoutMs });

Maintenant « changer l'API base URL » signifie mettre à jour une variable d'environnement, pas éditer la moitié du code. « Augmenter le timeout » signifie changer un seul nombre avec une seule unité. « Désactiver la nouvelle fonctionnalité » signifie basculer un seul flag rapidement quand quelque chose casse.

Erreurs courantes et pièges à éviter

L'objectif est la sécurité : moins d'éditions risquées, moins de surprises, des changements plus faciles à l'avenir. La plupart des problèmes arrivent quand le refactor semble propre, mais le comportement change discrètement.

Une erreur commune est de renommer une constante sans mettre à jour toutes les utilisations. Ça arrive beaucoup dans les projets IA où la même valeur est dupliquée sous des noms légèrement différents. L'app compile toujours, mais une limite, une URL ou un timeout devient incohérent.

Plusieurs fichiers de config sont un autre piège. Ça commence par « un pour le server, un pour le client », puis ça devient trois ou quatre fichiers qui divergent. Quand une valeur change, moitié de l'équipe met à jour le fichier A et oublie le fichier B.

Faites aussi attention aux fallback « utiles » qui écrasent silencieusement les env vars. Les defaults sont acceptables, mais seulement quand ils sont évidents et sûrs. Si votre code fait « utiliser ENV si présent, sinon cette URL de prod codée en dur », vous pouvez livrer une build qui parle au mauvais backend.

Erreurs qui mordent le plus :

• Renommer des constantes sans mettre à jour chaque import et usage, laissant un comportement scindé
• Créer plusieurs sources de config (plusieurs fichiers, plusieurs patterns) qui divergent avec le temps
• Valeurs par défaut codées qui l'emportent silencieusement sur les env vars, surtout en production
• Traiter les secrets comme des constantes normales (clés API dans des fichiers de constantes, committer des .env)
• Trop d'abstraction trop tôt avec des couches de config que personne ne comprend en cas d'incident

Si vous avez hérité d'un prototype généré par l'IA et que vous doutez que votre refactor n'ait pas modifié le comportement, c'est exactement ce que FixMyMess audite : duplicatas cachés, defaults dangereux et secrets mélangés dans les fichiers de constantes.

Checklist rapide avant de livrer le refactor

Après avoir centralisé les constantes, l'app peut sembler plus propre mais cacher encore des écarts risqués. Utilisez ce contrôle rapide avant la merge.

Vérification de sanity de la configuration

Faites un test de « changement unique ». Choisissez une valeur que vous pensez devoir changer plus tard (comme l'API base URL), mettez-la à jour une fois et confirmez que l'app utilise la nouvelle valeur partout. Si vous devez encore chercher dans plusieurs fichiers, vous ne l'avez pas vraiment centralisée.

Assurez-vous aussi que les secrets ne sont pas mélangés avec les réglages normaux. Votre config peut inclure des defaults sûrs, mais tout ce qui est sensible (clés API, mots de passe DB, secrets JWT) doit provenir uniquement des variables d'environnement. Si un secret est dans le repo, supposez qu'il fuira tôt ou tard.

Une checklist pré-merge :

• Changez un réglage clé (API base URL, webhook URL ou host CDN) en un seul endroit et vérifiez que toute l'app le suit.
• Recherchez les littéraux restants qui devraient être nommés (timeouts comme 30000, limites comme 50, retries comme 3).
• Assurez-vous que limites et timeouts sont nommés clairement et expliqués par un court commentaire (ce qu'ils protègent, et pourquoi cette valeur).
• Vérifiez que les toggles ont un propriétaire, une valeur par défaut sûre et un plan de suppression s'ils sont temporaires.
• Lancez un smoke test : connexion, principales écrans, et déclenchez au moins un chemin d'erreur (mauvais mot de passe, enregistrement manquant, mode hors-ligne).

Contrôle final « briser la vitre »

Pendant le smoke test, regardez les logs ou la console. Si vous voyez une env var manquante, une URL fallback inattendue, ou un toggle qui par défaut se comporte mal, corrigez avant de livrer.

Si vous avez hérité d'un prototype IA fragile et que vous n'êtes pas sûr des hardcodings ou des failles, FixMyMess (fixmymess.ai) peut commencer par un audit de code gratuit pour repérer les constantes risquées, les secrets exposés et les patterns de config qui plantent souvent en production.

Étapes suivantes : garder le code propre au fur et à mesure

Le vrai gain est d'empêcher les constantes magiques de réapparaître. Les petites équipes vont vite, et « encore un nombre codé en dur » est la façon dont on retrouve des modifications dispersées et risquées.

Un pas pratique suivant est un court sprint de nettoyage axé sur les constantes qui vous nuisent vraiment. Ne tentez pas de tout réparer. Choisissez les 10–20 valeurs qui changent souvent ou qui peuvent casser la prod si elles sont fausses (timeouts, rate limits, API base URLs, seuils de pricing, tailles d'upload), centralisez-les et livrez en petits lots.

Mettez en place une règle légère d'équipe : les nouvelles valeurs importantes doivent avoir un nom et une maison. Si ce n'est pas clairement un cas local (comme un index de boucle), ça appartient à votre module config ou constants.

Si votre base de code est générée par l'IA et semble fragile, un audit expert avant des refactors plus profonds peut vous faire gagner beaucoup de temps. Ces projets cachent souvent des constantes risquées aux côtés de problèmes plus sérieux comme des secrets exposés, des flux d'auth cassés ou des requêtes DB non sécurisées.