L’idée venait du groupe. Mais une idée de groupe sans quelqu’un qui s’en charge, ça reste une slide dans un deck. Je me suis dit que c’était moi : reprendre le concept, le resserrer, et le traduire en produit. Objectif clair — une app que les étudiants MMI Montaigne peuvent télécharger, utiliser, et qui matérialise la campagne avant même le vote.
Pourquoi Flutter, pourquoi maintenant
J’avais besoin d’iOS et Android avec un seul codebase : pas le temps de doubler le travail en deux stacks natives pour une deadline de campagne. Flutter + Dart, ça collait : UI déclarative, hot reload pour itérer vite, et une chaîne de build documentée jusqu’au store. Ce n’était pas mon premier « Hello World » en Dart, mais c’était de loin le projet le plus complet que je montais seul dessus — auth, temps réel, paiements symboliques côté boutique, navigation profonde entre cinq gros modules.
Le compromis qu’on accepte avec Flutter web (pour la démo embarquée sur le portfolio) : poids du bundle, CanvasKit, et comportements iframe sur mobile. Le binaire iOS/Android reste la cible principale ; le web sert surtout à montrer l’UI sans forcer l’installation.
Stack côté backend : Firebase sans sur-ingénierie
J’ai posé Firebase comme socle : Authentication pour les comptes promo, Cloud Firestore pour tout ce qui doit vivre en temps réel (posts du feed, likes, commentaires, événements du calendrier), et Firebase Storage pour les médias lourds (images des posts, visuels boutique). L’intérêt, c’est la cohérence : les listeners Firestore propagent les changements aux clients sans que je recâble du polling.
Les règles de sécurité Firestore, je les ai écrites tôt — c’est le genre de truc qui te mord les chevilles si tu codes d’abord « open bar » puis que tu essaies de refermer. Lecture largement ouverte pour le contenu public de campagne, écriture réservée aux rôles qui ont le droit de publier, validation des champs obligatoires côté règles quand c’était possible pour éviter des documents corrompus.
# Schéma mental (simplifié)
posts/{postId} → auteur, texte, imageUrl, timestamps, likeCount
events/{eventId} → titre, date, lieu, description
users/{uid} → displayName, photoUrl, pointsFidelite, roleLes cinq modules — ce que ça implique techniquement
Feed social : liste paginée ou infinite scroll selon ce que le design imposait, cartes avec image + texte riche, interaction like en optimistic UI puis rollback si la règle Firestore refuse. Le détail qui compte en campagne : la latence perçue — si le cœur apparaît instantanément et que la synchro suit, l’utilisateur a l’impression que « ça marche ».
Boutique : catalogue produits (goodies, billets), état stock cohérent, flux « ajouter au panier » vers une logique de commande adaptée au contexte associatif — pas un Shopify, mais quelque chose de crédible pour une promo étudiante. Là encore Firestore pour l’inventaire et les commandes, avec attention aux conditions de concurrence (deux personnes qui cliquent en même temps sur le dernier billet).
Calendrier : modèle de données orienté événements, fuseaux et affichage localisé, rappels côté client. Espace MMI et profil : contenu statique semi-dynamique (liens utiles, services BDE), carte de membre visuelle et système de points de fidélité — surtout de la présentation + persistance légère sur le document utilisateur.
Deux semaines de dev — et autant pour l’App Store
Le code des features principales, je l’ai bouclé dans une fenêtre courte en solo. Ce qui m’a pris proportionnellement autant de temps, c’est Apple : compte développeur, certificats, profils de provisioning, conformité aux Human Interface Guidelines, textes de métadonnées, captures d’écran aux bonnes tailles, politique de confidentialité hébergée quelque part, et la boucle infinie des rejets avec messages parfois cryptiques.
Chaque rejet est une mini-formation : interpréter la note du reviewer, corriger sans casser le reste, renvoyer un build. TestFlight a servi de filet — faire tester par des gens de la liste avant de repousser en review. La leçon : prévoir du buffer « store » dans l’estimation, surtout sur un premier déploiement sérieux.
“La partie la plus longue ? Pas le code — l’App Store. Les guidelines, les rejets, les allers-retours.”
État des lieux campagne et produit
Les votes n’étaient pas encore passés au moment où j’écris ça. L’app tourne, les retours sont bons : les gens comprennent le message de campagne parce qu’il existe en tactile, pas seulement sur Instagram. C’est beaucoup une vitrine — et c’est voulu : montrer qu’on sait livrer un binaire signé et une expérience cohérente avant le scrutin.
Si la liste est élue, la suite logique c’est d’en faire un outil vivant (vraies ventes, contenus modérés, rôles admin plus fins). Si ce n’est pas le cas, le dépôt technique reste une preuve de compétence — pas glorieux à dire comme ça, mais c’est la réalité des projets étudiants à fort enjeu politique.
Ce que j’en retiens
Une idée collective ne vaut que ce que quelqu’un accepte de porter jusqu’au bout. J’ai pris ce rôle : Flutter et Firebase comme levier de vitesse, la discipline des règles Firestore et la patience face à Apple comme garde-fous. Deux semaines pour un MVP crédible en prod, plus le temps « invisible » du store — c’est ça, une vraie livraison.
“Une idée de groupe reste une idée jusqu’à ce que quelqu’un décide de s’en charger pour de vrai. J’ai pris cette responsabilité. Deux semaines plus tard, l’app était sur l’App Store.”