Le partenariat VCARB-Salesforce autour d’Agentforce 360 a fait beaucoup de bruit. Ce que la communication officielle ne dit pas, c’est ce que ce type de déploiement révèle sur la mécanique commerciale des ESN françaises qui se positionnent sur l’Agentforce intégration dans les grands comptes.
Ce n’est pas un article sur la Formule 1. C’est un article sur la façon dont les ESN structurent leurs offres, où elles capturent de la valeur, et où elles prennent des risques architecturaux qu’elles ne mesurent pas toujours.
Ce que le cas VCARB révèle sur la structure d’un déploiement Agentforce 360
VCARB a déployé Agentforce 360 pour unifier l’engagement fan à travers plusieurs canaux : service client, contenu personnalisé, interactions en temps réel pendant les courses. L’architecture sous-jacente implique nécessairement Data Cloud pour l’unification des profils, l’Atlas Reasoning Engine pour le raisonnement multi-étapes, et des Topics/Actions configurés pour des cas d’usage métier spécifiques.
Ce pattern est directement transposable aux grands comptes français. Remplacez “fan engagement” par “parcours client omnicanal” dans le retail, “gestion des sinistres” dans l’assurance, ou “suivi de compte” dans la banque de détail. La structure architecturale est identique : Data Streams pour l’ingestion, Identity Resolution pour l’unification, Data Graphs pour les jointures pré-calculées, et des agents Agentforce qui consomment ces données enrichies via des Actions configurées.
Ce qui change entre VCARB et un grand compte français, c’est la contrainte RGPD sur les données personnelles traitées par le LLM, et la complexité des systèmes legacy à intégrer. Ces deux dimensions sont précisément là où les ESN françaises construisent leurs marges.
Comment les ESN françaises découpent leurs offres commerciales
En pratique, les ESN structurent leurs offres Agentforce intégration en trois couches distinctes, chacune avec sa propre logique de facturation.
La couche socle couvre l’architecture Data Cloud : configuration des Data Streams, définition des Data Model Objects, mise en place des rulesets d’Identity Resolution. C’est du travail d’ingénierie relativement standardisé. Les ESN qui ont industrialisé cette couche la vendent en forfait, avec des délais de 6 à 10 semaines pour un périmètre défini. Les marges sont correctes mais pas exceptionnelles, parce que la concurrence est forte et que Salesforce lui-même pousse ses propres équipes professionnelles sur ce segment.
La couche d’intégration métier est là où les ESN françaises capturent le plus de valeur. Connecter Agentforce aux systèmes legacy — ERP SAP, outils de gestion de sinistres, plateformes de gestion de contrats — nécessite soit MuleSoft, soit des External Services configurés directement dans Salesforce. Dans les organisations avec des systèmes hétérogènes, cette couche représente souvent 40 à 60% du budget total d’un projet Agentforce. Les ESN qui ont des compétences MuleSoft certifiées et une connaissance sectorielle profonde peuvent facturer cette couche en régie avec des taux journaliers significativement au-dessus du marché standard.
La couche de gouvernance IA est la plus récente et la plus rentable. Elle couvre la configuration du Prompt Builder pour garantir que les instructions données aux agents respectent les contraintes RGPD, la mise en place de l’Agentforce Testing Center pour valider les comportements avant déploiement, et la définition des guardrails qui encadrent ce que l’Atlas Reasoning Engine peut ou ne peut pas faire avec les données personnelles. Les DSI français sont particulièrement sensibles à cette couche depuis que la CNIL a commencé à s’intéresser aux traitements automatisés basés sur des LLM.
Les risques architecturaux que les ESN sous-estiment
La plupart des projets Agentforce intégration en France échouent ou dérapent pour trois raisons récurrentes, et aucune n’est liée à la technologie Salesforce elle-même.
Le premier problème est la qualité des données en entrée. L’Atlas Reasoning Engine est un moteur de raisonnement sophistiqué, mais il raisonne sur ce qu’on lui donne. Si les Data Graphs qui alimentent les agents contiennent des profils mal unifiés — ce qui est systématique dans les organisations avec plus de 3 000 points de contact et plusieurs années d’historique CRM — les agents produisent des réponses incohérentes. Les ESN qui ne font pas d’audit de qualité des données avant de configurer les agents se retrouvent à déboguer des comportements imprévisibles en phase de recette, avec des coûts de correction qui explosent.
Le deuxième problème est la définition des Topics. Un Topic Agentforce définit le périmètre de ce qu’un agent peut traiter. Dans les grands comptes, la tentation est de créer des Topics trop larges pour “couvrir tous les cas d’usage”. En pratique, un agent avec un Topic mal délimité dérive vers des comportements hors périmètre que l’Atlas Reasoning Engine ne peut pas anticiper. La règle architecturale qui fonctionne : un Topic par domaine métier clairement borné, avec des Actions explicitement listées et des Instructions qui définissent les cas de refus autant que les cas de traitement.
Le troisième problème est l’absence de stratégie de fallback. Agentforce n’est pas infaillible. Dans un contexte grand compte, un agent qui ne sait pas répondre doit escalader vers un humain de façon fluide, pas afficher un message d’erreur générique. Configurer correctement les mécanismes d’escalade — via Flow orchestration ou Platform Events — est une compétence que beaucoup d’ESN n’ont pas encore industrialisée.
Pour aller plus loin sur les patterns d’architecture multi-agent qui émergent dans ce contexte, l’article sur l’orchestration multi-agent de TDX 2026 donne un cadre utile pour structurer les décisions de déploiement.
Ce que les DSI français devraient exiger de leurs ESN
Un DSI qui engage une ESN sur un projet Agentforce intégration doit poser quatre questions précises avant de signer.
Première question : quelle est votre approche pour l’audit de qualité des données avant la configuration des agents ? Une ESN sérieuse proposera un sprint d’analyse des Data Streams existants, une évaluation des rulesets d’Identity Resolution, et un rapport sur le taux de profils unifiés exploitables. Une ESN qui saute cette étape vend de la configuration, pas de l’architecture.
Deuxième question : comment gérez-vous la conformité RGPD dans les prompts envoyés à l’Atlas Reasoning Engine ? Les données personnelles qui transitent dans les templates Prompt Builder doivent être traitées avec les mêmes garanties que n’importe quel traitement automatisé. L’ESN doit avoir une réponse précise sur la localisation des données, les mécanismes de pseudonymisation, et la traçabilité des décisions prises par les agents.
Troisième question : quelle est votre stratégie de test avant mise en production ? L’Agentforce Testing Center permet de simuler des conversations et de valider les comportements des agents sur des scénarios définis. Un projet sans plan de test structuré est un projet qui découvrira ses problèmes en production.
Quatrième question : comment mesurez-vous le ROI post-déploiement ? Les Calculated Insights de Data Cloud permettent de construire des métriques de performance directement liées aux interactions des agents. Si l’ESN ne propose pas de framework de mesure, elle n’est pas en mesure de démontrer la valeur de ce qu’elle livre.
Pour les organisations qui évaluent leur maturité avant de lancer ce type de projet, les patterns décrits dans le guide d’implémentation Data Cloud donnent une base solide pour évaluer la préparation des données.
La vraie question de monétisation pour les ESN
Le cas VCARB illustre quelque chose d’important : Agentforce 360 n’est pas un produit qu’on déploie, c’est une plateforme qu’on configure en continu. Les cas d’usage évoluent, les données changent, les comportements des agents doivent être ajustés. C’est structurellement différent d’un projet CRM classique avec une date de fin.
Les ESN françaises qui ont compris cela ne vendent pas des projets Agentforce. Elles vendent des contrats de service managé qui incluent la maintenance des Topics et Actions, l’évolution des Calculated Insights, et l’adaptation des guardrails au fur et à mesure que la réglementation évolue. C’est un modèle économique récurrent, avec des marges plus stables et une relation client plus profonde.
Les ESN qui continuent à vendre de l’Agentforce intégration comme un projet au forfait avec une livraison unique vont se retrouver dans une position difficile. Les clients qui ont déployé des agents en production découvrent rapidement que la valeur vient de l’itération, pas de la configuration initiale. Et ils cherchent des partenaires capables d’accompagner cette itération, pas des intégrateurs qui passent au projet suivant après la recette.
Pour les DSI qui veulent structurer cette relation de façon durable, les patterns d’architecture décrits sur la page dédiée à l’architecture Agentforce donnent un cadre pour évaluer ce qu’une ESN doit être capable de livrer sur la durée.
Points Clés
- L’Agentforce intégration dans les grands comptes se structure en trois couches : socle Data Cloud, intégration métier legacy, et gouvernance IA RGPD. La couche gouvernance est la plus rentable pour les ESN en 2026.
- Les projets Agentforce échouent rarement à cause de la technologie. Ils échouent à cause de données mal unifiées, de Topics trop larges, et de l’absence de stratégie de fallback vers les agents humains.
- Un DSI doit exiger quatre livrables avant signature : audit qualité des données, stratégie RGPD pour les prompts, plan de test Agentforce Testing Center, et framework de mesure ROI basé sur les Calculated Insights.
- Le modèle économique gagnant pour les ESN n’est pas le forfait projet mais le service managé récurrent : maintenance des Topics/Actions, évolution des Calculated Insights, adaptation des guardrails réglementaires.
- Le cas VCARB confirme qu’Agentforce 360 est une plateforme d’itération continue, pas un déploiement one-shot. Les ESN qui n’ont pas adapté leur modèle commercial à cette réalité perdront leurs clients au renouvellement.
