Notes de stratégie · Santé et sport · 2026

Réservations WhatsApp pour un cabinet de kinésithérapie

Les notes vocales gardées comme dossier clinique, l’onboarding réduit à un fichier de configuration, et un modèle qui ne détient jamais l’état d’une réservation.

Contexte

Une salle de sport doublée d’un cabinet de kinésithérapie, avec trois sites et un seul numéro de téléphone, premier client d’une plateforme multi-clients de réservation et de prise de contacts sur WhatsApp. La plateforme tourne en production depuis septembre 2026.

Point de départ

Les demandes de réservation étaient traitées à la main. Les personnes qui écrivent envoient des notes vocales dans un dialecte arabe régional mêlé d’anglais et de français. Trois types de personnel partagent un tableau de bord : l’accueil sur un ordinateur commun, les kinés et les coachs sur leur téléphone entre deux séances, et la direction, souvent sur mobile.

Décision

Le modèle propose, le code décide. Le modèle suggère des valeurs de champs et des réponses. Du code déterministe gère les changements d’état, les contrôles, la complétude et le statut. La règle du projet est simple : ne jamais laisser le modèle détenir l’état.

  • Garder les mots exacts du patient. L’arabe reste en écriture arabe, l’anglais et le français restent tels quels. C’est le dossier clinique du cabinet, donc rien n’est traduit.
  • Une seule lecture audio native, pas une transcription suivie d’une devinette. Elle rend les mots, un court résumé et des indices d’orientation, chacun avec un niveau de confiance. Une confiance faible sur un champ d’orientation déclenche une brève question de confirmation plutôt qu’une mauvaise réservation.
  • L’audio reste réécoutable dans le tableau de bord, parce que le ton et la gravité ne passent pas à l’écrit.
  • Un nouveau client, c’est un fichier de configuration validé par un schéma, puis une commande.

Preuve

Deux niveaux de tests, séparés exprès. Le premier fait passer des conversations scriptées dans la vraie pile technique, sans coût de modèle. Le second joue des scénarios réels avec un patient simulé et un modèle juge, plafonnés par défaut à 5 dollars par passage : 31 cas écrits à la main et 102 générés. Le juge est lui-même contrôlé, avec un seuil de 90 % de vrais négatifs et 80 % de vrais positifs. Je n’ai pas de chiffre sur les réservations traitées ni sur le temps gagné.

Où l’IA intervient

Le bot utilise un modèle pour la conversation et pour comprendre les notes vocales. Les tests utilisent un modèle qui joue le patient, un modèle qui juge la réponse, et un générateur de cas orienté vers les manques de couverture plutôt que vers le volume.

Temps gagné : non mesuré.

Livrables

  • Plateforme multi-clients sur AWS
  • Tableau de bord du personnel : demandes, revue rapide, rendez-vous, clients, export CSV
  • Commande d’onboarding et schéma de configuration
  • Suites de tests : bout en bout, scénarios réels, comparaison vocale, calibrage du juge
  • Cartographie de parcours, revues produit et UX, runbook

Retour aux travaux