Aurora Trauma est un projet de santé publique indépendant, à but non commercial. Sa fondatrice voulait une application gratuite pour accompagner les personnes qui vivent avec un stress post-traumatique (TSPT), en complément du soin.
FilouTech a pris la commande de bout en bout : cadrage, conception, développement, publication sur les stores et site vitrine. J’étais l’interlocuteur unique du client du premier au dernier jour. Le projet a été découpé en cinq phases, livrées l’une après l’autre entre fin mars et fin mai 2026.
La cible · Le problème
Entre deux séances de thérapie, ou en attendant une prise en charge longue et coûteuse, les personnes touchées par un TSPT se retrouvent souvent seules face à leurs symptômes. Les crises arrivent sans prévenir : dissociation, flashbacks, angoisses, cauchemars. Il faut alors un outil de régulation tout de suite, pas un article à lire.
Les apps de bien-être grand public ne sont pas faites pour ça, et beaucoup collectent des données de santé très sensibles.
La demande du client était nette : une app gratuite, sans compte, et aucune donnée envoyée hors du téléphone.
Le plan · La solution
Ollisto s’organise en quatre onglets : Accueil, Crise, Quotidien et Progrès.
En cas de crise, tout est accessible en un geste : ancrage 5-4-3-2-1, trois respirations guidées (4-7-8, carrée, cohérence cardiaque), sons apaisants, kit de survie personnel, carte de crise et bouton SOS vers le 15, le 3114 ou un contact choisi.
Au quotidien, l’utilisateur note son humeur, tient un journal et s’appuie sur l’outil RID (reconnaître, identifier, décider). Un parcours de 11 modules et 44 missions interactives l’aide à comprendre son trauma et à construire ses propres outils. L’onglet Progrès affiche l’évolution de l’humeur, une carte des zones de déclenchement et l’historique des crises. Un bilan peut être exporté en PDF pour le thérapeute.
Le choix d’architecture découle directement de la demande : une app local-first. Pas de serveur, pas d’API, pas de compte. La base de données vit sur l’appareil, les rappels sont planifiés localement, les exports passent par le menu de partage du téléphone.
Sur le téléphone, même sans réseauInterfaceécrans FlutterÉtatRiverpodDépôtsaccès aux donnéesBase localeIsar, sur l’appareilNotifications localesrappels programmésExport PDFpartagé seulement si l’utilisateur le décideAucun serveuraucune donnée ne quitte le téléphone
Sur le téléphone, sans réseauInterfaceécrans FlutterÉtatRiverpodDépôtsaccès aux donnéesBase localeIsar, sur l’appareilNotifications localesrappelsExport PDFsi l’utilisateur le décideAucun serveuraucune donnée ne quitte le téléphone
Schéma local-first d’Ollisto : interface, état, dépôts et base locale restent sur le téléphone, avec notifications locales et export PDF, sans serveur
L’exécution · Ce que FilouTech a livré
Cadrage et pilotage : découpage en cinq phases, revues avec la fondatrice à chaque livraison, alignement continu sur le cahier des charges.
Socle technique : architecture Flutter local-first, gestion d’état avec Riverpod, navigation avec GoRouter, base embarquée Isar.
Les écrans : onboarding, accueil, espace Crise, Quotidien, Progrès, paramètres, et les 11 modules du parcours.
Les exercices : respirations animées, ancrage, sons embarqués, kit de survie, carte de crise.
Les exports : bilan en PDF, TXT et CSV, partagé depuis le menu natif.
Les rappels : notifications locales de check-in et de parcours, fiabilisées sur Android.
La mise en production : build release Android, icônes adaptatives iOS et Android, préparation des fiches et publication sur les stores.
Autour de l’app : site vitrine statique avec les liens vers les stores, visuels de la fiche Google Play.
Le matériel · Stack technique
Application : Flutter, Dart, Riverpod, GoRouter, fl_chart pour les graphiques, just_audio pour les sons.
Données : Isar, base NoSQL embarquée, neuf collections (profil, humeur, journal, crises, kit, respirations, RID, zones, réponses aux modules).
Sur l’appareil : flutter_local_notifications pour les rappels, export PDF, partage natif.
Livraison : GitHub avec une branche par phase, publication App Store et Google Play, site vitrine en HTML, CSS et JavaScript.
Incident n°1 : des rappels à l’heure, sans aucun serveur
Imprévu. Les rappels de check-in (le matin ou le soir) et le rappel hebdomadaire du parcours sont entièrement locaux. Sur les versions récentes d’Android, le système décale ou regroupe les alarmes qu’il juge non urgentes.
Parade. Déclarations du manifeste complétées, passage de la planification en alarmes exactes, replanification au démarrage de l’app.
Ce que j’en retiens. Sur mobile, le local-first ne supprime pas la complexité. Il la déplace vers les règles du système d’exploitation.
Incident n°2 : une base embarquée qui bloque la mise en production
Imprévu. Isar 3 n’est plus maintenu et entre en conflit avec les versions récentes des outils de build Android. Le bundle de publication refusait de se construire.
Parade. Plusieurs corrections ciblées de la configuration Gradle, jusqu’à obtenir un bundle Android publiable.
Ce que j’en retiens. Le choix d’une base embarquée se juge aussi sur sa maintenance à long terme.
Incident n°3 : un contenu thérapeutique volumineux à rendre interactif
Imprévu. 11 modules, 44 missions et 9 types d’interaction différents : sélection, checklist, schéma corporel cliquable, carte de crise, météo intérieure.
Parade. Le contenu est décrit sous forme de données et affiché par des composants génériques, un par type d’interaction. Un audit d’écart avec le cahier des charges, puis une revue écran par écran de chaque module, ont aligné l’app sur la demande.
Ce que j’en retiens. Quand le contenu est abondant, séparer les données de leur affichage rend chaque correction rapide et sans risque.
Le bilan · Résultats
Application livrée en cinq phases, en deux mois environ, de mars à mai 2026.
