BlogCloud et DevOps
Une migration cloud réussie commence par un inventaire de l’existant et un choix de stratégie application par application, pas par le choix d’un fournisseur. Le coût final dépend surtout de l’architecture cible, du volume de données transférées et de la discipline d’exploitation après la bascule ; les risques se réduisent avec un pilote, des vagues de migration et un plan de retour arrière testé.
Sommaire de l’article
Pourquoi migrer, et quand ne pas le faire
Le cloud apporte de la souplesse : des ressources ajustées à la charge, des services managés (bases de données, files de messages, stockage objet) qui évitent d’administrer soi-même des serveurs, des environnements de test créés en quelques minutes, des sauvegardes et une redondance géographique plus simples à mettre en place. Pour une PME, l’intérêt principal est souvent de ne plus dépendre d’un serveur unique dans un local, d’une seule personne qui sait le maintenir, ou d’un matériel en fin de vie.
Migrer n’est pas toujours la bonne décision. Il vaut mieux attendre ou s’abstenir quand :
- l’application est stable, peu sollicitée et déjà correctement hébergée et sauvegardée ;
- un logiciel du marché n’est licencié que pour un usage sur site, ou son éditeur ne supporte pas l’hébergement cloud ;
- des contraintes contractuelles ou réglementaires imposent un lieu de stockage que l’offre visée ne permet pas de garantir ;
- l’équipe n’a ni le temps ni les compétences pour exploiter la nouvelle plateforme, et aucun accompagnement n’est prévu ;
- l’objectif est uniquement de « réduire les coûts » sans mesure préalable de ce que coûte l’existant.
Inventaire et évaluation de l’existant
L’inventaire est l’étape la plus rentable du projet : il évite de découvrir une dépendance oubliée le jour de la bascule. Pour chaque application, documentez :
- Le rôle métier et la criticité : qui l’utilise, à quels moments, ce que coûte une heure d’arrêt pour l’activité.
- La pile technique : système d’exploitation, langage, version de base de données, serveur web, tâches planifiées.
- Les dépendances : autres applications, API externes, partages de fichiers, annuaire d’utilisateurs, imprimantes, adresses IP codées en dur.
- Les données : volume, croissance, sensibilité (données personnelles, financières, de santé), durée de conservation.
- Les licences : conditions d’usage en cloud, mode de facturation (par cœur, par utilisateur, par serveur).
- L’exploitation actuelle : sauvegardes, supervision, procédure de mise à jour, personne responsable.
Cet inventaire sert aussi à mesurer le coût actuel (matériel, électricité, maintenance, temps passé) : sans ce point de départ, impossible de dire si la migration est rentable.
Les stratégies de migration, application par application
Les grands fournisseurs décrivent plusieurs stratégies, souvent appelées les « R » de la migration. Une même entreprise en combine généralement plusieurs.
| Stratégie | Principe | Quand elle convient |
|---|---|---|
| Rehost (« lift and shift ») | Déplacer l’application telle quelle sur des machines virtuelles cloud. | Échéance courte (fin de contrat, matériel en fin de vie), application peu modifiable ; on optimise plus tard. |
| Replatform | Changements limités pour profiter de services managés (base de données managée, conteneurs) sans réécrire le code métier. | Application saine dont l’administration de la base ou des serveurs pèse sur l’équipe. |
| Refactor (réarchitecture) | Revoir l’architecture pour tirer parti du cloud : découpage, mise à l’échelle automatique, services serverless. | Application stratégique, qui évolue souvent et dont la charge varie fortement ; demande le plus d’effort. |
| Replace (repurchase) | Remplacer par une offre SaaS du marché. | Besoin standard (messagerie, comptabilité, CRM) sans avantage concurrentiel à garder un outil maison. |
| Retire | Arrêter l’application après archivage des données utiles. | Outil peu ou plus utilisé, doublon fonctionnel découvert pendant l’inventaire. |
| Retain | Garder l’application où elle est, pour l’instant. | Contrainte de licence ou réglementaire, migration trop risquée à court terme, application bientôt remplacée. |
Pour un logiciel développé en interne, la question rejoint celle de sa modernisation : voir notre article logiciel sur mesure ou logiciel standard.
Les postes de coût à anticiper
Le prix d’une migration dépend trop de l’existant pour être donné sans inventaire. En revanche, les postes de coût sont toujours les mêmes :
- Calcul : machines virtuelles, conteneurs ou fonctions, facturés à la durée ou à l’exécution ; une instance surdimensionnée et allumée en permanence est la première source de dépassement.
- Stockage : disques, stockage objet, instantanés et sauvegardes, avec des niveaux de prix selon la fréquence d’accès.
- Transfert de données sortant (egress) : les données qui sortent du cloud vers Internet ou vers un autre fournisseur sont généralement facturées ; un site très consulté ou une synchronisation avec un serveur resté sur site peut peser lourd.
- Services managés : bases de données, équilibreurs de charge, passerelles, journalisation ; pratiques, mais chacun ajoute une ligne à la facture.
- Licences : systèmes d’exploitation, bases de données commerciales, logiciels tiers dont les conditions changent parfois en cloud.
- Effort de migration : inventaire, adaptation du code, tests, double fonctionnement pendant la transition.
- Formation : l’équipe doit apprendre à exploiter, sécuriser et surveiller la nouvelle plateforme.
- Coût d’exploitation (run) : supervision, mises à jour, gestion des incidents, revues de coûts régulières.
Pour garder la maîtrise, activez dès le premier jour les outils natifs de suivi des coûts : étiquettes (tags) par application et par environnement, budgets avec alertes par e-mail, tableaux de bord de dépenses et recommandations de redimensionnement. Éteindre automatiquement les environnements de test hors heures de travail est l’une des mesures les plus simples.
Les risques et comment les réduire
| Risque | Mesure de réduction |
|---|---|
| Interruption de service | Bascule planifiée hors période d’activité, communication aux utilisateurs, plan de retour arrière testé. |
| Perte ou corruption de données | Sauvegarde complète avant bascule, vérification des volumes et de contrôles d’intégrité après transfert. |
| Mauvaise configuration de sécurité | Accès public fermé par défaut, comptes nominatifs avec authentification multifacteur, droits minimaux, revue de configuration. |
| Dépendance au fournisseur (lock-in) | Conteneurs, standards ouverts et infrastructure décrite en code ; usage réfléchi des services propriétaires. |
| Dépassement de budget | Estimation à partir de l’inventaire, budgets et alertes, revue mensuelle des dépenses. |
| Localisation des données et obligations légales | Choix de la région d’hébergement, vérification des contrats et des obligations applicables avant migration. |
Sur ce dernier point, deux textes sont à vérifier selon votre situation : la loi organique tunisienne n° 2004-63 relative à la protection des données à caractère personnel, notamment pour les transferts de données vers l’étranger, et le RGPD si vous traitez des données de personnes situées dans l’Union européenne. Cet article ne constitue pas un avis juridique : faites valider ces points par votre conseil ou auprès de l’autorité compétente avant de choisir une région d’hébergement. Pour les aspects sécurité de l’hébergement, voir aussi cybersécurité et hébergement web en Tunisie.
Le plan de migration, étape par étape
- ÉvaluationInventaire, coût actuel, criticité, stratégie retenue pour chaque application et ordre de passage.
- Architecture cibleRéseau, comptes et environnements séparés, gestion des identités, sauvegardes, supervision, région d’hébergement. Les cadres « Well-Architected » des fournisseurs servent de grille de revue.
- PiloteUne application peu critique mais représentative, migrée de bout en bout pour valider la méthode, les outils et l’estimation des coûts.
- Vagues de migrationDes lots d’applications regroupées par dépendances, du moins critique au plus critique, avec un bilan après chaque vague.
- Bascule avec plan de retour arrièreSynchronisation finale des données, tests de recette, bascule du DNS ; critères de décision et procédure de retour à l’ancien système écrits et répétés à l’avance.
- OptimisationRedimensionnement selon la charge réelle, nettoyage des ressources inutilisées, arrêt de l’ancienne infrastructure une fois la stabilité confirmée.
Sauvegardes et objectifs de reprise : RPO et RTO
Deux indicateurs fixent le niveau de protection attendu pour chaque application, et donc son architecture et son coût :
- RPO (Recovery Point Objective) : la quantité maximale de données que vous acceptez de perdre, exprimée en durée. Un RPO d’une heure impose une sauvegarde ou une réplication au moins toutes les heures.
- RTO (Recovery Time Objective) : la durée maximale d’interruption acceptable avant le retour du service. Un RTO court suppose une infrastructure prête à redémarrer, voire déjà active dans une autre zone.
Plus ces objectifs sont exigeants, plus la solution coûte cher : fixez-les avec les métiers, application par application. Et une sauvegarde n’a de valeur que si la restauration a été testée : planifiez des exercices de restauration réguliers et conservez au moins une copie isolée du compte principal.
Ce qu’il faut automatiser
- L’infrastructure en code (Terraform, OpenTofu ou les outils natifs du fournisseur) : l’environnement est reproductible, versionné, revu comme du code, et peut être recréé ailleurs, ce qui limite aussi la dépendance au fournisseur.
- La chaîne CI/CD : construction, tests, analyse de sécurité et déploiement automatisés réduisent les erreurs manuelles et rendent les retours arrière rapides. C’est le cœur de notre offre cloud, DevOps et CI/CD (Docker, GitLab CI).
- La supervision : métriques, journaux centralisés, alertes sur la disponibilité, les erreurs, la saturation et les dépenses.
Avant d’exposer les applications migrées, passez-les en revue avec notre checklist de sécurité applicative.
Sources et références
Vous envisagez de migrer une ou plusieurs applications vers le cloud ? Partagez votre inventaire, même partiel : nous vous aidons à choisir la stratégie et à préparer un plan par étapes.