Agentforce RGPD : le défi des télécoms françaises

Salesforce vient de lancer Agentforce Communications, une offre verticale ciblant les opérateurs télécoms. L’annonce met en avant l’automatisation des devis, l’intégration des SLA et l’harmonisation des données clients. Ce que l’annonce ne dit pas : pour un opérateur français, déployer des agents IA sur des données clients, c’est d’abord un problème Agentforce RGPD avant d’être un problème d’architecture IA.

Les DSI des télécoms françaises le savent. Leurs clients sont des millions d’abonnés. Leurs données incluent la géolocalisation, les habitudes de consommation, les historiques d’appels. La CNIL a déjà sanctionné des opérateurs pour des manquements bien moins graves que ce qu’un agent IA non encadré peut produire en quelques semaines de production.

Pourquoi le secteur télécoms concentre les risques RGPD les plus élevés

Un opérateur télécoms n’est pas une ETI avec 50 000 contacts Salesforce. C’est une organisation avec plusieurs millions d’abonnés actifs, des dizaines de systèmes legacy (OSS/BSS, facturation, provisioning réseau), et des données qui relèvent souvent de la catégorie “données de communications électroniques”; soumises à des obligations spécifiques au-delà du RGPD standard.

Trois caractéristiques rendent ce secteur particulièrement exposé.

D’abord, la volumétrie. À l’échelle d’un opérateur national, Data Cloud ingère des flux en temps réel depuis les systèmes de facturation, les portails self-care, les centres d’appels et les applications mobiles. Chaque Data Stream représente une surface d’exposition. Si l’Identity Resolution crée des Unified Individuals en croisant des données de sources multiples sans base légale documentée pour chaque croisement, l’organisation est en infraction.

Ensuite, la sensibilité des données. Les données de trafic et de localisation des communications électroniques bénéficient d’une protection renforcée en droit français (article L34-1 du Code des postes et des communications électroniques, transposant la directive ePrivacy). Un agent IA qui accède à ces données pour personnaliser une offre commerciale doit s’appuyer sur une base légale distincte du simple intérêt légitime.

Enfin, la complexité organisationnelle. Un grand opérateur français opère souvent plusieurs marques, plusieurs entités juridiques, parfois des filiales dans d’autres pays européens. La question de la responsabilité de traitement (responsable unique, co-responsables, sous-traitants) devient critique dès qu’un agent IA prend des décisions ou génère des communications personnalisées.

L’architecture qui sécurise Agentforce dans un contexte télécoms français

Le problème n’est pas Agentforce en lui-même. Le problème, c’est que la plupart des déploiements Agentforce dans les télécoms sont architecturés pour la performance, pas pour la conformité. Ces deux objectifs ne sont pas incompatibles, mais ils nécessitent des choix délibérés dès la conception.

L’architecture qui fonctionne ici repose sur quatre couches distinctes.

Couche 1 : Gouvernance des Data Streams

Avant qu’un seul enregistrement n’entre dans Data Cloud, chaque Data Stream doit être qualifié selon trois critères : la base légale du traitement (consentement, contrat, obligation légale, intérêt légitime), la durée de conservation applicable, et la catégorie de données (données ordinaires, données de communications, données comportementales déduites).

En pratique, cela signifie que les Data Model Objects dans Data Cloud doivent porter des métadonnées de conformité. Un DMO “Abonné” n’a pas le même régime qu’un DMO “Historique de navigation”. L’Identity Resolution ne doit croiser que les sources dont la base légale est compatible.

Couche 2 : Périmétrage des Topics Agentforce

Les Topics définissent ce qu’un agent peut faire. Dans un contexte télécoms RGPD, ils définissent aussi ce qu’il ne peut pas faire. Un agent de service client peut accéder aux données contractuelles et aux tickets ouverts. Il ne doit pas accéder aux données de trafic pour inférer des comportements, sauf si le client a donné un consentement explicite à cette fin.

Ce périmétrage n’est pas une restriction fonctionnelle. C’est une décision d’architecture. Les Instructions de l’agent doivent explicitement exclure certaines catégories de données, et les Actions disponibles doivent être limitées aux APIs qui respectent ces contraintes. Un agent qui peut techniquement appeler une API de données de localisation mais ne devrait pas le faire légalement est une bombe à retardement.

Couche 3 : Traçabilité des décisions de l’Atlas Reasoning Engine

L’Atlas Reasoning Engine produit des chaînes de raisonnement. Dans un contexte réglementé, ces chaînes doivent être loggées. Pas pour le débogage, mais pour répondre à une demande de la CNIL ou à un droit d’accès exercé par un abonné.

