La personne qui réserve n’a rien signé chez vous
Un agenda de réservation a une particularité que les autres sources n’ont pas. Les gens qui remplissent le formulaire sont extérieurs à votre entreprise, ils n’ont jamais entendu parler de Kastel, et ils ont donné leur nom et leur adresse mail pour obtenir un créneau avec vous.
Beaucoup d’entre eux écrivent aussi le reste. Le champ libre du formulaire est l’endroit où un prospect raconte son problème, où un candidat explique pourquoi il cherche, où un client mécontent résume ce qui s’est passé. C’est de l’information de valeur, et elle ne vous appartient pas.
Le connecteur Calendly tranche ce point avant que la question du réglage se pose. Ni l’identité de la personne qui réserve ni ses réponses au formulaire n’entrent dans votre Kastel. Et un rendez-vous jugé personnel est écarté avant la moindre écriture, par un modèle que vous branchez avec vos propres clés.
Le connecteur n’a aucune méthode pour lire les invités
Chez Calendly, l’identité des invités ne vit pas avec le rendez-vous, elle se lit par une requête distincte. Le client de lecture du connecteur expose exactement deux requêtes, vérifier que la clé d’accès fonctionne et lister les rendez-vous. Celle qui ramènerait les invités n’a jamais été écrite, donc elle n’est pas désactivée par une option que quelqu’un rouvrirait un jour.
Les réponses au formulaire voyagent avec les invités chez Calendly, donc elles suivent le même sort. Du côté des invités, votre Kastel n’écrit qu’un nombre, qui distingue un entretien individuel d’une réunion à plusieurs et qui ne désigne personne.
L’autre outil de réservation pris en charge, Cal.com, renvoie ses participants dans la même réponse que le rendez-vous. La donnée y arrive de toute façon, donc le contrôle y est d’une autre nature.
Ce qui entre d’un rendez-vous, et ce qui reste chez Calendly
Le rendu d’une réservation est court, et il l’est par construction. Voici ce qu’il contient, ligne par ligne.
Cette liste d’exclusions n’est pas un filtre appliqué après coup. Les trois premières lignes se lisent chez Calendly par une requête que le connecteur n’a pas, donc il n’y a rien à écarter, et rien à mal régler.
Ce qui est écrit du lieu, selon ce que l’hôte a choisi
Chaque ligne se vérifie dans votre compte Calendly, au réglage de lieu du type de rendez-vous concerné.
| Lieu réglé dans Calendly | Ce qui est écrit dans votre Kastel |
|---|---|
| Rendez-vous en personne, à une adresse écrite par l’hôte | L’adresse, telle que l’hôte l’a écrite |
| Lieu personnalisé, en texte libre de l’hôte | Ce texte, tel quel |
| Zoom, Google Meet, Microsoft Teams, Webex | Le nom de l’outil seulement, jamais le lien de connexion |
| Appel téléphonique, entrant ou sortant | La mention d’un appel téléphonique, jamais le numéro |
| Lieu demandé à l’invité | La mention d’un lieu à confirmer, jamais ce que l’invité a répondu |
La règle tient à qui a écrit la ligne. Une adresse saisie par l’hôte décrit un endroit de l’entreprise, alors qu’un lien de visioconférence est une clé d’entrée et qu’une adresse donnée par un invité appartient à cet invité.
Chaque rendez-vous se range dans le service de son hôte
Calendly ne pose aucun droit de lecture sur un rendez-vous. Le seul signal disponible est l’hôte, la personne de votre équipe dont le créneau a été réservé. Chaque rendez-vous se range donc dans le service de cet hôte, et devient lisible par les gens de ce service à travers l’IA de leur choix.
Quatre situations font échouer cette résolution. Dans les quatre, le rendez-vous n’est rangé dans aucun service et attend la décision d’un administrateur.
Le cas du co-hôte illisible est le seul qui pourrait passer inaperçu, et il explique la mécanique. Le connecteur compte les places d’hôte plutôt que les adresses qu’il arrive à lire, parce que se ranger dans le service du seul hôte reconnu sous-estimerait le public du rendez-vous. Un rendez-vous tombe donc dans un service précis, ou il attend, comme le décrit gouverner son savoir.
- Aucun hôte n’est attaché au rendez-vous, et le propriétaire du type de rendez-vous ne dit rien non plus
- Un co-hôte figure sur le rendez-vous sans que son adresse soit lisible, par exemple un compte désactivé
- Les hôtes appartiennent à plusieurs services différents
- Un hôte est inconnu de la gouvernance de votre organisation
Un jeton d’organisation, et un refus au moment de le brancher
Deux périmètres sont possibles. Une clé d’administrateur couvre l’organisation entière et voit les réservations de tous les membres, une clé personnelle n’en couvre qu’un. Et si la clé fournie authentifie une organisation différente de celle qu’on a demandé de brancher, le connecteur refuse avant d’avoir stocké quoi que ce soit. Une agence qui gère les Calendly de plusieurs clients ne peut donc pas attacher les rendez-vous de l’un au Kastel de l’autre.
Calendly ne sait pas dire ce qui a changé depuis la dernière fois. Chaque passage relit donc une fenêtre de dates en repartant de l’instant du dernier passage réussi, et un second passage recense les annulations. La première lecture remonte à 365 jours par défaut et prend tous les rendez-vous à venir, donc un rendez-vous pris à l’instant apparaît au passage suivant plutôt que dans la seconde.
Ce que ce connecteur ne fait pas
Il ne lit pas votre agenda. Seuls les rendez-vous pris à travers Calendly entrent dans votre Kastel. Une réunion que vous créez à la main dans votre agenda ne passe pas par ce connecteur, et un créneau que vous bloquez pour travailler non plus. C’est le rôle du connecteur Google Calendar.
Vous ne pourrez pas demander à une IA branchée avec qui vous avez rendez-vous mardi. Elle saura qu’un rendez-vous existe, à quelle heure, avec quel hôte de votre équipe, et combien de personnes sont attendues. Elle ne connaîtra pas le nom du client. C’est le prix de la décision décrite plus haut, et nous le payons volontairement.
L’intitulé du rendez-vous est du texte que votre équipe a écrit dans Calendly. Si un hôte nomme son type de rendez-vous d’une façon qui révèle quelque chose de sensible, cet intitulé entre avec le rendez-vous.
Un rendez-vous annulé ne disparaît pas de votre Kastel. S’il y était déjà entré, il y est marqué comme disparu à la source et conservé, lisible par les mêmes personnes qu’avant, jusqu’à ce qu’un administrateur décide de l’effacer. Un rendez-vous annulé avant d’avoir été lu, lui, n’y entre jamais, puisqu’une annulation ne compte jamais comme un contenu.
Voyez comment votre Kastel décide, source par source.
La page produit montre ce que chaque IA branchée peut atteindre selon la personne pour qui elle travaille, et ce qu’un administrateur garde sous la main.
Voir le produit
