Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Qu'est-ce qu'une Azure Landing Zone ? Les 8 domaines de conception expliqués : la gouvernance contre le chaos cloud (Doublage IA)

Transcript

Qu'est-ce qu'une Azure Landing Zone ? Les 8 domaines de conception expliqués : la gouvernance contre le chaos cloud (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Bienvenue dans un nouvel épisode des Pépites de connaissances Microsoft
0:02
Speaker 2: ici sur M365FM. Je suis votre hôte Mirko Peters. Dans
0:05
Speaker 2: cette série, nous prenons une technologie Microsoft et nous l'expliquons
0:08
Speaker 2: en langage clair. Le sujet d'aujourd'hui est celui dont presque
0:10
Speaker 2: tout le monde a entendu parler, mais que peu savent
0:12
Speaker 2: vraiment expliquer. Les zones d'atterrissage et zones... Voici le topo.
0:15
Speaker 2: Imaginez que vous héritiez d'un tenant Azure où chaque équipe
0:17
Speaker 2: a fait ce qu'elle voulait. Pas de convention de nommage,
0:20
Speaker 2: pas de politique, pas de plan réseau, des abonnements partout.
0:23
Speaker 2: Certains en production, d'autres en test, et impossible de les distinguer.
0:25
Speaker 2: Personne ne sait qui possède quoi, la facture est un mystère,
0:28
Speaker 2: et quand quelque chose tombe en panne, il faut des
0:29
Speaker 2: heures pour trouver le problème. C'est le problème du chaos
0:31
Speaker 2: dans le cloud, et c'est étonnamment courant. Plus courant que
0:34
Speaker 2: vous ne le pensez. Les zones d'atterrissage azur sont ce
0:37
Speaker 2: qui empêchent ce désordre avant même qu'il ne compte. A
0:38
Speaker 2: la fin de cet épisode, vous comprendrez ce qu'est réellement
0:41
Speaker 2: une zone d'atterrissage, pourquoi les 8 domaines de conception comptent
0:43
Speaker 2: et comment éviter les erreurs les plus fréquentes. Prenez votre café,
0:47
Speaker 2: plongeons dans le sujet. Qu'est-ce qu'une zone d'atterrissage azur en réalité?
0:51
Speaker 2: La plupart des gens pensent qu'une zone d'atterrissage azur est
0:52
Speaker 2: un produit sur lequel on clique pour le déployer, mais
0:54
Speaker 2: ce n'est pas le cas. Il n'y a pas de
0:55
Speaker 2: bouton dans le portail qui dit créer une zone d'atterrissage.
0:57
Speaker 2: Ce n'est pas comme ça que ça fonctionne. Une zone
0:59
Speaker 2: d'atterrissage est un environnement préconfiguré avec des garde-fous déjà en place. Réseau, identité, surveillance, politique,
1:04
Speaker 2: tout est câblé avant l'arrivée des premières charges de travail.
1:07
Speaker 2: Voyez cela comme l'achat d'une maison qui possède déjà l'électricité,
1:09
Speaker 2: la plomberie et un système de sécurité. Vous emménagez simplement
1:13
Speaker 2: et commencez à travailler sans avoir à faire le câblage vous-même.
1:15
Speaker 2: L'idée principale est que l'abonnement est l'unité d'isolation, pas le
1:18
Speaker 2: groupe de ressources. Un abonnement est votre limite de rayon d'explosion.
1:22
Speaker 2: Vous donnez à une équipe un abonnement, car les abonnements
1:23
Speaker 2: comportent leurs propres limites de quotas attribution de politique et
1:26
Speaker 2: facturation des facturations. La zone d'atterrissage entoure cet abonnement, avec
1:29
Speaker 2: tout ce qui a été décidé de manière centralisée. Quelles
1:31
Speaker 2: régions sont autorisées? A quel réseau ils se connectent? Quelles
1:34
Speaker 2: balises sont obligatoires et ce qui leur est interdit de faire?
1:36
Speaker 2: Alors qu'est-ce qui applique réellement les règles? Azure Policy, pas
1:39
Speaker 2: de la documentation, ni de bonnes intentions. C'est attribué au
1:42
Speaker 2: niveau du groupe d'administration et cela remplit trois fonctions. Denis
1:44
Speaker 2: bloque des éléments comme les régions non autorisées ou les
1:46
Speaker 2: adresses IP publiques. Audit signale les ressources non conformes sans
1:49
Speaker 2: les bloquer. Deploy if not exist corrige automatiquement en déployant
1:53
Speaker 2: des éléments comme les paramètres de diagnostic pour Log Analytics
1:55
Speaker 2: ou les plans Microsoft Defender. C'est la différence entre une
1:58
Speaker 2: gouvernance qui n'est qu'une page Wiki et une gouvernance qui
2:00
Speaker 2: est du code. Les équipes avancent vite dans leur boîte,
2:02
Speaker 2: mais l'équipe plateforme contrôle la boîte, pas son contenu. Le
2:06
Speaker 2: grand changement consiste à laisser les équipes avoir leurs propres abonnements,
2:08
Speaker 2: tandis que l'équipe centrale définit les règles. Identité et gouvernance.
2:11
Speaker 2: La porte d'entrée, le livre des règles. Voici le point.
2:14
Speaker 2: Une landing zone n'est pas un élément unique, elle est
2:16
Speaker 2: composée de 8 domaines de conception. Plongeons dans les 3 premiers.
2:20
Speaker 2: Le premier concerne la facturation Azure et le tenant Entra.
2:22
Speaker 2: Il s'agit de configurer correctement votre tenant et vos abonnements
2:25
Speaker 2: dès le départ. Cela semble simple, mais vous seriez surpris
2:27
Speaker 2: du nombre d'entreprises qui se trompent. Vous devez penser à
2:30
Speaker 2: votre structure de facturation, à votre enregistrement et à la
2:33
Speaker 2: connexion avec votre tenant Entra avant tout déploiement. Votre limite
2:36
Speaker 2: de sécurité principale est la gestion des identités et des accès.
2:39
Speaker 2: Considérez Entra ID comme la réception d'un immeuble de bureau.
2:42
Speaker 2: C'est lui qui décide qui entre et ce qu'ils sont
2:43
Speaker 2: autorisés à faire. Vous devez utiliser la gestion des identités
2:46
Speaker 2: privilégiées ou PIM et appliquer des rôles RBAC à privilège minimum.
2:50
Speaker 2: Ne donnez pas un accès propriétaire à tout le monde,
2:52
Speaker 2: c'est la recette du désastre. Utilisez plutôt PIM pour accorder
2:54
Speaker 2: un accès temporaire juste à temps quand quelqu'un en a
2:56
Speaker 2: réellement besoin. Et mettez en place des revues d'accès récurrentes
2:58
Speaker 2: pour supprimer les permissions inutiles. Le troisième domaine de conception
3:02
Speaker 2: est l'organisation des ressources. Groupe d'administration, abonnement et groupe de ressources.
3:06
Speaker 2: Les groupes d'administration sont au-dessus des abonnements. Et les stratégies
3:09
Speaker 2: ainsi que les attributions de rôle se propagent vers le
3:11
Speaker 2: bas de l'arborescence. La hiérarchie de référence du Cloud Adoption
3:14
Speaker 2: Framework commence à la racine du tenant puis un groupe
3:16
Speaker 2: intermédiaire pour votre organisation. En dessous, vous avez les plateformes,
3:19
Speaker 2: les landing zones, les environnements décommissionnés et les bacs à sable.
3:22
Speaker 2: La plateforme contient vos abonnements partagés, la gestion des identités
3:25
Speaker 2: et la connectivité. Les landing zones se divisent en corps
3:28
Speaker 2: pégueux pour les charges de travail, nécessitant une connectivité sur
3:30
Speaker 2: site et un connexion pour les applications exposées à Internet.
3:33
Speaker 2: Pourquoi cette structure est-elle importante? Nous attribuons une stratégie une
3:35
Speaker 2: fois en haut de l'arborescence et tout ce qui est
3:37
Speaker 2: en dessous s'y conforme automatiquement. Exemple concret, une stratégie de
3:40
Speaker 2: refus au sommet bloque les régions non autorisées pour chaque
3:42
Speaker 2: abonnement en dessous. Vous n'avez pas à le configurer 50 fois.
3:46
Speaker 2: Définissez-le une fois et il se propage. C'est toute la
3:48
Speaker 2: puissance de la hiérarchie des groupes d'administration. Réseautage et sécurité,
3:51
Speaker 2: les murs et les serrures. L'identité et la gouvernance fixent
3:54
Speaker 2: les règles, mais rien ne fonctionne si le réseau est
3:56
Speaker 2: en désordre. La topologie réseau et la connectivité constituent le
4:00
Speaker 2: quatrième domaine de conception, soit la structure de vos réseaux virtuels.
4:02
Speaker 2: Il existe deux modèles principaux, Hub and Spoke Air, avec
4:05
Speaker 2: un réseau virtuel central en guise de Hub et plusieurs
4:07
Speaker 2: réseaux Spoke s'y connectant, ou Azure Virtual One, la version
4:11
Speaker 2: gérée de cette idée par Microsoft à plus grande échelle.
4:14
Speaker 2: Le Hub héberge tous vos services partagés. Parfeu Azure pour
4:17
Speaker 2: l'inspection du trafic, passerelle express route ou VPN pour la
4:19
Speaker 2: connectivité locale, résolution DNS, autant d'éléments nécessaires à chaque charge
4:23
Speaker 2: de travail. Les spokes sont là où vos charges de
4:25
Speaker 2: travail s'exécutent réellement. Ils se connectent au hub via peering
4:27
Speaker 2: pour que le trafic passe par les services centraux, tout
4:29
Speaker 2: en restant isolés les uns des autres. Voici une erreur courante.
4:33
Speaker 2: Les équipes créent un maillage de peering géant au lieu
4:35
Speaker 2: d'utiliser un hub en connectant directement chaque réseau virtuel aux autres.
4:39
Speaker 2: Cela fonctionne un temps, mais devient vite un chaos. Vous
4:42
Speaker 2: vous retrouvez avec une toile d'araignée de connexion que personne
4:44
Speaker 2: ne peut suivre. Un hub simplifie tout. Un seul endroit
4:47
Speaker 2: pour gérer, un seul endroit pour sécuriser. Planifiez vos plages
4:50
Speaker 2: d'adresse IP dès le départ. C'est plus important que vous
4:51
Speaker 2: ne le pensez. Une fois que les spokes sont connectés
4:54
Speaker 2: à un hub, les chevauchements d'espace d'adressage sont difficiles à corriger.
4:57
Speaker 2: Vous ne pouvez pas simplement les modifier. Vous devez supprimer
4:59
Speaker 2: le peering, mettre à jour la plage et reconnecter. Si
5:02
Speaker 2: vous avez des charges de travail en production, cela signifie
5:04
Speaker 2: un temps d'arrêt. Choisissez donc vos plages CIDR tôt et
5:06
Speaker 2: assurez-vous qu'elles ne se chevauchent pas. Le cinquième domaine de
5:08
Speaker 2: conception concerne les recommandations de sécurité, chiffrement, protection des identités,
5:11
Speaker 2: détection des menaces et gestion des vulnérabilités. Activez Microsoft Defender
5:15
Speaker 2: pour le cloud sur tous vos abonnements comme base de référence.
5:18
Speaker 2: Il vous fournit des recommandations de gestion de posture, des
5:20
Speaker 2: alertes et des conseils de remédiation pour tout votre environnement.
5:24
Speaker 2: Utilisez des points de terminaison privés pour garder les services
5:26
Speaker 2: hors de l'intérêt public. Au lieu d'accéder à un compte
5:28
Speaker 2: de stockage via une IP publique, vous lui attribuez une
5:30
Speaker 2: IP privée au sein de votre réseau virtuel. Le trafic
5:33
Speaker 2: ne quitte jamais l'épine dorsale de Microsoft. C'est plus sûr
5:35
Speaker 2: et plus simple à gérer. Placez des groupes de sécurité
5:38
Speaker 2: réseau sur chaque sous-réseau et bloquez le RDP entrant depuis
5:40
Speaker 2: Internet par défaut. Cela devrait être un an. Si quelqu'un
5:43
Speaker 2: a besoin d'un accès distant, il utilise Azure Bastion ou
5:45
Speaker 2: un serveur rebond, par une règle RDP directe. Exemple concret,
5:49
Speaker 2: une stratégie de refus qui bloque les adresses IP publiques
5:51
Speaker 2: sur les comptes de stockage. Vous assignez la stratégie au
5:53
Speaker 2: niveau du groupe d'administration, et dès que quelqu'un tente de
5:55
Speaker 2: déployer un compte de stockage avec un point de terminaison public,
5:57
Speaker 2: le déploiement échoue. Le message d'erreur explique pourquoi il doit
6:00
Speaker 2: utiliser un point de terminaison privé à la place. Sans exception.
6:03
Speaker 2: C'est une gouvernance qui fonctionne vraiment, pas juste une suggestion
6:06
Speaker 2: dans un document. Gestion, gouvernance et automatisation, maintenir le fonctionnement.
6:10
Speaker 2: Vous avez votre bâtiment avec des murs et des serrures,
6:12
Speaker 2: mais que se passe-t-il réellement à l'intérieur? Vous devez avoir
6:14
Speaker 2: un œil sur tout. Le sixième domaine de conception est
6:16
Speaker 2: la gestion. Il s'agit de la surveillance, des sauvegardes, de
6:18
Speaker 2: la journalisation et du côté opérationnel. Vous voulez un espace
6:21
Speaker 2: de travail Log Analytics central où chaque abonnement envoie ses journaux.
6:24
Speaker 2: Un lieu unique pour tout interroger, configurer des alertes et
6:26
Speaker 2: résoudre les problèmes. C'est l'objectif. Maintenant, comment vous assurer que
6:29
Speaker 2: chaque ressource envoie ses journaux de diagnostic là-bas? Vous ne
6:32
Speaker 2: le faites pas manuellement. Vous créez une stratégie qui dit,
6:34
Speaker 2: chaque ressource doit envoyer ses journaux de diagnostic vers cet
6:36
Speaker 2: espace de travail Log Analytics Maco. et vous configurez cette
6:39
Speaker 2: stratégie pour s'exécuter en mode déploiement sin existant. Résultat, toute
6:42
Speaker 2: nouvelle ressource est configurée automatiquement. Personne n'a besoin d'y penser.
6:45
Speaker 2: Cela arrive tout simplement. La septième zone de conception est
6:47
Speaker 2: la gouvernance, qui utilise Azure Policy pour assurer la conformité.
6:49
Speaker 2: Vous regroupez les règles associées dans ce qu'on appelle une
6:51
Speaker 2: initiative de stratégie ou un jeu de stratégie. Une initiative
6:54
Speaker 2: pour la sécurité, une autre pour la gestion des coûts.
6:57
Speaker 2: Chacune contient plusieurs stratégies qui fonctionnent ensemble. Voici un exemple.
7:01
Speaker 2: Un jeu de stratégie qui impose le chiffrement, le balisage
7:04
Speaker 2: et les tailles de machines virtuelles autorisées. Vous l'appliquez au
7:06
Speaker 2: niveau du groupe d'administration. Chaque abonnement en dessous hérite de
7:09
Speaker 2: ses règles. Lorsqu'un développeur tente de déployer une machine virtuelle,
7:13
Speaker 2: la stratégie vérifie qu'elle utilise une taille approuvée, possède des
7:15
Speaker 2: étiquettes requises et utilise des disques chiffrés. Si une vérification échoue,
7:19
Speaker 2: le déploiement est bloqué ou signalé immédiatement. Soyons clairs sur
7:22
Speaker 2: la différence entre une gouvernance qui vit sur une page
7:24
Speaker 2: Wiki et une gouvernance qui est du code réel. Une
7:26
Speaker 2: page Wiki dit« étiquetez vos ressources». La stratégie dit« vous
7:29
Speaker 2: ne pouvez pas déployer de ressources sans les étiquettes requises».
7:32
Speaker 2: L'une est une suggestion, l'autre est appliquée automatiquement. La huitième
7:36
Speaker 2: zone de conception est l'automatisation de la plateforme et le DevOps.
7:39
Speaker 2: L'infrastructure en tant que code et les pipelines CI-CD. Traiter
7:42
Speaker 2: la landing zone elle-même comme du code. Cela signifie Bicep,
7:45
Speaker 2: des modèles ARM ou Terraform stockés dans le contrôle de source.
7:48
Speaker 2: Chaque changement passe par une pull request. Chaque déploiement passe
7:51
Speaker 2: par un pipeline. Plus besoin de cliquer partout dans le
7:52
Speaker 2: portail azur. C'est là qu'intervient le cas subscription running. Un
7:55
Speaker 2: pipeline reproductible qui crée de nouveaux abonnements à la demande.
7:58
Speaker 2: Une équipe soumet une demande avec des paramètres comme le
8:00
Speaker 2: centre de coût, la taille du réseau et le type d'environnement.
8:03
Speaker 2: Le pipeline crée l'abonnement, le place dans le bon groupe d'administration,
8:06
Speaker 2: attribue les budgets, configure le réseau Spoke et le connecte
8:09
Speaker 2: au hub. Tout est automatisé. Pourquoi est-ce important? Parce que
8:14
Speaker 2: le nouvel abonnement est conforme dès l'instant où il existe.
8:17
Speaker 2: Les stratégies sont déjà sur le groupe d'administration et l'abonnement
8:19
Speaker 2: hérite automatiquement de tout. Il n'y a pas de période
8:22
Speaker 2: où il n'est pas gouverné. Personne n'a besoin de penser
8:24
Speaker 2: à appliquer les règles. Elles sont déjà là. C'est ce
8:27
Speaker 2: qui permet à une équipe de plateforme de prendre en
8:28
Speaker 2: charge des centaines d'abonnements sans devenir un goulot d'étranglement. L'automatisation
8:32
Speaker 2: effectue le travail difficile et l'équipe se concentre sur l'amélioration
8:34
Speaker 2: de la plateforme au lieu de cliquer dans le portail
8:36
Speaker 2: pour chaque demande. La séparation entre plateforme et application, la
8:40
Speaker 2: confusion la plus courante. Voilà donc les 8 zones de conception,
8:43
Speaker 2: mais c'est là que la plupart des gens se trompent.
8:45
Speaker 2: Il existe deux types de landing zones et les confondre
8:47
Speaker 2: est l'erreur la plus fréquente que je vois. Les landing
8:49
Speaker 2: zones de plateforme et les landing zones d'application. Elles servent
8:52
Speaker 2: des objectifs complètement différents. Les landing zones de plateforme sont
8:54
Speaker 2: la fondation partagée possédée par l'équipe de plateforme. Vous disposez
8:57
Speaker 2: d'un abonnement d'identité pour vos services de domaine, un abonnement
8:59
Speaker 2: de gestion. Avec Log Analytics et des comptes d'automatisation et
9:02
Speaker 2: d'un abonnement de connectivité pour le réseau virtuel Hub, Azure
9:05
Speaker 2: Firewall et les passerelles Express. io ou VPN. Et ce sont
9:09
Speaker 2: les services partagés dont dépendent toutes les charges de travail.
9:11
Speaker 2: Les zones d'atterrissage d'applications sont les lieux où s'exécutent les
9:13
Speaker 2: charges de travail. Ce sont les abonnements attribués aux équipes applicatives.
9:17
Speaker 2: Sans nombre, ils sont jetables. Et ils suivent toujours le
9:20
Speaker 2: même modèle. Une équipe obtient un abonnement. Il est placé
9:23
Speaker 2: sous bon groupe d'administration, il hérite des stratégies, il se
9:25
Speaker 2: connecte au réseau hub et le déploiement commence. La différence
9:28
Speaker 2: de propriété est importante. Les zones de plateforme sont peu nombreuses,
9:31
Speaker 2: peut-être 3 à 5 abonnements au total. Elles ont une
9:33
Speaker 2: longue durée de vie et sont gérées de manière centralisée
9:35
Speaker 2: par l'équipe plateforme. Les zones d'application sont nombreuses. Vous pouvez
9:37
Speaker 2: en avoir des dizaines ou des centaines. Elles sont temporaires.
9:40
Speaker 2: Une charge de travail est déployée, fonctionne un moment, puis
9:42
Speaker 2: est mise hors service. L'abonnement est nettoyé et le modèle
9:44
Speaker 2: se répète. Voici l'antimodèle classique. Quelqu'un place un pare-feu partagé
9:49
Speaker 2: dans un abonnement applicatif ou déploie la passerelle express route
9:51
Speaker 2: dans un abonnement de charge de travail au lieu de
9:53
Speaker 2: l'abonnement de connectivité. Désormais, les services partagés sont dispersés dans
9:57
Speaker 2: tout l'environnement. Personne ne sait où se trouve quoi. L'équipe
10:00
Speaker 2: plateforme ne peut pas gêner le pare-feu car il est
10:01
Speaker 2: dans l'abonnement d'un autre et l'équipe applicative ne veut pas l'entretenir.
10:05
Speaker 2: C'est un désordre total. Gardez les services partagés dans la
10:07
Speaker 2: couche plateforme. L'abonnement de connectivité héberge le réseau virtuel Hub,
10:11
Speaker 2: Azure Firewall et la passerelle ExpressRoute. Les abonnements applicatifs s'y
10:14
Speaker 2: connectent par pairing. Ils ne possèdent rien de tout cela.
10:17
Speaker 2: se contentent de l'utiliser. Ce que cela signifie pour vous,
10:19
Speaker 2: c'est une séparation claire des responsabilités. L'équipe plateforme contrôle le cadre,
10:22
Speaker 2: les garde-fous, les services partagés, et les stratégies, et les stratégies.
10:26
Speaker 2: Les équipes applicatives évoluent rapidement à l'intérieur. Elles obtiennent un abonnement,
10:29
Speaker 2: déjà conformes, déjà connectées, déjà surveillées. Elles n'ont pas à
10:31
Speaker 2: se soucier des fondations. Elles construisent simplement par-dessus. Comment les
10:35
Speaker 2: éléments s'articulent? Le déclic. Vous connaissez maintenant les briques individuelles,
10:39
Speaker 2: mais voici ce qui compte vraiment. Elles ne fonctionnent pas
10:41
Speaker 2: de manière isolée. Elles fonctionnent ensemble comme un système connecté.
10:44
Speaker 2: Et c'est là que tout prend du sens. Vous voyez
10:46
Speaker 2: les choses sous satin. L'identité décide qui peut franchir la
10:48
Speaker 2: porte d'entrée. La gouvernance leur indique ensuite dans quelles pièces
10:51
Speaker 2: ils sont autorisés à entrer. Le réseau contrôle la façon
10:54
Speaker 2: dont ils circulent entre ces pièces. La sécurité surveille les
10:57
Speaker 2: menaces à chaque coin de rue. La gestion assure le
10:59
Speaker 2: bon fonctionnement de l'ensemble du bâtiment. Et l'automatisation rend chaque
11:02
Speaker 2: étape répétable afin que rien ne soit oublié. Chaque pièce
11:05
Speaker 2: dépend des autres et ensemble, elle crée quelque chose de
11:07
Speaker 2: bien plus vaste que la somme de ses parties. Laissez-moi
11:09
Speaker 2: vous donner un exemple concret du fonctionnement de cette interaction.
11:12
Speaker 2: Imaginez qu'une nouvelle équipe doive déployer une charge de travail.
11:14
Speaker 2: Elle soumet une demande via le pipeline de distribution d'abonnements,
11:17
Speaker 2: qui crée automatiquement un tout nouvel abonnement. Il place cet
11:21
Speaker 2: abonnement dans le bon groupe d'administration, ce qui signifie qu'il
11:23
Speaker 2: hérite immédiatement de toutes les stratégies de ce groupe. Exigences
11:28
Speaker 2: de chiffrement, régions autorisées, tags obligatoires, configurations de journalisation, tout
11:31
Speaker 2: ce dont il a besoin. Le pipeline configure également le
11:35
Speaker 2: réseau Spock et le connecte au hub par pyrénées. Les
11:37
Speaker 2: paramètres de diagnostic envoient les journaux directement à l'espace de
11:40
Speaker 2: travail log analytique centralisé, tandis que Defender for Cloud active
11:43
Speaker 2: la protection L'abonnement entier finit par être conforme, connecté et
11:46
Speaker 2: surveillé en quelques minutes sans aucune intervention humaine. C'est la
11:50
Speaker 2: véritable différence entre le chaos dans le cloud et le
11:52
Speaker 2: contrôle du cloud. Dans l'environnement désordonné que j'ai décrit au début,
11:55
Speaker 2: chacune de ces étapes dépend de quelqu'un qui doit y
11:57
Speaker 2: penser et les gens oublient. Ou ils le font différemment
12:00
Speaker 2: à chaque fois, ou ils ne le font pas du tout.
12:03
Speaker 2: Avec une zone d'atterrissage appropriée, tout est automatique. Le système
12:06
Speaker 2: s'applique de lui-même et l'équipe peut avancer rapidement sans rien casser.
12:09
Speaker 2: C'est là que la plupart des organisations trébuchent. Elles traitent
12:11
Speaker 2: la zone d'atterrissage comme un projet ponctuel. La déploie, coche
12:14
Speaker 2: la case et passe à autre chose. Pourtant, une zone
12:16
Speaker 2: d'atterrissage est une plateforme vivante. Azure publie constamment de nouvelles fonctionnalités.
12:19
Speaker 2: Vos exigences de conformité évoluent avec le temps. Votre entreprise
12:22
Speaker 2: se développe. La zone d'atterrissage doit grandir avec elle, sinon
12:24
Speaker 2: elle commence à jouer contre vous. Le modèle opérationnel compte
12:26
Speaker 2: en réalité plus que les modèles techniques. Qui est responsable
12:29
Speaker 2: de la zone d'atterrissage? Comment évolue-t-elle? Comment les exceptions sont-elles gérées?
12:32
Speaker 2: Si votre seule réponse est qu'un équipe plateforme la gère rugueux,
12:34
Speaker 2: ce n'est pas suffisant. Vous avez besoin de véritables processus.
12:36
Speaker 2: Vous avez besoin d'un backlog approprié. Vous devez traiter la
12:38
Speaker 2: zone d'atterrissage comme un produit, pas comme un projet. Voici
12:40
Speaker 2: un exemple concret. Une équipe plateforme prend en charge 200
12:43
Speaker 2: abonnements sans devenir un goulot d'étranglement. Et le secret réside
12:46
Speaker 2: dans la distribution d'abonnements combinée à l'héritage des stratégies. L'équipe
12:49
Speaker 2: ne clique pas dans le portail pour créer chaque abonnement.
12:52
Speaker 2: Le pipeline gère cela automatiquement. Il ne configure pas manuellement
12:55
Speaker 2: la journalisation pour chaque chat de travail. La stratégie l'impose
12:57
Speaker 2: de manière cohérente. Il ne vérifie pas chaque déploiement pour
12:59
Speaker 2: la conformité. Le tableau de bord de conformité leur montre
13:01
Speaker 2: simplement les exceptions. Il se concentre sur les anomalies plutôt
13:04
Speaker 2: que sur le travail routinier. C'est là toute la différence
13:06
Speaker 2: entre une plateforme qui évolue et une qui étrangle l'entreprise.
13:10
Speaker 2: Point à retenir. Comment ces petits grandissent intelligemment? Alors que
13:13
Speaker 2: faites-vous concrètement lundi matin? Voici la réponse honnête. N'essayez pas
13:17
Speaker 2: de construire toute la hiérarchie à l'échelle de l'entreprise dès
13:19
Speaker 2: le premier jour. C'est un piège que vous voulez éviter.
13:22
Speaker 2: Vous passerez des mois à concevoir des scénarios qui ne
13:23
Speaker 2: se produiront peut-être jamais, sans jamais. Rien livré de concret.
13:26
Speaker 2: Commencez plutôt par une zone d'atterrissage minimale viable, ou MVLZ.
13:31
Speaker 2: Les composants principaux sont simples. Une hiérarchie de groupes d'administration,
13:35
Speaker 2: quelques politiques clés comme les restrictions de région, le chiffrement
13:37
Speaker 2: et les tags obligatoires. Un réseau de base avec un
13:39
Speaker 2: hub et un SPOC et une journalisation centralisée vers un
13:42
Speaker 2: espace de travail log analytics. Cela suffit. Vous n'avez pas
13:46
Speaker 2: besoin d'Azure Virtual One dès le premier jour, ni d'une
13:48
Speaker 2: initiative de politique complexe contenant 200 règles. Il vous suffit
13:51
Speaker 2: d'avoir assez de garde-fous pour être en sécurité. Rien de plus. Ensuite,
13:54
Speaker 2: intégrez votre première charge de travail réelle dans cet MVLZ.
13:57
Speaker 2: Pas une machine virtuelle de test, mais une charge importante
13:59
Speaker 2: pour votre équipe. Observez le comportement des politiques. Voyez ce
14:02
Speaker 2: qui bloque. Apprenez des frictions, puis itérez à partir de là.
14:05
Speaker 2: Ajoutez des politiques au besoin et tendez. Le réseau quand
14:08
Speaker 2: c'est nécessaire et laissez la zone d'atterrissage évoluer naturellement avec
14:10
Speaker 2: votre organisation. Laissez-moi vous donner trois points concrets que vous
14:13
Speaker 2: pouvez mettre en œuvre dès maintenant. Premier point, déployer l'accélérateur
14:17
Speaker 2: Azure Loading Zones depuis le portail vers un tenant de test.
14:20
Speaker 2: Cela ne coûte rien, prend environ une heure et vous
14:22
Speaker 2: apprendra plus sur le fonctionnement des groupes d'administration, des politiques
14:25
Speaker 2: et de l'héritage que n'importe quel diagramme ou documentation. Vous
14:29
Speaker 2: pouvez voir la hiérarchie, observer l'application des politiques en temps
14:32
Speaker 2: réel et expérimenter sans rien casser d'important. Deuxième point, activez
14:37
Speaker 2: les politiques en mode audit d'abord, pas en refus. Le
14:40
Speaker 2: mode audit vous permet de voir exactement ce qui n'est
14:41
Speaker 2: pas conforme dans votre environnement sans bloquer personne. Consultez le
14:45
Speaker 2: tableau de bord de conformité et je vous promets que
14:47
Speaker 2: vous serez surpris par le nombre de ressources enfreignantes discrètement
14:49
Speaker 2: les règles qui semblaient évidentes. Une fois que vous comprenez
14:51
Speaker 2: votre environnement, vous pourrez passer les politiques importantes en mode refus.
14:55
Speaker 2: Mais commencez par l'audit afin de ne pas bloquer vos
14:57
Speaker 2: équipes avant de savoir à quoi vous avez affaire. Troisième point,
15:01
Speaker 2: planifiez vos plages d'adresse IP et votre hiérarchie de groupe
15:03
Speaker 2: d'administration avant tout déploiement. Je sais que cela semble ennuyeux,
15:07
Speaker 2: mais les modifier plus tard est vraiment pénible. Des plages
15:09
Speaker 2: IP qui se chevauchent impliquent de supprimer le peering réseau
15:12
Speaker 2: et restructurer les groupes d'administration signifie déplacer des abonnements et
15:15
Speaker 2: réévaluer les politiques. Réussissez ces deux points dès le départ
15:18
Speaker 2: et vous économiserez des semaines de retravail par la suite.
15:20
Speaker 2: Les pièges courants sont assez simples. La suringénierie mène à
15:23
Speaker 2: une paralysie analytique qui vous empêche de jamais déployer. La
15:27
Speaker 2: sous-ingénierie vous laisse sans aucun garde-fou, ce qui n'est que
15:29
Speaker 2: du chaos cloud sous un autre nom. Et traitez la
15:31
Speaker 2: zone d'atterrissage comme un projet ponctuel au lieu d'une plateforme
15:34
Speaker 2: vivante garantie que vous serez à la traîne. Évitez ces
15:36
Speaker 2: trois pièges et vous aurez déjà une longueur d'avance sur
15:38
Speaker 2: la plupart des organisations. N'oubliez pas, l'objectif n'est pas d'avoir
15:40
Speaker 2: une zone d'atterrissage partout. L'objectif est une base gouvernée qui
15:42
Speaker 2: permet aux équipes d'avancer vite sans créer de chaos. Commencez petit,
15:46
Speaker 2: itérez et laissez les politiques faire le travail pour vous.
15:49
Speaker 2: Voilà donc les zones d'atterrissage Azure, expliquez simplement. Ce n'est
15:51
Speaker 2: pas un concept d'entreprise complexe. Voyez-les comme un abonnement gouverné
15:55
Speaker 2: avec des garde-fous intégrés. Les huit domaines de conception sont
15:58
Speaker 2: simplement les questions à résoudre avant de déployer. Identité, réseau, sécurité, gestion, gouvernance, automatisation.
16:05
Speaker 2: Répondez une fois, intégrez-les à la base et chaque charge
16:07
Speaker 2: de travail en bénéficiera. Voici la meilleure chose à faire
16:10
Speaker 2: dès maintenant. Déployez l'accélérateur dans un tenant de test et
16:13
Speaker 2: observez l'héritage des politiques. Cette heure vous apprendra plus que
16:16
Speaker 2: n'importe quel diagramme. Abonnez-vous pour d'autres explications simples comme celle-ci
16:19
Speaker 2: et laissez un commentaire si vous avez compris. Je les
16:21
Speaker 2: lis tous.