Riverpod vs Bloc Comparaison

Une architecture de providers sûre à la compilation, avec peu de code et en évolution rapide

VS
Bloc

Un contrat architectural mature et porté par une large communauté, qui impose le flux event/state

10 min de lectureCross-Platform

Verdict rapide

Il n'existe pas de « mauvais choix » — les deux sont éprouvés et sous licence MIT. Pour une équipe de 1 à 5 personnes en itération rapide : Riverpod, avec peu de boilerplate, une génération de code optionnelle et un rythme de versions très actif (3.4.3, le 2026-09-03). Pour un projet d'entreprise multi-équipes exigeant un flux d'événements auditable : Bloc, avec la séparation event/state obligatoire et BlocObserver — mais la dernière version de flutter_bloc date du 2025-05-02, à surveiller. La question n'est pas « lequel est le meilleur », mais « quel niveau de discipline doit être imposé de l'extérieur ».

RiverpodBloc
Lire le verdict complet

Comparaison des scores

Chargement du graphique...

Notation détaillée

Notation détaillée: Riverpod et Bloc — notes sur 10, catégorie par catégorie
CatégorieRiverpodBloc
Performance
8/10
8/10
Facilité d'apprentissage
8/10
6/10
Écosystème
7/10
9/10
Communauté
7/10
9/10
Marché de l'emploi
7/10
7/10
Pérennité
8/10
7/10

Avantages & Inconvénients

Riverpod

Avantages

  • La génération de code est entièrement optionnelle — on peut aussi écrire avec la syntaxe classique
  • Courbe d'apprentissage réduite autour d'un concept unique (Provider/Ref)
  • Tests unitaires isolés avec ProviderContainer.test(), sans package supplémentaire
  • Les providers peuvent être lus sans dépendre de BuildContext
  • L'extension DevTools est fournie avec le package riverpod (extension/devtools, v1.0.0)
  • Mutations expérimentales avec Riverpod 3.0 et persistance hors ligne avec riverpod_sqflite
  • Usage actif élevé avec 2 970 654 téléchargements par mois sur pub.dev
  • Rythme de développement très actif avec la version 3.4.3 sortie le 2026-09-03

Inconvénients

  • L'équipe doit elle-même choisir entre la syntaxe classique et la syntaxe avec génération de code
  • Le nombre d'étoiles GitHub (7 375) est derrière celui de Bloc — une communauté plus jeune
  • Le pub point pub.dev (140/160) est derrière le score parfait de Bloc
  • N'impose pas de contrat architectural — dans une grande équipe, la cohérence dépend de la discipline de l'équipe
  • Une dépendance à la chaîne build_runner apparaît dès que le codegen est utilisé
  • La « unified syntax » sans codegen n'en est encore qu'au stade de la RFC, pas stable

Idéal pour

Petites équipes de 1 à 5 personnes et itération rapide MVP/startupProjets utilisant déjà Freezed ou json_serializableApplications ayant des besoins offline-first ou de mutation de state expérimentaleÉquipes recherchant peu de boilerplate et un apprentissage rapide via un concept uniqueProjets donnant la priorité à une chaîne de dépendances active et à jour

Bloc

Avantages

  • La séparation event/state est obligatoire — aucune mutation de state arbitraire n'est possible
  • Chaque transition de state peut être journalisée de façon centralisée via BlocObserver
  • Architecture à trois couches (Presentation/Business Logic/Data) officiellement documentée
  • Score pub.dev parfait de 160/160 et badge officiel « Flutter Favorite »
  • Une communauté plus large et établie avec 12 482 étoiles sur GitHub
  • Des tests cohérents et lisibles selon le modèle build/act/expect grâce à blocTest
  • Composition multi-couches et multi-repository officiellement prise en charge via Bloc-to-Bloc Communication
  • Mature pour la cible web sur pub.dev avec les étiquettes wasm-ready et platform:web

Inconvénients

  • Même pour un écran simple, il faut écrire des classes event/state séparées
  • Il faut apprendre le package bloc_test et un DSL de test dédié (blocTest)
  • La dernière version de flutter_bloc date du 2025-05-02 — aucune nouvelle version depuis plus de 16 mois
  • Pas de générateur de code officiel basé sur build_runner ; la réduction du boilerplate repose sur la génération de modèles des extensions officielles IntelliJ/VSCode
  • Dépendance structurelle incontournable au package provider (base de BlocProvider)
  • La mise en place du constructeur Repository/DataProvider n'est pas clairement illustrée dans la documentation officielle

