Le parcours d'authentification

Un code reçu sur l'e-mail prouve l'e-mail, et la personne est authentifiée. Ce parcours est le même partout : sur le widget, dans Claude, dans ChatGPT, sur WhatsApp. Ce qui change d'une surface à l'autre, c'est seulement où ses étapes s'affichent, et qui garde le résultat.

La station n'écrit rien de plus que ses fournisseurs et le fournisseur de chaque portail. Core déduit le reste.

L'invitation, et deux façons d'y entrer

Là où la station sait connecter quelqu'un et qu'il ne l'est pas, la conversation s'ouvre sur une invitation à se connecter : dans le chat, pas sous la zone de saisie. Dans le widget et la PWA, c'est la première bulle ; dans Claude et ChatGPT, le cadre de l'ouverture de la room, avec un bouton « Se connecter » qui ouvre la connexion de l'hôte.

entrée	qui la lance	la personne peut continuer sans
une skill réservée, ou le submit quand submitted_by: owner	Core, quand la personne l'appelle (Demander l'authentification)	non
la personne le demande : le bouton de l'invitation, ou en le disant	sign_in : les étapes s'affichent dans la conversation	oui

Les agents autonomes

Un agent de code ou un agent LangChain n'a pas de fenêtre à ouvrir. Le refus qu'il reçoit (401) dit comment obtenir un jeton : un client MCP qui gère l'autorisation mène le parcours lui-même, en ouvrant un navigateur une fois ; un agent sans navigateur reçoit de son opérateur un jeton obtenu pour lui. La réponse durable est la sous-identité déléguée : une clé que l'organisation donne à son agent, avec ses limites. Un agent ne reçoit jamais le code d'une personne.

Les étapes d'un mécanisme

Chaque mécanisme est une suite d'étapes. Il n'en existe que quatre sortes :

sorte	sens	exemple
saisir	une donnée qui n'est pas secrète	l'e-mail
secret	une donnée que le modèle ne voit jamais	le code
rediriger	une page externe, puis le retour	l'IdP, la page de connexion du tenant
silencieux	un échange sans écran	l'assertion signée du site du tenant

mécanisme	ses étapes
otp	saisir la donnée, puis le secret (le code), puis « vérifié »
oidc	rediriger vers l'IdP, puis « vérifié »
assertion	silencieux si la personne est connectée sur le site du tenant ; sinon rediriger vers son login_url

Ce que voit la personne, selon la surface

surface	où s'affichent les étapes	ce qui la reconnaît ensuite
widget, sur le site du tenant	dans le cadre ; rien à faire avec assertion	son navigateur
PWA	dans le cadre	son navigateur
Claude, ChatGPT	Claude ou ChatGPT ouvre sa fenêtre de connexion ; elle mène à la page Convoy du tenant, avec les mêmes étapes	son compte Claude ou ChatGPT, d'une conversation à l'autre
WhatsApp	dans la conversation : Core pose les questions et lit les réponses, le modèle ne les voit pas ; le téléphone est déjà prouvé par le canal	son numéro
Teams, Slack	rien à faire si l'IdP de l'organisation est celui de la station ; sinon une carte « Se connecter »	son compte de la plateforme

Ce qui la reconnaît est le titulaire : la chose la plus durable que la surface sait identifier. L'authentification lui appartient. Elle n'appartient ni à la conversation — une nouvelle conversation dans Claude ne demande pas de se reconnecter —, ni à la room.

La room et la personne

• Une room créée par une personne connectée est la sienne dès le départ. Une room sans propriétaire devient la sienne quand elle l'ouvre connectée, sur n'importe quelle surface.
• Ses rooms la suivent. Connectée, une personne qui arrive sans code de room (un nouvel appareil, Claude, ChatGPT) retrouve la dernière room qu'elle a utilisée, où que ce soit. Le menu ⋮ et l'outil room_list listent ses autres rooms ; Nouvelle conversation en crée une.
• Seul un usage par quelqu'un qui peut entrer compte comme « dernière utilisation ». Lire une room, ou l'ouvrir avec son code sans en être le propriétaire, ne change pas celle où elle revient.
• La liste dit de quoi parle chaque room (le nom des faits retenus), jamais ce qui y a été dit.
• Si ses rooms ne peuvent pas être lues, l'appel échoue : aucune room vide n'est créée à la place.
• Le code d'une room ne donne aucun droit. Quelqu'un qui ouvre la room avec son code voit la sélection, mais il n'est pas connecté pour autant : les profils, les permissions et submitted_by: owner lisent la personne connectée, jamais la room.

Sur Claude et ChatGPT

Claude et ChatGPT suivent la même méthode, l'autorisation MCP (OAuth 2.1). Le connecteur s'installe sans connexion. Quand Core décide qu'une connexion est nécessaire, la porte MCP envoie à l'hôte le signal qu'il attend ; l'hôte ouvre sa fenêtre de connexion, puis relance lui-même l'appel.

Pour cela, Convoy fait tourner un serveur d'autorisation par tenant. Sa page ne prouve rien elle-même : elle mène les étapes du fournisseur (les opérations send et check du tenant, son IdP, sa page de connexion), puis donne à l'hôte un jeton valable pour les outils Convoy seulement. Ce jeton ne porte que l'identifiant opaque de la personne, jamais l'e-mail, et il n'est jamais transmis à l'API du tenant. Il n'existe pas de compte Convoy, ni de mot de passe Convoy.

Ce qui reste vrai partout

1. Seul Core décide qu'une connexion est nécessaire. Le modèle n'en lance jamais une là où la surface sait afficher les étapes.
2. Le modèle ne voit ni la donnée ni le code.
3. L'authentification appartient au titulaire ; la room garde son propriétaire ; le code d'une room n'authentifie personne.
4. Le code n'est vérifié que par le fournisseur, et Convoy ne le garde pas.
5. L'appel relancé repasse par toutes les règles.
6. Une valeur s'écrit d'une seule façon.
7. La phrase du fournisseur arrive à la personne, la valeur masquée : son refus, et, sur un code envoyé, où le lire (une boîte de démonstration, le dossier des indésirables).

Une nouvelle surface ou un nouveau mécanisme ne s'ajoute qu'en passant les tests qui vérifient ces sept points.