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 sur huit mois : 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.
praticien
Bilan clinique
Passation d'un bilan dont le contenu est configuré, pas codé.
plateforme
Moteur de décision
Les réponses sont confrontées aux critères cliniques en vigueur.
plateforme
Alertes médicales
Red flags (contre-indication) et yellow flags (vigilance).
plateforme
Prescription d'exercices
Les alertes filtrent et pondèrent le programme proposé.
patient
Séance guidée
La séance est exécutée sur mobile, avec retour de tolérance.
Le retour de tolérance renourrit la progression : la séance suivante est ajustée à la hausse, maintenue ou allégée. C'est une boucle, pas un tunnel : un même patient repasse par ce cycle à chaque séance.
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.
Les choix techniques
API
Java et Spring Boot
Typage fort de bout en bout et écosystème dont la maintenance et la documentation seront encore là dans dix ans : deux propriétés qui comptent davantage que la concision sur un produit de santé.
Découpage
Monolithe modulaire, un seul processus
Chaque module métier a sa frontière, vérifiée au build : une dépendance interdite casse la compilation au lieu de partir en revue. L'isolation des microservices, sans leur coût d'exploitation pour une équipe d'une personne.
Logique clinique
Configurée, pas codée
Bilans et critères d'alerte sont de la donnée versionnée, éditée depuis le back-office et applicable immédiatement. Le produit cesse de dépendre de mes cycles de release.
Mobile
React Native et Expo
L'application patient affiche des exercices et collecte un retour de tolérance : rien qui exige du natif. Une base de code pour iOS et Android divise par deux la surface à maintenir.
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.
Progression et charge d'entraînement
La pièce la plus sensible : c'est elle qui décide si un patient monte en charge ou lève le pied. Elle est verrouillée par des corpus de référence rejoués à chaque exécution, dont un couvrant 19 440 transitions. Toute divergence casse la suite ; le nouveau comportement attendu doit être justifié explicitement.
Évaluation des critères cliniques
Chaque opérateur de comparaison et chaque combinaison de réponses doit produire l'alerte attendue, y compris sur les cas dégradés : réponse absente, valeur hors bornes, critère référençant une question retirée du bilan.
Autorisation, route par route
L'autorisation est déclarée explicitement sur chaque route plutôt que déduite de la présence d'un jeton. Un test par route vérifie qu'un praticien étranger au dossier est refusé, pas seulement qu'un utilisateur authentifié est accepté.
Persistance et migrations
Les tests tournent contre un vrai PostgreSQL démarré en conteneur, pas contre une base en mémoire qui accepterait des requêtes que la production refuse. Le schéma est reconstruit depuis zéro à chaque exécution : une migration qui ne rejoue pas est détectée avant la mise en ligne.
Cycle de vie RGPD
Recueil et retrait du consentement, suppression douce, purge effective au terme de la rétention, complétude du journal d'accès. Ce sont des exigences vérifiables : elles sont vérifiées.
Parcours back-office
En navigateur réel : connexion, création de dossier, passation d'un bilan, lecture des alertes levées, prescription. Le parcours complet, pas des écrans isolés.
Frontières entre modules
Les dépendances autorisées entre modules métier sont déclarées et vérifiées à la compilation. Un raccourci pris un vendredi soir ne compile pas.
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 certification HDS en région France 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 sur les deux stores, un hébergement certifié HDS en France, et environ 235 000 lignes de Java et de TypeScript maintenues par une personne.
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.
