Comment le code généré par l'IA aide à réduire l'enfermement au framework en phase précoce

Ce que signifie l'enfermement au framework pour les produits précoces

L'enfermement au framework survient quand votre produit devient tellement lié à un framework spécifique (ou à une plateforme fournisseur) que le changer plus tard ressemble à réécrire l'entreprise. Ce n'est pas seulement « on utilise React » ou « on a choisi Django ». C'est quand les conventions du framework imprègnent tout — règles métier, accès aux données, jobs en arrière-plan, authentification, jusqu'à la façon dont vous nommez les fichiers — jusqu'à ce que le framework soit l'app.

À quoi ressemble l'enfermement en termes simples

Une base de code enfermée a souvent des décisions métier incorporées dans des classes, décorateurs, contrôleurs, ORM et middleware spécifiques au framework. Résultat : même de petits changements (changer de framework web, remplacer la couche base de données, séparer un service) deviennent de gros projets risqués.

L'enfermement arrive généralement parce que le chemin le plus rapide au début est de « suivre le framework ». Ce n'est pas fondamentalement mauvais — les frameworks existent pour vous accélérer. Le problème commence quand les patterns du framework deviennent votre conception produit au lieu de rester des détails d'implémentation.

Pourquoi les produits en phase précoce sont les plus vulnérables

Les produits précoces sont construits sous pression : vous courez pour valider une idée, les exigences changent chaque semaine, et une petite équipe gère tout, de l'accueil des utilisateurs à la facturation. Dans cet environnement, il est rationnel de copier-coller des patterns, d'accepter les valeurs par défaut et de laisser le scaffold dicter la structure.

Ces raccourcis initiaux se cumulent vite. Au moment où vous atteignez le « MVP-plus », vous pouvez découvrir qu'une exigence clé (données multi-tenant, pistes d'audit, mode hors ligne, une nouvelle intégration) ne rentre pas dans les choix initiaux sans de fortes entorses.

L'objectif réel : retarder les décisions irréversibles

Il ne s'agit pas d'éviter les frameworks pour toujours. L'objectif est de garder vos options ouvertes suffisamment longtemps pour apprendre ce dont votre produit a vraiment besoin. Les frameworks devraient être des composants remplaçables — pas l'endroit où résident vos règles cœur.

Où le code généré par l'IA intervient (et où il ne suffit pas)

Le code généré par l'IA peut réduire l'enfermement en vous aidant à créer des coutures propres — interfaces, adaptateurs, validations et tests — pour que vous n'ayez pas à « graver » chaque décision de framework juste pour aller vite.

Mais l'IA ne peut pas choisir l'architecture à votre place. Si vous lui demandez « construis la fonctionnalité » sans contraintes, elle reproduira souvent les patterns par défaut du framework. Vous devez définir la direction : séparer la logique métier, isoler les dépendances et concevoir pour le changement — même en expédiant rapidement.

