Validation initiale : les 24 premières heures après bascule
Les premières heures suivant le basculement en production sont critiques. Il faut commencer par vérifier que les services sont réellement up et accessibles : testez l'accès à vos applications depuis les différents points de connexion prévus (VPN, internet public, interconnexions directes si vous en avez). Vérifiez que vos instances EC2, conteneurs ECS ou pods EKS sont bien en état running, que les load balancers distribuent effectivement le trafic, et que les DNS résolvent correctement vers vos nouveaux endpoints AWS. Pour cette vérification initiale, utilisez des outils simples : curl, ping, ou des tests synthétiques basiques qui vous donnent rapidement un signal go/no-go. Documentez chaque point du moment où vous le testez, même si le résultat est positif, car cela constituera votre trace d'audit. Pendant ces 24 premières heures, gardez une personne disponible pour réagir rapidement à tout comportement anormal, et maintenez une ligne de communication ouverte avec tous les propriétaires de service critiques internes. C'est pendant cette fenêtre qu'on détecte 90% des problèmes de connectivité réseau ou de configuration basique, bien avant que les tests de performance ne révèlent des dégradations plus subtiles.
Validation de la performance applicative et infrastructure
Une fois que vous avez confirmé que tout est accessible, mesurez les performances réelles. Collez-vous à vos SLA : latence applicative moyenne et P95, taux d'erreur HTTP 4xx/5xx, temps de réponse des requêtes critiques. Comparez-les aux baseline que vous aviez établis avant migration (ou à défaut, aux performances que vous aviez en ancien environnement). Si la latence moyenne passe de 80 ms à 200 ms pour votre API critique, vous avez un problème qui doit être investigué avant de déclarer la migration réussie. Mesurez aussi la consommation de ressources : CPU, mémoire, bande passante réseau de vos instances. Certaines applications mal dimensionnées vont consommer beaucoup plus en AWS que prévu, ou au contraire mal utiliser les ressources, ce qui se traduit par des couts excessifs dès les premiers jours. Activez CloudWatch, configurez des dashboards avec les métriques critiques pour votre métier (temps de traitement par requête, nombre de transactions par minute, taux de cache hit si vous avez un cache), et laissez tourner pendant au moins 48 à 72 heures pour voir le profil réel de la charge. Les pics de charge arrivent souvent quelques jours après la migration quand les utilisateurs se réapproprient les outils ; ne prenez pas de décision définitive sur les performances pendant les premières 48 heures si votre charge est très basse.
Validation de l'intégrité et la complétude des données
Migrer une infrastructure c'est aussi migrer de la data. Vous devez vérifier que 100% de vos données ont bien traversé et qu'aucune corruption n'a eu lieu. Commencez par les comptes de lignes sur les données critiques : nombre de rows dans vos tables RDS ou DynamoDB, nombre d'objets dans vos buckets S3, nombre d'entrées dans vos caches Redis. Comparez-les exactement entre l'ancien et le nouvel environnement. Ensuite, allez plus loin : validez que les données sensibles sont toujours présentes et cohérentes. Si vous avez des identifiants uniques (customer IDs, transaction IDs), samplez quelques milliers d'enregistrements et vérifiez que le hash ou la checksum correspond entre ancienne et nouvelle base. Testez aussi les dépendances entre tables : si une commande dépend d'un client, vérifiez que la relation est toujours intacte en nouveau. Pour les données volumineuses (logs, media), ne vérifiez pas tout, mais faites un sampling statistique. Enfin, lancez vos jobs de validation les plus critiques (calcul de revenus, agrégations), comparez les résultats avec ceux d'avant migration, et levez une anomalie même mineure si quelque chose ne correspond pas exactement. L'intégrité des données n'est jamais un point à 90% : c'est 100% ou rien.
Vérification de la sécurité, de l'isolation réseau et de la conformité
Votre infrastructure en AWS doit respecter les mêmes règles de sécurité qu'avant. Vérifiez d'abord la segmentation réseau : les VPC, subnets et groupes de sécurité sont bien configurés pour que seuls les flux attendus passent. Utilisez AWS Security Groups et Network ACLs pour valider que vous n'avez pas créé d'ouverture accidentelle (ex : un port ouvert au monde qui ne devrait pas l'être). Testez les accès depuis les bonnes sources (collaborateurs internes via VPN, partenaires via connexions dédiées) et vérifiez que les accès non autorisés sont bloqués. Ensuite, passez en revue les secrets et les clés : vérifiez que les access keys AWS, les mots de passe de bases de données, les certificats TLS/SSL ne sont pas stockés en clair dans du code ou des fichiers de configuration. Utilisez AWS Secrets Manager ou Parameter Store pour tous les secrets dynamiques. Enfin, mettez à jour votre documentation de conformité et lancez une première passe de la liste d'audit de votre responsable conformité (RGPD, normes métier, exigences du client, ou prescriptions spécifiques de votre secteur). Ne laissez pas la conformité pour après la clôture du projet : si un problème existe, mieux vaut le découvrir et le corriger maintenant plutôt que lors d'un audit externe dans deux mois.
Tests de basculement et rollback
Avant de considérer la migration comme définitive, vous devez être certain que vous pouvez revenir en arrière si quelque chose d'irrémédiable se produit. Testez votre procédure de rollback, même partiellement : si vous pouvez router le trafic vers l'ancien environnement via un basculement de DNS ou un changement de route, faites-le pendant quelques minutes pour vérifier que l'ancien stack est toujours opérationnel et peut reprendre du trafic sans dégradation majeure. Si le rollback est techniquement complexe (ex : resynchro de bases de données), au minimum vérifiez que votre sauvegarde de l'ancien état est accessible, récente et testée (une sauvegarde que vous n'avez jamais restaurée n'existe pas vraiment). Documentez précisément les conditions qui activeraient un rollback : par exemple, « si P95 latency > 500ms pendant plus de 15 minutes » ou « si taux d'erreur HTTP 5xx > 1% ». Ces conditions doivent être claires et décidées AVANT la migration, pas au moment de la crise. Une fois votre fenêtre de validation complétée et tous les critères verts, vous pouvez décommissionner les environnements de secours si vous avez décidé que le rollback n'était possible que dans la première heure, mais documentez cette décision formellement.
Fermeture et documention post-migration
Après que tous les contrôles aient passé et que vous ayez confirmé que la migration est stable (généralement 48 à 72 heures minimum), documentez formellement le succès de la migration. Créez un rapport incluant : liste complète des points de la checklist avec le statut et la date/heure de validation, relevé des anomalies rencontrées et corrigées, comparaison avant/après des performances clés, coûts réels vs budgétisés pour les trois premiers mois, et signature d'approbation des sponsors et responsables opérationnels. Ce rapport servira à la fois de preuve pour la conformité (audit trail), de base de comparaison pour les analyses de coût ultérieures, et de retour d'expérience pour les prochaines migrations. Mettez aussi à jour votre documentation d'infrastructure AWS avec les choix réels (ce qui a été déployé vs ce qui était prévu, raison des écarts), les procédures opérationnelles (comment monitorer, comment escalader une alerte), et les contacts d'urgence pour chaque composant critique. Enfin, planifiez le transfert de responsabilité vers l'équipe opérationnelle permanente (DevOps, SRE) : qui maintient quoi, selon quels SLA, avec quels outils de monitoring et d'alerte. La clôture administrative du projet ne doit pas être un événement séparé, mais la formalisation de ce transfert de responsabilité.