Les fondations ennuyeuses de Salesforce (et c’est un compliment)

La plateforme sous-jacente à l’agent est plus importante que l’agent lui-même.

Quatrième partie de la série « L’entreprise accidentelle de l’agent ». [Commencez par le premier volet ici.]

Auteur: John Pettifor

Personne ne s’enthousiasme pour les métadonnées.

Personne n’est jamais sorti d’une conférence enthousiasmé par la sécurité au niveau des champs ou les politiques de conservation des journaux d’audit. Aucun post LinkedIn n’est devenu viral grâce à un ensemble d’autorisations bien implémenté. À chaque événement IA auquel j’assiste, l’attention se porte sur les démonstrations : l’agent qui écrit le code, le copilote qui rédige l’e-mail, le modèle qui résout un problème.

Mais voici ce qui me revient sans cesse à l’esprit alors que nous développons Delivery Intelligence : la décision technologique la plus importante de notre stratégie IA ne concerne pas le modèle utilisé. Ni les agents créés. C’est la plateforme sur laquelle ils s’exécutent. Et si cette plateforme fonctionne, ce n’est pas grâce à des effets spectaculaires. Salesforce est, par essence, un logiciel d’entreprise d’une simplicité élégante.

Je le dis comme un compliment des plus élogieux.

Une confession sur l’apocalypse SaaS

Je dois être honnête. Nous n’avons pas choisi Salesforce pour notre stratégie d’IA. Nous sommes partenaires Salesforce. Salesforce fait partie de notre activité. Lorsque nous avons entrepris de développer Delivery Intelligence, la question n’a jamais été « sur quelle plateforme devons-nous nous baser ?» mais plutôt « la plateforme que nous utilisons déjà peut-elle répondre à nos besoins ?»

Pendant environ six mois, je n’étais pas certain que la réponse soit positive.

Fin 2024, début 2025, j’étais sincèrement inquiet quant à la capacité de Salesforce à rester compétitif dans le domaine de l’IA. Le discours alarmiste sur la fin du SaaS était omniprésent : si l’IA peut générer des applications complètes et que les agents peuvent automatiser les flux de travail de bout en bout, à quoi bon une plateforme SaaS structurée ? Pourquoi payer pour Salesforce quand on peut tout simplement développer sa propre solution ?

J’ai entendu cet argument de la part de personnes brillantes. Je l’ai sérieusement envisagé. Et je pense maintenant qu’il est presque entièrement erroné.

Après des mois de développement d’une IA agentielle sur Salesforce, je pense que la « SaaSpocalypse » se méprend sur le potentiel de ces plateformes. Certes, leur utilisation va radicalement changer. Les interfaces évolueront. Les flux de travail seront repensés. Mais les modèles de données structurés, les cadres d’autorisation, l’infrastructure d’audit et des décennies de logique métier spécifique au domaine ? C’est ce noyau qui rend l’IA possible en entreprise. Il ne s’agit pas d’une concurrence avec l’IA, mais du socle dont elle a besoin.

Je suis aujourd’hui plus optimiste quant à l’avenir de Salesforce qu’avant le début de notre développement.

La plateforme Salesforce « ennuyeuse », et pourquoi nous l’adorons tant

Quand je dis « ennuyeux », je parle de caractéristiques de Salesforce qui existent depuis des années. Il ne s’agit pas de nouvelles fonctionnalités d’IA, mais de choix architecturaux fondamentaux, faits bien avant que l’on parle d’agents.

1. Basé sur les métadonnées

Chaque objet, champ et relation est décrit par des métadonnées que la plateforme comprend nativement. Inutile d’expliquer à un agent ce qu’est un contact ou comment les opportunités sont liées aux comptes. La plateforme le sait depuis vingt ans.

2. Gouvernance des permissions

Hiérarchies de rôles, profils, ensembles de permissions, sécurité au niveau des champs, paramètres par défaut à l’échelle de l’organisation, règles de partage : un système extrêmement performant pour contrôler qui voit quoi et qui fait quoi. Ce n’est pas un ajout superficiel, c’est intégré à chaque décision d’accès aux données.

3. Audit natif

Qui a modifié quoi, quand, de quelle valeur à quelle valeur ? Journal d’audit des modifications de configuration. Historique des connexions. Surveillance des événements pour les éditions Entreprise. Les reçus sont générés par défaut.

4. Schéma appliqué

