Un projet Salesforce en difficulté casse rarement par hasard. Sous la plainte, on retrouve les mêmes conditions : un modèle de données qui a dérivé de sa conception, des automatisations empilées par plusieurs équipes sans ordre convenu, et un circuit de déploiement qui a glissé vers des modifications manuelles en production. Quatre-vingt-dix jours suffisent pour reprendre la main si le travail avance par jalons, chacun avec un décideur et un livrable de sortie. Les tentatives qui sautent cette séquence traitent les symptômes et laissent les causes en place.
La plainte cache la cause
Les sponsors décrivent ce qu’ils ont vu : la dernière livraison a cassé la production, l’intégrateur ne répond plus, les commerciaux sont revenus à Excel. La question utile est ailleurs : comment un seul événement a-t-il pu faire autant de dégâts ? En général, parce qu’un risque s’est accumulé là où personne ne le voyait, faute d’une image à jour de l’org.
Un redressement ne commence donc pas par un correctif. Une équipe qui construit dès la première semaine construit sur des fondations qu’elle n’a pas lues, et chaque changement qu’elle livre ajoute à l’incertitude qu’on lui demandait de réduire. Les conditions se traitent aussi ensemble : corriger les automatisations tant que le modèle de données reste cassé ne fait que déplacer la panne.
Trois jalons, trois décideurs
Les phases suivent une chaîne de dépendances. On ne stabilise pas les automatisations sans connaître le modèle de données, et on ne rétablit pas la confiance dans les déploiements tant que les automatisations ne sont pas stables.
| Jalon | Fenêtre | Décision principale | Décideur | Livrable de sortie |
|---|---|---|---|---|
| 1. Arrêter l’hémorragie | Jours 1-30 | Geler toute nouvelle configuration | Sponsor | Inventaire des métadonnées et des automatisations |
| 2. Stabiliser | Jours 31-60 | Quelle automatisation reste sur chaque objet | Responsable du processus, avec l’autorité de conception | Automatisations sans conflit, circuit de déploiement opérationnel |
| 3. Rétablir la confiance, passer la main | Jours 61-90 | Go ou no-go sur chaque mise en production contrôlée | Responsable des mises en production | Document d’état actuel, inventaire des automatisations, dictionnaire de données |
Jalon 1 : arrêter l’hémorragie
Lisez avant de toucher. Extrayez l’ensemble des métadonnées de l’org, cartographiez chaque Flow actif, chaque trigger Apex et chaque reste de Process Builder face aux objets qu’il touche, puis vérifiez dans les debug logs lesquels tournent vraiment en production. Auditez le modèle de données pour repérer les références cassées : lookups vers des record types qui n’existent plus, règles de validation qui se contredisent, champs que personne ne remplit.
L’action de confinement est un gel de toute nouvelle configuration. Rien n’arrive en production sans une note d’impact écrite, revue par un petit comité des changements. Ce gel est politique : c’est au sponsor de le porter et de l’annoncer. Une équipe de redressement ne peut pas l’imposer seule.
Jalon 2 : stabiliser
Résolvez les conflits avant d’améliorer quoi que ce soit. Le motif le plus dangereux, ce sont des automatisations concurrentes sur le même objet. Deux Flows qui mettent à jour le Stage d’une Opportunity lors du même enregistrement, sans ordre défini, entrent en concurrence : le résultat dépend de celui qui s’exécute en dernier. Les utilisateurs signalent un bug intermittent, et déboguer davantage n’y changera rien, parce que le comportement est inscrit dans la conception.
La correction : un seul point d’entrée d’automatisation par objet et par événement déclencheur. Choisir la logique qui reste relève du métier, donc le responsable du processus tranche avec l’autorité de conception, et le choix est écrit.
Les réparations du modèle de données avancent en parallèle, dans un ordre fixe : d’abord les relations qui cassent le reporting, parce que c’est ce que voient les parties prenantes, puis les champs, puis les règles de validation. Ce jalon met aussi en place le circuit de déploiement : une sandbox qui reflète la production, et le contrôle de version comme référence de ce que l’org doit contenir.
Jalon 3 : rétablir la confiance dans les déploiements et passer la main
Prouvez que la stabilisation tient. Prenez un changement réel mais borné, faites-le passer par tout le circuit (sandbox, validation, mise en production avec plan de retour arrière) et consignez le résultat. Recommencez trois fois, avec un peu plus de complexité à chaque fois. Au troisième cycle, l’équipe a montré que le circuit fonctionne et a pris l’habitude de s’en servir.
La gouvernance reste légère : un registre des décisions, une matrice de propriété des métadonnées qui nomme qui possède quels objets et quelles automatisations, et une revue mensuelle. Le jalon se ferme quand la documentation est remise à un responsable nommé côté client.
Ce que les redressements ratent
La dérive du périmètre. Dès que l’org refonctionne, le métier demande des fonctionnalités. L’équipe de redressement veut montrer ce qu’elle apporte, se remet à construire, et les problèmes de fond restent. La parade est un verrou de périmètre explicite : les jalons 1 et 2 sont réservés au redressement. Le jalon 3 peut inclure un ou deux changements visibles, choisis parce qu’ils font tourner le nouveau circuit de déploiement plutôt que pour leur valeur métier. C’est au sponsor de le dire au métier.
Une date à la place d’un jalon. Quatre-vingt-dix jours, c’est une fenêtre de planification. Si le jalon 1 révèle un modèle de données plus abîmé que prévu, le jalon 2 s’allonge. Compresser le travail pour tenir une date donne une org qui a l’air stable et qui retombe sous la charge.
La documentation remise à plus tard. Les projets en difficulté sont presque toujours sans documentation. Une équipe qui part sans document d’état actuel ni inventaire des automatisations transmet à la suivante les mêmes risques cachés, et le cycle recommence. Inscrivez ces documents au plan comme livrables de sortie dès le premier jour.
Mesurer l’avancement
« L’org va mieux » n’est pas une mesure. Chaque jalon a besoin de marqueurs opérationnels :
- Fin du jalon 1 : un inventaire complet des métadonnées existe, toutes les automatisations actives sont documentées avec leur ordre d’exécution, et aucune modification non planifiée n’a touché la production pendant les deux dernières semaines.
- Fin du jalon 2 : plus aucun conflit d’automatisation connu, le circuit de déploiement s’exécute de bout en bout sans étape manuelle, et les références cassées sont résolues sur tous les objets du périmètre.
- Fin du jalon 3 : trois mises en production contrôlées sont faites, au moins deux décisions sont consignées, et un court questionnaire aux parties prenantes montre un progrès par rapport à la référence prise la première semaine.
Ces marqueurs sont opérationnels à dessein. Les résultats métier mettent plus de 90 jours à apparaître ; à ce stade, on mesure si les conditions d’une livraison fiable sont revenues. Pour le diagnostic lui-même, la revue d’org détaille ce qu’il faut lire, et la note sur la dette technique précise ce qu’il faut placer en premier sous contrôle de version.
À vérifier
- Le gel des changements a un responsable, et c’est le sponsor qui l’a annoncé.
- Chaque objet a un seul point d’entrée d’automatisation par événement déclencheur.
- L’équipe sait déployer un changement de bout en bout sans étape manuelle en production.
- Le document d’état actuel et l’inventaire des automatisations figurent au plan comme livrables, avec un responsable nommé après la passation.