Azure Arc ou Azure Local : clarifier la terminologie de l’infrastructure hybride de Microsoft

By Mirko Peters · 2026-08-22

Bienvenue dans le podcast ! Si vous suivez nos derniers épisodes sur l’architecture informatique moderne des entreprises, vous savez que nous consacrons beaucoup de temps aux stratégies de cloud hybride…

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

Bienvenue dans le podcast ! Si vous suivez nos derniers épisodes sur l’architecture informatique moderne des entreprises, vous savez que nous consacrons beaucoup de temps aux stratégies de cloud hybride. Récemment, j’ai reçu un excellent courriel d’un auditeur nommé Marcus, à Chicago. Marcus m’écrivait : « Je tente de concevoir la future infrastructure de notre entreprise, mais à chaque fois que je lis un livre blanc de Microsoft, je me perds dans le jargon marketing. Quelle est la différence réelle entre Azure Arc et Azure Local ? Sont-ce des produits concurrents ? En ai-je besoin de les deux ? »

Marcus, vous n’êtes certainement pas seul. Microsoft propose aujourd’hui l’un des écosystèmes hybrides les plus complets du marché, mais cette richesse s’accompagne d’une quantité vertigineuse de terminologie. Les termes changent de nom, les acronymes évoluent, et les administrateurs informatiques comme les architectes cloud se retrouvent vite désorientés, à tenter de comprendre quel outil fait quoi. C’est précisément la raison pour laquelle je souhaite consacrer cet article à la décomposition de ces deux piliers essentiels de la stratégie hybride de Microsoft. À la fin de cet article, vous comprendrez parfaitement ce qu’est Azure Arc, ce qu’est Azure Local, en quoi ils diffèrent et, surtout, comment ils peuvent fonctionner ensemble pour optimiser votre infrastructure.

Introduction à l’évolution hybride de Microsoft

Pour comprendre la place d’Azure Arc et d’Azure Local aujourd’hui, il faut revenir brièvement en arrière. Pendant des décennies, l’informatique d’entreprise était binaire : vos charges de travail résidaient soit sur vos propres serveurs physiques, dans un centre de données local, soit dans le centre de données de quelqu’un d’autre. Puis la révolution du cloud public, portée par Microsoft Azure, Amazon Web Services et Google Cloud Platform, a vu le jour. Soudain, les organisations se précipitaient pour migrer tout vers le cloud, en promettant une évolutivité infinie et une réduction des dépenses d’investissement.

Toutefois, la réalité ne tarda pas à rattraper les discours. Les entreprises ont compris que tout n’a pas sa place dans le cloud public. Les exigences réglementaires, les lois sur la souveraineté des données, les besoins de latence ultra-faible en périphérie du réseau et les applications héritées qui ne peuvent tout simplement pas être refactorisées facilement ont fait que l’infrastructure sur site ne disparaîtrait pas. Dans le même temps, les organisations ne voulaient pas renoncer aux capacités de gestion, aux outils de sécurité et aux gains de productivité des développeurs qu’elles avaient appris à apprécier dans Azure.

Ce constat a ouvert l’ère du cloud hybride. Microsoft a très tôt compris que l’avenir ne résidait pas uniquement dans le cloud public, mais dans un continuum fluide allant de la périphérie au centre de données, jusqu’au cloud. Au fil des années, Microsoft a développé différents outils pour combler cet écart. Certains visaient à gérer le matériel existant, d’autres à le moderniser entièrement. C’est ce qui nous amène aux deux sujets principaux d’aujourd’hui : Azure Arc, qui assure la gestion et le contrôle, et Azure Local, qui fournit la véritable fondation d’infrastructure hyperconvergée.

Décrypter la terminologie : qu’est-ce qu’Azure Arc ?

Commençons par Azure Arc. Si vous ne retenez qu’une seule phrase de cette section, retenez celle-ci : Azure Arc est un plan de contrôle, et non un produit d’infrastructure.

