Aller au contenu principal

Sur-mesure

Santé et hospitalisation à domicile : un outil métier doit d'abord prouver, ensuite seulement être pratique

par Paul Mantez, Co-fondateur & Développeur

Schéma : chaque livraison produit une preuve tracée, consentements, photos et signature, versée dans un journal exportable, le papier étant écarté

Dans beaucoup de structures de santé, l'organisation quotidienne repose sur un tableur partagé. Un onglet par journée, des adresses saisies à la main, des appels téléphoniques pour savoir où aller. Ça tient, parfois pendant des années, parce que les équipes compensent.

Ce qui ne tient pas, c'est la preuve. Une autorité de contrôle ne demande pas si la journée s'est bien passée, elle demande de montrer ce qui a été remis, à qui, avec quel consentement, et qui a signé. À cette question, un tableur ne répond pas.

Cet article part d'une application que nous avons conçue et mise en production en 2026 pour une pharmacie parisienne spécialisée en hospitalisation à domicile, qui livre chaque jour des traitements à des patients hospitalisés chez eux. Le client n'est pas nommé, le secteur étant régulé et les données sensibles. Les principes, eux, valent pour tout outil métier en santé.


Le problème n'est pas l'organisation, c'est la trace

Au départ, la demande ressemble à un besoin d'organisation : affecter des commandes à des livreurs, ordonner une tournée, éviter les appels. Ce sont de vrais sujets, et ils se règlent.

Mais le sujet sérieux est ailleurs. À l'arrivée chez le patient, la preuve de livraison tenait sur un papier, alors que l'Agence Régionale de Santé exige une traçabilité stricte : consentements, identité du signataire, justificatifs. Un papier se perd, ne se recherche pas, et ne se transmet pas.

La question qui structure tout le projet devient donc : qu'est-ce qu'on doit pouvoir montrer, et combien de temps après ? Tant qu'elle n'a pas de réponse écrite, il est inutile de dessiner des écrans.


Ce qu'une preuve doit contenir

Pour cette application, chaque remise produit quatre consentements distincts, des photos compressées des justificatifs, une signature tactile et l'identité de la personne qui signe, qui n'est pas toujours le patient. Le tout alimente un journal exportable.

Trois propriétés rendent cette preuve utile, et leur absence la rend décorative.

Horodatée et rattachée. Une photo dans une galerie de téléphone ne prouve rien. La même photo attachée à une livraison identifiée, avec son heure, prouve quelque chose.

Complète au moment de la remise. Une preuve complétée le soir, de mémoire, n'en est pas une. Le formulaire doit donc être remplissable là où l'on se trouve, ce qui ramène directement à l'ergonomie.

Exportable. C'est le critère le plus souvent oublié. Si la preuve ne peut pas sortir du logiciel pour être transmise, elle ne sert qu'à rassurer en interne.


L'ergonomie n'est pas un supplément, c'est ce qui rend la preuve possible

On pourrait croire que dans un métier réglementé, le confort d'usage passe après. C'est l'inverse : un formulaire pénible est un formulaire rempli plus tard, donc mal, donc une preuve fragile.

Les contraintes réelles sont physiques. L'application s'utilise debout, souvent avec des gants, parfois dans une cage d'escalier sans réseau. Ce qui en découle :

  • une application pensée pour le téléphone d'abord, avec de grandes zones tactiles ;
  • une tournée du jour dans un ordre unique, partagé avec l'équipe restée au comptoir, pour que tout le monde parle de la même séquence ;
  • une barre « prochain arrêt », la navigation et l'appel du patient accessibles en un geste ;
  • un formulaire de livraison sauvegardé en brouillon local, pour qu'une coupure de réseau ne fasse jamais perdre une saisie.

Ce dernier point est celui qui change le plus le vécu des équipes. Perdre dix minutes de saisie une fois suffit à créer une défiance durable envers un outil.


L'authentification sur des appareils partagés

En santé, les appareils sont partagés et les écrans restent allumés au comptoir. Deux exigences se contredisent en apparence : protéger les données et ne pas transformer chaque connexion en épreuve.

La réponse retenue : une connexion par prénom et code personnel sur des appareils enrôlés, plutôt que des mots de passe longs tapés des dizaines de fois par jour, complétée par un verrouillage automatique des postes partagés. L'appareil est connu, la personne est identifiée, l'écran ne reste pas ouvert.

C'est un compromis assumé, et c'est le genre de décision qui doit être prise explicitement, avec le responsable de la structure, plutôt que subie par défaut.


Reprendre l'historique sans arrêter l'activité

Une pharmacie ne peut pas suspendre ses livraisons le temps d'une migration. La bascule s'est donc faite en parallèle : le tableur historique a été importé, puis synchronisé journée par journée jusqu'au basculement définitif.

