Le lancement d’Agentforce Communications pose une question que chaque DSI télécom français se pose en ce moment : est-ce qu’on peut déployer des agents IA sur nos systèmes sans refondre notre stack BSS/OSS ? La réponse est oui. Mais la condition, c’est que l’Agentforce intégration, gouvernance données soit traitée comme un sujet d’architecture, pas comme un projet de déploiement.
Ce n’est pas la même chose.
Pourquoi le marché télécom français est structurellement différent
Les opérateurs français opèrent avec des contraintes que les blueprints Salesforce génériques ne capturent pas. D’un côté, des systèmes BSS vieux de 15 à 20 ans, souvent hybrides entre des progiciels comme Amdocs ou Comverse et des développements maison. De l’autre, des obligations RGPD renforcées par l’ARCEP sur la gestion des données d’abonnés. Entre les deux, des ETI régionales et des MVNO qui n’ont ni les équipes ni les budgets pour une transformation de fond.
Agentforce Communications s’appuie sur des Topics et Actions préconfigurés pour les cas d’usage télécoms : gestion des incidents réseau, automatisation des devis, suivi des SLA pour les interventions terrain. L’Atlas Reasoning Engine orchestre ces agents en s’appuyant sur des données contextuelles. Le problème, c’est que ces données contextuelles doivent venir de quelque part. Et dans un opérateur français moyen, elles sont réparties sur 6 à 12 systèmes qui ne se parlent pas.
La plupart des ESN abordent ce sujet en proposant une migration vers Data Cloud comme prérequis. Cela fonctionne jusqu’au moment où le DSI réalise que le projet Data Cloud seul représente 18 à 24 mois de travail avant que le premier agent soit opérationnel.
L’architecture qui fonctionne sans tout reconstruire
L’approche qui résiste dans les organisations télécoms enterprise repose sur trois couches distinctes, déployées séquentiellement.
Couche 1 : Fédération des données via MuleSoft
Plutôt que de migrer les données BSS/OSS vers Data Cloud en amont, on connecte les systèmes sources via MuleSoft avec des APIs REST exposées comme External Services dans Salesforce. L’agent Agentforce appelle ces services en temps réel pour récupérer le statut d’un abonné, l’historique des incidents ou les conditions contractuelles. La latence est de l’ordre de 200 à 800 millisecondes selon la complexité des appels. C’est acceptable pour la majorité des cas d’usage service client.
Ce pattern évite la duplication de données sensibles. Les données d’abonnés restent dans les systèmes sources, conformes aux politiques de rétention RGPD existantes. L’agent n’en voit qu’une projection contextuelle, pas une copie persistante.
Couche 2 : Gouvernance des Topics et des Instructions
Un pattern courant dans les organisations enterprise avec des équipes distribuées : les Topics Agentforce prolifèrent sans contrôle. Chaque équipe métier configure ses propres agents, avec des Instructions contradictoires, des périmètres qui se chevauchent, et aucune traçabilité des décisions prises par l’Atlas Reasoning Engine.
L’architecture qui fonctionne ici centralise la définition des Topics dans un référentiel géré par l’équipe architecture. Les Instructions sont versionnées. Les Actions sont auditées via Platform Events, qui capturent chaque invocation avec son contexte et son résultat. Cela vous donne la traçabilité nécessaire pour répondre aux exigences RGPD sur l’explicabilité des décisions automatisées, sans développement custom.
Couche 3 : Identity Resolution progressive
Pour les opérateurs avec plusieurs marques ou plusieurs systèmes de facturation, le problème de l’identité abonné est structurel. Un même client peut exister sous trois identifiants différents selon qu’il est abonné mobile, fixe ou entreprise.
Data Cloud Identity Resolution résout ce problème via des rulesets de correspondance configurables : email, numéro de téléphone, SIRET pour les clients B2B. Mais l’erreur classique est de vouloir résoudre l’intégralité du référentiel avant de démarrer. En pratique, une résolution partielle sur 60 à 70% des profils suffit pour que les agents Agentforce opèrent avec une vue cohérente sur la majorité des interactions. Le reste se résout progressivement, au fil des enrichissements.
Ce que les DSI sous-estiment systématiquement
Le problème n’est pas technique. Le problème, c’est la gouvernance des données en amont du déploiement.
Trois écueils reviennent dans les projets télécoms français.
Le premier : traiter la qualité des données comme un prérequis bloquant. Des organisations avec plus de 3 000 points de contact retail attendent parfois 12 mois que leurs données soient “propres” avant de démarrer. L’architecture qui survit accepte l’imperfection et construit des mécanismes de fallback dans les Actions Agentforce : si la donnée est manquante ou incohérente, l’agent escalade vers un conseiller humain plutôt que de produire une réponse erronée.
Le deuxième : négliger le Prompt Builder dans la chaîne de gouvernance. Les templates Flex de Prompt Builder permettent d’injecter des données contextuelles dans les prompts envoyés à l’Atlas Reasoning Engine. Sans gouvernance sur ces templates, les équipes métier modifient les prompts sans mesurer l’impact sur la cohérence des réponses. Un changement de formulation peut faire basculer un agent d’un comportement conforme à un comportement problématique sur des sujets sensibles comme les conditions de résiliation ou les engagements contractuels.
Le troisième : ignorer l’Agentforce Testing Center jusqu’à la mise en production. Les tests de régression sur les agents doivent être intégrés dans le cycle de développement dès les premières semaines. Dans les télécoms, où les cas d’usage couvrent des scénarios réglementés (portabilité, résiliation, facturation), un agent non testé en conditions réelles représente un risque opérationnel et juridique.
Cadrage pour les 18 prochains mois
La décision actuelle détermine si votre organisation peut itérer sur Agentforce de manière autonome ou si elle reste dépendante d’une ESN pour chaque évolution.
Les opérateurs qui démarrent avec une architecture fédérée via MuleSoft et une gouvernance centralisée des Topics ont généralement un premier agent en production en 3 à 4 mois. Cela leur donne une base pour mesurer l’impact réel avant d’engager un projet Data Cloud plus structurant. Dans 18 mois, ils auront les données de performance nécessaires pour justifier l’investissement dans une unification complète des profils abonnés.
Ceux qui attendent d’avoir une architecture “parfaite” avant de déployer se retrouvent dans 18 mois avec un projet Data Cloud en cours, aucun agent en production, et une pression croissante de la direction générale sur les résultats IA.
Pour aller plus loin sur l’architecture Identity Resolution dans ce contexte, l’article sur Data Cloud Identity Resolution détaille les rulesets de correspondance et les seuils de confiance applicables aux profils multi-systèmes.
Points Clés
- L’Agentforce intégration, gouvernance données dans les télécoms français ne nécessite pas de migrer vers Data Cloud en amont : une fédération via MuleSoft avec External Services permet de démarrer en 3 à 4 mois avec des données qui restent dans les systèmes sources.
- La gouvernance des Topics et des Instructions Agentforce doit être centralisée dès le départ. La prolifération non contrôlée des agents dans des équipes distribuées est le premier vecteur de non-conformité RGPD sur l’explicabilité des décisions automatisées.
- Platform Events est le mécanisme natif pour auditer les invocations d’agents sans développement custom. Chaque Action peut être tracée avec son contexte et son résultat, ce qui répond aux exigences de traçabilité sans surcharge architecturale.
- Identity Resolution progressive sur 60 à 70% des profils suffit pour opérationnaliser les agents sur la majorité des interactions. Attendre une résolution complète du référentiel abonnés est le principal facteur de retard dans les projets télécoms.
- Le Prompt Builder doit être inclus dans le périmètre de gouvernance dès le départ. Les templates Flex sont des vecteurs de dérive comportementale si leur modification n’est pas versionnée et auditée.