Imaginez Azure Arc comme une baguette magique qui étend le plan de contrôle Azure — la même interface de gestion que celle que vous utilisez pour administrer les machines virtuelles, les bases de données et les clusters Kubernetes dans le cloud public Azure — jusque dans vos propres centres de données, vos sites en périphérie, et même chez des concurrents comme AWS et Google Cloud Platform.

Le fonctionnement interne d’Azure Arc

Concrètement, Azure Arc installe des agents légers sur vos ressources existantes, quel que soit leur emplacement. Qu’il s’agisse d’un serveur Linux physique installé dans un rack à Francfort, d’une machine virtuelle VMware dans votre bureau local de Chicago ou d’une instance Amazon EC2, Azure Arc relie cette ressource à Azure. Une fois connectée, cette ressource externe est projetée dans Azure Resource Manager (ARM). Ainsi, vos serveurs non Azure apparaissent directement aux côtés de vos machines virtuelles Azure natives dans le portail Azure.

Cette projection donne accès à un ensemble important de fonctionnalités cloud natives pour une infrastructure qui ne touche jamais réellement le cloud Azure :

• Gouvernance et conformité unifiées : vous pouvez appliquer Azure Policy à vos serveurs sur site afin de garantir que les configurations restent conformes à l’ensemble de votre parc.
• Sécurité avancée : Microsoft Defender for Cloud peut être étendu pour surveiller les menaces et les vulnérabilités de vos serveurs non Azure et de vos clusters Kubernetes.
• Surveillance native du cloud : Azure Monitor peut collecter les journaux et les métriques de votre infrastructure locale, vous offrant une vue unique pour l’observabilité.
• Services activés par Arc : vous pouvez même exécuter Azure SQL Managed Instance et Azure PostgreSQL sur votre propre infrastructure locale, entièrement gérés via le plan de contrôle Azure.

Fait essentiel : Azure Arc se moque de l’hyperviseur sous-jacent. Il ne remplace ni votre configuration VMware, Hyper-V ni vos serveurs physiques bare-metal. Il ajoute simplement une couche de gestion intelligente à ce que vous avez déjà.

Décryptage de la terminologie : qu’est-ce qu’Azure Local ?

Maintenant que nous avons compris Azure Arc comme couche de gestion, passons au volet infrastructure : Azure Local. Si Azure Arc est le plan de contrôle défini par logiciel qui couvre tous les environnements, Azure Local est une solution d’infrastructure hyperconvergée (HCI) conçue pour exécuter des charges de travail localement, dans votre datacenter ou en périphérie de réseau.

Vous connaissez peut-être cette technologie sous son ancien nom : Azure Stack HCI. Microsoft a récemment renommé et rationalisé cette offre sous la bannière Azure Local, afin de mieux l’aligner sur sa mission principale. Azure Local fournit une plateforme moderne de calcul, de stockage et de réseau définie par logiciel, que vous exécutez sur des appliances matérielles validées directement dans vos locaux.

L’architecture d’Azure Local

Azure Local associe les technologies de Windows Server à un logiciel hyperconvergé avancé pour offrir des capacités de virtualisation et de stockage de niveau entreprise. Il utilise Hyper-V pour la virtualisation et Storage Spaces Direct pour un stockage défini par logiciel à hautes performances.

Ce qui rend Azure Local véritablement unique, c’est son intégration native et profonde avec le cloud public Azure, dès la conception. Alors que les plateformes de virtualisation traditionnelles nécessitent des outils tiers pour se connecter au cloud, Azure Local est conçu pour être connecté au cloud par défaut. Il vous permet d’exécuter des machines virtuelles Windows et Linux familières, ainsi que des clusters Azure Kubernetes Service (AKS), localement, sur un matériel que vous possédez et exploitez physiquement.

Les principales fonctionnalités d’Azure Local sont les suivantes :

