Pilume : une IA qui explique un horaire de médication mais ne le décide jamais

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. Ordonnancement déterministe. Un ordonnanceur testé unitairement attribue les heures de prise à partir des contraintes de moment et d'interaction de la base curée d'interactions médicamenteuses (médicament-médicament, médicament-aliment, séparation minimale).
3. Justification clinique. Claude Haiku reçoit un tableau clinique dé-identifié (tranche d'âge, sexe, conditions, allergies, médicaments, interactions connues présentées comme des faits) et rédige la justification en langage clair pour chaque médicament. Il ne fixe jamais une heure.
4. Vérification. Chaque créneau proposé est revérifié contre les contraintes avant d'atteindre le pharmacien ; un ensemble insatisfiable est signalé, pas résolu en silence.
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 décisions de moment. L'ordonnanceur décide ; le modèle explique.

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 un moteur hybride. Testabilité et responsabilité clinique. Un ordonnanceur à règles se prouve ; un modèle de langage ne peut qu'être relu. Le modèle reçoit donc la partie qui gagne à être formulée en langage, et rien de la partie qui exige une preuve.

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 justification est courte et bornée ; Haiku est rapide et peu coûteux, et la couche déterministe porte le risque.

Chiffres

5 applications : API, portail pharmacien, web patient, mobile patient, application de bureau pharmacien ; 2 paquets partagés.

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

Cibles du pilote : 99 % de disponibilité pendant les heures du pilote, pilote sur une pharmacie avec quelques dizaines d'utilisateurs.

Construite en 10 semaines (142 commits) 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 (Claude Haiku) · Zod à chaque frontière d'API