Une question qui revient dans toutes les orgs
Depuis que Salesforce a placé les agents au centre de son discours, la même question m'arrive sous des formes différentes. Faut-il refaire nos automatisations avec de l'IA ? Nos Flows sont-ils dépassés ? Doit-on prévoir un budget pour cela cette année ?
La réponse courte est que les deux ne font pas le même métier, et que les opposer est le meilleur moyen de se tromper de projet. La réponse longue tient en une distinction : un Flow exécute une décision que vous avez déjà prise, un agent prend une décision à votre place.
Tout le reste découle de là.
Ce qu'un Flow fait, et fait très bien
Un Flow est déterministe. Pour une même situation, il produira toujours exactement le même résultat, aujourd'hui, dans six mois, et la dix millième fois.
Cette prévisibilité n'est pas une limite, c'est la fonctionnalité. Quand une commande doit être bloquée parce que la marque n'est pas autorisée dans le pays de livraison, vous ne voulez pas d'un système qui apprécie la situation. Vous voulez un blocage, systématique, documenté, que vous pouvez expliquer à un auditeur.
Un Flow est aussi gratuit au sens où il est inclus dans vos licences, traçable dans les journaux, versionné, et modifiable par n'importe quel administrateur compétent sans écrire de code. Ce sont quatre propriétés que l'on sous-estime tant qu'on ne les a pas perdues.
Ce qu'Agentforce apporte réellement
Un agent fonctionne à l'inverse. Vous lui donnez un rôle, des instructions, l'accès à vos données et une liste d'actions autorisées. Face à une demande formulée en langage naturel, il interprète l'intention, choisit les actions à enchaîner, et répond.
Cela ouvre trois capacités qu'un Flow n'a jamais eues. Il comprend une demande mal formulée, là où un Flow exige un formulaire. Il gère l'imprévu, là où un Flow exige que chaque branche ait été anticipée. Et il tient une conversation, au lieu de dérouler un écran.
Le point que l'on comprend le plus tard, et qui change la façon de concevoir : un agent ne remplace pas vos automatisations, il les appelle. Les actions qu'il déclenche sont le plus souvent des Flows, des classes Apex ou des appels d'API que vous avez construits. L'agent apporte la compréhension, votre org apporte l'exécution.
La règle des trois questions
Devant un besoin, je me pose trois questions dans cet ordre. Elles suffisent à trancher dans la grande majorité des cas.
- La bonne réponse est-elle toujours la même ? Si la règle peut s'écrire, même en dix conditions imbriquées, c'est un Flow. Une règle écrite est vérifiable, un raisonnement ne l'est pas de la même façon.
- Une erreur occasionnelle est-elle acceptable ? Sur un résumé de compte proposé à un commercial, oui : il relit. Sur un calcul de remise, une facturation ou un contrôle réglementaire, non. Ces sujets restent déterministes.
- La demande arrive-t-elle en langage libre ? Un email client, une question posée dans un chat, une demande interne mal cadrée : c'est là qu'un agent devient pertinent, parce qu'aucun formulaire n'aurait capté la demande.
Deux « oui » sur trois penchent vers l'agent. Un seul, et vous économiserez du temps et de l'argent en restant sur une automatisation classique.
Trois cas où je garde un Flow, sans hésiter
Un contrôle de conformité. Bloquer une commande selon un couple marque et pays de livraison est une règle, pas une appréciation. Elle doit s'appliquer à chaque fois, se documenter, et se modifier sans reprogrammer quoi que ce soit.
Un calcul. Remise, marge, échéance, montant de TVA. La bonne réponse existe et elle est unique. Un système qui a raison 98 % du temps est ici un système défaillant.
Un parcours de saisie cadré. Quand un commercial doit renseigner huit informations dans un ordre précis, un écran guidé reste plus rapide et plus fiable qu'une conversation. La conversation sert à comprendre, pas à collecter des champs connus d'avance.
Trois cas où un agent a du sens
Le premier niveau de support. Répondre aux questions récurrentes sur un délai, un statut de commande, une procédure. Le volume est élevé, les formulations sont infinies, et l'escalade vers un humain reste possible dès que l'agent atteint sa limite.
La préparation d'un rendez vous. Rassembler l'historique d'un compte, les affaires en cours, les derniers échanges, et en tirer une synthèse. Une erreur d'interprétation n'a pas de conséquence : le commercial lit avant d'entrer en réunion.
La qualification entrante. Un formulaire libre ou un email produit un texte non structuré. Un agent en extrait les informations utiles, crée l'enregistrement, et laisse un humain décider de la suite.
Le point commun de ces trois cas : un humain reste dans la boucle, et l'erreur se voit avant de coûter quelque chose.
Ce dont personne ne parle assez
Un agent raisonne sur vos données et agit par vos actions. Ses deux dépendances sont donc la qualité de votre base et la propreté de vos automatisations.
Dans une org où trois champs portent la même information sans que personne ne sache lequel fait foi, un agent choisira le mauvais avec une belle assurance. Dans une org où les automatisations se chevauchent depuis des années, lui donner le droit d'agir revient à ajouter un acteur imprévisible dans un système déjà difficile à suivre.
C'est la raison pour laquelle je déconseille de commencer par l'agent. Une remise au propre avant, et le projet d'agent devient beaucoup plus simple. L'inverse produit une démonstration réussie et une mise en production décevante.
Le coût, qui change la façon de décider
Un Flow est inclus dans vos licences. Une fois construit, il peut s'exécuter un million de fois sans que votre facture bouge.
Agentforce fonctionne autrement : il se facture à part, sur un modèle de consommation. Chaque échange traité consomme des crédits, ce qui rend le coût proportionnel à l'usage. Cette différence est structurante. Automatiser une tâche répétitive à très gros volume avec un agent alors qu'une règle suffisait revient à payer, chaque mois, pour une décision que vous connaissiez déjà.
Avant tout projet d'agent, la question à se poser n'est donc pas « est-ce que cela fonctionne ? », mais « combien de fois par mois, et pour quel gain ? ».
Par où commencer sans se tromper
Si le sujet vous intéresse, la progression la plus sûre tient en quatre étapes.
- Mettez de l'ordre d'abord. Données fiables, automatisations lisibles, droits maîtrisés. C'est le socle sur lequel un agent s'appuiera.
- Choisissez un cas où l'erreur est rattrapable. Un usage interne, avec relecture humaine, plutôt qu'un agent exposé aux clients dès le premier jour.
- Mesurez avant. Combien de demandes par mois, combien de temps chacune, traitées par qui. Sans ce point de départ, aucun gain ne sera démontrable ensuite.
- Testez en environnement de test. Comme pour le reste, et pour les mêmes raisons.
Et gardez en tête que l'essentiel des gains de productivité reste, aujourd'hui encore, dans des automatisations classiques bien conçues. Les orgs que j'ouvre contiennent presque toujours des tâches manuelles qu'un Flow d'une heure ferait disparaître. Commencer par là coûte moins cher et rapporte plus vite.
Questions fréquentes
Agentforce remplace-t-il les Flows ?
Non, et l'architecture le montre bien : un agent agit en déclenchant des actions, et ces actions sont très souvent des Flows. L'agent apporte la compréhension de la demande et le choix de la marche à suivre, le Flow apporte l'exécution fiable. Une org sans automatisations propres ne donne pas un bon agent.
Agentforce est-il inclus dans mon abonnement Salesforce ?
Non. Contrairement aux Flows, qui sont inclus dans les licences, Agentforce se facture à part, sur un modèle de consommation. Chaque échange traité par un agent consomme des crédits, ce qui rend le coût proportionnel à l'usage et impose d'estimer les volumes avant de se lancer.