Systèmes d'information client : étude de cas dans la défense au Moyen-Orient

Voici l'étude de cas d'un industriel de la défense de taille moyenne au Moyen-Orient qui a remis en ordre ses systèmes d'information client. Les données clients vivaient à trois endroits, les devis partaient avec des prix incohérents et les approbations se perdaient dans les e-mails. La solution : une fiche client unique dans Microsoft Dynamics, un chiffrage par règles dans Experlogix CPQ et un transfert automatisé des devis approuvés vers SAP Ventes et distribution (SD) via SAP Cloud Integration. Le délai de devis a baissé de 35 % en moyenne. Ce texte s'adresse aux responsables des opérations commerciales, de l'informatique et de la finance chez les industriels dont les cycles de vente sont longs, configurables et très encadrés par la conformité. Le déroulé du déploiement et les enseignements, vers la fin, sont les parties à réutiliser.

Quand les équipes de la défense demandent des systèmes d'information client, elles entendent généralement plus qu'un CRM. Elles veulent de la structure : un endroit où les décisions complexes se retrouvent dans leur contexte, à travers des cycles de vente longs, des processus très encadrés par la conformité et des groupes de décideurs qui changent.

En tant que directeur de la transformation digitale dans une entreprise de défense, on m'a demandé de résoudre précisément ce problème. Le problème n'était pas le manque d'effort. Les gens faisaient le travail. Le souci, c'est que cet effort n'avait pas de point de rattachement. Pas de plateforme partagée, pas de visibilité, aucun alignement entre ce qui se vendait et ce qui se planifiait.

Un industriel de la défense de taille moyenne au Moyen-Orient. Il travaillait dans l'ombre : pas une marque grand public, et la visibilité n'était pas l'objectif. Ses composants équipaient l'aviation militaire et les communications sécurisées.

Chaque vente suivait un parcours détaillé : revues d'ingénierie, contrôles de conformité, approbations internes, devis sous gestion de versions. Ce n'était pas chaotique, mais c'était lourd.

Les systèmes d'information client s'effondraient. Les ventes utilisaient une plateforme. Le support en utilisait une autre. Les opérations travaillaient avec des tableurs, des dossiers hors ligne et des documents déjà périmés avant que quiconque les ouvre.

Voici ce qui ne fonctionnait pas et ce que cela coûtait :

Ce qui ne fonctionnait pas	Impact
Aucun CRM pour le flux d'opportunités ni la visibilité sur les décideurs	Aucune vision commune de l'avancement de chaque affaire
Prix gérés à la main, sans historique cohérent	Des devis partaient avec des chiffres périmés ou contradictoires
Approbations par e-mail, souvent perdues ou retardées	Pistes d'audit de conformité incomplètes
Fiches clients dupliquées d'un système à l'autre, avec des détails légèrement différents	Personne ne pouvait dire quelle version était exacte

Sur le papier, tout semblait structuré. Il suffisait de suivre un devis de sa création à sa livraison pour que tout s'effondre. Les approbations stagnaient faute de responsable clair. Le prix dépendait de la personne qui soumettait le devis. Les devis étaient enfouis dans des fils d'e-mails. Les équipes se posaient les mêmes questions encore et encore. Rien de tout cela n'était une défaillance spectaculaire, mais sur des mois les petits retards s'accumulaient, et pour une entreprise aux cycles de vente longs, l'élan perdu pesait plus que la plupart des gens ne le mesuraient.

L'objectif n'était pas de tout remplacer. Il s'agissait de réduire les frictions sans rien rendre plus difficile à utiliser : aider les systèmes à refléter la façon dont les équipes travaillaient déjà, au lieu d'enfermer les gens dans des processus rigides.

J'ai passé du temps avec les équipes avant de toucher à la moindre configuration. J'ai observé comment le travail circulait, de la saisie à la livraison, là où les outils gênaient et là où les gens avaient cessé de faire confiance aux données.

Ces séances ont fait ressortir trois priorités :