On ne peut pas simplement importer un objet JSON dans Salesforce et espérer que tout se passe bien. Les données sont typées, soumises à des règles de validation, comportent des champs obligatoires et des relations garantissant l’intégrité référentielle.

Rien de tout cela ne se reflète sur les réseaux sociaux. C’est pourtant ce qui rend l’IA agentique fiable à grande échelle.

La gouvernance de la plateforme devrait être votre première question concernant l’IA.

Beaucoup d’entreprises commettent actuellement une erreur fondamentale concernant l’IA : elles concentrent tous leurs efforts d’évaluation sur l’agent et presque aucun sur la plateforme dans laquelle il opère.

Les questions que j’entends le plus souvent : Quel modèle choisir ? Quel est le meilleur framework d’agent ? Faut-il opter pour Copilot ou Agentforce ? Ce ne sont pas de mauvaises questions en soi, mais ce ne sont pas les bonnes premières questions à se poser.

Les premières questions devraient être :

• Quand cet agent lit et écrit des données dans nos systèmes d’information, qu’est-ce qui régit cet accès ?
• Qu’est-ce qui l’empêche d’accéder à des enregistrements auxquels il ne devrait pas avoir accès ?
• Qu’est-ce qui consigne ses décisions ?
• Qu’est-ce qui garantit que les données qu’il lit sont structurées, propres et contextuellement exactes ?

Si vous n’avez pas de réponses à ces questions, le modèle importe peu. Vous avez construit un agent performant sur des fondations non fiables.

En pratique, la gouvernance opère directement au sein de l’intelligence de la prestation.

Je vais concrétiser cela avec ce que nous avons construit.

Prenons un exemple concret : nos agents Delivery Intelligence exploitent de multiples sources de données : Salesforce CRM pour les données de pipeline et clients, Certinia PSA pour les données financières des projets et la gestion des ressources, Azure DevOps pour le code et les éléments de travail, et SharePoint pour les connaissances relatives aux livraisons. Chacune de ces connexions transite par des serveurs MCP (présentés dans l’article 3) et est orchestrée par MuleSoft Agent Fabric.

Mais la gouvernance ne réside pas uniquement dans la couche d’orchestration. Elle réside au sein même de Salesforce.

Lors de la réalisation d’un projet Salesforce, les données de nos clients sont intégrées à notre environnement : leurs exigences, leurs processus métier, leurs spécifications techniques, leurs échéanciers et leurs budgets. Ces données alimentent nos agents d’intelligence de livraison. L’agent d’analyse des exigences les examine, l’agent de planification des ateliers les structure et les outils d’estimation s’y réfèrent. Les informations confidentielles de nos clients sont partagées avec nous et exploitées par des agents d’IA qui nous permettent de réaliser leurs projets plus rapidement et plus efficacement.

Cette relation de confiance ne fonctionne que grâce à ce qui se cache en dessous.

Lorsque notre agent de gestion des exigences génère les exigences fonctionnelles d’un projet client, voici comment cela fonctionne : l’agent accède aux données du projet via le serveur Certinia MCP, mais uniquement aux projets auxquels l’utilisateur demandeur a accès. Il consulte les connaissances relatives à la livraison dans SharePoint, mais seulement les collections de connaissances approuvées et organisées pour son utilisation. Il enregistre les résultats dans un entrepôt de données structuré dans Salesforce, où ces résultats héritent du modèle de partage du projet parent. Chaque action est consignée. Chaque accès aux données est régi par le même modèle d’autorisations que celui appliqué aux utilisateurs humains.

Nous n’avons pas créé cette gouvernance. Nous l’avons héritée. Elle était déjà en place car Salesforce applique ces pratiques depuis des années. Lorsqu’un client nous demande comment ses données sont protégées dans notre processus de livraison optimisé par l’IA, la réponse n’est pas « nous avons créé une couche de sécurité personnalisée ». La réponse est « vos données sont régies par le même modèle d’autorisations, le même cadre d’audit et les mêmes contrôles d’accès Salesforce auxquels les entreprises font confiance depuis vingt ans ».

Comparez cela aux agents construits sur des données non structurées avec des outils improvisés : un LLM pointant vers un partage de fichiers ou un lac de données aux autorisations incohérentes. L’agent lit tout ce à quoi il peut accéder.

• Aucune métadonnée pour signaler les données sensibles.
• Aucun modèle d’autorisations associé aux rôles métiers.
• Aucun cadre structuré pour la journalisation des actions de l’IA.
• Aucune validation de schéma pour détecter les résultats erronés avant leur propagation.

