# Garde-fous RGPD pour un agent IA relié à HubSpot sur un site de santé

> Quelles données un agent connecté à un CRM peut-il légitimement voir quand ces données concernent la santé d'un patient ? Checklist des limitations à imposer avant toute connexion.

- Auteur : Clément Hadrot
- Publié le : 2026-09-03
- Mis à jour le : 2026-09-03
- Catégorie : IA &amp; MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/garde-fous-rgpd-agent-ia-hubspot-site-sante/

## L’essentiel

- Les données de santé sont une catégorie particulière au sens du RGPD, jamais anodine
- L'agent ne doit jamais voir un champ de santé en clair sans nécessité stricte
- Un registre de traitement dédié à l'agent est obligatoire, pas optionnel

Quelles données un agent connecté à un CRM peut-il légitimement consulter quand ces données concernent la santé d'un patient ? Cette question s'est posée en configurant un agent de qualification des demandes entrantes pour une clinique de télémédecine, dont les fiches contact HubSpot contiennent des champs personnalisés décrivant motifs de consultation et antécédents déclarés par les patients eux-mêmes.

Les données de santé relèvent d'une catégorie particulière au sens de l'article 9 du RGPD, avec un régime de protection renforcé par rapport aux données personnelles courantes. Brancher un agent IA sur un CRM qui en contient impose une checklist plus stricte que pour un usage e-commerce classique, où l'essentiel se limite souvent à des coordonnées et un historique d'achat.

## Ce que l'agent ne doit jamais voir en clair

1. Les champs de santé structurés (motif de consultation, antécédents, traitements en cours) ne doivent jamais transiter en clair vers le modèle de langage sous-jacent, sauf strict besoin fonctionnel documenté au préalable
2. Toute donnée de santé transmise à l'agent doit l'être sous une forme minimisée, par exemple une catégorie générale plutôt qu'un motif détaillé, quand la tâche ne nécessite pas plus de précision
3. Aucune donnée de santé ne doit être conservée dans l'historique de conversation de l'agent au-delà de la durée strictement nécessaire au traitement de la demande en cours

## Ce que le registre de traitement doit couvrir

> L'essentiel à retenir : Les données de santé sont une catégorie particulière au sens du RGPD, jamais anodine ; L'agent ne doit jamais voir un champ de santé en clair sans nécessité stricte ; Un registre de traitement dédié à l'agent est obligatoire, pas optionnel

Le registre de traitement, déjà obligatoire pour tout traitement de données de santé, doit être complété spécifiquement pour l'usage de l'agent, avec un niveau de détail supérieur à ce qui suffirait pour une simple base de contacts commerciale :

- La liste exacte des champs HubSpot accessibles à l'agent, champ par champ, pas seulement à l'échelle de l'objet contact
- La finalité précise de chaque accès, distincte de la finalité générale du CRM
- La durée de conservation des échanges entre l'agent et le patient, généralement plus courte que celle des fiches CRM elles-mêmes
- L'identité du sous-traitant fournissant le modèle de langage, avec la localisation du traitement des données

## Le cloisonnement technique recommandé

```
function wpm_masquer_donnees_sante( array $fiche_contact ): array {
    $champs_sensibles = array( 'motif_consultation', 'antecedents', 'traitement_en_cours' );

    foreach ( $champs_sensibles as $champ ) {
        if ( isset( $fiche_contact[ $champ ] ) ) {
            $fiche_contact[ $champ ] = wpm_categoriser_sans_details( $fiche_contact[ $champ ] );
        }
    }

    return $fiche_contact; // transmis à l'agent sous forme catégorisée uniquement
}
```

Cette fonction, appelée avant toute transmission de fiche contact à l'agent via l'outil MCP correspondant, transforme un motif détaillé en catégorie générale (« suivi chronique », « consultation ponctuelle »), suffisante pour que l'agent priorise correctement la demande sans jamais avoir accès au détail médical précis.

## Ce que le patient doit pouvoir savoir et refuser

- Une information claire, avant tout échange, précisant qu'un agent IA participe au traitement initial de la demande
- Une option explicite pour être mis en relation directement avec un humain sans passer par l'agent
- Un droit d'accès qui couvre également les données traitées spécifiquement par l'agent, pas seulement par le CRM dans son ensemble

## Ce qui reste hors du périmètre de cette checklist

La performance de cette intégration, notamment le temps de réponse de l'agent face au volume de demandes entrantes, ne fait volontairement pas partie de cette checklist : elle mérite une évaluation distincte, une fois les garde-fous de conformité posés en premier lieu, faute de quoi la rapidité d'un système mal cadré juridiquement ne ferait qu'accélérer un problème de fond.

> Un agent qui répond vite à des données de santé mal protégées n'est pas un progrès, c'est un risque accéléré.

## En résumé

Connecter un agent IA à un CRM qui contient des données de santé n'est pas une variation mineure d'un projet e-commerce classique : c'est un projet à part entière, qui demande un registre de traitement dédié, une minimisation stricte des champs transmis et une information transparente du patient. Aucune de ces exigences ne devrait être perçue comme un frein à l'innovation, mais comme la condition de sa viabilité sur ce type de terrain.