• Haute disponibilité et résilience : le clustering intégré et la réplication du stockage garantissent que vos charges de travail locales restent opérationnelles, même en cas de défaillance matérielle.
• Formats physiques flexibles : des nœuds de périphérie robustes déployés dans les magasins ou les usines jusqu’aux clusters multinœuds de grande taille dans les datacenters d’entreprise, Azure Local s’adapte à l’espace physique dont vous disposez.
• Virtualisation familière : si vos équipes connaissent déjà Hyper-V ou les concepts généraux de virtualisation, l’adoption d’Azure Local présente une courbe d’apprentissage très douce.

Différences clés entre gestion et infrastructure

Lorsque des auditeurs me demandent de comparer Azure Arc et Azure Local, mon premier objectif est toujours de corriger la prémisse de la question. Comparer Azure Arc à Azure Local revient un peu à comparer une télécommande à un téléviseur. Ce ne sont pas des technologies concurrentes ; elles opèrent à des niveaux totalement différents de la pile informatique.

Détaillons les différences fondamentales selon quelques dimensions clés :

1. Couche de la pile

Azure Arc se situe entièrement au niveau de la couche de gestion et du plan de contrôle. C’est un service cloud qui vous permet d’organiser, de gouverner et de sécuriser les ressources. Azure Local se situe au niveau de la couche infrastructure et calcul. C’est un système d’exploitation et une plateforme hyperconvergée qui fournit les ressources physiques et virtuelles de calcul et de stockage où vos applications s’exécutent réellement.

2. Dépendance matérielle

Comme Azure Arc n’est qu’un outil de gestion basé sur un agent, il ne dépend pratiquement d’aucun matériel spécifique. Vous pouvez installer l’agent Arc sur un serveur Dell vieux de cinq ans fonctionnant avec une version ancienne de Linux, sur un serveur HPE tout neuf sous Windows, ou même sur une machine virtuelle hébergée dans AWS. Azure Local, en revanche, nécessite du matériel spécifique et validé par les partenaires matériels de Microsoft. Vous ne pouvez pas simplement installer Azure Local sur n’importe quel équipement disponible dans votre salle serveur : il exige des nœuds de cluster certifiés afin de garantir les performances, la fiabilité et la prise en charge.

3. Objectif principal

Azure Arc a pour objectif la gestion unifiée, en apportant de la cohérence à un patrimoine informatique fragmenté, multicloud et sur site. Azure Local a pour objectif la modernisation de l’infrastructure locale : une plateforme HCI native du cloud pour exécuter des charges de travail virtualisées et conteneurisées directement là où les données sont produites.

Quand utiliser Azure Arc ou Azure Local

Maintenant que nous avons défini le rôle de chacun de ces outils, parlons de la prise de décision. Lors de vos sessions de planification d’architecture, comment savez-vous quand recourir à Azure Arc et quand déployer Azure Local ?

Quand utiliser Azure Arc

Vous devez déployer Azure Arc lorsque vous souhaitez étendre les capacités de gestion d’Azure à une infrastructure que vous possédez déjà et que vous n’envisagez pas de remplacer à court terme. Par exemple :

• Vous disposez d’un investissement considérable dans des serveurs VMware ou Linux physiques répartis dans plusieurs centres de données à travers le monde, et vous souhaitez disposer d’une vue unique dans le portail Azure pour gérer la conformité, surveiller les journaux et appliquer des stratégies.
• Vous exécutez des clusters Kubernetes sur AWS ou Google Cloud, et vous souhaitez utiliser Azure GitOps et Azure Policy pour gérer les déploiements sur l’ensemble de ces clouds simultanément.
• Vous souhaitez exécuter des services de données Azure, comme Azure SQL Managed Instance, sur site sans migrer l’intégralité de votre couche de virtualisation sous-jacente.

Quand utiliser Azure Local

Vous devez déployer Azure Local lorsque vous souhaitez renouveler une infrastructure locale vieillissante ou mettre en place un nouvel environnement de périphérie (edge computing), et que vous voulez que cette infrastructure locale se comporte comme une extension du cloud Azure :

