Le contexte
L’un de nos déploiements en clinique gère l’accueil des patients sur un canal de messagerie. Les patients écrivent en langage naturel — demandes de report, questions sur les soins, « est-ce que je peux plutôt venir jeudi après-midi » — et un assistant IA mène la conversation. Le planning de la clinique vit là où la clinique l’a toujours tenu : une grille partagée dans un tableur, maintenue par l’accueil, avec des conventions de créneaux que l’équipe utilise depuis des années.
La construction évidente consiste à laisser le modèle lire le planning et réserver tout ce qui semble libre. Nous n’avons pas construit cela, et les raisons en sont la partie utile de ce billet.
Règle numéro un : le modèle ne décide jamais de ce qui est réservable
Le planning de la clinique encode la politique dans des conventions : certains créneaux sont réservés exclusivement aux visites de suivi et aux consultations, et ils sont marqués visuellement, pas étiquetés dans une base de données. Les soins pour nouveaux patients n’y ont jamais leur place. L’accueil le sait. Un modèle de langage qui lit la grille ne le sait pas — il voit un créneau libre.
La première chose que nous avons livrée n’était donc pas la réservation. C’était un garde-fou strict : les créneaux réservés sont structurellement hors d’atteinte de l’assistant. Pas « instruit de les éviter » — hors d’atteinte, imposé par du code qui s’exécute après le modèle et avant que quoi que ce soit ne touche le planning. On peut argumenter avec un prompt ; pas avec une fonction pure.
C’est l’architecture en une phrase : le LLM extrait, le code déterministe décide. Le modèle excelle à lire « jeudi prochain après 15 h ce serait parfait, même soin que la dernière fois » et à produire une intention structurée : fenêtre demandée, type de soin, identité du patient. Tout ce qui suit est de la logique simple et testable — classification des créneaux, règles d’éligibilité, calcul des durées — écrite sous forme de fonctions pures sur des données, avec des tests unitaires, relue comme n’importe quel autre code.
La sécurité tient dans les détails ingrats
L’essentiel de l’effort d’ingénierie est allé dans des détails qu’aucune démo ne montrerait jamais :
- Les durées des soins viennent de la table de référence de la clinique elle-même. Chaque soin réservable a un temps de préparation et un temps de soin, rapprochés ligne par ligne de la table imprimée de la clinique — y compris la passe où nous avons trouvé et corrigé dix-neuf divergences. L’assistant ne peut pas proposer un créneau où la durée réelle ne tient pas.
- L’heure d’arrivée est dérivée, pas devinée. Le temps de préparation détermine quand le patient doit arriver ; le message de confirmation l’indique. Un jugement de moins pour le modèle, une surprise de moins pour l’accueil.
- Les numéros de téléphone sont écrits en texte. Un tableur avale sans hésiter le zéro initial d’un numéro de téléphone stocké comme nombre. Petit bug, conséquence bien réelle, correctif déterministe.
- L’ambiguïté est routée vers un humain. Quand la demande ne passe pas proprement les garde-fous — une combinaison de soins inhabituelle, un conflit de créneaux que les règles ne peuvent pas résoudre, un patient qui demande quelque chose que la table de politique ne couvre pas — l’assistant n’improvise pas. Il transmet la conversation à une personne, avec le contexte joint. Ce passage de relais est une fonctionnalité, pas un mode de défaillance.
Chaque règle de décision de cette liste existe parce que l’exploitant de la clinique a tranché, que nous avons encodé ce choix, et que l’encodage est désormais inspectable. Quand l’exploitant change une politique, nous changeons une fonction et son test — pas un prompt et un espoir.
Pourquoi nous travaillons ainsi
Il existe une version de ce projet qui se livre en un week-end : donner le planning et un prompt système à un modèle compétent, et le laisser réserver. La démo serait superbe et cela fonctionnerait la plupart du temps. « La plupart du temps », c’est précisément le problème. Le planning d’une clinique est une promesse faite à de vrais patients et à une vraie équipe ; les cas d’échec, ce sont des salles de soin réservées en double et un accueil qui cesse de faire confiance à l’outil après le deuxième incident.
La séparation que nous utilisons — le modèle pour la compréhension, les garde-fous déterministes pour l’autorité, le relais humain pour tout ce qui sort du cadre — coûte plus cher en ingénierie au départ et rend quelque chose qu’un prompt ne peut pas offrir : la logique de réservation est testable avant de toucher un patient, auditable après, et corrigeable en exactement un seul endroit quand la politique change.
Le schéma n’est pas propre aux cliniques. Partout où un assistant IA rencontre une ressource dont d’autres personnes dépendent — un calendrier, un inventaire, un registre comptable — la même ligne s’applique. Laissez le modèle lire. Ne le laissez pas régner.