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.
Diagnostic
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.
Évaluation technique
L’état actuel de l’org a été documenté par rapport au cahier des charges initial. Sur les 87 exigences fonctionnelles du périmètre d’origine, 34 étaient entièrement livrées, 28 étaient partiellement livrées (fonctionnelles mais incomplètes), et 25 n’avaient pas été commencées. Parmi les 34 exigences « entièrement livrées », 11 avaient été livrées 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 de vente en gros B2B du client, créant une contrainte empêchant la propriété multi-territoire des comptes. Le processus de conversion des prospects avait été personnalisé d’une manière qui créait des problèmes d’intégrité des données à chaque conversion. Des Record-Triggered Flows avaient été écrits sans tenir compte des limites du gouverneur, provoquant des échecs lors des opérations 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.
Évaluation des processus et de la gouvernance
Le projet ne disposait d’aucun contrôle des 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, et 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 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.
Évaluation de la récupération
Sur les 28 exigences partiellement livrées, 19 pouvaient être complétées par un travail de développement ciblé. Les 9 restantes avaient été construites selon des approches architecturalement inadaptées et devaient être reconstruites plutôt que complétées. 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 avant que les exigences restantes puissent être construites par-dessus — sinon, nous aurions ajouté des exigences sur une fondation défaillante.
Action
Semaines 1-2 : Réparation de l’architecture
Le modèle de hiérarchie des comptes a été repensé. Les enregistrements de comptes existants ont été migrés vers la structure corrigée à l’aide d’un processus Batch Apex avec réconciliation complète avant/après. Le défaut de conversion des prospects a été diagnostiqué, attribué à un conflit entre un déclencheur et un Flow, et résolu. Tous les Record-Triggered Flows ont été audités, restructurés pour respecter les limites du gouverneur, et retestés dans des scénarios de données en masse.
Une suite de tests a été construite à partir de zéro : 340 méthodes de test couvrant l’ensemble de l’Apex personnalisé, atteignant 84 % de couverture. C’était une condition non négociable avant tout nouveau développement.
Semaines 3-8 : Sprint de livraison
Les exigences ont été repriorisées selon l’impact métier : les fonctionnalités ayant un impact sur le chiffre d’affaires en premier, l’efficacité opérationnelle en second, le reporting en dernier. Un cycle de sprints de deux semaines a été établi avec une planification de sprint formelle, des points quotidiens et des revues de sprint avec les parties prenantes métier comme mécanisme d’acceptation.
Les 19 exigences partielles complétables ont été finalisées lors des sprints 1-2. Les 9 reconstructions architecturales ont été exécutées lors des sprints 2-4. Les 25 exigences non commencées ont été livrées lors des sprints 3-6, avec des démonstrations hebdomadaires au métier confirmant l’acceptation avant de passer à la suite.
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 de prétendre avoir livré des exigences que le client n’acceptait pas.
Semaines 9-12 : Durcissement et lancement
Les tests de performance sur les volumes transactionnels projetés ont identifié trois requêtes lentes et un traitement par lots qui aurait échoué en charge. Tous ont été optimisés avant la mise en production. Une période de fonctionnement en parallèle a permis à l’équipe commerciale d’utiliser Salesforce en parallèle de son processus Excel existant, installant la confiance avant le retrait formel du processus Excel.
La formation à l’adoption a été dispensée au cours des deux dernières semaines. Contrairement à l’approche de l’intégrateur qui formait les utilisateurs au fonctionnement du système, la formation a été dispensée sous la forme « voici comment vous faites votre travail avec Salesforce » — spécifique au rôle, basée sur les flux de travail, avec des supports de référence qui survivaient au-delà des sessions de formation.
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 et 84 % de couverture de tests — a donné au métier une plateforme sur laquelle construire plutôt qu’une plateforme à contourner.
Le délai du directeur financier a été respecté. Le litige juridique avec l’intégrateur d’origine a été résolu : la position juridique du client a été renforcée par la documentation de l’évaluation technique, qui fournissait un constat objectif de ce qui avait et n’avait pas été livré. La négociation de règlement s’est conclue favorablement pour le client.
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, adopté — avec une feuille de route d’extension vers Service Cloud puis Data Cloud — a reconstruit cette confiance.
Approche : Évaluation et réparation de l’architecture, méthodologie de livraison par sprints, contrôle des modifications formel, recette fonctionnelle pilotée par les utilisateurs, tests de performance et optimisation
Related Case Studies
8M+ d'enregistrements, 7 systèmes historiques, zéro perte de données
Migration d'une plateforme pharma d'envergure avec zéro perte de données sur 8M+ d'enregistrements
8M+ Records, 7 Legacy Systems, Zero Data Loss
Enterprise pharma platform migration with zero data loss across 8M+ records