flutter_bloc ou Riverpod en 2026 : comment choisir vraiment

C'est la question rituelle de tout nouveau projet Flutter, et les débats en ligne la traitent comme une guerre de religion. En 2026, la vraie réponse est plus ennuyeuse : les deux sont matures, maintenus et capables de porter n'importe quelle application. Le choix ne se fait pas sur la puissance, mais sur l'adéquation à votre équipe et à votre projet. Voici les critères qui comptent.

Ce qui les distingue vraiment

flutter_bloc impose une discipline événementielle : l'interface émet des événements (ou appelle des méthodes de Cubit), la logique produit des états, l'interface reconstruit. Tout est explicite, séquencé, traçable. C'est verbeux, et c'est le but : le flux de données a une seule forme possible, qu'on retrouve identique dans chaque feature.

Riverpod est un graphe de dépendances réactif : des providers qui exposent des valeurs, se recalculent quand leurs dépendances changent, et que l'interface observe. C'est plus concis, plus flexible, et la combinaison de providers (un provider qui filtre les résultats d'un autre) est d'une élégance que bloc n'égale pas.

Les critères de décision

La taille et la rotation de l'équipe. C'est, à mon avis, le critère n°1. La rigidité de bloc est une force quand plusieurs personnes (ou plusieurs générations de contributeurs) touchent au code : impossible de faire « créatif », le pattern canalise tout le monde. La liberté de Riverpod demande plus de conventions d'équipe pour ne pas dériver en spaghetti de providers.

Le rapport à la testabilité. Les deux se testent très bien, mais différemment : bloc excelle au test de séquences (tel événement produit tels états, dans cet ordre ; blocTest rend cela trivial), Riverpod au test d'assemblage (remplacer un provider par un mock via les overrides). Si votre logique métier est faite de processus séquencés (authentification multi-étapes, synchronisation, machines à états), bloc raconte mieux cette histoire.

La nature de l'état. Beaucoup d'états dérivés et combinés (filtres, recherches, agrégations réactives) : avantage Riverpod. Des flux métier avec transitions explicites et effets contrôlés : avantage bloc.

L'existant. Sur un projet en cours, la meilleure solution est presque toujours celle déjà en place. Une migration de state management ne s'amortit à peu près jamais.

Mon choix, et pourquoi il ne devrait pas être le vôtre par défaut

Sur mes projets au long cours, j'ai choisi flutter_bloc (Cubit pour le simple, BLoC pour les flux complexes), adossé à une Clean Architecture. Raison principale : un projet mené en solo avec l'assistance d'outils d'IA bénéficie énormément d'un pattern ultra-régulier : chaque feature a la même forme, ce qui rend le code prévisible à générer, à relire et à tester. La verbosité, dans ce contexte, est un atout de contrôle.

Mais si votre équipe est petite, expérimentée, et que votre application vit d'états dérivés, Riverpod est probablement le choix plus confortable. Les deux réponses sont correctes ; c'est la justification qui doit être la vôtre.

La leçon

Choisissez sur vos contraintes, écrivez la décision quelque part (un court ADR suffit), et n'y revenez plus. L'énergie dépensée à re-débattre du state management est de l'énergie volée aux fonctionnalités.