Reprendre un projet Salesforce sans tout refaire : l’arbitrage sauver / refondre
Quand un projet Salesforce a déraillé, deux réflexes s’affrontent : tout jeter pour repartir « au propre », ou rafistoler indéfiniment. Les deux se trompent de point de départ. L’arbitrage sauver / refondre se prend sur quatre critères mesurables : la dette technique réelle, la qualité des données, l’adoption effective et l’écart au standard. Voici la grille que nous utilisons en reprise de projet.
La situation type : l’org existe, il a coûté cher, une partie tourne, mais plus personne n’ose y toucher. Le prestataire est parti ou la confiance est rompue, la documentation est partielle, et chaque nouvelle demande métier devient une négociation. La question qu’on nous pose alors est toujours la même : « on garde ou on recommence ? »
Le réflexe à éviter : décider avant de mesurer
La refonte totale rassure. Page blanche, nouveau prestataire, nouvelles promesses. Mais elle coûte structurellement le prix fort : on repaye ce qui fonctionnait déjà, on re-migre les données, on re-forme les équipes, et on perd l’historique des décisions (pourquoi ce champ, pourquoi cette règle) qui faisait la valeur de l’existant.
L’acharnement symétrique coûte aussi : maintenir à bout de bras un socle mal conçu, c’est payer chaque évolution deux fois, en développement puis en correction.
Entre les deux, la reprise sélective (garder le socle, refondre les périmètres malades) est l’issue la plus fréquente. Encore faut-il savoir ce qui est malade. Ça se mesure.
Critère 1 : la dette technique réelle, pas ressentie
« C’est mal fait » n’est pas un diagnostic. Ce qui s’observe et se compte, en revanche :
- le nombre d’automatisations qui se superposent sur un même objet (Flows multiples, anciens Workflow Rules et Process Builders jamais migrés) ;
- les identifiants codés en dur et les règles écrites pour des cas particuliers devenus permanents ;
- la gestion des droits (profils historiques empilés au lieu de permission sets) ;
- la couverture et la lisibilité du code, quand il y en a ;
- l’écart entre ce qui est documenté et ce qui tourne réellement.
Une dette élevée mais localisée (un module, un processus) plaide pour la reprise sélective. Une dette diffuse, présente sur tous les objets cœur, rapproche de la refonte.
Critère 2 : la qualité des données
C’est le critère le plus souvent oublié, et celui qui tranche le plus vite. Des données incomplètes mais cohérentes se nettoient : dédoublonnage, règles de validation, campagnes de complétion. Des données dont on ne sait plus ce qu’elles signifient (champs détournés de leur usage, statuts contradictoires, historique importé n’importe comment) condamnent parfois davantage l’org que le code.
Le test simple : prenez dix enregistrements récents et faites-les relire par un opérationnel. S’il ne peut pas dire lesquels sont fiables, le chantier données passera avant tout le reste, quelle que soit l’option retenue.
Critère 3 : l’adoption effective
Un org boudé n’est pas forcément un org raté. Avant d’imputer le rejet à l’outil, regardez qui se connecte, qui saisit, et où les équipes travaillent vraiment (souvent : dans des exports Excel). Trois causes très différentes produisent le même symptôme :
- un outil mal conçu (les écrans ne suivent pas le processus réel) : c’est un problème de conception, la refonte du périmètre concerné se défend ;
- un outil jamais enseigné : c’est un problème de formation et d’accompagnement, pas de plateforme ;
- un management qui n’a jamais arbitré (le CRM cohabite avec trois fichiers parallèles « en attendant ») : aucun prestataire ne réglera cela à votre place, et une refonte reproduira le problème à l’identique.
Refondre un org pour un problème d’adoption est l’erreur la plus chère de cette liste.
Critère 4 : l’écart au standard
Plus l’org s’est éloigné du standard Salesforce (objets sur-personnalisés, processus natifs recodés à la main, fonctionnalités standard doublées par du spécifique), plus chaque montée de version et chaque évolution coûtent cher, et plus la refonte devient rationnelle. À l’inverse, un org proche du standard, même désordonné, se remet en état à coût maîtrisé.
La grille de décision
| Situation constatée | Option qui se défend |
|---|---|
| Dette localisée, données nettoyables, adoption partielle, proche du standard | Sauver : reprise par lots, quick wins d’abord |
| Dette diffuse sur les objets cœur, écart au standard massif | Refondre, en re-migrant peu mais bien |
| Socle sain, un ou deux périmètres malades | Hybride : refonte du périmètre, conservation du socle |
| Données illisibles quelle que soit la suite | Chantier données d’abord, décision structurelle ensuite |
| Adoption en cause, org techniquement correct | Ni l’un ni l’autre : formation, simplification, gouvernance |
Dans tous les cas, la reprise commence petit : un lot de quick wins visibles en quelques semaines, qui rétablit la confiance des équipes avant les chantiers de fond. Un plan de reprise qui commence par six mois de tunnel reproduit les conditions de l’échec précédent.
Comment l’IA change l’état des lieux (concrètement)
La partie la plus longue d’une reprise a toujours été l’inventaire : lire l’org, comprendre les automatisations, reconstituer ce que le prestataire précédent n’a pas documenté. C’est précisément ce que l’IA accélère aujourd’hui : nos outils lisent l’ensemble des métadonnées, des Flows et du code, cartographient les dépendances et produisent une première documentation de l’existant, que nos consultants vérifient et confrontent aux entretiens utilisateurs.
Le gain n’est pas de remplacer le jugement : c’est de le nourrir. L’arbitrage sauver / refondre se prend sur un inventaire complet plutôt que sur un sondage, et en jours plutôt qu’en semaines. C’est ce format condensé que nous avons productisé dans le Second avis Salesforce.
Questions fréquentes
Peut-on reprendre un org sans documentation ? Oui, c’est même le cas le plus courant. La configuration et le code constituent la source de vérité ; la documentation se reconstitue à partir d’eux, l’IA aidant, puis se valide avec les utilisateurs clés.
L’ancien prestataire doit-il coopérer ? C’est utile, pas indispensable. Une passation d’une heure et la remise des livrables font gagner du temps ; leur absence ne bloque pas une reprise. Le sujet est traité en détail dans notre plan d’action quand l’intégrateur ne répond plus.
Une refonte fait-elle perdre l’historique ? Pas nécessairement : les données et leur historique se migrent. Ce qui se perd dans une refonte mal préparée, c’est la connaissance des règles métier enfouies dans l’ancienne configuration. D’où l’inventaire d’abord.
Combien coûte une reprise par rapport à une refonte ? Cela dépend entièrement du diagnostic, et c’est précisément pour cela qu’on chiffre les deux scénarios dans l’état des lieux : la décision se prend en comparant des plans chiffrés en jours, pas des convictions.
Vous héritez d’un org Salesforce ou votre projet est en difficulté ? Le Second avis Salesforce tranche l’arbitrage en 5 jours : état des lieux indépendant, risques classés, plan priorisé avec les deux scénarios chiffrés. 3 500 € HT, 100 % crédités* si une reprise ou une TMA se signe avec nous sous 60 jours. Voir les conditions sur la page.
