Services de migration AWS pour PME : à quoi ressemble un bon mandat

Un bon mandat de migration AWS pour une PME a une forme reconnaissable : une phase de découverte qui produit un inventaire écrit, un plan découpé en vagues avec les charges de travail les plus simples en premier, une bascule répétée d’avance avec un chemin de retour arrière, et un responsable nommé pour l’environnement après la mise en service. Si un fournisseur vous donne un prix avant d’avoir vu vos serveurs, ou si le plan se termine le jour de la bascule sans que personne soit imputable des opérations ensuite, c’est le mandat qu’il faut refuser.

Ce que vous décidez

Vous n’achetez pas vraiment « une migration ». Vous achetez quatre choses distinctes qu’on regroupe et qu’on brouille trop souvent : une évaluation (qu’est-ce que vous opérez vraiment, et que devrait devenir chaque pièce sur AWS), une zone d’atterrissage (la structure de comptes, le réseau et l’identité dans lesquels tout arrive), le déménagement lui-même (réplication, tests, bascule), et les opérations du jour deux (correctifs, sauvegardes, surveillance, contrôle des coûts). Les mandats de PME dérapent quand l’un de ces quatre morceaux manque en silence — habituellement le premier ou le dernier.

L’évaluation compte parce que tout ne devrait pas être déménagé tel quel. Un parc de dix serveurs contient typiquement deux ou trois serveurs à mettre au rancart, une charge de travail qui a sa place dans un service géré comme RDS plutôt que dans une base de données auto-hébergée sur une VM, et des partages de fichiers qui conviennent mieux à un stockage géré qu’à un serveur de fichiers sur EC2. Un fournisseur qui propose « on déménage les dix serveurs » sans cette conversation optimise sa propre simplicité, pas votre facture.

Les mécaniques de coûts valent la peine d’être comprises avant de signer quoi que ce soit. L’outillage de migration lui-même coûte peu — AWS Application Migration Service réplique les serveurs sans frais de service pendant une période gratuite limitée par serveur, et vous payez les ressources de transit qu’il crée. Ce qui détermine vraiment le prix du projet, c’est la main-d’œuvre : le nombre d’applications, l’enchevêtrement de leurs dépendances, le volume de données à déplacer et la quantité de tests que votre entreprise peut tolérer. Passez votre inventaire dans le calculateur de prix AWS vous-même avant les appels de découverte, pour pouvoir valider les chiffres de coûts récurrents qu’un fournisseur vous présente.

Quoi vérifier en premier

Avant d’évaluer qui que ce soit, vérifiez votre propre état de préparation — ces lacunes empirent toutes les soumissions :

• Avez-vous un inventaire de serveurs? Même un chiffrier avec nom d’hôte, système d’exploitation, rôle et responsable. Sinon, la première phase payée de tout mandat honnête consiste à le bâtir.
• Connaissez-vous vos dépendances? Quelle application parle à quelle base de données, qu’est-ce qui casse si le serveur de fichiers déménage. Les dépendances non documentées sont la première cause des fins de semaine de bascule qui virent au cauchemar.
• Y a-t-il des contraintes de licences? Windows Server, SQL Server et les applications de fournisseurs avec des licences liées au matériel changent considérablement le calcul.
• Qui opère l’environnement ensuite? Si la réponse est « la même personne qui s’occupait de la salle de serveurs, à temps partiel », le plan de transfert des opérations compte plus que le plan de migration.
• Y a-t-il une échéance? Un bail qui se termine ou du matériel en fin de vie comprime tout, et devrait être divulgué dès le départ, pas découvert en plein projet.

Comment vérifier

Si un fournisseur a déjà monté un compte AWS pour vous, ou si vous en avez un d’une tentative antérieure, quelques commandes révèlent le sérieux du travail :

# À qui appartient ce compte, et fait-il partie d'une organisation?
aws sts get-caller-identity
aws organizations describe-organization

# Est-ce que quelque chose roule sans que personne vous l'ait dit?
aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,Tags]' \
  --output table

# Combien le compte dépense-t-il vraiment?
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

