Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article fournit une orientation rapide avec un objectif de démarrage sur cinq piliers de plateforme fondamentale : calcul, mise en réseau, stockage, conteneurs et données. Pour chaque pilier, vous obtenez un court tableau de décision qui associe votre situation à un service par défaut, ainsi qu’une note indiquant à quel moment reconsidérer ce choix à mesure que votre startup se développe.
Dans cet article, vous allez apprendre à
- Choisissez les primitives Azure de calcul, de mise en réseau et de stockage appropriées pour votre étape.
- Déterminez si Azure Kubernetes Service est la plateforme de conteneur appropriée pour votre étape, et ce qu'il faut utiliser à la place si ce n'est pas le cas.
- Choisissez une plateforme de données unique pour les charges de travail relationnelles, documentaires, vectorielles et analytiques.
- Appliquez un petit ensemble de paramètres par défaut en matière de coût, de fiabilité et de sécurité, qui restent pertinents à mesure que vous évoluez.
- Reconnaître les signaux qui vous indiquent qu’un choix par défaut a dépassé son utilité.
Prerequisites
- Un abonnement Azure actif.
- Le Azure CLI installé et connecté. Pour vous connecter, exécutez
az login. - Accès propriétaire ou contributeur sur au moins un groupe de ressources.
- La connaissance de la page d’accueil du portail Azure est utile, mais pas nécessaire.
- Connaissance de base de Azure notions de base (régions, abonnements et groupes de ressources).
Pourquoi cela compte pour les start-ups
Dans une startup en phase de démarrage, le coût d’un mauvais choix d’infrastructure, ce n’est pas la facture. C’est la semaine que vous perdez à migrer depuis le mauvais service après avoir tout construit autour de lui. Les cinq piliers de cet article sont ceux pour lesquels les conséquences d’un mauvais choix par défaut ont tendance à se cumuler : une mauvaise plateforme de calcul façonne votre pipeline de déploiement ; une mauvaise base de données contraint votre modèle de données ; une mauvaise topologie réseau bloque votre premier client entreprise. Vous n’avez pas besoin d’une équipe de plateforme, d’un ingénieur de fiabilité de site ou d’un spécialiste des opérations financières pour faire ces choix bien. Vous avez besoin d’une valeur par défaut suffisamment bonne pour être livrée, ainsi que d’un signal clair vous indiquant quand la réexaminer. Si votre startup participe au programme Microsoft for Startups, les mêmes paramètres par défaut permettent à vos crédits d’aller plus loin et vous permettent de rester éligible à des avantages supplémentaires par la suite.
Calcul : où votre code s’exécute
Azure a plus d’une douzaine de services de calcul. Les bonnes nouvelles : pour la plupart des charges de travail de première étape, trois d’entre elles couvrent ce dont vous avez besoin.
| Votre situation | Service Azure par défaut | Pourquoi | Revenir quand |
|---|---|---|---|
| Application web ou API HTTP, un ou deux services, vous souhaitez un runtime managé | Azure App Service (Linux) | Aucune build de conteneur n’est requise. Tls intégré, domaines personnalisés, emplacements de déploiement et mise à l’échelle automatique. Les offres gratuites et de base sont assez abordables pour faire fonctionner un environnement de préproduction, bien que les slots et la mise à l’échelle automatique nécessitent l’offre Standard ou une offre supérieure. | Vous souhaitez exécuter plus d’une poignée de services, avez besoin d’une mise à l’échelle par service ou de sidecars. |
| Fonction pilotée par les événements, travail planifié ou gestionnaire de webhook | Azure Functions (plan consommation) | Paiement à l’exécution. Passe à zéro. Les liaisons suppriment la plupart du code de collage pour les files d’attente, les objets blob et les déclencheurs HTTP. | Les démarrages à froid augmentent la latence perçue par l’utilisateur, ou vous dépassez les limites de l’offre Consommation. |
| Microservices conteneurisés, vous souhaitez un environnement d’exécution clé en main sans avoir à gérer Kubernetes | Azure Container Apps | Basé sur Kubernetes avec la mise à l’échelle automatique basée sur KEDA, mais vous ne gérez pas le cluster. Dapr est disponible en tant qu’intégration facultative. Mise à l’échelle à zéro, révisions et entrée HTTPS incluses. | Vous avez besoin d’un contrôle au niveau du cluster, d’un planificateur personnalisé ou d’un réseau avancé. |
| Traitement par lots long, entraînement GPU ou lift-and-shift d’une charge de travail de machine virtuelle existante | Machines virtuelles Azure | Contrôle complet du système d’exploitation. Utilisez un groupe de machines virtuelles identiques lorsque vous avez besoin d’une mise à l’échelle horizontale. | La surcharge opérationnelle de la mise à jour corrective et de la gestion des images commence à ralentir l’expédition. |
| Vous êtes sûr que vous avez besoin de Kubernetes (voir la section 4 avant de supposer cela) | Azure Kubernetes Service | Plan de contrôle managé. Correspond aux équipes qui ont déjà une expérience Kubernetes ou des exigences de plateforme spécifiques. | Consultez la section Conteneurs pour connaître les critères de décision AKS. |
Tip
Commencez par App Service pour votre première application web orientée utilisateur et Azure Functions pour tout ce qui est piloté par les événements. Vous pourrez passer plus tard à Azure Container Apps ou à Azure Kubernetes Service sans modifier le code de votre application, si vous conservez l’application sans état et stockez la configuration dans des variables d’environnement.
Choix entre Container Apps et App Service
Container Apps et App Service se recoupent. Le critère décisif, en toute franchise : si votre application s’exécute déjà sous forme d’image conteneur et que vous souhaitez une mise à l’échelle par service (avec un nombre de réplicas différent pour la couche web et pour le service de traitement), Container Apps l’emporte. Si votre application est un processus web unique et que vous ne souhaitez pas conserver un fichier Dockerfile, App Service gagne.
Avertissement
Envisagez Azure Kubernetes Service lorsque vous avez des exigences claires qui ne sont pas remplies par des options plus simples. Bien qu’il offre une flexibilité et un contrôle forts, il introduit également des considérations opérationnelles supplémentaires (comme les mises à niveau, le dimensionnement du pool de nœuds, la configuration d’entrée et la gestion des certificats). Si elle est adoptée trop tôt, les équipes trouvent souvent plus de temps dans la gestion de la plateforme que la création de fonctionnalités de produit.
Réseau : ce qu’il faut configurer le premier jour
La plupart des premières Azure charges de travail n'ont pas besoin d'un réseau virtuel le jour 1. App Service, Functions, Container Apps et la plupart des bases de données gérées vous donnent des points de terminaison publics avec TLS qui sont sûrs à exposer, tant que vous définissez l’authentification correctement. L’ajout de la complexité réseau avant d’avoir une raison est l’optimisation prématurée la plus courante sur Azure.
| Votre situation | Approche par défaut | Pourquoi | Revenir quand |
|---|---|---|---|
| Toute nouvelle application, trafic web public, aucune exigence de conformité | Utilisez le point de terminaison public avec TLS. Aucun réseau virtuel. | Surcharge opérationnelle la plus faible. App Service, Container Apps et bases de données managées gèrent TLS pour vous. Utilisez Microsoft Entra ID pour l’authentification. | Votre premier client d’entreprise demande une connectivité privée. |
| Vous avez besoin d’une connexion privée entre votre application et une base de données managée | Intégration de réseau virtuel côté calcul, point de terminaison privé côté base de données | Le trafic reste sur le réseau fédérateur de Microsoft. Aucune exposition publique pour la base de données. Même service managé, aucune modification de l’application. | Jour 1 si vous gérez les données protégées ; sinon, lorsqu’un audit ou un client demande. |
| Vous avez besoin d’un point d’entrée public unique qui sert de point d’accès à plusieurs services back-end, avec routage, terminaison TLS et pare-feu applicatif web. | Azure Front Door (global) ou Azure Application Gateway (régional) | Front Door ajoute un réseau de distribution de contenu global et une mise en cache de périphérie. Application Gateway est l’option native de réseau virtuel régional. | Vous avez dépassé le protocole TLS et le routage intégrés d’App Service. |
| Vous avez besoin d’adresses IP statiques sortantes (une liste d’autorisation chez un prestataire de paiement, par exemple) | Passerelle NAT attachée à votre réseau virtuel | Adresse IP sortante prévisible. Requis par de nombreuses API tierces. | Un fournisseur en a besoin. Ne l’ajoutez pas de façon spéculative. |
| Topologie multirégion ou multi-compte | Peering de réseau virtuel ou Azure Virtual WAN | L’architecture réseau réelle commence ici. Hors de portée pour la plupart des équipes en phase d’exploration. | La multirégion est une exigence réelle, et non une aspiration. |
Important
Sécurisez Microsoft Entra ID et vos attributions de rôles au niveau de l’abonnement avant de vous préoccuper de l’isolation réseau. La plupart des incidents de sécurité Azure chez les petites entreprises proviennent d’une identité sur-autorisée, et non d’une exposition réseau. Utilisez les groupes Microsoft Entra ID pour les accès d’ingénierie, et n’attribuez pas le rôle Propriétaire au niveau de l’abonnement.
Stockage : objets blob, fichiers et disques
stockage Azure est un type de ressource unique (le compte de stockage) qui expose quatre services de données : objets blob, fichiers, files d’attente et tables. Pour les décisions de stockage d’applications, vous choisissez presque toujours entre les objets blob (stockage d’objets), les fichiers (partages de fichiers managés) et les disques managés (stockage de blocs attaché à une machine virtuelle).
| Ce que vous stockez | Service Azure par défaut | Pourquoi | Revenir quand |
|---|---|---|---|
| Fichiers chargés par l’utilisateur, rapports générés, journaux d’activité, artefacts de modèle, sauvegardes | Stockage Blob Azure (niveau d’accès chaud) | Stockage d’objets. Économique, durable, évolutif jusqu’à plusieurs pétaoctets. Utilisez ultérieurement des niveaux de stockage froids ou d’archivage pour les données que vous consultez rarement. | Vous avez besoin d’une sémantique de fichier POSIX ou d’une lecture-écriture aléatoire dans un fichier unique à partir de plusieurs ordinateurs. |
| Un système de fichiers partagé monté par plusieurs machines virtuelles ou conteneurs | Azure Files (Standard) ou Azure NetApp Files (débit élevé) | Volumes partagés SMB (Server Message Block) ou NFS (Network File System). Évitez d’utiliser ces éléments pour le contenu qui correspond au modèle d’objet blob. | Vous commencez à utiliser un partage de fichiers en tant que file d’attente ou base de données. Passez à la primitive de droite. |
| Disques d’une machine virtuelle | SSD Premium v2 disques managés | Performances ajustables, bon rapport qualité-prix pour les disques pour applications. Ssd Premium v2 ne peut pas être utilisé comme disque du système d’exploitation ; associez-le à SSD Premium (v1) ou SSD Standard pour le système d’exploitation. Ssd Standard est acceptable pour les charges de travail à faible débit. | Vous avez besoin d’un stockage de blocs partagés sur des machines virtuelles (utilisez Azure Elastic SAN ou Azure NetApp Files). |
| Ressources de site web statiques (bundle d’applications monopage, site marketing, documentation) | stockage Azure hébergement de sites web statiques + Azure Front Door | Static Web Apps est le choix moderne par défaut : domaines personnalisés intégrés, TLS géré gratuitement, distribution mondiale, CI/CD avec GitHub Actions et authentification intégrée. Le site web statique de stockage + Front Door fonctionne toujours pour les configurations très peu coûteuses, mais ne prend pas en charge en mode natif les en-têtes personnalisés ou l’authentification. | Vous ajoutez des pages rendues par le serveur. Accédez à App Service ou Container Apps. |
Note
Les comptes de stockage ont une limite réversible de 250 par région par abonnement (pouvant atteindre 500 par demande). C’est beaucoup pour les équipes de première étape. L’erreur d’éviter est de créer un compte de stockage par microservice ; regrouper par environnement (production, préproduction, développement) et par modèle d’accès (chaud, froid, archive) à la place.
Remarque sur les sauvegardes
Sauvegarde Azure et les options de redondance de compte de stockage (stockage localement redondant, stockage redondant interzone, stockage géoredondant) sont paramétrables par compte et par disque. Le stockage localement redondant (LRS) convient au développement et à la préproduction. Utilisez le stockage redondant interzone (ZRS) pour les données de production. Le stockage géoredondant ajoute des coûts et n’est pas un substitut à la récupération d’urgence au niveau de l’application.
Conteneurs et Azure Kubernetes Service
Azure a trois façons d’exécuter des conteneurs en production : Azure Container Apps, Azure Container Instances et Azure Kubernetes Service. Ils correspondent à différentes tailles d’équipe et aux appétits opérationnels.
| Votre situation | Service Azure par défaut | Pourquoi | Quand ça commence à faire mal |
|---|---|---|---|
| Vous avez des images de conteneurs et vous souhaitez un environnement d’exécution managé avec un point d’entrée HTTPS, une mise à l’échelle jusqu’à zéro et des révisions | Azure Container Apps | Plateforme serverless sur Kubernetes avec mise à l’échelle automatique KEDA, mais vous ne voyez pas ou ne gérez pas le cluster. Payez pour ce qui s’exécute. Bon ajustement jusqu’à ce que vous atteignez les exigences au niveau du cluster. Dapr est disponible en tant qu’intégration optionnelle. | Vous avez besoin de planificateurs personnalisés, de mise en réseau avancée (plusieurs cartes d’interface réseau, de plug-ins d’interface réseau de conteneur personnalisés) ou d’opérateurs Kubernetes spécifiques. |
| Vous souhaitez exécuter un seul conteneur en tant que travail unique ou un lot court | Azure Container Instances | Le chemin le plus rapide entre l’image et le conteneur en cours d’exécution. Aucune orchestration. Facturé par seconde du runtime. | Vous avez besoin de tout ce qui ressemble à un maillage de service ou à une mise à l’échelle automatique au-delà d’un seul conteneur. |
| Vous utilisez déjà Kubernetes ailleurs, ou votre architecture d’application nécessite réellement | Azure Kubernetes Service | Plan de contrôle managé. Apportez vos propres pools de nœuds, plug-in réseau, contrôleur d’entrée et pile d’observabilité. | Jour 1. Planifiez les mises à niveau en cours (version mineure publiée tous les 4 mois), le réglage du pool de nœuds et la gestion des certificats. |
| Vous ne savez pas si vous avez besoin de Kubernetes | Container Apps pour le moment | Vous pouvez reconstruire sur Azure Kubernetes Service ultérieurement si nécessaire. La migration d’une application sans état conteneurisée prend quelques jours, pas des semaines. | Vous avez un besoin concret (écosystème d’opérateurs, stratégie au niveau du cluster) que vous pouvez nommer. « La pérennisation » n’est pas un besoin concret. |
Quand obtenir un diplôme à AKS
Passez à Azure Kubernetes Service (AKS) quand au moins deux d’entre eux sont vrais :
- Vous exécutez plus de dix services avec des problèmes de cycle de vie partagé et de mise en réseau.
- Vous avez besoin de contrôleurs personnalisés, de sidecars ou de définitions de ressources personnalisées (CRD) que Container Apps n’expose pas.
- Vous avez besoin d’une intégration de réseau virtuel profond avec une application stricte des stratégies.
- Vous standardisez sur un écosystème open source basé sur Kubernetes (Argo, Istio, KEDA, etc.).
Si vous adoptez AKS, suivez l’architecture de base AKS. L’infrastructure Microsoft Azure Well-Architected et la référence de base AKS couvrent ensemble les valeurs par défaut de sécurité, de mise à l’échelle et de mise à niveau souhaitées.
Valeurs par défaut d’AKS pour une petite équipe
| Setting | Par défaut | Pourquoi |
|---|---|---|
| Taille du nœud | pool système Standard_D4s_v5, pool utilisateur Standard_D8s_v5 | Rapport prix-performance prévisible pour les charges de travail générales |
| Autoscaler de clusters | Enabled | Éviter de payer pour les nœuds inactifs |
| Identité de charge de travail | Enabled | Remplace l’identité pod, s’intègre à Microsoft Entra ID |
| module complémentaire Azure Policy | Enabled | Garde-fous gratuits (aucun conteneur privilégié, étiquettes requises) |
| Aperçus sur les conteneurs | Enabled | Métriques et journaux de première classe dans Azure Monitor |
| Cluster privé | Activé pour la production | Plan de contrôle accessible uniquement à partir du réseau virtuel |
Azure Container Registry (Service d'enregistrement de conteneurs Azure)
Quelle que soit la plateforme de calcul choisie, stockez vos images dans Azure Container Registry. Le niveau De base est suffisant pour les équipes en phase anticipée. Utilisez un registre distinct par environnement (production, préproduction) si vous souhaitez une isolation matérielle ou un registre unique avec des référentiels distincts et un contrôle d’accès en fonction du rôle si vous souhaitez simplifier.
Plateforme de données : relationnel, document, vecteur, analytique
Les décisions relatives à la plateforme de données sont les plus susceptibles d’être permanentes. Le schéma que vous livrez au cours du premier mois façonne chaque fonctionnalité des deux années à venir. Choisissez une valeur par défaut suffisamment flexible pour croître avec le produit et résistez à la tentation de pré-choisir une base de données spécialisée pour une fonctionnalité que vous n’avez pas encore créée.
| Votre charge de travail | Service Azure par défaut | Pourquoi | Revenir quand |
|---|---|---|---|
| Données d’application transactionnelle (utilisateurs, commandes, contenu) avec un schéma relationnel connu | Azure Database pour PostgreSQL (serveur flexible) | Écosystème d’extension mature, largement compris et fort (y compris pgvector pour les incorporations). Le niveau burstable est assez économique pour le développement et la préproduction. | Modèles d’écriture multirégion ou de lecture à très grande échelle. Envisagez Azure Cosmos DB pour PostgreSQL. |
| Données opérationnelles à schéma flexible, distribution mondiale, temps de lecture prévisibles inférieurs à 10 millisecondes | Azure Cosmos DB (API NoSQL) | Multirégion par défaut. Le niveau serverless est suffisamment bon marché pour démarrer. La conception de partition est importante ; lisez les instructions relatives à la clé de partition avant d’expédier. | Vous imposez des jointures relationnelles à travers la couche applicative. PostgreSQL est probablement la bonne réponse. |
| Recherchez dans des contenus structurés et non structurés, y compris la génération augmentée par récupération | Recherche Azure AI | Recherche de mots clés et de vecteurs hybrides. S’intègre à Azure OpenAI Service et Cosmos DB. Le niveau gratuit existe pour le prototypage. | Vous dépassez les limites d’index par niveau (Standard 1 est un point de mise à niveau commun). |
| Embeddings vectoriels pour une fonctionnalité de génération augmentée par recherche | Commencez par pgvector dans PostgreSQL ou Recherche Azure AI | Évitez une base de données vectorielle distincte pour la première version d’une fonctionnalité de récupération. Vous découvrirez ce dont vous avez réellement besoin (filtrage, recherche hybride, mise à l’échelle) à partir de l’utilisation réelle. | Vous avez caractérisé vos modèles de lecture et les contraintes justifient un moteur spécialisé. |
| Analyses, rapports et requêtes ad hoc sur les données de production | Azure Database pour PostgreSQL réplique en lecture (Exploration), Microsoft Fabric (Expansion et extraction) | Une réplique de lecture suffit pour la plupart des analyses en phase d’exploration. Microsoft Fabric est la plateforme d’analyse moderne qu’il vous faut lorsque cela ne suffit plus. | Vos réplicas de lecture ne parviennent plus à suivre le rythme, ou les parties prenantes de l’entreprise ont besoin d’une interface d’analytique en libre-service. |
| Couche de mise en cache devant une base de données | Azure Cache pour Redis (niveau De base) | Primitive de mise en cache standard. Bon marché pour ajouter plus tard ; n’ajoutez pas spéculativement. | Vous voyez un modèle de lecture chaud clair qui sature la base de données. Mesure avant d’ajouter. |
Important
Choisissez une base de données par défaut et restez dessus tant que vous le pouvez. Une équipe de quinze ingénieurs qui fait tourner PostgreSQL, Cosmos DB, Redis, AI Search, une file d’attente et une base de données orientée graphe s’est retrouvée, sans le vouloir, avec une charge de travail équivalente à celle d’une équipe plateforme.
Où s’adapte Azure OpenAI Service
Azure OpenAI Service n’est pas une plateforme de données, mais elle partage le même rythme de décision. La plupart des start-ups qui créent une fonctionnalité d’IA générative commencent par un déploiement de modèle (modèle d’achèvement de conversation récent) dans une seule région, ainsi que la recherche IA ou le pgvector pour la récupération. Vous n’avez pas besoin d’un pipeline d’ajustement fin dédié, d’une passerelle pour les modèles ou de plusieurs déploiements tant que l’usage ne montre pas que vous devez les ajouter.
Ce que cet article couvre (et ce qu’il ne fait pas)
| Sujet | Dans cet article | Quand l’ajouter |
|---|---|---|
| Gestion des identités et des accès au-delà des principes de base | Non | Premier jour de la configuration de Microsoft Entra ID. Accès conditionnel et Privileged Identity Management lors d’un audit de sécurité de l’information. |
| Infrastructure en tant que code (Bicep, Terraform) | Non | Lorsque les modifications manuelles du portail commencent à dériver entre les environnements. Généralement au moment où vous ajoutez le staging. |
| Pipelines d’intégration continue et de déploiement continu | Non | Jour 1. GitHub Actions ou Azure DevOps Pipelines sont tous les deux corrects. |
| Observabilité (logs, métriques, traces) | Non | Application Insights dès le premier jour. Carnets Azure Monitor en cas de fatigue liée aux alertes. |
| Gestion des coûts | Non | Définissez un budget au niveau de l’abonnement le jour 1. Étiquetez les ressources avec l’environnement et le propriétaire à partir du début. |
| Conformité (SOC 2, ISO 27001, HIPAA) | Non | Quand un client demande. Microsoft Defender for Cloud dispose d’un tableau de bord de conformité qui mappe les contrôles aux ressources Azure. |
| Récupération d’urgence et multirégion | Non | Lorsque le coût d’une heure de temps d’arrêt dépasse le coût d’ingénierie de la deuxième région. |
Lorsque les valeurs par défaut de la plateforme ne sont plus suffisantes
Ces signaux de croissance vous indiquent qu’une valeur par défaut spécifique a besoin d’un remplacement plus délibéré :
- Vous avez déployé plus de cinq services distincts sur App Service ou Container Apps et la mise à l’échelle par service devient un problème quotidien. Regardez Azure Kubernetes Service.
- Votre facture Azure mensuelle augmente plus rapidement que votre chiffre d’affaires mensuel depuis deux mois consécutifs. Durée d’une analyse de la gestion des coûts et de l’analyse de l’instance réservée ou du plan d’épargne.
- Votre réseau virtuel s’étend désormais sur plusieurs abonnements ou régions. Examinez Azure Virtual WAN et une topologie hub-and-spoke.
- Une seule instance PostgreSQL ne peut pas garder l’ensemble de travail en mémoire, et les réplicas de lecture ne comblent pas l’écart. Examinez Cosmos DB pour PostgreSQL ou une architecture partitionnée.
- Les requêtes d’analyse sur la base de données de production affectent sensiblement la latence des applications. Déplacez l’analytique vers Microsoft Fabric.
- Vous exécutez plus de deux comptes de stockage par environnement pour le même modèle d’accès. Consolidez.
- Vous avez ajouté un pays tiers avec des clients payants. Il est temps d’évaluer une deuxième région, un stockage géoredondé et une stratégie de routage avec Front Door.
Note
Résistez à la tentation d’adopter les outils de plateforme d’entreprise dès le début. La plupart des modèles précédents (service mesh, actif-actif multirégion, outils FinOps, opérateurs Kubernetes personnalisés) ajoutent une complexité opérationnelle qui n’apporte de bénéfices qu’à grande échelle. Ajoutez-les quand vous disposez de l’équipe nécessaire pour les maintenir, et pas avant.
Liste de contrôle de référence
Exécutez cette opération une fois par mois pour les six premiers mois sur Azure. Il intercepte la dérive la plus courante.
- Un abonnement par environnement (production, préproduction, développement) ou un abonnement avec des groupes de ressources stricts par environnement. Ne mélangez pas.
- Chaque ressource est dotée d’étiquettes pour l’environnement, le propriétaire et le centre de coûts (même si, aujourd’hui, le centre de coûts a la même valeur pour toutes les ressources).
- Un budget pour l’abonnement avec des alertes à 50 %, 80 % et 100 % de l’objectif mensuel dans Cost Management.
- Les groupes Microsoft Entra ID, et non les individus, se voient attribuer des rôles au niveau des groupes de ressources. Aucun propriétaire permanent au niveau de l’étendue de l’abonnement.
- Application Insights ou Azure Monitor est activé sur chaque ressource de calcul de production.
- Les sauvegardes de base de données de production sont vérifiées par un test de restauration documenté (au moins une fois).
- Les secrets se trouvent dans Azure Key Vault, et non dans la configuration de l’application. Utilisez des identités gérées pour le chemin d’accès entre le calcul et Azure Key Vault.
- Les images de conteneur sont analysées (Microsoft Defender pour conteneurs ou l’analyseur intégré à votre registre de conteneurs).