Si vous utilisez un environnement de développement IA (pas seulement un assistant dans l'éditeur), cherchez des fonctionnalités qui facilitent l'application de ces contraintes. Par exemple, Koder.ai inclut un mode de planification pour définir les frontières à l'avance (ex. « le core n'a pas d'imports framework ») et prend en charge l'export du code source — ainsi vous préservez la portabilité et évitez d'être piégé par des choix d'outillage.

Comment l'enfermement arrive (souvent par accident)

L'enfermement au framework commence rarement comme un choix délibéré. Il pousse généralement à travers des dizaines de petites décisions « juste pour livrer » qui semblent inoffensives sur le moment, puis deviennent silencieusement des hypothèses gravées dans votre base de code.

Déclencheurs habituels

Quelques patterns reviennent souvent :

• Couplage fort : les règles métier appellent directement des helpers du framework (requests, sessions, modèles ORM) au lieu de vos propres abstractions fines.
• APIs spécifiques au fournisseur : vous utilisez la solution intégrée la plus simple — queues, auth, stockage, analytics — sans frontière autour.
• Hacks rapides qui collent : un raccourci de prototype devient « temporalement en production », puis personne n'ose y toucher parce que ça marche.

Le code généré par l'IA peut accélérer cet accident : si vous demandez du « code qui marche », il produira souvent l'implémentation la plus idiomatique au framework — excellente pour la vitesse, mais cela peut durcir les dépendances plus vite que prévu.

Où l'enfermement se cache (avec exemples)

L'enfermement se forme souvent dans quelques zones à haute gravité :

• Routage et contrôleurs : les params de route et les hypothèses de middleware se propagent partout (ex. « tout a accès à l'objet request »).
• Authentification/autorisation : rôles, sessions et guards liés aux concepts d'un seul fournisseur compliquent les futurs changements.
• Modèles de données : la logique métier vivant dans des modèles ORM crée un réseau de comportements implicites liés à cet ORM.
• Systèmes de composants UI : quand chaque écran dépend d'une librairie de composants avec son stylage et ses patterns d'état, la remplacer devient une réécriture.

Enfermement accidentel vs intentionnel

S'enfermer n'est pas toujours mauvais. Choisir un framework et s'y appuyer peut être un bon compromis quand la vitesse compte. Le vrai problème, c'est l'enfermement accidentel — quand vous ne voulez pas vous engager, mais votre code ne présente plus de coutures propres où un autre framework (ou un module différent) pourrait se brancher plus tard.

Ce que le code généré par l'IA peut (et ne peut pas) faire

Le code généré par l'IA signifie généralement utiliser des outils comme ChatGPT ou des assistants intégrés pour produire du code à partir d'un prompt : une fonction, un scaffold de fichier, des tests, une suggestion de refactor, ou même une petite fonctionnalité. C'est du pattern-matching rapide plus le contexte que vous fournissez — utile, mais pas magique.

Ce qu'il fait bien (au début)

Quand vous passez du prototype au MVP, l'IA est la plus précieuse pour les tâches chronophages qui ne définissent pas votre produit :

• Scaffolding : créer les dossiers, endpoints CRUD basiques, composants UI simples, fichiers de config et boilerplate.
• Glue code : mapper des données entre modules, câbler des services, écrire de petits adaptateurs et gérer des transformations répétitives.
• Refactors guidés : renommages, extraction d'helpers, séparation de fichiers et nettoyage des duplications — surtout quand vous savez déjà la direction.

Utilisée ainsi, l'IA peut réduire la pression d'enfermement en vous permettant de vous concentrer sur les frontières (règles métier vs glue framework) au lieu de céder au chemin que le framework rend le plus simple.

Ce qu'elle ne peut pas faire (et où l'enfermement s'insinue)

L'IA ne pourra pas fiablement :

• Choisir une architecture pour vous ou comprendre les compromis de maintenance à long terme.
• Repérer le couplage subtil (ex. logique métier incrustée dans des modèles ORM, décorateurs spécifiques au framework disséminés).
• Maintenir la cohérence des patterns dans une base de code qui grandit sans directives fortes.

Un mode d'échec courant est le code qui « fonctionne » mais exploite largement des fonctionnalités pratiques du framework, rendant la migration future plus difficile.

L'état d'esprit adéquat : la sortie IA est un brouillon

Considérez le code généré par l'IA comme la première version d'un junior : utile, mais à relire. Demandez des alternatives, exigez des versions agnostiques au framework et vérifiez que la logique cœur reste portable avant de fusionner quoi que ce soit.

Séparer la logique métier du framework

Si vous voulez rester flexible, traitez votre framework (Next.js, Rails, Django, Flutter, etc.) comme une couche de livraison — la partie qui gère les requêtes HTTP, les écrans, le routage, le câblage auth et le plumbing base de données.

Votre logique métier cœur inclut ce qui doit rester vrai même si vous changez la couche de livraison : règles de tarification, calculs de factures, vérifications d'éligibilité, transitions d'état et politiques comme « seuls les admins peuvent annuler des factures ». Cette logique ne devrait pas « savoir » si elle est déclenchée par un contrôleur web, un bouton mobile ou un job en arrière-plan.

La frontière la plus simple : le code du framework appelle votre code

Une règle pratique qui évite le couplage profond :

Le code du framework appelle votre code, pas l'inverse.

Plutôt qu'une méthode de contrôleur remplie de règles, faites des contrôleurs fins : parser l'entrée → appeler un module use-case → retourner une réponse.

Modules pilotés par use-case (et comment l'IA aide)

Demandez à votre assistant IA de générer la logique métier sous forme de modules nommés d'après les actions produit :

• CreateInvoice
• CancelSubscription
• CalculateShippingQuote

Ces modules doivent accepter des données simples (DTOs) et renvoyer des résultats ou des erreurs de domaine — sans référence aux objets request du framework, aux modèles ORM ou aux widgets UI.

Le code généré par l'IA est particulièrement utile pour extraire la logique déjà présente dans des handlers vers des fonctions/services pures. Collez un endpoint désordonné et demandez : « Refactorise en un service pur CreateInvoice avec validation d'entrée et types de retour clairs ; garde le contrôleur mince. »

Test simple d'odeur

Si vos règles métier importent des paquets du framework (routing, contrôleurs, hooks React, UI mobile), vous mélangez les couches. Inversez la dépendance : gardez les imports dirigés vers le framework, et votre logique cœur restera portable quand vous changerez la couche de livraison.

Utiliser des adaptateurs et interfaces pour garder les options ouvertes

Les adaptateurs sont de petits « traducteurs » entre votre application et un outil/framework spécifique. Votre cœur parle à une interface que vous possédez (un contrat simple comme EmailSender ou PaymentsStore). L'adaptateur gère les détails de comment un framework fait le boulot.

Cela garde vos options ouvertes parce que remplacer un outil devient un changement ciblé : remplacer l'adaptateur, pas tout le produit.

Où les adaptateurs comptent le plus

Quelques endroits où l'enfermement s'immisce tôt :

• Accès à la base de données : encapsuler un ORM ou client DB pour que la logique métier ne dépende pas de la syntaxe des requêtes ou des modèles.
• Clients HTTP : isoler un SDK fournisseur ou une librairie HTTP derrière HttpClient / ApiClient.
• Queues et jobs en arrière-plan : masquer que vous utilisez SQS, RabbitMQ, Redis queues ou un job runner spécifique.
• Fichiers/stockage : abstraire disque local vs S3/GCS, leurs auth, chemins et sémantiques d'upload.

Quand ces appels sont disséminés dans le code, la migration devient « toucher partout ». Avec des adaptateurs, c'est « swap un module ».

Comment l'IA aide : générer des paires, vite

Le code généré par l'IA excelle à produire le scaffold répétitif : une interface + une implémentation concrète.

Par exemple, demandez :

• une interface (Queue) avec les méthodes nécessaires (publish(), subscribe())
• une implémentation (SqsQueueAdapter) qui utilise la librairie choisie
• une seconde implémentation « fake » pour les tests (InMemoryQueue)

Vous relisez encore le design, mais l'IA économise des heures sur le boilerplate.

Gardez les adaptateurs fins et interchangeables

Un bon adaptateur est ennuyeux : logique minimale, erreurs claires et aucune règle métier. Si un adaptateur devient trop malin, vous avez déplacé l'enfermement ailleurs. Mettez la logique métier dans votre cœur ; gardez les adaptateurs comme plomberie remplaçable.

Générer d'abord les contrats : schémas, types et validation

L'enfermement commence souvent par un raccourci simple : vous construisez l'UI, la branchez directement sur la forme de données pratique et réalisez plus tard que chaque écran suppose le même modèle de données spécifique au framework.

L'approche « contract-first » inverse l'ordre. Avant de brancher quoi que ce soit au framework, définissez les contrats dont votre produit dépend — formes requête/réponse, événements et structures de données cœur. Pensez : « À quoi ressemble CreateInvoice ? » et « Que garantit un Invoice ? » plutôt que « Comment mon framework sérialise ceci ? »

Commencer par un schéma, pas un contrôleur

Utilisez un format de schéma portable (OpenAPI, JSON Schema ou schéma GraphQL). Cela devient le centre de gravité stable de votre produit — même si l'UI passe de Next.js à Rails, ou si votre API change de REST à autre chose.

Laisser l'IA générer la colle ennuyeuse (mais critique)

Une fois le schéma en place, l'IA est très utile pour produire des artefacts cohérents :

• Types/interfaces (types TypeScript, data classes Kotlin, etc.) dérivés du schéma
• Validateurs runtime (ex. Zod/Ajv) pour rejeter les données invalides tôt
• Fixtures de tests : exemples de payloads valides et invalides, plus des cas limites que vous n'auriez pas pensé

Cela réduit le couplage au framework parce que votre logique métier dépend d'interfaces internes et d'entrées validées, pas des objects request du framework.

Versionnez les contrats pour permettre un changement progressif

Traitez les contrats comme des fonctionnalités produit : versionnez-les. Même un versionnage léger (ex. /v1 vs /v2, ou invoice.schema.v1.json) vous permet d'évoluer sans tout casser. Vous pouvez supporter les deux versions pendant une transition, migrer progressivement les consommateurs et garder vos options ouvertes si les frameworks changent.

Utiliser l'IA pour construire un filet de sécurité avec des tests

Les tests sont l'un des meilleurs outils anti-enfermement que vous puissiez investir tôt — car de bons tests décrivent le comportement, pas l'implémentation. Si votre suite de tests affirme clairement « pour ces entrées, nous devons produire ces sorties », vous pouvez remplacer un framework plus tard avec beaucoup moins de crainte. Le code change ; le comportement doit rester.

Pourquoi les tests réduisent l'enfermement

L'enfermement se produit souvent quand les règles métier se mélangent aux conventions du framework. Un solide jeu de tests unitaires met ces règles en lumière et les rend portables. Lors d'une migration (ou d'un refactor), vos tests prouvent que vous n'avez rien cassé.

Comment l'IA vous aide à tester ce qu'il faut

L'IA est particulièrement utile pour générer :

• Tests unitaires autour des règles métier (tarification, éligibilité, permissions, transitions d'état)
• Cas limites que vous oubliez quand vous allez vite (entrées vides, fuseaux horaires, arrondis, soumissions en double)
• Tests de régression à partir de rapports de bugs (« ça échouait avant ; ça ne doit plus échouer »)

Workflow pratique : collez une fonction et une courte description de la règle, puis demandez à l'IA de proposer des cas de test, incluant bornes et entrées « bizarres ». Vous révisez encore les cas, mais l'IA vous aide à couvrir plus de scénarios rapidement.

Viser une pyramide de tests (pas une tour de tests)

Pour rester flexible, privilégiez beaucoup de tests unitaires, un plus petit nombre de tests d'intégration et peu de tests end-to-end. Les tests unitaires sont plus rapides, moins coûteux et moins liés à un seul framework.

Éviter les helpers de test lourds du framework

Si vos tests nécessitent le démarrage complet du framework, des décorateurs personnalisés ou des utilitaires de mocking spécifiques à un écosystème, vous vous enfermez silencieusement. Préférez des assertions simples sur des fonctions pures et des services de domaine, et gardez les tests spécifiques au framework isolés et minimes.

Prototyper plus vite sans cimenter la stack

Les produits précoces devraient se comporter comme des expériences : construisez petit, mesurez, puis changez d'orientation selon ce que vous apprenez. Le risque est que votre premier prototype devienne « le produit », et que les choix de framework faits sous contrainte deviennent coûteux à annuler.

Considérer les prototypes comme jetables

Le code généré par l'IA est idéal pour explorer des variantes rapidement : un flux d'onboarding simple en React vs une version rendue côté serveur, deux fournisseurs de paiement différents, ou un modèle de données alternatif pour la même fonctionnalité. Comme l'IA peut produire un scaffold utilisable en minutes, vous pouvez comparer des options sans parier l'avenir sur la première stack livrée.

L'important est l'intention : étiquetez les prototypes comme temporaires, et décidez d'emblée ce qu'ils doivent répondre (ex. « Les utilisateurs complètent-ils l'étape 3 ? »). Une fois la réponse obtenue, le prototype a fait son travail.

Limiter dans le temps, puis supprimer volontairement

Fixez une fenêtre courte — souvent 1–3 jours — pour construire et tester un prototype. À la fin, choisissez :

• Supprimer le code et ne garder que les apprentissages.
• Reconstruire proprement l'approche choisie, en utilisant le prototype comme référence.

Cela évite que la « colle de prototype » (quick fixes, snippets copiés, raccourcis spécifiques au framework) ne devienne un couplage à long terme.

Documenter les décisions en itérant

Au fur et à mesure que vous générez et ajustez du code, tenez un journal léger des décisions : ce que vous avez essayé, ce que vous avez mesuré et pourquoi vous avez choisi (ou rejeté) une direction. Capturez aussi les contraintes (« doit tourner sur l'hébergement existant », « besoin de SOC2 plus tard »). Une simple page dans /docs ou le README du projet suffit — et rend les futurs changements plus planifiés que des réécritures douloureuses.

Refactorer tôt et souvent pour empêcher le couplage profond

Les produits précoces changent chaque semaine : noms, formes de données, même la définition de « utilisateur ». Si vous attendez pour refactorer après la croissance, vos choix de framework durcissent en logique métier.

Le code généré par l'IA peut vous aider à refactorer plus tôt car il est bon pour les modifications répétitives et à faible risque : renommer de façon cohérente, extraire des helpers, réorganiser des fichiers et déplacer du code derrière des frontières plus claires. Bien utilisé, cela réduit le couplage avant qu'il ne devienne structurel.

Cibles de refactor à haute valeur (où l'enfermement se cache)

Commencez par des changements qui facilitent les déplacements futurs de votre comportement cœur :

• Bornes de service : extraire ce que fait le métier en services (ex. BillingService, InventoryService) qui n'importent ni contrôleurs, ni modèles ORM, ni objets request.
• DTOs / view models : introduire des formes de données simples pour les entrées/sorties au lieu de passer des modèles framework partout. Gardez le mapping aux bords.
• Gestion des erreurs : remplacez les exceptions spécifiques au framework disséminées par vos propres types d'erreur (ex. NotFound, ValidationError) et traduisez-les à la frontière.

Petites étapes réversibles (avec tests après chacune)

Refactorez par incréments que vous pouvez annuler :

1. Ajoutez ou mettez à jour des tests autour du comportement que vous touchez.
2. Demandez à l'IA de faire un seul changement (renommer, extraire, déplacer) et d'expliquer le diff.
3. Lancez les tests immédiatement ; puis passez à l'étape suivante.

Ce rythme « un changement + tests verts » garde l'IA utile sans la laisser dériver.

Éviter les réécritures massives

Ne demandez pas à l'IA de faire d'énormes « modernisations d'architecture » sur tout le repo. Les gros refactors générés mélangent souvent changements de style et de comportement, rendant les bugs difficiles à repérer. Si le diff est trop grand pour être relu, il est trop grand pour être fiable.

Planifier la migration même si vous ne migrez jamais

Planifier une migration n'est pas du pessimisme — c'est de l'assurance. Les produits précoces changent vite : vous pourriez changer de framework, scinder un monolithe ou passer à une auth conforme. Si vous concevez avec une sortie en tête, vous obtenez souvent des frontières plus propres même si vous restez sur place.

Les parties les plus difficiles à déplacer plus tard

Une migration échoue (ou coûte cher) quand les éléments les plus emmêlés sont partout :

• Gestion d'état : état UI qui fuit dans la logique métier, ou stores spécifiques au framework devenant source de vérité.
• Couche de données : modèles ORM doublant de contrat API, requêtes éparpillées sur les écrans et migrations liées aux conventions du framework.
• Auth et permissions : gestion de session, middleware et vérifications d'autorisation disséminées dans contrôleurs/composants.

Ces domaines sont collants car ils touchent beaucoup de fichiers et de petites incohérences se multiplient.

Utiliser l'IA pour rédiger un plan de migration réaliste

Le code généré par l'IA sert ici — pas pour « faire la migration », mais pour créer de la structure :

• Rédigez une checklist de migration adaptée à votre stack (routes, état, accès aux données, flows auth). Commencez par un template comme /blog/migration-checklist.
• Proposez une séquence incrémentale (« migrer l'auth d'abord, puis l'accès aux données, puis l'UI »), incluant ce qu'il faut garder stable (contrats, IDs, noms d'événements).
• Générez un tableau des risques (ce qui peut casser, comment le détecter, étapes de rollback) que vous transformerez en tickets.

L'important est de demander des étapes et des invariants, pas juste du code.

Construire un chemin « strangler »

Au lieu de tout réécrire, faites tourner un nouveau module à côté de l'ancien :

• Créez un nouveau service/module avec les mêmes contrats externes (schémas, endpoints, événements).
• Orientez un faible pourcentage de trafic — ou une seule fonctionnalité — vers le nouveau chemin.
• Étendez la couverture jusqu'à ce que l'ancien module devienne une coquille que vous pouvez supprimer.

Cette approche marche mieux quand les frontières sont déjà claires. Pour des patterns et exemples, voyez /blog/strangler-pattern et /blog/framework-agnostic-architecture.

Même si vous ne migrez jamais, vous y gagnez : moins de dépendances cachées, des contrats plus clairs et moins de dette technique surprise.

Gardefous pratiques pour le code généré par l'IA

L'IA peut livrer beaucoup de code vite — et elle peut aussi propager les hypothèses d'un framework si vous ne fixez pas des limites. L'objectif n'est pas de « moins faire confiance », mais de rendre la revue facile et d'empêcher le couplage accidentel du cœur produit à une stack donnée.

Vérifications de revue qui évitent l'enfermement caché

Utilisez une checklist courte et répétable pour chaque PR incluant du code assisté par l'IA :

• Pas de types/framework dans les modules core (pas de Request, DbContext, ActiveRecord, Widget, etc.). Le core doit parler en vos termes : Order, Invoice, UserId.
• Globals et singletons minimaux. Si ça ne peut pas être construit par paramètres, c'est plus dur à tester et à déplacer.
• Dépendances dirigées vers l'intérieur. UI/API importent le core ; le core n'importe pas l'UI/API/framework.
• La sérialisation reste aux bords. Convertir JSON/HTTP/form doit se faire dans les adaptateurs, pas dans la logique métier.

Standards légers que l'IA peut suivre

Gardez des standards simples à appliquer :

• Définissez des frontières de dossiers comme core/, adapters/, app/ et une règle : « core n'a aucun import framework ».
• Utilisez une nomenclature qui signale l'intention : *Service (logique métier), *Repository (interface), *Adapter (collage framework).
• Ajoutez un petit outil de règle de dépendance (ou un script minimal) pour faire échouer les builds quand des imports interdits apparaissent.

Hygiène des prompts : explicitez les contraintes

Quand vous demandez du code à l'IA, incluez :

• le dossier cible (ex. « générer du code pour /core sans imports framework »),
• les dépendances autorisées,
• un petit exemple de votre style d'interface préféré.

C'est aussi l'endroit où des plateformes IA avec un workflow « plan then build » aident. Sur Koder.ai, par exemple, vous pouvez décrire ces contraintes en mode planification puis générer le code en conservant des snapshots et des rollback pour garder les changements relisables quand le diff est grand.

Automatiser l'application dès le départ

Mettez en place formateurs/linter et un CI basique dès le jour un (même un pipeline « lint + test »). Attrapez le couplage immédiatement, avant que ça ne devienne « comment le projet fonctionne ».

Checklist : rester flexible pendant les 90 premiers jours

Rester « flexible vis-à-vis du framework » n'est pas éviter les frameworks — c'est les utiliser pour aller vite tout en gardant vos coûts de sortie prévisibles. Le code généré par l'IA peut vous faire avancer rapidement, mais la flexibilité vient de l'endroit où vous placez les coutures.

Tactiques centrales qui retardent l'enfermement

Gardez ces quatre tactiques en tête dès le jour 1 :

• Séparer la logique métier du framework : placez règles de tarification, règles d'onboarding et permissions dans des modules/services purs qui n'importent pas de paquets spécifiques au framework.
• Utiliser adaptateurs et interfaces : considérez le framework, la base de données, les queues, l'auth et l'email comme des prises remplaçables. Votre app appelle une interface ; un adaptateur l'implémente.
• Générer les contrats d'abord : définissez schémas/types/validateurs avant de câbler les endpoints. L'IA est excellente pour générer des types et validateurs cohérents.
• Utiliser l'IA pour construire un filet de sécurité avec des tests : tests unitaires à haute valeur autour des règles métier, plus quelques tests d'intégration, rendent les refactors et migrations réalistes.

Checklist semaine 1 (pratique et rapide)

À viser avant que la base de code ne grossisse :

1. Créez un dossier /core (ou équivalent) qui contient la logique métier sans imports framework.
2. Définissez contrats API et domaine (schémas/types) et générez des validateurs.
3. Ajoutez des interfaces pour stockage, auth, email, paiements et implémentez les premiers adaptateurs.
4. Demandez à l'IA de générer des tests unitaires pour les 5 règles principales (facturation, permissions, éligibilité, etc.) et exécutez-les en CI.
5. Établissez la règle : le code framework vit aux bords (contrôleurs/routes/vues), pas dans la logique cœur.

Jusqu'au jour 90 (garder les sorties abordables)

Revisitez les coutures toutes les 1–2 semaines :

• Refactorez la logique dupliquée dans des services core.
• Gardez les adaptateurs fins ; résistez au « juste un raccourci » qui fuit des objets framework dans le core.
• Quand l'IA génère du code, exigez qu'il suive vos contrats et interfaces, et rejetez les couplages directs.

Si vous évaluez des options pour passer du prototype au MVP tout en restant portable, vous pouvez consulter des plans et contraintes sur /pricing.