Démo Squad Azure

Ce que vous démontrez#

Chaque étape associe une capacité au rôle de la squad qui en est responsable. C'est le fil conducteur de votre présentation — la différence tient au fait que l'ensemble est livré sous forme de package APM installé dans n'importe quel dépôt, avec MCP facultatif, des solutions de repli adaptées et une validation humaine pour chaque déploiement.

Avant de commencer#

Orientez les étapes en lecture seule (documentation de l'existant, diagnostic) vers un groupe de ressources existant dont vous disposez déjà. Elles produisent alors des résultats réels sans déploiement, sans dépense et sans risque.

Configurer le MCP Azure (facultatif)#

Le package n'écrit jamais votre fichier .vscode/mcp.json à l'installation, et une demande ordinaire à la squad ne le crée pas non plus en silence. Deux possibilités s'offrent à vous :

1. Demandez au coordinateur de le préparer (fusion sur demande explicite, présentée sous forme de diff avant enregistrement) :
   Copier

   /squad request="merge the squad MCP template into my VS Code workspace"

2. Créez-le manuellement — la version minimale exécutable se limite au serveur officiel :
   Copier

   {
     "servers": {
       "azure": {
         "type": "stdio",
         "command": "npx",
         "args": ["-y", "@azure/mcp@latest", "server", "start"]
       }
     }
   }

   Rechargez VS Code, puis vérifiez son fonctionnement : demandez à Copilot de lister vos groupes de ressources.

Cette préparation est une fusion, jamais un écrasement : les serveurs déjà présents sont donc conservés. Le bloc de tarification de mcp.template.json est un emplacement réservé suivi dans Git, non exécutable — seul le serveur @azure/mcp ci-dessus est prêt pour la démo.

Facultatif — Diagrammes d'architecture avec icônes Azure#

Par défaut, Azure Architect produit le HLD en Mermaid. Si vous souhaitez plutôt un diagramme avec icônes enregistré dans Git (PNG/SVG avec les véritables icônes des produits Azure), l'architecte utilise la compétence python-diagrams, qui effectue le rendu avec la bibliothèque Python diagrams et le moteur Graphviz. Cette option nécessite une demande explicite et deux outils locaux :

• uv (ou Python) — exécute le générateur : winget install astral-sh.uv.
• Graphviz — le moteur de rendu, un binaire système : winget install Graphviz.Graphviz (exécutez avec élévation de privilèges, puis rouvrez le terminal pour que dot soit dans le PATH).

Ces deux outils interviennent uniquement avant le déploiement — sans connexion Azure ni dépense. Sur une machine vierge, l'étape d'implémentation s'interrompt pour installer Graphviz (qui nécessite une élévation de privilèges) ; préinstallez-le pour une exécution fluide. Pour déclencher cette option, ajoutez une phrase à la demande de conception — vous indiquez le résultat, pas les ressources, et l'architecte déduit le diagramme de sa propre conception et du Bicep, puis enregistre dans Git les paires PNG + SVG sous docs/architecture/ :

/squad request="... Also render the architecture you decide on as committed Azure-icon diagram images using the python-diagrams skill."

Sans ces outils, l'architecte se replie simplement sur Mermaid ; rien ne bloque.

Étape 0 — Initialiser la squad#

/squad profile=azure request="Set up the squad for an Azure infrastructure project."

Le coordinateur découvre le dépôt, propose le profil azure et initialise la squad après votre confirmation. À expliquer : « Une seule équipe — Cost Manager, Architect, IaC Author, Deployer, As-Built et Diagnose — accompagnée de l'ossature méthodologique : researcher, lead, developer, tester, pour que recherche → planification → implémentation → revue reste toujours disponible. »

Étape 1 — Analyse des coûts#

/squad request="Estimate the monthly Azure cost for a small internal web workload in West Europe: a frontend and a backend App Service, an Azure SQL Database, a Key Vault, and a Storage account, reached over private endpoints on a VNet. I need the monthly cost to stay under $60 — give an indicative figure and WAF cost-optimization recommendations to hit that target."

Le Cost Manager produit une estimation indicative par la voie de tarification (MCP s'il est configuré, repli REST sinon), ainsi que la liste de contrôle d'optimisation des coûts du WAF.

Étape 2 — Architecture, puis IaC#

/squad request="Design the HLD and LLD for that workload — frontend and backend web apps, Azure SQL, Key Vault, and Storage in West Europe — using Azure Verified Modules and a landing-zone-aligned layout. Configure the VNet and subnets, add private endpoints and private links where needed, follow security standards, and decide whether containerization is worth it."

/squad request="Author the Bicep for that LLD under infra/bicep/demo using AVM modules. Do not deploy."

Azure Architect produit le HLD Mermaid et le tableau LLD adapté à Bicep. C'est ici que la méthodologie devient visible : « écrire le Bicep » est une demande de niveau implémentation ; le contrôle d'implémentation (Implementation Gate) sollicite donc le rôle researcher (modules AVM, landing zone), puis le rôle lead (plan IaC), avant que l'IaC Author n'écrive une ligne. Il ne passe jamais à l'implémentation sans préparation.

Vous préférez des diagrammes avec icônes Azure enregistrés dans Git plutôt que Mermaid ? Ajoutez « produis des images de diagrammes avec icônes Azure à l'aide de la compétence python-diagrams » à la demande de conception — consultez la section Facultatif — Diagrammes d'architecture avec icônes Azure ci-dessus pour la configuration initiale de uv et de Graphviz.

Étape 2b — Revoir l'implémentation (nouveauté de la version 0.8.1)#

Une fois le Bicep livré par l'IaC Author, le suivi systématique de revue (Review Follow-Through) sollicite tester (Implementation Validator ou Code Review Full) pour vérifier l'IaC par rapport au LLD. La revue clôt désormais chaque implémentation, rendant le contrôle symétrique — recherche et planification précèdent la réalisation, la revue la suit. Vous pouvez aussi la demander explicitement :

/squad request="Review the Bicep we just authored against the LLD and flag any drift."

Étape 3 — Découvrir la gouvernance et déployer sous approbation#

/squad request="Deploy infra/bicep/demo to my subscription. Run the policy precheck first and show me what governance constraints apply before the gate."

Le Deployer effectue un contrôle préalable Azure Policy en lecture seule (affectations effectives et refus anticipés) avant la validation des actions à conséquences (Impactful-Action Gate), puis s'arrête pour obtenir votre approbation. À expliquer : « Il découvre les véritables stratégies de l'abonnement avant de demander à déployer — et ne déploie jamais sans moi. » Pour une démo sans risque, refusez au point de validation ; la valeur du contrôle préalable est déjà démontrée.

Étape 4 — Documentation de l'existant#

Ciblez un groupe de ressources existant pour que cette étape fonctionne sans déploiement :

/squad request="Document the deployed Azure infrastructure in resource group rg-demo as as-built artifacts: a resource inventory, a compliance matrix from Azure Policy, an operations runbook, and a backup/DR plan."

L'As-Built Author établit l'inventaire via Resource Graph (en lecture seule), construit la matrice de conformité et rédige le guide d'exploitation et le plan de reprise après sinistre pour le rôle technical-writer — le tout livré sous forme d'un ensemble de documents Markdown.

Étape 5 — Diagnostic#

/squad request="Diagnose why the App Service in resource group rg-demo is returning 5xx errors. Query Resource Health and recent logs, rank the likely causes, and recommend fixes — but do not change anything."

Le rôle Azure Diagnose interroge Resource Health, Azure Monitor (KQL) et Resource Graph, renvoie des hypothèses classées et étayées, puis confie toute correction au Deployer soumis à approbation ou à l'IaC Author — en restant strictement en lecture seule.

La version autonome en une demande#

Le même parcours s'exécute à partir d'une seule demande autopilot qui exprime le besoin sans nommer les étapes. La squad déduit elle-même leur enchaînement :

/squad mode=autopilot profile=azure request="Stand up a small, production-ready web app on Azure for an internal team — web apps for a frontend and a backend with a SQL database, secrets handling, and file storage in West Europe, I need you to configure vnets and subnets for that and decide on the resources that you prefer. Make sure to follow security standards and create private endpoints and private links when needed. I need monthly cost to stay under $60, the setup to respect our governance, and to be able to operate and troubleshoot it once it's live. So you are free to decide whether it is better to do containerization or not. Keep me in control of anything that spends money or changes my subscription. Also render the architecture you decide on as committed Azure-icon diagram images."

À partir de cette seule ligne, autopilot organise le pipeline et ne s'arrête que lorsque c'est nécessaire :

• Initialisation — propose le profil azure et attend votre confirmation.
• Recherche → Planification — le rôle researcher, puis le rôle lead.
• Conseil — architecture, sécurité et coûts donnent leur avis avant toute réalisation.
• Implémentation — Azure Architect et IaC Author produisent la conception et le Bicep.
• Revue — tester valide l'implémentation.
• Validation des actions à conséquences (Impactful-Action Gate) — s'arrête avant le déploiement et demande une approbation.
• Documentation de l'existant + validation du résultat final — documente le résultat et attend votre accord final.

Vous n'intervenez qu'à la confirmation du profil, à l'approbation du déploiement et à la validation finale — c'est le mode « dites-le une fois, laissez-le travailler ».

Solutions de repli en cas de problème#

Points clés pour conclure#

• Pas de clonage. hve-squad s'installe par apm install dans votre dépôt — la squad vous accompagne.
• MCP facultatif. Chaque capacité Azure dispose d'une solution de repli sans MCP identifiée ; l'absence d'un serveur ne bloque donc jamais la squad.
• Sûr par conception. Les déploiements restent soumis à la validation des actions à conséquences (Impactful-Action Gate) ; la documentation de l'existant et le diagnostic s'effectuent strictement en lecture seule.
• Méthodologie complète. Recherche → planification → implémentation → revue s'exécute dans chaque profil : le travail Azure est planifié et revu, pas improvisé.