Le débat agentforce vs microsoft copilot entreprise revient dans presque tous les comités d’arbitrage DSI que je croise depuis un an. Et la plupart du temps, la question est mal posée. Ce n’est pas un choix entre deux assistants IA concurrents, c’est un choix entre deux architectures de donnée radicalement différentes, avec des implications qui dépassent largement le périmètre du cas d’usage initial.
Pourquoi ce choix engage bien plus que l’IA générative
Le piège classique consiste à comparer les deux plateformes sur la qualité des réponses générées, la fluidité de l’interface conversationnelle ou le prix par utilisateur. C’est le mauvais niveau d’analyse. Copilot s’appuie sur le Microsoft Graph et l’écosystème Microsoft 365 : emails, documents SharePoint, Teams, calendriers. Agentforce s’appuie sur le CRM et, quand l’architecture est bien construite, sur Data Cloud comme couche d’unification des données client.
Ce qui distingue vraiment ces deux approches, c’est la nature des données qu’elles exploitent. Copilot excelle sur les tâches de productivité individuelle : résumer une réunion, rédiger un email, synthétiser un document. Agentforce est conçu pour des actions transactionnelles ancrées dans un contexte client : qualifier une opportunité, déclencher un remboursement, mettre à jour un dossier de service après-vente en respectant des règles métier précises.
Dans les organisations avec plus de 3 000 points de contact retail ou service client, cette distinction devient structurante. Un agent Copilot qui rédige un résumé d’incident client n’a aucune garantie de cohérence avec le référentiel CRM. Un agent Agentforce, correctement configuré avec des Topics et des Actions liés au modèle de données Salesforce, agit directement sur l’enregistrement source. La différence n’est pas cosmétique, elle conditionne la fiabilité opérationnelle du système.
Comment se décide l’architecture entre Agentforce et Copilot
L’erreur la plus fréquente est de traiter ce choix comme binaire. Dans la réalité des grandes organisations, les deux coexistent, et la vraie question architecturale est de savoir qui pilote quoi.
Le cadre qui fonctionne en pratique repose sur trois critères.
Premier critère, la source de vérité de la donnée. Si l’action de l’agent nécessite d’écrire ou de lire dans le CRM, dans un Data Model Object Salesforce, ou de déclencher un Flow métier, l’orchestration doit rester côté Agentforce. L’Atlas Reasoning Engine a été conçu pour raisonner sur des objets métier structurés, pas sur des documents non structurés dispersés dans un Data Lake bureautique. Tenter de faire écrire du CRM par un agent Copilot via des connecteurs tiers introduit une latence et un risque de désynchronisation qui finissent toujours par coûter cher en support.
Deuxième critère, la nature de la tâche. Les tâches de productivité pure (rédaction, synthèse de réunion, recherche documentaire interne) restent le terrain naturel de Copilot. Vouloir faire porter ces usages par Agentforce, c’est mal utiliser un outil transactionnel pour un besoin de productivité bureautique. À l’inverse, vouloir faire piloter un parcours de service client complexe par Copilot revient à demander à un outil de productivité de gérer une machine à états métier, ce qu’il ne fait pas.
Troisième critère, la gouvernance de l’identité et de la donnée client. C’est ici que Data Cloud change la donne. Quand une organisation a mis en place des Data Streams consolidant les interactions omnicanales, des rulesets d’Identity Resolution produisant un Unified Individual fiable, et des Data Graphs pour matérialiser les vues croisées produit/client/commande, Agentforce hérite directement de ce socle. Copilot, lui, n’a pas de mécanisme natif équivalent pour unifier une identité client à travers des systèmes hétérogènes. Il consomme ce qu’on lui expose via Graph Connector, mais il ne résout pas le problème de déduplication ou de réconciliation d’identité.
Architecture typique en coexistence :
[Data Streams] -> [Identity Resolution] -> [Unified Individual]
|
v
[Data Graphs] -> [Agentforce: Topics/Actions transactionnelles]
|
v
[Exposition read-only via API] -> [Copilot: synthèse, productivité bureautique]Dans ce schéma, Data Cloud agit comme la colonne vertébrale, Agentforce comme la couche d’action métier, et Copilot comme la couche de productivité individuelle qui consomme, sans jamais écrire, les données unifiées. C’est le pattern qui limite le risque de divergence entre systèmes.
J’ai déjà détaillé ailleurs pourquoi la maîtrise d’Agentforce devient un prérequis pour tout architecte solution travaillant sur des environnements CRM complexes, dans why-salesforce-architects-must-learn-agentforce. La logique est la même ici : un architecte qui ne comprend pas la différence entre orchestration transactionnelle et productivité augmentée finira par recommander la mauvaise plateforme pour le mauvais cas d’usage.
Ce que la plupart des organisations font mal
Le premier écueil, très répandu, consiste à laisser le choix se faire par défaut, en fonction du fournisseur de messagerie déjà en place. Une organisation sous Microsoft 365 déploie Copilot par réflexe, puis tente d’y greffer des cas d’usage transactionnels qui dépassent largement ce que l’outil a été conçu pour faire. Résultat typique : des agents qui hallucinent sur des statuts de commande parce qu’ils n’ont jamais de vue temps réel sur le système transactionnel réel.
Deuxième écueil, l’absence de gouvernance sur les instructions et les garde-fous métier. Sur chaque plateforme, l’équipe doit prouver le périmètre, les données accessibles, les actions autorisées et le comportement sur les cas limites avant la mise en production. Agentforce Testing Center peut contribuer à cette preuve côté Salesforce. La capacité équivalente côté Microsoft doit être évaluée sur le produit, l’édition et le cas d’usage réellement retenus, sans supposer une hiérarchie universelle entre les plateformes.
Troisième écueil : traiter la qualité des données comme un problème que le modèle résoudra seul. Un use case qui dépend d’un profil cross-système a besoin d’une source gouvernée et suffisamment à jour. Data 360 et Identity Resolution peuvent répondre à ce besoin lorsqu’il faut rapprocher des identités ; ils ne sont pas des prérequis universels à tout agent. Le même principe vaut pour les sources reliées à Microsoft : la décision dépend du contexte nécessaire, de sa fraîcheur et des droits d’accès.
Quatrième écueil, l’absence d’arbitrage clair sur la propriété des cas d’usage entre la DSI et les équipes métier. Lorsque plusieurs équipes déploient Agentforce et Copilot en parallèle sans registre partagé des cas d’usage, les plateformes peuvent finir par couvrir les mêmes besoins avec des contrôles différents. Un Centre d’Excellence peut porter l’arbitrage, à condition que ses droits de décision soient explicites. Le guide de conception d’un Salesforce Center of Excellence décrit ce contrat de gouvernance.
Le cinquième écueil concerne la traçabilité des décisions automatisées. Une action métier telle qu’un remboursement ou une modification de contrat exige des contrôles et des preuves plus forts qu’un résumé assisté. Les obligations exactes dépendent du processus, des données, du niveau d’autonomie et du cadre juridique applicable. Le registre de décision doit nommer ces exigences avant le choix de plateforme.
Le cadre de décision à appliquer maintenant
Pour les DSI qui doivent trancher cette année, la question n’est pas “Agentforce ou Copilot” mais “quelle plateforme pour quelle couche du système d’information”. Concrètement, cela suppose de cartographier les cas d’usage selon leur besoin d’écriture transactionnelle, leur exigence de traçabilité, et leur dépendance à une identité client unifiée.
Les architectures qui tiennent dans la durée sont celles qui posent d’abord le socle Data Cloud, avant même de statuer sur le choix de l’agent conversationnel. Sans cette étape, le choix entre Agentforce et Copilot devient un débat de préférence produit, déconnecté de la réalité opérationnelle. Avec ce socle en place, la décision devient presque mécanique : Agentforce pour l’action métier ancrée dans le CRM, Copilot pour la productivité bureautique, et une frontière API claire entre les deux.
C’est ce type d’arbitrage que je structure avec les DSI dans le cadre de missions d’architecture Agentforce, en particulier lorsque l’organisation a déjà un existant Microsoft 365 fortement ancré et cherche à éviter la duplication d’investissement. Le détail de cette approche est disponible sur la page /guides/agentforce-architecture.
À horizon deux ou trois ans, les organisations qui auront tranché tôt entre ces deux couches d’orchestration disposeront d’un avantage structurel net sur celles qui auront laissé les deux plateformes se chevaucher par défaut. La dette technique générée par un chevauchement mal arbitré aujourd’hui se traduit, dans les cas que j’observe le plus souvent, par des refontes complètes d’architecture agentique dans les 18 à 24 mois suivant le déploiement initial.
Points Clés
- Le choix agentforce vs microsoft copilot entreprise n’est pas un arbitrage produit, c’est un arbitrage architectural entre orchestration transactionnelle et productivité bureautique.
- Agentforce doit piloter toute action qui écrit dans le CRM ou déclenche un Flow métier, Copilot doit rester cantonné aux usages de productivité individuelle sur documents et messagerie.
- Data Cloud, via Data Streams, Identity Resolution et Data Graphs, constitue le socle qui conditionne la fiabilité des deux plateformes, pas seulement d’Agentforce.
- L’absence de gouvernance claire entre DSI et métiers sur la propriété des cas d’usage IA conduit systématiquement à des déploiements redondants et incohérents entre les deux systèmes.
- Les organisations qui posent le socle de donnée avant de choisir la plateforme conversationnelle évitent la refonte d’architecture qui survient typiquement 18 à 24 mois après un déploiement mal arbitré.
