Le DSI souhaite conserver ses serveurs on-premises tout en utilisant Azure pour gérer les pics de charge. Quel modèle de déploiement cloud est le plus adapté, et pourquoi ?

Le modèle de cloud hybride est le plus adapté à la situation de Metalux SA. Ce modèle permet de conserver l'infrastructure existante on-premises (les 100 serveurs physiques, notamment pour l'ERP sensible) tout en utilisant le cloud public Azure pour ajouter des ressources à la demande lors des pics de charge saisonniers, sans investissement matériel supplémentaire. Ce modèle évite une migration totale risquée, respecte les contraintes de souveraineté des données et offre la flexibilité d'élasticité côté cloud. L'élasticité d'Azure permettra d'augmenter ou de réduire automatiquement les ressources en fonction de la charge réelle, optimisant ainsi les coûts opérationnels.

Pour gérer les 40 VMs de test hebdomadaires déployées et supprimées par l'équipe DevOps, quel service Azure est le plus approprié et quels avantages offre-t-il ?

Azure DevTest Labs est le service le plus approprié pour ce besoin. Il est conçu spécifiquement pour les environnements temporaires de développement et de test, permettant de créer et supprimer rapidement des machines virtuelles de manière automatisée et contrôlée. DevTest Labs offre des politiques de coûts (budget par lab, arrêt automatique des VMs), des modèles de VM réutilisables pour accélérer les déploiements, et une gestion des quotas par utilisateur. Cela répond exactement au besoin de l'équipe DevOps de 8 développeurs qui doit déployer 40 VMs chaque semaine sans processus manuel lourd, tout en maîtrisant les dépenses cloud associées.

La direction souhaite que chaque département dispose de son propre suivi budgétaire et d'options de facturation séparées. Quelle structure Azure recommandez-vous et comment surveiller les dépassements de budget ?

Il est recommandé de créer un abonnement Azure distinct pour chacun des 5 départements. Un abonnement Azure est l'unité de facturation et de paiement dans Azure : créer un abonnement par département permet d'utiliser des options de paiement différentes, d'isoler les coûts par entité et de déléguer l'administration à un responsable par département. Pour surveiller les dépenses, il faut mettre en place des alertes de budget via Azure Cost Management (Azure Budgets) : on définit un seuil de coût (par exemple 3 000 € par abonnement départemental), et des notifications sont envoyées en temps réel lorsque les dépenses approchent ou dépassent la limite fixée, permettant une réaction proactive avant tout dépassement du budget global de 15 000 €.

Pour distribuer le trafic entre les deux régions Azure et assurer la continuité de service en cas de panne d'une région, quel service Azure faut-il utiliser et comment fonctionne-t-il ?

Azure Traffic Manager est le service adapté à ce besoin. C'est un service de routage DNS global qui permet de distribuer le trafic entre des applications déployées dans plusieurs régions Azure. En cas de panne d'une région (par exemple France Centre), Traffic Manager détecte automatiquement l'indisponibilité via ses sondes de santé et redirige l'ensemble du trafic vers la région disponible (Europe Ouest), assurant ainsi la continuité de service. Plusieurs méthodes de routage sont disponibles : priorité, performance (latence minimale), pondération ou géographique. Pour E-Commerce Plus, une configuration en mode Performance permettrait de router chaque utilisateur vers la région offrant la meilleure latence, tout en basculant automatiquement en cas de défaillance. Ce service contribue directement à atteindre le SLA de 99,9 % requis.

L'équipe technique souhaite suivre le comportement des utilisateurs (pages vues, taux d'abandon de panier, temps de réponse) sur l'application .NET Core. Quel service Azure répond à ce besoin et quelles fonctionnalités clés offre-t-il ?

