Concevoir sur Azure : par où commencer au Port

On ne construit pas le port, on y loue un quai

Un port à conteneurs, personne dans l'équipe ne l'a construit. Les digues, les bassins, les portiques, le poste électrique et la clôture existaient avant nous. Ce qu'on signe, c'est une concession : un quai, une surface d'entreposage, un règlement à respecter.

L'exploitant garde la main sur tout le reste. Il décide de la profondeur des chenaux, de l'entretien des grues, du gardiennage du périmètre. On ne lui demande pas l'autorisation de charger un navire, mais on ne redessine pas le port non plus.

C'est le contrat du cloud public, et c'est le point que la plupart des projets manquent au démarrage. On croit acheter des machines. On loue un emplacement dans une infrastructure dont le règlement est écrit par quelqu'un d'autre.

Cette série suit trois mouvements, dans cet ordre : ouvrir le port, construire les terminaux, faire tourner le port. D'abord les règles, les accès et les radars. Ensuite les installations. Enfin ce qui doit tenir le jour où un navire arrive de travers.

Cette page est le plan de lecture. Elle n'enseigne aucun service en détail : elle donne le chemin, les trois paliers, les huit domaines et l'ordre des vingt et un billets. Garde-la dans un onglet, tu y reviendras entre deux étapes.

Chaque billet ouvre sur Le Port, le même d'un bout à l'autre de la série, transpose ensuite côté Azure, et se termine sur un cas réel documenté publiquement, le scénario B. Celui-ci est le seul sans cas réel. C'est une carte, pas une étape.

Ce que l'exploitant garde, ce que tu assumes

Le règlement portuaire dit noir sur blanc qui répare quoi. Un portique en panne, c'est l'exploitant. Un conteneur mal arrimé qui s'ouvre sur le quai, c'est le locataire. Personne ne découvre la répartition le jour de l'accident : elle figure dans la concession.

Azure publie la même chose sous le nom de modèle de responsabilité partagée. Trois couches restent au client quel que soit le service consommé, trois autres passent au fournisseur dès qu'on quitte ses propres murs, et entre les deux se trouve une zone dont la frontière se déplace selon le modèle de service.

Lis le tableau de haut en bas plutôt que de gauche à droite. Les trois premières lignes ne bougent jamais : la donnée, les comptes et les terminaux qui s'y connectent restent à ta charge, même sur un service entièrement managé.

Plus on descend vers le bas, plus on délègue. Et déléguer se paie en boutons de réglage perdus : une base managée sauvegarde toute seule, mais elle ne te laissera pas installer ton agent maison sur le serveur.

L'erreur classique consiste à lire cette délégation comme un transfert de risque. Devant un client mécontent ou une autorité de contrôle, c'est l'organisation qui exploite le service qui répond de ses données, pas son hébergeur. Le sujet est traité sous l'angle sécurité dans Cloud : IaaS, PaaS, SaaS et responsabilité partagée.

La ligne de partage se déplace avec le modèle de service, jamais avec l'urgence du projet. Ce qui n'a pas été délégué par écrit reste à toi, y compris à trois heures du matin.

Deux cadres, et la confusion qu'ils provoquent

Dans le bureau de la capitainerie, deux documents cohabitent. Le cahier des charges technique d'un terminal, qui dit comment on construit un quai qui tient la charge. Et le plan directeur du port, qui dit dans quel ordre on ouvre les terminaux, qui décide et qui paie.

Microsoft publie les deux équivalents, et ils ne servent pas au même moment.

Le Well-Architected Framework juge une charge de travail. Il repose sur cinq piliers :

• Fiabilité : le service reste rendu quand un composant tombe.
• Sécurité : la donnée et les accès résistent à un attaquant motivé.
• Optimisation des coûts : la facture correspond à la valeur produite.
• Excellence opérationnelle : le déploiement, la supervision et le correctif sont outillés.
• Efficacité des performances : les ressources suivent la demande, ni plus ni moins.

Ces piliers se contredisent en permanence, et c'est justement leur intérêt. Une revue honnête ne coche pas cinq cases : elle écrit ce qu'on sacrifie sur un pilier pour en tenir un autre, et qui a validé ce sacrifice.

Le Cloud Adoption Framework opère un cran au-dessus. Il ne parle pas d'une application mais d'une organisation entière : définir une stratégie, planifier, préparer l'environnement d'accueil, adopter, puis gouverner, gérer et sécuriser dans la durée. C'est lui qui produit la zone d'atterrissage, cette version du port livrée avec les quais déjà viabilisés.