1. Une fiche client unique, visible des ventes, du support et des opérations dans le même format. Fini les versions parallèles.
2. Un chiffrage structuré, qui suit des règles cohérentes de configuration et de prix au lieu d'habitudes individuelles et de vieux modèles.
3. Une exécution des commandes connectée, avec un passage propre du devis approuvé vers SAP SD et aucune ressaisie manuelle.

Système	Ce qu'il a résolu
Microsoft Dynamics CRM	Une fiche client unique, liée à l'activité commerciale et aux opportunités
Experlogix Configure Price Quote (CPQ)	Règles de configuration des produits, logique de prix, versions de devis
SAP Ventes et distribution (SD)	Exécution et livraison des commandes
SAP Cloud Integration (CPI)	Couche d'intégration reliant CPQ et CRM à SAP SD

Microsoft Dynamics comme fondation. Il nous fallait un endroit où l'information client soit exacte et visible dans son contexte complet. Dynamics nous a donné un point de départ pour démêler les données. La familiarité avec la plateforme a aidé, tout comme son intégration avec Outlook et Teams. Elle n'obligeait personne à repartir de zéro ; il fallait seulement l'ajuster à la façon dont l'entreprise fonctionnait. Dès que les équipes ont vu les mêmes données dans le même format d'une fonction à l'autre, la confiance a commencé à s'installer.

Experlogix CPQ pour la configuration et les prix. Avant, le chiffrage se faisait de trop de façons différentes. On comptait sur la mémoire et les corrections manuelles. Nous avons paramétré Experlogix avec des règles définies pour les combinaisons de produits, des prix liés aux configurations et un routage des approbations selon le type et le montant de l'affaire. C'était contraignant au début, et certains ne se sont pas gênés pour le dire, mais cela a supprimé l'ambiguïté. L'ingénierie recevait des devis plus propres, et les commerciaux ont cessé d'ajuster les prix de mémoire d'après des affaires précédentes.

SAP SD via SAP CPI. SAP SD servait déjà pour les commandes. Le point faible était le passage de relais : un devis approuvé devait encore être ressaisi dans SAP. Nous avons intégré les deux par SAP CPI : les devis approuvés arrivaient directement dans SAP sous forme de commandes, et les données clients et commandes restaient synchronisées entre Dynamics et SAP. Là où nous avons rencontré des limites, nous avons ajouté de la logique sur mesure. Ce n'était pas élégant dans tous les cas, mais cela fonctionnait.

1. 01Fiche clientMicrosoft Dynamics, une seule version pour toutes les équipes
2. 02Configurer et chiffrerRègles Experlogix CPQ pour les combinaisons et les prix
3. 03ApprouverRoutage selon le type et le montant de l'affaire
4. 04Créer la commandeSAP CPI transfère le devis approuvé dans SAP SD
5. 05LivrerSAP SD, avec des données clients synchronisées

Aucune ressaisie, et une piste d'audit de l'approbation à la commande

Le déploiement s'est étalé par phases sur six à huit mois environ. Rien de spectaculaire : des changements par couches, validés à chaque étape.

1. Pilote. Un petit groupe d'utilisateurs et des scénarios précis centrés sur le CRM et le CPQ. Nous avons testé les cas limites, repéré les lacunes et corrigé avant de passer à l'échelle.
2. Nettoyer les données. Les fiches clients ont été consolidées et dédoublonnées avant d'entrer dans Dynamics, avec les documents de conformité rattachés aux bonnes opportunités. Cela a pris plus de temps que la configuration.
3. Étendre aux autres services. Une fois les workflows du pilote affinés, la solution est passée aux ventes, au support et aux opérations.
4. Intégrer SAP SD à mi-parcours. L'intégration entre CPQ et SAP est entrée en production une fois les systèmes en amont stabilisés, pour que les premiers problèmes ne se propagent pas aux commandes.

