ITSec France

Migrer son infrastructure vers Azure avec l’IA : le processus réel

Migrer son infrastructure vers Azure avec l’IA : le processus réel

Depuis avril 2026, Azure Migrate embarque un agent Copilot capable de raisonner sur les données de votre projet de migration. Ce n’est pas un assistant générique branché sur de la documentation : il lit votre inventaire découvert, vos analyses de rentabilité et vos évaluations, puis répond en langage naturel.

La question utile n’est pas de savoir si c’est impressionnant, mais où passe exactement la frontière entre ce qu’il fait et ce qu’il vous laisse. C’est l’objet de cet article.

Une frontière nette, à connaître avant de s’engager

L’agent planifie et analyse. Il n’exécute rien. Réplication, migrations de test, bascule et déplacement des charges de travail restent des opérations du portail Azure Migrate. Aucun agent ne fera basculer votre production.

Ce que l’agent fait réellement

Cinq domaines, tous adossés aux données de votre projet Azure Migrate plutôt qu’à des généralités.

1. Analyse de la stratégie de migration

Il évalue les caractéristiques de votre infrastructure au regard de vos objectifs, et explicite les arbitrages entre déplacement à l’identique et modernisation. L’intérêt n’est pas la réponse toute faite, mais le fait qu’elle s’appuie sur votre inventaire réel.

2. Lecture de l’inventaire découvert

Il interprète les données issues de l’appliance Azure Migrate, du collecteur, ou d’un import RVTools. Il fait remonter les attributs qui comptent — version de système d’exploitation, statut de support — et permet d’organiser les charges de travail par étiquettes.

C’est là que le gain est le plus tangible sur un parc de plusieurs centaines de machines : demander « montre-moi les serveurs hors support » remplace un export tableur et un tri manuel.

3. Analyse de rentabilité

Il crée, résume et compare des analyses de rentabilité Azure Migrate. Il explique d’où viennent les économies annoncées et compare le retour sur investissement entre plusieurs scénarios.

Détail qui a son importance en contexte d’entreprise : les résultats s’exportent en présentation PowerPoint pour un comité de direction. C’est trivial techniquement, mais c’est souvent ce qui débloque un budget.

4. Interprétation de l’évaluation de préparation

Il résume les signaux de préparation, identifie les points bloquants et explique les recommandations de dimensionnement et d’estimation de coût. Il compare les résultats entre plusieurs regroupements de charges de travail.

5. Raisonnement sur la zone d’atterrissage

À partir de vos contraintes — régions cibles, exigences de conformité, préférences de connectivité — il génère une configuration de zone d’atterrissage. Le modèle est téléchargeable ; le déploiement, lui, se fait ailleurs.

Le périmètre exact, par type d’environnement

Environnement Ce que couvre l’agent
VMware Planification et analyse de bout en bout, y compris la personnalisation des modèles de zone d’atterrissage
Hyper-V et serveurs physiques Analyse d’inventaire, comparaison de stratégies, interprétation des évaluations. La découverte reste dans le portail
Exécution, tous environnements Non couverte. Réplication, tests, bascule et déplacement passent par le portail Azure Migrate

Le processus, phase par phase

La séquence ne change pas. Ce qui change, c’est le temps passé sur chaque étape.

Phase 1 — Découverte

Trois voies : l’appliance Azure Migrate, le collecteur, ou un import RVTools. L’agent vous oriente vers la méthode adaptée et rappelle les prérequis, mais c’est vous qui déployez.

Sur un parc VMware déjà documenté par RVTools, l’import évite de déployer une appliance pour la seule phase d’analyse. C’est le raccourci le plus rentable si vous voulez chiffrer avant d’engager quoi que ce soit.

Phase 2 — Organisation de l’inventaire

L’étiquetage par application est le travail le plus ingrat d’une migration, et celui qui détermine tout le reste. L’agent l’accepte en langage naturel :

Assigne l'étiquette application:CommandesClients
aux serveurs vm-web-tier et vm-app-tier

Liste toutes les charges de travail portant
l'étiquette application:CommandesClients

Montre les serveurs hors support

Étiquette ces serveurs avec upgraderequired: yes

Regrouper par application plutôt que par machine est ce qui distingue une migration réussie d’un déplacement de machines virtuelles qui casse des dépendances le jour de la bascule.

Phase 3 — Analyse de rentabilité

C’est la phase où l’agent fait gagner le plus de temps, parce qu’elle est répétitive et qu’elle doit être refaite à chaque changement d’hypothèse.

Donne le résumé du retour sur investissement
pour un déplacement à l'identique

Compare le retour sur investissement entre
déplacement à l'identique et modernisation

Explique comment les économies de cette
analyse sont obtenues

La dernière question est la plus utile. Une estimation dont on ne sait pas expliquer l’origine ne survit pas au premier contradicteur en comité.

