Agentforce ETI : réduire la dette technique

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 Spring ‘26 apporte concrètement aux architectures ETI

La release Spring ‘26 consolide plusieurs capacités Agentforce qui, combinées, créent une opportunité de modernisation incrémentale. Trois mécanismes 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 Agentforce Spring ‘26 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 peut déployer un agent de qualification commerciale qui interroge des champs personnalisés hérités, les normalise à la volée via des Instructions, et présente une interface cohérente aux utilisateurs, sans migrer les données.

Intégration externe via External Services sans code custom. Une part importante de la dette technique dans les ETI provient des intégrations maison avec des ERP ou des outils métier. Spring ‘26 renforce la capacité des agents à consommer des External Services directement dans leurs Actions, ce qui permet de remplacer progressivement des intégrations Apex fragiles par des connecteurs déclaratifs. En pratique, cela réduit la surface de code à maintenir à chaque release.

Agentforce Testing Center pour valider sans régression. Le Testing Center, disponible en GA dans Spring ‘26, permet de définir des scénarios de test pour les agents et de les rejouer automatiquement. Pour une ETI qui n’a pas de QA dédiée, c’est un filet de sécurité qui rend la modernisation incrémentale moins risquée.

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. 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. C’est ce que permet Spring ‘26 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. Les données ne quittent pas l’environnement contractuellement défini. 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 RGPD 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 avec Spring ‘26 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.

Phase 2 (semaines 7 à 16) : remplacement des intégrations fragiles. On identifie les intégrations point-à-point les plus instables et on les remplace par des External Services consommés 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.

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 des agents. 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, ce qui est le critère de succès réel dans ce segment de marché. 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. Spring ‘26 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, Agentforce ne compense pas ces problèmes structurels. Il les contourne temporairement, ce qui peut être utile, mais ce n’est pas une solution durable.

De même, les agents Agentforce 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 Spring ‘26 permet, 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 Spring ‘26 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’Atlas Reasoning Engine permet de remplacer des Flows imbriqués complexes par une orchestration déclarative, réduisant la surface de maintenance à chaque release Salesforce.
• 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 dans Spring ‘26 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.