Sur l’écran, tout fonctionne. Le compte rendu apparaît, l’alerte remonte, le parcours patient semble enfin fluide. Puis vient le lundi matin dans un service : connexion impossible, identité mal rapprochée, infirmière déjà débordée. Pour une jeune entreprise de santé, c’est ici que commence le véritable produit. À l’horizon de septembre 2026, la question décisive n’est plus seulement de prouver qu’une technologie peut aider. Elle est de montrer qu’elle peut entrer dans les soins sans désorganiser ceux qui les assurent.
La démonstration convainc, le déploiement engage
Une démonstration maîtrise son environnement : données choisies, utilisateurs préparés, scénario sans interruption. Le terrain impose l’inverse. Les informations arrivent incomplètes, plusieurs professionnels interviennent et les systèmes ne parlent pas toujours le même langage. Une solution peut réussir son test technique tout en ajoutant une tâche que personne n’a le temps d’effectuer.
La télésurveillance illustre cette différence. Recueillir une mesure à domicile n’est qu’une étape. Il faut décider qui consulte les alertes, dans quel délai, avec quel relais en cas d’absence et quelle trace dans le dossier. Son entrée dans le droit commun du remboursement en France, en 2023, a matérialisé une évolution importante : derrière l’outil connecté, c’est une activité médicale organisée qu’il faut financer et faire fonctionner.
Le premier déploiement est donc une épreuve entrepreneuriale autant que clinique. Il révèle le coût d’installation, la charge de support, les adaptations nécessaires et la dépendance à quelques personnes motivées. Autrement dit, il teste ce que la présentation commerciale laisse généralement hors champ : la capacité à reproduire le service sans réinventer l’entreprise chez chaque client.
L’interopérabilité se mesure au travail évité
Dans un établissement, une application supplémentaire peut devenir une fenêtre supplémentaire. Si le soignant doit rechercher le patient, recopier ses antécédents puis transférer manuellement le résultat, le bénéfice annoncé s’érode. L’interopérabilité n’est pas un bonus technique : c’est souvent la condition pour que la solution soit effectivement utilisée.
Les standards tels que HL7 FHIR facilitent les échanges structurés. DICOM reste central pour l’imagerie. Mais afficher leur prise en charge ne suffit pas. Deux logiciels peuvent employer un même standard sans partager les mêmes champs, règles de codage ou versions. Il faut aussi gérer les droits d’accès, les doublons et les erreurs silencieuses, plus dangereuses qu’une panne visible.
En France, le Ségur du numérique en santé, l’Identité nationale de santé et les services associés à Mon espace santé ont renforcé l’importance de cet environnement commun. Pour un entrepreneur, la leçon est simple : partir des référentiels et des interfaces réellement disponibles chez le client, plutôt que dessiner un parcours idéal puis demander à l’établissement de s’y adapter.
Choisir un périmètre étroit, mais complet
Un premier projet gagne à traiter un seul usage de bout en bout : une population définie, un service, un circuit de validation. Mieux vaut un résultat correctement intégré au dossier qu’une plateforme couvrant dix fonctions isolées. Le contrat doit préciser qui construit le connecteur, qui le maintient et ce qui se passe lorsque le logiciel métier change.
Les données sensibles ne tolèrent pas l’improvisation
La protection des données commence avant leur collecte. Quelles informations sont indispensables ? Pour quelle finalité ? Pendant combien de temps ? Qui peut les consulter ? Ces questions dessinent l’architecture du produit. Les repousser jusqu’à la signature expose à découvrir qu’un prototype repose sur des usages de données incompatibles avec son exploitation réelle.
Le RGPD impose notamment de clarifier les rôles et les bases juridiques du traitement. Le consentement n’est pas une réponse universelle à toutes les opérations réalisées dans le cadre des soins. Une analyse d’impact peut être requise, notamment pour certains traitements à grande échelle de données de santé. L’entrepreneur doit travailler avec le délégué à la protection des données, pas lui transmettre un dossier figé.
En France, le recours à un hébergeur certifié HDS s’impose dans les situations prévues par le cadre applicable à l’hébergement de données de santé. Cette certification ne rend pas, à elle seule, toute l’application conforme ou sûre. Authentification, journalisation, sauvegardes, gestion des habilitations et réponse aux incidents restent à organiser. Les éventuels transferts internationaux demandent également une analyse spécifique.
L’IA ajoute une question concrète : les données servent-elles uniquement à produire le service demandé, ou aussi à améliorer un modèle ? Il faut distinguer ces finalités et encadrer les sous-traitants. Le règlement européen sur l’intelligence artificielle, adopté en 2024, prévoit une application progressive. Selon l’usage et la qualification du produit, ses exigences peuvent se combiner avec celles des dispositifs médicaux : le calendrier réglementaire doit entrer dans le plan de développement.
Le véritable acheteur est une organisation
Le médecin enthousiaste ouvre la porte, mais il ne détient pas nécessairement le budget, les accès informatiques ou le pouvoir de modifier les procédures. Direction des systèmes d’information, achats, équipes de soins, responsables de sécurité et direction financière regardent chacun un risque différent. Leur implication précoce évite qu’une expérimentation appréciée reste sans lendemain.
Il faut surtout nommer le travail nouveau. Qui forme les remplaçants ? Qui répond au patient perdu devant son interface ? Qui vérifie une suggestion algorithmique ? Une promesse de temps gagné peut masquer un transfert de charge vers un autre métier. L’évaluation doit donc observer le parcours entier, et pas uniquement les minutes économisées par l’utilisateur principal.
Un scénario de panne fait partie du produit. Lorsque le service devient indisponible, l’équipe doit savoir comment continuer les soins et récupérer les informations utiles. La possibilité de revenir à une procédure dégradée, sans perte de données ni ambiguïté de responsabilité, rassure davantage qu’une promesse abstraite de disponibilité permanente.
Transformer le pilote en décision d’achat
Avant de lancer l’expérimentation, les partenaires devraient définir les conditions de sa sortie. Quel résultat justifiera une extension ? Qui décidera ? Quel budget prendra le relais ? Sans ces réponses, le pilote risque de devenir une démonstration prolongée, financée par la trésorerie de la jeune entreprise.
Quelques indicateurs bien choisis valent mieux qu’un tableau de bord spectaculaire :
- L’usage réel par les professionnels concernés, au-delà des premiers volontaires.
- Le temps total consacré au parcours, y compris les corrections et le support.
- Les incidents, les alertes inutiles et les éventuelles conséquences sur la sécurité.
- Le coût complet du déploiement et de son maintien.
Ces mesures ne remplacent pas une évaluation clinique lorsque celle-ci est nécessaire. Elles montrent si le bénéfice peut survivre aux conditions ordinaires. Pour l’entreprise, elles permettent aussi de calculer une marge réaliste, intégrant les connecteurs, la formation et l’accompagnement, plutôt qu’un simple coût d’abonnement logiciel.
Et maintenant ? Dans la perspective de septembre 2026, l’avantage pourrait aller aux jeunes entreprises capables de vendre moins de magie et davantage de continuité. L’hypothèse est simple : à mesure que les outils numériques se multiplient, les établissements devraient privilégier ceux qui s’intègrent, documentent leurs risques et allègent réellement le travail. Le premier déploiement ne sera alors plus la dernière diapositive du financement. Il en deviendra la preuve centrale.