Application Insights est le service Azure approprié pour ce besoin. Il fournit des fonctionnalités de télémétrie applicative et d'analyse d'usage, notamment : le suivi des utilisateurs (sessions, pages vues, flux de navigation), l'analyse des performances (temps de réponse des requêtes, dépendances externes), la détection d'anomalies et d'exceptions, ainsi que des entonnoirs de conversion permettant d'identifier les étapes où les utilisateurs abandonnent (comme le panier). Application Insights s'intègre nativement avec les applications .NET Core hébergées sur Azure Web Apps, sans modification majeure du code. Pour E-Commerce Plus, cela permettrait de mesurer précisément l'impact des pics de trafic x8 sur les temps de réponse et d'identifier les goulots d'étranglement avant qu'ils n'entraînent une panne comme celle ayant coûté 120 000 €.

Le SLA Azure garantit un taux de disponibilité de 99,9 % pour Azure Web Apps. Que se passe-t-il concrètement si Microsoft ne respecte pas ce niveau de service, et quelle est la limite de ce SLA pour l'architecture d'E-Commerce Plus ?

Un SLA Azure garantit un pourcentage de disponibilité (uptime) pour un service donné sur une période définie. Si ce niveau de disponibilité n'est pas respecté, Microsoft accorde des crédits de service (remises sur facture) proportionnels à la durée d'indisponibilité. Par exemple, en dessous de 99,9 %, des crédits de 10 % à 30 % de la facture mensuelle du service concerné peuvent être accordés. Cependant, le SLA présente une limite importante pour E-Commerce Plus : il ne garantit pas l'absence de panne, mais uniquement une compensation financière après coup. De plus, le SLA s'applique par service individuellement — le SLA composite de l'architecture complète (Web App + Traffic Manager + base de données) sera toujours inférieur au SLA de chaque composant pris séparément. C'est pourquoi l'architecture multi-régions avec Traffic Manager est essentielle pour dépasser les garanties contractuelles de base et éviter une nouvelle perte de 120 000 €.

Le DSI souhaite imposer des règles de sécurité identiques à tous les établissements depuis un point de contrôle central, sans gérer chaque abonnement individuellement. Quelle structure Azure recommandez-vous et quel rôle RBAC est nécessaire pour appliquer des Azure Policies à ce niveau ?

