Solo Consult Booking Kit — Kit de réservation de consultations…

Kit de réservation de consultations pour cabinet solo — Réservation de première consultation pour un praticien solo

⚠️ À lire en premier — le prérequis HIPAA (avant toute construction)

Ce système n'est compatible HIPAA que s'il fonctionne dans un compte Google Workspace avec un Business Associate Agreement (BAA) signé. Ne construisez, ne déployez et n'insérez aucune donnée réelle de client avant que tous les points suivants ne soient vérifiés :

1. Vous disposez de Google Workspace (Business Starter, Standard, Plus, ou une édition couverte équivalente) sur votre propre nom de domaine professionnel — pas un compte Gmail personnel gratuit (@gmail.com). Un compte personnel ne permet pas de signer un BAA et ne doit jamais héberger ce système ou ses données.
2. Le BAA Google Workspace est signé. Dans la console d'administration Google (Admin → Compte → Juridique / « Avenant au contrat de service d'entreprise associé » — le nom exact du menu change avec le temps), révisez et acceptez le BAA pour Google Workspace / Cloud Identity, et conservez une trace de la date. La signature est un clic unique effectué par un administrateur Workspace ; si vous ne le trouvez pas, arrêtez-vous et résolvez cela d'abord — ne présumez pas que la couverture est en place.
3. Tout se trouve dans ce compte Workspace. Les projets Apps Script, le tableur de réservation, le calendrier qui reçoit les consultations, et la boîte aux lettres qui envoie les confirmations doivent tous appartenir au même utilisateur Workspace (vous). N'utilisez aucune partie de ce système sur un compte Google personnel, et ne dirigez pas les réservations vers un calendrier personnel — un compte personnel se trouve en dehors du BAA.
4. Le durcissement du compte est activé : la validation en deux étapes est appliquée pour le compte (les clés de sécurité / la Protection Avancée sont meilleures), un mot de passe fort et unique dans un gestionnaire de mots de passe, et des options de récupération que vous contrôlez.

