Agentforce Vibes : comment intégrer le développement agentique dans un environnement Salesforce

L’intelligence artificielle est déjà utilisée pour écrire du code, générer des tests ou expliquer des erreurs. Dans un environnement Salesforce, la difficulté se situe toutefois rarement dans la syntaxe seule. Il faut comprendre les objets, les champs, les automatisations, les permissions et les dépendances propres à chaque organisation.

Agentforce Vibes cherche à répondre à cette limite en intégrant l’IA directement dans le contexte du projet Salesforce. L’outil ne se contente pas de proposer quelques lignes de code. Il peut analyser une demande, préparer un plan, modifier plusieurs fichiers, exécuter des outils de développement et accompagner les différentes étapes jusqu’aux tests et au déploiement.

Pour une entreprise, l’enjeu consiste aujourd’hui à accélérer le développement sans fragiliser l’architecture, la sécurité ou la maintenabilité de l’organisation Salesforce. 

Un outil qui travaille avec le contexte réel de Salesforce

Un assistant de code généraliste connaît Apex, JavaScript ou les Lightning Web Components. Il ne connaît en revanche pas nécessairement les noms réels des objets, les champs personnalisés, les permission sets ou les conventions techniques de l’entreprise.

Agentforce Vibes peut exploiter le projet local et les métadonnées de l’organisation Salesforce connectée. Il peut ainsi identifier les objets, les relations, les profils, les record types ou les composants déjà présents avant de proposer une modification. Cette connaissance réduit le risque de générer un code techniquement plausible, mais incompatible avec l’environnement réel.

Cette capacité est particulièrement utile pour les projets qui traversent plusieurs couches de Salesforce. Une nouvelle fonctionnalité peut, par exemple, nécessiter un objet personnalisé, une classe Apex, un composant LWC, un Flow, un permission set et plusieurs classes de test. Agentforce Vibes peut coordonner ces éléments comme un ensemble plutôt que de les traiter séparément.

L’outil reste toutefois dépendant des informations qui lui sont accessibles. Une règle métier non documentée, un contrat d’API externe ou une différence entre la sandbox et la production doit toujours être expliqué explicitement par l’équipe projet.

Du prompt à un plan d’exécution contrôlé

Agentforce Vibes propose un mode de planification destiné aux travaux complexes. À partir d’une demande formulée en langage naturel, l’outil analyse le projet, identifie les dépendances et produit un plan structuré comprenant les objectifs, l’approche et les différentes tâches à réaliser.

Aucun fichier n’est modifié avant la validation du plan. Une fois celui-ci approuvé, l’agent peut exécuter les étapes prévues et créer un point de sauvegarde permettant de revenir à l’état précédent du projet.

Prenons le cas d’une entreprise souhaitant remplacer un ancien composant Visualforce par un Lightning Web Component. L’outil peut commencer par analyser le composant existant, repérer les classes Apex associées, proposer une nouvelle architecture, préparer les tests et organiser la migration.

La valeur ne réside donc pas uniquement dans la génération du code. Elle se trouve également dans la décomposition du besoin et dans la visibilité donnée au développeur avant l’exécution.

Cette approche exige malgré tout une validation humaine. Salesforce indique clairement que l’agent peut produire de mauvaises hypothèses, inventer une méthode ou générer un code qui compile sans répondre exactement au besoin métier. La revue technique reste indispensable.

Le rôle du serveur MCP dans l’environnement de développement

Agentforce Vibes s’appuie sur le Model Context Protocol, ou MCP, pour connecter l’agent aux outils dont il a besoin. Le serveur Salesforce DX MCP lui permet notamment d’accéder à des fonctions liées aux métadonnées, aux tests, à l’analyse du code et au déploiement.

L’agent peut découvrir les outils disponibles, sélectionner ceux qui correspondent à la demande, les exécuter dans le bon ordre puis exploiter leurs résultats. Des serveurs MCP externes, comme GitHub ou Figma, peuvent également être ajoutés lorsqu’ils sont utiles au projet.

Cette ouverture apporte de la souplesse, mais elle augmente aussi le nombre d’éléments à gouverner. Chaque serveur doit être configuré, authentifié et limité aux usages réellement nécessaires. Certains serveurs hébergés doivent par ailleurs être activés par un administrateur Salesforce avant de pouvoir être utilisés.

Ajouter le plus grand nombre possible d’outils n’est donc pas toujours pertinent. Une configuration plus restreinte réduit les risques d’erreur, simplifie les validations et facilite la compréhension des actions réalisées par l’agent.

Des règles pour industrialiser les bonnes pratiques

Pour obtenir des résultats cohérents, les entreprises doivent transmettre à l’outil leurs propres standards de développement.

Les Rules permettent d’imposer des contraintes permanentes, comme les conventions de nommage, les exigences de sécurité ou les règles de bulkification Apex. Les Skills apportent des instructions plus spécialisées qui sont activées lorsqu’une tâche correspond à leur domaine, par exemple la génération d’un trigger, d’un Flow ou d’un permission set.

Ces éléments peuvent être conservés dans le projet et versionnés avec le reste du code. L’expertise n’est alors plus uniquement stockée dans les habitudes individuelles des développeurs. Elle devient un cadre réutilisable par toute l’équipe.

La qualité de ce cadre est déterminante. Des instructions incomplètes ou contradictoires peuvent conduire l’agent à appliquer de mauvaises conventions de manière systématique.

La sécurité ne repose pas uniquement sur la technologie

Agentforce Vibes est intégré à la couche de confiance Salesforce, destinée à protéger le code, le schéma et les métadonnées utilisés comme contexte. L’outil propose également des mécanismes d’autorisation permettant de demander une validation avant l’exécution de certaines actions ou d’autoriser automatiquement des outils précis.

Ces protections ne remplacent pas une gouvernance de projet. L’entreprise doit encore définir les environnements accessibles, les personnes autorisées, les actions pouvant être automatisées et les étapes nécessitant une approbation.

Les développements sensibles, notamment ceux concernant l’authentification, le chiffrement, les données personnelles ou les règles de partage, doivent faire l’objet d’une revue ligne par ligne. Le code généré doit suivre le même processus de contrôle, de tests et de validation qu’un développement réalisé manuellement.

Comment lancer un premier projet Agentforce Vibes

Un déploiement progressif est préférable à une généralisation immédiate.

1. Le premier pilote peut porter sur un périmètre maîtrisé : création d’un composant interne, génération de tests, documentation d’un code existant ou refactorisation d’une fonctionnalité non critique. La sandbox, le projet Salesforce DX et les métadonnées utiles doivent être préparés avant de lancer les premiers prompts.
2. Il faut ensuite définir les Rules et Skills, configurer les serveurs MCP nécessaires et conserver des permissions restrictives au début. Les résultats peuvent enfin être évalués selon des critères concrets : qualité du code, respect des conventions, couverture des tests, temps de revue et nombre de corrections humaines.

L’accompagnement d’un tiers devient particulièrement utile lorsque l’organisation Salesforce est ancienne, peu documentée ou fortement personnalisée. Le travail ne consiste alors pas seulement à installer une extension, mais à identifier les bons cas d’usage, structurer les garde-fous et intégrer l’outil dans les pratiques de développement existantes.

Chez SIWAY, nous accompagnons les entreprises dans la mise en place de ces approches au sein de leur écosystème digital, depuis le cadrage des usages jusqu’à leur intégration dans les projets Salesforce.