[{"data":1,"prerenderedAt":162},["ShallowReactive",2],{"article-\u002Fblog\u002Fclean-architecture-flutter-pourquoi-comment":3},{"id":4,"title":5,"body":6,"brouillon":148,"date":149,"description":150,"extension":151,"image":152,"imageAlt":152,"meta":153,"navigation":154,"path":155,"seo":156,"stem":157,"tags":158,"__hash__":161},"blog\u002Fblog\u002Fclean-architecture-flutter-pourquoi-comment.md","Clean Architecture en Flutter : pourquoi je l'impose sur mes projets au long cours",{"type":7,"value":8,"toc":141},"minimark",[9,26,31,43,53,77,81,87,97,103,107,110,134,138],[10,11,12,13,17,18,21,22,25],"p",{},"Sur un petit projet Flutter, tout mettre dans ",[14,15,16],"code",{},"lib\u002F"," avec quelques dossiers\n",[14,19,20],{},"screens\u002F"," et ",[14,23,24],{},"widgets\u002F"," fonctionne très bien. Puis le projet grandit, un\ndeuxième contributeur arrive (ou vous-même, six mois plus tard), et chaque\nmodification devient une expédition. La Clean Architecture est la réponse\nque j'ai adoptée pour tout projet destiné à vivre plus d'un an ; elle se\npaie dès les premières semaines.",[27,28,30],"h2",{"id":29},"la-structure","La structure",[10,32,33,34,38,39,42],{},"Le principe : séparer ",[35,36,37],"strong",{},"ce que fait l'application"," (le domaine) de\n",[35,40,41],{},"comment elle le fait"," (les détails techniques). Concrètement :",[44,45,50],"pre",{"className":46,"code":48,"language":49},[47],"language-text","lib\u002F\n├── core\u002F                  # transversal : erreurs, réseau, DI, thème\n└── features\u002F\n    └── auth\u002F\n        ├── data\u002F          # sources (API, base locale), repositories impl\n        ├── domain\u002F        # entités, interfaces de repositories, use cases\n        └── presentation\u002F  # blocs\u002Fcubits, écrans, widgets\n","text",[14,51,48],{"__ignoreMap":52},"",[10,54,55,56,59,60,63,64,67,68,71,72,67,74,76],{},"La règle de dépendance est la seule chose à retenir : ",[35,57,58],{},"les flèches\npointent vers le domaine",". La couche ",[14,61,62],{},"presentation"," ne connaît que\n",[14,65,66],{},"domain"," ; ",[14,69,70],{},"data"," implémente les interfaces définies par ",[14,73,66],{},[14,75,66],{},"\nne connaît personne. Votre logique métier ne sait pas si les données\nviennent d'une API REST, d'une base SQLite ou d'un mock de test.",[27,78,80],{"id":79},"ce-que-ça-rapporte-concrètement","Ce que ça rapporte concrètement",[10,82,83,86],{},[35,84,85],{},"La testabilité d'abord."," Un use case qui dépend d'une interface de\nrepository se teste avec un mock en trois lignes, sans réseau, sans base,\nsans widget. C'est ce qui rend possible une vraie couverture de tests sur\nla logique métier, celle qui coûte cher quand elle casse.",[10,88,89,92,93,96],{},[35,90,91],{},"Le remplacement des détails ensuite."," Changer de solution de stockage\nlocal, remplacer un endpoint, passer d'un backend à un autre : si la\nfrontière data\u002Fdomain est propre, c'est un chantier localisé dans ",[14,94,95],{},"data\u002F",",\npas une réécriture.",[10,98,99,102],{},[35,100,101],{},"L'onboarding enfin."," Sur une feature inconnue, on sait toujours où\nregarder : le use case dit ce que fait la feature, le bloc dit comment\nl'écran réagit, le repository dit d'où viennent les données. La structure\nest la documentation.",[27,104,106],{"id":105},"ce-que-ça-coûte-soyons-honnêtes","Ce que ça coûte, soyons honnêtes",[10,108,109],{},"Plus de fichiers, plus d'indirection, et une cérémonie qui peut sembler\nabsurde sur un CRUD simple (une entité, un modèle, un mapper, une\ninterface, une implémentation... pour un écran de liste). Deux\ngarde-fous :",[111,112,113,120],"ul",{},[114,115,116,119],"li",{},[35,117,118],{},"Ne créez un use case que quand il y a de la logique."," Pour un simple\npassage de plat, le bloc peut appeler le repository directement : la\npureté dogmatique est l'ennemie de l'adoption.",[114,121,122,125,126,129,130,133],{},[35,123,124],{},"La structure par feature est plus importante que le nombre de\ncouches."," Si vous ne retenez qu'une chose : isolez chaque feature dans\nson dossier avec ses trois couches, plutôt que des couches globales\n(",[14,127,128],{},"models\u002F",", ",[14,131,132],{},"services\u002F",") qui mélangent toutes les features.",[27,135,137],{"id":136},"la-leçon","La leçon",[10,139,140],{},"La Clean Architecture n'est pas un badge de sérieux, c'est un pari sur la\ndurée : vous acceptez d'écrire un peu plus aujourd'hui pour que le projet\nreste modifiable dans deux ans. Sur un prototype jetable, c'est du\nsur-coût. Sur un produit au long cours (celui qu'on maintient seul le\nsoir, celui qui doit survivre à ses propres pivots), c'est ce qui fait la\ndifférence entre itérer et réécrire.",{"title":52,"searchDepth":142,"depth":142,"links":143},2,[144,145,146,147],{"id":29,"depth":142,"text":30},{"id":79,"depth":142,"text":80},{"id":105,"depth":142,"text":106},{"id":136,"depth":142,"text":137},false,"2026-05-26","Structure core\u002Ffeatures, séparation data\u002Fdomain\u002Fpresentation : ce que la Clean Architecture coûte au démarrage et ce qu'elle rapporte sur la durée.","md",null,{},true,"\u002Fblog\u002Fclean-architecture-flutter-pourquoi-comment",{"title":5,"description":150},"blog\u002Fclean-architecture-flutter-pourquoi-comment",[159,160],"Flutter","Architecture","OXswTRsWKh92HKBIUtQ3ue33rCRjALj3i2egnettd2s",1784652016702]