Un abonné qui reçoit un refus de crédit ou une offre différenciée générée par un agent IA a le droit de comprendre la logique appliquée (article 22 du RGPD sur les décisions automatisées). L’architecture doit prévoir un mécanisme d’explicabilité, même partiel. Les Calculated Insights utilisés comme inputs de décision doivent être documentés et accessibles.

Couche 4 : Cloisonnement des entités juridiques

Pour un opérateur multi-marques, chaque entité juridique doit avoir son périmètre Data Cloud distinct ou, à défaut, des Segments strictement cloisonnés avec des règles d’accès différenciées. Un agent déployé pour la marque grand public ne doit pas accéder aux données de la filiale B2B, même si les deux partagent la même org Salesforce.

Ce cloisonnement est souvent négligé dans les architectures multi-cloud pensées pour la performance. Il devient non-négociable dès qu’on parle de co-responsabilité de traitement entre entités du même groupe.

Ce que la plupart des déploiements font mal

Un pattern courant dans les organisations télécoms enterprise : l’équipe IA déploie Agentforce en sandbox, valide les cas d’usage, obtient le feu vert métier, puis passe en production. La DPO (Délégué à la Protection des Données) est consultée en fin de parcours, souvent après que l’architecture de données soit figée.

Cela fonctionne jusqu’au moment où la CNIL ouvre une enquête ou qu’un abonné exerce son droit à l’effacement. À ce stade, l’organisation découvre que ses Unified Individuals dans Data Cloud agrègent des données dont certaines n’auraient pas dû être croisées, que les logs de l’Atlas Reasoning Engine ne sont pas conservés dans un format exploitable, et que les Actions de l’agent ont généré des communications sans que la base légale soit documentée pour chaque type d’envoi.

Le coût d’une remédiation post-production est sans commune mesure avec celui d’une conception conforme dès le départ. Les organisations qui ont subi une due diligence technique sérieuse avant déploiement le savent : les risques cachés dans une architecture Agentforce non encadrée peuvent dépasser plusieurs millions d’euros en exposition réglementaire.

Le rôle du DPA Salesforce dans l’équation contractuelle

Un point souvent sous-estimé par les DSI : Salesforce agit comme sous-traitant au sens du RGPD pour les données traitées dans Data Cloud et Agentforce. Le Data Processing Addendum (DPA) de Salesforce doit être signé et ses clauses vérifiées, notamment sur les transferts de données hors UE.

Agentforce s’appuie sur des modèles LLM. La question de savoir où ces modèles traitent les données, si des données clients sont utilisées pour l’entraînement, et quelles garanties contractuelles s’appliquent est une question que chaque DPO d’opérateur télécoms français doit poser avant le go-live. Les réponses existent dans la documentation contractuelle Salesforce, mais elles doivent être explicitement vérifiées et documentées dans le registre des traitements.

Construire la conformité comme un avantage concurrentiel

La conformité RGPD dans un déploiement Agentforce télécoms n’est pas un frein à l’innovation. C’est un différenciateur.

Un opérateur qui peut démontrer à ses abonnés que ses agents IA opèrent dans un cadre transparent, avec des droits exercables et une traçabilité des décisions, construit une relation de confiance que ses concurrents moins rigoureux ne peuvent pas revendiquer. Dans un secteur où la confiance client est structurellement faible, c’est un argument commercial réel.

La décision actuelle détermine si l’organisation peut scaler Agentforce sereinement dans 18 mois ou si elle devra reconstruire son architecture de données sous pression réglementaire. Les opérateurs qui architecturent la conformité dès la phase de conception gagnent du temps sur tous les déploiements suivants. Ceux qui la traitent comme une contrainte à gérer en fin de projet la subissent comme un coût récurrent.

L’architecture qui survit optimise pour la confiance réglementaire, pas seulement pour la performance des agents.

---

Points clés

• Dans les télécoms françaises, chaque Data Stream entrant dans Data Cloud doit être qualifié par sa base légale avant que l’Identity Resolution ne croise les sources : c’est la condition sine qua non d’un déploiement Agentforce RGPD conforme.
• Les Topics et Actions Agentforce sont des décisions d’architecture autant que des décisions fonctionnelles : le périmétrage des accès données doit être défini avec la DPO, pas seulement avec les équipes métier.
• L’Atlas Reasoning Engine produit des chaînes de raisonnement qui doivent être loggées dans un format exploitable pour répondre aux droits d’accès et aux demandes réglementaires (article 22 RGPD sur les décisions automatisées).
• Pour les opérateurs multi-marques, le cloisonnement des entités juridiques dans Data Cloud n’est pas une option architecturale : c’est une obligation liée à la co-responsabilité de traitement.
• Le DPA Salesforce doit être vérifié et documenté dans le registre des traitements avant tout go-live : la question des transferts hors UE et de l’utilisation des données pour l’entraînement des modèles LLM doit obtenir une réponse contractuelle explicite.