Le premier juge une application, le second organise une entreprise. Les confondre donne une revue d'architecture qui débat de refacturation, ou un comité de gouvernance qui discute de tailles de machines virtuelles.

Le fil rouge : Le Port

Un même port sert de décor à toute la série. Sa capitainerie, ses badges, sa tour de contrôle, ses entrepôts, ses chenaux et son poste de douane. Le choix n'est pas décoratif : le port rend visible une contrainte que le cloud dissimule derrière un formulaire de création de ressource.

Voici la table de correspondance en version courte. Chaque billet en reprend une ou deux lignes, celles qui le concernent.

Un quai mal placé se voit depuis la passerelle du navire. Un plan d'adressage mal taillé, lui, ne se voit jamais, jusqu'au jour où deux réseaux doivent se parler et se découvrent les mêmes adresses.

Une ou deux ancres par section, puis on passe à Azure. La métaphore ouvre le sujet, elle ne le démontre jamais.

Le parcours en un schéma

Les huit domaines, regroupés en trois paliers, dans l'ordre de lecture. On avance de gauche à droite, et on ne passe au palier suivant qu'une fois le précédent digéré.

Les paliers ne trient pas les sujets par difficulté, mais par dépendance. Choisir une taille de machine virtuelle suppose de savoir dans quel abonnement elle atterrit et qui a le droit de la créer. Concevoir une reprise d'activité suppose de savoir ce qui tourne, où, et sur quelles données.

Attaquer la série par le palier 3 revient à installer une grue avant d'avoir signé la concession. Ça se fait, et ça se démonte.

Palier 1 : Ouvrir le port

Avant le premier conteneur, la capitainerie enregistre la concession, délivre les badges et allume les radars. Aucune tonne n'a été déchargée et pourtant l'essentiel est déjà décidé : qui occupe quel lot, qui entre, et qui voit ce qui se passe.

Ce palier ne déploie presque rien. Il installe le cadre que les deux autres vont remplir. Trois domaines, page du palier : Ouvrir le port.

Gouvernance

Le registre des concessions dit qui occupe quel lot, à quelles conditions, et à qui va la facture. Azure tient le même registre sous forme d'une hiérarchie à quatre niveaux de portée, et le niveau retenu décide de tout le reste.

Locataire
└── Groupe d'administration
    └── Groupe d'administration enfant
        └── Abonnement
            └── Groupe de ressources
                └── Ressource

Ce qui s'applique à un étage descend sur ceux du dessous. C'est vrai pour les attributions de rôles et pour les stratégies, ça ne l'est pas pour les étiquettes, et cette asymétrie explique une bonne partie des surprises de refacturation.

Deux outils rendent la hiérarchie vivante. Azure Policy empêche : il refuse une configuration interdite au moment de la création, ou la corrige. L'étiquetage explique : il dit à qui appartient une ressource et sur quel budget elle tombe. Le reste du domaine porte sur la livraison de ce cadre par du code, puis sur la facture, qui est le seul indicateur que tout le monde lit.

1. Cette page, le plan de lecture de la série.
2. Gouvernance Azure : hiérarchie, stratégies et étiquetage
3. Zone d'atterrissage et déploiement automatisé
4. Maîtriser la facture : budgets, réservations, dimensionnement

Page du domaine : Gouvernance.

Identité

Le badge portuaire est délivré par la capitainerie et reconnu sur tous les quais. Il ne dit pas où son porteur a le droit d'aller, ni pendant combien de temps il peut monter sur un portique. Ce sont trois questions distinctes, et elles ont trois réponses distinctes.

Le premier billet pose l'annuaire : ce que Microsoft Entra ID fait, ce qu'il ne fait pas, et comment il coexiste avec un annuaire interne déjà en place. Le second traite l'autorisation : RBAC répond « quoi, sur quelle portée », l'accès conditionnel répond « dans quelles conditions », et l'élévation temporaire répond « pendant combien de temps ».

1. Microsoft Entra ID : annuaire, identité hybride et invités
2. RBAC, accès conditionnel et PIM : donner le bon accès

Page du domaine : Identité.

Supervision

La tour de contrôle voit les navires avant qu'ils n'entrent dans la darse. Encore faut-il que les radars soient allumés et que le journal de bord soit tenu.

