Azure rencontre SAP : SAP on Azure expliqué pour Microsoft Teams

By Mirko Peters · 2026-11-05

Ce que signifie réellement faire tourner SAP sur Microsoft Azure : machines virtuelles et stockage certifiés, la zone d’atterrissage à construire en premier, la connectivité hybride, les trois chemins de déploiement et les erreurs qui transforment un système SAP pris en charge en système non pris en charge.

Automatically translated with AI from the original post. Read the English original

En tant que Microsoft MVP, je passe la plupart de mon temps avec des personnes qui connaissent Azure, Entra ID et Microsoft 365 sur le bout des doigts, et à qui l’on demande soudain de « soutenir le chantier SAP ». Pour beaucoup d’entre elles, SAP ressemble à un univers à part, avec son propre vocabulaire. La bonne nouvelle : SAP sur Azure est bien plus banal qu’il n’y paraît. Tout tient à deux règles. Rester dans des configurations certifiées, et construire les fondations avant l’arrivée du premier système SAP. Cet article les détaille, dans l’ordre où vous les appliqueriez réellement.

Ce que signifie réellement SAP sur Azure

SAP sur Azure signifie que vos systèmes SAP s’exécutent sur Microsoft Azure. La base de données SAP HANA, les serveurs d’application et les services centraux reposent sur des machines virtuelles Azure et utilisent le stockage et le réseau Azure. Le logiciel SAP lui-même ne change pas : SAP S/4HANA reste S/4HANA, SAP NetWeaver reste NetWeaver. Seul le socle sous-jacent change.

Cette répartition indique qui est responsable de quoi. Microsoft fournit la plateforme : machines virtuelles, disques, réseaux, identité et supervision. SAP fournit l’application et la base de données, que vous exploitez selon les exigences de SAP. Le point de rencontre entre les deux est l’infrastructure certifiée qui se trouve au milieu.

Il est utile de distinguer cela d’un sujet connexe. Copier des données SAP dans Azure pour alimenter des rapports Power BI ou Microsoft Fabric relève de l’intégration de données, une tâche utile mais différente. Faire fonctionner SAP sur Azure signifie que le système de production lui-même y réside, traite ses transactions et sert ses utilisateurs depuis cet environnement.

Si vous souhaitez d’abord avoir une vue d’ensemble de la famille de produits SAP, la page thématique SAP sur M365.FM rassemble nos contenus associés.

Pourquoi le mot « certifié » décide de tout

Dans l’univers SAP, « fonctionner sur Azure » signifie réellement « fonctionner sur un Azure certifié ». SAP et Microsoft testent des types de machines virtuelles et des options de stockage spécifiques pour des produits et scénarios SAP précis, et seules ces combinaisons sont prises en charge. Microsoft documente les certifications et configurations SAP pour Azure ainsi que les logiciels SAP pris en charge sur Azure. Pour SAP HANA, le SAP HANA Hardware Directory de SAP fait autorité ; pour les systèmes basés sur NetWeaver, la note SAP 1928533 répertorie les types de machines virtuelles Azure pris en charge.

La certification n’est pas une propriété d’Azure dans son ensemble. Elle concerne une machine virtuelle précise, une option de stockage précise et un scénario SAP précis, alignés ensemble. Une machine virtuelle généreuse, parfaite pour une application web, peut tout simplement ne pas figurer sur la liste pour HANA. Si vous la choisissez quand même, vous n’avez pas fait d’économies : vous avez bâti un système que ni l’un ni l’autre des éditeurs ne sera tenu de soutenir.

La logique est la même pour le stockage. Les disques managés Azure sont le bloc de base du quotidien, Azure NetApp Files fournit un stockage NFS utilisé dans plusieurs architectures SAP, et Azure Files sur un stockage premium (SSD) peut héberger des répertoires partagés. Le niveau standard, moins cher, d’Azure Files n’est pas pris en charge pour les partages de haute disponibilité des services centraux SAP ; l’option économique est donc la mauvaise option dans ce cas. Microsoft détaille ces limites dans ses scénarios pris en charge pour les charges de travail SAP sur les machines virtuelles Azure.

L’habitude qui évite la plupart des problèmes : avant de dimensionner la moindre machine, consultez la liste certifiée pour votre produit SAP et votre scénario, et concevez en fonction de celle-ci.

La zone de destination à construire en premier

Une zone de destination Azure est la fondation qui apporte à chaque charge de travail son identité, son réseau, sa sécurité et sa gouvernance avant tout déploiement. Le Cloud Adoption Framework de Microsoft la divise en deux parties :

• Zone de destination de plateforme : la base partagée, avec les groupes d’administration, la connectivité centrale, l’identité, la sécurité et les services de gestion.
• Zones de destination d’applications (charges de travail) : les environnements individuels, généralement de développement, de test et de production, constitués d’abonnements qui héritent des garde-fous de la plateforme.

Pour SAP, cet aspect compte davantage que pour la plupart des charges de travail, car SAP porte la finance, la chaîne d’approvisionnement et les opérations. Les stratégies, les règles réseau et l’identité doivent exister avant l’arrivée du premier système SAP. Les ajouter après revient à déplacer des ressources au sein d’un système métier en production.

Microsoft propose un accélérateur de zone de destination SAP sur Azure comprenant des conceptions de référence fondées sur une topologie réseau en hub-and-spoke ou sur Azure Virtual WAN. Azure Policy et la hiérarchie des groupes d’administration définissent les garde-fous, et chaque système SAP s’installe ensuite dans ce cadre. C’est ce qui permet l’arrivée du deuxième et du troisième système SAP sans nouveau débat sur les conventions de nommage, les accès et les règles réseau.

