Déploiement progressif du mode strict TypeScript pour les applications générées par IA

Qu'est-ce que change le mode strict (et pourquoi les applications générées par l'IA échouent)

Le mode strict de TypeScript n'est pas une seule règle. C'est un ensemble de vérifications qui empêche le compilateur d'accepter des suppositions. L'activer fonctionne mieux si vous le traitez comme l'ajout de meilleurs détecteurs de fumée, pas comme la reconstruction de la maison entière.

Quand vous mettez "strict": true dans tsconfig, TypeScript active plusieurs réglages souvent désactivés dans les prototypes. Les plus remarquables sont :

• strictNullChecks : vous oblige à gérer null et undefined volontairement
• noImplicitAny : empêche les types “anything goes” silencieux
• strictFunctionTypes : détecte les types de paramètres de fonction non sûrs
• noImplicitThis : évite le problème du “this qui peut être n'importe quoi”
• alwaysStrict : applique les règles de strict mode JavaScript

Les applications générées par IA cassent souvent sous ces vérifications car elles « fonctionnent » en s'appuyant sur un typage faible et des hypothèses cachées : parser des réponses API en any, supposer qu'un champ existe toujours, traiter l'entrée utilisateur comme du bon type, ou passer des objets à moitié formés entre les couches. Tout semble correct jusqu'à ce qu'un vrai utilisateur rencontre un cas limite. Ensuite apparaissent des erreurs d'undefined, des flux d'auth brisés, ou des données qui n'ont pas la forme attendue par l'interface.

Le mode strict réduit les bugs runtime en rendant ces problèmes bruyants pendant le développement. Il détecte fréquemment :

• l'accès à des propriétés sur des valeurs possiblement undefined
• la confusion entre formes de données (par exemple, { id: string } vs { id: number })
• l'appel de fonctions avec des arguments manquants ou incorrects
• l'utilisation non sûre de any qui masque des erreurs de typage réelles

La première activation est souvent bruyante. C'est normal. Considérez-le comme une refactorisation contrôlée : vous ajoutez de la clarté et des garde‑fous par petites zones, pas vous ne réécrivez toute l'application.

Inventaire rapide : cartographiez les parties désordonnées avant de changer la config

Avant de toucher aux réglages stricts, passez une heure à cartographier où les bugs runtime sont les plus susceptibles de se cacher. Dans les projets générés par IA, un changement dans un fichier « central » peut faire exploser les erreurs à travers le repo.

Commencez par localiser où les données entrent dans l'app et sont réutilisées. Les types faibles se propagent le plus vite via :

• appels API et helpers client (wrappers fetch, instances axios, parsing des réponses)
• gestion de l'authentification et des sessions (stockage des tokens, objets user, middleware)
• couche base de données et requêtes (modèles ORM, SQL brut, migrations)
• utilitaires partagés et constantes (helpers date, accès aux env, feature flags)
• glue code entre pages/composants et services (mapping JSON -> état UI)

Ensuite, scannez les motifs que le mode strict va exposer. Vous ne les corrigez pas encore, vous repérez simplement : beaucoup de any, paramètres en implicit any, JSON non typé, champs optionnels utilisés comme s'ils existaient toujours, et des identifiants « stringly typed » qui se mélangent (userId vs orgId).

Décidez du périmètre tôt pour que le travail reste gérable. Vous pouvez cibler ce que vous vérifiez : d'abord le code source de l'app, puis les tests, scripts et outils de build. Un point de départ courant est « seulement le code source de l'app », afin de ne pas être bloqué par des scripts de dev one‑off.

Enfin, tenez un document léger de notes de migration. Suivez les types d'erreurs récurrentes (comme “Object is possibly undefined”) et votre correction préférée (clause garde, valeur par défaut ou meilleur type). Quand vous corrigez la 30e erreur similaire, vous serez content d'avoir pris des notes.

Choisissez une stratégie de staging qui rend le travail gérable