Sur Azure, la donnée de supervision n'arrive pas toute seule. Métriques et journaux n'ont ni la même granularité, ni la même rétention, ni le même coût, et certains journaux n'existent tout simplement pas tant que personne n'a demandé leur collecte. Le billet traite l'espace de travail comme une décision d'architecture, puis l'alerte comme un objet de conception : la seule question qui compte est de savoir qui fait quoi quand ça sonne.

1. Supervision : Azure Monitor, Log Analytics et alertes

Page du domaine : Supervision.

Ordre de lecture du palier 1 : cette page, la gouvernance, l'identité, la supervision. À la fin, tu n'as déployé aucune application, et tu sais déjà qui peut créer quoi, où, et qui le verra.

Palier 2 : Construire les terminaux

Les concessions sont signées, les badges distribués, les radars allumés. On coule le béton. Portiques, entrepôts frigorifiques, darses et raccordement ferroviaire : les installations qui portent le trafic réel.

Ce palier est le plus technique de la série et le plus long. Trois domaines, page du palier : Construire les terminaux.

Calcul

Décharger un navire à la main, louer un portique, ou confier la cargaison à un terminal automatisé : le tonnage traité est le même, l'équipe nécessaire n'a rien à voir. Le premier billet parcourt les services de calcul du plus manuel au plus abstrait et fait apparaître l'arbitrage central : ce qu'on gagne en contrôle se paie en exploitation. Les deux suivants entrent dans les deux briques les plus utilisées, la machine virtuelle et le conteneur.

1. Choisir son service de calcul : de la machine virtuelle au serverless
2. Machines virtuelles : tailles, disques, images, mise à l'échelle
3. Conteneurs sur Azure : ACI, Container Apps et AKS

Page du domaine : Calcul.

Stockage & données

Sur le même terminal cohabitent l'entrepôt courant, le frigorifique, l'entrepôt sous douane et les archives du fond. Personne ne stocke des bananes dans les archives, et personne ne paie un emplacement réfrigéré pour des palettes qui dorment cinq ans.

Le domaine commence par le compte de stockage, ressource la plus banale et la plus mal paramétrée, avec ses deux décisions à longue portée : contre quelle panne on est couvert, et combien on paie pour une donnée qu'on ne lit jamais. Il enchaîne sur les bases : le registre des manifestes tenu ligne à ligne d'un côté, le carnet de bord libre de l'autre. Il se termine sur les chaînes qui déplacent et transforment la donnée.

1. Comptes de stockage : redondance, niveaux d'accès, cycle de vie
2. Bases relationnelles : Azure SQL, Managed Instance ou machine virtuelle
3. Cosmos DB : partitionnement, unités de requête et cohérence
4. Intégration de données : lot, flux et entrepôt

Page du domaine : Stockage & données.

Réseau & connectivité

Les darses, les chenaux et le balisage se tracent une fois. Les élargir suppose de vider le bassin. Un plan d'adressage se change en redéployant, ce qui en fait la décision la plus coûteuse à défaire de tout le palier.

Le premier billet construit l'intérieur puis raccorde l'extérieur, avec la résolution de noms traitée comme un sujet à part entière. Le second aiguille et filtre : quatre services répartissent le trafic et se confondent en permanence, plusieurs dispositifs le filtrent et ne voient pas les mêmes choses.

1. Réseau virtuel : adressage, appairage et connectivité hybride
2. Répartition de charge et sécurité réseau : quatre services, cinq filtres

Page du domaine : Réseau & connectivité.

Le palier 2 se lit dans l'ordre calcul, données, réseau. Choisir un service d'exécution avant de connaître son plan d'adressage revient à commander un portique sans savoir la largeur du quai.

Palier 3 : Faire tourner le port

Le port est construit, les navires arrivent. Reste le travail quotidien : faire circuler les bordereaux entre les services, garder les scellés au coffre, et savoir quoi faire la nuit où un bassin devient inutilisable.

Deux domaines, page du palier : Faire tourner le port.

Applications & intégration

Le centre de tri reçoit, trie, redistribue, et garde une trace de ce qui n'a pas pu être livré. La consigne, elle, garde sous la main ce qu'on va redemander dans l'heure.

Le premier billet traite la communication entre composants, la présentation des API vers l'extérieur et le cache, avec une distinction que confondre coûte cher : un message attend un destinataire, un événement annonce un fait. Le second rassemble les gestes de sécurité applicative, à commencer par celui qui évite le plus d'incidents : ne jamais écrire un secret en clair dans le code ou la configuration.

1. Infrastructure applicative : messagerie, passerelle d'API et cache
2. Sécuriser ses applications : Key Vault, identités managées, chiffrement

