Une migration technique mal préparée coûte en moyenne 2,5 fois plus cher qu'une migration planifiée (source : étude Gartner, Cloud Migration Strategies, 2025). L'étape la plus critique n'est pas la migration elle-même, mais l'audit technique qui la précède. Voici la checklist complète en 8 points pour préparer une migration souveraine sans mauvaise surprise.
Point 1 : Inventorier tous les services
L'étape zéro consiste à dresser la carte complète de vos dépendances techniques. La plupart des PME sous-estiment le nombre de services tiers utilisés : un site web moyen en utilise entre 15 et 40.
- Hébergement : serveurs, CDN, DNS, load balancer
- Base de données : PostgreSQL, MySQL, Redis, MongoDB, Elasticsearch
- Services tiers : analytics, email, paiement, CRM, chatbot, monitoring
- Outils internes : CI/CD, stockage, messagerie, visioconférence
- APIs consommées : services météo, géolocalisation, traduction, IA
Le scan COCORRIDOR automatise cette étape pour la partie web : il détecte plus de 400 services via 14 vecteurs d'analyse (DNS, headers HTTP, scripts, cookies, certificats TLS, containers GTM). Pour les services non détectables par scan (outils internes, APIs back-end), complétez manuellement.
Point 2 : Cartographier les flux de données
Pour chaque service identifié, documentez :
- Quelles données sont transmises (données personnelles, données métier, logs)
- Dans quel sens circulent les données (lecture seule, écriture, bidirectionnel)
- Où sont stockées les données (pays, région cloud, datacenter)
- Qui y a accès (équipe interne, sous-traitant, API publique)
Cette cartographie est aussi exigée par le RGPD (article 30 : registre des traitements). L'audit technique pré-migration alimente directement votre conformité réglementaire.
« Chaque responsable du traitement tient un registre des activités de traitement effectuées sous sa responsabilité. Ce registre comporte le nom et les coordonnées du responsable, les finalités du traitement, les catégories de destinataires et les transferts de données. »
RGPD, article 30, paragraphe 1
Point 3 : Identifier les dépendances critiques
Certaines dépendances sont plus critiques que d'autres. Classez chaque service selon :
| Niveau | Définition | Exemple | Conséquence d'une panne |
|---|---|---|---|
| Critique | Le site ou l'application ne fonctionne pas sans | Base de données, hébergement, DNS | Site hors ligne |
| Élevé | Fonctionnalité majeure indisponible | Paiement, authentification, email transactionnel | Perte de revenu, blocage utilisateurs |
| Modéré | Dégradation de service sans arrêt | Analytics, CDN, monitoring | Moins de visibilité, performance réduite |
| Faible | Fonctionnalité non essentielle | Chat widget, A/B testing, social media embed | Impact négligeable |
Migrez les services par ordre de criticité inverse : commencez par les services à faible criticité (analytics, CDN) pour rôder le processus, puis migrez les services critiques en dernier avec un plan de rollback testé.
Point 4 : Vérifier les périodes d'engagement contractuel
Avant de planifier une migration, vérifiez :
- Durée d'engagement : certains contrats imposent un engagement annuel avec pénalité de sortie anticipée
- Préavis de résiliation : souvent 30 à 90 jours selon le fournisseur
- Portabilité des données : le RGPD (article 20) garantit un droit à la portabilité, mais en pratique les formats d'export varient
- Propriété intellectuelle : vérifiez que les données générées via l'outil vous appartiennent (templates, configurations, rapports)
Alignez le calendrier de migration avec les échéances contractuelles pour éviter de payer deux abonnements en parallèle plus longtemps que nécessaire.
Point 5 : Estimer les coûts complets
Le coût total d'une migration comprend :
- Frais de sortie (egress) : transfert de données depuis l'ancien fournisseur (AWS : 0,09 €/Go, Azure : 0,08 €/Go)
- Double facturation temporaire : ancien + nouveau fournisseur pendant la transition (2 à 4 semaines)
- Temps humain : équipe technique interne ou prestataire externe
- Adaptation applicative : modification du code si changement de service (ex : DynamoDB vers PostgreSQL)
- Tests et validation : staging, tests de charge, tests de non-régression
Règle générale : prévoyez un budget de +30 % au-dessus de l'estimation initiale pour absorber les imprévus.
Point 6 : Planifier le rollback
Chaque étape de migration doit avoir un plan de retour en arrière documenté :
- DNS : re-pointer vers l'ancienne IP (propagation : 5 min avec TTL 300s)
- Base de données : snapshot avant migration, restaurable en moins de 30 minutes
- Stockage : ne pas supprimer les données sources avant validation complète (minimum 7 jours)
- Application : déploiement de la version précédente en un clic (CI/CD avec historique)
Testez le rollback avant la migration en production. Un plan de retour non testé est un plan de retour inexistant.
Point 7 : Tester en staging
Reproduisez l'environnement cible complet :
- Déployez l'application sur l'infrastructure cible avec un domaine temporaire
- Importez un échantillon représentatif des données
- Exécutez les tests fonctionnels (parcours utilisateur complets)
- Mesurez les performances (latence, temps de réponse, throughput)
- Vérifiez les intégrations tierces (webhooks, callbacks, APIs)
- Testez le plan de rollback sur le staging
Point 8 : Documenter tout
La documentation post-migration est aussi importante que la migration elle-même :
- Schéma d'architecture : avant et après, avec les IP, ports, DNS
- Procédures opérationnelles : déploiement, backup, monitoring, alertes
- Runbook de rollback : étape par étape, avec les commandes exactes
- Registre RGPD : mise à jour du registre des traitements avec les nouveaux sous-traitants
- Leçons apprises : ce qui a fonctionné, ce qui a posé problème, pour les prochaines migrations
Erreurs fréquentes que l'audit prévient
| Erreur | Conséquence | Prévention |
|---|---|---|
| Oublier les enregistrements MX email | Emails professionnels indisponibles | Lister tous les enregistrements DNS actifs |
| TTL DNS trop élevé | Propagation lente, trafic vers l'ancien serveur | Baisser le TTL à 300s 48h avant |
| Certificats SSL non transférés | Avertissement « connexion non sécurisée » | Provisionner Let's Encrypt avant bascule |
| Cache CDN non purgé | Ancien contenu servi pendant des heures | Purger le cache CDN avant et après bascule |
| Webhooks pointant vers l'ancien serveur | Paiements, notifications perdus | Inventorier tous les webhooks et callbacks |
| Cron jobs oubliés | Tâches planifiées non exécutées | Lister les crontabs et scheduled tasks |
Quand faire appel à un expert
L'audit et la migration peuvent être réalisés en interne si votre équipe technique maîtrise les deux environnements (source et cible). Faites appel à un expert en migration souveraine dans ces situations :
- Infrastructure complexe (microservices, multi-cloud, services propriétaires)
- Données sensibles (santé, finance, juridique) nécessitant une certification HDS ou SecNumCloud
- Contrainte de temps (migration sous 30 jours)
- Aucune équipe technique interne
- Volume de données supérieur à 5 To
Lancez un scan gratuit pour démarrer votre audit avec un inventaire automatisé de vos dépendances web. Le Legal Builder génère automatiquement les documents RGPD mis à jour avec vos nouveaux sous-traitants.
Foire aux questions
Combien de temps dure un audit technique complet ?
Pour un site vitrine ou une application simple : 1 à 2 jours. Pour une infrastructure complexe (microservices, multi-cloud) : 3 à 5 jours. L'audit est un investissement : il représente généralement 10 à 15 % du budget total de migration mais évite des dépassements de 100 à 200 % en cas de mauvaise surprise.
L'audit est-il utile si je migre un seul service (ex : analytics) ?
Pour une migration isolée (remplacer GA4 par Matomo), un audit complet n'est pas nécessaire. Vérifiez simplement les intégrations (GTM, Looker Studio, segments d'audience) et la configuration de consentement. Pour une migration structurelle (hébergement, base de données), l'audit complet est indispensable.
Qui doit participer à l'audit ?
L'audit technique implique au minimum : le responsable technique (CTO, développeur principal), le responsable des données ou DPO (cartographie RGPD), et un décideur (budget et calendrier). Pour les PME sans CTO, un expert externe prend le rôle technique.