Projet complet

Onze leçons ont chacune isolé une difficulté. C'est nécessaire pour apprendre, et insuffisant pour savoir construire : dans une application réelle, ces briques interagissent, et c'est cette interaction qui pose les questions difficiles. Où placer le code qui décide de lire le cache plutôt que le réseau ? Comment un formulaire prévient-il la liste qu'un élément a changé ? Que voit l'utilisateur pendant qu'une écriture locale attend une confirmation distante ?

Nous allons construire Carnet, un gestionnaire de tâches synchronisé. Le choix n'est pas anodin : c'est le plus petit domaine qui exige simultanément une base locale, une API, un état partagé entre écrans, un formulaire validé et un fonctionnement hors ligne. Une application de démonstration plus jolie mais purement locale n'apprendrait rien de plus que la leçon 4.

L'accent est mis sur l'architecture, c'est-à-dire sur les frontières entre les couches. Un code Flutter devient ingérable pour une raison presque toujours identique : la logique métier finit dans les build, les appels réseau dans les onPressed, et le SQL dans les widgets. Séparer coûte quelques fichiers de plus au départ et permet de tester, de modifier et de comprendre ensuite.