Pilume : le modèle propose, le système vérifie, le pharmacien décide

Flux

1. Patient et médicaments. Le pharmacien saisit le patient, les ordonnances (médicament, dose, fréquence, forme, voie) et la forme de la journée : réveil, repas, coucher.
2. Proposition par le modèle. Un tableau clinique dé-identifié part vers un petit modèle rapide, qui renvoie la journée : chaque prise à une heure, sous sorties structurées.
3. Phrase patient et observations. Le modèle rédige aussi la raison courte que le patient lira telle quelle, et des observations distinctes destinées au pharmacien.
4. Vérification, jamais réparation. Une fonction pure et testée unitairement contrôle la proposition contre les contraintes et transforme chaque écart en constat affiché à côté du plan. Rien n'est corrigé en silence : le pharmacien validerait sinon quelque chose que personne n'a proposé.
5. Porte de validation. L'horaire reste en brouillon tant qu'un pharmacien ne l'a pas explicitement validé. La publication exige le statut validé ; le contrôle vit dans la couche service et route de l'API, pas dans l'interface.
6. Canaux patient. Web (WCAG 2.1 AA, gros caractères, contraste élevé) et mobile (Expo, horaire hors ligne, rappels sur l'appareil). Questions d'interaction pour les produits en vente libre et information sur les effets secondaires, toujours présentées comme une aide à la décision validée par le pharmacien.
7. Alertes et audit. Rappels de prise manquée et de reprise, alertes de suivi pour le pharmacien, et une entrée d'audit en ajout seul pour chaque accès ou modification de données patient.

Portes humaines

La porte de validation du pharmacien est imposée côté serveur et couverte par un test d'intégration non négociable. Pas de statut validé, pas de visibilité patient.

Les pharmaciens se connectent avec MFA (TOTP) ; les patients avec courriel et mot de passe, plus une biométrie optionnelle sur mobile ; des délais de session propres à la santé s'appliquent aux deux.

Ce qui ne part jamais au LLM

Noms, identifiants, dates de naissance, numéros d'identification de médicament. Le modèle voit une tranche d'âge et un tableau clinique ; deux patients au même tableau produisent des requêtes identiques à l'octet près.

Les constats du vérificateur et les observations pour le pharmacien : ce sont ses notes de travail, retirées de tous les canaux patient. Un patient qui lit « duplication thérapeutique possible » lit une conversation professionnelle à son sujet.

Quoi que ce soit sans entrée d'audit : chaque lecture et écriture de données patient est journalisée dans une table immuable, en ajout seul.

Décisions et pourquoi

Pourquoi le modèle propose plutôt qu'un ordonnanceur à règles. La première version calculait les heures avec un solveur déterministe. Il connaissait les séparations et les fréquences, et rien de la personne : ni qu'un diurétique le soir fait tomber quelqu'un à mobilité réduite, ni que deux médicaments font le même travail. Il rangeait des heures ; un pharmacien attendait le deuxième regard d'un collègue.

Pourquoi vérifier plutôt que corriger. Un vérificateur pur, testé unitairement, dit ce qui cloche et laisse la proposition intacte. Corriger en silence reviendrait à faire valider un plan que personne n'a proposé et que rien ne trace, et à reconstruire le solveur qu'on a remplacé.

Pourquoi aucun repli. Si le modèle est indisponible, la génération échoue et le dit. Substituer un plan à règles donnerait au pharmacien une autre chose sous le même nom, sans moyen de faire la différence.

Pourquoi la dé-identification à la source. Loi 25 et LPRPDE. Envoyer une situation clinique plutôt qu'une personne est ce qui rend le pilote défendable, sans rien coûter en qualité.

Pourquoi la porte vit dans l'API. Un bouton caché ne protège rien. Le service qui publie un horaire refuse d'en publier un non validé, quel que soit le client.

Pourquoi un petit modèle. La tâche est bornée et la sortie est un schéma strict, un petit modèle rapide suffit ; ce sont le vérificateur et le pharmacien qui portent la sécurité.

Chiffres

5 applications : API, portail pharmacien, web patient, mobile patient, application de bureau pharmacien.

66 fichiers de tests dans l'espace de travail ; 15 registres de décisions d'architecture.

En pilote dans une pharmacie communautaire du Québec.

Construite en 10 semaines par l'AI Product Factory.

Pile technique

Monorepo TypeScript (pnpm, Turborepo) · NestJS · Prisma sur PostgreSQL · Next.js avec next-intl (français par défaut) · Expo / React Native · Electron avec stockage local chiffré · SDK Anthropic · validation par schéma à chaque frontière d'API