Un logiciel ne peut pas être « certifié HIPAA », et ce kit ne rend pas un cabinet conforme HIPAA par lui-même. Il est construit avec des garanties compatibles HIPAA (minimisation des données, liens de gestion hachés et à durée limitée, événements de calendrier génériques, nettoyage des données, journal d'audit — voir references/security-and-hipaa.md), et il fonctionne sur un fournisseur (Google) qui signe un BAA. La conformité exige également votre propre analyse des risques, des politiques, une formation et un avis de pratiques de confidentialité. Si l'un des prérequis ci-dessus manque, la première tâche de l'agent est d'aider le propriétaire à le résoudre — pas de construire les applications.

Objectif

Offrir à un clinicien solo le système de réservation utilisé par un cabinet de groupe, sans la complexité du groupe :

• Partie A — Application de réservation publique. Une page web publique (intégrée sur le site web du cabinet) où un client potentiel répond à une brève vérification de compatibilité (état, paiement, pour qui est la consultation, langue), voit uniquement les créneaux réellement disponibles — vos heures de consultation déclarées moins les occupations réelles de votre calendrier, vos congés et les réservations existantes — et réserve une première consultation gratuite (15 minutes par défaut ; configurable). Le client reçoit un email de confirmation avec un fichier .ics et un lien privé de report/annulation ; vous recevez une notification minimale. Les rappels (~24h avant) et les suivis post-consultation sont déclenchés par une minuterie.
• Partie B — Console propriétaire (une application, trois vues). Une application privée protégée par un code PIN que vous seul utilisez, fusionnant ce qu'un cabinet de groupe répartit sur trois applications :
  • Mes consultations — consultations à venir / passées / annulées, détails complets au clic, marquer une consultation passée comme non-présentée.
  • Disponibilités — définir les heures de consultation hebdomadaires (jours fractionnés autorisés), les heures spécifiques à une date, les congés, l'activation/désactivation de l'acceptation de nouveaux clients, et les paramètres de réservation (limite de fréquence par consultation, préavis minimum, marges, pas de réservation) ; voir vos disponibilités résolues et les 7 prochains jours de créneaux ouverts exactement comme la page de réservation les calcule.
  • Paramètres et outils — modifier chaque modèle d'email et chaque règle de réservation sans toucher au code, voir les statistiques de réservation et la piste d'audit, exporter les audits / réservations en CSV (jamais les jetons de gestion).

Implémentation de référence : deux applications web Google Apps Script alimentées par un tableur et votre propre Google Calendar. Pas de service de réservation tiers, pas d'analytique, pas de traqueurs.

Ce que l'édition solo abandonne délibérément (groupe → solo)

• Pas d'application « Connectez votre calendrier ». Dans un cabinet de groupe, cette application existe pour une seule raison : chaque prestataire, connecté en tant que lui-même, partage son calendrier avec le compte central du cabinet avec l'autorisation « Apporter des modifications aux événements » et enregistre l'ID du calendrier dans le système de réservation. Un propriétaire solo est le propriétaire du script et le propriétaire du calendrier — l'application de réservation fonctionne déjà en votre nom, avec un accès propriétaire à votre calendrier. Il n'y a rien à partager et rien à enregistrer. La configuration consiste simplement à : mettre l'ID de votre calendrier dans l'onglet Config (l'ID de votre calendrier principal est simplement votre adresse email ; ou créez un calendrier dédié « Premières consultations » dans le même compte Workspace et utilisez son ID), puis exécuter la fonction intégrée checkSetup() et confirmer qu'elle indique accessRole=owner et freebusy=OK.
• Pas de classeur de registre des prestataires ni de synchronisation du registre. Un clinicien = une ligne Config contenant le nom, les références, les États agréés, les panels, les langues, les tranches d'âge desservies, le tarif dégressif, le lien bio, le fuseau horaire, l'ID du calendrier. Pas de travail de synchronisation, pas d'ID de prestataire transmis à d'autres.
• Pas de moteur de correspondance/orientation des prestataires. L'assistant de groupe oriente un client vers le bon clinicien. L'assistant solo vérifie uniquement l'adéquation avec vous : mauvais État, un panel que vous n'acceptez pas, une tranche d'âge que vous ne servez pas, ou pas de tarif dégressif quand c'est requis → un message clair de non-adéquation avec votre email de contact, jamais une impasse.
• Rien de multi-prestataire : pas de codes PIN par prestataire dans un registre partagé (un code PIN propriétaire, haché, dans l'onglet Config), pas de « modifier au nom de », pas de filtre par prestataire, pas de congés à l'échelle du cabinet (vos congés sont simplement vos congés).

Remettre ceci à votre agent (pour le collègue qui reçoit ce kit)

Ce kit est indépendant de la plateforme : c'est du Markdown simple (le format ouvert Agent Skills) et fonctionne avec n'importe quel agent IA capable — un agent qui charge des compétences, un agent de codage avec un espace de travail, ou un agent de chat avec les fichiers téléchargés. Le fichier README.md dans ce dossier contient les instructions par plateforme et PROMPT.md contient une invite de démarrage à copier-coller ; les deux chemins mènent au même endroit :

1. Confirmer que le prérequis HIPAA en haut est rempli (Workspace + BAA signé + durcissement). Si ce n'est pas le cas, faites-le d'abord.
2. Répondre à l'entretien de configuration ci-dessous — l'agent doit demander une fois, avant de construire.
3. Laisser l'agent construire et tester les deux applications, exécuter la liste de contrôle de test dans references/test-checklist.md avec des réservations de test, et ensuite seulement remplacer vos liens publics par la nouvelle page de réservation.

Conservez votre ancien lien de réservation (si vous en avez un) comme solution de repli jusqu'à ce que la liste de contrôle de test soit réussie de bout en bout.

Instructions pour l'agent qui construit ceci (toute plateforme)

• Travaillez à partir de ces fichiers, pas de la mémoire de systèmes similaires. Lisez ce fichier et chaque référence avant d'écrire du code. Là où une référence et l'instruction en direct du propriétaire sont en conflit, l'instruction du propriétaire prévaut et la modification est consignée par écrit.
• Votre livrable est des fichiers + des étapes vérifiées, quels que soient vos outils. Produisez chaque projet sous forme de fichiers prêts à être collés (Code.gs, Index.html, Manage.html le cas échéant, appsscript.json). Si vous avez un accès direct au compte Google du propriétaire ou à une API/voie de déploiement Apps Script, vous pouvez déployer — mais seulement avec l'accord du propriétaire, et vous vérifiez toujours à partir du résultat servi. Si vous n'avez pas cet accès (la plupart des agents de chat ne l'ont pas), remettez les fichiers et guidez le propriétaire à travers references/setup-and-deploy.md clic par clic : la connexion Google, l'autorisation des portées et les actions de déploiement sont à effectuer par le propriétaire, et un agent qui ne peut pas les effectuer doit le dire clairement plutôt que de laisser entendre qu'il a déployé quelque chose.
• Testez dans les formes qu'utilisera la production. Construisez un banc d'essai local qui simule la couche tableur/calendrier et appelle chaque fonction serveur avec les exactes formes d'arguments que le client livré envoie. Exécutez-le après chaque modification de code, pas seulement à la fin.
• N'exigez jamais de fonctionnalité spécifique à un fournisseur. Tout ici est Google Apps Script + Sheets + Calendar + Gmail plus Markdown. Si votre plateforme offre une commodité (une intégration de déploiement, un outil de fichier), utilisez-la, mais la construction ne doit pas en dépendre — le même kit doit fonctionner pour le prochain propriétaire sur un agent différent.

Entretien de configuration (recueillir une fois, noter, ne jamais deviner)

• Prérequis : domaine Workspace, le compte qui possédera tout (par exemple, [email protected]), BAA signé (date), validation en deux étapes activée.
• Cabinet : nom du cabinet, votre nom + titres tels que les clients doivent les voir, email de contact du cabinet, email de notification (peut être le même), URL du site web, URL de la politique de confidentialité.
• Calendrier : calendrier principal, ou un calendrier de consultation dédié dans le même compte ? Son ID va dans Config. (Recommandé : calendrier dédié — les événements de consultation restent visuellement séparés, et vous pouvez partager les disponibilités de ce calendrier sans exposer le contenu de votre calendrier principal. Dans les deux cas, l'application ne lit jamais que les disponibilités et écrit des événements de consultation génériques.)
• Profil d'adéquation (pilote les options de paiement/éligibilité de l'assistant — généré à partir de Config, jamais codé en dur dans la page) : États dans lesquels vous êtes agréé ; panels d'assurance, PAE et fonds que vous acceptez (noms exacts destinés aux clients) ; auto-paiement et tarif dégressif (oui/non, et toute formulation de seuil que vous utilisez publiquement) ; langues dans lesquelles vous proposez une thérapie ; qui vous servez (adultes / adolescents / enfants / couples / familles) ; si vous voyez des clients situés en dehors des États-Unis (si oui : les consultations sont toujours gratuites, mais la thérapie continue est en auto-paiement/tarif dégressif uniquement — l'assistant restreint les options de paiement en conséquence).
• Règles de réservation (valeurs par défaut du système de référence — confirmer ou modifier) : durée de la consultation 15 min ; fenêtre de réservation 14 jours ; préavis minimum 12 heures ; grille de créneaux toutes les 30 minutes ; marge de 10 minutes autour des événements occupés ; délai d'annulation/report 4 heures ; rappel 24h avant ; suivi post-consultation 5 minutes après la fin de la consultation ; une consultation active par email/téléphone du client (protection contre les doublons activée).
• Disponibilités initiales : vos premières heures de consultation hebdomadaires + fuseau horaire, afin que la page ait de vrais créneaux dès le premier jour. (Vous les maintiendrez ensuite dans la Console.)
• Rédaction des emails : modèles de confirmation, rappel et suivi (jetons comme {ClientFirstName}, {EventDateTime}, {ProviderName}) ; le lien d'enquête/prochaines étapes vers lequel pointe l'email de suivi ; le nom/l'adresse de l'expéditeur (votre adresse, ou un alias d'envoi sur votre compte tel que [email protected] — les alias nécessitent une portée OAuth supplémentaire, voir la référence de déploiement).
• Image de marque : l'apparence de votre site web pour la page publique (polices, couleur du texte, couleur d'accentuation pour les boutons/liens, style des coins). La page publique utilise un style de site web plat — pas de verre/aurore portail, pas de marque Google, pas de boîtes de dialogue natives du navigateur.
• Langue(s) : anglais uniquement, ou bilingue ? Le système de référence prend en charge une deuxième langue complète (un jeu de questions traduit, des emails dans la langue que le client a choisie lors de la réservation). Ajoutez-la uniquement si vous servez effectivement des clients dans cette langue.
• Avis de confidentialité : le texte de confidentialité court du formulaire de réservation que les clients doivent accepter (ce qui est collecté, que l'email n'est pas surveillé pour les urgences, ligne de crise 988 / 911 aux États-Unis). Chaque réservation enregistre l'horodatage de l'accord + la version de l'avis. Incrémentez la chaîne de version à chaque modification du texte.

Comment tout s'assemble (un paragraphe)

Les deux applications fonctionnent en votre nom (USER_DEPLOYING) à l'intérieur de votre compte Workspace. L'application de réservation est publique et anonyme : les visiteurs ne voient jamais le tableur ni aucun détail du calendrier — la disponibilité est calculée uniquement à partir des disponibilités. Une réservation, effectuée sous un verrou de script afin que deux visiteurs ne puissent pas prendre le même créneau, écrit une ligne dans l'onglet Rendez-vous, crée un événement à titre générique (« Première consultation — », description minimale, aucun participant client) sur votre calendrier, et envoie un email au client (confirmation + .ics + lien de gestion privé, jeton stocké uniquement sous forme de hachage SHA-256) et à vous (minimum de triage, pas de nom de client dans l'objet). Une minuterie de 5 minutes envoie les rappels et les suivis et exécute le nettoyage des données. La Console est protégée par un code PIN, lit/écrit le même classeur, et est le seul endroit où les détails complets de la réservation sont consultés. Modèle de données complet et règles de priorité : references/architecture.md.

