--- title: "Comment rendre Claude Desktop conforme à la Loi 25 québécoise avec MCP" description: "Brancher Claude Desktop sur une couche d'autorité MCP : décisions ALLOW, DENY, APPROVE, ESCALATE et preuve signée, avant que l'agent touche un renseignement personnel." url: https://structureclerk.ca/blog/fr/claude-desktop-loi-25-mcp language: fr translation: https://structureclerk.ca/blog/en/claude-desktop-law-25-mcp published: 2026-08-19 updated: 2026-08-19 reading_minutes: 10 author: Michel Fotsing, CISSP publisher: StructureClerk — la couche d'autorité pour agents IA keywords: Claude Desktop Loi 25, MCP conformité, Loi 25 intelligence artificielle, agent IA Québec, gouvernance agents IA, connecteur MCP conformité, décision automatisée article 12.1, transfert hors Québec article 17 --- # Comment rendre Claude Desktop conforme à la Loi 25 québécoise avec MCP *Un agent qui lit des renseignements personnels au Québec doit pouvoir dire, avant d'agir, ce qu'il a le droit de faire — et le prouver après coup. MCP rend cela branchable en dix minutes.* Votre équipe utilise Claude Desktop. Quelqu'un finit par lui donner accès au CRM, au dossier client, aux courriels. À partir de cette minute, un logiciel manipule des renseignements personnels de Québécois, et la question n'est plus « est-ce que ça marche ? » mais « est-ce qu'on a le droit ? ». > **Ce que cet article ne prétend pas** — Un logiciel n'est jamais « conforme ». Une **organisation** l'est, ou ne l'est pas. Aucun connecteur, y compris le nôtre, ne rend Claude Desktop conforme à la Loi 25 : ce qu'un connecteur peut faire, c'est rendre la règle **exécutable au moment de la décision** et **prouvable après coup**. Ce texte est technique, pas juridique — validez vos cas d'usage avec un conseiller juridique. ## Le problème n'est pas Claude Desktop, c'est le moment de la décision Les politiques internes vivent dans des PDF. Les agents, eux, décident en millisecondes, dans une boucle d'outils, sans lire le PDF. Entre la politique écrite et l'action exécutée, il n'existe le plus souvent aucun point de contrôle : c'est le trou. La Loi 25 ne parle pas d'agents IA. Elle parle de collecte, de communication, de décisions automatisées, de transfert hors Québec. Ce sont exactement les choses qu'un agent fait tout seul, vite, plusieurs milliers de fois par jour. Un agent n'invente pas une obligation nouvelle : il **industrialise** celles qui existent déjà. ## Ce que la Loi 25 exige réellement d'un agent qui lit vos données Quatre dispositions de la Loi sur la protection des renseignements personnels dans le secteur privé, modifiée par la Loi 25, se déclenchent presque toujours dès qu'un agent est branché sur des données clients. *Les quatre dispositions qu'un déploiement d'agent déclenche presque toujours.* | Disposition | Obligation | Ce que ça implique pour un agent | | --- | --- | --- | | Art. 3.1 | Désigner un responsable de la protection des renseignements personnels | Quelqu'un doit pouvoir répondre de ce que l'agent a fait — donc il faut une trace lisible par un humain | | Art. 3.3 | Tenir un registre des incidents de confidentialité et notifier la CAI en cas de risque de préjudice sérieux | Un agent qui exfiltre ou expose des données produit un incident : il faut savoir **quoi**, **quand**, **quelles données** | | Art. 12.1 | Informer la personne d'une décision fondée exclusivement sur un traitement automatisé, et lui permettre de présenter ses observations à une personne | Toute décision « exclusivement automatisée » doit être identifiable comme telle — ou réservée à un humain | | Art. 17 | Évaluer les facteurs relatifs à la vie privée (ÉFVP) avant de communiquer des renseignements hors Québec | La destination des données fait partie de la décision, pas de l'infrastructure | Les sanctions ne sont pas symboliques : sanctions administratives pécuniaires jusqu'à 10 M$ ou 2 % du chiffre d'affaires mondial, amendes pénales jusqu'à 25 M$ ou 4 %. Le facteur aggravant classique, dans toutes les juridictions, n'est pas la faute technique — c'est l'incapacité à démontrer qu'un contrôle existait. ## Pourquoi une consigne dans le prompt système n'est pas un contrôle La réponse réflexe est d'écrire dans le prompt : « n'utilise jamais de données personnelles sans autorisation ». C'est utile, et ce n'est pas un contrôle. Trois raisons, dans l'ordre de gravité. - **Ce n'est pas déterministe.** Le même prompt, deux fois, peut donner deux comportements. Une règle qui dépend d'un échantillonnage n'est pas une règle, c'est une tendance. - **Ce n'est pas prouvable.** Six mois plus tard, face à la CAI ou à un client, vous ne pouvez pas démontrer qu'à 14 h 32 le 3 mars, la consigne était présente, appliquée, et appliquée de cette façon-là. - **Ce n'est pas révisable.** Une politique dans un prompt ne se relit pas, ne se teste pas, ne se versionne pas indépendamment du reste de l'invite. Un contrôle, c'est une décision prise **hors du modèle**, par un composant déterministe, qui renvoie toujours la même réponse pour la même question, et qui laisse une preuve qu'un tiers peut vérifier sans vous faire confiance. > StructureClerk décide, votre infrastructure applique. > — La thèse produit, en une phrase ## L'architecture en une image *La décision est consultative. L'exécution reste chez vous — c'est ce qui rend la couche installable sans toucher à votre infrastructure.* ```text Claude Desktop │ (1) l'agent veut agir : lire un dossier client, envoyer, payer… ▼ Outil MCP authority_decide │ (2) action + juridiction + secteur ▼ Moteur d'autorité (déterministe, sans LLM) │ (3) ALLOW · APPROVE · DENY · ESCALATE │ + cadres cités + preuve signée Ed25519 ▼ Votre application (4) applique : exécute, demande une approbation humaine, ou refuse ``` Cette séparation n'est pas une limite technique, c'est le contrat. Un tiers qui **applique** vos règles devient un point de panne dans votre chaîne de production et un dépositaire de vos données. Un tiers qui **décide** ne voit qu'une description d'action, et son avis peut être ignoré, journalisé, ou contesté. ## Mise en place, étape par étape ### 1. Ajouter le connecteur dans Claude Desktop Réglages → Connecteurs → Ajouter un connecteur personnalisé. Nom : StructureClerk. URL : l'endpoint MCP ci-dessous. Le serveur est distant et public : rien à installer, rien à exposer sur votre réseau. Il n'y a pas de clé à saisir pour commencer — une franchise quotidienne s'applique par adresse IP. ```bash https://structureclerk.ca/api/mcp-http ``` ### 2. Vérifier que les outils sont bien vus Demandez à Claude de lister les outils du connecteur. Vous devez voir `authority_decide` — c'est le seul qui compte pour la Loi 25 ; les autres (cartographie, feuille de route, évaluation) sont des outils d'analyse. ```bash curl -s https://structureclerk.ca/api/mcp-http \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","method":"tools/list","id":1}' ``` ### 3. Poser une vraie question, pas une question de démonstration Prenez l'action la plus banale de votre équipe et faites-la passer par l'outil : « Décide si un agent peut lire un dossier client au Québec et l'envoyer à un service hébergé aux États-Unis. » Une question de démonstration donne une réponse de démonstration. ### 4. Câbler la décision dans le code qui agit C'est l'étape que personne ne saute impunément. Tant que la décision n'est pas lue par le code qui exécute l'action, vous avez un avis, pas un contrôle. En pratique : appelez l'API avant l'effet de bord, et traitez `APPROVE` comme une file d'attente humaine, pas comme un `ALLOW` verbeux. ```bash curl -s https://structureclerk.ca/api/v1/authority/decide \ -H 'Content-Type: application/json' \ -d '{ "agent": { "id": "crm-assistant", "autonomy_level": 3 }, "action": { "type": "read.customer_record", "data_categories": ["personal"], "destination_jurisdiction": "US_FED" }, "context": { "jurisdictions": ["CA_QC"], "sector": "tech" } }' ``` ### 5. Conserver la preuve, et la vérifier une fois Chaque décision porte un identifiant de preuve. Vérifiez-en une, à la main, aujourd'hui — pas le jour où on vous la demande. La vérification est gratuite et ne demande aucun compte : c'est une promesse publiée, verrouillée par un test du dépôt. ```bash curl -s https://structureclerk.ca/api/v1/authority/verify/ ``` ## Ce que renvoie une décision Voici la réponse réelle pour la question de l'étape 3 — un agent québécois qui veut envoyer un dossier client vers les États-Unis. Elle est reproduite telle quelle, champs coupés pour la lisibilité. ```json { "decision": "APPROVE", "zone": 2, "reason": "cross_border_transfer_mechanism_required", "confidence": 0.95, "matched_rules": [ { "id": "zone2.cross_border_transfer", "specificity": "exact", "confidence": 0.95 } ], "frameworks": [ { "name": "Loi 25", "domain": "data_protection", "jurisdiction": "CA_QC", "last_verified": "2025-01-31", "coverage_tier": "priority" } ], "sources_verified_from": "2025-01-31", "rules_version": "2026-08-14.3", "advisory": true, "evidence": { "id": "ev_...", "sha256": "9f2c...", "signature": "MEUCIQD...", "key_id": "sc-authority-2026" } } ``` - `decision` — l'une des quatre primitives. `APPROVE` veut dire : autorisé **avec** approbation humaine préalable, pas « autorisé avec un avertissement ». - `reason` — un code stable, pas une phrase. Ici : le transfert exige un mécanisme, ce qui renvoie directement à l'ÉFVP de l'article 17. - `confidence` et `matched_rules` — quelle règle a décidé, et avec quelle spécificité. En dessous de 0,90, le moteur bascule volontairement en `ESCALATE` plutôt que de deviner. - `frameworks` — les cadres cités, au niveau du cadre et jamais de l'article : citer « article 17 » comme s'il s'agissait d'un avis juridique serait une promesse que le moteur ne peut pas tenir. - `sources_verified_from` — la date de vérification de la source la plus ancienne derrière cette décision. Publiée, pas cachée. - `evidence` — empreinte SHA-256 de la décision et signature Ed25519. ### Le cas qui compte vraiment : la sortie du Québec Changez une seule chose dans la requête — la destination — et la décision change. C'est le comportement à tester en premier, parce que c'est celui que les politiques écrites ratent le plus souvent : la même action est licite vers un serveur montréalais et exige une évaluation préalable vers un serveur américain. *Quatre appels réels au moteur, contexte CA_QC. Les motifs sont les codes renvoyés par l'API.* | Action | Destination | Décision | Motif | | --- | --- | --- | --- | | `read.contract` | interne | `ALLOW` | `low_risk_operation` | | `read.customer_record` (personnel) | `US_FED` | `APPROVE` | `cross_border_transfer_mechanism_required` | | `hiring.decide` | — | `DENY` | `human_only_decision` | | `payment.execute` 12 000 $ CA | — | `APPROVE` | `financial_threshold_exceeded` | Notez le troisième : une décision d'embauche est refusée, pas escaladée. L'article 12.1 encadre les décisions exclusivement automatisées ; le moteur choisit de les réserver à un humain plutôt que d'inventer une procédure d'information. Un refus ne coûte d'ailleurs rien — la portée et le solde sont vérifiés **avant** tout travail facturable. ## La preuve : ce que vous montrez, six mois plus tard Une décision qui n'existe que dans vos journaux ne prouve rien : vous êtes à la fois l'auteur et le témoin. C'est pour ça que chaque décision sort avec une preuve dont la vérification ne dépend pas de nous. - **Empreinte** — SHA-256 d'une sérialisation canonique de la décision. Les clés absentes restent absentes du hachage : c'est ce qui garde les empreintes stables dans le temps. - **Signature** — Ed25519, clé publique publiée sur `/.well-known/structureclerk-authority.json`. - **Chaînage** — chaque preuve porte sa position dans un journal en ajout seul ; retirer une décision casse la chaîne. - **Ancrage tiers** — la tête de chaîne est horodatée par une autorité RFC 3161 externe. Une preuve « horodatée » et une preuve « publiée » (auto-attestée) ne sont jamais présentées comme la même chose. - **Vérification gratuite, sans compte** — parce qu'une preuve qu'il faut payer pour vérifier n'est pas une preuve. ## Les limites, dites franchement - **C'est consultatif.** Le moteur ne bloque rien. Si votre code ignore un `DENY`, l'action a lieu. La preuve enregistrera qu'elle a eu lieu contre un refus — ce qui est mieux que rien, et moins bien qu'un blocage. - **Les citations sont au niveau du cadre.** « Loi 25 », pas « article 17, deuxième alinéa ». Une citation article par article donnerait l'illusion d'un avis juridique. - **Toutes les juridictions ne se valent pas.** Celles sur lesquelles le moteur décide sont revérifiées chaque cycle ; les autres sont indicatives, et chaque citation porte sa propre date. - **Hors périmètre, définitivement** : SSO, RBAC, application à l'exécution. Ce n'est pas un manque de temps, c'est la thèse. ## Checklist avant de brancher un agent sur des données québécoises 1. Lister les actions que l'agent peut réellement déclencher (pas celles qu'on lui souhaite). 2. Pour chacune : quelles catégories de données, quelle destination, réversible ou non. 3. Marquer celles qui produisent une décision au sens de l'art. 12.1 — et les réserver à un humain. 4. Faire passer les actions restantes par `authority_decide` **avant** l'effet de bord. 5. Traiter `APPROVE` comme une file d'attente humaine, avec un délai et un responsable nommé. 6. Conserver l'identifiant de preuve à côté de votre journal applicatif. 7. Documenter l'ÉFVP pour toute destination hors Québec, une fois, et la référencer. 8. Vérifier une preuve à la main, aujourd'hui. Si vous ne savez pas par où commencer, l'[évaluation de conformité gratuite](/scan) parcourt ces questions et produit un profil de politique — que l'API applique ensuite à chaque décision de votre organisation. C'est la porte d'entrée, elle ne demande aucune carte de crédit. **Est-ce que ce connecteur rend Claude Desktop conforme à la Loi 25 ?** Non, et aucun produit ne le peut. La conformité est une propriété de l'organisation, pas d'un logiciel. Le connecteur rend la règle exécutable au moment où l'agent agit, et vérifiable après coup ; le reste — registre des incidents, responsable désigné, ÉFVP, information des personnes — reste à votre charge. **Est-ce que mes données passent par StructureClerk ?** Non. L'outil reçoit une description d'action — type d'action, catégories de données, juridiction, secteur, destination — jamais le contenu du dossier client. Une couche d'autorité qui exigerait vos données pour dire si vous avez le droit de les traiter serait une contradiction. **Que se passe-t-il si l'API est indisponible ?** Votre agent continue de fonctionner : la décision est consultative, elle n'est pas sur le chemin critique de votre infrastructure. À vous de choisir la posture par défaut en cas d'indisponibilité — pour des actions sensibles, refuser par défaut est le comportement prudent. **Pourquoi une décision d'embauche est-elle refusée plutôt qu'approuvée avec supervision ?** Parce que l'article 12.1 encadre les décisions fondées exclusivement sur un traitement automatisé, avec obligation d'information et droit de présenter des observations. Le moteur classe ces actions en zone 3 — réservées à l'humain — plutôt que de prétendre orchestrer une procédure d'information qu'il ne contrôle pas. **Faut-il un compte pour essayer ?** Non. Une franchise quotidienne par adresse IP permet d'essayer sans inscription, et la vérification de preuve est gratuite en permanence. Au-delà, une clé API dépense des crédits prépayés ou l'allocation incluse dans un plan Autorité. **Ça marche avec autre chose que Claude Desktop ?** Oui. Le même moteur est exposé en REST, en A2A et en MCP. Tout client MCP — Claude Desktop, Cursor, un agent maison — parle au même endpoint, et un service qui n'est pas un agent peut appeler l'API REST directement. Pour le détail du contrat de décision, des quatre primitives et du format de preuve : [la page Autorité](/authority). Pour l'entrée en matière côté organisation : [l'évaluation gratuite](/scan).