La dette technique Salesforce dans les ETI françaises ne ressemble pas à celle des grands comptes. Elle est plus silencieuse, plus diffuse, et souvent invisible jusqu’au moment où elle bloque un projet stratégique. Spring ‘26 change l’équation, pas parce que Salesforce a sorti une nouvelle fonctionnalité spectaculaire, mais parce qu’Agentforce ETI et la modernisation technique convergent enfin vers un modèle accessible sans refonte budgétaire.
Le paradoxe des ETI face à Salesforce est bien documenté dans les DSI françaises : elles ont investi dans la plateforme, accumulé des personnalisations, et se retrouvent avec un org qui coûte cher à maintenir mais impossible à abandonner. La question n’est plus “faut-il moderniser ?” mais “comment le faire sans paralyser l’activité pendant 18 mois ?”
Pourquoi la dette technique des ETI est structurellement différente
Dans une ETI de 500 à 5 000 salariés, la dette technique Salesforce prend une forme particulière. Il n’y a pas d’équipe architecture dédiée. Les personnalisations ont été empilées par des consultants successifs, souvent sans documentation. Les Flows remplacent des Process Builder qui remplaçaient des Workflow Rules, mais les trois coexistent encore dans le même org.
Le résultat concret : des temps de chargement de pages qui dépassent 8 secondes sur les objets critiques, des déclencheurs Apex qui s’exécutent en cascade sur des volumes de données que personne n’avait anticipés, et des intégrations point-à-point avec des ERP qui cassent à chaque release Salesforce.
Ce que Spring ‘26 introduit avec Agentforce, c’est une couche d’orchestration qui peut absorber une partie de cette complexité sans la supprimer. L’Atlas Reasoning Engine, le moteur de raisonnement LLM d’Agentforce, peut prendre en charge des workflows décisionnels qui étaient auparavant codés en dur dans des Flows imbriqués ou des classes Apex. Ce n’est pas une solution miracle, mais c’est un levier architectural réel.
Ce que la plateforme Agentforce apporte concrètement aux architectures ETI
Depuis la release Spring ‘26, Salesforce a continué à consolider et étendre les capacités agentiques. Trois évolutions méritent l’attention des architectes solution travaillant avec des ETI.
Orchestration par Topics et Actions découplée du modèle de données. Les agents peuvent être configurés avec des Topics qui encapsulent des logiques métier sans toucher aux objets Salesforce sous-jacents. Pour une ETI avec un modèle de données vieillissant, c’est significatif : on déploie un agent de qualification commerciale qui interroge des champs personnalisés hérités, les normalise via des Instructions, et présente une interface cohérente aux utilisateurs, sans migrer les données. Agentforce Builder évolue vers une approche graph-based qui renforce ce contrôle déclaratif, avec une visibilité accrue sur les chemins d’exécution des agents.
Interopérabilité via MCP et A2A. Salesforce a confirmé la prise en charge du protocole A2A 1.0 et pousse MCP comme couche d’accès standardisée aux outils externes. Pour les ETI, cela change concrètement l’équation des intégrations : les agents peuvent désormais consommer des serveurs MCP tiers directement dans leurs Actions, sans code Apex custom. Une intégration ERP historique qui nécessitait un middleware maison peut être remplacée par un connecteur MCP déclaratif. La surface de code à maintenir à chaque release diminue mécaniquement.
Agentforce Testing Center pour valider sans régression. Disponible en GA, le Testing Center permet de définir des scénarios de test pour les agents et de les rejouer automatiquement. Pour une ETI sans QA dédiée, c’est le mécanisme qui rend la modernisation incrémentale moins risquée. Combiné aux flux plus déterministes que Salesforce intègre dans les parcours agentiques, il offre un filet de sécurité opérationnel réaliste.
L’architecture qui fonctionne ici est celle du “strangler fig” appliqué à Salesforce : on ne remplace pas l’existant d’un coup, on construit une couche agent qui prend en charge progressivement les cas d’usage, pendant que la dette sous-jacente est résorbée à un rythme soutenable.
Les écueils que les ESN françaises reproduisent systématiquement
Le marché français des ESN Salesforce a une tendance structurelle à sur-architecturer les projets Agentforce pour les ETI. On voit régulièrement des propositions qui conditionnent le déploiement d’agents à une migration Data Cloud complète, une refonte du modèle de données, et une gouvernance RGPD formalisée sur 6 mois. C’est la mauvaise approche.
Data Cloud est pertinent pour les ETI qui ont des volumes de données fragmentés sur plusieurs systèmes et un besoin d’Identity Resolution. Mais pour une ETI avec un Salesforce Sales Cloud bien alimenté et un ERP connecté, déployer Agentforce ne nécessite pas Data Cloud en prérequis. Les agents peuvent opérer directement sur les objets CRM standard et les External Services, ou via des connecteurs MCP si l’infrastructure le permet. Conditionner l’un à l’autre, c’est créer une dépendance artificielle qui rallonge les délais et gonfle les budgets.
L’autre erreur fréquente est de traiter Agentforce comme un projet de transformation plutôt que comme un outil d’ingénierie. Les DSI d’ETI n’ont pas besoin d’un “programme de transformation IA” avec un comité de pilotage mensuel. Ils ont besoin d’un agent opérationnel sur un cas d’usage précis en 6 à 8 semaines, avec des métriques claires. La disponibilité croissante de cas d’usage préconfigurés (IT Service, Lead Generation, support conversationnel) réduit encore le temps de démarrage si on reste discipliné sur le périmètre.
Sur la question RGPD, qui est systématiquement soulevée dans les ETI françaises, la position correcte est la suivante : Agentforce opère dans le périmètre Salesforce, qui est certifié et hébergé en Europe pour les orgs configurés en conséquence. Ce n’est pas une raison de ne pas faire de gouvernance, mais c’est une raison de ne pas bloquer le déploiement pendant 6 mois pour un audit exhaustif sur un agent de qualification commerciale.
Pour aller plus loin sur les enjeux RGPD spécifiques aux agents Agentforce dans le contexte français, l’article Spring ‘26 Agentforce et RGPD pour les ETI détaille les vecteurs de risque réels et les configurations à valider avant mise en production.
Comment structurer la modernisation en trois phases
L’architecture de modernisation qui fonctionne pour les ETI françaises suit une logique de phases courtes avec des livrables mesurables.
Phase 1 (semaines 1 à 6) : audit et premier agent. L’audit ne doit pas être exhaustif. Il doit identifier les trois à cinq Flows ou classes Apex qui concentrent le plus de maintenance et de risque de régression. Parmi ces candidats, on sélectionne celui qui correspond à un cas d’usage Agentforce naturel : qualification de leads, routage de tickets, mise à jour de statuts. On déploie un agent sur ce périmètre avec le Testing Center configuré dès le départ. Les cas d’usage préconfigurés disponibles dans Agentforce Builder réduisent le temps de cadrage initial.
Phase 2 (semaines 7 à 16) : remplacement des intégrations fragiles. On identifie les intégrations point-à-point les plus instables et on évalue leur migration vers des External Services ou des connecteurs MCP consommés directement par les agents. Cette phase réduit la surface de code custom et améliore la résilience à chaque release Salesforce. En pratique, les ETI qui ont entre 3 et 8 intégrations maison peuvent en migrer 2 à 3 sur cette période sans mobiliser une équipe dédiée. L’adoption du protocole A2A ouvre aussi la voie à une orchestration multi-agents si des workflows complexes de bout en bout justifient cette architecture.
Phase 3 (semaines 17 à 24) : extension et gouvernance. On étend le périmètre des agents aux cas d’usage adjacents, on formalise les Topics et Instructions dans un référentiel documenté, et on met en place les métriques de performance. C’est à ce stade, et seulement à ce stade, qu’on évalue si Data Cloud apporte une valeur incrémentale pour les besoins d’unification de données.
Cette séquence permet à une ETI de montrer des résultats concrets à la DSI en moins de deux mois. Les projets qui démarrent par 6 mois de cadrage ne survivent pas aux arbitrages budgétaires de mi-année.
Pour les DSI qui veulent comprendre le positionnement exact d’un architecte solution indépendant dans ce type de programme, la page Architecture IA et Agentforce détaille les modes d’intervention adaptés aux ETI.
Ce que Spring ‘26 ne résout pas
Il faut être honnête sur les limites. Agentforce ne résout pas la dette technique profonde liée à un modèle de données incohérent. Si une ETI a des doublons massifs sur ses comptes, des relations objet mal conçues, ou des volumes de données qui dépassent les limites gouverneur Apex, les agents ne compensent pas ces problèmes structurels. Ils les contournent temporairement, ce qui peut être utile, mais ce n’est pas une solution durable.
De même, les agents ne remplacent pas une gouvernance de release. Les ETI qui déploient sans processus de test formalisé vont créer de la dette technique Agentforce par-dessus leur dette technique Salesforce existante. Le Testing Center aide, mais il ne remplace pas une discipline de déploiement.
La modernisation technique réelle nécessite toujours une intervention sur le code et les données sous-jacentes. Ce que la plateforme permet aujourd’hui, c’est de financer cette intervention progressivement grâce aux gains opérationnels des agents, plutôt que de demander un budget de transformation massif en amont.
Points Clés
- Les agents Agentforce peuvent encapsuler des logiques métier héritées via Topics et Instructions sans migrer le modèle de données sous-jacent, ce qui rend la modernisation incrémentale viable pour les ETI.
- L’adoption des protocoles MCP et A2A par Salesforce permet de remplacer des intégrations Apex fragiles par des connecteurs déclaratifs, réduisant la surface de maintenance à chaque release.
- Data Cloud n’est pas un prérequis pour déployer Agentforce dans une ETI avec un CRM bien alimenté : conditionner l’un à l’autre est une erreur architecturale fréquente des ESN françaises.
- Le Testing Center en GA est le mécanisme qui rend la modernisation sans régression accessible aux ETI sans équipe QA dédiée.
- Une modernisation en trois phases de 24 semaines maximum est le format adapté aux ETI françaises : au-delà, les projets ne survivent pas aux arbitrages budgétaires internes.
