Agent IA et données confidentielles : une architecture qui protège

La question qu'on nous pose sur la sécurité d'un agent IA sur mesure est presque toujours la même : « est-ce que le fournisseur du modèle est sérieux ? » Bonne question, une couche trop tard. Le contrat avec Anthropic ou OpenAI encadre ce que ces entreprises font des données une fois reçues. Il ne décide pas de ce que votre agent leur envoie, ni de qui, chez vous, peut faire parler l'agent d'un dossier qui ne le regarde pas.

C'est cette deuxième couche qui protège vraiment, et c'est celle qu'on conçoit. Un agent bien architecturé envoie peu, lit selon les droits de la personne qui pose la question, conserve encore moins, et laisse une trace vérifiable de ce qu'il a fait. Voici les cinq décisions qui font ce travail, avec les politiques de données réellement en vigueur chez les deux principaux fournisseurs d'API, vérifiées sur leurs pages officielles en août 2026.

La réponse courte, pour les pressés

Protéger des renseignements confidentiels dans un agent IA se joue dans l'architecture, pas dans les promesses du fournisseur. Cinq décisions font le travail. Minimiser à l'entrée : l'agent ne reçoit que les champs nécessaires à la tâche, jamais le dossier complet, ce que l'article 5 de la Loi 25 exige déjà. Lire selon les permissions : l'agent qui répond à un employé ne voit que ce que cet employé a le droit de voir. Régler l'API : ni Anthropic ni OpenAI n'entraînent leurs modèles sur les données d'API par défaut, Anthropic supprime les entrées et sorties de l'API en 30 jours, OpenAI conserve ses journaux de surveillance des abus jusqu'à 30 jours, et la rétention zéro existe mais sur approbation et avec des exceptions. Savoir où les données transitent physiquement, ce qui déclenche l'article 17. Journaliser les décisions plutôt que le contenu, puis dater la destruction.

Le périmètre réel n'est pas le contrat du fournisseur

L'article 10 de la Loi sur la protection des renseignements personnels dans le secteur privé (P-39.1, la « Loi 25 ») exige des mesures de sécurité « propres à assurer la protection des renseignements personnels collectés, utilisés, communiqués, conservés ou détruits » et « qui sont raisonnables compte tenu, notamment, de leur sensibilité, de la finalité de leur utilisation, de leur quantité, de leur répartition et de leur support ».

Relisez le mot « quantité ». Le volume de renseignements en cause entre dans l'évaluation du caractère raisonnable de vos mesures. La quantité de données que votre agent manipule est donc elle-même un paramètre de conformité : un agent qui reçoit trois champs par requête ne crée pas le même risque qu'un agent branché sur l'ensemble de votre CRM, et n'appelle pas les mêmes protections. Réduire ce que l'agent voit est la mesure de sécurité la moins chère du lot, et la plus efficace.

Manquer à l'article 10 figure d'ailleurs parmi les infractions pénales de l'article 91, dont les amendes pour une entreprise vont de 15 000 $ à 25 M$, ou 4 % du chiffre d'affaires mondial de l'exercice précédent si ce montant est plus élevé.

Minimiser à l'entrée : l'agent n'a pas besoin de tout votre CRM

L'architecture par défaut, celle des démonstrations, donne à l'agent un accès large et lui fait confiance pour ne s'en servir qu'au besoin. C'est confortable à construire et indéfendable à documenter.

L'architecture qui tient fait le contraire. Pour chaque tâche, on définit le plus petit jeu de champs qui permet de l'accomplir. L'agent qui qualifie une demande de service reçoit la description du problème et un identifiant interne, pas le nom, l'adresse et l'historique de facturation. Celui qui rédige une relance reçoit le montant et l'échéance, pas le dossier complet. Quand un champ sensible doit voyager, on le remplace par un jeton que seule votre application sait résoudre. L'article 5 de la Loi 25 dit déjà l'essentiel : on ne peut recueillir « que les renseignements nécessaires aux fins déterminées avant la collecte ».

Il y a une raison très concrète de prendre ça au sérieux. Anthropic écrit noir sur blanc que pour les clients payants de son API, la suppression ponctuelle n'est pas offerte : vous ne pouvez pas demander l'effacement d'une requête précise. La seule donnée dont vous êtes certain qu'elle n'a jamais été conservée nulle part est celle que vous n'avez pas envoyée.

Lire selon les permissions, pas selon un compte de service

Voici l'erreur d'architecture la plus répandue, et la plus silencieuse. On indexe la documentation interne, les contrats, les dossiers RH et les courriels dans une base vectorielle unique, on branche l'agent dessus avec un compte de service qui a tous les droits, et on met une interface de clavardage devant. L'agent fonctionne magnifiquement. Il répond aussi à l'employé de l'entrepôt qui demande le salaire de son gestionnaire, parce que rien dans cette chaîne ne sait qui pose la question.

La correction est une décision de conception, prise tôt. L'identité de la personne qui interroge l'agent doit voyager jusqu'à la couche de données, et la recherche doit s'exécuter avec ses droits à elle. Chaque document indexé porte les mêmes restrictions d'accès que dans le système d'origine, et le filtrage se fait avant que le contenu n'entre dans le contexte du modèle, jamais après par une consigne du genre « ne révèle pas les salaires ». Une instruction dans une invite est une politesse, pas un contrôle d'accès.

