Introduction
1) Votre périmètre s’élargit : des tâches de souscription aux systèmes organisationnels
En tant qu’opérateur AZ-104, votre périmètre est souvent :
- un abonnement ou un ensemble de groupes de ressources
- une charge de travail connue ou un composant de plateforme
- la stabilité au quotidien et la réponse aux incidents
- la justesse de l’implémentation et de la configuration
En tant qu’architecte AZ-305, votre périmètre devient :
- plusieurs abonnements et environnements (dev/test/prod)
- plusieurs équipes avec des niveaux de maturité différents
- des services partagés (identité, réseau, supervision, gouvernance)
- la maintenabilité à long terme et la prévisibilité des coûts
- la gestion des risques (sécurité, conformité, résilience)
Traduction : vous cessez de penser « comment déployer ceci ? » et vous commencez à penser « comment déployer ceci de façon répétable, sûre et cohérente pendant des années ? »
2) Votre mentalité change : de l’exécution aux arbitrages
Les opérateurs exécutent. Les architectes décident. Cela signifie que vous devenez responsable d’arbitrages tels que :
- vitesse vs contrôle (self-service vs approbations/garde-fous)
- coût vs résilience (une seule région vs multi-région, choix RTO/RPO)
- simplicité vs flexibilité (modèles standards vs exceptions)
- sécurité vs facilité d’usage (frontières strictes vs friction utilisateur)
- centralisation vs autonomie (équipe plateforme vs équipes produit)
3) Vous passez de « gérer les incidents » à « concevoir pour éviter les incidents »
Le travail AZ-104 ressemble souvent à :
- diagnostiquer
- atténuer
- rétablir le service
- améliorer la supervision
- corriger la cause racine
Le travail AZ-305 ressemble à :
- empêcher qu’une classe de panne se reproduise
- standardiser des modèles qui réduisent la dérive (drift)
- construire des garde-fous qui bloquent tôt les déploiements risqués
- intégrer la responsabilité d’exploitation dans l’architecture
Les architectes n’éliminent pas les incidents. Ils éliminent les surprises.
4) Vos livrables changent : des runbooks aux artefacts d’architecture
Livrables typiques AZ-104 (résultats d’exécution) :
- ressources déployées et configurées
- règles/tableaux de bord de supervision
- configuration des sauvegardes + étapes de restauration
- runbooks opérationnels (« comment faire la rotation des clés », « comment récupérer »)
- notes d’incident et actions de remédiation
Livrables typiques AZ-305 (résultats de décision) :
- chémas d’architecture de référence + justification
- conception de landing zone (hiérarchie des MG, abonnements, stratégie de politiques)
- décisions de topologie réseau (hub-spoke/vWAN, DNS, contrôle de l’egress)
- modèle d’identité et d’accès (stratégie RBAC, approche PIM, frontières)
- plan de résilience (zones/régions, approche DR, objectifs RTO/RPO)
- stratégie de journalisation sécurité (quoi journaliser, où, qui supervise)
- hypothèses de modèle de coûts + garde-fous
- enregistrements de décisions d’architecture (ADR)
Si vous ne produisez pas ces artefacts, vous n’opérez pas encore réellement dans le rôle d’architecte : vous faites du « senior admin avec des opinions ».
5) La liste « ce qui casse en premier » (réalité opérateur → architecte)
Voici ce qui casse généralement en premier quand quelqu’un passe à l’architecture sans changer sa façon de penser :
Complexité réseau et DNS
- les hypothèses de routage ne tiennent pas en hybride
- les endpoints privés cassent la résolution de noms
- le contrôle de l’egress est incohérent selon les environnements
- « ça marche en dev » échoue en prod à cause de chemins/politiques différents
Frontières d’identité et explosion des accès
- trop de Owners
- séparation des tâches floue
- principaux de service avec des secrets non gérés
- pas d’accès privilégié limité dans le temps
Gouvernance à grande échelle politiques appliquées trop tard (après l’apparition du sprawl)
- les exceptions deviennent permanentes
- nommage/tagging non imposés, donc visibilité coûts/ops qui s’effondre
Résilience théorique
- les sauvegardes existent mais les restaurations ne sont pas testées
- les étapes DR sont manuelles et non documentées
- des dépendances mono-région se cachent dans des conceptions « multi-région »
Responsabilité d’exploitation floue
- personne ne sait qui possède les composants partagés
- changements sans contrôle de changement
- supervision bruyante ou incomplète, donc incidents plus lents
Les architectes gagnent en concevant ces modes de défaillance dès le départ.
6) Comment savoir si vous avez opéré le changement (petit auto-test)
Vous raisonnez encore comme un opérateur si vous vous concentrez principalement sur :
- « comment configurer X »
- « quel service est le plus adapté »
- « comment résoudre les problèmes liés à Y »
Vous raisonnez comme un architecte lorsque vous posez systématiquement les questions suivantes :
- « quels sont les besoins et les contraintes ? »
- « quel est le mode de défaillance ? »
- « qui assure l’exploitation à 2 heures du matin ? »
- « comment imposer cela comme une norme ? »
- « quels sont les coûts et le modèle de gouvernance ? »
- « quel est le plan de retour en arrière (rollback) ? »
Une approche pragmatique : bâtir sa crédibilité, puis formaliser une réflexion architecturale
FAQ
Dois-je « cesser toute activité technique » pour devenir architecte ?
Non. Les meilleurs architectes conservent une pratique technique suffisante pour comprendre la réalité opérationnelle. Le changement réside dans la responsabilité des décisions, et non dans l’abandon de l’exécution.
La certification AZ-305 est-elle réservée aux environnements d'entreprise ?
Non. Même les petits environnements nécessitent une réflexion architecturale — notamment en matière de gouvernance, de périmètres d’identité et de résilience — car les petites équipes ne peuvent pas se permettre le chaos.
Quel est le moyen le plus rapide d'adopter une mentalité d'architecte ?
Commencez par consigner les compromis et les décisions prises, et veillez à ce que chaque conception intègre :
- un modèle d’identité
- un modèle réseau/DNS
- des garde-fous de gouvernance
- des objectifs de résilience ainsi que des procédures de rétablissement testées
Est-ce qu'il existe une liste référence des parcours de certifications Microsoft?
Oui, Microsoft publie fréquemment les mises à jour des parcours de certifications disponibles sous forme d’une affiche numérique.
Il est suggéré cependant d’utiliser la version anglaise dû aux mises à jours plus fréquentes.
