Une organisation Salesforce en production depuis huit ans a rarement été construite d'un seul tenant. Elle empile des couches successives : Workflow Rules puis Process Builder puis Flows, triggers Apex écrits par des prestataires différents, champs créés pour un projet abandonné, permissions accordées « en urgence ». Cette accumulation forme une dette technique. Vouloir y greffer de l'IA — Einstein, Agentforce, ou un modèle branché via API — sans diagnostic préalable revient à construire sur des fondations que personne ne connaît plus. Cet article propose une méthode de diagnostic pragmatique, pensée pour les ETI qui veulent moderniser sans casser l'existant.

Pourquoi l'IA rend le diagnostic non négociable

L'IA appliquée au CRM ne fait pas de magie sur des données incohérentes. Un modèle de scoring, un résumé automatique d'opportunité ou un agent conversationnel s'appuient sur les mêmes objets, champs et règles que le reste de l'org. Si un champ « statut client » contient quinze valeurs dont six obsolètes, l'IA apprendra ce désordre et le restituera. La qualité de sortie est plafonnée par la qualité de l'entrée.

Une org ancienne pose trois problèmes spécifiques face à l'IA :

  • des données historiques hétérogènes, saisies selon des règles qui ont changé plusieurs fois ;
  • des automatisations empilées dont on ignore l'effet combiné sur un enregistrement ;
  • des limites de plateforme (governor limits, quotas d'API) déjà proches de la saturation, que l'IA va solliciter davantage.

Le diagnostic sert donc à deux choses : mesurer l'état réel de l'org et identifier ce qui doit être assaini avant, non pendant, le projet IA.

Les quatre couches à auditer

1. Les données et le modèle

Commencez par cartographier les objets réellement utilisés. Combien de champs personnalisés existent, et combien sont renseignés sur plus de 20 % des enregistrements ? Salesforce fournit des rapports d'usage des champs et des outils comme le Field Trip ou l'Optimizer intégré permettent de repérer les champs morts. Documentez les règles de validation, les doublons et les valeurs de listes de sélection incohérentes.

Ce travail conditionne directement la faisabilité d'un cas d'usage IA. Un scoring de leads suppose un historique fiable de conversions ; si le champ de qualification a été rempli au doigt mouillé pendant cinq ans, le modèle sera inexploitable.

2. Les automatisations

C'est souvent la strate la plus dangereuse. Une org de 8 ans peut contenir des Workflow Rules, des Process Builder et des Flows qui agissent sur le même objet, dans un ordre difficile à prévoir. Salesforce a d'ailleurs annoncé la fin de la création de nouveaux Workflow Rules et Process Builder au profit de Flow : une org ancienne se trouve donc face à une migration à planifier.

Recensez chaque automatisation, son déclencheur, sa cible et son statut actif/inactif. Identifiez les redondances et les boucles potentielles. Cet inventaire évite qu'un agent IA déclenche en cascade des mises à jour non maîtrisées.

3. Le code Apex et les intégrations

Mesurez la couverture de tests réelle, l'âge des classes, les appels externes et les dépendances vers des packages managés (AppExchange) qui ne sont plus maintenus. Une intégration IA passe fréquemment par des appels API ou des Platform Events : il faut connaître les limites déjà consommées.

4. La sécurité et les accès

Profils, permission sets, partages : une org ancienne accumule des droits accordés au fil des départs et arrivées. Avant d'exposer des données à un moteur d'IA ou à un agent, il faut savoir qui voit quoi. C'est un enjeu de conformité au RGPD autant que de sécurité.

8 ans
âge où l'empilement Workflow/Process/Flow devient critique
3
générations d'outils d'automatisation à réconcilier
4
couches à auditer avant tout projet IA

Une méthode de diagnostic en trois temps

Un diagnostic utile n'est pas un audit exhaustif de 200 pages que personne ne lira. Il vise une photographie actionnable.

  • Inventaire outillé. Utilisez Salesforce Optimizer, les rapports d'usage natifs et des outils d'analyse statique pour objectiver l'état. Les données remontées sont factuelles, pas des impressions.
  • Priorisation par risque et par cas d'usage IA. Croisez la dette identifiée avec le projet visé. Inutile d'assainir un pan de l'org qui n'a aucun lien avec le cas d'usage.
  • Feuille de route d'assainissement. Séquencez les corrections : ce qui bloque le projet IA, ce qui le fragilise, ce qui peut attendre.

Méfiez-vous des projets IA vendus « clé en main » sur une org non auditée. Si le prestataire ne demande pas à voir l'état de vos automatisations et de vos données avant de chiffrer, le budget de remédiation apparaîtra en cours de route — au plus mauvais moment.

Ce que le diagnostic doit produire

À l'issue de l'exercice, une ETI devrait disposer de trois livrables concrets :

  • une cartographie des objets, champs actifs et automatisations réellement en vigueur ;
  • une évaluation des données du point de vue du cas d'usage IA visé (complétude, cohérence, historique exploitable) ;
  • un plan d'assainissement chiffré et séquencé, distinguant le prérequis du projet IA des chantiers de fond.

Ce triptyque permet de décider en connaissance de cause : lancer l'IA maintenant, la reporter après un assainissement ciblé, ou traiter les deux en parallèle sur des périmètres disjoints.

Faire réaliser le diagnostic : quelques repères

Le diagnostic peut être mené en interne si vous disposez d'un administrateur expérimenté, ou confié à un intégrateur. Dans ce dernier cas, un point d'attention : le prestataire qui réalise le diagnostic n'est pas toujours le mieux placé pour être juge et partie sur la remédiation. Demandez un diagnostic dont les livrables restent votre propriété et sont réutilisables par n'importe quel intervenant.

Cadrez aussi le périmètre : un diagnostic d'org représente généralement quelques jours à quelques semaines selon la taille et l'ancienneté. Un devis ouvert « au fil de l'eau » est un signal de flou dans la méthode.

Pour dimensionner la charge, gardez en tête que l'ancienneté n'est pas le seul facteur : le nombre d'utilisateurs, de licences par cloud et de packages installés pèse au moins autant. Un CRM utilisé par 30 commerciaux depuis 8 ans est plus simple à auditer qu'une org de 3 ans partagée entre ventes, service et marketing.

En résumé

Greffer de l'IA sur une org Salesforce ancienne sans diagnostic, c'est prendre le risque d'amplifier automatiquement les défauts accumulés pendant huit ans. Le diagnostic n'est pas une étape administrative : c'est ce qui rend le projet IA prévisible, chiffrable et réversible. Il commence par les données, remonte les automatisations, le code et les accès, et débouche sur un plan d'assainissement priorisé par le cas d'usage. C'est cette clarté qui distingue un projet IA piloté d'un pari coûteux.

Un projet Salesforce à cadrer ?

Trouver le bon intégrateur Salesforce

Mise en relation gratuite · sans engagement · qualification par la donnée publique