Étude de cas sur la migration d’un SaaS vers un VPS pour des bascules plus sûres
Publié le 28 septembre 2026
La base de données de production dépassait depuis longtemps les capacités de son environnement mutualisé, bien avant de tomber réellement en panne. Les temps de réponse augmentaient pendant les périodes de forte activité, les fenêtres de déploiement semblaient risquées et l’équipe ne disposait d’aucune procédure de reprise fiable si une mise à jour de plugin ou un problème de base de données tournait mal. Cette étude de cas sur la migration d’un SaaS vers un VPS suit un éditeur de logiciels B2B composite qui a déplacé son application vers un VPS géré sans transformer la nuit de migration en pari.
L’entreprise disposait d’un portail client, d’une API, de processus workers, d’une base de données PostgreSQL et de tâches d’envoi d’e-mails en arrière-plan, le tout exécuté sur une infrastructure d’hébergement devenue trop encombrée pour cette charge. Ce n’était pas une histoire de panne spectaculaire. Ce sont rarement les plus utiles. C’était une histoire de gestion des risques : migrer avant que la croissance normale ne devienne un incident.
Point de départ : une pile SaaS avec peu de marge
Le fournisseur SaaS servait environ 3 500 utilisateurs actifs, le trafic étant concentré pendant les heures de bureau aux États-Unis. Son application fonctionnait sur une pile web classique : Nginx, PHP-FPM, PostgreSQL, Redis et plusieurs tâches workers planifiées. L’équipe disposait d’un contrôle de version et de scripts de déploiement, mais l’infrastructure s’était constituée de manière pragmatique, comme souvent : un service ajouté après l’autre, jusqu’à ce que plus personne ne veuille toucher au serveur un vendredi.
La pression immédiate concernait les performances de la base de données. L’utilisation du processeur n’était pas constamment élevée, mais de courts pics provoquaient l’accumulation de requêtes lentes. Une contention des entrées-sorties disque apparaissait lorsque les sauvegardes s’exécutaient en même temps que les tâches de reporting. L’application parvenait généralement à récupérer, mais « généralement » n’est pas un objectif de reprise.
L’équipe avait également besoin de mieux contrôler les versions de PHP, la configuration des services, les règles du pare-feu et la supervision. L’hébergement mutualisé avait été utile au début, mais il avait atteint sa limite naturelle. Un VPS offrait des ressources dédiées allouées et un contrôle au niveau root, sans obliger l’entreprise à exploiter du matériel physique.
Une contrainte a guidé chaque décision : les sessions client et les workflows payants ne pouvaient pas être interrompus longtemps. Une migration avec plusieurs heures d’interruption était techniquement possible, mais commercialement peu attractive.
Vérifications effectuées avant la migration vers le VPS
Avant de provisionner le nouvel environnement, le plan de migration a séparé le système en composants pouvant être déplacés indépendamment et en composants nécessitant une bascule finale. Les fichiers statiques de l’application, les images de conteneurs et la plupart des configurations pouvaient être copiés en amont. La base de données nécessitait davantage de précautions, car elle continuait à évoluer jusqu’à la bascule finale.
L’équipe a d’abord mesuré l’utilisation réelle au lieu de choisir une offre VPS par optimisme. Elle a examiné les pics de CPU, la consommation de RAM, la taille de la base de données, la croissance du stockage, le comportement des IOPS, le transfert réseau et le nombre de processus workers simultanés. Le VPS obtenu a été dimensionné avec une marge pour les pics de trafic et la maintenance, et pas seulement avec une capacité suffisante pour reproduire les moyennes actuelles.
Un VPS géré a été choisi, car l’équipe de développement interne pouvait assurer la maintenance de l’application, mais ne souhaitait pas devenir le point d’escalade nocturne pour chaque alerte du système d’exploitation. Il faut énoncer clairement ce compromis : l’hébergement VPS non géré peut coûter moins cher sur le papier, mais il transfère la gestion des correctifs, la supervision, la validation des sauvegardes et le triage des incidents à vos propres équipes. Pour les équipes disposant de personnel dédié à l’infrastructure, cela peut être pertinent. Pour une petite équipe SaaS, cela devient souvent une distraction coûteuse qui se cache derrière un faible prix mensuel.
Le nouveau VPS a été renforcé avant l’arrivée des données applicatives. L’accès a été limité aux clés SSH, les services inutiles ont été supprimés, les règles du pare-feu n’autorisaient que le trafic requis et les mises à jour de sécurité automatiques ont été vérifiées pour assurer leur compatibilité avec la pile. Des utilisateurs système distincts ont été créés pour le déploiement et les processus de service. Les secrets ont été sortis de la base de code et placés dans des fichiers de configuration protégés.
Les sauvegardes ont été configurées sous deux formes : des sauvegardes hors serveur planifiées pour permettre la reprise après une perte du serveur, et des sauvegardes propres à la base de données pour restaurer les données plus rapidement. Une sauvegarde qui n’a jamais été restaurée n’est qu’un fichier plein d’espoir. L’équipe a restauré une sauvegarde de la base de données dans une base de test isolée et vérifié que l’application pouvait la lire correctement.
Le plan de migration reposait sur une bascule progressive
L’application a été déployée sur le nouveau VPS plusieurs jours avant la nuit de migration. Cela a donné à l’équipe le temps de comparer le comportement sous une charge réaliste et de résoudre les petites différences concernant les extensions PHP, les permissions des fichiers, l’exécution de cron, la configuration de Redis et la distribution des e-mails. Ces détails sont ennuyeux, jusqu’à ce qu’ils ne le soient plus.
Un nom d’hôte de préproduction a été utilisé pour les tests de bout en bout. Le personnel interne a vérifié la connexion, la création de comptes, les callbacks de facturation, les téléversements de fichiers, les rapports planifiés, l’authentification de l’API et le portail d’administration. Il a également testé la procédure de retour arrière. C’est l’étape que de nombreuses migrations ignorent, car la planification du retour arrière semble pessimiste. En réalité, c’est ce qui permet de prendre une décision sereine en cas de problème.
La bascule finale comportait quatre étapes opérationnelles :
- Réduire à l’avance le TTL DNS afin que les changements d’enregistrement se propagent plus rapidement.
- Effectuer une synchronisation initiale de la base de données tandis que l’ancienne plateforme restait active.
- Placer les fonctions générant beaucoup d’écritures en mode maintenance pour la courte synchronisation finale.
- Mettre à jour le DNS, vérifier le trafic de production et conserver l’ancien environnement disponible jusqu’à confirmation de la stabilité du nouveau service.
Le transfert initial a déplacé la majeure partie de la base de données sans affecter les utilisateurs. À l’heure de maintenance convenue, l’équipe a suspendu les nouvelles écritures, exécuté une synchronisation incrémentielle finale et démarré les services de production sur le VPS. La suspension des écritures a duré 11 minutes. Les utilisateurs qui naviguaient déjà pouvaient continuer à consulter la plupart des pages publiques et des pages de compte, tandis que les actions telles que la mise à jour des informations de facturation ou l’envoi de nouveaux enregistrements affichaient brièvement un avis de maintenance.
Cette approche n’était pas entièrement dépourvue de compromis. Une migration avec quasi-zéro interruption utilisant la réplication de base de données peut réduire davantage la fenêtre de maintenance finale, mais elle ajoute de la complexité et nécessite une préparation plus poussée. Pour ce fournisseur SaaS, une suspension contrôlée des écritures de 11 minutes était plus sûre que la conception d’une réplication que l’équipe n’était pas prête à exploiter par la suite. Une bonne infrastructure n’est pas toujours l’infrastructure la plus complexe.
Ce qui s’est passé pendant la bascule
L’enregistrement DNS a été mis à jour après la vérification finale de la base de données. L’équipe de migration a surveillé les journaux d’accès, les journaux d’erreurs, les connexions PostgreSQL, l’activité des workers PHP-FPM, les temps de réponse et la profondeur de la file d’attente en arrière-plan à mesure que le trafic atteignait le nouveau VPS.
Deux problèmes sont apparus durant la première heure. Une tâche de rapport planifiée utilisait un chemin codé en dur provenant de l’ancien serveur, et un fournisseur d’API externe avait autorisé l’ancienne adresse IP sortante. Aucun de ces problèmes n’a nécessité de retour arrière. Le chemin de la tâche de rapport a été corrigé et la liste d’autorisation du fournisseur a été mise à jour avec la nouvelle adresse du VPS. Les journaux racontaient désormais tous la même histoire.
L’équipe a conservé l’ancien environnement intact, mais y a désactivé les écritures publiques. Cela a créé une option de retour arrière protégée tout en empêchant la divergence des données entre les deux systèmes. Après 24 heures de comportement stable de l’application, de sauvegardes réussies et de traitement normal des files d’attente, l’ancien environnement a été retiré de la production.
Résultats après le passage au VPS
Le gain immédiat a été la régularité. Le temps de réponse médian de l’application s’est amélioré, car la base de données et les workers web ne rivalisaient plus avec des locataires sans rapport pour l’accès aux ressources. Plus utile encore que l’amélioration de la vitesse, la visibilité a permis à l’équipe de consulter le CPU, la RAM, le disque, le réseau, l’état des services et le comportement de la base de données dans une seule vue opérationnelle.
Le fournisseur SaaS a également gagné une routine de maintenance plus claire. Les mises à jour pouvaient être testées en préproduction avant la production, les sauvegardes s’exécutaient en dehors des heures de pointe du reporting et des responsables étaient définis pour les alertes. Grâce au support opérationnel géré et à la supervision active de kodu.cloud, l’équipe interne disposait d’un chemin d’escalade plus clair lorsque le comportement de l’infrastructure nécessitait une intervention.
La migration n’a pas supprimé toutes les responsabilités. Le client restait responsable des mises en production de l’application, de l’exactitude des données, des permissions utilisateur et des intégrations avec les fournisseurs. La couche d’hébergement pouvait être supervisée, corrigée, sauvegardée et prise en charge, mais aucun fournisseur ne peut déterminer si une fonctionnalité nouvellement déployée contient une erreur de logique métier. Des limites de responsabilité claires font partie d’une configuration saine.
Leçons pour les équipes SaaS qui prévoient de passer à un VPS
La principale leçon est que la qualité de la migration se décide avant la fenêtre de bascule. Le meilleur moment pour découvrir une tâche cron non documentée, un identifiant d’API expiré ou une table de base de données surdimensionnée est la préproduction, pas lorsque les clients actualisent leur navigateur.
Commencez par mesurer l’utilisation des ressources, puis prévoyez une marge de croissance. Mettez en place le nouveau serveur suffisamment tôt pour tester des workflows réels. Confirmez les sauvegardes en les restaurant. Définissez ce qui déclenche un retour arrière et qui peut prendre cette décision. Enfin, supervisez le service après les changements DNS au lieu de déclarer la victoire lorsque la commande de déploiement se termine.
Une migration vers un VPS devrait donner à votre équipe davantage de contrôle et moins de décisions prises au hasard tard dans la nuit. Si le plan prévoit une reprise testée, un transfert progressif et des personnes qui surveillent le serveur après l’arrivée du trafic, le service peut retrouver sa stabilité.
Andres Saar Ingénieur du support client