Les projets Agentforce déraillent lorsque configuration, architecture, delivery et exploitation sont traitées séparément. Une direction Agentforce indépendante relie ces décisions avant qu’une équipe n’ouvre le nouveau Builder, et avant qu’un agent historique ne soit activé sur un moteur de raisonnement différent.
Le problème n’est pas qu’Agentforce soit devenu plus riche. Le problème, c’est que l’écriture d’agents a déjà changé de contrat: depuis la semaine du 13 juillet 2026, la création passe exclusivement par le nouveau Builder, alors que Voice, un index de documents et les tests n’ont toujours pas le même propriétaire.
Pourquoi les projets Agentforce déraillent
La difficulté n’est pas de configurer un Subagent ou une Action. Elle est de relier le périmètre, les données, les permissions, les intégrations, les tests, le support et la responsabilité métier.
Salesforce présente Agentforce 360 comme un ensemble qui réunit Builder, Agent Script, Voice et Intelligent Context (annonces Agentforce 360). Salesforce y nomme aussi Topics, Subagents et Instructions. Depuis avril 2026, la documentation développeur appelle les anciens Topics des Subagents, sans changement de fonction (Agent Script). Confirmer la disponibilité dans l’org cible reste un prérequis de cadrage.
Le Builder n’est plus un écran unique. Salesforce indique que, à partir de la semaine du 13 juillet 2026, la création d’agents a quitté le Builder historique: les agents déjà construits restent éditables, mais les nouveaux se créent dans le nouveau Builder, autour d’Agent Script (migration vers le nouveau Builder). Summer ‘26 a rendu ce Builder et Agent Script généralement disponibles (guide développeur Summer ‘26). Un lot “Agentforce 360” qui ignore cette coupure mélange deux moteurs.
Trois patterns d’échec reviennent.
L’agent trop large. Une instance concentre trop de Subagents, avec un catalogue d’Actions difficile à attribuer. Le nouveau Builder abaisse la friction d’écriture: canvas, vue Script, simulations. L’effet utile est la vitesse. L’effet collatéral, si l’accès n’est pas provisionné, c’est le chevauchement de périmètres. Le seuil acceptable se mesure par les tests, pas par un nombre universel.
L’intégration point à point. Chaque agent appelle directement les APIs métier. Pas de contrat partagé. Pas d’observabilité commune. Le premier changement d’API casse plusieurs agents. Le suivant, personne ne sait lesquels.
La gouvernance absente. Aucune suite de scénarios comparable entre version historique et version migrée. Aucune procédure de retour. Salesforce nomme aussi Agentforce Observability. Un produit de suivi ne crée pas à lui seul un propriétaire, un critère d’arrêt ou un rollback testé.
Ces échecs ne viennent pas d’un manque de compétences Salesforce. Ils viennent d’un manque d’architecture système.
Ce qu’une direction Agentforce apporte réellement
Ce rôle de direction Agentforce indépendante relie trois problèmes que les équipes traitent souvent séparément: l’architecture, la delivery et la gouvernance. Il tranche aussi un quatrième: sur quel Builder vit le parc, et qui autorise l’activation.
Décomposition système
L’architecture qui tient à l’échelle n’est jamais un agent unique. C’est un système d’agents spécialisés, avec des périmètres clairs et des propriétaires nommés.
En pratique, un agent de qualification lead, un agent de routage de case et un agent de recommandation produit restent séparés lorsque leurs permissions, données et propriétaires diffèrent. La taille de l’ensemble de Subagents se décide par la séparabilité et les tests.
Cette décomposition rend le système plus testable. Elle permet d’attribuer incidents, changements et métriques à un périmètre. Son effet sur la latence doit être mesuré dans l’environnement réel.
Couche d’abstraction d’intégration
Les appels directs aux API métier ne sont pas interdits par principe. Ils doivent être justifiés par le volume, la stabilité du contrat, la sécurité, l’observabilité et la capacité de changement.
Quand plusieurs agents partagent des intégrations complexes, une couche via MuleSoft, Apex ou un service API peut centraliser transformations, erreurs, relances et contrôles. External Services enregistre des opérations externes décrites par une spécification OpenAPI et en fait des actions invocables (External Services). Ce n’est pas, à soi seul, un middleware complet.
La valeur de cette couche se mesure sur la réutilisation, les changements isolés, les incidents et le délai de reprise. Aucun seuil de dix systèmes ni économie universelle ne s’applique à toutes les organisations.
Le cadrage Data 360 contre MuleSoft, pour la frontière identité versus flux transactionnel, est développé dans Salesforce Data 360 vs MuleSoft.
Contrôles de production
La gouvernance Agentforce n’est pas une checklist. C’est le système qui rend un agent arrêtable, attribuable et rejouable.
Migration. Salesforce décrit une conversion qui crée une nouvelle version, sans downtime pendant la validation: l’agent historique reste actif jusqu’à l’activation de la version reconstruite, qui le désactive alors automatiquement (migration vers le nouveau Builder). Le moteur change: classification puis boucle ReAct d’un côté, graphe de Subagents et variables d’état de l’autre (migration des agents historiques). Le geste n’équivaut pas à un export d’écran.
Tests. Une suite de base doit d’abord capturer le comportement de la version historique, puis s’exécuter à l’identique sur la version migrée. Le propriétaire métier nomme les énoncés des parcours qui écrivent un enregistrement, plus au moins un cas d’interdiction. L’équipe delivery construit cette suite. Salesforce distingue le Testing Center historique (AiEvaluationDefinition) de l’onglet Tests d’Agentforce Studio (AiTestingDefinition, actuellement en beta) et des commandes Agentforce DX (migration des agents historiques). Ni l’un ni l’autre ne bloque un déploiement à lui seul. La condition d’activation, c’est la même suite verte, avant tout nouveau cas ajouté.
Version et retour. Salesforce indique que Builder compile un agent dans un fichier JSON portable (annonces Agentforce 360). Cela aide à versionner et à partager la configuration. Ce fichier n’est pas un rollback automatique. L’exploitation détient le critère d’arrêt et peut désactiver l’agent. Si l’activation a déjà eu lieu, le retour testé est la réactivation de l’agent historique, pas un espoir de fichier JSON.
Suivi. Taux d’erreur par agent, latence, taux d’escalade vers un humain. Observability peut alimenter ce suivi. Le seuil d’arrêt n’est pas un chiffre universel: c’est celui que l’exploitation a écrit avant le pilote, et qu’elle seule peut déclencher.
Les trois erreurs d’architecture les plus coûteuses
Confondre raisonnement probabiliste et contrôle déterministe
Le runtime combine des décisions probabilistes avec des Actions, des permissions, des validations et des automatisations qui doivent rester déterministes lorsque l’enjeu l’exige.
Les équipes qui placent des règles obligatoires uniquement dans des Instructions obtiennent des comportements difficiles à garantir. Agent Script est le langage du nouveau Builder: expressions pour conditions, transitions et séquence d’actions, instructions en langage naturel là où le modèle peut raisonner (Agent Script). La source établit une surface de contrôle. Une règle scriptée ne rend pas un traitement conforme à elle seule, et elle ne se propage pas automatiquement à tous les agents qui réutilisent une Action voisine.
La frontière à documenter reste simple: ce que le modèle peut interpréter, ce qu’un script ou une Action valide, ce qu’un humain approuve, ce qui reste interdit. Testez-les ensemble, y compris le repli lorsqu’une condition ne peut pas être évaluée.
Imposer ou ignorer Data 360 sans examiner le cas d’usage
Un périmètre étroit peut fonctionner avec les données CRM et Knowledge existantes. Le cas qui raisonne sur une identité unifiée et plusieurs systèmes peut nécessiter Data 360: Data Streams, Data Model Objects, Identity Resolution, Data Graphs, Calculated Insights. Ces composants ne garantissent ni une source de vérité unique ni une latence fixe.
Intelligent Context, présenté comme s’appuyant sur Data 360, extrait et structure des documents non structurés puis les expose aux agents (annonces Agentforce 360). La source ne décrit pas l’injection d’un profil Unified Individual complet, ni une mémoire inter-sessions par défaut. Le premier problème de conception est l’autorité du document: quelle source fait foi, qui l’indexe, comment une pièce obsolète est exclue.
Ne tranchez pas “avec ou sans Data 360”. Tranchez quelles données sont nécessaires, où elles sont autoritatives, quelle fraîcheur est requise, et quel produit satisfait ce contrat.
Voice change le contrat de latence, et le Builder
Voice n’est pas du chat lu à voix haute. Salesforce le décrit comme un agent vocal qui peut accéder aux données CRM, mettre à jour des enregistrements, déclencher des workflows, et transférer un appel vers un humain avec l’historique de la conversation (Agentforce Voice). La fiche produit indique une disponibilité GA dans toutes les régions, en anglais (US/UK), avec d’autres langues à suivre. Elle ne publie pas un seuil de latence universel.
Les évolutions Voice à venir sont décrites comme livrées sur le nouveau Builder; la création de nouveaux agents vocaux sur le Builder historique s’arrête à la même coupure de juillet 2026 (migration vers le nouveau Builder). Mesurez reconnaissance, raisonnement, chaque Action, récupération de données, synthèse et transfert. Une chaîne acceptable en chat asynchrone peut rater le critère vocal. Confirmez langue et disponibilité dans l’org avant d’en faire un jalon de programme.
Ce que cela signifie pour votre organisation
Si vous évaluez Agentforce aujourd’hui, le choix n’est plus configurer ou architecturer. C’est quelle architecture, sachant que l’écriture, le déterministe, la voix et le non structuré n’ont pas le même propriétaire, et que le parc peut déjà être coupé en deux Builder.
Option 1: traiter le sujet comme un projet de configuration. L’équipe crée des agents dans le nouvel écran, laisse les agents historiques sans suite de référence, puis découvre en production les dépendances de données, de sécurité, d’intégration et d’exploitation qui n’avaient pas été attribuées. Le coût apparaît dans la reprise, les incidents et le délai.
Option 2: gouverner le programme dès le départ. Le sponsor métier autorise l’activation. Le propriétaire plateforme provisionne le nouveau Builder. L’équipe delivery convertit, durcit Agent Script, et tient la suite comparable. L’exploitation écrit le critère d’arrêt avant le pilote. Les données et le corpus Intelligent Context ont un propriétaire nommé, interne même si une ESN construit. Cette préparation a un coût initial. Sa valeur se mesure sur les incidents évités, le taux de reprise, la vitesse de décision et la stabilité des changements.
La décision actuelle détermine si votre implémentation restera explicable lorsque Voice ou un index documentaire sera ajouté sur le même socle. Quand ESN et équipes internes se partagent le parc, une direction Agentforce indépendante nomme ces propriétaires avant le prochain canal. Un Program Control Review ne remplace pas cette attribution.
Points clés
- Les projets Agentforce échouent par manque d’architecture système, pas par manque de compétences Salesforce
- Depuis la semaine du 13 juillet 2026, créez les nouveaux agents dans le nouveau Builder et traitez la migration comme un changement de moteur, pas comme un changement d’écran
- Si une règle est obligatoire, portez-la par une permission, une validation, un script ou une approbation, pas par une Instruction seule
- Capturer une suite sur l’agent historique, la rejouer sur la version migrée, puis seulement activer. L’onglet Tests d’Agentforce Studio est encore en beta
- Data 360 devient pertinent pour l’identité unifiée ou l’indexation de documents. Ni l’un ni l’autre n’est un prérequis universel, et aucun des deux ne garantit une latence fixe
