You are currently viewing Pourquoi les projets Salesforce deviennent plus risqués avec l’IA

Pourquoi les projets Salesforce deviennent plus risqués avec l’IA

En 2026, on ne se demande plus si Salesforce va intégrer l’IA. La question est devenue : comment cette IA est-elle en train de fragiliser les projets, sans que personne ne s’en rende compte avant le premier incident en production ?

Depuis le lancement d’Agentforce Vibes 2.0 et de Headless 360 à TDX 2026, on voit arriver dans nos audits une nouvelle catégorie de problèmes. Pas des bugs spectaculaires. Pas des plantages bruyants. Des erreurs silencieuses, des automatisations qui se contredisent, des flows générés par IA qui passent les sandboxes et explosent à la première charge réelle.

Cet article s’adresse aux DSI, directeurs CRM et architectes qui sentent que quelque chose change dans la manière dont leur org Salesforce évolue — sans toujours réussir à mettre des mots dessus.

Le « vibe coding » sur Salesforce, ce n’est pas un buzzword

Le vibe coding, c’est l’idée qu’un développeur — ou un admin — décrit en langage naturel ce qu’il veut, et l’IA génère le code Apex, le flow, le déclencheur. Avec Agentforce Vibes, intégré directement dans VS Code et la CLI Salesforce, n’importe qui peut désormais produire un objet métier complet en quelques minutes.

Sur le papier, c’est génial. En production, c’est devenu notre principal sujet d’inquiétude. Paul Battisson, MVP Salesforce et fondateur de Groundwork Apps, le résume dans un édito Salesforce Ben de janvier 2026 : « Si vous pouvez construire plus vite, ça ne veut pas dire que vous construisez mieux. Ça veut juste dire que vous construisez plus, plus vite. »

Et c’est exactement ce qu’on observe sur le terrain.

Quatre symptômes que votre org est en train d’accumuler une dette IA

1. Des flows redondants qui s’ignorent

L’IA ne lit pas l’historique. Quand un admin lui demande « crée un flow qui envoie une notification quand un compte change de statut », elle crée un flow. Même si trois autres existent déjà. Et ces flows ne se parlent pas, parfois se contredisent. On a audité récemment une org où quatre automatisations différentes mettaient à jour le même champ. Le résultat dépendait de l’ordre d’exécution. Personne ne le savait.

2. Du code Apex qui passe les tests mais ignore le contexte métier

Un trigger généré par IA passera ses tests unitaires. Il respectera les patterns Salesforce. Mais il ignorera la règle métier que vous avez mis trois mois à faire valider par la direction commerciale en 2023. Cette règle vit dans un wiki Confluence, dans un Slack, dans la tête d’un ex-collaborateur. Pas dans le prompt.

3. Une explosion silencieuse des objets personnalisés

L’équipe Gearset l’explique très bien dans leur analyse de la gouvernance Agentforce Vibes : « Vos process de delivery n’ont pas été conçus pour absorber autant de changements. Vos revues, vos standards qualité, vos contrôles de gouvernance ont été pensés pour des changements humains, délibérés. Quand un agent IA produit et déploie un trigger Apex dans le temps qu’il fallait avant pour ouvrir un fichier, ces garde-fous prennent du retard. »

4. Une org qui devient illisible

C’est le point qui fait le plus mal. À force de générer, on perd la trace de pourquoi un objet existe, pourquoi un champ a été ajouté, pourquoi telle automatisation a été désactivée puis réactivée. La documentation IA est plausible mais souvent inventée. Six mois plus tard, plus personne ne sait débugger l’ensemble. Ce que l’éditorial Salesforce Ben résumait dans « Why Salesforce Professionals Are Feeling Lost in 2026 » par cette phrase devenue virale : « It’s never been cheaper to get something built. But it’s never been harder to build the right thing. »

Pourquoi c’est pire sur Salesforce que sur un projet « classique »

Salesforce a trois spécificités qui amplifient le risque IA :

  • L’org est partagée. Contrairement à un repo Git classique, votre org Salesforce héberge la production de toutes les équipes simultanément. Ventes, marketing, support, finance. Une régression introduite par un flow IA touche immédiatement tous les utilisateurs.
  • Le déploiement est continu. Pas de release toutes les deux semaines. Les changements partent en production au fil de l’eau, parfois validés en quelques heures.
  • L’historique est faible. Sans setup DevOps rigoureux (Gearset, Copado, Flosum), il est très difficile de revenir en arrière sur un changement précis.

Combinez ces trois facteurs avec une IA qui produit dix fois plus de changements à la minute, et vous obtenez un cocktail à risque maximal — surtout si votre gouvernance n’a pas suivi le rythme.

Ce qui distingue les orgs qui s’en sortent

Sur la trentaine d’audits Salesforce qu’on a réalisés ces six derniers mois, voici ce qui distingue celles qui tirent profit de l’IA de celles qui se font dépasser :

Une architecture documentée AVANT d’autoriser le vibe coding

Les orgs résilientes ont une cartographie claire : quels objets servent à quoi, quelles automatisations sont prioritaires, quels champs sont source de vérité. Sans cette base, l’IA produit du chaos plausible.

Une revue humaine systématique des changements IA

Pas une revue rapide. Une revue qui pose les questions « est-ce que ça doit exister ? » et « est-ce que ça respecte la règle métier qu’on a posée il y a deux ans ? ». C’est plus lent. C’est ce qui fait la différence.

Un découpage par domaine de responsabilité

L’IA peut intervenir librement sur certains périmètres (notifications internes, scripts de migration, tests). Elle est strictement encadrée sur d’autres (logique de pricing, gestion des accès, intégrations financières). Cette séparation, c’est de la gouvernance, pas de la technique.

Un health check trimestriel

L’org dérive plus vite avec l’IA. Ce qui était propre il y a six mois ne l’est plus. Le rythme d’audit doit s’aligner sur le rythme de changement, pas sur l’agenda comptable.

Le rôle de l’intégrateur en 2026

Chez Cloud Girafe, on a changé notre manière de travailler. Avant, 60 % du temps d’un projet allait à la construction. Aujourd’hui, c’est 30 %. Le reste va à la structuration : poser les bonnes questions avant de coder, définir ce qui doit être construit, ce qui ne doit pas, ce qui doit être documenté, ce qui doit être revu.

Ce changement n’est pas une mode. Il est structurel. L’IA fait gagner du temps sur l’exécution ; elle en coûte sur la gouvernance. Et le ratio s’inverse de plus en plus vite.

Pour aller plus loin, vous pouvez consulter notre livre blanc DevOps Salesforce (gratuit) ou notre checklist Health Check Premium en 30 points. Si vous voulez aller plus vite, on propose un audit Salesforce express en 5 jours qui identifie les risques de gouvernance IA dans votre org.

Et si le bon profil n’était plus le bon développeur, mais le bon partenaire ?

On observe que de plus en plus de DSI ne cherchent plus seulement « un développeur Salesforce » mais quelqu’un capable de poser un cadre. Ce sujet, on l’a creusé avec nos amis de SF Talent, qui constatent la même chose côté recrutement : les profils opérationnels seniors deviennent introuvables, alors que les juniors se multiplient. C’est tout le marché Salesforce qui est en train de se reconfigurer.

Le vrai risque IA sur Salesforce, ce n’est pas l’IA. C’est l’absence de structure pour l’absorber. Et la structuration, c’est précisément ce qui ne se génère pas par prompt.

Laisser un commentaire