Pour éviter la répétition de la panne du Black Friday, quelle combinaison de concepts AWS l'équipe technique doit-elle mettre en œuvre, et pourquoi l'architecture actuelle a-t-elle échoué ?

L'architecture actuelle a échoué pour deux raisons fondamentales : elle repose sur un point de défaillance unique (deux serveurs physiques sans redondance réelle), et elle ne dispose d'aucune capacité d'élasticité face aux pics de trafic. Sur AWS, l'équipe doit mettre en œuvre la scalabilité horizontale : ajouter dynamiquement des instances EC2 de même taille pour absorber le trafic croissant, plutôt que de surprovisioner un seul gros serveur. L'élasticité, via l'Auto Scaling, permet d'ajuster automatiquement le nombre d'instances selon la demande réelle, réduisant ainsi les coûts hors pic. Par ailleurs, déployer l'application sur plusieurs zones de disponibilité (AZ) élimine le risque de panne locale : si une AZ rencontre un problème, les autres continuent de servir les utilisateurs, réalisant ainsi un système tolérant aux pannes. Ces principes — scalabilité horizontale, élasticité et déploiement multi-AZ — sont les piliers d'une architecture résiliente sur AWS qui aurait évité les 4 heures d'interruption lors du Black Friday.

Le DSI souhaite évaluer financièrement la migration avant de s'engager. Quels outils AWS peut-il utiliser, et comment le modèle de facturation AWS change-t-il la nature des dépenses informatiques de RetailNow ?

Pour évaluer l'intérêt financier de la migration, le DSI peut utiliser le AWS TCO Calculator, qui permet de comparer le coût total de possession de l'infrastructure on-premise actuelle (8 400 €/mois) avec une estimation équivalente sur AWS, en tenant compte des coûts cachés (matériel, énergie, personnel). Une fois sur AWS, il peut utiliser AWS Cost Explorer pour visualiser et analyser les dépenses par service au fil du temps, et AWS Cost & Usage Reports pour un détail complet de la facturation mensuelle EC2 et autres services. Sur le plan du modèle financier, la migration transforme les dépenses d'investissement (CapEx) — renouvellement matériel tous les 3 ans, infrastructure physique — en dépenses opérationnelles variables (OpEx), payées à l'usage selon le modèle Pay-As-You-Go. RetailNow n'a plus besoin d'estimer la capacité à l'avance ni de surinvestir pour tenir les pics : elle paie exactement ce qu'elle consomme. Pour les charges de base stables, l'équipe peut envisager des Reserved Instances (sur 1 ou 3 ans) afin d'obtenir des réductions significatives par rapport aux instances On-Demand, optimisant encore davantage les coûts récurrents.

L'administrateur système doit garantir la traçabilité des actions sur les ressources AWS et sécuriser les accès des 4 développeurs selon le principe du moindre privilège. Quels services et pratiques AWS doit-il mettre en place ?