Il est recommandé de mettre en place des Management Groups (groupes d'administration) Azure. Les management groups permettent d'organiser plusieurs abonnements Azure sous une hiérarchie commune et d'appliquer des Azure Policies et des affectations RBAC à l'ensemble des abonnements enfants en une seule opération. Le GHR pourrait créer un management group racine 'GHR' regroupant les 6 abonnements des établissements, avec éventuellement des sous-groupes géographiques. Concernant le rôle RBAC nécessaire : seul le rôle Owner (Propriétaire) au niveau du management group permet à la fois de gérer les ressources ET d'assigner des Azure Policies. Les rôles User Access Administrator ou Managed Identity Operator ne permettent pas d'assigner des policies. Le DSI du groupe devrait donc se voir attribuer le rôle Owner au niveau du management group racine pour centraliser la gouvernance.

Pour sécuriser les accès aux ressources sensibles (dossiers patients, données RH), le groupe souhaite que les administrateurs n'aient des droits élevés que lorsque c'est strictement nécessaire. Quel service Azure répond à ce besoin et comment fonctionne-t-il ?

Azure Privileged Identity Management (PIM) est le service adapté à cette exigence. PIM permet d'attribuer des rôles Azure de manière temporaire (Just-In-Time), c'est-à-dire qu'un administrateur ne dispose de droits élevés (comme Contributeur ou Propriétaire) que pendant une durée limitée et définie, uniquement lorsque cela est nécessaire. Le processus typique est : l'administrateur fait une demande d'élévation de privilèges, justifie la raison, obtient une approbation (manuelle ou automatique), et dispose des droits pendant une fenêtre de temps paramétrable (ex. 1 à 8 heures). À l'expiration, les droits sont automatiquement révoqués. Pour le GHR, cela réduit considérablement la surface d'attaque en cas de compromission d'un compte administrateur, et génère un historique d'audit complet de toutes les élévations de privilèges, répondant ainsi aux exigences réglementaires HDS et RGPD.

Pour les besoins d'audit réglementaire, le GHR doit être capable de répondre à la question : 'Qui a supprimé le groupe de ressources contenant les données de l'établissement X le 15 mars à 14h32 ?' Quel service Azure permet de retrouver cette information et que contient-il exactement ?

Azure Activity Log est le service qui permet de répondre à cette question. L'Activity Log enregistre toutes les actions effectuées sur les ressources Azure au niveau de l'abonnement, notamment : qui a effectué l'action (utilisateur ou service principal), quelle action a été réalisée (création, modification, suppression), sur quelle ressource et à quel moment précis (horodatage). Dans le cas du GHR, l'Activity Log de l'abonnement correspondant à l'établissement X contiendrait une entrée indiquant l'identité exacte de l'utilisateur ayant supprimé le groupe de ressources, son adresse IP, l'heure précise et le résultat de l'opération. Les logs d'activité sont conservés 90 jours par défaut dans Azure, mais peuvent être archivés vers un compte de stockage ou un espace de travail Log Analytics pour une rétention longue durée répondant aux exigences d'audit réglementaire du secteur hospitalier.

DataFlow Analytics souhaite héberger sa plateforme SaaS uniquement avec des services PaaS, sans gérer de serveurs. Quels services Azure correspondent à ce modèle pour héberger l'application web et la base de données, et quelles responsabilités restent à la charge de l'équipe ?

Pour respecter la contrainte PaaS exclusive, DataFlow Analytics doit utiliser Azure App Service pour héberger l'application web et Azure SQL Database pour la base de données relationnelle. Ces deux services sont des ressources PaaS : Azure gère entièrement l'infrastructure sous-jacente (serveurs physiques, système d'exploitation, mises à jour, haute disponibilité, sauvegardes automatiques). L'équipe de DataFlow conserve uniquement la responsabilité du code applicatif, des données et de la configuration des services. Contrairement à une machine virtuelle Azure (qui est IaaS et nécessite la gestion de l'OS), App Service et Azure SQL Database permettent à l'équipe de 12 développeurs de se concentrer sur le développement produit, réduisant la charge d'administration bien en dessous des 15 % fixés par le CTO. Dans un modèle SaaS (pour leurs propres clients), la haute disponibilité et l'infrastructure sont gérées intégralement par le fournisseur cloud.

Les journaux d'événements de la plateforme doivent être chargés automatiquement chaque semaine dans Azure SQL Database. Quel service Azure permet d'automatiser ce flux de données et pourquoi est-il adapté à ce besoin ?

Azure Data Factory est le service adapté à ce besoin d'intégration de données. C'est un service d'intégration et d'orchestration de données qui permet d'automatiser des flux de données, de planifier des chargements périodiques (scheduling) et de connecter des sources hétérogènes (fichiers de logs, stockage blob, bases de données). Pour DataFlow Analytics, Data Factory peut être configuré pour déclencher automatiquement chaque semaine un pipeline qui lit les fichiers de journaux depuis leur source (par exemple Azure Blob Storage), les transforme si nécessaire et les charge dans Azure SQL Database. Étant un service PaaS managé, Data Factory ne nécessite aucune gestion d'infrastructure et s'intègre parfaitement dans la stratégie cloud-only de la startup. Cela permet à l'équipe technique d'éviter de développer et maintenir des scripts de chargement personnalisés, réduisant d'autant la charge d'administration.

DataFlow Analytics envisage de recruter des développeurs en télétravail depuis différents pays. Un développeur macOS souhaite automatiser la création de ressources Azure via des scripts PowerShell. Est-ce techniquement possible, et quelles alternatives existent pour administrer Azure depuis n'importe quel environnement ?

Oui, c'est techniquement possible. PowerShell Core (version 6.0 et ultérieure) est multiplateforme et fonctionne sur Windows, macOS et Linux. Un développeur sur macOS peut donc installer PowerShell Core et le module Azure PowerShell (Az) pour exécuter des scripts de création de ressources Azure exactement comme sur Windows. Outre PowerShell Core sur macOS, plusieurs alternatives permettent d'administrer Azure depuis n'importe quel environnement : Azure CLI (interface en ligne de commande multiplateforme, disponible sur Windows, macOS et Linux), Azure Cloud Shell (terminal intégré directement dans le portail Azure, accessible depuis n'importe quel navigateur sans installation locale, supportant à la fois PowerShell et Bash), et le portail Azure (interface graphique web accessible depuis tout navigateur). Pour une startup avec des développeurs en télétravail international, Azure Cloud Shell est particulièrement adapté car il ne nécessite aucune configuration locale et garantit un environnement cohérent pour tous les membres de l'équipe.

L'audit a identifié plusieurs types de ressources inutilisées : adresses IP publiques non attachées, interfaces réseau (NIC) orphelines, machines virtuelles arrêtées et comptes de stockage vides. Lesquelles génèrent réellement des coûts et doivent être supprimées en priorité pour réduire la facture ?

Parmi les ressources identifiées, les adresses IP publiques inutilisées (non attachées à une ressource) sont les seules qui génèrent une facturation directe même lorsqu'elles ne sont pas utilisées : Azure facture les adresses IP publiques statiques réservées mais non associées à une ressource active. Leur suppression permet donc de réduire immédiatement les coûts Azure. Les interfaces réseau (NIC) orphelines ne génèrent aucun coût de facturation direct lorsqu'elles existent seules — les supprimer n'a donc pas d'impact sur la facture. Les machines virtuelles arrêtées (état 'Stopped' depuis le portail) continuent de consommer des ressources de calcul facturées ; elles doivent être désallouées (état 'Deallocated') ou supprimées pour stopper la facturation du compute (le stockage des disques reste facturé). Les comptes de stockage vides génèrent des coûts minimaux voire nuls selon leur configuration, mais leur suppression contribue à l'hygiène de l'environnement. La priorité absolue est donc : supprimer les IPs publiques non attachées et désallouer ou supprimer les VMs arrêtées.

Le RSSI souhaite obtenir des recommandations concrètes pour améliorer la posture de sécurité de l'abonnement Azure, identifier les ressources mal configurées et réduire les risques. Quel service Azure natif permet d'obtenir ces recommandations sans coût supplémentaire de configuration ?

Azure Advisor est le service natif qui répond à ce besoin. Azure Advisor fournit des recommandations personnalisées basées sur les bonnes pratiques Microsoft dans plusieurs domaines, dont la sécurité (amélioration de la posture de sécurité, détection des ressources non sécurisées), le coût (identification des ressources sous-utilisées ou surdimensionnées, recommandations d'économies), la haute disponibilité, les performances et l'excellence opérationnelle. Pour FinSecure, Advisor permettrait simultanément d'identifier les ressources gaspillées (contribuant aux 23 % de budget perdu, soit ~9 660 €/mois) et de signaler les failles de sécurité (comptes de stockage avec accès public, VMs sans mises à jour, etc.). Azure Advisor est disponible gratuitement dans le portail Azure sans configuration préalable et analyse automatiquement les ressources de l'abonnement pour fournir des recommandations actionnables classées par priorité.

FinSecure doit choisir un plan de support Azure lui permettant d'ouvrir des tickets de support technique en cas d'incident sur ses applications de trading critiques. Le responsable IT a entendu dire que le plan Basic suffit. Est-ce exact, et quel plan minimum recommandez-vous ?

Non, le plan Basic ne suffit pas. Le plan de support Basic est inclus gratuitement avec tout abonnement Azure et offre uniquement l'accès à la documentation, aux bonnes pratiques et aux informations sur l'état de santé des services Azure (Azure Service Health). Il ne permet pas d'ouvrir des demandes de support technique. Seuls les plans Developer, Standard, Professional Direct et Premier permettent d'ouvrir des demandes de support technique Azure, avec des niveaux de service différents. Pour une société de services financiers comme FinSecure dont les applications de trading sont critiques, le plan minimum recommandé est le plan Standard, qui permet d'ouvrir des tickets pour tous les niveaux de sévérité avec des temps de réponse garantis. Pour des applications véritablement critiques 24h/24 (trading en temps réel), le plan Professional Direct ou Premier serait plus approprié, offrant des temps de réponse initiaux de moins d'une heure pour les incidents critiques et un accès à des gestionnaires de compte techniques dédiés.