Phase 4 — Évaluation de la préparation

L’agent résume les blocages et explique le dimensionnement proposé. À ce stade, la valeur ajoutée est de pouvoir interroger un résultat plutôt que de lire un rapport de plusieurs centaines de lignes.

Phase 5 — Zone d’atterrissage

La configuration se génère à partir de vos contraintes de région, de conformité et de connectivité. Vous récupérez un modèle. Le déploiement, la validation réseau et l’intégration à votre existant restent votre travail.

Phase 6 — Exécution

L’agent sort du jeu. Réplication, migration de test, bascule : portail Azure Migrate, méthodes classiques, fenêtres de maintenance classiques. Aucun raccourci.

Les prérequis qu’on découvre trop tard

  • Un abonnement Azure avec les droits sur Azure Migrate
  • Un accès à VMware vCenter
  • Azure Copilot activé au niveau du tenant
  • Les agents en préversion activés dans Azure Copilot — c’est une bascule distincte, et c’est celle qu’on oublie

Une incompatibilité peu documentée

L’agent n’est pas pris en charge si vous avez activé le stockage sur votre propre compte pour l’historique des conversations Azure Copilot. Si votre organisation a mis cela en place pour des raisons de souveraineté ou de conformité, l’agent ne fonctionnera pas. Vérifiez ce point avant de bâtir un plan autour de lui.

Les autres briques IA d’Azure Migrate

L’agent conversationnel n’est pas la seule nouveauté. Trois ajouts méritent l’attention selon votre contexte :

  • Analyse de code par GitHub Copilot. Les évaluations d’applications web s’enrichissent d’une lecture du code source, qui affine la recommandation entre Azure Kubernetes Service et App Service. C’est la différence entre une recommandation fondée sur la configuration de l’hôte et une recommandation fondée sur ce que fait réellement l’application.
  • Génération d’infrastructure as code. Le redéploiement de serveurs Windows peut désormais produire des modèles IaC à partir des charges de travail évaluées, avec intégration des configurations de disques. Utile pour la reproductibilité, indispensable si vous migrez par vagues.
  • Évaluations MongoDB. Recommandations de préparation et de dimensionnement, avec estimation mensuelle, vers Azure DocumentDB ou MongoDB sur machines virtuelles.

Ce que l’IA ne fera pas à votre place

C’est la partie que les annonces passent sous silence, et c’est celle qui détermine si votre projet aboutit.

  • L’exécution. Répété, mais c’est le malentendu le plus coûteux. Un plan généré en une heure ne raccourcit pas une bascule.
  • L’exploitation après migration. Aucun agent de planification ne pilote votre parc une fois en production. Supervision, optimisation des coûts, gestion des versions : rien de tout cela n’est couvert.
  • Le financement. Les dispositifs d’accompagnement financier Microsoft ne se demandent pas tout seuls. Les équipes qui migrent en autonomie complète passent souvent à côté.
  • La conversion des agents Copilot Studio vers Azure AI Foundry. Ni l’agent de migration ni GitHub Copilot App Modernization ne la prennent en charge. La procédure est documentée, mais elle reste manuelle.
  • Les dépendances applicatives non déclarées. L’outillage voit ce qui est découvert. Le flux nocturne vers un serveur oublié, le partage monté par une lettre de lecteur codée en dur : ça, c’est votre connaissance du terrain.

Le piège des cinquante pour cent

Microsoft fournit des accélérateurs, pas une solution complète. Le schéma d’échec typique : une équipe interne parcourt rapidement la moitié du chemin grâce à l’outillage, puis se retrouve bloquée sur les tâches décisives — dépendances, fenêtres de bascule, reprise après incident. Prévoyez le budget et les compétences pour la seconde moitié, qui reste entièrement humaine.

La méthode pour que ça marche

Ce que je retiens de la façon dont ces outils s’insèrent dans un projet réel :

  • Faites la découverte avant de solliciter l’agent. Il raisonne sur des données ; sans inventaire, il produit des généralités. Un import RVTools suffit pour commencer.
  • Investissez sur l’étiquetage par application. C’est ce qui conditionne la qualité de tout ce qui suit. L’agent accélère la saisie, pas la réflexion.
  • Faites-vous expliquer les chiffres. Ne présentez jamais une estimation dont vous ne savez pas reconstituer l’origine.
  • Traitez le plan comme une hypothèse. Une recommandation reste une recommandation, y compris quand elle est bien formulée.
  • Gardez la maîtrise de la bascule. C’est là que se joue la réussite, et c’est intégralement entre vos mains.

Le gain réel se situe sur la phase d’analyse : ce qui prenait des semaines de tableurs et de réunions se compresse en quelques jours. La migration elle-même, elle, ne s’automatise toujours pas.

Sources