Quel service Azure SQL est le plus adapté pour héberger le système transactionnel existant, et pourquoi est-ce préférable à Azure SQL Database standard dans ce contexte bancaire ?

Azure SQL Managed Instance est le service le plus adapté. Contrairement à Azure SQL Database (Single Database ou Elastic Pool), Managed Instance offre une compatibilité quasi-totale avec SQL Server on-premise, incluant SQL Agent (nécessaire pour les jobs planifiés de nuit), Linked Servers, Service Broker et les assemblies CLR. La migration peut se faire avec un minimum de modifications du code T-SQL existant, ce qui est critique pour une banque où le code applicatif est souvent figé et non réécriptible rapidement. De plus, le système bancaire repose sur des transactions ACID strictes : l'atomicité garantit qu'un virement (débit + crédit) s'exécute entièrement ou est annulé, la cohérence assure le respect des contraintes d'intégrité (soldes non négatifs, clés étrangères entre comptes et transactions), et la durabilité garantit qu'aucune transaction validée n'est perdue même en cas de panne. Ces propriétés sont nativement assurées par Managed Instance, ce qui est indispensable pour un système OLTP bancaire à 850 000 transactions quotidiennes.

Pour l'entrepôt de données analytique destiné aux rapports de gestion sur 10 ans d'historique, quelle architecture Azure recommanderiez-vous, et comment les rôles de l'équipe data s'y articulent-ils ?

L'architecture recommandée s'appuie sur trois services complémentaires. Azure Data Lake Storage (ADLS) sert de zone de stockage brut (landing zone) pour les 2,4 To de données historiques au format non structuré ou semi-structuré (JSON, CSV, fichiers de logs). Azure Data Factory orchestre les pipelines ETL/ELT : extraction depuis le système OLTP (Managed Instance), transformation (nettoyage, normalisation, agrégation par agence et par période), puis chargement dans Azure Synapse Analytics. Synapse constitue l'entrepôt de données final, optimisé pour les charges analytiques OLAP : requêtes complexes sur de grands volumes historiques, agrégations multi-dimensionnelles (encours par agence × période × type de crédit). Power BI se connecte à Synapse pour les tableaux de bord interactifs. Côté rôles : l'ingénieur de données conçoit et maintient les pipelines Data Factory (ETL), l'analyste de données crée les visualisations et mesures DAX dans Power BI, et l'administrateur DBA supervise Managed Instance et les accès. Cette séparation OLTP (Managed Instance) / OLAP (Synapse) est fondamentale : les requêtes analytiques lourdes sur 10 ans d'historique n'impactent pas les performances transactionnelles du système bancaire.

La DSI s'interroge sur la redondance des données stockées dans Azure pour garantir la continuité de service en cas de sinistre majeur affectant la région Azure primaire. Quelle option de redondance recommanderiez-vous, et quel niveau de cohérence de stockage cela implique-t-il ?