Ce n’est pas un risque théorique.

Le cauchemar du codage vibratoire (une vraie conversation)

Dans le premier article de cette série, j’ai écrit une phrase qui a suscité plus de réactions que presque tout le reste : l’idée que quelqu’un puisse développer un système de gestion financière concurrent de Certinia en programmant de manière intuitive nous donne des cauchemars.

Je souhaite développer ce point à travers une conversation récente.

Je discutais avec le PDG d’une entreprise spécialisée dans la formation et la certification propriétaires. Leur produit ? Le savoir-faire accumulé par leurs experts au fil des décennies, intégré dans des cours et des certifications payants pour les professionnels. Son entreprise venait de participer à une formation intensive en intelligence artificielle, et les participants sont revenus avec ce conseil : « Vous pouvez maintenant développer un LMS en programmant de manière intuitive. Cela ne prendrait que quelques mois, et il suffirait ensuite de s’en occuper.»

À première vue, cela semble raisonnable. Le développement assisté par l’IA est puissant. On pourrait créer la structure de l’application, concevoir l’interface utilisateur, connecter la base de données et obtenir un LMS fonctionnel en quelques mois.

Ce conseil ne tient pas compte de l’ensemble de la situation.

Il faudrait de la vision et de la créativité pour concevoir un logiciel véritablement performant, et non pas simplement fonctionnel. Il faudrait le mettre à jour en permanence : évolutions des navigateurs, correctifs de sécurité, normes d’accessibilité, plateformes mobiles, exigences de certification. Il faudrait également gérer les paiements, la vérification des identifiants, les rapports, le suivi de la conformité, l’authentification et la diffusion de contenu à grande échelle.

Et le problème fondamental : le produit de cette entreprise n’est pas un logiciel. Il s’agit de sa propriété intellectuelle en matière de formation et de certification. Le savoir-faire de ses experts. La crédibilité de ses certifications sur le marché. Chaque heure consacrée à la maintenance d’un LMS personnalisé est une heure de moins investie dans ce qui génère réellement des revenus.

Pour une entreprise dont le produit est un logiciel, le développement intuitif est un véritable atout. Pour toutes les autres, utiliser une plateforme mature, abordable, sécurisée et évolutive pour diffuser leur produit est presque toujours plus judicieux. La plateforme gère l’infrastructure complexe, leur permettant ainsi de se concentrer sur la différenciation.

Ce même raisonnement s’applique à l’échelle de l’entreprise. Certinia existe car la gestion financière à grande échelle exige des années d’expertise métier, la conformité réglementaire, le respect des exigences d’audit, la prise en charge de plusieurs devises, les règles de comptabilisation des revenus et l’expérience acquise au fil de milliers de déploiements en entreprise. Ce savoir-faire est intégré à la plateforme. On ne peut pas se contenter de coder intuitivement pour se conformer à la norme ASC 606. MuleSoft existe car la gouvernance de l’intégration est un véritable défi. Salesforce et Agentforce existent car la gestion de la relation client (CRM) à l’échelle de l’entreprise nécessite des modèles de données structurés, des cadres d’autorisation et des moteurs de workflow perfectionnés depuis plus de vingt ans.

Nos agents ne se contentent pas de reproduire ce que Salesforce et Certinia font déjà très bien. Ils rendent ces plateformes intelligentes en y intégrant l’IA.

Faire évoluer votre profil de risque en IA

On passe désormais d’une discussion technique à une discussion axée sur les enjeux commerciaux.

Lorsque vous développez des agents sur une plateforme structurée et gouvernée, leur profil de risque est fondamentalement modifié. Votre RSSI n’a pas besoin d’évaluer un nouveau modèle de sécurité, car l’agent hérite du modèle déjà approuvé. L’équipe de conformité n’a pas besoin de concevoir de nouveaux processus d’audit, car les actions de l’agent sont consignées dans le même cadre d’audit qu’elle utilise déjà. Votre équipe de gouvernance des données n’a pas besoin de créer de nouveaux contrôles d’accès, car l’agent respecte les mêmes limites d’autorisation que les utilisateurs humains.

C’est pourquoi nous pouvons avancer à ce rythme. Notre rythme de publication bimensuel n’est pas possible en négligeant la gouvernance. Il est possible parce que nous ne créons pas une gouvernance de A à Z pour chaque nouvelle fonctionnalité. Chaque nouvel agent que nous ajoutons hérite de la couche de confiance complète de la plateforme Salesforce.