Dans la console, Migration Hub > Discover > Servers montre si un outil de découverte a réellement été déployé, et Billing and Cost Management > Bills montre si quelqu’un a mis en place la visibilité sur les coûts. Un compte avec des charges en production et zéro budget ou alarme configurés vous dit comment le dernier mandat s’est terminé.

La démarche

Un mandat compétent pour une PME se déroule dans cet ordre :

1. Une découverte outillée, pas seulement des entrevues. Un collecteur avec ou sans agent inventorie les serveurs, l’utilisation et les connexions réseau pendant au moins deux semaines. Le livrable est un inventaire écrit avec une disposition par charge de travail : réhéberger, adapter, retirer, ou conserver sur place.
2. Une zone d’atterrissage avant que le moindre serveur bouge. Des comptes séparés pour la production et la non-production, une identité centralisée, CloudTrail activé, un réseau réparti sur plusieurs zones de disponibilité. Voyez Control Tower et Account Factory pour ce que ça donne quand c’est bien fait — même à petite échelle, la structure de comptes est la partie pénible à corriger après coup.
3. Une vague pilote d’une ou deux charges à faible risque. Elle valide l’outil de réplication, le chemin réseau et le cahier d’exécution avant que quoi que ce soit de visible pour les clients bouge. Un fournisseur qui résiste à une vague pilote devine.
4. Des vagues ordonnées par dépendance, pas par commodité. Les bases de données et les services partagés déménagent avec, ou avant, les applications qui en dépendent. Chaque vague a une fenêtre de test et des critères de succès définis.
5. Une bascule répétée avec retour arrière. Les TTL DNS abaissés d’avance, une bascule de test dans un sous-réseau isolé d’abord, et une décision de point de non-retour écrite. « On va s’arranger le soir même » n’est pas un plan.
6. Un transfert des opérations, par écrit. Qui applique les correctifs, qui répond aux alarmes, où vont les sauvegardes et qui a vérifié une restauration, à quoi ressemble la revue mensuelle des coûts. Un ensemble d’alarmes de base comme celui de la base d’alarmes CloudWatch devrait exister avant que le fournisseur parte.

Quand c’est la mauvaise approche

Certaines PME ne devraient pas faire de migration de serveurs du tout. Si votre parc se résume à un vieux serveur qui fait du courriel et des fichiers, le remplacer par du SaaS (courriel hébergé, une plateforme documentaire) coûte moins cher et reste plus simple que de le recréer sur EC2. Si votre matériel a deux ans et que vos charges sont stables, l’argument financier pour déménager maintenant n’existe peut-être tout simplement pas — AWS récompense l’élasticité et punit la capacité inutilisée. Et si une application de fournisseur est la seule chose qui garde un serveur en vie, demandez au fournisseur son offre hébergée avant de payer qui que ce soit pour la déménager.

Erreurs fréquentes

• Acheter une migration à prix fixe sans phase de découverte. Le prix a été inventé; les avenants, eux, ne le seront pas.
• Laisser le fournisseur posséder le compte racine AWS. Le compte, les identifiants racine et la relation de facturation doivent vous appartenir dès le premier jour.
• Sauter la conversation sur les retraits. Payer pour migrer des serveurs qui auraient dû être décommissionnés est le coût évitable le plus fréquent.
• Traiter la mise en service comme la ligne d’arrivée. Les mauvaises surprises coûteuses — instances surdimensionnées, sauvegardes manquantes, aucune alarme — apparaissent aux mois deux et trois.

Prévention

• Exigez que l’énoncé des travaux nomme les quatre phases : évaluation, zone d’atterrissage, migration, transfert des opérations.
• Gardez la propriété du compte racine, la facturation et au moins un accès administrateur entre vos mains pendant tout le projet.
• Exigez un plan de retour arrière écrit par vague avant d’approuver cette vague.
• Demandez l’estimation des coûts post-migration par écrit et comparez-la à la facture réelle à 30 et 90 jours.
• Entendez-vous avant de signer sur qui répond quand quelque chose plante à 2 h du matin après la bascule.

La plupart des migrations de PME échouent sur ce qui n’a jamais été inclus au mandat — l’inventaire que personne n’a bâti et les opérations dont personne n’était responsable. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.