Pour un établissement bancaire soumis à des exigences réglementaires de continuité d'activité (PCA/PRA), l'option GRS (Geo-Redundant Storage) est la plus adaptée. GRS réplique automatiquement les données dans deux régions géographiquement distantes (ex. : France Centre + France Sud, ou France Centre + Europe Ouest), protégeant contre une défaillance régionale complète (incendie de datacenter, catastrophe naturelle). Cette option est supérieure à LRS (Local Redundant Storage, réplication dans une seule région) ou ZRS (Zone Redundant Storage, réplication entre zones d'une même région) car elle seule garantit la survie des données en cas de sinistre régional majeur. Pour les fichiers archivés dans Azure Blob Storage (notamment les archives de transactions sur 10 ans), le niveau Archive avec GRS combine coût minimal (environ 0,01€/Go/mois pour les données froides) et résilience géographique maximale. Il faut noter que le niveau Archive impose un délai de récupération de plusieurs heures (réhydratation nécessaire), ce qui est acceptable pour des données historiques mais pas pour les données opérationnelles courantes qui doivent rester en niveau Hot ou Cool avec GRS.

Quel service Azure recommanderiez-vous pour stocker les profils clients aux attributs variables, et justifiez pourquoi une base relationnelle comme PostgreSQL n'est pas optimale pour ce cas d'usage ?

Azure Cosmos DB avec l'API SQL (Core) ou MongoDB est la solution la plus adaptée pour stocker les profils clients. Les données clients de ShopNow sont typiquement semi-structurées : elles s'expriment naturellement en JSON avec des structures imbriquées (tableau d'adresses, tableau de préférences, historique variable). Une base relationnelle comme PostgreSQL impose un schéma fixe : pour gérer des adresses multiples, il faudrait une table 'adresses' séparée avec une clé étrangère, et chaque attribut variable nécessiterait soit une colonne NULL pour la majorité des lignes, soit une table de jointure supplémentaire. Cette rigidité génère des jointures complexes et coûteuses pour reconstruire un profil complet, ce qui explique les problèmes de latence observés. Cosmos DB stocke chaque profil comme un document JSON autonome, éliminant les jointures. Surtout, sa réplication mondiale automatique permet de servir les clients d'Europe du Sud depuis une région Azure proche (ex. : France Sud ou Spain Central), réduisant drastiquement la latence. La scalabilité horizontale automatique absorbe les pics à +340 % sans intervention manuelle. Le niveau de cohérence 'Session' suffit pour les profils clients (un utilisateur voit toujours ses propres modifications), sans impacter les performances comme le ferait la cohérence 'Strong'.

Quelle solution Azure recommanderiez-vous pour stocker les 650 Go de médias (photos de produits, vidéos de démonstration, images de révisions clients), et comment optimiseriez-vous les coûts selon la fréquence d'accès aux contenus ?

Azure Blob Storage est le service approprié pour stocker ces données non structurées (images, vidéos, fichiers audio) qui n'ont pas de schéma prédéfini ni d'organisation tabulaire. La stratégie de niveaux d'accès permet d'optimiser significativement les coûts. Le niveau Hot s'applique aux photos et vidéos des produits actifs du catalogue (accès fréquent par les pages produit et les API), malgré un coût de stockage plus élevé, car la latence d'accès doit être minimale pour l'expérience utilisateur. Le niveau Cool convient aux médias de produits retirés du catalogue mais conservés pour les historiques de commandes (accès occasionnel, par exemple lors d'un retour client ou d'un litige). Le niveau Archive est réservé aux anciennes révisions clients avec photos de plus de 2 ans, aux sauvegardes de médias archivés et aux contenus marketing obsolètes : le coût est minimal (environ 0,01€/Go/mois) mais le délai de récupération de plusieurs heures est acceptable pour ces usages. Pour la redondance, GRS est recommandé pour les actifs critiques (photos du catalogue actif) afin de garantir la disponibilité en cas de panne régionale, tandis que LRS peut suffire pour les archives froides, réduisant encore les coûts.

Le data scientist souhaite entraîner des modèles de recommandation sur 3 ans d'historique d'achats (données massives, formats variés : logs JSON, exports CSV, données structurées). Quelle architecture de traitement Big Data recommanderiez-vous sur Azure ?

L'architecture recommandée combine Azure Data Lake Storage Gen2 et Azure Databricks. Azure Data Lake Storage (ADLS Gen2) sert de référentiel central pour toutes les données brutes : logs JSON des sessions utilisateurs, exports CSV des transactions, données structurées exportées de la base opérationnelle. Contrairement à un Data Warehouse, le Data Lake stocke les données dans leur format brut sans transformation préalable, ce qui est idéal pour la diversité des formats et les 3 ans d'historique. Azure Databricks, fondé sur Apache Spark, est la plateforme optimale pour le data scientist : il permet de traiter distributivement les volumes massifs (plusieurs centaines de Go à To), d'explorer les données en notebooks interactifs Python/Scala, et d'entraîner des modèles de machine learning (algorithmes de filtrage collaboratif, modèles de recommandation basés sur l'historique). Azure Data Factory orchestre les pipelines d'ingestion depuis les sources opérationnelles (Cosmos DB, bases SQL) vers ADLS, assurant la fraîcheur des données d'entraînement. Cette séparation Data Lake (stockage brut) / Databricks (traitement ML) est fondamentale : le Data Lake conserve toutes les données sans perte (même celles dont l'utilité future est incertaine), tandis que Databricks transforme à la demande selon les besoins du data scientist, sans rigidité de schéma imposée à l'avance.

Pour répondre à l'objectif de détection des ruptures de stock en moins de 5 minutes, quel service Azure recommanderiez-vous pour le traitement en temps réel des flux de données de caisse, et comment s'articule-t-il avec les autres composants ?

Azure Stream Analytics est le service Azure spécialement conçu pour le traitement en temps réel de flux d'événements continus, ce qui correspond exactement à l'objectif de latence inférieure à 5 minutes. L'architecture de flux recommandée fonctionne ainsi : les données de caisse de chaque magasin (transactions, niveaux de stock) sont émises en continu vers Azure Event Hubs ou Azure IoT Hub, qui servent de porte d'entrée pour les flux d'événements à haut débit (1,2 million de transactions/jour soit environ 14 transactions/seconde en moyenne, avec des pics aux heures de repas et de fermeture). Azure Stream Analytics consomme ces flux en temps réel et applique des requêtes de type SQL sur les fenêtres temporelles glissantes : par exemple, si le niveau de stock d'un article tombe sous un seuil configuré sur une fenêtre de 3 minutes, une alerte est déclenchée. Les alertes peuvent être envoyées vers Azure Service Bus pour notifier les responsables de magasin, ou vers Power BI en mode streaming pour un tableau de bord de supervision en temps réel. Ce traitement en flux est fondamentalement différent du traitement par lots (batch) de l'architecture actuelle avec les fichiers CSV journaliers, et permet de passer d'une latence de 4-6 heures à une latence inférieure à 5 minutes.

Pour l'entrepôt de données analytique destiné aux 5 analystes de données de la direction commerciale, quelle différence fondamentale devez-vous leur expliquer entre leur usage actuel (OLTP) et le nouveau système analytique (OLAP), et quel service Azure incarnerait cet entrepôt ?

Il est essentiel d'expliquer aux analystes la distinction OLTP vs OLAP pour qu'ils comprennent pourquoi deux systèmes distincts sont nécessaires. Le système OLTP actuel (SQL Server centralisé) est optimisé pour les transactions rapides et individuelles : chaque insertion d'une transaction de caisse modifie quelques lignes, les requêtes touchent peu d'enregistrements, et l'objectif est la vitesse d'écriture et l'intégrité transactionnelle (propriétés ACID). Demander à ce système de calculer la marge par famille de produits sur 12 mois pour 240 magasins simultanément dégrades les performances transactionnelles pour tous les utilisateurs. Le système OLAP, au contraire, est conçu pour lire et agréger de très grands volumes de données historiques : requêtes complexes avec GROUP BY, jointures multiples entre tables de faits et dimensions (magasins, produits, périodes), calculs d'agrégats (SUM des ventes, AVG du panier, COUNT des transactions). Azure Synapse Analytics est le service Azure qui incarne cet entrepôt de données : il combine les capacités SQL analytiques (Synapse SQL Pools) pour les requêtes des analystes, les capacités Spark pour les traitements Big Data, et l'intégration native avec Azure Data Factory pour les pipelines ETL d'alimentation depuis le système transactionnel. Power BI se connecte directement à Synapse pour les rapports hebdomadaires et mensuels, avec le langage DAX pour les mesures calculées (taux de marge, évolution N-1).

Les directeurs de région souhaitent accéder à des tableaux de bord interactifs sans compétences techniques SQL ou DAX. Quel outil Microsoft recommanderiez-vous, et quel type de visualisation serait le plus adapté pour suivre l'évolution du panier moyen hebdomadaire sur 12 mois ?

Power BI est l'outil Microsoft dédié à la business intelligence et à la visualisation de données, parfaitement adapté à des utilisateurs sans compétences techniques. Les directeurs de région peuvent consulter des tableaux de bord partagés via Power BI Service (accès navigateur ou application mobile) sans jamais écrire une ligne de SQL ou de DAX — ces mesures sont créées en amont par les 5 analystes de données de l'équipe. Pour suivre l'évolution du panier moyen hebdomadaire sur 12 mois, le graphique en courbes (line chart) est le type de visualisation le plus adapté : chaque point de la courbe représente la valeur du panier moyen pour une semaine donnée, les points étant reliés par une ligne continue qui permet de percevoir immédiatement les tendances (hausse sur les périodes de fêtes, baisse en janvier), les anomalies et les saisonnalités. Un graphique circulaire serait inadapté (il montre des proportions statiques, pas des évolutions temporelles), tout comme un nuage de points (adapté aux corrélations entre variables). Les analystes de données créent ces visualisations dans Power BI Desktop en utilisant DAX pour les mesures calculées (ex. : AVERAGE du panier, comparaison avec la semaine précédente via DATEADD), puis publient les rapports dans Power BI Service pour les partager avec les directeurs de région, qui peuvent filtrer par magasin ou par région grâce aux slicers interactifs, sans aucune compétence technique requise.

MedTrack doit stocker trois types de données radicalement différents (mesures physiologiques structurées, rapports PDF et audios non structurés, métadonnées patients semi-structurées). Quelle combinaison de services Azure Storage recommanderiez-vous pour chacun de ces types, et justifiez votre choix ?

Chaque type de données nécessite un service de stockage adapté à sa nature. Pour les mesures physiologiques structurées (valeurs numériques horodatées : glycémie, tension, SpO2), Azure SQL Database est adapté pour les données récentes nécessitant des requêtes précises (alertes sur seuils, historique patient sur 30 jours), ou Azure Table Storage pour une approche NoSQL clé-valeur scalable (PartitionKey = identifiant patient, RowKey = horodatage) permettant d'ingérer rapidement le million de mesures quotidiennes avec une scalabilité horizontale préparée pour les 80 000 patients futurs. Pour les rapports médicaux PDF et enregistrements audio (données non structurées sans schéma prédéfini, combinant contenus visuels, textuels et auditifs), Azure Blob Storage est le service approprié : optimisé pour les objets binaires volumineux, il propose des niveaux d'accès adaptés à la fréquence de consultation (Hot pour les rapports récents consultés par les médecins, Cool pour les rapports de plus de 6 mois, Archive pour les données au-delà de 5 ans dans une logique de conformité et de coût). Pour les métadonnées patients semi-structurées (profils JSON avec attributs variables selon la pathologie — un diabétique a des champs différents d'un hypertendu), Azure Cosmos DB avec l'API SQL stocke des documents JSON sans schéma fixe, avec une scalabilité mondiale et une latence faible pour les lectures fréquentes lors des consultations. La redondance GRS est recommandée pour l'ensemble, compte tenu du caractère critique des données médicales.

La startup souhaite détecter automatiquement les anomalies critiques (glycémie dangereusement haute, chute de SpO2) dans les flux de mesures en temps quasi réel pour alerter les médecins référents. Quelle architecture de traitement en temps réel recommanderiez-vous sur Azure ?

L'architecture de traitement en temps réel repose sur Azure Stream Analytics, le service Azure spécialisé dans l'analyse de flux d'événements continus, exactement adapté aux flux IoT médicaux. Les capteurs transmettent leurs mesures via Azure IoT Hub, qui est conçu pour gérer des millions de connexions d'appareils IoT simultanées avec une haute fiabilité, servant de point d'entrée sécurisé pour les 12 000 (puis 80 000) capteurs. Azure Stream Analytics consomme en continu ces flux et applique des requêtes de type SQL sur des fenêtres temporelles : par exemple, si la glycémie dépasse 3,0 g/L sur deux mesures consécutives dans une fenêtre de 30 minutes pour un patient donné, une alerte est déclenchée. Ces alertes peuvent être routées vers Azure Service Bus pour notifier les applications médicales, ou via Azure Functions pour envoyer des SMS aux médecins référents. Les mesures brutes sont parallèlement archivées dans Azure Data Lake Storage pour constituer un historique massif exploitable ultérieurement par des algorithmes de machine learning (Azure Machine Learning) pour la détection prédictive de décompensations. Cette architecture découple clairement le traitement temps réel (Stream Analytics pour les alertes immédiates) du traitement analytique différé (Synapse Analytics ou Databricks sur le Data Lake pour les analyses épidémiologiques et les modèles prédictifs), une séparation analogue à la distinction fondamentale entre OLTP et OLAP.

Pour respecter la conformité RGPD sur les données de santé des patients, MedTrack doit savoir précisément où se trouvent toutes ses données personnelles dans Azure, les classifier et contrôler les accès. Quel service Azure de gouvernance des données recommanderiez-vous, et en quoi est-il différent d'Azure Policy ?

Microsoft Purview (anciennement Azure Purview) est le service Azure dédié à la gouvernance centralisée et au catalogue de données d'entreprise, parfaitement adapté aux exigences RGPD de MedTrack. Purview permet de découvrir automatiquement toutes les sources de données dans l'environnement Azure (Azure SQL Database, Blob Storage, Cosmos DB, Data Lake), de scanner leur contenu pour classifier les données sensibles (il peut détecter automatiquement des numéros de sécurité sociale, des données médicales, des noms de patients), de créer un catalogue consultable listant où se trouvent toutes les données personnelles de santé, et d'appliquer des politiques de lignage (data lineage) pour tracer le parcours d'une donnée de sa source à ses transformations. Ces fonctionnalités répondent directement aux obligations RGPD : droit d'accès (savoir quelles données on détient sur un patient), droit à l'effacement (localiser toutes les occurrences d'une donnée patient pour les supprimer), et accountability (démontrer à la CNIL la maîtrise du patrimoine de données). Azure Policy est fondamentalement différent : c'est un service de gouvernance des ressources Azure (infrastructure), qui permet de définir des règles sur le provisionnement des ressources cloud (ex. : imposer le chiffrement, interdire certaines régions Azure, forcer les tags). Azure Policy ne comprend pas le contenu des données, ne les classe pas et ne crée pas de catalogue : il gouverne l'infrastructure, pas les données elles-mêmes. Pour MedTrack, les deux sont complémentaires : Purview pour la gouvernance des données de santé (RGPD), Azure Policy pour la gouvernance de l'infrastructure cloud (conformité de configuration).

Pour unifier les données d'abonnement de 8 pays (actuellement dans des bases SQL relationnelles distinctes) et permettre une vue 360° des abonnés pouvant être présents dans plusieurs pays, quelle architecture de pipeline de données recommanderiez-vous sur Azure, et quel rôle professionnel est central dans sa mise en œuvre ?

La consolidation des données d'abonnement de 8 pays nécessite un pipeline ETL/ELT orchestré par Azure Data Factory, le service Azure natif d'intégration et d'orchestration de pipelines de données. Data Factory se connecte à chaque source (bases SQL nationales, potentiellement hébergées sur Azure SQL Database, Azure SQL Managed Instance ou des serveurs on-premise via integration runtime) et extrait les données selon une planification définie. L'étape de transformation est critique ici : elle doit harmoniser les schémas hétérogènes (chaque pays a potentiellement des colonnes différentes, des formats de date locaux, des devises distinctes), normaliser les identifiants abonnés pour détecter les doublons multi-pays (un même abonné avec une adresse email commune en France et en Belgique), et enrichir les données avec un identifiant groupe unique. Les données transformées sont chargées dans Azure Synapse Analytics, qui joue le rôle d'entrepôt de données centralisé pour le groupe. Synapse permet les requêtes analytiques SQL complexes nécessaires à la vue 360° : JOIN entre la table des abonnés consolidée et les tables de transactions par pays, agrégations multi-dimensionnelles. L'ingénieur de données est le rôle central dans cette mise en œuvre : il conçoit et maintient les pipelines Data Factory, gère les transformations de données, assure la qualité et la fraîcheur des données dans Synapse. L'analyste de données exploite ensuite ces données préparées pour construire les tableaux de bord Power BI destinés aux équipes marketing du groupe.

Le groupe possède 95 To de vidéos de reportage archivées. Quelle stratégie de stockage Azure recommanderiez-vous pour optimiser les coûts sur ces données non structurées, en sachant que certaines vidéos sont récentes et fréquemment consultées, d'autres ont plus de 5 ans et ne sont quasiment plus accédées ?

Les 95 To de vidéos de reportage sont des données non structurées (pas de schéma prédéfini, combinaison de contenus visuels et auditifs), ce qui oriente naturellement vers Azure Blob Storage, le service Azure optimisé pour le stockage d'objets binaires volumineux. La stratégie de niveaux d'accès (tiering) est essentielle pour optimiser les coûts sur un volume aussi important. Le niveau Hot est réservé aux vidéos récentes (moins de 3 mois), fréquemment consultées par les journalistes pour les montages, par les équipes éditoriales, ou accessibles aux abonnés premium : le coût de stockage est plus élevé mais la latence d'accès est minimale. Le niveau Cool convient aux vidéos de 3 mois à 2 ans, accédées occasionnellement (recherches d'archives, documentaires, retours sur événements passés) : le coût de stockage est réduit d'environ 50 % par rapport à Hot. Le niveau Archive est appliqué aux vidéos de plus de 5 ans, quasiment jamais consultées mais conservées pour des raisons légales (droits d'auteur, presse historique) ou éditoriales : le coût est minimal (environ 0,01€/Go/mois), soit environ 950€/mois pour 95 To en Archive, contre un coût nettement supérieur en Hot. La contrepartie est un délai de récupération de plusieurs heures (réhydratation), acceptable pour des archives anciennes. Des politiques de cycle de vie automatisées dans Azure Blob Storage peuvent gérer la transition automatique entre niveaux selon l'âge des fichiers, sans intervention manuelle. La redondance GRS est recommandée pour les vidéos récentes et les archives irremplaçables, compte tenu des 95 To et de leur valeur patrimoniale.

Pour le moteur de recommandation d'articles personnalisé, le data scientist du groupe doit entraîner un modèle sur les comportements de lecture de 3,4 millions d'abonnés dans 8 pays (données JSON semi-structurées). Quelle plateforme Azure recommanderiez-vous pour ce projet de machine learning à grande échelle, et comment s'intègre-t-elle dans l'architecture globale ?

Azure Databricks est la plateforme la plus adaptée pour ce projet de machine learning à grande échelle sur des données semi-structurées massives. Fondée sur Apache Spark, Databricks permet le traitement distribué des données comportementales JSON de 3,4 millions d'abonnés sur 8 pays — un volume que les outils de machine learning classiques ne pourraient traiter en mémoire sur une seule machine. Les données brutes de comportement de lecture (pages vues, temps de lecture, articles partagés, séquences de navigation) au format JSON sont stockées dans Azure Data Lake Storage Gen2, qui sert de lac de données centralisé alimenté par les pipelines Azure Data Factory. Databricks lit ces données depuis ADLS via des connecteurs natifs, permet au data scientist d'explorer et préparer les données dans des notebooks Python/Scala interactifs, et d'entraîner des algorithmes de filtrage collaboratif (recommandations basées sur les similarités entre abonnés) ou de contenu (basées sur les caractéristiques des articles). Une fois le modèle entraîné, Azure Machine Learning prend le relais pour la gestion du cycle de vie du modèle (versioning, monitoring de performance, déploiement en endpoint API). L'intégration dans l'architecture globale est la suivante : Data Factory ingère les données comportementales depuis les 8 plateformes nationales vers ADLS → Databricks entraîne le modèle sur ces données → Azure Machine Learning déploie le modèle en API → les applications web et mobiles du groupe appellent cette API pour personnaliser les recommandations d'articles en temps réel pour chaque abonné, quelle que soit sa nationalité. Cette architecture illustre la différence fondamentale entre un Data Lake (ADLS, stockage brut des comportements) et un Data Warehouse (Synapse, données structurées pour les rapports analytiques) : les deux coexistent et se complètent dans l'écosystème Azure du groupe.