J’ai vu cet article circuler et j’ai voulu proposer un petit décryptage technique pour expliquer pourquoi les agents LLM de Salesforce galèrent de façon si prévisible :
📎 https://www.theregister.com/2025/06/16/salesforce_llm_agents_benchmark/
D’abord et avant tout, Salesforce utilise un système RAG outillé qui traîne des problèmes d’architecture très spécifiques.
💠 Surcharge d’augmentation du system prompt
Les agents Salesforce sont forcés de raisonner à travers des system prompts massifs — rôles, sécurité, définitions d’outils, logique d’alignement — à chaque tour.
La plupart des modèles gèrent les system prompts longs, mais le system prompting consomme une bande passante de raisonnement prioritaire ; il doit être à la fois bien structuré et réduit au minimum, surtout avec les agents basés sur GPT.
Voyez le system prompting comme des maths. Vous disposez de X en bande passante de raisonnement pour chaque réponse, cumulée à toutes les autres réponses. Chaque morceau de complexité cyclomatique supplémentaire ajouté au system prompt, c’est autant de complexité cyclomatique en moins pour l’ingestion plus tard dans votre session ou votre processus.
(Petite parenthèse : quand je parle de "bande passante de raisonnement", je ne parle pas du nombre de tokens.
Je parle plutôt de la quantité de logique structurée que le modèle peut raisonner utilement par tour — le poids qu’il peut porter avant de commencer à perdre des morceaux. Les fenêtres de tokens sont larges. La bande passante est étroite.)
D’un point de vue modélisation, la bande passante de raisonnement agit comme une couche d’optimisation bornée à l’intérieur du manifold d’attention du transformer. Chaque tour est une traversée contrainte entre plusieurs tâches : résolution d’instructions, réconciliation de la mémoire, abstraction d’outils et planification de la sortie.
Vous ne contrôlez pas les poids internes — mais vous façonnez absolument la charge. Ajoutez de l’entropie, et la traversée échoue. Ajoutez de la clarté, et le système route proprement.
🪙 Oversaturation du contexte
L’une des raisons pour lesquelles on a envie d’utiliser un système comme Salesforce Agents, c’est leur connectivité. De base, ils sont branchés à vos systèmes métier, vos pipelines, tout votre bazar d’entreprise. Et on ne peut pas nier la valeur de la connexion à ces services. C’est précieux.
Le faire correctement, c’est obtenir une synthèse pertinente de documents, de données CRM et d’intégrations. Le faire mal, c’est avoir des agents saturés par des bassins massifs de données qui n’ont aucun rapport contextuel avec les tâches en cours, et que, encore une fois, chaque agent doit raisonner à chaque tour du processus.
La complexité cyclomatique, en d’autres termes... combien de décisions oui/non ou on/off peuvent être prises en un seul tour, c’est comme ça qu’on mesure ça. Les agents ne sont pas du code, et ne devraient pas être traités comme tel. Le code est conçu pour fournir des processus complexes et cyclomatiquement intenses. Les LLM sont conçus pour le tasking, l’exécution et le raisonnement probabiliste.
L’astuce, c’est de comprendre ce que le job implique et quel est l’outil approprié. Typiquement, un agent est à la fois du code et un processus LLM potentiellement long. Où l’un s’arrête et l’autre commence ? La ligne peut être floue, mais elle doit exister.
Tout balancer partout et d’un coup dans une fenêtre de contexte en espérant que ça passe, ce n’est pas comme ça qu’on y arrive.
🥵 Confusion des rôles
Bon, alors c’est quoi les rôles, exactement, et pourquoi c’est important ?
Les rôles font partie du protocole qu’on utilise. Il existe plusieurs standards pour ce protocole. Le plus courant est celui d’OpenAI, mais d’autres systèmes d’API comparables comme Ollama existent. Parfois, on utilise les deux (c’est rigolo !), ou aucun des deux. Ça dépend de votre projet.
Mais quel que soit le système qui sert de colle entre vous et votre machine, vos rôles définissent qui parle à qui, et ce qui est dit. Le contenu utilisateur aura un rôle « user », les outils sont marqués comme « tools », et on peut créer des rôles personnalisés pour donner aux utilisateurs, aux systèmes et aux LLM un contexte supplémentaire sur ce qui se passe, et comment.
En tant que développeur d’agents, vous comprenez, sur le principe, que les rôles sont sacrés. Vous étiquetez tout correctement, avec le bon rôle, à chaque fois. Vous segmentez vos tâches par rôles dédiés et vous marquez tout clairement, parce que vous savez que si vous ne le faites pas, la machine va halluciner de façon charmante, mais pas très utile.
Envie de voir un LLM s’imaginer être une application terminal qui crée des fichiers ?
Facile. Confondez votre rôle d’outil en assignant les sorties d’outils au rôle d’assistant.
Envie de voir votre LLM halluciner une autorité ? Faites la même chose avec des appels HTTP.
Ça vous dirait de regarder votre LLM perdre complètement le fil ? Augmentez simplement le prompt utilisateur avec des données de mémoire hors contexte provenant d’ailleurs dans la conversation, à chaque tour, d’une manière qui ne peut être suivie ni rationnellement ni déterministement — et appelez ça un système de mémoire !
Chaque rôle possède un poids de raisonnement, gratuit ou peu coûteux, qui influence les résultats obtenus à chaque tour.
Et ça nous amène aux systèmes RAG. Ça ne date pas de si longtemps, mais les systèmes RAG font vraiment sentir comme des reliques d’une autre époque. Une époque où l’appel d’outils n’existait pas et où il fallait bourrer le contexte. Quelle est la manière la plus sûre et évidemment risquée de bourrer de la mémoire dans un système LLM ? Ajouter ou « augmenter » le rôle utilisateur avec des données supplémentaires.
Les bases de données vectorielles ne sont pas problématiques en soi. Bien utilisées, elles sont incroyablement utiles — voire nécessaires pour les tâches quotidiennes. En fait, rien ne vous empêche d’utiliser correctement des systèmes de bases de données vectorielles.
Mais quand vous utilisez correctement les rôles d’outils et que vous interrogez ces mêmes bases de données vectorielles sans polluer votre prompt ni casser le fonctionnement de vos protocoles basés sur les rôles... ce n’est plus vraiment du RAG, si ?
À l’inverse, les agents Salesforce sont toujours bâtis sur une architecture RAG qui ajoute les données de contexte récupérées et d’autres informations directement dans le prompt utilisateur, sans structure, sans marquage et sans conscience contextuelle claire du rôle que ces données sont censées jouer. Comme je l’ai dit, un retour aux temps plus simples et aux systèmes moins performants.
C’est comme ça qu’on obtient des hallucinations. C’est comme ça qu’on a des faux pas, des performances dégradées et des agents incapables de tenir un fil cohérent d’un tour à l’autre.
Même si vous nettoyez le pipeline de récupération ou que vous affinez le modèle pour qu’il se comporte mieux dans ces conditions, vous travaillez toujours sur la même base foireuse, où les fondamentaux de la conception de tâches sont ignorés au profit de solutions si pragmatiques qu’elles n’ont plus aucun sens. La contamination du prompt devient une caractéristique même de l’architecture.
Le résultat est aussi prévisible que frustrant : des agents stupides. Une mémoire corrompue. Une bande passante de raisonnement épuisée. Et peut-être, occasionnellement, un manifeste artistique halluciné.
Alors, comment on règle le problème ?
Construisez quelque chose d’intentionnel
La première chose à faire est de comprendre comment fonctionnent le contexte et le raisonnement dans les systèmes LLM. Rappelez-vous que chaque morceau de contexte ajouté à la fenêtre de contexte est réexaminé de bout en bout, à chaque tour. Mais l’engagement chute à mesure que la bande passante de raisonnement s’épuise.
La bande passante du raisonnement, c’est différent de l’attention via le contexte des tokens, ce dont on parle d’habitude quand on évoque les fenêtres de contexte. Une fenêtre de contexte peut contenir dix billions de tokens avant de tronquer ou que l’attention ne flanche. Mais ça ne veut pas forcément dire que le modèle lui-même est capable de raisonner et d’ingérer tout le bloc de manière cohérente.
Les différences entre des systèmes comme Llama 4 Maverick et Gemini Pro 2.5 sont flagrantes pour précisément cette raison, même s’ils ont des limitations de fenêtre de contexte similaires.
En d’autres termes, la seule façon de voir Salesforce ici, c’est comme une mise en garde. Au lieu de répéter leurs erreurs... construisez quelque chose d’intentionnel.
Et par intentionnel, je veux dire :
🔹 Des entrées à faible bruit, où tout ce que l’agent voit a une raison d’être là.
🔹 Un étiquetage des rôles et de la mémoire qui rend le contexte lisible — tant pour les humains que pour les machines.
Règle d’or : si vous n’arrivez pas à suivre, alors que vous avez une puissance de raisonnement infiniment supérieure à n’importe quelle IA, la machine n’y arrivera probablement pas non plus.
🔹 Des sorties d’outils traitées comme des outils, pas comme du flou utilisateur.
🔹 Et surtout, arrêtez de supposer que votre modèle possède le « bon sens ».
Il faut dire à la machine ce que signifie « bien ».