On nous appelle souvent après un go-live qui s’est mal passé. Pas un échec total — l’org tourne, les données sont là — mais quelque chose cloche. Les sales contournent l’outil, le backlog de bugs grossit, les équipes internes passent leur temps à éteindre des incendies plutôt qu’à avancer.
C’est le scénario classique de la reprise d’org. Voici comment on s’y prend.
1. Ne rien toucher avant d’avoir compris
La première tentation, c’est de se mettre à corriger. Un flux cassé ici, un champ mal mappé là. C’est une erreur.
Avant d’intervenir, on passe 2 à 3 jours à observer : on lit les flows, on regarde les logs d’erreur, on parle aux utilisateurs. Pas aux managers — aux utilisateurs. Ceux qui voient les bugs tous les jours et qui ont développé des contournements.
Ce travail d’observation permet de distinguer :
- les bugs structurels (modèle de données cassé, flux en erreur silencieuse)
- les problèmes d’adoption (l’outil fonctionne mais personne ne le comprend)
- les dettes techniques accumulées (customisations empilées sans logique d’ensemble)
Chaque catégorie appelle une réponse différente.
2. Prioriser par impact métier, pas par complexité technique
Une fois le diagnostic posé, on établit un plan de remédiation. Le critère de priorisation n’est pas la facilité de correction — c’est l’impact sur le métier.
Un flux en erreur qui bloque 3 commerciaux tous les matins passe avant une refonte du modèle de données, même si la refonte est plus “propre” techniquement.
On structure le backlog en trois niveaux :
- Critique — corrige dans la semaine, impact immédiat sur les équipes
- Structurant — planifié sur les 4 à 8 semaines suivantes, améliore la fondation
- Amélioration — intégré dans le run continu, traité quand la plateforme est stable
3. Documenter en avançant
Une org reprise sans documentation est une org qu’on reprendra encore dans 18 mois.
Chaque intervention — correction de flow, modification de modèle de données, ajustement de règle de validation — est documentée au moment où on la fait. Pas dans un wiki séparé : dans l’org elle-même, via les descriptions de champs, les notes sur les flows, les metadata.
L’objectif : qu’un développeur qui arrive 6 mois plus tard comprenne pourquoi les choses sont faites comme elles sont faites.
4. Remettre les utilisateurs dans la boucle
La plupart des problèmes d’adoption viennent d’un outil configuré sans les utilisateurs, puis livré à des gens qui ne l’ont pas demandé.
Lors d’une reprise, on organise systématiquement des ateliers courts (45 minutes, pas plus) avec les utilisateurs clés de chaque équipe. Pas pour leur présenter ce qu’on a fait — pour comprendre leurs vrais points de friction et valider les corrections avant de les déployer.
Ce travail prend du temps. Il est pourtant le facteur le plus déterminant pour que la plateforme soit utilisée durablement.
5. Mettre en place un process de run avant de partir
Stabiliser une org sans laisser un process de run en place, c’est garantir qu’elle se dégradera à nouveau.
Avant de clore une mission de stabilisation, on met en place systématiquement :
- un canal unique pour les demandes (Jira, Linear, Notion — peu importe, l’important c’est qu’il soit utilisé)
- un SLA minimal : délai de traitement selon la criticité
- une revue mensuelle du backlog avec un interlocuteur côté client
Pas de gouvernance lourde. Juste assez de structure pour que les nouvelles demandes ne s’accumulent pas dans des mails et des Slack épars.
Une org Salesforce n’est jamais vraiment “terminée”. Ce qui compte, c’est qu’elle soit stable, documentée et qu’il existe un process clair pour la faire évoluer sans l’abîmer.
Si vous êtes dans cette situation, on peut en parler.