Le test tient en une minute : ouvrez l'agent avec le compte d'un employé aux droits limités, posez une question dont la réponse se trouve dans un document auquel il n'a pas accès, et regardez. Avant la mise en production, puis après chaque ajout de source.

Les réglages d'API que personne ne lit

Les politiques de données des deux principaux fournisseurs ont changé plusieurs fois. Voici ce que disent leurs pages officielles en août 2026.

Anthropic. Par défaut, les entrées et les sorties des produits commerciaux, dont l'API, ne servent pas à entraîner les modèles. Elles sont supprimées automatiquement des systèmes d'Anthropic dans les 30 jours suivant leur réception ou leur génération, sauf exceptions (service à rétention plus longue que vous contrôlez comme l'API Files, entente contraire, application de la politique d'usage, obligation légale). Une entente de rétention zéro existe, accordée par organisation après approbation : Anthropic ne conserve alors ni les invites ni les réponses une fois la réponse envoyée. Nuance depuis le 9 juin 2026 : les modèles désignés « covered models » (Claude Fable 5 et Claude Mythos 5) imposent une rétention de 30 jours et ne sont pas offerts en rétention zéro. Dans tous les cas, un contenu signalé par les systèmes automatisés de sécurité peut être conservé jusqu'à deux ans.

OpenAI. Depuis le 1er mars 2023, les données envoyées à l'API ne servent pas à entraîner les modèles, sauf si vous y consentez explicitement. Les journaux de surveillance des abus sont générés pour toutes les fonctionnalités de l'API et conservés jusqu'à 30 jours, sauf obligation légale ou nécessité de protéger le service ou un tiers. La rétention zéro et la surveillance des abus modifiée existent, sur approbation préalable d'OpenAI. Deux réserves à connaître : OpenAI se réserve le droit de rendre certains modèles inéligibles à ces régimes pour un client donné, avec préavis écrit, et surtout la rétention zéro ne couvre pas tous les points d'accès. Les points d'accès à état (/v1/conversations, /v1/assistants, /v1/threads, /v1/vector_stores) conservent les données jusqu'à ce que vous les supprimiez, et ne sont pas éligibles à la rétention zéro.

La leçon d'architecture est là : la rétention zéro se vérifie point d'accès par point d'accès, jamais au niveau du projet. Un agent qui bascule sur une fonctionnalité à état pour garder l'historique d'une conversation réintroduit du stockage que le contrat n'annule pas.

Reste la géographie. Le paramètre de résidence d'Anthropic, inference_geo, n'accepte que « global » ou « us », et la géographie d'espace de travail se limite pour l'instant à « us ». Aucune option canadienne sur l'API directe, donc l'article 17 s'applique. Les obligations et les montages possibles sont dans votre agent IA roule sur des serveurs américains.

Journaliser sans thésauriser

Un agent en production a besoin de traces : pour expliquer une décision, diagnostiquer une erreur, répondre à une plainte. La tentation est d'enregistrer chaque invite et chaque réponse au complet. Vous venez de créer une deuxième copie des renseignements personnels, souvent moins bien protégée que la première, soumise aux mêmes obligations.

Journalisez plutôt la décision et ses coordonnées : horodatage, identité du demandeur, action posée, sources consultées par référence, indicateur d'escalade vers un humain. Le contenu reste dans le système d'origine, où il est déjà gouverné. Fixez ensuite une durée de conservation pour le journal, parce que l'article 23 impose de détruire ou d'anonymiser un renseignement quand les fins de sa collecte sont accomplies. Un journal sans date de péremption est un entrepôt qui grossit.

Les questions qui séparent un agent encadré d'un copier-coller dans ChatGPT

Un employé qui colle un contrat client dans un outil grand public pour aller plus vite, c'est de l'IA fantôme, et c'est le scénario le plus courant en PME. Nous lui consacrons un article complet : employés et IA fantôme. Un agent encadré est la réponse à ça, à condition de pouvoir répondre à cinq questions.

Quels champs exactement partent vers le modèle, pour chaque tâche ? Comment l'agent sait-il ce que la personne qui l'interroge a le droit de voir ? Quels points d'accès de l'API sont utilisés, et lesquels conservent un état ? Que contient le journal, et combien de temps le gardez-vous ? Que se passe-t-il quand l'agent n'est pas sûr de lui ?

Cette dernière question rejoint la gouvernance de l'agent une fois en service, que nous traitons dans hallucinations et erreurs. Un fournisseur qui répond aux cinq sans consulter personne a conçu l'architecture. Un fournisseur qui répond « c'est sécurisé, on utilise Claude » a lu une page de vente.

Par où commencer

Prenez la tâche que vous voulez confier à un agent et écrivez, en une ligne, les champs dont elle a réellement besoin. La liste est presque toujours plus courte que ce que le système enverrait par défaut, et cet écart est votre risque.

C'est le premier exercice qu'on fait avec un client : cartographier ce qui doit circuler, décider qui voit quoi, choisir les réglages d'API en conséquence, avant la première ligne de code. 30 minutes, sans engagement, et si votre architecture actuelle tient la route, on vous le dira.

→ Première conversation, sans engagement

Ce texte est une vulgarisation à des fins d'information générale, pas un avis juridique. Pour tout cas impliquant des renseignements sensibles ou une décision à conséquences importantes, consultez un conseiller juridique qualifié. Les sources qui prévalent sont la Commission d'accès à l'information et les textes de loi disponibles sur LégisQuébec.