Votre ERP concentre tout ce qui compte : données financières, fiches clients, paye, stocks. Et pourtant, dans la majorité des PME et ETI européennes, les comptes ERP sont gérés séparément du reste du système d’information. Un collaborateur a un mot de passe Office 365, un autre pour l’ERP, un troisième pour la GED. Résultat : des mots de passe réutilisés, des comptes fantômes jamais supprimés à la sortie d’un employé, et aucune visibilité centrale sur qui accède à quoi.
Le Single Sign-On (SSO) couplé à Microsoft Entra ID (l’ancien Azure Active Directory) est la réponse opérationnelle à ce problème. Ce guide détaille le “pourquoi” et le “comment” pour les quatre ERP les plus répandus en France et en Europe : SAP S/4HANA, Microsoft Dynamics 365 Business Central, Odoo et Sage.
Pourquoi connecter votre ERP à Microsoft Entra ID en 2026
SSO vs comptes ERP locaux : les 5 risques du statu quo
Gérer des comptes ERP en silo expose l’organisation à des risques bien documentés.
1. Mots de passe partagés ou réutilisés Quand un collaborateur doit retenir cinq mots de passe différents, il finit par en copier un. Le mot de passe ERP devient le même que celui de l’email personnel ou du PC. Une seule fuite suffit à compromettre l’accès aux données financières.
2. Comptes orphelins Un départ, une mutation interne, un prestataire en fin de mission : si la désactivation ERP n’est pas synchronisée avec la RH, le compte reste actif. Ces comptes zombies sont la porte d’entrée préférée des attaquants, car ils ne déclenchent aucune alerte d’activité suspecte.
3. Absence de MFA sur l’ERP Beaucoup d’ERP historiques n’ont pas de MFA natif. Connectés à Entra ID, ils héritent automatiquement des politiques d’authentification de l’entreprise, y compris le second facteur.
4. Aucune visibilité centralisée Avec des comptes locaux, impossible de répondre en temps réel à “qui était connecté à l’ERP hier à 23h depuis une IP roumaine ?”. Avec Entra ID, les logs de connexion sont disponibles dans un tableau de bord unique.
5. Non-conformité NIS2 La directive NIS2 (applicable en France via la transposition de la Directive (UE) 2022/2555) exige des mesures d’authentification renforcée et une capacité de traçabilité. Des comptes ERP locaux sans audit trail centralisé fragilisent votre dossier de conformité.
Les bénéfices concrets pour l’utilisateur et pour la sécurité
Du côté utilisateur, le SSO signifie une seule connexion pour toute la journée. L’employé s’authentifie sur son poste Windows (ou depuis le portail Microsoft 365), et l’ERP s’ouvre sans nouvelle demande de mot de passe. L’expérience est identique en télétravail, avec le MFA conditionnel comme seul garde-fou supplémentaire.
Du côté sécurité, Microsoft confirme dans sa recherche officielle que le MFA bloque plus de 99,9 % des attaques sur les comptes, en s’appuyant sur l’analyse de millions de connexions Azure AD (Microsoft Security Blog, 2019). La mise à jour de ce chiffre en 2024 confirme la tendance : les comptes protégés par MFA résistent à plus de 99,2 % des attaques basées sur l’identité (Microsoft Entra documentation).
Entra ID, Azure AD, SAML, OIDC : le lexique essentiel en 5 minutes
Microsoft Entra ID est le nouveau nom de Microsoft Azure Active Directory depuis juillet 2023. Si votre intégrateur ERP parle encore “d’Azure AD”, il parle de la même chose. La documentation officielle Microsoft a migré progressivement, mais les APIs et les fonctionnalités sont identiques.
SAML 2.0 (Security Assertion Markup Language) est le protocole historique du SSO d’entreprise. Il fonctionne en échangeant des “assertions” XML entre l’ERP (le fournisseur de services) et Entra ID (le fournisseur d’identité). La plupart des ERP on-premise et SaaS B2B supportent SAML 2.0.
OAuth 2.0 / OpenID Connect (OIDC) est le protocole plus récent, natif du web et des applications mobiles. Dynamics 365 Business Central utilise OIDC nativement avec Entra ID. Odoo peut être configuré en OIDC via certains modules.
Quand utiliser quoi ? SAML 2.0 pour les ERP on-premise ou les solutions SaaS B2B qui ne supportent pas encore OIDC (SAP IAS, Sage X3). OIDC pour les applications Microsoft-natives et les ERP cloud modernes. Dans tous les cas, Entra ID supporte les deux protocoles.
Intégration SSO par ERP : les 4 principaux
SAP S/4HANA et SAP Business One avec Entra ID
SAP recommande une architecture à trois niveaux pour l’intégration avec un fournisseur d’identité externe. Entra ID ne se connecte pas directement à S/4HANA : il passe par SAP Cloud Identity Services (l’ancien SAP Identity Authentication Service, IAS), qui joue le rôle de proxy.
Le flux est le suivant : l’utilisateur tente de se connecter à S/4HANA, SAP IAS redirige la demande vers Entra ID, Entra ID authentifie l’utilisateur (avec MFA si applicable), puis renvoie une assertion à IAS, qui la transmet à S/4HANA.
Ce schéma présente un avantage clé : SAP IAS reste le référentiel central pour les droits SAP (rôles, groupes SAP), tandis qu’Entra ID gère l’identité de l’utilisateur. Les administrateurs SAP ne perdent pas la main sur la gouvernance des accès. Microsoft et SAP documentent conjointement ce scénario dans le guide Scenario - Using Microsoft Entra ID to secure access to SAP platforms.
Pour SAP Business One, l’intégration est disponible via le module IAM (Identity and Authentication Management) de Business One, avec configuration SAML 2.0 vers Entra ID.
Microsoft Dynamics 365 Business Central avec Entra ID
C’est le cas le plus simple. Business Central est une solution Microsoft : l’intégration avec Entra ID est native et ne nécessite aucun middleware tiers. Chaque tenant Business Central est automatiquement lié au tenant Entra ID de l’organisation.
Les utilisateurs Business Central sont provisionnés depuis Entra ID. Les politiques Conditional Access (MFA hors réseau, blocage d’IP suspectes) s’appliquent automatiquement. C’est un avantage structurel fort pour les entreprises déjà dans l’écosystème Microsoft 365 : il n’y a rien à configurer au-delà de la gestion des licences.
Entra ID est inclus dans les abonnements Microsoft 365 Business Premium (niveau P1) et dans les plans E3 et E5. Pour la grande majorité des PME sous Microsoft 365, cette intégration est donc disponible sans surcoût de licence.
Odoo 17/18 avec Entra ID
Odoo Community et Enterprise ne proposent pas d’intégration SAML ou OIDC native en standard. Deux options s’offrent à l’intégrateur.
Option 1 : module OCA (Odoo Community Association)
Le module auth_saml maintenu par l’OCA (disponible sur apps.odoo-community.org) permet d’activer SAML 2.0 sur Odoo. Il est open source, compatible avec Odoo 17, et peut être configuré avec Entra ID comme Identity Provider. C’est la solution privilégiée pour les déploiements on-premise.
Option 2 : modules marketplace Odoo Apps Plusieurs éditeurs proposent des modules spécifiques Microsoft Azure SSO sur la marketplace officielle Odoo Apps, pour les versions 16, 17 et 18. Ces modules gèrent l’authentification via OAuth 2.0 / OIDC avec Entra ID.
Points d’attention : vérifier la compatibilité avec votre version Odoo, la maintenance du module (date du dernier commit, issues ouvertes) et l’impact sur les futures migrations. Aucun de ces modules n’est endossé officiellement par Odoo SA.
Sage X3 / Sage 100 avec Entra ID
Sage X3 (désormais “Sage X3” dans la famille Sage Business Cloud) supporte l’authentification SAML 2.0. La configuration se fait dans les paramètres d’authentification du module X3 Administration, en déclarant Entra ID comme Identity Provider via son URL de métadonnées SAML.
Pour Sage 100cloud, la configuration SSO dépend de la version et de l’hébergement. En mode SaaS Sage, certaines options SSO sont disponibles directement depuis le portail partenaire. En mode on-premise, l’intégration SAML requiert une intervention de l’intégrateur sur la configuration du serveur Sage.
Dans les deux cas, le principe reste le même : configurer l’Entity ID et l’Assertion Consumer Service URL côté Sage, puis créer l’application d’entreprise correspondante dans Entra ID.
MFA conditionnel sur votre ERP : les règles recommandées
Le MFA conditionnel est la fonctionnalité Entra ID qui impose le second facteur selon le contexte de connexion, pas de façon systématique.
Règle 1 : toujours exiger le MFA hors réseau Configurez une politique Conditional Access qui impose le MFA pour tout accès à l’ERP depuis une IP hors du réseau d’entreprise. En pratique : télétravail, déplacements, accès depuis un téléphone sur réseau mobile.
Règle 2 : exempter les accès depuis les IP de confiance Pour éviter la friction quotidienne en bureau, définissez vos plages IP fixes comme “Named Locations” dans Entra ID. Les connexions depuis ces IP sont exemptées du MFA. Ce compromis pragmatique satisfait les équipes métier sans sacrifier la sécurité externe.
Règle 3 : bloquer les pays à risque Entra ID permet de bloquer les tentatives de connexion depuis des géographies entières. Si votre ERP n’a aucun utilisateur légitime en dehors de France, Belgique et Suisse, le reste peut être bloqué en deux clics.
Règle 4 : exiger le MFA pour les rôles sensibles en toutes circonstances Pour les administrateurs ERP, les accès comptabilité et les rôles finance, configurez le MFA obligatoire quelle que soit l’IP. Ces comptes sont les cibles prioritaires des attaquants.
Provisioning et déprovisioning automatique avec SCIM
Le SSO règle l’authentification, mais pas la gestion du cycle de vie des comptes. Le protocole SCIM (System for Cross-domain Identity Management) comble ce manque.
Pourquoi le SSO seul ne suffit pas Avec le SSO pur, l’utilisateur s’authentifie via Entra ID mais son compte ERP reste géré manuellement. Un employé qui quitte l’entreprise voit son compte Entra ID désactivé par la RH, mais son compte ERP peut rester actif si personne ne pense à le supprimer. Ce décalage est une violation directe des exigences NIS2 sur la gestion des accès.
Ce que permet SCIM Quand un utilisateur est créé, modifié ou désactivé dans Entra ID (typiquement piloté par le SIRH via une connexion ADP, SAP SuccessFactors ou autre), SCIM propage automatiquement l’action dans l’ERP cible. L’administrateur ERP ne reçoit pas de ticket à traiter manuellement.
SAP Cloud Identity Services supporte SCIM nativement pour la synchronisation entre Entra ID et S/4HANA. Dynamics 365 Business Central gère le cycle de vie directement depuis Entra ID. Pour Odoo et Sage, la disponibilité de SCIM dépend de la version et de l’intégrateur : vérifier avec votre partenaire.
Les 5 pièges courants et comment les éviter
Piège 1 : les comptes de service exclus du SSO Les comptes techniques (synchronisation EDI, interfaces API, batchs nocturnes) ne peuvent pas passer par SSO. Ils restent locaux. Erreur fréquente : les laisser sans MFA ni audit. Appliquez des mots de passe longs et rotatifs, une surveillance des connexions, et limitez leur périmètre de droits au strict nécessaire.
Piège 2 : des groupes Entra ID mal mappés sur les rôles ERP Le SSO transporte les groupes Entra ID vers l’ERP. Si le mapping est approximatif (“tout le groupe Finance” reçoit un profil “administrateur ERP”), vous créez une surallocation massive de droits. Cartographiez précisément la correspondance groupes Entra ID / profils ERP avant le déploiement.
Piège 3 : tester uniquement en environnement de dev Le SSO en prod peut se comporter différemment du SSO en dev (URL de callback, certificats, durées de session). Prévoyez un test complet en préprod avec les vrais certificats de prod avant le basculement.
Piège 4 : oublier les utilisateurs externes (consultants, auditeurs) Les comptes invités B2B d’Entra ID permettent de leur donner un accès temporaire sans créer de compte local dans l’ERP. Exploitez cette fonctionnalité plutôt que de créer des comptes locaux “provisoires” qui ne sont jamais supprimés.
Piège 5 : négliger la rotation des certificats Les métadonnées SAML contiennent un certificat X.509 avec une date d’expiration. Si ce certificat expire, le SSO tombe. Planifiez le renouvellement 90 jours à l’avance et testez le processus au moins une fois.
Checklist de mise en oeuvre en 7 étapes
- Inventorier les ERP concernés : quels modules, quelles versions, quels hébergements (cloud/on-premise).
- Vérifier les licences Entra ID : Microsoft 365 Business Premium ou E3/E5 incluent Entra ID P1, suffisant pour le Conditional Access basique. Les politiques avancées (Identity Protection, Privileged Identity Management) nécessitent Entra ID P2.
- Cartographier les groupes et les rôles : définir la correspondance entre les groupes Active Directory existants et les profils ERP avant toute configuration.
- Configurer l’application d’entreprise dans Entra ID : une application par ERP, avec le protocole adapté (SAML pour SAP IAS, OIDC pour Business Central, SAML ou OIDC pour Odoo).
- Tester le SSO sur un groupe pilote : 5 à 10 utilisateurs volontaires, profils variés, avant déploiement généralisé.
- Déployer les politiques Conditional Access : MFA hors réseau, blocage géographique, règles par rôle sensible.
- Activer SCIM si disponible : synchroniser le cycle de vie des comptes ERP depuis Entra ID/SIRH dès le go-live, pas en phase 2.
Ce qu’il faut anticiper pour 2027
Microsoft Entra ID pousse activement vers l’authentification sans mot de passe (Passkeys, Windows Hello for Business, Microsoft Authenticator passwordless). Pour les ERP supportant ces mécanismes, c’est la prochaine étape naturelle après le SSO+MFA.
La directive NIS2, pleinement applicable en France, va renforcer les exigences d’audit de la gestion des identités. Avoir un SSO centralisé et un provisioning SCIM opérationnel place vos preuves de conformité dans un seul système d’enregistrement, ce qui simplifie considérablement la préparation des audits.
Pour aller plus loin sur la sécurité des accès ERP, consultez notre guide IAM/PAM/MFA Zero Trust pour ERP et la checklist NIS2 des preuves ERP à préparer pour un audit. Pour les enjeux de gouvernance et conformité qui encadrent ces choix, voir aussi notre article sur la gouvernance ERP, risques et conformité.
Téléchargez notre grille d’évaluation ERP : 30 critères sur 100 points pour comparer trois solutions côte à côte, avec une section dédiée aux fonctionnalités IAM/SSO.