• Votre pile SAN et de virtualisation traditionnelle arrive en fin de vie, et vous souhaitez la remplacer par une infrastructure hyperconvergée définie par logiciel, qui s’intègre nativement à la sauvegarde, à la reprise après sinistre et à la supervision d’Azure.
• Vous avez besoin de ressources de calcul et de stockage à faible latence sur un site de périphérie, comme un hôpital, un magasin ou une usine, où les données doivent être traitées localement, tout en souhaitant gérer ces charges de travail de manière centralisée depuis le cloud Azure.
• Vous souhaitez exécuter Azure Kubernetes Service (AKS) sur site, avec une prise en charge complète et une intégration fluide dans vos pipelines de déploiement cloud existants.

Comment ils fonctionnent ensemble dans une stratégie hybride

C’est là que la magie opère vraiment. Bien qu’Azure Arc et Azure Local soient des produits distincts, Microsoft les a conçus pour être encore plus efficaces ensemble. En effet, les clusters Azure Local sont automatiquement activés avec Azure Arc par défaut !

Lorsque vous déployez un cluster Azure Local dans votre centre de données, l’infrastructure sous-jacente est gérée localement, mais son plan de contrôle est entièrement intégré à Azure Arc. Cela signifie que vous n’avez pas besoin d’installer des agents distincts ni de configurer des tunnels complexes pour gérer votre infrastructure Azure Local : elle apparaît nativement dans votre abonnement Azure dès son initialisation.

Examinons un scénario hybride réel pour voir comment cette synergie se concrétise. Imaginez une grande entreprise mondiale de logistique :

1. En périphérie : l’entreprise exploite des centaines de centres de préparation de commandes dans le monde. Dans chacun de ces centres, elle déploie de petites appliances Azure Local à deux nœuds pour traiter les étiquettes d’expédition, exécuter des instances de bases de données locales et gérer les systèmes d’automatisation des entrepôts avec une latence ultra-faible.
2. À l’échelle de l’entreprise : elle dispose également de centres de données historiques exploitant un mélange de serveurs VMware et physiques, ainsi que certaines charges de travail hébergées dans AWS. Elle installe des agents Azure Arc sur l’ensemble de ces environnements afin d’appliquer des lignes de base de sécurité et de suivre la conformité.
3. Gestion unifiée : Depuis le portail Azure, l’équipe informatique centrale peut consulter l’état des centres de traitement en périphérie (exécutés sur Azure Local) aux côtés de vos instances AWS et de vos serveurs existants (gérés via Azure Arc). Elle utilise Azure Policy pour garantir le respect des normes de chiffrement partout, et Azure Monitor pour suivre les indicateurs de performance à l’échelle mondiale.

Dans cette architecture, Azure Local fournit le socle résilient et haute performance en périphérie, tandis qu’Azure Arc assure la gouvernance globale et le plan de contrôle qui relie l’ensemble du patrimoine hybride.

Conclusion : simplifier votre parcours vers le cloud hybride

Se repérer dans l’écosystème hybride de Microsoft peut sembler intimidant au premier abord, mais une fois la terminologie associée à des couches d’architecture précises, tout s’éclaire. Retenez la règle d’or : Azure Arc est votre plan de contrôle de gestion pour tout, partout, tandis qu’Azure Local est votre infrastructure hyperconvergée moderne pour les charges de travail locales et en périphérie.

Lorsque vous planifiez l’architecture de votre entreprise pour l’année à venir, ne considérez pas ces technologies comme un choix exclusif. Observez plutôt comment elles se complètent. Utilisez Azure Arc pour unifier et gouverner vos investissements informatiques hétérogènes existants, et tirez parti d’Azure Local lorsque vous souhaitez moderniser votre infrastructure sur site et en périphérie avec l’agilité propre au cloud natif.

J’espère que cette analyse approfondie dissipera la confusion autour de la terminologie hybride de Microsoft. Comme toujours, nous serions ravis de connaître votre avis. Utilisez-vous déjà Azure Arc dans vos environnements multicloud ? Avez-vous déployé Azure Local sur vos sites en périphérie ? Laissez un commentaire ci-dessous ou écrivez-nous pour notre prochain épisode de courrier des lecteurs. À bientôt, et continuez à concevoir l’avenir !