Idéal pour

Projets d'entreprise multi-modules avec 10 développeurs ou plusSecteurs régulés exigeant auditabilité/conformité (fintech, santé)Projets nécessitant un contrat architectural imposé dans des équipes majoritairement juniorÉquipes voulant garantir automatiquement la cohérence des tests en code reviewProjets voulant s'appuyer sur une communauté mature et large à long terme

Comparaison de code

Riverpod
// Riverpod - Liste d'utilisateurs (avec génération de code)
// Source : modèle de la documentation officielle riverpod.dev
import 'package:flutter_riverpod/flutter_riverpod.dart';
import 'package:riverpod_annotation/riverpod_annotation.dart';

part 'user_list_provider.g.dart';

@riverpod
Future<List<User>> userList(Ref ref, {required int page}) async {
  final repository = ref.watch(userRepositoryProvider);
  return repository.fetchUsers(page: page);
}

class UserListScreen extends ConsumerWidget {
  const UserListScreen({super.key});

  @override
  Widget build(BuildContext context, WidgetRef ref) {
    final usersAsync = ref.watch(userListProvider(page: 1));

    return usersAsync.when(
      data: (users) => ListView.builder(
        itemCount: users.length,
        itemBuilder: (context, index) => ListTile(
          title: Text(users[index].name),
          subtitle: Text(users[index].email),
        ),
      ),
      loading: () => const Center(child: CircularProgressIndicator()),
      error: (error, stack) => Center(child: Text('Hata: $error')),
    );
  }
}

// Alternative en syntaxe classique sans codegen (documentation officielle, optionnel) :
final userListClassicProvider =
    FutureProvider.autoDispose.family<List<User>, int>((ref, page) async {
  final repository = ref.watch(userRepositoryProvider);
  return repository.fetchUsers(page: page);
});
Bloc
// Bloc - Liste d'utilisateurs (Event/State + Repository)
// Source : modèle Core Concepts officiel de bloclibrary.dev
import 'package:flutter_bloc/flutter_bloc.dart';

sealed class UserListEvent {}

class FetchUsers extends UserListEvent {
  FetchUsers({required this.page});
  final int page;
}

sealed class UserListState {}

class UserListInitial extends UserListState {}

class UserListLoading extends UserListState {}

class UserListLoaded extends UserListState {
  UserListLoaded({required this.users});
  final List<User> users;
}

class UserListError extends UserListState {
  UserListError({required this.message});
  final String message;
}

class UserListBloc extends Bloc<UserListEvent, UserListState> {
  UserListBloc({required this.repository}) : super(UserListInitial()) {
    on<FetchUsers>(_onFetchUsers);
  }

  final UserRepository repository;

  Future<void> _onFetchUsers(
    FetchUsers event,
    Emitter<UserListState> emit,
  ) async {
    emit(UserListLoading());
    try {
      final users = await repository.fetchUsers(page: event.page);
      emit(UserListLoaded(users: users));
    } catch (error) {
      emit(UserListError(message: error.toString()));
    }
  }
}

Conclusion

Il n'existe pas de « mauvais choix » — les deux sont éprouvés et sous licence MIT. Pour une équipe de 1 à 5 personnes en itération rapide : Riverpod, avec peu de boilerplate, une génération de code optionnelle et un rythme de versions très actif (3.4.3, le 2026-09-03). Pour un projet d'entreprise multi-équipes exigeant un flux d'événements auditable : Bloc, avec la séparation event/state obligatoire et BlocObserver — mais la dernière version de flutter_bloc date du 2025-05-02, à surveiller. La question n'est pas « lequel est le meilleur », mais « quel niveau de discipline doit être imposé de l'extérieur ».

Obtenir une consultation gratuite
FAQ

Questions fréquentes

Il n'y a pas de réponse unique. Si vous êtes une équipe de 1 à 5 personnes en itération rapide et que vous pouvez régler les décisions d'architecture par une simple discussion interne, Riverpod (peu de boilerplate, génération de code optionnelle, tests sans BuildContext) convient mieux. Pour un projet d'entreprise multi-équipes exigeant un flux d'événements auditable et un contrat strict (secteurs régulés comme la fintech ou la santé), Bloc offre un terrain plus sûr en imposant la séparation event/state et la journalisation centralisée via BlocObserver.

Articles de blog associés

Voir tous les articles

Projets associés

Voir tous les projets
Toutes les comparaisons