Physio Xpert, SaaS médical pour kinésithérapeutes

Le contexte

Physio Xpert est une plateforme de rééducation destinée aux kinésithérapeutes, en production sur app.physio-xpert.com. Le praticien fait passer un bilan clinique, la plateforme en déduit des alertes médicales, ces alertes déterminent les exercices prescrits, et le patient exécute ses séances depuis une application mobile en signalant sa tolérance à chaque exercice.

J’ai conçu et développé l’ensemble seul depuis septembre 2025 : l’API, le back-office praticien, l’application mobile patient, le schéma de données, l’hébergement et la chaîne de tests. Trois contraintes expliquent à peu près toutes les décisions techniques qui suivent.

La logique clinique doit évoluer sans redéploiement. Les critères d’alerte suivent la pratique, pas les cycles de release : ils vivent en données, modifiables par les praticiens eux-mêmes depuis le back-office.

Ce sont des données de santé. Hébergement certifié, chiffrement, consentement explicite et traçabilité des accès forment un cadre réglementaire qui se pose à la conception, pas à la livraison.

Un seul développeur, sur la durée. Chaque brique doit rester compréhensible et modifiable par une seule personne dans cinq ans, ce qui exclut autant la sur-ingénierie que le raccourci.

La chaîne de décision clinique

C’est la pièce à comprendre en premier : tout le reste de l’architecture existe pour que cette chaîne soit juste, traçable et modifiable sans redéploiement.

Deux propriétés de cette chaîne ont structuré le reste du travail. D’abord, un maillon est configuré, pas codé : un praticien fait évoluer ses bilans et ses critères d’alerte sans que je déploie quoi que ce soit. Ensuite, la sortie du dernier maillon revient dans le premier : la progression n’est pas une fonction pure d’un bilan initial, c’est une machine à états qui accumule l’historique du patient.

Le point de départ, et pourquoi il a changé

Le produit n’a pas démarré sur la pile qu’il porte aujourd’hui. La première version était un MVP React + Supabase : une base managée, l’authentification et les règles d’accès fournies par la plateforme, et un front qui parlait directement à cette base. Pour valider la chaîne de décision clinique auprès de praticiens, c’était le chemin le plus court, et il a rempli son rôle.

Ce qui a mis fin à ce montage n’est pas une limite technique, c’est le cadre réglementaire. Dès que la plateforme manipule des dossiers patients réels, l’hébergement doit être certifié HDS, et la donnée de santé impose un consentement horodaté, une rétention explicite et un journal d’accès complet. Ces exigences se posent au niveau du serveur qui répond à chaque requête, pas d’un client. Un front qui interroge la base directement n’a nulle part où les faire tenir.

La migration n’a donc pas été un déplacement de code, c’est une réécriture totale du moteur de l’application. Tout ce qui vivait dans Supabase, le schéma, les règles d’accès et la logique de décision clinique, a été réécrit derrière une API Java / Spring Boot sur un PostgreSQL hébergé chez Scalingo, seul point d’entrée des deux clients. Ce qui est resté, c’est l’interface : le back-office praticien est toujours en React, et c’est l’ajout de l’application mobile patient qui a étendu la partie front plutôt qu’il ne l’a remplacée.

Mener cette bascule seul, sur un produit déjà utilisé, a été le morceau le plus formateur du projet. Elle explique aussi la forme actuelle de l’architecture : si les deux interfaces ne parlent qu’à l’API, c’est parce que l’inverse a été essayé et ne pouvait pas tenir sur des données de santé.

Les choix techniques

L’architecture qui en découle

Les 310 routes de l’API vivent toutes sous /api/v1. Le back-office et l’application mobile se mettent à jour à des rythmes différents, et une application installée sur un téléphone ne se redéploie pas d’un git push : le versionnement de l’API n’est pas une précaution théorique.

Ce que la chaîne de tests couvre

Travailler seul change la méthode : sans relecteur, la seule chose qui peut contredire un raisonnement, c’est un test. La couverture n’est donc pas répartie uniformément : elle est concentrée là où une erreur silencieuse aurait des conséquences cliniques ou réglementaires.

Le volume n’est pas l’argument, même s’il se cite volontiers : 4 658 tests sur l’API, dont j’ai vérifié l’exécution réelle plutôt que le simple décompte. L’argument, c’est qu’aucune de ces zones ne peut changer de comportement en silence.

Ce que les données de santé imposent

La conformité n’est pas une couche ajoutée avant la mise en ligne, c’est une série de contraintes posées dans les premières migrations. Le consentement est une donnée explicite et horodatée, pas une case cochée ; la suppression est douce, avec une rétention de 30 jours ; chaque lecture de dossier patient est journalisée. Ces exigences appartiennent au schéma parce qu’un journal d’accès ajouté après coup laisse un trou historique impossible à combler. L’hébergement suit la même logique : la plateforme tourne chez Scalingo, certifié HDS, en région France. Une certification est un prérequis légal, arbitré avant d’être un choix d’infrastructure.

Le même principe s’applique aux dépendances externes. Un outil de supervision remonte volontiers un nom ou une réponse clinique dans un contexte d’erreur : les données sensibles sont donc masquées avant tout envoi, à la source plutôt qu’au filtrage.

Où en est le produit

La plateforme est en production et continue d’évoluer : une API de 310 routes couverte par 4 658 tests, un back-office praticien, une application mobile patient sur iOS et Android, et un hébergement chez Scalingo, certifié HDS, en France, le tout maintenu par une seule personne.

L’ouverture aux patients reste devant nous. C’est aussi pourquoi cette page ne cite aucune métrique d’usage : il n’y en a pas encore, et un chiffre de volume mis à la place ne mesurerait que ce que j’ai produit.

Le pari central se vérifie sur la durée : les praticiens font évoluer leurs bilans et leurs critères d’alerte sans passer par moi. C’est exactement ce que le moteur de décision devait rendre possible.

Ce qu’en dit le client