> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hi-doctor.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Sécurité du connecteur

> Comment le connecteur vous authentifie, ce qu'il conserve, et ce qu'il refuse délibérément de faire.

Le serveur MCP Hi-Doctor est un **serveur de ressources** OAuth 2.1. Il ne
détient aucune base de données patients qui lui soit propre : chaque appel
d'outil est transmis à l'API Hi-Doctor en tant que *vous*, avec les
autorisations de votre propre compte.

## La connexion

La connexion suit un flux OAuth 2.1 standard par code d'autorisation, avec
**PKCE** (`S256`). Votre client IA ne voit jamais votre mot de passe : vous le
saisissez sur une page Hi-Doctor, et le client reçoit un code d'autorisation de
courte durée qu'il échange contre un jeton.

Le serveur publie les documents de découverte qu'un client MCP attend, si bien
qu'aucune configuration manuelle n'est nécessaire :

| Document                                  | Norme                                        |
| ----------------------------------------- | -------------------------------------------- |
| `/.well-known/oauth-protected-resource`   | RFC 9728                                     |
| `/.well-known/oauth-authorization-server` | RFC 8414                                     |
| `POST /register`                          | RFC 7591, enregistrement dynamique de client |

Les codes d'autorisation sont **à usage unique** et de courte durée. En
utiliser un deux fois échoue : un code rejoué est rejeté, pas honoré.

## Où un jeton peut être renvoyé

Chaque client enregistré reçoit un `client_id` signé qui **lie l'URI de
redirection exacte** avec laquelle il s'est enregistré. Au moment de
l'autorisation, l'URI `redirect_uri` demandée doit correspondre exactement à
cette liaison.

<Note>
  C'est la défense contre l'interception du code d'autorisation : un attaquant qui
  connaît votre `client_id` ne peut toujours pas demander que le code soit
  délivré à son propre serveur, parce que l'URI est scellée dans l'identifiant et
  vérifiée avant même que le formulaire de connexion ne s'affiche.
</Note>

Les redirections en boucle locale suivent la RFC 8252 §7.3 : le port peut
varier, comme l'exigent les clients de bureau, mais le reste de l'URI doit
correspondre.

## Les jetons

Les jetons d'accès sont des **enveloppes chiffrées en AES-256-GCM**, et non des
identifiants bruts du back-end. Une enveloppe est liée à son audience et se voit
rejetée si elle est altérée, rejouée contre la mauvaise ressource, ou présentée
après l'expiration du jeton back-end qu'elle contient. Une enveloppe de
rafraîchissement ne peut pas être utilisée là où une enveloppe d'accès est
requise.

Votre mot de passe Hi-Doctor est échangé contre un jeton à la connexion ; il
n'est jamais conservé par le connecteur, jamais écrit dans un journal, et jamais
transmis à l'application qui se connecte.

## Les autorisations

Les outils sont regroupés, et chaque groupe exige sa propre portée : profil,
consultations, messages, questionnaires, progrès, paiement. Un outil dont vous
n'avez pas accordé la portée n'est pas seulement refusé, il n'est **pas
proposé** : il n'apparaît jamais dans la liste d'outils du client.

Les rôles ne se cumulent pas. Un compte reçoit exactement un catalogue d'outils,
de sorte qu'un jeton de patient ne peut jamais atteindre un outil de clinicien
ou de back-office. Voir [Autorisations](/fr/mcp/permissions) pour la liste
complète des accès accordés.

## Ce que le serveur refuse de laisser filtrer

* **Les corps de réponse `5xx` du back-end sont entièrement écartés.** Une
  erreur en amont renvoie un échec générique et stable, plutôt qu'une trace
  interne.
* **Les réponses `4xx` sont filtrées selon une liste blanche** de champs
  structurés, afin qu'une erreur puisse être exploitable sans renvoyer de
  données de santé dans le résultat de l'outil.
* Les arguments de chemin ne peuvent pas sortir de l'hôte d'API configuré ni de
  son préfixe de version.
* La limitation de débit est indexée sur le jeton, et non sur un en-tête qu'un
  appelant pourrait remodeler pour obtenir un nouveau quota.

## Le paiement

Le connecteur ne manipule jamais de données de carte bancaire.
`hidoctor_checkout_create` renvoie un lien vers la page de paiement hébergée par
Stripe, et les changements de carte, de formule et d'adresse de facturation ont
lieu dans le portail de facturation Stripe. Aucun outil n'accepte de numéro de
carte, et tout assistant qui vous en demande un ne parle pas à Hi-Doctor.

## Les limites cliniques

Aucun jeton, quel qu'il soit, ne peut approuver une consultation, émettre ou
modifier une ordonnance, ou changer une dose. Ces actions ne sont pas exposées
du tout par le serveur MCP : elles ne sont pas protégées derrière une portée,
elles sont tout simplement absentes.

L'éligibilité médicale est appliquée par le back-end Hi-Doctor au moment de
l'envoi du questionnaire. Un assistant ne peut pas pré-approuver un patient, et
renvoyer le questionnaire avec des réponses différentes ne contourne pas le
contrôle.

## Signaler un problème

Écrivez à [hello@hi-doctor.ai](mailto:hello@hi-doctor.ai) en détaillant le
problème. Si vous pensez que des données de santé sont exposées, indiquez-le
dans l'objet du message afin qu'il soit traité en priorité.