Concrètement, l'équipe travaille dans la nouvelle application tout en gardant l'ancien fichier comme filet, et on ne coupe que lorsque plus personne n'y revient. Sur cette mise en service, ce sont environ mille deux cents patients et trois mille commandes qui ont été repris, avec une recherche et un historique qui n'existaient pas auparavant.

Cette prudence n'est pas propre à la santé, mais elle y est non négociable : une journée de livraison manquée n'est pas un incident informatique.


Le volet financier, souvent oublié au cadrage

Dernier point, rarement présent dans les demandes initiales et pourtant structurant : l'argent encaissé sur place. Espèces et chèques notés à la main, dettes patients non suivies, personne qui sache en fin de journée ce qui a été collecté.

Chaque patient dispose donc d'un compte : une livraison non réglée crée une dette, soldable par le livreur sur place ou par la structure à distance. Le responsable voit les débiteurs, la caisse de chaque livreur et un récapitulatif en fin de journée.

Ce n'est pas de la comptabilité, c'est de la traçabilité de terrain. Et elle suit exactement la même règle que la preuve de livraison : ce qui n'est pas saisi au moment où ça se passe n'existe pas.


Questions fréquentes

Pourquoi un tableur ne suffit-il plus pour organiser des livraisons de santé ?

Parce qu'il ne prouve rien. Un tableur organise une journée, mais il ne garde ni le consentement recueilli, ni l'identité de la personne qui a signé, ni la photo du justificatif. Le jour où il faut retrouver ce qui s'est passé lors d'une livraison précise, six mois plus tôt, il n'y a rien à montrer. C'est cette absence de preuve qui pose problème, bien avant le confort d'usage.

Que doit contenir une preuve de livraison dans un contexte réglementé ?

Au minimum : les consentements recueillis, l'identité de la personne qui reçoit, une signature, et les justificatifs photographiés quand ils sont exigés. Le tout horodaté, rattaché à la livraison concernée, et surtout exportable : une preuve qu'on ne peut pas sortir du logiciel pour la transmettre à l'autorité de contrôle ne remplit pas son rôle.

Comment concevoir une application utilisable sur le terrain par des livreurs ?

En partant des contraintes physiques réelles : on l'utilise debout, souvent avec des gants, parfois avec un réseau dégradé dans une cage d'escalier. Cela impose de grandes cibles tactiles, un ordre de passage unique partagé avec l'arrière-boutique, une action évidente vers l'arrêt suivant, et une sauvegarde locale des saisies pour qu'une coupure de réseau ne fasse jamais perdre un formulaire.

Comment gérer l'authentification sur des appareils partagés ?

Par une connexion courte sur des appareils enrôlés, par exemple un prénom et un code personnel, plutôt que par des mots de passe longs saisis dix fois par jour sur un téléphone. Le complément indispensable est le verrouillage automatique des postes partagés, pour que l'écran ne reste pas ouvert sur des données patient au comptoir.

Peut-on reprendre un historique de tableur sans interrompre le service ?

Oui, en important l'historique puis en synchronisant jour après jour jusqu'à la bascule. Les deux systèmes coexistent quelques semaines, l'équipe travaille dans le nouveau tout en gardant l'ancien comme filet, et on ne coupe que lorsque plus personne n'y revient. C'est plus long qu'une bascule sèche, et bien moins risqué sur une activité quotidienne.

Combien de temps faut-il pour mettre en service ce type d'application ?

Quelques mois entre le premier atelier et la production, la durée dépendant surtout du nombre de règles métier et du périmètre de reprise. Ce qui prend le temps n'est pas le développement des écrans, ce sont les décisions : quelles preuves sont exigées, qui a le droit de faire quoi, et comment se comporte l'application quand le réseau, l'adresse ou le patient ne sont pas conformes à ce qui était prévu.


En santé, un bon outil métier ne se reconnaît pas à ses écrans. Il se reconnaît à ce qu'il peut montrer six mois plus tard, et au fait que les équipes l'utilisent quand même, debout, avec des gants, un vendredi soir.

Votre activité régulée tourne encore sur un tableur partagé ? On commence par ce que vous devez pouvoir prouver →

Plus d'articles

Mettre en place le click & collect dans un commerce artisanal : ce qu'il faut vraiment, et ce qui ne sert à rien

Stock qui dit vrai, paiement en ligne, créneau que la production peut tenir, préparation qui suit : les quatre briques d'un click & collect artisanal.

Voir plus

Connecter Sage X3 et Salesforce sans connecteur payant : la passerelle par fichiers plats

Catalogue, tarifs, stocks et commandes de Sage X3 dans Salesforce chaque nuit, sans abonnement : exports planifiés, SFTP, upsert par clé externe.

Voir plus

Nous contacter

Un projet ? Parlons-en.

On répond en moins de 24h.