La sécurité et la conformité ont été intégrées dès le premier jour. Pour un client de la défense, l'intégrité des pistes d'audit et les accès par rôle ne sont pas négociables. Nous avons défini clairement les rôles d'accès et tracé les circuits d'approbation. La résidence des données a été réglée très tôt : toutes les données sont restées aux Émirats arabes unis, conformément aux règles du secteur de la défense. Cela nous a un peu ralentis au départ, et cela a évité des problèmes plus graves par la suite.

La formation était pratique : des séances courtes, des supports ciblés, des démonstrations en direct et des vidéos de prise en main, étalées sur des semaines et des mois plutôt que concentrées en une seule session. L'adoption n'a pas été parfaite au début. Un accompagnement régulier et des bénéfices visibles ont fini par vaincre les premières hésitations. Le tournant est venu quand les équipes ont utilisé les outils en situation réelle et constaté que les données obtenues étaient correctes.

Résultat	Ce qui a changé
Délai d'émission des devis	En baisse de 35 % en moyenne ; des heures gagnées sur de nombreuses affaires et plusieurs jours sur les affaires complexes
Exactitude de la configuration	Les règles de validation empêchaient les erreurs d'arriver jusqu'à l'ingénierie
Préparation aux audits	Les contrôles de conformité ne demandaient plus de course de dernière minute
Alignement entre équipes	Ventes, support et opérations travaillaient à partir de la même fiche client

La baisse de 35 % n'est pas intervenue la première semaine. Les premiers cycles comportaient encore des demandes de précisions et des corrections. Une fois les règles produit et la logique de prix cohérentes, le chiffrage s'est accéléré. Les commerciaux ne couraient plus après les approbations et ne corrigeaient plus de modèles réutilisés. Le système prenait en charge ces étapes.

L'alignement compte plus que la technologie. La construction technique était la partie facile. Obtenir que les équipes fassent confiance à une source de vérité unique et cessent de tenir leurs propres fichiers était plus difficile. Il fallait montrer aux gens que les données étaient fiables avant de leur demander de s'y appuyer.

Les détails d'intégration comptent plus que les fonctionnalités. C'est l'intégration entre CPQ et SAP SD qui a donné toute sa valeur à l'ensemble. Un CRM isolé et un outil de chiffrage isolé, avec saisie manuelle des commandes, auraient chacun aidé un peu. C'est dans la connexion entre eux que la friction a disparu.

L'accompagnement et la formation font que ça tient. Déployé puis abandonné, ce n'est pas livré. La formation s'est poursuivie pendant des semaines et des mois après le go-live, et c'est pendant cette période que l'adoption s'installe ou se défait.

L'architecture tient toujours : le CRM pour la fiche client, le CPQ pour le chiffrage structuré, l'intégration ERP pour l'exécution des commandes. Trois choses changeraient si la même mission démarrait aujourd'hui.

La plateforme d'intégration. SAP CPI est aujourd'hui la fonction Cloud Integration au sein de SAP Integration Suite, aux côtés de la gestion d'API, de l'intégration par événements et du contenu d'intégration prédéfini. Un flux Dynamics, CPQ puis SAP SD demanderait moins de temps de conception aujourd'hui. Mon guide SAP Cloud Integration présente la plateforme.

Le CRM de SAP figurerait sur la présélection. Avec un back-end SAP SD, une nouvelle mission devrait comparer SAP Sales Cloud, qui intègre désormais Joule, avec Microsoft Dynamics. Dynamics était le bon choix ici, à cause de la familiarité existante. La réponse dépend toujours des capacités et des préférences d'intégration, mais l'option native SAP est un candidat plus crédible qu'avant. Ma comparaison des systèmes CRM pour SAP passe en revue les options.

Le périmètre fédéral américain exige un autre modèle d'hébergement. Ce client n'en avait pas besoin, mais une entreprise de défense ayant des activités fédérales aux États-Unis se tournerait vers SAP National Security Services (SAP NS2). En 2025, cette entité a reçu une autorisation provisoire pour exploiter S/4HANA Cloud Private Edition et SAP BTP au niveau FedRAMP+ Impact Level 5, avec des opérations exclusivement américaines.

