La plupart des conseils sur « l’architecture Flutter » se résument soit à un template de 40 fichiers, soit à un haussement d’épaules. Après quelques années à livrer des applications en production, voici ce que j’aurais aimé qu’on me dise à mes débuts.
Raisonnez en couches, pas en dossiers
Les dossiers n’ont aucune importance. Ce qui compte, c’est la direction des dépendances. Gardez trois couches et faites en sorte que les dépendances ne pointent que vers l’intérieur :
- Présentation — widgets, état, navigation.
- Domaine — entités et cas d’usage. Aucun import Flutter. Jamais.
- Data — repositories, API, stockage local.
Un cas d’usage n’est rien d’autre qu’une fonction. Résistez à l’envie d’en faire une classe de 200 lignes :
class GetActiveRides { GetActiveRides(this._repo); final RideRepository _repo;
Future<List<Ride>> call() => _repo.activeRides();}Gardez un état ennuyeux
Quel que soit votre gestionnaire d’état — Riverpod, Bloc, signals — la règle ne change pas : l’état se dérive, les effets sont explicites. Si vous ne pouvez pas dire où se produit un effet de bord juste en lisant le fichier, c’est que l’abstraction est mauvaise.
final activeRidesProvider = FutureProvider.autoDispose((ref) { return ref.watch(getActiveRidesProvider)();});Les petites abstractions qui valent le coup
- Un type
Result<T>au lieu de lever des exceptions d’une couche à l’autre. - Une seule hiérarchie
AppException, mappée à la frontière de la couche data. - Un unique endroit qui transforme les modèles d’API en entités du domaine.
C’est à peu près tout. L’architecture, ce sont les décisions coûteuses à changer plus tard — mettez votre discipline là-dessus, et restez souple partout ailleurs.