Agentforce peut accélérer un parcours précis dans un org Salesforce ancien. Il peut aussi masquer une dette technique pendant quelques mois et ajouter une nouvelle couche de dépendances. La différence tient au diagnostic et aux critères de sortie.
Ce que la dette technique recouvre réellement
Dans un org mature, la dette peut se trouver dans plusieurs couches :
- automatisations qui se chevauchent ;
- Apex ou Flows sans tests suffisants ;
- modèle de permissions difficile à expliquer ;
- intégrations point-à-point sans propriétaire clair ;
- données dont la source de vérité n’est pas définie ;
- packages ou APIs en fin de vie ;
- déploiements manuels et rollback fragile ;
- documentation et observabilité insuffisantes.
Le premier travail consiste à relier chaque dette à un impact observable : incident, délai de changement, risque de sécurité, erreur de données, coût d’exploitation ou blocage métier.
Ce qu’Agentforce peut et ne peut pas faire
Un agent peut :
- guider un utilisateur dans un parcours borné ;
- appeler une Action contrôlée ;
- résumer un contexte autorisé ;
- proposer une étape suivante ;
- escalader avec les faits déjà collectés.
Il ne corrige pas automatiquement :
- une source de données contradictoire ;
- une permission excessive ;
- une intégration non idempotente ;
- une règle métier sans propriétaire ;
- une absence de monitoring ;
- une procédure de déploiement non maîtrisée.
Si l’agent contourne ces défauts sans plan de retrait, le programme déplace la dette au lieu de la réduire.
Construire un registre de dette exploitable
Pour chaque élément, documentez :
| Champ | Question |
|---|---|
| Composant | Quel Flow, classe, objet, intégration ou contrôle ? |
| Symptôme | Quel incident ou délai est observé ? |
| Dépendances | Quels parcours et systèmes sont concernés ? |
| Propriétaire | Qui décide de conserver, corriger ou retirer ? |
| Risque | Sécurité, données, disponibilité, coût ou conformité ? |
| Preuve de sortie | Quel test montrera que la dette est traitée ? |
Classez ensuite par impact et dépendance, pas par préférence technique.
Lancer un cas d’usage Agentforce sans aggraver l’org
Un premier cas d’usage doit avoir :
- un Topic borné ;
- une source de vérité identifiée ;
- des Actions avec permissions et erreurs explicites ;
- une escalade humaine ;
- un jeu de tests versionné ;
- un propriétaire métier et technique ;
- une date de revue du contournement éventuel.
Data 360 n’est pas un prérequis universel. Il devient pertinent si le cas nécessite une identité cross-système, un grounding ou une activation gouvernée que l’architecture existante ne peut fournir de façon sûre.
Organiser la modernisation par vagues
Une séquence prudente peut être :
- Stabiliser : incidents, permissions critiques, observabilité et rollback.
- Rendre explicite : propriétaires, sources de vérité, dépendances et contrats d’interface.
- Simplifier : automatisations redondantes, composants obsolètes et transformations inutiles.
- Automatiser la qualité : tests, analyse statique, déploiement et contrôles de régression.
- Retirer : supprimer le contournement lorsque le système cible est prêt.
La durée de chaque vague vient du registre de dette, de la capacité disponible et des critères de sortie. Un calendrier public standard ne remplace pas ce travail.
Mesurer ce qui change
Évitez une métrique unique de « dette réduite ». Suivez localement :
- incidents liés au composant ;
- temps de diagnostic et de restauration ;
- taux de changements bloqués ou annulés ;
- couverture de tests utile ;
- nombre de propriétaires inconnus ;
- intégrations sans SLO ni alerte ;
- composants effectivement retirés ;
- coût d’exploitation mesuré sur la même période.
Décision sponsor
Le sponsor doit pouvoir distinguer trois décisions :
- lancer un cas Agentforce borné maintenant ;
- corriger une dépendance avant le lancement ;
- arrêter le cas si la donnée, la sécurité ou l’exploitation ne sont pas défendables.
Agentforce peut coexister avec une modernisation progressive. Il ne doit jamais servir de preuve que la dette sous-jacente a disparu.
