Agence Flutter et Firebase à Paris : votre application en 2 semaines, à prix fixe

Highway Studio est une agence parisienne spécialisée en Flutter et Firebase. Nous développons des applications iOS, Android et web à partir d'une seule base de code Flutter, avec un serveur Firebase, en 2 semaines de développement et pour un prix fixe de 12 000 €. À la livraison, vous recevez le code source, organisé selon une architecture que nous avons publiée en open source et qu'un autre développeur Flutter peut reprendre.

Pourquoi développer votre application en Flutter ?

Flutter permet de développer une application iOS, une application Android et une version web à partir d'un seul code. Cette technologie open source, soutenue par Google, compile l'application en code natif pour chaque plateforme (flutter.dev).

Pour un fondateur ou une PME, ce choix technique se traduit en termes très concrets : une seule équipe, un seul budget, et des fonctionnalités qui arrivent le même jour sur iPhone et sur Android. Il pèse aussi sur la suite, puisque chaque correction et chaque évolution ne s'écrivent qu'une fois.

React Native répond au même besoin et fait lui aussi ses preuves en production ; le choix entre les deux tient souvent aux compétences de l'équipe qui maintiendra l'application. Chez Highway, chaque application est développée en Flutter.

Et la version web ?

Flutter publie aussi votre application sur le web, à partir du même code. Sa documentation le destine aux applications (un espace client, un tableau de bord, un parcours d'inscription) plutôt qu'aux sites de contenu, dont les pages doivent être lues et classées par les moteurs de recherche (documentation Flutter). Votre application peut donc avoir sa version web en Flutter, et votre site vitrine rester un site HTML classique.

Que fait Firebase côté serveur ?

Firebase est la plateforme de Google qui fournit le serveur de votre application. Elle évite de construire et d'administrer un serveur de zéro, et elle est facturée selon l'usage. Chez Highway, nous en utilisons les briques suivantes, selon les besoins de votre application :

• Authentication : l'inscription et la connexion de vos utilisateurs.
• Firestore : la base de données, synchronisée en temps réel avec l'application.
• Storage : les photos, les documents et les fichiers de vos utilisateurs.
• Cloud Functions : les fonctions serveur, écrites en TypeScript, qui portent les règles de votre activité.
• Cloud Messaging : les notifications, sur iPhone comme sur Android.

Chaque application dispose de deux environnements Firebase séparés, l'un de test, l'autre de production : vos utilisateurs ne voient jamais une version en cours de travail.

Pourquoi toutes les modifications passent-elles par le serveur ?

Dans nos projets, l'application n'écrit jamais directement dans la base de données. Chaque modification (une réservation, un profil, un paiement) passe par une fonction serveur, qui vérifie qui la demande, s'il en a le droit et si les données sont valides avant de l'enregistrer.

Les règles de votre activité sont ainsi écrites à un seul endroit, et elles s'appliquent de la même façon à l'application iOS, à l'application Android et à la version web. Une requête envoyée en dehors de l'application ne peut pas les contourner, et une règle qui change ne se corrige qu'une fois.

Comment s'assurer qu'un autre développeur pourra reprendre le code ?

Un code se reprend facilement lorsque chaque élément se trouve là où l'on s'attend à le trouver. C'est l'objet de Chassis, le framework d'architecture Flutter que nous avons conçu et publié en open source sur pub.dev, le registre des paquets Flutter et Dart.

Chassis impose la même organisation à chaque application, inspirée de l'architecture que recommande Flutter. Chaque fonctionnalité y prend la même forme : une commande ou une requête qui décrit l'opération (« réserver un cours », « afficher le planning »), le code qui l'exécute, et l'écran qui en affiche le résultat. Une partie de cette structure est vérifiée à la compilation : une opération privée du code qui l'exécute, par exemple, empêche l'application de compiler.

Pour vous, cela se traduit de trois façons :

• Vous ne dépendez pas de nous : un développeur Flutter qui ouvre le projet retrouve chaque fonctionnalité au même endroit, organisée de la même façon.
• Vous pouvez vérifier avant de signer : Chassis est public. Votre développeur ou votre CTO peut l'examiner sur pub.dev avant même de nous contacter.
• Le code reste cohérent dans le temps : chaque nouveau sprint ajoute ses fonctionnalités dans la même structure, sans que l'architecture se dégrade.

Ce cadre strict est aussi ce qui permet à notre méthode de développement, assistée par l'IA, de produire un code régulier d'une application à l'autre.

Et lorsqu'une fonctionnalité exige du code natif ?

Flutter ne limite pas votre application à ses propres modules : il communique avec du code natif, écrit spécifiquement pour iOS ou pour Android, ainsi qu'avec des bibliothèques écrites dans d'autres langages (documentation Flutter). Lorsqu'une fonctionnalité l'exige, nous écrivons cette partie en natif et la relions au reste de l'application.

• Smarteen : toutes les applications sont en Flutter, dont l'application Parent sur iOS et Android. Le logiciel qui contrôle le téléphone de l'enfant, intégré au plus profond du système Samsung, est quant à lui écrit en Kotlin natif, parce qu'il pilote directement l'appareil, 24 h sur 24.
• myUnbox : le moteur cryptographique de ce portefeuille numérique, développé en Rust par une autre équipe, fonctionne au cœur de l'application Flutter, sur iOS comme sur Android. Nous avons mené cette intégration avant de développer le moindre écran (étude de cas).

Lorsque votre application repose sur une brique de ce type (un matériel, un kit de développement fourni par un partenaire, un moteur existant), nous commençons par elle, afin de vérifier qu'elle fonctionne avant de fixer le reste du périmètre. Un projet de cette ampleur se découpe ensuite en plusieurs sprints, chacun à prix fixe.

Pouvez-vous reprendre une application Flutter ou FlutterFlow existante ?

Oui. Une application existante est même un point de départ précieux : ses écrans décrivent déjà ce qu'elle doit faire, et tiennent lieu de maquettes.

FlutterFlow, l'outil de création visuelle d'applications, produit du code Flutter que l'on peut télécharger (documentation FlutterFlow), et s'appuie souvent sur Firebase. Votre projet repose donc déjà sur les technologies que nous utilisons.

1. Nous examinons votre application et son code. Écrans, données, projet Firebase, fonctionnalités en place.
2. Nous vous indiquons ce qui se conserve et ce qui gagne à être réécrit. Le projet Firebase et les données de vos utilisateurs peuvent être conservés ; le code de l'application est repris sur notre architecture, à partir de ses écrans.
3. Nous fixons le prix et la date. L'application existante sert de maquette, et le développement suit le même déroulé qu'une nouvelle application.

Voir FlutterFlow : quand passer au code Flutter.

Combien coûte une application Flutter et Firebase chez Highway ?

12 000 €, prix fixe, pour 2 semaines de développement à partir de maquettes validées. Ce prix comprend l'application Flutter pour iOS, Android et, si besoin, le web, le serveur Firebase, les tests, la mise en production, la soumission aux stores et le code source. Le prix, la date de livraison et la liste des fonctionnalités sont écrits avant le premier jour de développement.

Restent à prévoir à côté : vos comptes développeur (99 USD par an chez Apple, 25 USD une seule fois chez Google), l'hébergement Firebase, facturé par Google selon l'usage et faible au démarrage (tarifs Firebase), et les services tiers propres à votre application, comme le paiement ou l'IA.

Un projet plus vaste se découpe en plusieurs sprints de 2 semaines, chacun avec son prix et sa date. Pour le détail du déroulé et de ce qui est compris, voir notre page développement d'application mobile à prix fixe.

Comment se déroulent les 2 semaines ?

1. Vous nous envoyez vos maquettes. Sous 48 h, nous vous envoyons le périmètre écrit, écran par écran.
2. Vous validez. Les maquettes deviennent la référence du développement, et la date de livraison est fixée.
3. Nous développons l'application Flutter et son serveur Firebase, pendant 2 semaines, sans réunion ni étape intermédiaire à valider de votre côté.
4. Nous livrons, avec le code source, puis nous soumettons l'application à l'App Store et à Google Play.

Pas encore de maquettes ? Nous les réalisons avec vous et un designer avant les 2 semaines, dans une étape chiffrée à part.

Qui développe votre application ?

Highway Studio a été fondé par Pierre Martin, développeur Flutter et Firebase. Il développe des applications Flutter depuis 2021, en freelance sur Malt, où ses clients lui ont laissé 23 avis, tous à 5 sur 5, et toutes les applications qu'il a livrées ont été publiées sur iOS et Android. Il est l'auteur de Chassis.

Questions fréquentes

Faut-il connaître Flutter pour travailler avec vous ?

Non. Vous nous apportez les maquettes de votre application et une description de votre activité ; les choix techniques sont de notre ressort, et nous vous les expliquons en termes simples.

Êtes-vous une agence FlutterFlow ?

Nous développons en Flutter, directement dans le code. Nous reprenons en revanche les applications créées avec FlutterFlow lorsqu'elles doivent aller plus loin. Voir FlutterFlow : quand passer au code Flutter.

Une application Flutter est-elle aussi fluide qu'une application native ?

Flutter compile l'application en code natif pour iOS et pour Android, et dessine lui-même son interface (flutter.dev). Pour une application de réservation, de gestion ou de contenu, c'est ce qui lui permet d'offrir la même fluidité sur les deux plateformes. Lorsqu'une fonction exige un accès plus direct au téléphone, cette partie s'écrit en natif.

Où sont hébergées les données de mon application ?

Chez Google, dans le projet Firebase de votre application. Firestore propose plusieurs emplacements européens, dont Paris ; l'emplacement se choisit à la création de la base de données et ne peut plus être modifié ensuite (documentation Firebase). Nous le fixons donc avec vous avant le premier jour de développement.

À qui appartient le code source ?

À vous. Il vous est remis à la livraison, et vos comptes Apple et Google sont créés à votre nom.

Que se passe-t-il après la livraison ?

Vous choisissez la suite : une maintenance mensuelle, sans engagement, pour corriger les bugs et suivre les mises à jour imposées par Apple et Google ; de nouveaux sprints, chacun à prix fixe ; ou la reprise du code par votre propre équipe.

Travaillez-vous avec des entreprises hors de Paris ?

Oui. Le studio est basé à Paris, et tout le projet se mène à distance, en France comme en Belgique ou en Suisse.