Ordre de construction (ne pas réorganiser)

1. Classeur + application de réservation selon references/booking-app-spec.md et references/setup-and-deploy.md (créer la feuille, exécuter setupSheet(), checkSetup(), setupTriggers(), déployer).
2. Application Console selon references/console-app-spec.md (protection par code PIN, Mes consultations, Disponibilités, Paramètres et outils) avec le même classeur.
3. Test avec references/test-checklist.md — véritable réservation de test de bout en bout, tentative de double réservation, report/annulation via le lien envoyé par email, chemin de non-adéquation, rappel/suivi manuellement.
4. Mise en ligne : intégrez l'application de réservation sur la page de réservation de votre site web, remplacez les liens publics, conservez l'ancien lien comme solution de repli jusqu'à ce qu'une véritable réservation soit passée sans problème.

Règles strictes pour l'agent (ce sont les leçons coûteuses)

• Portées : déclarez la portée complète https://www.googleapis.com/auth/spreadsheets chaque fois que le code appelle SpreadsheetApp.openById — la portée en lecture seule fait échouer tous ces appels. Si l'application envoie du courrier avec à la fois GmailApp et MailApp, déclarez les deux gmail.send et script.send_mail (gmail.send seul ne couvre pas MailApp, et les échecs sont avalés par try/catch — le courrier n'est jamais envoyé en silence). L'envoi depuis un alias d'envoi via GmailApp nécessite également gmail.settings.basic. Les fonctionnalités du calendrier nécessitent le service avancé Calendar (v3) activé dans le manifeste.
• Déploiements : après le premier déploiement, mettez toujours à jour le déploiement existant vers une Nouvelle version. Ne créez jamais un nouveau déploiement — une nouvelle URL brise chaque intégration et chaque lien, et l'ancienne URL continue de servir l'ancien code. Lisez le contenu déployé / vérifiez le markdown servi.