Clone Netflix.
Année : 2026
Une interface FlutterFlow sur une base qui vérifie les droits ligne par ligne
Fiche
- Rôle
- Conception et développement
- Équipe
- Seul, en formation Alegria Academy
- Période
- Octobre 2026
- Statut
- Rendu
- Code
- Projet pédagogique
- Captures
- Écrans de l’application extraits de la vidéo de présentation du projet et posés dans un cadre d’iPhone ; règles et triggers capturés dans Supabase.
En bref
Un exercice de la formation Alegria Academy, que j’ai réalisé seul : reproduire le parcours de Netflix avec FlutterFlow pour l’interface, et Supabase pour la base, l’authentification et le stockage des affiches. La logique est écrite dans la base PostgreSQL : un schéma relationnel, des règles de sécurité au niveau des lignes et des triggers qui complètent les données d’eux-mêmes.
Point de départ
L’exercice imposait un outil sans code pour l’interface. Or une règle posée dans l’interface se contourne en appelant la base directement. J’ai donc placé les règles dans la base.
Contraintes
- Des droits qui tiennent même si l’application est contournée.
- Des affiches envoyées par les utilisateurs, à limiter en taille et en format.
Livrables
- Les écrans de l’application : présentation, inscription et connexion, choix du profil, accueil par catégories, fiche d’un film, recherche et ajout d’un film.
- Le schéma de la base : utilisateurs, films, catégories et profils de visionnage.
- Neuf règles de sécurité au niveau des lignes et quatre triggers.
- Des fonctions Dart personnalisées : couleur de fond tirée de la base, recherche insensible à la casse.
- Cinq scripts SQL versionnés, qui créent le schéma, les règles de sécurité, les triggers et les données de démonstration.
Architecture
FlutterFlow génère l’application Flutter. Supabase porte la base PostgreSQL, l’authentification et le stockage des affiches. Les droits sont appliqués dans la base par des politiques RLS, et des triggers complètent les données à l’inscription et à chaque ajout ou modification d’un film.
La base compte quatre tables : les utilisateurs, liés au compte d’authentification et supprimés avec lui ; les catégories ; les films ; les profils de visionnage. La couleur de chaque film est contrôlée par la base (un code hexadécimal valide ou rien), et deux index servent les listes par catégorie et par date d’ajout.
Stack technique
- Langages
- Interface
- Données et stockage
- Authentification
- Règles en base
Décisions
-
Le parcours complet d’un abonné
L’application enchaîne l’écran de présentation, l’inscription et la connexion, avec validation des champs, puis le choix du profil et la fiche d’un film avec sa bande-annonce. La couleur de fond de chaque fiche est lue dans la base.
Écran de présentation, création de compte avec validation des champs, choix du profil. -
Recherche, tri et ajout de films
La recherche filtre à chaque lettre, sans tenir compte des majuscules, avec un tri par date d’ajout ou par ordre alphabétique. Un formulaire ajoute un film, son affiche et sa catégorie.
La recherche triée de A à Z, et le formulaire d’ajout d’un film. -
Chacun ne modifie que ses propres données
Chaque utilisateur ne lit et ne modifie que sa propre fiche et ses propres profils. Le catalogue est lisible par tout utilisateur connecté ; un film ne peut être ajouté qu’au nom de l’utilisateur connecté, et seul son auteur peut le modifier ou le supprimer.
Ces règles sont vérifiées par PostgreSQL à chaque requête : elles s’appliquent donc aussi à un appel envoyé à la base sans passer par l’application. Les affiches, elles, vont dans un espace de stockage qui limite la taille et le format des fichiers.
Les règles de sécurité au niveau des lignes, dans Supabase. -
Une base qui se complète d’elle-même
À l’inscription, un trigger crée la fiche de l’utilisateur et son premier profil de visionnage, et un autre reporte ensuite son nom sur ce profil. Un troisième convertit le nom de catégorie envoyé par le formulaire en clé étrangère, car la liste déroulante de FlutterFlow ne manipule que du texte ; un quatrième donne au film une affiche par défaut quand il n’en a pas. L’interface n’a donc rien à calculer.
Trois des quatre triggers, dans Supabase ; celui de l’inscription est posé sur la table des comptes d’authentification.
Résultats
- 9
- règles de sécurité au niveau des lignes, sur quatre tables et le stockage
- 5
- scripts SQL versionnés : schéma, données de démonstration et triggers
- 14
- films dans le catalogue de démonstration
Projet rendu avec une vidéo de présentation de l’application.