Blog
Architecture propre en Flutter : Clean Architecture et repository pattern
8 min de lecture
Comment structurer une app Flutter scalable avec la Clean Architecture, le repository pattern et une séparation claire des responsabilités.
La Clean Architecture n'est pas une idée propre à Flutter. Popularisée par Robert C. Martin, elle s'applique à tout système logiciel qui doit évoluer dans le temps. En développement mobile et particulièrement en Flutter l'absence d'architecture se fait vite sentir : des widgets qui contiennent de la logique métier, des appels API dispersés partout, des états impossibles à tester.
Voici comment j'applique ces principes dans mes projets Flutter, de façon pragmatique et sans over-engineering.
Les trois couches fondamentales
La Clean Architecture divise le code en couches concentriques. Dans une app Flutter, j'utilise trois couches principales.
La couche Data est responsable de toute communication avec l'extérieur : Firebase, REST APIs, SQLite, SharedPreferences. Elle contient les implémentations concrètes des repositories, les modèles de données (DTOs), et les data sources. Elle ne contient pas de logique métier.
La couche Domain est le cœur de l'application. Elle contient les entités (les objets métier purs, sans annotation Firebase ou JSON), les interfaces de repository (abstractions), et les use cases (la logique métier unitaire). Cette couche ne dépend de rien d'autre ni Flutter, ni Firebase, ni HTTP.
La couche Presentation gère l'UI et l'état. Avec Riverpod, ce sont les Notifiers qui orchestrent les use cases et exposent l'état aux widgets. Les widgets eux-mêmes ne contiennent que de la logique de rendu.
Le repository pattern en pratique
Le repository pattern est la clé de voûte de cette architecture. Un repository abstrait définit le contrat : quelles opérations sont disponibles (getUser, saveOrder, fetchProducts). L'implémentation concrète (FirebaseUserRepository, MockUserRepository) respecte ce contrat.
Avantage immédiat : les tests unitaires. Plutôt que de mocker Firebase directement (complexe et fragile), on crée un MockUserRepository qui retourne des données prédéfinies. Les use cases et les Notifiers travaillent avec l'interface abstraite ils ne savent pas si la donnée vient de Firebase ou d'un fichier JSON de test.
Avantage à moyen terme : la migration. Si vous décidez de passer de Firebase à Supabase, vous réécrivez uniquement l'implémentation du repository. Le domain et la presentation ne bougent pas. C'est un changement qui prend des heures plutôt que des semaines.
Les use cases : de la logique, pas autre chose
Un use case représente une action métier unique : GetUserProfileUseCase, PlaceOrderUseCase, SyncOfflineDataUseCase. Il prend des paramètres en entrée et retourne un résultat.
Leur avantage principal : la testabilité. Un use case sans UI et sans framework se teste avec des tests unitaires purs, rapides, sans setUp complexe. Si PlaceOrderUseCase passe ses tests, vous savez que la logique de commande est correcte indépendamment du rendu.
Un use case ne devrait faire qu'une chose. Si vous vous retrouvez à nommer un use case ManageUserAndNotifyAndUpdateCacheUseCase, c'est le signe qu'il faut le diviser. La règle de responsabilité unique s'applique ici strictement.
Quand appliquer cette architecture ?
La Clean Architecture a un coût d'entrée réel : plus de fichiers, plus de couches, plus de code initial. Sur un projet de 2 semaines pour une startup qui veut un MVP, elle est souvent disproportionnée. FlutterFlow avec quelques Custom Actions fait le travail plus vite.
Mais dès que le projet dépasse 4 à 6 semaines de développement, qu'une équipe est impliquée, que des features s'accumulent, ou que les tests commencent à compter l'investissement initial est largement rentabilisé.
Je l'applique sur : les apps avec logique métier riche, les projets destinés à vivre plusieurs années, les teams de 2 développeurs ou plus. C'est aussi très compatible avec KMP : la couche domain d'un projet Flutter peut être migrée dans un module KMP partagé si le projet évolue vers une cible multi-plateforme natif.
Pour conclure
La Clean Architecture en Flutter n'est pas une religion c'est un outil. Adapté aux bons projets, appliqué avec pragmatisme, il transforme une app fragile en un système qui peut évoluer, se tester et s'améliorer sans crainte. La question n'est pas « est-ce que j'applique la Clean Architecture ? », mais « jusqu'où l'applique-je sur ce projet précis ? ».
Discuter d'un projet
Un projet Flutter, FlutterFlow ou KMP en tête ?
Un call de 20 minutes pour cadrer votre besoin et vous proposer un plan d'action concret.