2M€ levés, une application mobile de santé à construire - Jinko.care

Jinko.care, c'est une plateforme pensée pour les personnes atteintes de cancer ou en rémission. Un espace pour poser des questions, partager son expérience, trouver du soutien auprès d'une communauté qui comprend vraiment ce qu'on traverse. Avant l'application mobile, tout se passait sur le web. Anthony, co-fondateur, voulait aller plus loin, mettre cette communauté dans la poche de chaque patient.

Avec 2M€ levés, les moyens étaient là. Ce qu'il fallait, c'était une équipe capable d'exécuter vite et bien sur un sujet aussi sensible.

‍

Créer une application mobile de santé : deux défis qui ne tolèrent pas l'approximation

Deux contraintes se posaient dès le départ, et elles n'étaient pas négociables.

La première : les données. Jinko.care manipule des informations de santé. Des données médicales partagées par des personnes dans des situations de vulnérabilité, des informations qui engagent la responsabilité légale et éthique de la plateforme à chaque interaction. Chaque décision d'architecture devait intégrer cette contrainte dès la conception, pas en bout de chaîne.

La deuxième : l'organisation. Anthony gérait à la fois la vision produit et la supervision technique en tant que CTO. Il avait besoin d'une équipe externe capable de prendre en charge l'exécution de manière autonome, sans avoir besoin d'être guidée à chaque étape. Un partenaire, pas un prestataire.

‍

Comment on a créé l'application mobile Jinko.care

On est intervenus en abonnement, un mode de collaboration où on intègre l'écosystème existant pour faire avancer le produit en continu, pas juste livrer et partir.

Une architecture Firebase conforme aux exigences RGPD pour les données de santé

Le backend repose sur Firebase,; choix imposé par le client, stack qu'on a sécurisée et configurée pour répondre aux exigences spécifiques d'une application de santé.

Les données de santé partagées par les utilisateurs ne sont jamais stockées en clair. Les échanges sont chiffrés en transit via TLS, les données au repos sont protégées par le chiffrement natif Firebase. Les Firebase Security Rules ont été configurées avec une granularité maximale : chaque utilisateur n'accède qu'à ses propres données, aucune donnée médicale n'est exposée dans des endpoints non authentifiés, et les accès sont loggés.

Côté conformité RGPD, l'architecture a été pensée dès le départ pour garantir la pseudonymisation des profils : aucune information directement identifiante n'est associée aux données médicales partagées dans la communauté. Les utilisateurs ont un contrôle total sur leurs données, consultation, export, suppression, conformément aux obligations du règlement européen. Sur une app de santé, ce n'est pas une option. C'est la base légale du produit.

‍

Une communauté anonyme construite pour la vulnérabilité

Le fer de lance de l'application, c'était la communauté. Un espace où chaque patient peut poser ses questions, partager son parcours, lire les expériences des autres, avec une approche entièrement anonyme.

Techniquement, la communauté repose sur une architecture Firestore structurée autour de collections de posts, commentaires et interactions, avec des profils pseudonymisés dès la création de compte. Aucun nom réel, aucune information identifiante n'apparaît dans les échanges publics. Les identités sont dissociées des contributions par construction, pas par paramètre désactivable. Un modérateur ne peut pas remonter à l'identité d'un utilisateur depuis ses posts, c'est voulu, c'est architectural.

C'est une décision de design autant que technique : sur une communauté de patients atteints de cancer, l'anonymat n'est pas un confort. C'est une condition pour que les gens parlent vraiment.

‍

Un assistant IA intégré pour accompagner les patients

Au-delà de la communauté, Jinko.care intègre un assistant IA conçu spécifiquement pour accompagner les patients dans leur parcours. Pas un chatbot générique,; un assistant entraîné sur le contexte oncologique, capable de répondre aux questions courantes sur les traitements, les effets secondaires, les démarches administratives, et d'orienter les utilisateurs vers les bonnes ressources quand la question dépasse son périmètre.

L'IA est intégrée directement dans l'app mobile avec une interface conversationnelle pensée pour des utilisateurs en situation de fragilité : ton adapté, réponses claires, et garde-fous explicites pour ne jamais se substituer à un avis médical. Chaque réponse de l'assistant est accompagnée d'un rappel systématique : l'IA conseille, le médecin décide. Ce périmètre est non négociable, et il est codé, pas juste mentionné dans les CGU.

‍

Triple authentification : Google, Apple, Email

L'accès à l'application est sécurisé via trois modes d'authentification, Google, Apple Sign-In et Email, gérés nativement par Firebase Auth. Chaque méthode génère un token sécurisé qui donne accès aux données de l'utilisateur sans jamais exposer ses identifiants. L'onboarding a été pensé pour minimiser les frictions tout en garantissant l'intégrité de l'authentification : des personnes en parcours de soin n'ont pas d'énergie à dépenser sur une procédure de connexion complexe.

‍

Push notifications via Firebase Cloud Messaging

Les notifications push sont gérées via Firebase Cloud Messaging, cohérent avec la stack Firebase en place. Nouveaux messages dans la communauté, réponses à ses propres posts, relances de l'assistant IA, rappels de suivi, chaque notification est ciblée et contextuelle. Sur une app de santé, une notification mal calibrée peut être intrusive au pire moment. La logique de déclenchement a été construite avec cette sensibilité en tête.

‍

Flutter : une contrainte client, une exécution sans compromis

Comme pour Jobs That Makesense, le choix Flutter venait du client. Firebase et Flutter forment un écosystème Google cohérent, et Anthony avait des raisons techniques légitimes de vouloir cette stack. On s'y est adaptés sans friction.

Flutter compile vers du code natif iOS et Android depuis une seule codebase Dart, performances natives sur les deux plateformes, une seule base à maintenir, et des widgets entièrement personnalisables pour construire une interface à la hauteur de la sensibilité du sujet. L'app est en production sur App Store et Google Play.

‍

Une V1 en 1 mois et demi, puis des évolutions en continu

La priorité initiale était de porter l'essentiel de la plateforme sur mobile rapidement. Onboarding, profil utilisateur, accès à la communauté anonyme, assistant IA, les fondations ont été posées en 6 semaines.

Après la première livraison, le produit n'a pas été figé. On continue à faire évoluer l'app en mode abonnement : nouvelles features, itérations UX, corrections, au rythme des besoins d'Anthony et de sa communauté. C'est ça, un vrai partenaire technique : pas une livraison puis un au revoir.

‍

Les résultats

• 2M€ levés avant le lancement de l'app
• V1 livrée en 1 mois et demi, onboarding, communauté, assistant IA
• Architecture Firebase sécurisée et conforme RGPD pour les données de santé
• Communauté anonyme par construction, pseudonymisation architecturale
• Assistant IA intégré avec garde-fous médicaux explicites
• Triple authentification Google, Apple, Email via Firebase Auth
• Push notifications ciblées via Firebase Cloud Messaging
• App en production sur App Store et Google Play en Flutter
• Évolutions continues en mode abonnement

‍

Ce qu'on retient sur la création d'une application mobile de santé

Travailler sur une app de santé, ce n'est pas comme travailler sur une app de fitness ou de productivité. Chaque décision technique a un impact sur des personnes dans des situations de vulnérabilité. La conformité RGPD n'est pas un livrable à cocher, c'est une contrainte qui redessine l'architecture de fond en comble. L'anonymat n'est pas un paramètre utilisateur, c'est une propriété du système.

Le rôle de firstapp ici n'était pas juste d'exécuter. C'était d'être un partenaire de confiance, capable de travailler de manière autonome sur un sujet qui ne tolère pas l'approximation.

‍