« Passer au cloud » ne décrit ni la destination d’une application ni son fonctionnement demain. Une architecture hybride peut être pertinente si elle répond à des contraintes précises ; elle devient coûteuse et fragile lorsqu’elle accumule des composants sans responsabilités claires. La décision se prend par charge de travail, avec des hypothèses que l’on peut vérifier.
Dresser une fiche de décision pour chaque application
Pour une application métier, notez les utilisateurs, les heures de service, les flux entrants et sortants, les dépendances, la sensibilité des données et la méthode actuelle de sauvegarde. Séparez ce qui doit changer de ce qui peut rester en place. Un ERP relié à une base locale, par exemple, ne se déplace pas sans mesurer la latence des échanges, le comportement en cas de coupure et l’ordre de migration des interfaces. Chaque application doit être évaluée selon ses propres contraintes.
- Documenter les contraintes de disponibilité et de localisation des données avec les responsables concernés.
- Comparer au moins les options « conserver », « moderniser », « déplacer » et « remplacer », avec leurs dépendances.
- Définir un critère de réussite observable pour un pilote limité.
Dessiner l’exploitation cible avant la migration
Qui déploiera les changements ? Qui surveillera les erreurs applicatives, les coûts et les accès ? Qui interviendra la nuit ou lors d’un incident réseau ? Le partage des responsabilités dépend du service utilisé et du contrat avec le fournisseur. Les cinq axes du cadre Azure Well-Architected — fiabilité, sécurité, optimisation des coûts, excellence opérationnelle et performance — offrent une grille de revue, même si l’architecture ne se limite pas à Azure.
Prévoyez la gestion des identités, les journaux utiles, les sauvegardes, les tests de restauration et la documentation des flux. Une application déplacée qui ne peut plus être diagnostiquée ou restaurée n’est pas un progrès.
Lire le coût complet et ses compromis
Le prix d’une machine virtuelle ne représente pas le coût d’exploitation. Les transferts de données, le stockage, les environnements oubliés, les licences, le support, la supervision et le temps d’équipe comptent aussi. La démarche FinOps associe équipes techniques, métiers et finance pour suivre les coûts technologiques et les rapprocher de la valeur des usages. Une mesure d’économie qui réduit la disponibilité attendue n’est pas automatiquement une bonne décision.
- Établir une estimation avec les hypothèses de charge et de croissance.
- Attribuer un propriétaire et un budget à chaque environnement.
- Revoir la consommation après la mise en service, plutôt que seulement au moment du devis.
Tester la reprise et conserver une porte de sortie
Avant de basculer un service critique, préparez les scénarios de retour arrière : données à synchroniser, délai acceptable, validation fonctionnelle et décision de bascule. L’objectif de reprise doit être défini avec le métier puis testé dans l’architecture choisie. Enfin, documentez les formats de données, les dépendances et les conditions contractuelles nécessaires à une évolution future. L’hybride fonctionne lorsqu’il reste compréhensible et pilotable après le projet de migration.
À retenir
Le choix d’hébergement n’a de sens qu’avec un modèle clair pour l’exploitation, les données, les coûts et la reprise.
