La plupart des DSI d’ETI françaises regardent Agentforce 360 avec le même réflexe : “on va devoir refondre notre gouvernance IT avant de pouvoir déployer ça.” C’est le mauvais diagnostic. Et il coûte cher en temps perdu.
Agentforce 360 est passé en disponibilité générale avec un ensemble de mécanismes de contrôle qui s’insèrent dans une gouvernance existante plutôt qu’ils ne la remplacent. La question de l’Agentforce Gouvernance n’est pas “comment restructurer notre organisation IT”, c’est “comment mapper nos guardrails métier existants sur les primitives de la plateforme”. Ce n’est pas la même question, et la réponse est radicalement différente.
Ce que change réellement Agentforce 360 pour une ETI
Avant la GA d’Agentforce 360, déployer un agent en production nécessitait de jongler entre des configurations éparpillées : Topics définis dans un endroit, Actions dans un autre, instructions de comportement dans un troisième. Le résultat était une gouvernance de fait impossible à auditer.
Agentforce Builder centralise maintenant l’ensemble de cette configuration dans une interface unifiée. Ce n’est pas qu’un changement UX. C’est un changement de modèle de gouvernance : pour la première fois, un DSI peut voir en un seul endroit ce qu’un agent est autorisé à faire, dans quel périmètre, avec quelles contraintes. Pour une ETI avec 3 à 5 agents déployés sur des processus différents, c’est la différence entre une gouvernance documentée et une gouvernance réelle.
Agent Script guardrails est la fonctionnalité qui mérite le plus d’attention du point de vue métier. Elle permet de définir des scripts de comportement contraignants que l’Atlas Reasoning Engine ne peut pas contourner, même face à des instructions utilisateur contradictoires. En pratique, cela signifie qu’un agent de service client ne peut pas être manipulé par un utilisateur pour sortir de son périmètre défini, qu’il s’agisse de données sensibles, de processus réglementés, ou simplement de sujets hors scope.
Pour une ETI française opérant dans des secteurs réglementés (finance, santé, industrie), cette contrainte forte au niveau de la plateforme est exactement ce que les équipes conformité demandent depuis le début.
Comment mapper les guardrails métier existants sur Agentforce
La plupart des ETI françaises ont déjà des guardrails métier. Ils existent sous forme de procédures internes, de matrices d’habilitation, de règles de validation dans leur CRM, parfois de politiques RGPD formalisées. Le travail d’architecture n’est pas d’en créer de nouveaux, c’est de les traduire dans le modèle Agentforce.
Le mapping fonctionne sur trois niveaux.
Topics et périmètre d’action correspondent aux domaines métier dans lesquels un agent est autorisé à opérer. Si votre gouvernance IT actuelle définit qu’un commercial n’a accès qu’aux données de ses comptes assignés, ce périmètre se traduit directement en Topics avec des filtres de données associés. Aucune restructuration nécessaire, c’est une traduction.
Instructions de comportement correspondent aux règles de conduite que votre organisation applique déjà. Les scripts de conformité, les formulations obligatoires dans certains contextes réglementaires, les escalades obligatoires vers un humain pour certaines décisions : tout cela s’encode dans les Instructions au niveau agent. Agent Script guardrails ajoute une couche de contrainte forte sur ces instructions, ce qui les rend non-négociables même face à un utilisateur créatif.
Actions et intégrations correspondent aux systèmes que l’agent peut appeler. Ici, la gouvernance existante sur les accès API et les droits d’intégration s’applique directement. Un agent Agentforce hérite des permissions de l’utilisateur connecté ou d’un utilisateur de service dédié, ce qui signifie que votre modèle de contrôle d’accès actuel reste le point de référence.
Ce mapping est documentable, auditable, et surtout réversible. C’est ce que les équipes conformité et les DSI d’ETI ont besoin d’entendre.
Intelligent Context et la question des données personnelles
Intelligent Context est la fonctionnalité d’Agentforce 360 qui soulève le plus de questions RGPD dans le contexte français. Elle permet à l’agent de maintenir un contexte enrichi sur la durée d’une interaction, en puisant dans Data Cloud pour personnaliser les réponses en temps réel.
Le problème architectural est précis : quelles données personnelles transitent dans le contexte de l’agent, pendant combien de temps, et avec quelle base légale ?
La réponse correcte n’est pas de désactiver Intelligent Context. C’est de définir explicitement quels Data Model Objects (DMOs) alimentent le contexte de chaque agent, et de documenter cette configuration dans votre registre de traitements RGPD. En pratique, cela signifie que l’architecte solution doit travailler avec le DPO dès la phase de conception pour définir les Data Graphs qui alimenteront chaque agent, et non après déploiement.
Les ETI qui font cette erreur de séquençage se retrouvent à devoir reconfigurer des agents en production, ce qui est coûteux et risqué. L’architecture que j’observe fonctionner dans les organisations qui ont bien géré ce sujet consiste à créer des Data Graphs dédiés par agent, avec un périmètre de données minimal, plutôt que de donner à chaque agent accès à un profil unifié complet. La granularité est plus fine à configurer, mais elle est défendable devant une CNIL.
Pour aller plus loin sur la configuration de Data Cloud dans ce contexte, l’article sur l’implémentation Data Cloud couvre les patterns de segmentation qui s’appliquent directement ici.
Agentforce Voice et les contraintes réglementaires françaises
Agentforce Voice arrive en GA avec Agentforce 360, et c’est le canal qui génère le plus d’incertitude réglementaire pour les ETI françaises.
Les interactions vocales avec un agent IA sont soumises à des obligations spécifiques en France : information préalable de l’interlocuteur, enregistrement conditionnel au consentement, conservation des logs selon des durées définies. Ces obligations ne sont pas nouvelles, elles s’appliquaient déjà aux bots vocaux précédents. Ce qui change avec Agentforce Voice, c’est la sophistication de l’interaction, ce qui rend l’obligation d’information préalable encore plus critique.
L’architecture recommandée pour les ETI françaises est de traiter Agentforce Voice comme un canal distinct avec ses propres guardrails, séparés des agents textuels. Les Agent Script guardrails permettent d’encoder l’obligation d’identification de l’agent IA en début d’interaction, et de bloquer certaines catégories de données sensibles sur ce canal. Ce n’est pas une limitation de la plateforme, c’est une configuration délibérée.
Les ESN qui accompagnent des ETI sur ces déploiements ont intérêt à formaliser ces configurations dans leurs livrables de conception, car c’est ce que les DSI et les équipes juridiques demanderont lors des revues de mise en production.
Ce que les ETI ne doivent pas faire
Le pattern d’échec le plus fréquent dans les déploiements Agentforce en ETI n’est pas technique. C’est organisationnel : lancer un pilote agent sans avoir défini qui est responsable de la gouvernance de cet agent en production.
Un agent Agentforce n’est pas un rapport ou un tableau de bord. Il prend des actions, envoie des communications, modifie des données. La question “qui valide les changements de configuration de cet agent ?” doit avoir une réponse avant le go-live, pas après le premier incident.
La structure qui fonctionne dans les ETI avec des équipes IT de taille raisonnable est un comité de validation léger : un représentant métier propriétaire du processus, un architecte solution ou un administrateur Salesforce senior, et un représentant conformité pour les agents qui touchent des données personnelles. Ce comité valide les changements de Topics, d’Instructions et d’Actions avant déploiement en production. Pas de réunion hebdomadaire obligatoire, juste un processus de validation documenté.
C’est moins glamour que de parler d’Atlas Reasoning Engine, mais c’est ce qui détermine si un déploiement Agentforce tient dans la durée.
Pour les organisations qui partent de zéro sur la gouvernance Salesforce, le framework de gouvernance pour l’enterprise pose les bases sur lesquelles greffer une gouvernance Agentforce spécifique.
La conception détaillée d’une architecture Agentforce adaptée aux contraintes d’une ETI française est couverte dans l’offre Architecture IA et Agentforce, qui inclut le mapping des guardrails métier existants sur les primitives de la plateforme.
Points Clés
- Agentforce Builder centralise la configuration des agents en un point auditable unique, ce qui rend la gouvernance réelle plutôt que documentaire.
- Agent Script guardrails encode des contraintes de comportement non-contournables, directement mappables sur les procédures de conformité existantes d’une ETI.
- Intelligent Context nécessite une définition explicite des Data Graphs par agent dès la conception, avec validation DPO, pour rester conforme RGPD.
- Agentforce Voice requiert des guardrails distincts des agents textuels, incluant l’identification obligatoire de l’agent IA en début d’interaction selon le droit français.
- La gouvernance Agentforce ne nécessite pas de restructuration IT : elle nécessite un processus de validation des changements de configuration avec un propriétaire métier identifié par agent.