Page du domaine : Applications & intégration.

Continuité

Un port sérieux prévoit un second poste d'amarrage dans un autre bassin, et un port de repli à cinquante kilomètres. Les deux ne servent pas au même incident et ne coûtent pas le même prix.

La disponibilité se calcule avant de se promettre : le premier billet pose l'arithmétique, les trois échelles de redondance, puis l'arbitrage entre actif et passif. Le deuxième sépare la sauvegarde, qui répare une donnée, de la réplication, qui déplace un service. Le dernier clôt la série sur la migration, seul moment où l'on ne peut plus reculer.

1. Haute disponibilité : SLA, zones, régions et basculement
2. Sauvegarde et reprise : Azure Backup et Site Recovery
3. Migrer vers Azure : évaluer, choisir son R, basculer

Page du domaine : Continuité.

La continuité arrive en dernier dans la série et en premier dans les questions du comité de direction. C'est aussi le seul domaine dont on ne mesure la qualité qu'en le déclenchant pour de vrai.

Les huit domaines en un coup d'œil

Le parcours complet, pour retrouver rapidement où aller.

Comment lire la série

Quatre repères avant de commencer.

Commence au palier 1, même si tu déploies sur Azure depuis trois ans. Beaucoup d'équipes savent créer une machine virtuelle et bloquent sur « dans quel abonnement, sous quelle stratégie, avec quel rôle ». Les trois premiers domaines donnent le vocabulaire que tous les autres réutilisent.

Ouvre le portail à côté. Chaque billet décrit des décisions, pas des clics. Le geste utile consiste à retrouver l'écran correspondant sur ton propre locataire et à regarder ce qui y est déjà coché, souvent par défaut, souvent depuis longtemps.

Lis le scénario B jusqu'au bout. Chaque billet, sauf celui-ci, se termine sur un incident ou une décision réelle, documentée publiquement par ceux qui l'ont vécue. C'est la partie qui empêche la série de rester un catalogue de bonnes intentions.

Reviens à cette page entre deux paliers. Le schéma du parcours montre d'un coup d'œil ce que tu viens d'acquérir et pourquoi la suite arrive maintenant plutôt qu'avant. Une carte ne sert qu'à ceux qui la ressortent en chemin.

Un dernier avertissement, valable pour toute la série. Les noms de services Microsoft changent, les limites évoluent, une région ouvre ce qu'une autre n'a pas encore. Les billets décrivent des capacités et des arbitrages, qui bougent lentement ; pour un chiffre exact ou une disponibilité régionale, la documentation officielle reste la seule source qui fasse foi.

La série vise la conception d'une infrastructure entière, pas la maîtrise d'un produit. Aucun billet ne remplace la documentation ; tous cherchent à te faire poser la bonne question avant de l'ouvrir.

Points clés

• Le cloud public est une concession, pas une acquisition : la responsabilité se partage selon le modèle de service, et la donnée, les comptes et les terminaux restent toujours à ta charge.
• Deux cadres coexistent sans se confondre : l'un juge une charge de travail sur cinq piliers, l'autre organise l'adoption d'une entreprise entière.
• La série suit trois paliers, ouvrir le port, construire les terminaux, faire tourner le port, qui classent les sujets par dépendance et non par difficulté.
• Le palier 1 ne déploie presque rien et décide presque tout : hiérarchie, stratégies, identités, collecte de journaux.
• Huit domaines, vingt et un billets, un seul décor : le même port du début à la fin.

Dans la série

Palier 1 : Ouvrir le port. Domaine : Gouvernance.

• Suivant : Gouvernance Azure : hiérarchie, stratégies et étiquetage

Pour aller plus loin

• Gouvernance Azure : hiérarchie, stratégies et étiquetage, la suite immédiate de cette page.
• Zone d'atterrissage et déploiement automatisé, pour livrer ce cadre par du code plutôt qu'à la main.
• Cloud : IaaS, PaaS, SaaS et responsabilité partagée, le même partage vu sous l'angle sécurité.
• Architecture logicielle : par où commencer sur Le Chantier et System design : par où commencer dans La Ville, les deux séries voisines, en amont de l'infrastructure.
• Les trois pages de palier regroupent leurs billets au fil des publications : Ouvrir le port, Construire les terminaux, Faire tourner le port.
• La section Cloud rassemble les vingt et un billets à mesure qu'ils sortent.
• Les sources officielles citées ici : Well-Architected Framework, Cloud Adoption Framework et modèle de responsabilité partagée.