Un déploiement du mode strict réussit quand vous choisissez des unités de travail que vous pouvez terminer. Les apps générées par IA ont souvent une qualité inégale : un dossier est correct, le suivant regorge d'implicit any, de vérifications null manquantes et de types copiés‑collés. Le staging vous permet d'avancer sans transformer tout le code en un mur rouge.

Choisissez une unité de migration qui corresponde à l'organisation du projet : par dossier (projets stratifiés), par fonctionnalité (routes + UI + services), par package (monorepos), ou par point d'entrée (worker, webhook, job runner qui cause la plupart des crashs).

Continuez à livrer pendant la migration. Évitez une branche « strict mode » longue qui dérive pendant des semaines. Travaillez en petits PR et fusionnez souvent. Si la strictness n'est pas activée partout, traitez la « zone stricte » comme protégée : les nouveaux fichiers à l'intérieur doivent être propres, et les changements en dehors ne doivent pas affaiblir les types.

Désignez aussi une personne pour décider des patterns de migration. Il ne s'agit pas d'une question hiérarchique, mais de cohérence. Quelqu'un doit répondre à des questions comme : quand utiliser unknown vs any, comment nommer les types partagés, et quand une simple garde de type suffit vs quand une refactorisation vaut le coup.

Pour chaque tranche, définissez clairement ce qu'est « terminé » : les vérifications strictes passent pour cette tranche, les tests passent (ou vous ajoutez un petit test pour le chemin risqué), les échappatoires temporaires sont suivies, et le code reste lisible.

Plan de déploiement étape par étape (petits pas, moins de surprises)

Commencez par vous assurer que vous pouvez dire si vous avez cassé le comportement. Les apps générées par IA « fonctionnent » souvent parce que rien ne vérifie les cas limites, pas parce que le code est sûr.

Gelez le comportement d'aujourd'hui avec un build qui s'exécute de la même façon à chaque fois. Ajoutez quelques checks smoke qui couvrent les chemins principaux : connexion, chargement d'une page clé, soumission d'un formulaire et appel d'un endpoint API. Gardez‑les simples mais répétables.

Puis déployez le strictness par tranches contenues. L'objectif est moins de bugs runtime sans transformer tout en une gigantesque refactorisation.

1. Base actuelle : faites exécuter tsc en CI (ou localement) et assurez‑vous que le projet se compile proprement dans son état actuel. Ajoutez un petit script smoke ou une checklist manuelle que vous pouvez exécuter en 2 minutes.
2. Limitez la strictness à une zone sûre d'abord : appliquez des réglages plus stricts à un seul dossier (une nouvelle fonctionnalité, un package, ou un module) pour apprendre les motifs d'erreurs sans arrêter tout le travail.
3. Corrigez les frontières runtime à haut risque : concentrez‑vous sur les endroits où des données inconnues entrent dans le système, comme les réponses API, les corps de requête, les vars d'env, localStorage et lectures DB. Ajoutez du parsing/validation et faites correspondre les types à la réalité.
4. Étendez progressivement avec de petits PR : gardez les changements ciblés (un thème par PR), par exemple « corriger les any dans le client API » ou « ajouter des vérifs null dans le flow auth ». Les petits PR sont plus faciles à relire et moins susceptibles de cacher des changements de comportement.
5. Activez le strict globalement quand le compteur d'erreurs est bas : une fois que vous êtes descendus à un nombre gérable, activez strict globalement et nettoyez les derniers points chauds.

Exemple : si votre prototype plante parfois sur « Cannot read property 'id' of undefined », le strictness indiquera généralement la chaîne où user peut être null. Le corriger une fois à la frontière auth élimine souvent toute une classe de bugs.

