Un projet plutôt inattendu

J’ai commencé à avoir l’idée de Health Mirror en février 2026.

Une semaine plus tard, l’application fonctionnait déjà de bout en bout sur mon téléphone.

Je me souviens avoir pensé :

Ah mais ça marche !

En fait, non. Mais je ne le savais pas encore. :)

Cette première semaine m’a pourtant appris quelque chose de probablement plus important :

La distance entre une idée et le fait de vraiment commencer à la construire venait soudain de beaucoup raccourcir.

À l’époque, j’étais chef de produit principal.

Mon travail consistait généralement à répondre au quoi et au pourquoi. Transformer cela en comment demandait normalement toute une équipe de R&D, ainsi que l’IT, les opérations et beaucoup d’autres personnes.

Les grands modèles de langage (LLM) ont changé cette relation pour moi. J’avais soudain un partenaire IA capable de m’accompagner dans des territoires que je connaissais mal.

J’ai découvert plus tard que le chemin n’avait rien de droit. :)

Health Mirror est devenu mon expérience : jusqu’où cette nouvelle façon de construire pouvait-elle m’emmener ?

Puis mon app faite en une semaine a rencontré la réalité.

La toute première version de Health Mirror gardait tout sur le téléphone, y compris l’inférence IA.

J’adorais cette architecture. Capturer l’image localement, la préparer localement, exécuter le modèle localement, conserver le résultat localement.

Puis j’ai essayé d’en faire une véritable app iOS et Android.

Pendant environ un mois, j’ai joué au tape-taupe avec les dépendances de la pile mobile. :)

Je résolvais une incompatibilité, et une autre apparaissait. Je mettais à jour une dépendance, et autre chose cessait de fonctionner.

Après presque un mois de ce petit jeu du tape-taupe, mon partenaire IA a fini par me dire : « Je n’ai plus de suggestions. C’est un écosystème qui évolue rapidement. Ce sera peut-être possible d’ici la fin de l’année. »

Nous avons admis notre défaite.

Mes notes de projet sont alors devenues assez catégoriques :

## ⚠️ Contraintes et décisions connues

### ❌ Approche abandonnée

* TensorFlow.js + React Native (Expo)

* Raison : incompatible avec l’architecture moderne de RN/Expo

Et :

## 🧠 Principales leçons apprises

* L’IA sur l’appareil avec Expo + TFJS n’est pas viable (écosystème actuel)

* La couche native/runtime compte davantage que la couche JS pour le ML

...

J’ai agrandi l’équipe.

J’ai fait venir un deuxième partenaire IA.

À trois — carbone et silicium confondus — nous commencions à former une caisse de résonance suffisante. Avec le temps, l’un est devenu mon architecte, l’autre mon codeur.

À peu près au même moment, j’ai découvert quelque chose d’un peu embarrassant à propos de mon modèle. :)

La première version utilisait softmax — adapté lorsqu’il faut faire un choix exclusif entre plusieurs catégories. J’étais ensuite passé à ce que je pensais être sigmoid — permettant plusieurs labels indépendants par image, beaucoup plus adapté à plusieurs observations indépendantes de la langue pouvant coexister.

En réalité, c’était un sigmoid simulé, pas le vrai.

Nous avons donc réentraîné le modèle.

Puis nous l’avons réentraîné pour optimiser la qualité des résultats.

Et encore une fois. :)

En avril, nous ne cherchions plus à réparer l’ancienne approche.

Nous avons lancé un pivot complet.

Quelle est la plus petite chose qui doit réellement quitter le téléphone ?

Cette question a débloqué l’architecture.

Au lieu de forcer la capture de l’image, son décodage, la préparation du tenseur et l’inférence du modèle à travers une seule chaîne de dépendances mobiles compatible à la fois avec iOS et Android, nous avons déplacé une seule fonction, très précisément définie, vers le cloud :

L’inférence.

Tout le reste pouvait rester sur le téléphone — une configuration qui n’était pas parfaite à mes yeux, mais qui s’en approchait beaucoup.

