Platform Engineering | The .NET Blog

Supprimer le Travail Répétitif de la Migration avec l'Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Ce post a été traduit automatiquement. Pour la version originale, cliquez ici.

Removing the Monkey Work of Migration with Agentic Platform Engineering — une présentation de Git-Ape (outil git d’ingénierie de plateforme agentique) qui migre un vrai dépôt Terraform AWS vers Azure, en se concentrant sur l’extraction d’intention plutôt que sur une conversion ligne par ligne.

L’entrée : contoso-migration

La source est un vrai projet Terraform (contoso-migration) qui déploie une application Next.js sur AWS — EC2 pour le calcul, ALB pour l’équilibrage de charge, S3 pour les artefacts, et des clés IAM pour l’identité. Coût : ~34 $/mois. L’objectif n’est pas de reproduire la même infrastructure sur Azure ; c’est de comprendre ce que le déploiement essaie réellement de faire et de le reconstruire avec des services natifs Azure.

Étape 1 : Validation et authentification

Git-Ape commence par valider tous les outils CLI requis — az, aws, gh, jq, git — et en confirmant les sessions d’authentification actives avant de toucher quoi que ce soit. Pas d’exécutions partielles.

Étape 2 : Extraction d’intention

L’agent lit l’intégralité du dépôt source via l’API GitHub et extrait l’intention de déploiement : runtime (Node.js), type de calcul, modèle d’ingress, gestion des artefacts, modèle d’identité, réseau et surveillance. C’est l’étape clé — elle construit un modèle sémantique de ce que fait le déploiement, pas quels mots-clés Terraform il utilise.

Étape 3 : Correspondance de services

Les services AWS sont mappés vers leurs équivalents Azure :

EC2 → App Service (Linux, Node 20 LTS)
ALB → Équilibrage de charge intégré d’App Service
Rôles/clés IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Étape 4 : Agent de critique

Avant de générer la sortie, un agent de critique s’exécute et détecte deux problèmes bloquants :

Anti-modèle de build au démarrage — le Terraform original exécutait npm install && npm run build sur EC2 au démarrage. Correction : construire dans CI, déployer un artefact prêt.
Blob Storage inutile — S3 était utilisé pour la mise en attente d’artefacts qui pouvait être éliminé avec un CI/CD approprié. L’agent de critique l’a supprimé entièrement.

Étape 5 : Sortie générée

Le résultat est ~80 lignes de Bicep au lieu des 200+ lignes originales de Terraform. L’agent a créé un nouveau dépôt GitHub avec infra/main.bicep et .github/workflows/deploy.yml et supprimé tous les fichiers spécifiques à AWS.

Comparaison de la posture de sécurité

La migration a également produit une amélioration significative de la sécurité :

AWS original	Sortie Azure
HTTP uniquement	HTTPS uniquement, TLS 1.2
SSH ouvert à 0.0.0.0/0	Pas d’exposition SSH
Clés d’accès IAM	OIDC + Managed Identity
Pas de surveillance	Application Insights

Coût : ~13 $/mois vs les 34 $/mois originaux.

Ce qui le distingue d’un convertisseur de syntaxe

L’étape de l’agent de critique est ce qui sépare ceci d’une traduction mécanique. Il a détecté des modèles qui auraient fonctionné sur AWS mais seraient incorrects sur Azure — et les a corrigés plutôt que de les répliquer. La sortie n’est pas “AWS en syntaxe Azure” ; c’est un déploiement natif Azure qui atteint le même objectif plus proprement.

Consultez le guide complet pour la trace complète de l’agent et les fichiers générés.

L'Ingénierie de Plateformes Agentique Devient Réalité — Git-APE Montre Comment

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Cet article a été traduit automatiquement. Pour la version originale, cliquez ici.

L’ingénierie de plateformes est un de ces termes qui sonne bien en conférence mais qui signifie généralement « on a construit un portail interne et un wrapper Terraform. » La vraie promesse — une infrastructure en self-service qui soit réellement sécurisée, gouvernée et rapide — a toujours été à quelques pas.

L’équipe Azure vient de publier la Partie 2 de leur série sur l’ingénierie de plateformes agentique, et celle-ci porte sur l’implémentation concrète. Ils l’appellent Git-APE (oui, l’acronyme est intentionnel), et c’est un projet open source qui utilise les agents GitHub Copilot plus les serveurs Azure MCP pour transformer des requêtes en langage naturel en infrastructure validée et déployée.

Ce que Git-APE fait concrètement

L’idée principale : au lieu que les développeurs apprennent des modules Terraform, naviguent dans des UIs de portails ou déposent des tickets à l’équipe plateforme, ils parlent à un agent Copilot. L’agent interprète l’intention, génère de l’Infrastructure-as-Code, la valide contre les politiques et déploie — le tout dans VS Code.

Voici la mise en place :

git clone https://github.com/Azure/git-ape
cd git-ape

Ouvre le workspace dans VS Code, et les fichiers de configuration de l’agent sont automatiquement découverts par GitHub Copilot. Tu interagis directement avec l’agent :

@git-ape deploy a function app with storage in West Europe

L’agent utilise Azure MCP Server en interne pour interagir avec les services Azure. La configuration MCP dans les paramètres de VS Code active des capacités spécifiques :

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Pourquoi c’est important

Pour ceux d’entre nous qui construisent sur Azure, cela déplace la conversation de l’ingénierie de plateformes de « comment construire un portail » à « comment décrire nos garde-fous comme des APIs. » Quand l’interface de ta plateforme est un agent IA, la qualité de tes contraintes et politiques devient le produit.

Le blog de la Partie 1 posait la théorie : des APIs bien décrites, des schémas de contrôle et des garde-fous explicites rendent les plateformes agent-ready. La Partie 2 prouve que ça marche en livrant des outils concrets. L’agent ne génère pas aveuglément des ressources — il valide contre les bonnes pratiques, respecte les conventions de nommage et applique les politiques de ton organisation.

Le nettoyage est tout aussi simple :

@git-ape destroy my-resource-group

Mon avis

Je serai honnête — ici c’est plus le pattern que l’outil spécifique qui compte. Git-APE lui-même est une démo/architecture de référence. Mais l’idée sous-jacente — les agents comme interface de ta plateforme, MCP comme protocole, GitHub Copilot comme hôte — c’est la direction que prend l’expérience développeur en entreprise.

Si tu es une équipe plateforme qui cherche comment rendre son outillage interne agent-friendly, il n’y a pas de meilleur point de départ. Et si tu es un développeur .NET qui se demande comment ça se connecte à ton monde : Azure MCP Server et les agents GitHub Copilot fonctionnent avec n’importe quel workload Azure. Ton API ASP.NET Core, ton stack .NET Aspire, tes microservices containerisés — tout ça peut être la cible d’un flux de déploiement agentique.

Pour conclure

Git-APE est un aperçu précoce mais concret de l’ingénierie de plateformes agentique en pratique. Clone le repo, essaie la démo et commence à réfléchir à comment les APIs et politiques de ta plateforme devraient se présenter pour qu’un agent puisse les utiliser en toute sécurité.

Lis le post complet pour le walkthrough et les vidéos de démo.