Quels flags de strictness activer en premier (et pourquoi l'ordre compte)

Si vous activez tout d'un coup sur un code désordonné, vous obtenez souvent un mur d'erreurs sans chemin clair. Une meilleure approche est d'activer les vérifs dans un ordre qui garde les corrections locales et les revues compréhensibles.

Une séquence pratique pour les bases de code en désordre est :

• noImplicitAny : vous force à nommer les types flous au lieu d'utiliser silencieusement any
• strictNullChecks : arrête les classiques crashs « cannot read property of undefined »
• strictBindCallApply : attrape les mauvais appels de fonctions (courant dans du code utilitaire copié)
• noImplicitThis : empêche l'utilisation confuse de this dans d'anciens patterns
• useUnknownInCatchVariables : rend la gestion des erreurs plus sûre que d'assumer any

Après chaque flag, corrigez les nouvelles erreurs, puis passez au suivant. Vous gardez les changements petits et vous apprenez quelles parties de l'app sont réellement fragiles.

S'il faut définir "strict": true, cela dépend de votre situation. Si vous avez de bons tests et une petite base de code, c'est acceptable. Pour des apps générées par IA avec des frontières peu claires, activer les flags un par un est généralement plus sûr.

Vous pouvez aussi contrôler le rayon d'impact avec include et exclude. Démarrer par src/ et ignorer temporairement les zones problématiques fait souvent la différence entre « progrès » et « bloqué ».

Traitez certains dossiers différemment :

• sortie générée : excluez‑la et vérifiez la source à la place
• code vendor : ne l'éditez pas ; enveloppez‑le avec des adaptateurs typés
• dossiers legacy : isolez‑les et ajoutez des types seulement là où ils touchent du code nouveau
• mix JS/TS : convertissez d'abord les points d'entrée, pas chaque fichier d'un coup

Patrons de correction qui suppriment les erreurs sans sur‑ingénierie

Les gains les plus rapides viennent de la correction répétée de quelques motifs d'erreurs de façon cohérente.

Commencez par l'implicit any. Ajoutez des types aux frontières d'abord : entrées de fonction, types de retour et tout ce qui traverse une ligne de module (client API, helpers DB, handlers d'événements). Une fois les bords typés, beaucoup d'erreurs internes any disparaissent car TypeScript peut inférer davantage.

Les erreurs null et undefined demandent souvent moins de travail qu'elles n'en ont l'air. Préférez le narrowing plutôt que des types complexes : testez la valeur, retournez tôt et gardez le chemin heureux propre. Quand une valeur par défaut est acceptable, définissez‑la une fois (par exemple name ?? "" pour l'affichage) plutôt que de parsemer des assertions non‑null (!) partout.

Quand vous traitez du JSON façonné par l'IA, utilisez unknown au lieu de any. unknown force une vérification avant utilisation, ce qui est exactement ce que vous voulez pour des payloads non fiables.

Corrections pratiques que vous pouvez appliquer rapidement

• Tapez d'abord les entrées et sorties (fonctions API, utilitaires, composants), puis complétez les internes seulement là où des erreurs persistent.
• Réduisez les valeurs nullables avec if (!value) return ... et de petits garde‑fous comme typeof x === "string".
• Utilisez unknown pour le JSON et les résultats de parsing, puis réduisez avec des vérifications simples avant de lire des propriétés.
• Pour les réponses API, validez ou réduisez ce dont vous avez besoin au lieu de faire confiance à toute la forme du payload.

React et les formulaires sont des points douloureux courants. Typisez les événements (React.ChangeEvent<HTMLInputElement>), gardez les types d'état cohérents et définissez explicitement les props des composants. Un type d'événement correct peut éliminer un nombre surprenant d'erreurs en aval.

Garde‑fous : empêcher le retour en arrière de la strictness

Activer la strictness n'est que la moitié du travail. La partie difficile est de la maintenir quand la prochaine « correction rapide » est tentante, surtout dans du code généré par IA où il est facile de masquer un problème avec any.

Mettez en place des garde‑fous qui rendent le chemin sûr le plus facile. Vous n'avez pas besoin d'un énorme ensemble de règles. Commencez par quelques règles qui correspondent à la façon dont votre équipe casse réellement les types :

• lint contre any et les assertions de type « non sûres » (as unknown as X) sauf dans quelques fichiers autorisés
• signalez les promesses flottantes pour que les erreurs async ne soient pas ignorées
• exigez des types de retour explicites sur des frontières clés (handlers API, auth, accès aux données)
• bannissez // @ts-ignore sauf s'il inclut une raison et une date d'expiration
• surveillez les contournements de noUncheckedIndexedAccess qui masquent de vrais cas null

Gardez les exceptions visibles. Si un fichier doit rester lâche pendant une semaine, marquez‑le et suivez‑le au lieu de laisser le « temporaire » devenir permanent.

Ajoutez une simple porte CI : les builds échouent si de nouvelles erreurs TypeScript apparaissent. Pendant une migration progressive, la version la plus simple est de limiter les vérifications au dossier que vous durcissez d'abord, puis d'élargir la portée au fil du temps.

Vous pouvez aussi ajouter de légers « tests de types » pour les formes qui comptent. Ce sont des vérifications au moment de la compilation qui protègent des structures clés, comme « une Session doit inclure un userId » ou « la réponse API pour /me inclut email et role ». Gardez‑les minuscules.

Enfin, réduisez la duplication en créant un petit dossier de types partagés pour les formes que votre app réinvente sans cesse : User, Session, Role, ApiError. Quand ces types vivent au même endroit, le travail de strictness reste cohérent et le code généré futur a une cible claire à respecter.

Erreurs courantes qui bloquent les migrations (et comment les éviter)

Les projets en mode strict stagnent quand l'équipe rend le compilateur silencieux, mais ne fait pas confiance au comportement runtime. L'objectif n'est pas « faire disparaître les erreurs », c'est moins de bugs en production tout en resserrant les types.

La façon la plus rapide de perdre cette confiance est d'étouffer le compilateur au lieu de corriger la cause.

Les raccourcis qui se retournent contre vous

• Remplacer de vraies corrections par des assertions as. Si vous écrivez as any ou as SomeType à répétition, arrêtez‑vous et demandez ce que la valeur peut être à l'exécution. Validez ou réduisez‑la.
• Utiliser l'assertion non‑null (!) partout. Elle transforme les avertissements de compilation en crashs runtime, surtout autour de l'état d'auth, des données async et des vars d'env optionnelles.
• Construire d'énormes unions pour modéliser des inputs désordonnés. Elles peuvent être « correctes », mais si personne ne peut les lire, elles pourrissent. Normalisez les données à la frontière, puis utilisez une forme interne propre.
• Changements de typage qui modifient aussi le comportement. De petites éditions comme remplacer || par ??, modifier des valeurs par défaut, ou réordonner des vérifs peuvent changer la sortie. Séparez les éditions de typage des edits logiques pour que les revues restent claires.
• Migrer tout dans un seul PR massif. Ça semble efficace jusqu'au fichier dur qui bloque toute la fusion. Découpez le travail en tranches réalisables.

Une habitude pratique : chaque fois que vous ajoutez un cast ou !, laissez‑vous une note et essayez de l'enlever avant la prochaine étape majeure. S'il ne peut pas être enlevé, vous avez probablement besoin d'une vraie vérification runtime.

Un exemple rapide

Supposons qu'un flow d'inscription généré par IA lise req.body.email et que vous étouffiez les erreurs avec as string et email!.trim(). Ça se compile, mais un payload vide lance maintenant une exception. Une correction plus sûre est de vérifier le type et de renvoyer une erreur claire tôt.

Checklist rapide avant d'activer le strict sur une plus large portée

Avant d'élargir les réglages stricts à travers le repo, assurez‑vous que les bases sont stables. Le mode strict change la confiance que vous pouvez avoir dans chaque valeur qui traverse l'app.

Si le projet ne se compile que sur un seul laptop, ou dépend d'une version TypeScript non épinglée, vous perdrez du temps à chasser des erreurs qui ne viennent pas de votre code.

Vérifications pré‑vol qui rendent les déploiements prévisibles :

• L'app se compile proprement aujourd'hui avec une version TypeScript épinglée et la même commande en CI.
• Vous pouvez nommer les 2 à 3 sources principales de bugs runtime (souvent valeurs null, désaccords de réponses API et cas limites d'auth) et vous savez où elles apparaissent.
• Vos frontières principales sont typées, même si l'intérieur est encore désordonné : appels client API, couche d'accès aux données et variables d'environnement.
• Vous pouvez garder les changements petits : chaque PR tient en moins d'une journée et a un thème clair.
• Vous avez une règle claire sur quand any est acceptable, et c'est rare et documenté.

Un scénario simple aide : imaginez que votre prototype déconnecte parfois les utilisateurs après un refresh. Si votre helper auth retourne User | null mais le code en aval le traite comme toujours présent, vous obtenez des crashs aléatoires. Avant d'étendre la strictness, confirmez que vous avez un endroit typé où « user peut être null » est géré, et que le reste de l'app lit depuis cet endroit.

Exemple : durcir un prototype sans ralentir le travail de fonctionnalité

Un fondateur hérite d'un prototype Lovable ou Bolt. Il tourne bien localement, mais en production ça plante après la connexion et certaines pages affichent des données vides. Le code « fonctionne » jusqu'à ce qu'un vrai utilisateur touche un cas limite : champ manquant, null renvoyé par l'API, ou un nombre qui arrive en string.

Au lieu d'activer strict: true partout et de vous noyer dans les erreurs, traitez le mode strict comme une série de petites corrections à fort impact.

Commencez par là où les bugs runtime font le plus mal : la couche API et l'auth. Dans ce prototype, getSession() renvoie parfois undefined, mais l'UI suppose qu'il existe toujours. Les vérifs strictes le dévoilent rapidement.

// Before
const userId = session.user.id

// After
const userId = session?.user?.id
if (!userId) throw new Error("Not authenticated")

Ensuite, passez aux utilitaires partagés, où une correction peut protéger de nombreuses vues. Un exemple courant est le parsing numérique. L'API envoie "42", mais l'app le traite comme un nombre et fait ensuite des calculs qui deviennent NaN.

Un chemin par étapes qui garde habituellement le travail fonctionnel en mouvement :

• ajoutez la strictness d'abord seulement aux fichiers API/auth
• corrigez les erreurs majeures qui correspondent à des crashs réels
• renforcez les helpers partagés (parsing, gestion des dates, config)
• étendez les vérifs strictes aux composants UI en dernier

En chemin, vous rencontrerez des erreurs typiques du code généré : supposer que des champs optionnels existent (profile.name), mélanger des types (string | number), ou retourner des objets partiels. La correction est rarement sophistiquée. Ajoutez des gardes simples, corrigez les types de retour et normalisez les données à la frontière (réponse API -> types propres de l'app).

Ce à quoi ressemble « bien » après le déploiement : moins de crashs en production, règles plus claires sur ce qui peut être undefined, et un petit nombre de propriétaires pour les fichiers centraux (auth, client API, types partagés).

Prochaines étapes : obtenir un plan de migration clair (et de l'aide si besoin)

Le mode strict fonctionne quand vous choisissez un rythme que vous pouvez tenir. Avant de vous engager, décidez ce que « terminé » signifie pour votre app : moins de bugs en production, une auth et un traitement des données plus sûrs, ou une base de code que votre équipe peut changer sans peur.

Si vous voyez encore les mêmes bugs « impossibles » (déconnexions aléatoires, logique d'auth qui diverge entre environnements, secrets qui finissent dans le repo), c'est un signe que les frontières ont besoin d'attention. Un autre drapeau rouge est une architecture spaghetti : fichiers qui font tout, aucune séparation claire, et des corrections de types qui s'étendent sur des dizaines de modules non liés.

Si vous avez hérité d'un prototype généré par IA et souhaitez un avis extérieur, FixMyMess (fixmymess.ai) se concentre sur la transformation d'apps construites par IA en logiciels prêts pour la production en diagnostiquant la base de code, réparant la logique, renforçant la sécurité, refactorant les zones dangereuses et préparant les déploiements. Une première étape pratique est un audit de code gratuit pour obtenir un plan de strict mode progressif sans deviner par où commencer.