Les exigences propres à la défense (pistes d'audit, accès par rôle, gestion des versions des devis, résidence des données) s'appliquent quelle que soit la génération de la plateforme. Pour une vision plus large de la conformité, consultez mon guide sur la conformité SAP dans le secteur public.

Pourquoi Microsoft Dynamics a-t-il été retenu plutôt que d'autres plateformes CRM ?

Il pouvait gérer tout le cycle de vie du client, du prospect à l'opportunité puis au suivi après-vente, et absorber les cycles d'affaires longs et complexes de la vente dans la défense. Son intégration avec Outlook et Teams a favorisé l'adoption, et la familiarité de l'équipe avec l'outil a encore abaissé la barrière.

Le contrôle d'accès, la journalisation d'audit, la flexibilité et la marge d'évolution ont été les autres facteurs décisifs pour un client très exposé aux exigences de conformité.

Quel rôle Experlogix CPQ a-t-il joué, et pourquoi un CPQ ?

Les produits de défense obéissent à des règles de configuration complexes. Un tarif ne peut pas rendre compte de l'interaction entre les variantes de produit, les exigences de conformité et les conditions propres à chaque client. Sans CPQ, chaque devis dépendait du fait que son auteur connaisse les règles.

Experlogix a mis ces règles dans l'outil de chiffrage. Le commercial recevait un retour de validation pendant qu'il construisait le devis, et non une correction de l'ingénierie plusieurs jours après. Les erreurs ont remonté en amont, là où elles coûtent peu à corriger.

Comment SAP SD a-t-il été intégré au CRM et au CPQ ?

SAP CPI faisait office de middleware. Un devis approuvé dans Experlogix déclenchait un flux qui créait la commande dans SAP SD avec les bonnes lignes, les bons prix et les bonnes données client. CPI maintenait aussi la synchronisation des données clients et commandes entre Dynamics et SAP, avec des règles de validation pour bloquer les incohérences.

Avant, quelqu'un recopiait à la main chaque devis approuvé dans SAP. L'automatisation a supprimé les erreurs de ressaisie et créé une piste d'audit propre, de l'approbation à la commande.

Quels ont été les plus grands défis pendant la mise en œuvre ?

D'abord la qualité des données. Les données clients étaient incohérentes d'un service à l'autre, avec des doublons et des champs manquants, et il a fallu les nettoyer avant que Dynamics puisse devenir la source de vérité.

La correspondance des données entre systèmes est venue en deuxième, en particulier pour les configurations produit et les prix entre trois systèmes. Le troisième défi était d'aligner les ventes, l'ingénierie, l'informatique et la finance, surtout quand la responsabilité de certaines parties du processus changeait.

Comment la sécurité et la conformité ont-elles été traitées ?

Elles ont été intégrées dès le premier jour. Chaque composant devait respecter les politiques de sécurité internes et la réglementation nationale. Les accès par rôle limitaient qui pouvait consulter et modifier quels enregistrements. Des pistes d'audit complètes couvraient le chiffrage, les approbations et les modifications de données. Toutes les données sont restées aux Émirats arabes unis, conformément aux règles du secteur de la défense.

Comme la conception est partie de ces exigences, les données étaient déjà dans la bonne forme quand les revues de conformité sont arrivées.

Combien de temps le déploiement a-t-il duré ?

Environ six à huit mois, par phases. Il a commencé par un pilote centré sur le CRM et le CPQ, s'est étendu aux services après retour d'expérience, puis a ajouté l'intégration SAP SD à mi-parcours, une fois les systèmes en amont stabilisés. Formation, accompagnement et réglages se sont poursuivis tout du long.

Ce modèle s'applique-t-il à d'autres entreprises de défense ou d'industrie ?

Oui, partout où les cycles de vente sont longs, les produits configurables et la documentation de conformité obligatoire : l'aéronautique, les équipements industriels et toute activité où un devis doit être validé par l'ingénierie avant de partir.

Les outils précis comptent moins que la logique d'intégration. Le devis approuvé doit alimenter l'ERP sans ressaisie, et la fiche client doit être une source de vérité unique.