Hébergement cloud d’une application métier : VM, PaaS ou conteneurs ?

Une application métier ancienne arrive souvent avec des dépendances discrètes : tâche planifiée, répertoire partagé, base de données proche, impression, export nocturne, compte de service ou paramètre modifié directement en production. Avant de comparer les architectures cloud, il faut donc comparer ce que l’équipe devra réellement reprendre.

Le cadrage peut s’appuyer sur un registre des dépendances SI pour éviter de limiter l’analyse au serveur applicatif. Le coût cloud ne se résume pas au prix d’une instance : il inclut les environnements, les sauvegardes, les flux sortants, la supervision, les licences, les opérations manuelles et le temps passé à diagnostiquer.

Le transfert vers des machines virtuelles cloud est souvent l’option la plus directe. L’équipe conserve une grande partie de l’architecture existante : système, runtime, serveur applicatif, base parfois séparée, scripts et procédures proches du modèle actuel. Cette continuité réduit l’effort initial, surtout lorsque l’application est peu documentée ou difficile à modifier.

Le revers apparaît dans la durée. Les machines doivent rester dimensionnées, patchées, sauvegardées, supervisées et arrêtées lorsque les environnements ne servent plus. Si l’application était déjà surdimensionnée sur site, le cloud peut simplement rendre ce surdimensionnement plus visible dans la facture. Cette option convient lorsque l’objectif principal est de sortir d’une infrastructure contrainte sans réécrire l’application tout de suite.

Une approche PaaS consiste à confier davantage de briques au fournisseur cloud : exécution applicative, base de données managée, stockage objet, sauvegardes automatisées ou supervision intégrée. L’équipe réduit certaines tâches d’administration, mais doit accepter les conventions de la plateforme.

Cette option devient intéressante lorsque l’application peut être adaptée sans réécriture complète : configuration externalisée, stockage local remplacé, logs standardisés, connexions réseau clarifiées. Elle demande un travail plus précis sur les dépendances et les environnements, mais elle peut rendre les coûts plus pilotables si chaque composant est rattaché à un service métier, un propriétaire et un usage clair.

Les conteneurs apportent de la portabilité et une séparation plus nette entre l’application et l’infrastructure. Ils sont utiles lorsque plusieurs applications partagent les mêmes pratiques de déploiement, lorsque l’équipe dispose déjà d’une chaîne CI/CD solide ou lorsque l’application doit évoluer par versions fréquentes.

Ils ne suppriment pas la complexité. Une plateforme de conteneurs ajoute des sujets d’images, de registre, de réseau, de secrets, d’observabilité et de capacité. Pour une seule application métier stable, l’effort peut dépasser le bénéfice immédiat. Pour un portefeuille applicatif à moderniser progressivement, l’option devient plus crédible, notamment si elle s’inscrit dans une trajectoire de modernisation d’application métier.

Imaginons une application interne de planification utilisée chaque matin par une équipe opérationnelle. Elle fonctionne encore, mais son serveur approche de la fin de support. Le métier veut éviter une interruption, la DSI veut réduire la dépendance à l’infrastructure historique et l’équipe projet dispose d’une fenêtre courte.

Dans ce scénario hypothétique, une migration directe sur machines virtuelles peut sécuriser le calendrier si l’urgence porte sur l’hébergement. Un passage PaaS devient pertinent si l’application peut rapidement externaliser ses fichiers, ses paramètres et ses journaux. Les conteneurs n’ont de sens que si l’organisation possède déjà la chaîne de build, les contrôles et l’exploitation nécessaires. Sinon, la migration risque de mélanger deux projets : sauver l’hébergement et construire une plateforme.

La décision doit intégrer les coûts récurrents qui passent souvent après le choix d’architecture. Les environnements de recette restent-ils allumés en permanence ? Les sauvegardes sont-elles conservées plus longtemps que nécessaire ? Les logs applicatifs sont-ils volumineux sans valeur d’exploitation ? Les ressources portent-elles des étiquettes permettant de relier la dépense à une application, un environnement et un responsable ?

Une démarche FinOps adaptée ne cherche pas seulement à réduire la ligne de facture. Elle relie la dépense à une valeur de service et à une responsabilité. C’est le prolongement naturel d’une approche déjà décrite pour maîtriser les coûts cloud avec une démarche FinOps.

• Nommer le propriétaire métier et le propriétaire technique de l’application migrée.
• Lister les dépendances entrantes et sortantes avant de choisir le modèle d’hébergement.
• Comparer les coûts par environnement, pas seulement la production.
• Définir les règles d’arrêt, de redimensionnement et de suppression des ressources temporaires.
• Vérifier où seront gérés les secrets, les sauvegardes, les logs et les accès d’administration.
• Prévoir les critères de retour arrière pendant la période de bascule.
• Documenter la raison du choix pour éviter de rouvrir le débat à chaque incident ou renouvellement budgétaire.

Une application métier peut commencer sur machines virtuelles, puis évoluer vers des services managés lorsque ses dépendances sont clarifiées. Elle peut aussi rester sur une architecture simple si son usage est stable, son coût lisible et son exploitation maîtrisée. Le cloud n’impose pas une seule cible valable.

La décision solide est celle qui rend le compromis explicite : ce que l’équipe gagne maintenant, ce qu’elle accepte de conserver temporairement et ce qu’elle devra revoir plus tard. Sans cette clarification, le choix d’hébergement devient une préférence technique. Avec elle, il devient un arbitrage pilotable entre migration, exploitation et FinOps.