Pour la traçabilité, l'administrateur doit activer AWS CloudTrail, qui enregistre l'intégralité des actions effectuées sur les ressources AWS (création, modification, suppression d'instances EC2, accès à S3, etc.) avec l'identité de l'auteur, l'horodatage et la source. En cas d'incident — par exemple des instances EC2 supprimées accidentellement — CloudTrail permet d'identifier immédiatement qui a effectué l'action. Pour la gestion des accès, il doit créer des utilisateurs IAM individuels pour chacun des 4 développeurs (jamais de compte root partagé), et appliquer le principe du moindre privilège : n'accorder à chaque développeur que les permissions strictement nécessaires à ses missions (par exemple, accès en lecture seule à S3 pour un développeur frontend, sans droits sur EC2). L'utilisation de rôles IAM est également recommandée pour les instances EC2 qui ont besoin d'accéder à d'autres services AWS (comme S3), évitant ainsi de stocker des clés d'accès en dur dans le code. Enfin, pour surveiller la performance et détecter des anomalies opérationnelles en temps réel, Amazon CloudWatch doit être configuré pour monitorer les métriques des instances EC2 et déclencher des alertes en cas de comportement anormal.

Le prestataire d'audit a identifié comme critique l'absence de politique IAM structurée et le partage de clés d'accès. Quelles mesures concrètes le CTO doit-il immédiatement mettre en place pour sécuriser les accès des 8 membres de l'équipe ?

La première mesure est de cesser immédiatement l'utilisation du compte root AWS pour les opérations quotidiennes. Le compte root doit être réservé aux seules tâches nécessitant impérativement ce niveau d'accès (changement de plan de support, fermeture de compte), et sécurisé avec un MFA matériel. Le CTO doit ensuite créer des utilisateurs IAM individuels pour chacun des 8 membres de l'équipe, sans jamais partager de clés. Chaque utilisateur doit se voir attribuer uniquement les permissions dont il a réellement besoin — c'est le principe du moindre privilège. Les clés d'accès partagées sur Slack doivent être révoquées immédiatement et remplacées : les développeurs accèdent à la console AWS via nom d'utilisateur et mot de passe, et utilisent des clés d'accès individuelles (générées via IAM) pour l'AWS CLI. Pour les instances EC2 ou services qui ont besoin d'accéder à S3 (par exemple pour lire/écrire les 850 000 documents), le CTO doit utiliser des rôles IAM attachés aux instances (Instance Profiles), qui fournissent des credentials temporaires automatiquement sans stocker de clés dans le code. Enfin, AWS CloudTrail doit être activé sur tous les comptes pour auditer toutes les actions IAM et détecter toute utilisation suspecte des accès.

Pour gérer les politiques de sécurité de manière cohérente sur les 3 comptes AWS et démontrer la conformité RGPD à ses clients avocats et experts-comptables, quels services AWS le CTO doit-il utiliser ?

Pour centraliser la gouvernance des 3 comptes AWS, le CTO doit utiliser AWS Control Tower, qui permet d'orchestrer l'application de politiques de sécurité unifiées (Service Control Policies) sur l'ensemble des comptes d'une organisation. Cela garantit par exemple qu'aucun développeur du compte de développement ne peut accidentellement modifier des ressources de production. Pour détecter les vulnérabilités sur les instances EC2 et les images de conteneurs de la plateforme SaaS, AWS Inspector analyse automatiquement les configurations et identifie les failles logicielles avec un niveau de sévérité. Pour une vue centralisée de l'ensemble des alertes de sécurité — provenant d'Inspector, de GuardDuty (détection de menaces), d'AWS Config (conformité de configuration) — le CTO doit activer AWS Security Hub, qui agrège tous les résultats dans un tableau de bord unique et facilite la remédiation. Enfin, pour démontrer la conformité RGPD et répondre aux demandes d'audit des clients, le CTO utilise AWS Artifact, qui donne accès aux rapports de conformité officiels d'AWS (SOC 2, ISO 27001, etc.), prouvant que l'infrastructure sous-jacente respecte les standards requis. La responsabilité de la protection des données clients dans S3 reste néanmoins celle de DataSafe (modèle de responsabilité partagée).

Le CTO doit s'assurer que les dépenses cloud ne dépassent pas 3 500 €/mois sur les 3 comptes AWS. Quelles solutions AWS met-il en place pour surveiller et contrôler ce budget, et quel avantage apporte la facturation consolidée dans ce contexte ?

Pour surveiller le budget de 3 500 €/mois, le CTO dispose de deux outils complémentaires. D'abord, AWS Budgets permet de définir un seuil budgétaire et d'envoyer automatiquement des alertes (via email ou SNS) dès que les dépenses approchent ou dépassent le seuil fixé — par exemple une alerte à 80 % (2 800 €) et une alerte critique à 100 % (3 500 €). Ensuite, une alerte CloudWatch Billing couplée à Amazon SNS peut être configurée pour notifier immédiatement l'équipe en cas de dépassement. Pour analyser la répartition des dépenses par compte et par service, AWS Cost Explorer offre une visualisation graphique qui permet d'identifier quel compte (production, staging, développement) consomme le plus et quels services EC2 ou S3 sont les plus coûteux. La facturation consolidée via AWS Organizations regroupe la facturation des 3 comptes sous un compte principal unique, ce qui présente deux avantages : une vision globale unifiée des dépenses, et des remises sur volume — les ressources consommées par les 3 comptes s'additionnent pour atteindre les paliers de tarification dégressifs d'AWS plus rapidement, générant des économies que chaque compte n'aurait pas pu obtenir individuellement. Les Reserved Instances achetées sur un compte bénéficient également à l'ensemble des comptes de l'organisation.

Quelles fonctionnalités de l'infrastructure mondiale AWS l'équipe doit-elle exploiter pour réduire la latence des utilisateurs australiens et brésiliens sous les 2 secondes ?

La latence élevée (8,2 secondes pour l'Australie) s'explique principalement par la distance géographique entre les utilisateurs et la région eu-west-1 en Irlande. AWS offre deux leviers complémentaires pour résoudre ce problème. Premièrement, la portée mondiale d'AWS (Global Reach) : l'équipe doit déployer des instances de l'application dans des régions AWS géographiquement proches des utilisateurs — par exemple ap-southeast-2 (Sydney) pour l'Australie et sa-east-1 (São Paulo) pour le Brésil. Chaque région AWS contenant plusieurs zones de disponibilité, les déploiements locaux bénéficient également d'une haute disponibilité régionale. Deuxièmement, les Edge Locations d'AWS (utilisées par Amazon CloudFront) permettent de mettre en cache les contenus statiques — images, CSS, JavaScript, ordonnances PDF — au plus près des utilisateurs, dans des points de présence répartis dans de nombreuses villes mondiales. Pour les dossiers médicaux fréquemment consultés, CloudFront réduit drastiquement le temps de réponse en servant le contenu depuis la ville la plus proche de l'utilisateur plutôt que depuis l'Irlande. La combinaison de régions locales pour les données dynamiques et d'Edge Locations pour les contenus statiques permet d'atteindre l'objectif de moins de 2 secondes pour les utilisateurs internationaux.

Comment l'équipe doit-elle repenser l'architecture de base de données et le déploiement pour éviter qu'une panne d'une seule région AWS ne rende à nouveau la plateforme totalement inaccessible pendant 3 heures ?

La panne de 3 heures illustre deux problèmes d'architecture : un point de défaillance unique (SPOF) au niveau de la région eu-west-1, et l'absence de tolérance aux pannes. Plusieurs principes doivent être appliqués simultanément. D'abord, au niveau de la base de données, Amazon Aurora offre des sauvegardes automatisées et une haute disponibilité native avec réplication multi-AZ au sein d'une même région : si une AZ tombe, Aurora bascule automatiquement vers une réplique en quelques secondes, sans les 3 heures de downtime constatées. Les zones de disponibilité au sein d'une région sont connectées par des liens à faible latence, ce qui permet la réplication synchrone des données et une reprise quasi instantanée. Ensuite, pour une résilience géographique totale, l'équipe doit mettre en place une stratégie de sauvegarde dans une région secondaire (par exemple us-east-1) : les 12 To de données S3 doivent être répliqués dans une autre région via S3 Cross-Region Replication, conformément à la bonne pratique AWS de placer les sauvegardes dans un emplacement géographique différent. Enfin, l'architecture applicative doit éliminer les SPOF en déployant l'application sur plusieurs AZ avec un Elastic Load Balancer, et en adoptant un couplage faible entre les composants (découplage) pour qu'une défaillance partielle n'entraîne pas l'arrêt complet de la plateforme. Ces pratiques sont alignées avec le pilier Fiabilité du Well-Architected Framework.

L'équipe envisage d'utiliser AWS CloudFormation pour déployer l'infrastructure dans plusieurs régions. En quoi cette approche s'inscrit-elle dans les bonnes pratiques AWS, et comment Amazon CloudWatch contribue-t-il à l'excellence opérationnelle de MediConnect ?

AWS CloudFormation permet de gérer l'infrastructure comme du code (Infrastructure as Code) : l'ensemble de l'architecture de MediConnect — instances EC2, groupes de sécurité, bases Aurora, buckets S3, configurations CloudFront — est décrit dans des templates réutilisables et versionnés. Cette approche offre plusieurs avantages alignés avec les bonnes pratiques AWS. Premièrement, l'automatisation : déployer la même architecture dans les régions Sydney, São Paulo et eu-west-1 se fait en réutilisant le même template CloudFormation, éliminant les erreurs de configuration manuelle et accélérant le déploiement. Cela facilite également l'expérimentation architecturale — l'équipe peut tester une nouvelle configuration dans la région de staging, la valider, puis la déployer en production en quelques minutes. Deuxièmement, en cas de panne, la capacité à reconstruire rapidement l'infrastructure via un template élimine les longues heures de reconstruction manuelle. Concernant Amazon CloudWatch, il constitue le pilier du pilier Excellence Opérationnelle du Well-Architected Framework pour MediConnect : il surveille en temps réel les métriques des instances EC2 (CPU, mémoire, latence réseau), la disponibilité des endpoints de l'API, et les performances de la base de données Aurora. Des alarmes CloudWatch peuvent déclencher automatiquement des actions correctives (Auto Scaling, notification SNS vers l'équipe d'astreinte) avant qu'un problème de performance ne devienne une panne visible pour les patients. La combinaison CloudFormation + CloudWatch permet ainsi à MediConnect de monitorer ses systèmes, d'améliorer continuellement ses processus et de réagir proactivement aux incidents.

Le COMEX demande au DSI de justifier financièrement la migration vers AWS plutôt que le renouvellement du datacenter. Quels arguments et outils AWS le DSI doit-il mobiliser pour convaincre la direction financière ?

Le DSI dispose de plusieurs arguments structurants pour convaincre le COMEX. L'argument central est la transformation des dépenses : la migration vers AWS permet d'éviter l'investissement de 1,8 million d'euros en CapEx prévu dans 18 mois, en le remplaçant par des dépenses opérationnelles variables (OpEx) payées à l'usage selon le modèle Pay-As-You-Go. Pour le groupe, cela signifie ne plus immobiliser du capital dans du matériel qui sera obsolète dans 5 ans. Pour étayer ces arguments avec des chiffres précis, le DSI doit utiliser le AWS TCO Calculator, outil permettant à un non-client ou à une organisation avec datacenter existant de comparer le coût total de possession on-premise (matériel, énergie, surface, personnel de maintenance) versus AWS. Il intègre dans la démonstration les économies d'échelle d'AWS : plus la plateforme AWS croît mondialement, plus elle répercute les gains de coût à ses clients via des tarifs en baisse continue. Pour les charges de travail stables et prévisibles (ERP, applications métier), des Reserved Instances sur 1 ou 3 ans permettront d'obtenir des réductions significatives sur le tarif On-Demand. La facturation consolidée des comptes AWS du groupe (un par pays ou par environnement) permettra de bénéficier de remises sur volume supplémentaires. Enfin, l'élasticité du cloud élimine le surdimensionnement : IndusCorp n'a plus besoin d'acheter pour le pic maximal de charge, mais paie la capacité réellement utilisée, d'où la réduction estimée de 35 % des coûts opérationnels.

IndusCorp utilise des licences Oracle et Windows Server achetées il y a 3 ans sous contrat BYOL. Comment AWS prend-il en charge ce scénario, et quel modèle de déploiement cloud le DSI doit-il adopter pour les 18 premiers mois de migration ?

Pour la gestion des licences BYOL (Bring Your Own License), AWS propose les Dedicated Hosts : ce sont des serveurs physiques dédiés exclusivement à IndusCorp, sur lesquels l'entreprise peut déployer ses licences Oracle et Windows Server existantes en respectant les termes contractuels avec les éditeurs. Contrairement aux instances EC2 standard qui s'exécutent sur matériel partagé, les Dedicated Hosts donnent une visibilité sur le serveur physique sous-jacent (nombre de sockets, cœurs), ce que les éditeurs comme Oracle exigent souvent pour la conformité des licences. Cette option garantit qu'IndusCorp ne paie pas deux fois ses licences et reste en conformité avec ses contrats existants. Concernant le modèle de déploiement, la stratégie progressive du DSI correspond parfaitement au modèle hybride : les applications non critiques (reporting, archivage, environnements de test) migrent d'abord vers AWS, tandis que l'ERP reste temporairement dans le datacenter de Lyon. Le modèle hybride connecte les ressources cloud AWS aux ressources on-premise existantes, permettant les échanges de données entre l'ERP sur site et les nouvelles applications cloud. Cette approche réduit les risques de la migration (pas de bascule tout ou rien), permet à l'équipe IT de monter en compétences progressivement, et démontre la valeur du cloud avant d'aborder les systèmes critiques. L'AWS CAF structure cette démarche en fournissant une feuille de route d'adoption couvrant les dimensions technique, organisationnelle et financière.

Le responsable sécurité d'IndusCorp s'interroge sur qui est responsable de quoi une fois les applications migrées sur AWS. Comment le DSI doit-il lui expliquer le modèle de responsabilité partagée, notamment pour les applications EC2 hébergeant l'ERP ?

Le modèle de responsabilité partagée AWS définit clairement la frontière entre ce qu'AWS gère et ce qu'IndusCorp doit gérer lui-même, avec des nuances selon le type de service utilisé. Pour les instances EC2 hébergeant l'ERP (service IaaS), la répartition est la suivante : AWS est responsable de la sécurité de l'infrastructure physique mondiale — datacenter, alimentation électrique, réseau physique, matériel des serveurs — ainsi que du patching matériel (firmware, hyperviseur). IndusCorp reste en revanche responsable de tout ce qui tourne sur ses instances : le système d'exploitation (Windows Server, mises à jour et patches), les applications (ERP, configurations), la gestion des données (chiffrement au repos et en transit), les règles de pare-feu (Security Groups), et la gestion des accès IAM. Il s'agit d'un contrôle partagé pour la gestion des correctifs applicatifs et la gestion de la configuration : AWS patche l'hyperviseur, IndusCorp patche ses OS et applications. Le responsable sécurité doit comprendre que les responsabilités varient selon les services utilisés : avec Amazon RDS (service managé), AWS prend en charge davantage de couches (OS, patches de la base de données), tandis qu'avec EC2, IndusCorp conserve plus de responsabilités. Cette clarification est essentielle pour que l'équipe sécurité d'IndusCorp ne suppose pas qu'AWS gère automatiquement tous les aspects de sécurité, et pour qu'elle dimensionne correctement ses propres processus de sécurité opérationnelle dans le cloud.

L'équipe technique maintient 10 instances EC2 On-Demand actives en permanence alors que le CPU est à 12 % la plupart du temps. Quelle combinaison de types d'achat EC2 et de principes AWS permettrait de réduire significativement les coûts EC2 tout en gérant les pics x15 ?

La configuration actuelle est le cas typique d'une mauvaise adéquation entre le type d'achat EC2 et le profil de charge. Voici la stratégie optimale. Pour la charge de base stable et prévisible — le niveau de trafic normal couvrant 90 % du temps — l'équipe doit migrer vers des Reserved Instances (RI) sur 1 ou 3 ans pour les instances qui tournent en continu. Les RI offrent des réductions importantes par rapport aux prix On-Demand, pouvant atteindre 40 à 75 % selon la durée d'engagement. Si le type d'instance pourrait évoluer avec la croissance de la plateforme, les Convertible RI permettent d'échanger contre un type plus puissant en cours de réservation. Pour les pics événementiels (x15 pendant 2 à 6 heures), l'élasticité via Auto Scaling est la réponse appropriée : des instances supplémentaires EC2 sont provisionnées automatiquement quand la charge augmente, puis arrêtées dès que le trafic revient à la normale. Ces instances de capacité additionnelle peuvent être des instances On-Demand pour la fiabilité, ou des Spot Instances pour les traitements non critiques (transcodage vidéo, génération de miniatures) qui tolèrent une interruption — les Spot Instances étant les plus économiques pour les charges flexibles. La scalabilité horizontale (ajouter des instances de même taille plutôt qu'une seule plus grosse) s'applique naturellement ici. Cette combinaison — RI pour la base + Auto Scaling avec On-Demand/Spot pour les pics — alignée avec le principe d'élasticité AWS, pourrait réduire la facture EC2 de 14 000 € à environ 6 000-8 000 €/mois selon les estimations.

Les 420 To de vidéos de plus de 12 mois sont stockés dans la même classe S3 que les contenus récents. Comment l'équipe doit-elle restructurer sa politique de stockage S3 pour optimiser les coûts, et quelles sont les limites de S3 à ne pas confondre avec d'autres services ?

Le problème de stockage S3 de StreamActu illustre parfaitement l'importance du cycle de vie des données. Les vidéos récentes (moins de 3 mois) sont consultées fréquemment et doivent rester dans la classe S3 Standard pour des temps d'accès optimaux. Pour les vidéos dont le schéma d'accès est imprévisible — certains vieux contenus peuvent devenir viraux suite à un événement d'actualité — l'équipe doit activer S3 Intelligent-Tiering : cette classe déplace automatiquement les objets entre des niveaux de coût selon la fréquence d'accès réelle, sans frais de récupération, optimisant le coût sans décision manuelle. Pour les 420 To d'archives de plus de 12 mois qui ne sont presque jamais consultées, des classes de stockage froides comme S3 Glacier ou S3 Glacier Deep Archive offrent des coûts de stockage très bas (jusqu'à 95 % moins cher que S3 Standard), en contrepartie de délais de récupération de quelques minutes à plusieurs heures selon la classe. Des règles de cycle de vie S3 automatisent le déplacement : par exemple, déplacer automatiquement vers Intelligent-Tiering après 90 jours d'absence d'accès, puis vers Glacier après 365 jours. Concernant les limites de S3 à ne pas confondre : S3 est un service de stockage objet, pas un hébergeur d'applications — il ne peut pas exécuter du code applicatif ou héberger un backend dynamique (contrairement à EC2). Sa scalabilité est automatique, pas manuelle. Ces caractéristiques le différencient fondamentalement d'EC2 et justifient une architecture où EC2 gère la logique applicative tandis que S3 stocke les médias.

