Transformation Salesforce B2B paneuropéenne

Situation

Disneyland Paris lançait une transformation digitale B2B sur Salesforce, en remplacement de processus manuels fragmentés à travers les marchés européens. L’activité B2B, ventes corporate de groupe, partenariats avec les agences de voyages, relations avec les tour-opérateurs, s’étendait sur plus de 20 marchés européens. Chaque marché disposait de ses propres processus de vente, pratiques de gestion partenaires et modes opératoires hérités de décennies d’exploitation.

La mission était architecture-first par construction. Plutôt que de choisir un prestataire et de laisser les décisions d’implémentation dicter la conception, le siège voulait que l’architecture précède le prestataire. La spécification devait être suffisamment précise pour que le partenaire d’implémentation retenu construise selon la conception, et non autour d’elle.

Le risque sur la table était classique. Un programme Salesforce B2B couvrant 20+ marchés, cadré comme un appel d’offres de capacités, aboutirait soit à une sur-standardisation (et perdrait les marchés à l’adoption), soit à une sous-spécification (et verrait l’intégrateur re-concevoir au fil des changements de périmètre). Le brief du siège était de retirer ce choix de l’équation avant l’arrivée des prestataires.

Défi

Les opérations B2B européennes résistent à la standardisation. Chaque marché a développé des pratiques qui reflètent la culture commerciale locale, l’historique des relations partenaires et le contexte réglementaire. Un processus de réservation corporate qui tourne efficacement en France ne se transpose pas directement à son équivalent en Allemagne, en Espagne ou au Royaume-Uni. Imposer un modèle unique à tous les marchés produit une plateforme qui fonctionne techniquement pendant que les équipes locales la contournent discrètement. Permettre à chaque marché de personnaliser sans limites ramène exactement l’état fragmenté que la transformation devait résoudre.

Le problème architectural consistait à trouver le bon niveau d’abstraction. Le cadre devait être suffisamment standard pour gouverner, suffisamment souple pour absorber les variances réelles, et suffisamment explicite pour qu’un prestataire ne puisse pas le redéfinir en cours de construction. Cela exigeait de distinguer la véritable différence opérationnelle (divergence légitime que l’architecture devait accommoder) de la terminologie incohérente et des variations locales non documentées (convergence que la standardisation pouvait résoudre).

Le risque de transfert au prestataire amplifiait l’ensemble. Les programmes où une partie conçoit et une autre construit produisent de la dérive, à chaque fois. Les prestataires interprètent les exigences à travers leurs patterns de livraison existants, qui correspondent rarement à l’intention architecturale de manière précise. La seule protection est une documentation qui élimine l’ambiguïté : non pas une conception de haut niveau que le prestataire complète, mais une spécification que le prestataire exécute.

Ce que j'ai dit au comité de pilotage au démarrage de la phase d'audit

Le prestataire sera choisi à un moment. La question est de savoir s’il hérite d’une spécification ou d’une liste de souhaits. Nous n’avons qu’une seule occasion de trancher.

Action

L’audit a été mené du terrain vers le sommet, et non l’inverse. Plutôt que de concevoir à partir de la stratégie du siège, le travail a démarré par un engagement direct avec les opérations commerciales de chaque marché : structure des comptes corporate, gestion des relations avec les agences de voyages, circulation des réservations de la demande à la confirmation, reportings que les marchés devaient remonter. Plus de 20 marchés ont été évalués, en capturant les nuances opérationnelles que les processus classiques de recueil des besoins manquent systématiquement.

L’audit a produit une différenciation structurée entre les véritables exigences de marché (que l’architecture devait accommoder), les incohérences opérationnelles (que la standardisation pouvait résoudre), et les contournements locaux (symptômes de défaillances technologiques antérieures qu’une plateforme bien conçue éliminerait). Cette séparation a servi d’entrée à chaque décision de conception qui a suivi.

Le modèle de personnalisation a été rendu explicite sur le papier, pas supposé en réunion. Chaque marché pouvait configurer dans les paramètres définis ; les configurations hors paramètres nécessitaient une revue architecturale. Cela donnait aux équipes locales une vraie flexibilité tout en empêchant l’accumulation de divergences structurelles qui avaient fragmenté l’état antérieur.

L’appel d’offres a été rédigé comme une spécification technique, et non comme un questionnaire de capacités. Les réponses des prestataires ont été évaluées par rapport à l’architecture, et non par rapport à leur expertise plateforme ou à leurs clients de référence, parce que l’architecture avait déjà établi ce qui devait être construit. Les prestataires qui proposaient des approches divergeant de la conception devaient justifier cette divergence par rapport aux exigences qui l’avaient motivée, et non simplement proposer des alternatives.

Le prestataire retenu a reçu non pas un simple document d’exigences mais une conception architecturale complète : modèle de données, structure des objets, architecture d’intégration, périmètres de personnalisation et séquence de déploiement. L’implémentation a été cadrée selon l’architecture, et non l’inverse.

Résultat

L’audit B2B paneuropéen a été finalisé sur chaque marché du périmètre. Le livrable était une analyse des exigences et des divergences qui capturait la réalité opérationnelle plutôt que des processus idéalisés. L’architecture de la solution Salesforce a unifié les modèles de travail européens diversifiés en un cadre technique cohérent, avec une flexibilité définie pour les variations locales légitimes.

Le processus d’appel d’offres a abouti à une sélection de prestataire où le partenaire retenu était cadré selon la spécification architecturale. Le mandat d’implémentation était de construire ce qui avait été conçu, et non de découvrir quoi construire pendant la livraison. Le transfert n’a créé aucune ambiguïté sur ce qui constituait une livraison réussie, parce que la spécification le disait explicitement.

Le siège possède désormais un cadre paneuropéen qui gouverne sans aplatir. Les marchés locaux configurent dans le périmètre ; le reporting inter-marchés tourne sur le même modèle de données. La plateforme qui a atterri est celle que l’architecture spécifiait, pas celle qu’un prestataire aurait inventée en cours de route.

Recul

Ce motif fonctionne quand 10+ marchés partagent une opération B2B, quand le siège a l’appétit d’investir dans la phase d’audit avant la sélection du prestataire, et quand la direction accepte que l’architecture atterrisse avant la construction. C’est le bon choix dès que le coût d’une dérive de conception pilotée par le prestataire dépasserait le coût de l’audit, ce qui est le cas de la plupart des grands programmes paneuropéens ou pan-APAC.

Cela fonctionne moins bien sur les déploiements mono-marché où le choix spec-vs-prestataire existe à peine. Le coût de l’audit et de l’architecture ne rapporte rien sur un projet à un seul marché ; un appel d’offres de capacités et une équipe de build resserrée feront mieux.

À faire plus tôt : la documentation du périmètre de personnalisation. Le moment où les marchés résistent le plus à la standardisation est celui où ils découvrent, en cours de construction, qu’une fonction dont ils ont besoin sort du périmètre. Écrire le périmètre avant l’appel d’offres, et le rendre visible aux marchés, retire la découverte et le ressentiment ensemble.