Agentforce ETI : unifier avant de déployer

L’acquisition de Momentum par Salesforce a été commentée sous l’angle de l’orchestration revenue et des insights conversationnels. C’est le bon angle pour les grandes entreprises. Pour les ETI françaises, le signal est différent, et plus urgent : Agentforce ETI ne fonctionne pas sur des données fragmentées. Avant de déployer des agents, il faut résoudre le problème en amont.

Ce que Momentum change concrètement pour les ETI

Momentum apporte deux capacités dans l’écosystème Salesforce : l’analyse des conversations commerciales (appels, emails, réunions) et la visibilité sur l’exécution des processus revenue. Ces deux capacités alimentent les agents Agentforce avec du contexte. Un agent qui orchestre une relance commerciale a besoin de savoir ce qui a été dit lors du dernier appel, quel est l’état réel de l’opportunité, et quelles actions ont déjà été tentées.

Le problème, c’est que cette chaîne de contexte suppose une architecture de données cohérente en amont. Dans les ETI françaises avec 200 à 2 000 utilisateurs Salesforce, ce n’est pas l’hypothèse de départ. C’est l’exception.

Un pattern courant dans les organisations de cette taille : Sales Cloud déployé il y a 6 à 10 ans, Service Cloud ajouté ensuite avec un modèle de données partiellement aligné, Marketing Cloud ou Pardot connecté via des intégrations point-à-point, et un ERP (SAP, Sage, Cegid) qui reste la source de vérité pour les données financières sans synchronisation fiable vers Salesforce. Les conversations Momentum vont s’indexer sur des enregistrements Account et Opportunity dont la qualité de données est, au mieux, partielle.

Le vrai prérequis : l’unification des données avant l’intelligence

Agentforce fonctionne sur un principe simple : l’Atlas Reasoning Engine raisonne à partir du contexte disponible. Si ce contexte est incomplet ou contradictoire, le raisonnement produit des actions incorrectes. Un agent commercial qui propose une remise sur un compte déjà en litige contentieux, parce que l’information n’est pas remontée dans Salesforce, n’est pas un problème d’IA. C’est un problème d’architecture de données.

Il existe trois façons d’aborder ce sujet dans une ETI. Une seule résiste au-delà du pilote.

La première : déployer Agentforce sur le périmètre existant, accepter les limitations, et itérer. Cela fonctionne jusqu’au moment où un agent prend une décision sur des données périmées et crée un incident client. À ce stade, la confiance dans l’outil s’effondre, et le projet est mis en pause.

La deuxième : attendre que le projet de nettoyage de données soit terminé avant de déployer quoi que ce soit. En pratique, ce projet dure 18 à 36 mois dans une ETI avec des systèmes legacy. Agentforce n’est jamais déployé.

La troisième : définir un périmètre de données minimal mais fiable, déployer Data Cloud pour unifier ce périmètre, et construire les premiers agents sur cette fondation. C’est l’approche qui fonctionne. Elle demande de renoncer à l’exhaustivité au départ, ce qui est contre-intuitif pour des DSI habitués à des projets de transformation globale.

Comment Data Cloud devient le prérequis architectural

Dans une ETI française typique, le chemin vers Agentforce passe par Data Cloud, pas autour. Voici pourquoi.

Data Cloud permet de créer des Data Streams depuis les sources existantes : Sales Cloud, Service Cloud, l’ERP via MuleSoft ou des connecteurs natifs, les données de conversation Momentum une fois intégrées. Ces flux alimentent des Data Model Objects normalisés, sur lesquels Identity Resolution applique ses rulesets pour créer des profils Unified Individual cohérents.

Ce profil unifié devient le contexte sur lequel Agentforce raisonne. Un agent qui gère une relance commerciale peut accéder à l’historique d’achat depuis l’ERP, aux tickets de support ouverts depuis Service Cloud, aux dernières interactions email depuis Momentum, et au statut de l’opportunité depuis Sales Cloud. Tout ça dans un seul contexte, sans que l’agent ait à interroger quatre systèmes séparément.

La latence d’activation en temps réel dans Data Cloud se situe typiquement entre 2 et 5 minutes pour les événements déclenchés par Platform Events. Pour la plupart des cas d’usage ETI (relances, qualifications, escalades), c’est suffisant. Pour les cas d’usage nécessitant une réponse en moins de 30 secondes, l’architecture doit être revue.

L’autre avantage de passer par Data Cloud : la conformité RGPD est gérée au niveau de la plateforme. Dans une ETI française avec des données clients réparties sur plusieurs systèmes, centraliser la gestion des consentements et des droits d’accès dans Data Cloud simplifie considérablement la réponse aux obligations légales. C’est un argument que les DSI français comprennent immédiatement, parce que le coût de non-conformité est concret.

