DSIApplication métierMaintenanceBudget
Migrer une application métier vers le cloud : les options, les coûts cachés et la méthode pour une PME
11 min de lecture
Pour migrer une application métier vers le cloud, choisissez d'abord la bonne stratégie : la déplacer telle quelle sur un serveur hébergé, adapter quelques briques (base de données, sauvegardes, stockage), ou la réécrire en application web. Le bon choix dépend de l'état de l'application, pas de la mode. Une application saine se déplace ; une application vieillissante qu'on déplace reste vieillissante, sur un serveur plus cher. Dans tous les cas, la reprise des données, les sauvegardes et la réversibilité se préparent avant la bascule.
La plupart des pages sur le sujet sont écrites par les grands fournisseurs de cloud ou par des intégrateurs qui migrent des centaines de serveurs. Cet article s'adresse à une PME qui a une application importante, souvent installée sur un serveur dans un local technique, et qui se demande quoi en faire.
Pourquoi la question se pose maintenant
Les déclencheurs sont presque toujours les mêmes :
- le serveur arrive en fin de vie, et son remplacement oblige à décider où l'application vivra les cinq prochaines années ;
- le travail à distance : commerciaux, techniciens ou dirigeants veulent l'application hors du bureau, et le VPN ne suffit plus ;
- un incident : panne, rançongiciel, sauvegarde qui ne se restaure pas ;
- le départ de la personne qui s'en occupait, interne ou prestataire ;
- un éditeur ou un composant qui n'est plus maintenu, comme une version ancienne de Windows Server ou de la base de données.
Si votre cas est surtout le dernier, lisez aussi notre article sur la refonte d'un logiciel métier plus maintenu : la question n'est alors plus seulement « où héberger », mais « faut-il le garder ».
Les stratégies possibles, en clair
Les fournisseurs de cloud classent les migrations en grandes stratégies. La documentation d'AWS en recense sept, les « 7 R ». Pour une seule application métier, quatre comptent vraiment :
| Stratégie | Ce qu'on fait | Quand c'est le bon choix |
|---|---|---|
| Réhéberger (« lift and shift ») | Déplacer l'application telle quelle sur un serveur hébergé | Application saine, urgence matérielle |
| Adapter (« replatform ») | Déplacer et remplacer quelques briques par des services gérés | Base de données ou sauvegardes fragiles |
| Réécrire (« refactor / rebuild ») | Refaire l'application en web, pensée pour le cloud | Application en fin de vie, client lourd, besoin mobile |
| Remplacer (« repurchase ») | Passer à un logiciel du marché en abonnement | Besoin standard, bien couvert par un SaaS |
Les trois autres (retirer, conserver, relocaliser) concernent surtout les grands parcs : retirer une application inutile, en garder une sur place faute de mieux, ou déplacer des machines virtuelles en bloc.
AWS recommande lui-même, pour les grandes migrations, de déplacer d'abord et de moderniser ensuite, la réécriture étant la stratégie la plus complexe et la plus coûteuse. Pour une PME avec une seule application, le raisonnement est différent : si l'application doit de toute façon être refaite dans deux ans, payer un réhébergement soigné entre-temps peut être de l'argent perdu.
Le cas du client lourd
Beaucoup d'applications métier de PME sont des logiciels Windows installés sur chaque poste, reliés à une base de données sur le serveur du bureau : WinDev, Access, Delphi, Visual Basic, ou un progiciel ancien. Deux voies existent.
Le bureau à distance
On installe l'application et sa base sur un serveur hébergé, et les utilisateurs s'y connectent par bureau à distance ou par publication d'application. Avantages : rapide, sans toucher au code, accessible hors du bureau. Limites : les licences Windows Server et d'accès distant s'ajoutent, l'impression et les périphériques locaux posent souvent problème, l'usage sur téléphone reste pénible, et l'application n'a pas rajeuni d'un jour.
La réécriture en application web
On refait l'application pour qu'elle s'ouvre dans un navigateur, sur ordinateur comme sur mobile, avec une base de données hébergée et des sauvegardes gérées. C'est un vrai projet, mais c'est aussi l'occasion de supprimer les contournements accumulés. Nos articles sur la migration WinDev vers le web et sur le passage d'Access à une application web détaillent ces deux cas fréquents.
Une voie intermédiaire marche bien : bureau à distance tout de suite pour régler l'urgence matérielle, puis réécriture progressive, module par module, selon la méthode de refonte par étapes.
Où héberger : ce qui compte vraiment
Le choix de l'hébergeur tient en quelques questions :
- La localisation des données et des sauvegardes. Le RGPD n'impose pas la France, mais il encadre les transferts hors de l'Union européenne. Notre article où héberger une application métier détaille les règles, y compris l'hébergement HDS pour les données de santé.
- Le partage des responsabilités. Chez un fournisseur de cloud, la sécurité du centre de données est à sa charge ; celle de votre application, de vos comptes et de vos sauvegardes reste à la vôtre. AWS le formalise dans son modèle de responsabilité partagée, et les autres fournisseurs appliquent le même principe.
- Le niveau de service. Disponibilité garantie, délai d'intervention, et surtout fréquence et durée de conservation des sauvegardes.
- La simplicité. Pour une seule application, un hébergeur européen avec des serveurs gérés est souvent plus lisible qu'un grand cloud aux centaines de services.
Les coûts qu'on oublie
Un devis de migration couvre souvent le transfert, rarement le reste. Comparez sur trois à cinq ans :
| Poste | Serveur au bureau | Application dans le cloud |
|---|---|---|
| Matériel | Achat, puis remplacement périodique | Aucun, inclus dans l'abonnement |
| Hébergement | Électricité, onduleur, climatisation | Facture mensuelle, souvent à l'usage |
| Licences | Déjà payées, parfois plus maintenues | Licences serveur ou d'accès distant à louer |
| Sauvegardes | Disque externe, souvent jamais testé | Service géré, à configurer et tester |
| Administration | Temps interne ou prestataire | Toujours nécessaire, sous une autre forme |
| Sortie | Sans objet | Export des données, encadré par le Data Act |
Deux pièges reviennent souvent : les ressources surdimensionnées qu'on ne réduit jamais après la bascule, et les frais de transfert de données sortantes, facturés par certains fournisseurs. Pour le budget d'une réécriture, voyez le prix de la refonte d'un logiciel métier.
La réversibilité, désormais encadrée
Changer de fournisseur de cloud a longtemps été coûteux. Le règlement européen sur les données, dit Data Act (règlement 2023/2854), applicable depuis le 12 septembre 2025, change la donne pour les clients européens : le préavis pour lancer un changement de fournisseur ne peut pas dépasser deux mois, une période de transition de 30 jours est prévue, et à partir du 12 janvier 2027, les fournisseurs ne pourront plus facturer de frais de changement (article 29).
Le droit ne règle pas tout : une application qui s'appuie sur des services propres à un fournisseur reste coûteuse à déplacer. Préférez des briques standard (base de données relationnelle classique, conteneurs, stockage compatible) quand le gain d'un service propriétaire n'est pas évident. Côté prestataire, la même vigilance s'applique : voyez la réversibilité quand on change de prestataire.
La méthode en sept étapes
- Inventorier. Serveurs, versions, base de données, fichiers partagés, tâches planifiées, imprimantes, liaisons avec d'autres logiciels. Ce qui n'est pas listé sera oublié à la bascule.
- Évaluer l'application. Code disponible, documentation, versions encore maintenues, dette technique. Un audit de l'application existante évite de déplacer un problème.
- Choisir la stratégie dans le tableau plus haut, application par application si vous en avez plusieurs.
- Préparer les données. Nettoyage, volumes, durée de transfert, et une reprise de données testée sur une copie.
- Migrer une copie et la faire tester par des utilisateurs réels, sur leurs cas quotidiens, imprimantes comprises.
- Basculer un week-end ou un soir, avec un plan de retour arrière écrit et une ancienne installation gardée en lecture seule quelques semaines.
- Restaurer une sauvegarde dans le mois qui suit. Une sauvegarde qui n'a jamais été restaurée n'est pas une sauvegarde.
Les erreurs les plus fréquentes
- Déplacer sans regarder. Le réhébergement d'une application dont personne ne maîtrise le code transporte la dette dans un endroit plus cher.
- Oublier les liaisons. L'export comptable de 18 h, le partage réseau du scanner, le fichier déposé par un fournisseur : tout ce qui touchait le serveur doit être retrouvé.
- Négliger la latence. Un client lourd conçu pour un réseau local peut devenir très lent s'il interroge une base distante directement.
- Couper l'ancien serveur trop tôt. Gardez-le, éteint ou en lecture seule, jusqu'à la première clôture mensuelle réussie.
- Laisser la sécurité par défaut. Comptes administrateurs partagés, accès ouverts sur internet : les règles de sécurité d'une application métier s'appliquent dès le premier jour.
Quand ne pas migrer
Restez sur place si l'application dépend d'un matériel local sans équivalent distant (une machine d'atelier, un automate), si elle sera remplacée sous peu par un logiciel du marché, ou si elle sert trois personnes au même endroit et fonctionne bien. Dans ce dernier cas, une sauvegarde externalisée et testée apporte l'essentiel de la sécurité pour un coût bien moindre.
Par où commencer
Faites l'inventaire, puis posez la seule question qui compte : cette application doit-elle vivre encore cinq ans telle qu'elle est ? Si oui, déplacez-la proprement. Si non, la migration est l'occasion de la refaire, et vous pouvez voir le résultat avant d'engager un budget : nous construisons un prototype visuel gratuit de la future application web, présenté en visio sous 5 jours ouvrés, comme l'explique voir son logiciel avant de le payer.