Le CTO de StreamActu souhaite être alerté immédiatement si la facture AWS mensuelle approche 25 000 €, et disposer d'une visibilité sur la répartition des dépenses par service. Quels outils AWS met-il en place, et comment le pilier Excellence Opérationnelle du Well-Architected Framework guide-t-il la surveillance de la plateforme ?

Pour la surveillance budgétaire, le CTO doit combiner deux outils complémentaires. AWS Budgets permet de configurer un budget mensuel avec des alertes automatiques : par exemple, une alerte à 80 % (20 000 €) pour anticiper, et une alerte critique à 100 % (25 000 €), envoyées via Amazon SNS (email, SMS) à l'équipe de direction technique. Il peut également configurer une alerte CloudWatch Billing pour déclencher une notification en temps réel dès que le seuil est franchi, avec des actions automatisées si nécessaire. Pour la visibilité détaillée sur la répartition des dépenses, AWS Cost Explorer offre des tableaux de bord visuels permettant d'analyser les coûts par service (EC2, S3, Aurora), par période (jour, semaine, mois), et d'identifier les postes les plus coûteux. Les AWS Cost & Usage Reports fournissent quant à eux un export complet et granulaire de toute l'activité de facturation, permettant par exemple de voir le détail des coûts EC2 instance par instance sur le mois précédent. Sur le plan de l'architecture, le pilier Excellence Opérationnelle du Well-Architected Framework stipule que l'équipe doit être capable de monitorer ses systèmes et d'améliorer continuellement ses processus. Concrètement pour StreamActu, Amazon CloudWatch doit surveiller les métriques des instances EC2 (CPU, latence, erreurs HTTP), les métriques S3 (requêtes, transferts de données) et les métriques Aurora (connexions, latence des requêtes). Des tableaux de bord CloudWatch centralisent ces informations, et des alarmes déclenchent automatiquement l'Auto Scaling lors des montées en charge événementielles — transformant la réaction manuelle en processus automatisé, conforme aux bonnes pratiques d'automatisation du Well-Architected Framework.