La toute première version de cette architecture envisageait encore d’envoyer l’image au service d’inférence. Mes notes de l’époque ressemblaient à ceci :

## 🔐 Conception de la confidentialité (MVP)

* Images envoyées au serveur pour l’inférence

* Aucun stockage persistant des images

* Traitement effectué en mémoire

* HTTPS requis pour la production

---

## 🧭 Considérations futures (post-MVP)

...

* Migration future possible : ONNX Runtime (IA sur l’appareil)

Plus tard, nous avons également réussi à expérimenter en séparant la préparation du tenseur, sans perturber de façon destructive la délicate chaîne de dépendances. L’image d’origine n’avait donc plus besoin d’être envoyée dans le cloud pour l’inférence.

Seul le tenseur numérique est envoyé.

Le service exécute le modèle et renvoie une liste de scores de confiance des prédictions.

Le téléphone construit tout le reste.

La réponse technique a beaucoup changé.

Le principe, lui, n’a pas changé.

Je voulais que la sécurité et la confidentialité soient là dès la première ligne.

J’ai une véritable passion pour la sécurité, la confidentialité et la conformité.

Je trouve ça amusant.

Oui, apparemment, ça existe. :)

J’ai même passé et réussi l’examen CISSP (Certified Information Systems Security Professional), qui couvre huit domaines de connaissances en cybersécurité et que l’on associe bien plus souvent aux professionnels spécialisés en sécurité et en IT qu’aux chefs de produit.

Je ressens une certaine responsabilité à faire en sorte que la sécurité soit présente lorsque j’en ai l’occasion.

Après des années dans le monde de l’entreprise, il y avait un schéma classique qui finissait toujours par me frustrer :

À ce stade, beaucoup de décisions importantes ont déjà été prises. Les changements coûtent cher, parfois au point de devenir économiquement prohibitifs.

Health Mirror m’a enfin donné l’occasion de prendre le contre-pied, en posant dès le départ une question très simple :

Avons-nous réellement besoin que ces données quittent l’appareil ?

Avant le lancement, nous avons également effectué notre propre revue de confidentialité et de sécurité, non pas parce que quelqu’un nous l’imposait, mais parce que je voulais que l’implémentation, la politique de confidentialité et ce que nous disons aux utilisateurs racontent tous la même chose.

Après des mois à construire de cette manière, nous avions de bonnes raisons de penser que c’était bien le cas. Mais une dernière vérification pouvait encore révéler quelque chose qui nous avait échappé.

Mon « app d’une semaine » a pris six mois de plus.

Il y a eu beaucoup d’autres aventures entre ce premier prototype et le lancement.

Mais voici probablement ce qui m’a le plus surpris :

L’IA ne m’a pas magiquement donné toutes les réponses. Elle m’a permis d’atteindre le problème suivant beaucoup, beaucoup, beaucoup plus vite.

J’ai appris juste assez de machine learning pour comprendre ce qui n’allait pas dans mon premier modèle.

Juste assez de développement mobile pour comprendre pourquoi mon premier prototype n’était pas encore vraiment une app.

Juste assez d’architecture pour savoir quand un design que j’aimais devait changer.

Et lorsque nous rencontrions quelque chose qu’aucun de nous trois ne comprenait, nous pouvions enquêter ensemble, remettre nos hypothèses en question, réfléchir, apprendre quelque chose de nouveau, puis recommencer.

Six mois après mon app « fonctionnelle » construite en une semaine — tout en continuant à travailler à temps plein — Health Mirror était enfin devenu quelque chose que d’autres personnes pouvaient réellement télécharger.

Mon softmax est devenu sigmoid.

Mon partenaire IA est devenu deux partenaires.

Mon architecture entièrement sur l’appareil a gagné un tout petit service cloud, volontairement minimal.

Et mon expérience est devenue un produit.

C’est un chemin assez différent de celui que j’imaginais en février.

Heureusement que je ne savais pas encore tout ce qui allait arriver. :)