Sauvetage Salesforce en 90 jours pour un distributeur de mode mondial

Situation

Un distributeur de mode mondial avec 800 M€ de chiffre d’affaires annuel tentait un déploiement Salesforce Sales Cloud depuis 18 mois. La date de mise en production initiale remontait à 14 mois. Le projet avait consommé 2,4 M€ en honoraires d’intégrateur pour un budget initial de 900 K€. Le partenaire d’implémentation en place avait facturé 40 % de plus en « changements de périmètre » que la valeur du contrat d’origine, sans que la livraison soit pour autant achevée.

L’entreprise subissait un impact opérationnel significatif. L’équipe commerciale gérait son pipeline dans Excel parce que le déploiement Salesforce n’inspirait pas confiance : trop d’erreurs de données, trop de problèmes de performance. La direction avait perdu confiance dans le projet et dans le partenaire d’implémentation. L’investissement Salesforce était remis en question au niveau du conseil d’administration.

La relation avec l’intégrateur s’était complètement dégradée. Les escalades auprès de la direction commerciale de l’intégrateur avaient produit des engagements de niveau de service et des excuses, mais aucune livraison. Le client avait adressé une mise en demeure à l’intégrateur. La mission était passée d’un projet technologique à un litige juridique, l’intégrateur protégeant sa position plutôt que de livrer.

Le client avait besoin d’un architecte indépendant pour évaluer les dégâts, déterminer ce qui pouvait être récupéré, et livrer les exigences restantes dans un délai ferme de 90 jours fixé par le nouveau directeur financier.

Défi

Les deux premières semaines ont été entièrement consacrées au diagnostic. Aucune modification n’a été apportée à l’org ou au plan de projet tant que le tableau complet n’était pas clair.

L’évaluation technique a documenté l’état de l’org face au cahier des charges initial. Sur les 87 exigences fonctionnelles du périmètre d’origine, 34 étaient entièrement livrées, 28 partiellement (fonctionnelles mais incomplètes), et 25 jamais commencées. Parmi les 34 « entièrement livrées », 11 l’étaient avec des défauts connus que l’intégrateur avait enregistrés comme « éléments d’arriéré » : livrées sur le papier mais défaillantes en pratique.

Le modèle de données présentait des problèmes architecturaux fondamentaux. La hiérarchie des comptes avait été modélisée de manière incorrecte pour la structure wholesale B2B du client, créant une contrainte empêchant la propriété multi-territoires des comptes. Le processus de conversion des prospects avait été personnalisé d’une façon qui créait des problèmes d’intégrité à chaque conversion. Des Record-Triggered Flows avaient été écrits sans tenir compte des limites du gouverneur, provoquant des échecs en masse. La couverture de tests était de 42 %, bien en dessous des 75 % exigés par Salesforce et des 80 % nécessaires en charge de production.

Le tableau côté processus et gouvernance correspondait au tableau technique. Aucun contrôle de modifications digne de ce nom. Les changements d’exigences étaient convenus oralement avec le chef de projet de l’intégrateur, jamais formellement documentés, souvent interprétés différemment par le client et l’intégrateur. Les frais de « changement de périmètre » représentaient dans certains cas du travail supplémentaire légitime et dans d’autres des erreurs de l’intégrateur, mais en l’absence d’ordres de modification formels, il n’existait aucun moyen de trancher. Il n’y avait pas non plus de processus de recette fonctionnelle. Le client avait accepté les livrables sur la base de démonstrations pilotées par l’intégrateur, sans test d’acceptation structuré adossé à des cas de test écrits. Les utilisateurs n’avaient participé à aucun test avant chaque mise en production, ce qui signifie que les défauts étaient découverts en production plutôt qu’en phase de test.

Sur les 28 exigences partiellement livrées, 19 pouvaient être complétées par un développement ciblé. Les 9 restantes avaient été construites selon des approches architecturalement inadaptées et devaient être reconstruites. Les 25 exigences non commencées étaient toutes réalisables en 90 jours avec la bonne équipe et la bonne méthodologie. Les problèmes de modèle de données nécessitaient des corrections architecturales en premier ; sinon, les nouvelles exigences seraient venues se poser sur une fondation défaillante, et la reprise aurait échoué de la même manière que l’original.

Ce que j'ai dit au directeur financier à la fin de la phase de diagnostic

Nous ne pouvons pas livrer quatre-vingt-sept exigences sur une hiérarchie de comptes cassée. Deux semaines pour réparer l’architecture, huit semaines pour tout livrer. C’est le seul chemin qui tienne.

Action

Chaque exigence disposait d’un document de critères d’acceptation écrits, rédigé par le responsable métier et validé avant le début du développement. Chaque élément terminé était testé par le métier selon ces critères avant d’être marqué comme terminé. Cela a éliminé l’ambiguïté qui avait permis à l’intégrateur d’origine de prétendre avoir livré des exigences que le client n’acceptait pas.

Résultat

Les 87 exigences ont été livrées en production en 90 jours, y compris les 25 qui n’avaient jamais été commencées au début de la mission. L’équipe commerciale a migré intégralement d’Excel vers Salesforce en trois semaines après la mise en production, sans incident critique pendant les 30 premiers jours d’exploitation.

Le socle architectural (hiérarchie de comptes reconstruite, modèle de données propre, automatisation respectant les limites du gouverneur, 84 % de couverture de tests) a donné au métier une plateforme sur laquelle construire plutôt qu’une plateforme à contourner. La couche de reporting tournait sur le même modèle de données que celui que l’équipe commerciale saisissait. Les métriques de pipeline dont le directeur financier avait besoin pour la revue trimestrielle existaient pour la première fois depuis deux ans.

Le délai du directeur financier a été respecté. Le litige juridique avec l’intégrateur d’origine a été résolu à des conditions favorables au client. La documentation du diagnostic technique a fourni un constat objectif de ce qui avait et n’avait pas été livré, ce qui a renforcé la position du client dans la négociation de règlement.

Plus important encore, l’organisation a retrouvé sa confiance dans Salesforce en tant que plateforme. Les 18 mois de blocage avaient créé un scepticisme réel au niveau du conseil d’administration quant à la capacité de Salesforce à fonctionner pour l’entreprise. Un déploiement fonctionnel et adopté, avec une feuille de route d’extension vers Service Cloud puis Data Cloud, a reconstruit cette confiance.

Recul

Ce motif fonctionne quand le mode d’échec est architectural et procédural, quand la direction accepte que le diagnostic précède la modification, et quand les responsables métier acceptent de signer des critères d’acceptation écrits. C’est le bon choix dès qu’un programme en blocage approche d’une échéance ferme et que la relation avec l’intégrateur d’origine s’est dégradée : une reprise sur une fondation propre coûte moins cher et va plus vite qu’un redémarrage complet.

Cela fonctionne moins bien quand l’implémentation antérieure a franchi un seuil structurel, par exemple quand le modèle de données a été tellement personnalisé que le coût de migration dépasse le coût de reconstruction, ou quand les customisations de l’org sont restées non documentées si longtemps que le diagnostic lui-même devient un projet de plusieurs mois. À ce stade, un redémarrage contrôlé est la réponse honnête.

À faire plus tôt : les critères d’acceptation écrits. La seule modification qui prévient le plus régulièrement le mode d’échec que cette mission a réparé est d’imposer que chaque exigence dispose d’une définition de « terminé » signée par le responsable métier avant le démarrage du développement. Cette modification est gratuite, se trouve dans l’autorité du client, et aurait évité au moins la moitié du conflit de périmètre qui a consommé les 18 mois d’origine.