Pour nos clients, cela a un double impact. Premièrement, chaque projet sur lequel ils nous font appel bénéficie d’un processus de livraison optimisé par l’IA, où leurs données sont gérées par une infrastructure de niveau entreprise, et non par des outils disparates. Deuxièmement, lorsque ces mêmes clients sont prêts à développer leurs propres agents sur Salesforce, les mêmes avantages fondamentaux s’appliquent. Le cadre de gouvernance déjà en place (autorisations, journaux d’audit, modèles de données structurés) devient la couche de confiance pour leurs agents. Ils n’ont pas à partir de zéro : les bases sont déjà là.

Imaginez faire la même chose avec des agents construits sur une base de données vectorielle autonome et une connexion API directe à un LLM. Vous passerez plus de temps à construire la couche de gouvernance qu’à développer l’agent.

Vous devez savoir ceci si vous évaluez une stratégie d’IA

Si vous êtes un dirigeant d’entreprise et que vous évaluez où investir dans l’IA agentique, voici une analyse objective :

Le modèle va changer. Les frameworks d’agents vont évoluer. Les fonctionnalités vont s’améliorer. Tout cela est en constante évolution et le restera pendant des années. Choisir le « bon » modèle aujourd’hui est un pari qui devra être réévalué.

En revanche, la plateforme sous-jacente est un choix durable. Si vos données structurées, vos permissions, vos capacités d’audit et votre cadre de gouvernance sont déjà matures, alors chaque fonctionnalité d’IA que vous ajoutez bénéficie de cette base solide. Dans le cas contraire, chaque fonctionnalité d’IA ajoutée représente un nouveau problème de gouvernance à résoudre de zéro.

Salesforce n’est pas la seule plateforme présentant ces caractéristiques. Mais c’est celle que nous connaissons parfaitement et celle pour laquelle nous avons prouvé que sa base est suffisamment robuste pour supporter ce que nous développons. Vingt ans de métadonnées, de permissions et de données structurées ne semblaient pas passionnants lors de leur création. Aujourd’hui, c’est grâce à elles que nous pouvons déployer l’IA agentique en toute confiance.

Les tâches ennuyeuses étaient toujours les plus difficiles. Il a simplement fallu l’IA pour que cela devienne évident.

Qu’est-ce qui a changé ?

Il y a six mois, j’étais sincèrement inquiet quant à l’avenir de Salesforce, en tant que plateforme, dans un monde dominé par l’IA. Son développement quotidien a complètement changé la donne. Le discours alarmiste sur la « SaaSpocalypse » se trompe totalement sur la nature de la menace. L’IA ne rend pas ces plateformes obsolètes. Elle valorise plus que jamais la gouvernance, la structure et l’expertise métier qu’elles ont accumulées au fil des décennies. Les entreprises qui auront des difficultés ne sont pas celles qui proposent des solutions SaaS d’entreprise, mais celles qui tentent de développer l’IA sans elle.

Et ensuite ?

Le cinquième article aborde un sujet que la plupart des entreprises négligent encore : l’efficacité. Il ne s’agit pas seulement de savoir si l’agent fonctionne, mais aussi de déterminer la puissance de calcul, le nombre de jetons et l’énergie nécessaires pour obtenir la réponse. Les choix architecturaux qui optimisent les agents ne sont pas toujours évidents, et la différence entre une requête bien ciblée et une requête bâclée est considérable. Nous partagerons des chiffres concrets issus de notre propre développement.

---

Où en sommes-nous ?

Delivery Intelligence est opérationnel et bénéficie de mises à jour toutes les deux semaines. Les agents de planification d’atelier et d’exigences sont en production sur des projets actifs. L’agent de compilation est en cours de développement. La suite Delivery Intelligence complète devrait être finalisée d’ici l’été 2026. Envie de la voir en action ? Contactez notre équipe.

---

Diabsolut est un partenaire de conseil Salesforce qui développe l’entreprise multi-agents en toute transparence. Suivez cette série pour découvrir nos réussites, nos enseignements et nos prochaines innovations.

---

Pour en savoir plus, consultez notre série sur l’entreprise agentique :

• Partie 1 : Diabsolut : L’entreprise agentique accidentelle
• Partie 2 : Ce ne sont pas les agents qui mènent la danse, mais les gens
• Partie 3 : Solution déployée en une semaine : c’est maintenant possible, et voici comment
• Partie 4 : S’appuyant sur les fondations ennuyeuses de Salesforce (et c’est un compliment)