Générateur de solutions IoT Smart City pour Azure

Utilisez cette skill pour reconstruire et standardiser un flux de travail complet pour les solutions IoT et Smart City sur Azure.

Quand l'utiliser

Utilisez cette skill quand l'utilisateur demande des choses comme :

• « Je veux construire une solution IoT sur Azure »
• « Architecture Smart City pour le trafic, l'éclairage ou les déchets »
• « Comment connecter les appareils, l'analytique et les alertes ? »
• « J'ai besoin d'une feuille de route et d'un backlog pour une plateforme urbaine »

Objectifs

• Convertir une idée haut niveau en architecture déployable.
• Réutiliser les skills existants axés sur Azure autant que possible.
• Produire des artefacts concrets que l'équipe peut implémenter.

Flux de travail

0) Examen obligatoire de la documentation (avant toute architecture)

Avant de proposer une architecture ou des décisions technologiques impliquant l'edge computing, consultez d'abord la documentation Azure IoT Edge :

• https://learn.microsoft.com/azure/iot-edge/

Pages minimales à consulter :

• What is Azure IoT Edge
• Runtime architecture
• Supported systems
• Version history/release notes
• Relevant Linux/Windows quickstarts for the scenario

Si la documentation ne peut pas être consultée, déclarez-le explicitement et continuez avec des hypothèses clairement marquées.

1) Périmètre et contraintes

Collectez et confirmez :

• Domaine urbain : mobilité, stationnement, qualité de l'air, eau, énergie, sécurité publique, déchets, etc.
• Échelle : nombre d'appareils, fréquence de télémétrie, rétention, régions.
• Objectifs de latence et de disponibilité.
• Contraintes réglementaires et de confidentialité.
• Systèmes existants à intégrer (SCADA, SIG, ERP, ticketing, APIs).

2) Cartographie des capacités

Divisez la plateforme en couches :

• Appareil et edge : onboarding, identité, firmware, OTA, traitement edge.
• Ingestion et messaging : commande et contrôle, routage d'événements, buffering.
• Données et analytique : chemin chaud vs chemin froid, tableaux de bord, analyse historique.
• Opérations : observabilité, flux d'incidents, SLOs.
• Gouvernance : RBAC, secrets, politiques, isolement réseau.

3) Sélection des services Azure (référence)

• Connectivité des appareils : Azure IoT Hub, Azure IoT Operations, IoT Edge.
• Streaming d'événements : Event Hubs, Service Bus, Event Grid.
• Stockage : Blob Storage, Data Lake, Cosmos DB, SQL.
• Analytique : Azure Data Explorer, Stream Analytics, Fabric/Synapse.
• APIs et applications : API Management, App Service, Container Apps, Functions.
• Monitoring : Azure Monitor, Application Insights, Log Analytics.
• Sécurité : Key Vault, Defender for IoT, Private Endpoints, Managed Identity.

4) Conception non-fonctionnelle

Définissez et documentez :

• Modèle de fiabilité (zones/régions, retries, gestion des dead-letter, replay).
• Contrôles de sécurité (zero trust, chiffrement, rotation des secrets, principe du moindre privilège).
• Contrôles de coûts (tiers de rétention, dimensionnement, autoscaling, planification des charges).
• Cycle de vie des données (brutes, curées, agrégées, archivées).

5) Plan de livraison

Créez une exécution par phases :

• Phase 1 : District pilote ou cas d'usage unique.
• Phase 2 : Intégration multi-domaine.
• Phase 3 : Déploiement à l'échelle de la ville et optimisation.

Pour chaque phase, incluez :

• Critères de sortie
• Dépendances
• Risques et atténuations
• Ensemble d'indicateurs clés

Réutilisez d'autres skills en premier

Il y a deux sources de skills :

• Skills fournis par le runtime (externes à ce repository) : disponibles uniquement quand l'environnement hôte du Copilot les expose.
• Skills du repository local (ce repository) : disponibles en tant que fichiers locaux sous skills/.

Skills Azure fournis par le runtime (optionnels)

S'ils sont disponibles dans l'environnement d'exécution, déléguez à ces skills spécialisés pour une guidance plus approfondie :

• azure-kubernetes
• azure-messaging
• azure-observability
• azure-storage
• azure-rbac
• azure-cost
• azure-validate
• azure-deploy

Alternatives du repository local (utiliser dans ce repo)

Quand les skills du runtime ne sont pas disponibles, privilégiez les skills locaux existants dans ce repository :

• azure-architecture-autopilot pour la génération et l'affinage de l'architecture.
• azure-resource-visualizer pour les diagrammes de relations entre ressources.
• azure-role-selector pour la guidance de sélection des rôles.
• az-cost-optimize et azure-pricing pour l'analyse des coûts et tarification.
• azure-deployment-preflight pour les vérifications de pré-déploiement.
• appinsights-instrumentation pour les patterns d'instrumentation de télémétrie.

Si aucune skill spécialisée n'est disponible, continuez avec cette skill et gardez les hypothèses explicites.

Artefacts de sortie requis

Fournissez toujours ces sorties :

1. Résumé de la solution Smart City (périmètre, hypothèses, contraintes).
2. Architecture de référence (composants et flux de données).
3. Checklist de sécurité et gouvernance.
4. Stratégie de coûts et de mise à l'échelle.
5. Backlog d'implémentation par phases (épics et jalons).

Modèle de sortie

Utilisez cette structure de réponse :

1. Contexte et objectifs
2. Architecture proposée
3. Décisions technologiques et compromis
4. Contrôles de sécurité, opérations et coûts
5. Plan d'implémentation par phases
6. Risques et questions ouvertes

Directives

• Ne passez pas au déploiement avant de valider les prérequis.
• Ne recommandez pas une production mono-région pour les charges de travail critiques d'une ville.
• N'omettez pas la propriété opérationnelle (qui gère les incidents, SLAs, fenêtres de changement).
• Séparez clairement les hypothèses des faits confirmés.