OpenLegi repose sur deux services distincts, ce qui explique que vous rencontriez deux noms de domaine.
┌────────────────────────────┐
│ Votre client MCP │
│ Claude · ChatGPT · │
│ Mistral · Cursor · VS Code│
└──────────────┬─────────────┘
│ MCP (JSON-RPC sur HTTP)
▼
┌─────────────────────┐ ┌────────────────────────────┐
│ auth.openlegi.fr │◄──┤ mcp.openlegi.fr │
│ Authentification │ │ Passerelle MCP │
│ │ │ │
│ · comptes │ │ · expose les outils │
│ · tokens │ │ · valide l'accès │
│ · OAuth2 / OIDC │ │ · applique les quotas │
│ · clés PISTE │ │ · met en forme les réponses│
└─────────────────────┘ └──────────────┬─────────────┘
│ API officielles
▼
┌───────────────────────────────────────────────────────┐
│ Légifrance (via PISTE) · RNE / INPI · EUR-Lex │
│ BOFiP · BODACC │
└───────────────────────────────────────────────────────┘
Les composants
Votre client MCP. Tout assistant qui gère le protocole MCP. C'est lui qui décide d'appeler un outil en fonction de votre question.
La passerelle MCP — mcp.openlegi.fr. Elle expose les outils, vérifie que l'appel est
autorisé, applique les quotas, interroge la source officielle et met le résultat en forme
pour un modèle de langage. C'est le seul service que votre client contacte directement.
Le serveur d'authentification — auth.openlegi.fr. Il gère les comptes, les tokens,
le rôle de serveur d'autorisation OAuth 2.0 / OpenID Connect, et le stockage chiffré de
vos identifiants PISTE personnels. C'est aussi là que vivent le tableau de bord et cette
documentation. Vous vous y connectez, mais votre client MCP ne l'appelle pas.
Les sources officielles. Légifrance via l'API PISTE de l'État, le RNE via l'INPI, EUR-Lex pour le droit européen, ainsi que BOFiP et BODACC. OpenLegi n'héberge aucune copie de ces bases : chaque requête part vers la source.
Le parcours d'une requête
- Vous posez une question à votre assistant, qui décide d'appeler un outil OpenLegi.
- Le client envoie une requête MCP à la passerelle, avec un jeton OAuth ou un token.
- La passerelle vérifie l'accès — signature du jeton pour OAuth, validation auprès du serveur d'authentification pour un token — et contrôle le quota.
- Si vous avez déclaré vos propres identifiants PISTE, la passerelle les récupère (chiffrés au repos, déchiffrés le temps de l'appel). Sinon elle utilise les identifiants partagés.
- La requête est traduite en appel à l'API de la source concernée.
- Le résultat est mis en forme, accompagné des liens vers la source officielle, et renvoyé au client.
Ce que cette architecture implique pour vous
- Une seule adresse à configurer dans votre client : celle de la passerelle. Si un
guide vous demande de pointer un client MCP vers
auth.openlegi.fr, il est périmé. - Les données ne sont pas stockées par OpenLegi. Chaque réponse provient d'une requête en direct à la source, à la latence de cache près.
- Ce que vous lisez est une représentation intermédiaire du texte officiel : filtrée, remise en forme, puis souvent reformulée par votre assistant. D'où la règle de vérification systématique sur Légifrance avant tout usage professionnel — voir la page « Limitations connues ».