Cas stratégique · France
Cas client — Synapa · E-santé
Intention SEO · développement logiciel e-santé · Durée · Projet en cours
Résumé — 15 secondes
En résumé : PromptConsulting conçoit avec Synapa le socle technique et produit d’une plateforme de coordination du dossier patient, afin que chaque échange clinique soit traçable, sécurisé et utilisable au cabinet — pas seulement « beau » sur une démo.
Synapa est une start-up française qui développe une plateforme de coordination du dossier patient, pensée avec des soignants pour des soignants. Contrairement à un logiciel de cabinet qui équipe un seul lieu, Synapa vise la coordination entre plusieurs acteurs autour d’un même patient.
Le positionnement produit a été clarifié en cours de projet : « Les outils équipent un cabinet. Synapa coordonne des soins. » Cette phrase oriente toutes les décisions d’architecture : ce qui compte, c’est le parcours entre soignants, pas la multiplication de modules décoratifs.
Avant et au démarrage du travail avec PromptConsulting, le défi n’était pas « faire un site ». C’était de passer d’une vision produit ambitieuse à un système capable d’absorber la complexité clinique sans la rendre illisible.
Les données concernées sont sensibles par nature : timeline clinique, transmissions entre soignants, messagerie, éléments susceptibles d’alimenter des échanges FHIR / HL7 / MSSanté / DMP. Chaque information doit pouvoir être attribuée, horodatée et auditée.
Les rôles utilisateurs ne se réduisent pas à « admin / user ». Plusieurs profils soignants coexistent, avec des droits et des besoins de lecture différents. Un parcours qui marche en atelier fondateur peut échouer dès qu’un soignant de terrain doit s’en servir en moins de quinze minutes entre deux patients.
Le problème réel n’était pas le manque de fonctionnalités. C’était le risque classique des produits e-santé : empiler des écrans avant d’avoir un modèle de données et une logique de traçabilité solides.
Sans PostgreSQL pensé comme socle (et non comme simple base d’app), les transmissions deviennent des messages jetables, l’offline devient un patch, et la conformité HDS se traite après coup — trop tard.
Second diagnostic : le marché confond « logiciel médical » et « coordination ». Clarifier ce positionnement évite de construire le mauvais produit pour la mauvaise promesse.
Décision 1
Pourquoi — La traçabilité, les relations multi-entités (patient, soignants, transmissions, événements) et l’auditabilité exigent un modèle relationnel explicite, pas un stockage document opportuniste.
Alternatives — NoSQL document / backend BaaS « rapide »
Arbitrage — Plus de travail de modélisation en amont, mais un socle auditables et interopérable sur le long terme.
Décision 2
Pourquoi — En coordination de soins, une information non attribuable est un risque clinique et réglementaire. La traçabilité n’est pas une feature : c’est le produit.
Alternatives — Messagerie « chat » classique sans journal métier
Arbitrage — UX plus exigeante (qui a dit quoi, quand, dans quel contexte) mais crédible face aux soignants et à l’hébergement de données de santé.
Décision 3
Pourquoi — Intégrer trop tôt sans cadre produit un spaghetti d’API. Documenter les frontières évite de promettre l’impossible au marché.
Alternatives — Intégrations « live » immédiates sans contrat d’interface
Arbitrage — Moins de démos flashy à court terme, plus de sérieux produit.
Décision 4
Pourquoi — Un outil de coordination inutilisable hors réseau ne survit pas au terrain. La sync doit être pensée dans le modèle, pas ajoutée en fin de sprint.
Alternatives — Online-only + message d’erreur réseau
Arbitrage — Complexité de synchronisation et de résolution de conflits, indispensable pour le cas d’usage réel.
La plateforme s’organise autour d’un socle data PostgreSQL. Les interfaces soignants (web) consomment des parcours métier (timeline, messagerie, dossier) ; les couches sécurité et interopérabilité s’appuient sur ce même modèle plutôt que sur des silos parallèles.
Soignant(s)
↓
Next.js (parcours métier)
↓
API / règles d'accès
↓
PostgreSQL (source de vérité)
├── Dossier patient
├── Timeline clinique
├── Transmissions tracées
├── Messagerie chiffrée
└── Journal d'audit
↓
Sync offline-first
↓
Interopérabilité (FHIR / HL7 / MSSanté / DMP)Livrables distincts des résultats : ce qui a été conçu et construit, pas encore les KPI post-production.
| Dimension | Avant | Après |
|---|---|---|
| Nature du travail | Vision produit ambitieuse, risques de sur-fonctionnalisation | Socle data + parcours critiques cadrés |
| Transmissions | Risque de messages non auditables | Modèle conçu pour 100 % de traçabilité |
| Conformité | HDS traité comme contrainte future | HDS/RGPD comme contrainte de conception |
| Positionnement | Logiciel médical générique dans un marché saturé | Coordination des soins vs équipement de cabinet |
Le projet est en cours. À ce stade, l’architecture data et les parcours applicatifs critiques sont cadrés ; la plateforme continue d’évoluer vers la mise en production.
PostgreSQL
Socle data
Source de vérité métier
100 %
Transmissions tracées
Objectif intégré au modèle
< 15 min
Prise en main visée
Soignants tests
Le client ne disposant pas encore de métriques d’usage post-production consolidées, nous ne communiquons pas de ROI chiffré (temps gagné, volume de patients, etc.). Les indicateurs ci-dessus sont des cibles produit validées avec l’équipe Synapa.
Adaptée notamment à
Contre-indication — Cette approche est excessive pour un simple site vitrine médical ou une landing de prise de rendez-vous sans logique métier de coordination.
PostgreSQL
Source de vérité relationnelle et auditables
Prisma
Modèle typé aligné sur le schéma métier
Next.js 15
Parcours soignants web performants
TypeScript
Réduire les erreurs sur des flux critiques
FHIR / HL7
Cadre d’interopérabilité santé
MSSanté
Échanges sécurisés entre professionnels
Chiffrement HDS
Exigence sectorielle non optionnelle
Offline-first
Usage réel hors connectivité idéale
Un site présente ; une plateforme métier orchestre des données sensibles, des rôles, des transmissions et souvent de l’interopérabilité. Le critère décisif est la traçabilité et la conformité, pas le design.
Parce que les relations patient / soignants / événements / droits d’accès se modélisent naturellement en relationnel, et que l’auditabilité repose sur un schéma explicite plutôt que sur des documents opaques.
Elle impose de traiter hébergement, accès, chiffrement et journalisation comme des contraintes de conception. Les « on verra pour la sécu plus tard » ne passent pas en e-santé.
Non. Le site produit est un support. Le cœur de l’accompagnement porte sur l’architecture applicative, le modèle de données et les parcours soignants de la plateforme.
Aller plus loin
Autres réalisations
Cas stratégique · Sport professionnel
Comment structurer l’écosystème digital d’un club de football professionnel
Cas stratégique · Enseignement supérieur
Comment former plus de 120 étudiants à l’IA générative sans leur apprendre simplement à « utiliser ChatGPT »
Cas performance · Marketing & Innovation
Comment transformer une carte de visite en canal d’acquisition avec un mini-jeu web
Une problématique similaire ?
On regarde votre situation, vos contraintes, et ce qui mérite vraiment d'être construit — sans ROI inventé.