Comment intégrer SAP avec Dynamics 365 sans dupliquer les données ?

Intégrer SAP avec Dynamics 365 consiste à faire circuler uniquement les données nécessaires, dans un sens défini et sous le contrôle d’un système de référence. La première décision n’est donc pas le choix d’un connecteur : il faut d’abord décider où naissent le client, le produit, le devis, la commande et la facture.

Dynamics 365 Sales utilise Dataverse pour les données commerciales. SAP reste généralement le référentiel des données de gestion, mais cette répartition n’est pas universelle. Elle doit être validée objet par objet avec les responsables métier et le référent SAP.

Quelles données synchroniser entre SAP et Dynamics 365 ?

Le CRM n’a pas besoin d’une copie complète de SAP : il lui faut le contexte nécessaire pour vendre et informer le client. Répliquer chaque table augmente les doublons, les erreurs et la maintenance sans améliorer le travail commercial.

Une répartition fréquente ressemble à celle-ci :

Ce tableau est un point de départ, pas une règle automatique. Une entreprise peut par exemple gérer ses devis dans Dynamics 365 tout en confiant le calcul final des prix et la commande à SAP. L’important est d’éviter que deux systèmes puissent modifier la même donnée sans règle d’arbitrage.

Comment éviter les doublons entre SAP et Dataverse ?

Chaque objet synchronisé doit posséder une clé stable commune aux deux systèmes. Le nom d’une société ou son adresse ne suffisent pas : ils changent, s’écrivent différemment et créent rapidement plusieurs fiches pour le même client.

Le cadrage doit définir pour chaque donnée :

1. son système de référence ;
2. son identifiant SAP et son identifiant Dataverse ;
3. le sens autorisé de création et de mise à jour ;
4. les champs réellement échangés ;
5. le traitement d’une suppression, d’une fusion ou d’un rejet.

Dataverse fournit notamment des clés alternatives et l’opération upsert pour retrouver un enregistrement existant avant de le créer ou de le mettre à jour. Ces mécanismes limitent les doublons, mais ils ne remplacent pas une règle claire sur la propriété de la donnée.

Temps réel, asynchrone ou traitement par lots ?

Le bon rythme est celui exigé par la décision métier, pas celui qui paraît le plus moderne. Un traitement synchrone bloque l’action en cours jusqu’à la réponse du système distant ; un traitement asynchrone laisse chaque application continuer et traite l’échange séparément.

Le synchrone se justifie lorsqu’un commercial doit obtenir immédiatement une information pour poursuivre : disponibilité critique, contrôle de crédit ou validation indispensable. Il crée toutefois une dépendance directe à SAP, au réseau et au mécanisme d’intégration.

L’asynchrone convient mieux aux commandes validées, changements de statut ou mises à jour qui doivent être rapides sans bloquer l’utilisateur. Une file de messages peut absorber un pic et conserver les échanges jusqu’à leur traitement.

Le traitement par lots reste pertinent pour un catalogue volumineux, une reprise initiale ou une actualisation nocturne. Microsoft recommande de choisir le modèle à partir du volume, de la fréquence, de la direction et de la capacité du système le plus contraint. Power Automate fonctionne de manière asynchrone et ne garantit pas une performance en temps réel.

Quel connecteur utiliser pour SAP et Dynamics 365 ?

Le choix dépend d’abord de la version de SAP et des interfaces qu’elle expose. SAP ECC, SAP S/4HANA sur site et SAP S/4HANA Cloud ne proposent pas nécessairement les mêmes mécanismes ni les mêmes contraintes réseau.

Microsoft documente deux familles principales :

• le connecteur SAP ERP, fondé sur le protocole RFC et la bibliothèque SAP .NET Connector ;
• le connecteur SAP OData, adapté aux produits SAP qui exposent des services OData.

Azure Logic Apps prend aussi en charge des opérations SAP basées sur BAPI, RFC et IDoc. Pour SAP S/4HANA, SAP documente des API OData et SOAP ; certaines API OData peuvent répondre de façon synchrone, tandis que d’autres permettent aussi un traitement asynchrone.

Power Automate convient aux automatisations ciblées avec Dataverse et aux volumes maîtrisés. Azure Logic Apps est à étudier pour une intégration plus critique, plus volumineuse ou nécessitant une architecture découplée. Azure Functions peut compléter l’ensemble lorsqu’une transformation ou une règle spécifique ne peut pas être exprimée proprement dans l’orchestrateur.

Que doit-il se passer lorsqu’un échange échoue ?

Un échec doit devenir visible, explicable et rejouable sans créer une deuxième commande. Une intégration qui se contente de relancer silencieusement peut transformer une panne temporaire en doublon métier.

Le dispositif de reprise doit prévoir :

• un identifiant de corrélation commun aux journaux SAP et Microsoft ;
• une clé d’idempotence pour reconnaître un message déjà traité ;
• des tentatives automatiques limitées pour les erreurs temporaires ;
• une file de quarantaine pour les messages qui nécessitent une correction ;
• une alerte adressée à un responsable identifié ;
• un contrôle de réconciliation pour détecter les échanges manquants.

Une erreur technique et une erreur métier ne se corrigent pas de la même manière. Une indisponibilité réseau peut être retentée ; un client sans identifiant obligatoire doit être corrigé avant le rejeu. Les tests doivent couvrir ces deux familles, pas seulement le parcours nominal.

Qui est responsable de chaque côté de l’intégration ?

Benly Consulting intervient sur Dynamics 365, Dataverse et l’orchestration ; le fonctionnement interne de SAP reste sous la responsabilité de votre spécialiste SAP. Cette frontière évite de promettre une expertise fonctionnelle ERP qui n’appartient pas au périmètre CRM.

Benly Consulting peut cadrer les objets Dataverse, les correspondances de champs, les flux, la journalisation et les tests côté CRM. Votre référent SAP, votre éditeur ou votre intégrateur SAP doit ouvrir et documenter les interfaces, valider les autorisations, confirmer les règles ERP et conduire la recette dans SAP.

Les décisions communes portent sur les référentiels, les identifiants, la sécurité, les cas d’erreur et les critères d’acceptation. Sans interlocuteur SAP disponible, une estimation de calendrier ou de budget resterait artificielle.

Par quoi commencer avant de demander un chiffrage ?

Commencez par un seul flux qui possède une valeur métier claire et un propriétaire disponible. Une commande validée envoyée de Dynamics 365 vers SAP, avec retour de son numéro et de son statut, constitue souvent un périmètre plus contrôlable qu’une synchronisation générale des clients et produits.

Préparez six informations : version et mode d’hébergement de SAP, objet métier prioritaire, sens du flux, volume moyen et maximal, délai acceptable, et nom du référent SAP. Ces éléments permettent ensuite de comparer Power Automate, Azure Logic Apps et les interfaces SAP disponibles sans choisir un outil à l’aveugle.

Notre page Intégration ERP avec Dynamics 365 et Dataverse détaille le partage des responsabilités. Pour obtenir un simple ordre de grandeur sans supposer la complexité de SAP, utilisez le simulateur de budget Dynamics 365.

Sources officielles vérifiées

Sources consultées le 3 septembre 2026 :

• Microsoft Learn — Power Platform et intégration SAP
• Microsoft Learn — accéder à SAP depuis Azure Logic Apps
• Microsoft Learn — choisir un modèle d’intégration Power Platform
• Microsoft Learn — synchroniser des données avec Dataverse
• SAP Help — API de vente SAP S/4HANA