Une société de transport de la région d'Annemasse nous a appelés avec une demande simple en apparence : mettre son serveur dans le cloud. La machine héberge une application de gestion des tournées installée en 2016, une base de données SQL Server, un partage de fichiers et deux tâches de nuit qui produisent les récapitulatifs de facturation. Le dirigeant voulait sortir le serveur du placard technique, parce que la climatisation du local avait lâché deux fois pendant l'été. Un intégrateur consulté auparavant avait répondu par une proposition de refonte complète en conteneurs, sur dix-huit mois. Les deux interlocuteurs parlaient du même serveur, mais pas du même projet.
Cette confusion revient dans presque tous les dossiers de migration cloud que nous instruisons. Elle se dénoue en distinguant clairement deux stratégies, dont les coûts, les délais et les risques n'ont rien de comparable.
Reprendre la machine telle quelle ou réécrire l'application : les deux termes posés
La reprise telle quelle, appelée lift and shift dans le vocabulaire des fournisseurs, consiste à emporter la machine virtuelle vers le cloud en conservant son système d'exploitation, ses logiciels et sa configuration. Vous retrouvez le même serveur, au même nom, avec les mêmes habitudes d'exploitation, mais dans un centre de données professionnel au lieu d'un placard. La facture devient mensuelle et proportionnelle à la puissance réservée.
La réécriture pour tirer parti des services managés, appelée refactor, consiste au contraire à découper l'application pour confier chaque morceau à un service géré par le fournisseur : une base de données administrée par le fournisseur au lieu d'un SQL Server que vous mettez à jour vous-même, un stockage objet au lieu d'un disque, une file de messages au lieu d'un dossier surveillé, éventuellement des conteneurs. Vous n'administrez plus de système d'exploitation, la capacité s'ajuste, et le code doit être modifié pour fonctionner ainsi.
Un troisième cran existe entre les deux, souvent plus utile qu'on ne le croit. Il consiste à déplacer la machine sans réécrire l'application, tout en sortant les éléments que le fournisseur sait mieux tenir que vous : la base de données passe en service managé, les sauvegardes s'exécutent en dehors du serveur, la supervision est branchée, le réseau est refait proprement. L'application ne change pas d'une ligne, mais les tâches d'exploitation les plus ingrates disparaissent.
Ce que la reprise telle quelle emporte avec elle, défauts compris
Le principal avantage de cette approche est la prévisibilité. L'inventaire est court, le comportement de l'application reste identique, la formation des utilisateurs est nulle, et vous pouvez basculer en quelques semaines plutôt qu'en plusieurs trimestres. Quand une application vieillissante n'est plus modifiée mais reste indispensable, cette voie est la bonne, et il n'y a rien de honteux à la choisir.
Son inconvénient est qu'elle déplace aussi les problèmes. Une version de système d'exploitation qui n'est plus corrigée par son éditeur reste sans correctifs dans le cloud. Un accès de bureau à distance ouvert sur Internet devient un accès ouvert sur Internet depuis une adresse publique de fournisseur, ce qui ne l'améliore en rien. Des droits d'accès aux fichiers accumulés depuis dix ans restent aussi désordonnés qu'avant. Nous profitons donc systématiquement de la bascule pour traiter trois points : la version du système et son support, l'exposition réseau qui doit passer par un accès contrôlé plutôt que par un port publié, et les comptes d'administration qui doivent devenir nominatifs.
Le second inconvénient est financier. Une machine reprise telle quelle tourne en continu, dimensionnée sur son pic historique, et cette réservation permanente se paie tous les mois alors que le serveur du placard était un investissement amorti. C'est la raison pour laquelle nous ouvrons le sujet de la discipline de suivi des coûts dès le premier jour, comme nous l'expliquons dans notre article sur une facture cloud qui augmente.
Les situations où la réécriture se justifie, et celles où elle s'enlise
La réécriture devient pertinente quand plusieurs conditions se rencontrent. L'application est encore développée, par une équipe interne ou par un éditeur qui accompagne le mouvement. La charge varie fortement, par exemple parce que votre activité connaît des pointes saisonnières ou parce qu'un portail public reçoit un trafic irrégulier. Vous avez besoin d'une capacité qui s'ajuste réellement, et pas seulement de l'idée qu'elle pourrait s'ajuster. Enfin, quelqu'un chez vous restera propriétaire de cette architecture après le départ du prestataire.
Elle s'enlise quand ces conditions manquent. Nous voyons régulièrement des projets où une application interne utilisée par douze personnes, dont la charge est parfaitement stable et connue, est découpée en services autonomes orchestrés par un cluster que personne dans l'entreprise ne sait dépanner. Le résultat est une architecture plus fragile que la machine de départ, avec une facture supérieure et une dépendance totale au prestataire. Nous développons ce point dans notre article expliquant pourquoi Kubernetes arrive trop tôt pour beaucoup de PME.
Un critère pratique tranche souvent la question : demandez-vous ce que vous ferez de cette application dans trois ans. Si vous prévoyez de la remplacer, ne la réécrivez pas, déplacez-la proprement et attendez le remplacement. Si vous prévoyez de l'enrichir régulièrement, la réécriture devient un investissement défendable.
Les contraintes qui décident à votre place
Certaines contraintes ferment des options avant même que la discussion technique commence, et elles doivent être examinées en premier.
- Une licence logicielle attachée à un identifiant matériel ou à un boîtier physique interdit parfois purement et simplement le déplacement de la machine. La réponse se trouve chez l'éditeur, pas dans la console du fournisseur cloud.
- Une obligation de conserver les données sur le territoire suisse restreint le choix des régions disponibles et oriente vers un hébergement souverain ou un cloud privé, sujet que nous traitons dans notre article sur les données conservées en Suisse.
- Un équipement industriel qui doit dialoguer en local avec le serveur impose de conserver une partie du système d'information au bureau, quelle que soit la stratégie retenue par ailleurs.
- Une application dont l'éditeur ne supporte officiellement qu'une configuration précise limite la réécriture, car vous perdriez le support en modifiant l'architecture.
Comment nous instruisons la décision avant de chiffrer une migration
Nous commençons par relever l'existant sans a priori : la consommation réelle de la machine sur plusieurs semaines et non sa taille nominale, les dépendances entre l'application et le reste du réseau, la version du système et son horizon de support, l'état des sauvegardes, et l'identité des personnes qui détiennent les accès d'administration. Ce relevé occupe généralement quelques jours et il change souvent la conclusion, parce qu'un serveur jugé saturé se révèle largement dimensionné, ou l'inverse.
Nous rendons ensuite une recommandation écrite, application par application. Il est fréquent qu'un même système d'information mélange les trois approches : le serveur de fichiers part tel quel, la base de données passe en service managé, une application spécifique attend d'être remplacée et reste sur place, et un portail public récent est réécrit. Nous chiffrons la trajectoire en journées, à 1000 HT / jour, avec le même montant hors taxes en euros et en francs, et nos missions cloud se déroulent à distance dans toute la France et en Suisse. Le déroulé de la bascule elle-même, avec sa fenêtre de risque et son plan de repli, fait l'objet d'un travail distinct que nous décrivons dans notre article sur la façon de migrer sans couper le service un week-end entier.
Si un prestataire vous propose une refonte en conteneurs alors que vous cherchiez d'abord à sortir un serveur d'un local mal ventilé, envoyez-nous l'architecture actuelle. Nous vous dirons si la reprise telle quelle suffit, si la réécriture se justifie sur une partie du périmètre, ou si votre serveur mérite simplement d'être hébergé correctement sans changer d'architecture.