Mon Test Civique
Concevoir et livrer seul une application mobile iOS et Android, du design à la publication sur les stores.
- 3 k+
- Téléchargements
- 5,0 ★
- Note stores
- +20 k€
- Revenus générés
- 0
- Plantages

Le contexte
France Access m'a contacté pour développer la partie mobile d'une plateforme de préparation à l'examen civique français. Le projet était déjà lancé côté web : un développeur backend travaillait sur la plateforme et l'API.
Ma mission couvrait l'intégralité de l'application iOS et Android. Le backend me fournissait les endpoints au fur et à mesure de l'avancement, étape par étape, et je les intégrais de mon côté.
Point important : il n'y avait ni maquette, ni charte graphique. J'ai donc pris en charge l'ensemble de la conception : design UI, arborescence des écrans et parcours utilisateur, en plus du développement.

Le problème
Préparer un examen civique demande de la régularité, pas une session unique. Les candidats devaient pouvoir réviser n'importe où, y compris dans les transports, et suivre leur progression dans le temps.
Il fallait aussi couvrir plusieurs types d'examens (carte de séjour, carte de résident, naturalisation) avec des contenus distincts, tout en gardant une expérience simple pour des utilisateurs qui ne sont pas toujours à l'aise avec le numérique.
Le tout devait rester synchronisé avec la plateforme web : un utilisateur qui commence sur mobile doit retrouver sa progression ailleurs.

Mes choix techniques
J'ai retenu Flutter pour le cross-platform. En natif, il aurait fallu maintenir deux bases de code distinctes pour iOS et Android, soit un coût en temps de développement et en déploiement que le calendrier ne permettait pas. Une seule base de code, deux plateformes publiées.
Le reste de la stack a découlé d'une évaluation fonctionnalité par fonctionnalité, à partir de ce que le client voulait intégrer. Riverpod pour la gestion d'état, une architecture en couches pour isoler la logique métier des appels réseau.
Côté conception, j'ai construit chaque écran à partir des besoins fonctionnels : quiz interactifs par thématique, système de récompenses, et suivi de progression en temps réel synchronisé avec la plateforme web.

La difficulté
C'était ma première intégration d'API à cette échelle dans une application mobile. Les endpoints arrivaient progressivement, au fil de l'avancement du backend, ce qui m'obligeait à structurer le code pour absorber des contrats qui n'étaient pas tous connus dès le départ.
Il m'est arrivé de rester bloqué plusieurs jours sur un même problème, avec une deadline à tenir en parallèle. C'est la partie du métier dont on parle le moins.
Ce que j'en ai tiré : découper le problème en morceaux testables isolément plutôt que de chercher à faire fonctionner l'ensemble d'un coup, et communiquer tôt avec le backend quand le blocage venait du contrat d'API plutôt que de mon code.

Le résultat
L'application est en production sur l'App Store et le Google Play Store, notée 5,0/5 et sans plantage signalé.
Le point le plus parlant vient du dashboard : la majorité des inscriptions se fait désormais via l'application mobile plutôt que par la plateforme web. Le mobile est devenu le canal d'acquisition principal du produit.
Le client a été satisfait du résultat, et le modèle premium par abonnement a généré plus de 20 k€.
Ce que ce projet m'a appris
- 01Concevoir sans maquette impose de trancher soi-même : chaque écran est une décision à assumer et à justifier devant le client.
- 02Flutter tient sa promesse sur le cross-platform, à condition de structurer le code pour absorber une API livrée par étapes.
- 03Rester bloqué plusieurs jours fait partie du métier. Ce qui compte, c'est de découper le problème et de savoir quand le blocage ne vient pas de son propre code.
- 04Une app mobile bien pensée peut devenir le canal d'acquisition principal, devant le web.