Les écueils spécifiques aux ETI françaises

Le premier écueil : confondre intégration et unification. Beaucoup d’ETI ont déjà des intégrations entre leurs systèmes. Salesforce reçoit des données de l’ERP via des jobs batch nocturnes. Marketing Cloud envoie des campagnes basées sur des segments exportés manuellement. Ces intégrations créent une illusion de cohérence. En pratique, les données ont des latences différentes, des modèles d’objet incompatibles, et aucune résolution d’identité. Agentforce ne peut pas raisonner sur ce type d’architecture.

Le deuxième écueil : sous-estimer le travail de gouvernance. Data Cloud unifie les données, mais quelqu’un doit décider quelles règles Identity Resolution applique, quels champs sont sources de vérité, et comment les conflits entre systèmes sont résolus. Dans une ETI sans Chief Data Officer, cette décision tombe souvent dans un vide organisationnel. Le projet technique avance, mais les décisions de gouvernance ne sont jamais prises. Résultat : des profils unifiés techniquement corrects mais métier incorrects.

Le troisième écueil : démarrer par les cas d’usage les plus visibles plutôt que les plus fondés. Un agent de qualification de leads est séduisant à démontrer. Mais si les données de leads viennent de trois sources avec des doublons non résolus, l’agent va qualifier les mêmes prospects plusieurs fois, ou pire, ignorer des leads chauds parce qu’ils sont associés à un enregistrement orphelin. Les premiers cas d’usage Agentforce dans une ETI doivent être choisis en fonction de la qualité des données disponibles, pas de la valeur business théorique.

L’architecture qui fonctionne pour une ETI en 2026

Le séquençage recommandé pour une ETI française qui veut déployer Agentforce de façon viable :

Phase 1 (3 à 4 mois) : Audit de la qualité des données sur le périmètre Sales Cloud et Service Cloud. Identification des sources de vérité par domaine de données. Mise en place de Data Cloud avec les Data Streams prioritaires. Configuration des rulesets Identity Resolution sur le périmètre Account et Contact.

Phase 2 (2 à 3 mois) : Intégration des données ERP via MuleSoft sur les objets financiers clés (commandes, factures, statut client). Validation des profils unifiés avec les équipes métier. Définition des Calculated Insights nécessaires aux premiers agents (score d’engagement, risque de churn, potentiel d’upsell).

Phase 3 (2 à 3 mois) : Déploiement des premiers agents Agentforce sur le périmètre de données validé. Topics et Actions définis sur des processus à faible risque d’erreur. Intégration des données Momentum sur les conversations commerciales une fois disponibles.

Ce séquençage donne 7 à 10 mois avant un premier déploiement Agentforce en production. C’est plus long que ce que les ESN vendent en général. C’est aussi la durée réaliste pour une ETI qui veut des agents qui fonctionnent, pas des pilotes qui impressionnent en démo.

La décision actuelle sur l’architecture de données détermine si Agentforce devient un avantage opérationnel ou un projet de plus qui n’atteint pas ses objectifs. Dans 18 mois, les ETI qui auront investi dans l’unification des données auront des agents capables de raisonner sur un contexte complet. Celles qui auront déployé des agents sur des silos existants seront en train de gérer les incidents et de reconstruire la confiance.

Points Clés

• Agentforce raisonne sur le contexte disponible. Des données fragmentées produisent des décisions incorrectes, indépendamment de la qualité du modèle IA.
• Dans les ETI françaises avec des architectures multi-cloud Salesforce et un ERP non synchronisé, Data Cloud est le prérequis architectural à Agentforce, pas une option complémentaire.
• L’acquisition Momentum ajoute des données de conversation dans l’équation. Ces données n’ont de valeur que si elles s’indexent sur des enregistrements Account et Opportunity fiables.
• Identity Resolution dans Data Cloud résout le problème des doublons et des identités fragmentées. Sans cette étape, les agents opèrent sur des profils incomplets.
• Le séquençage réaliste pour une ETI : 3 à 4 mois d’unification des données, puis déploiement Agentforce sur un périmètre validé. Les projets qui inversent cet ordre échouent au-delà du pilote.

Pour aller plus loin sur l’architecture Data Cloud dans ce contexte, voir le guide d’implémentation Data Cloud et les patterns d’architecture multi-cloud. Si vous évaluez la maturité de votre org avant un déploiement Agentforce, la checklist d’architecture Salesforce est un point de départ utile.