Garder SAP connecté à votre centre de données

Migrer SAP vers Azure ne signifie que rarement tout abandonner. La plupart des environnements restent hybrides pendant longtemps ; la connectivité est donc le pont qui les relie.

L’option privée principale est Azure ExpressRoute, une connexion privée dédiée entre votre centre de données et Azure, au lieu d’un trafic passant par l’internet public. Lorsque ExpressRoute n’est pas disponible, un VPN site à site constitue l’alternative. Dans les deux cas, la connexion aboutit généralement dans le hub central ou dans Virtual WAN, et le réseau virtuel SAP l’atteint depuis ce point. Au sein d’Azure, une conception SAP type sépare les niveaux application et base de données dans leurs propres sous-réseaux, protégés par des groupes de sécurité réseau, des tables de routage et un pare-feu.

L’identité mérite une attention particulière, car c’est là que les équipes Microsoft font souvent des hypothèses. Microsoft Entra ID est excellent pour l’authentification unique aux applications SAP. Mais les systèmes SAP NetWeaver et S/4HANA exécutés sous Windows n’utilisent pas de comptes Entra ID pour l’application SAP elle-même. Ils attendent toujours Active Directory Domain Services, soit étendu depuis l’environnement local, soit fourni par Microsoft Entra Domain Services. L’ouverture de session et l’annuaire du système d’exploitation sont deux sujets distincts.

Vos trois options de déploiement

Il n’existe pas de manière unique de déployer SAP sur Azure. Choisissez la voie qui correspond à la façon dont votre équipe exploite les systèmes.

1. Machines virtuelles Azure classiques. Vous gérez vous-même le système d’exploitation, l’installation de SAP, les correctifs et la supervision. Contrôle maximal, travail maximal. Une bonne solution lorsque les compétences approfondies en SAP et Azure sont disponibles en interne.
2. Azure Center for SAP solutions. Un service Azure qui fait de SAP une charge de travail de premier plan. Il peut créer l’infrastructure et installer le logiciel SAP pour des systèmes sur un seul serveur, distribués et distribués à haute disponibilité, ou enregistrer des systèmes SAP qui fonctionnent déjà sur Azure. Chaque système devient une instance virtuelle pour les solutions SAP, une vue logique du SID, des services centraux, de la base de données et des serveurs d’application. Depuis cette vue, vous consultez l’état de santé et le statut, démarrez et arrêtez le système, exécutez des contrôles de qualité basés sur les bonnes pratiques et suivez les données de supervision. Les détails figurent dans l’aperçu d’Azure Center for SAP solutions.
3. Infrastructure d’automatisation de déploiement SAP sur Azure. Une approche open source d’infrastructure as code, destinée aux équipes qui souhaitent des déploiements reproductibles, versionnés et intégrés à un flux DevOps.

Une règle de décision simple : un contrôle total et des compétences solides orientent vers des machines virtuelles classiques ; une configuration guidée avec un point unique de gestion du système orientent vers Azure Center for SAP solutions ; de nombreux systèmes déployés de la même manière orientent vers l’infrastructure d’automatisation.

Erreurs courantes

Les premières migrations les plus douloureuses suivent souvent le même schéma : une étape qui semblait facultative.

• Considérer la certification comme une simple formalité. Une machine virtuelle ou un type de stockage non certifié transforme un système pris en charge en système non pris en charge, et vous vous en apercevez généralement au pire moment.
• Faire l’impasse sur la zone d’atterrissage. « Nous ajouterons la gouvernance plus tard » se réalise rarement, et reconfigurer les règles d’identité et de réseau autour d’un système SAP en production est lent et risqué.
• Supposer qu’Entra ID remplace Active Directory pour les systèmes SAP basés sur Windows. Ce n’est pas le cas.
• Concevoir la connectivité en dernier. Répartir la couche applicative SAP et la couche base de données entre un environnement local et Azure, ou entre plusieurs régions Azure, n’est pas pris en charge.
• Supposer que tout fonctionne sur Azure. Azure VMware Solution n’est généralement pas une plateforme prise en charge pour héberger des charges de travail SAP, et les SAP HANA Large Instances ne sont plus proposées aux nouveaux clients.
• Utiliser Azure Site Recovery pour la base de données. Azure Site Recovery n’est pas pris en charge pour la couche base de données SAP ; utilisez la réplication native de la base de données, comme SAP HANA System Replication, pour la reprise après sinistre.

Chacun de ces points marque une limite où les périmètres de support de Microsoft et de SAP cessent de coïncider. Ces limites ne sont pas là pour vous ralentir ; elles délimitent le périmètre dans lequel les deux éditeurs garantiront votre système.

Conclusion : l’ordre des opérations

Si vous ne retenez qu’une chose, retenez la séquence. Définissez les besoins du système SAP en performance, disponibilité et reprise. Construisez la zone d’atterrissage. Reliez le réseau et l’annuaire à votre centre de données. Choisissez le niveau de gestion souhaité : machines virtuelles classiques, Azure Center for SAP solutions ou infrastructure d’automatisation. Sélectionnez un calcul et un stockage certifiés. Puis concevez la haute disponibilité et la reprise après sinistre en vous appuyant sur les capacités propres à la base de données.

Vous n’êtes pas obligé de tout migrer d’un coup. Commencer par un seul système révèle où votre zone d’atterrissage est fragile et où votre équipe a besoin d’accompagnement, alors que les enjeux restent limités. Pour les professionnels Microsoft, SAP sur Azure n’est pas un univers étranger. C’est un ensemble de décisions d’ingénierie tout à fait classiques, avec la certification comme seule règle à ne jamais enfreindre.