Quand un projet perso a besoin d’un vrai hébergement, et comment le déménager en un après-midi.

Un forfait gratuit est le bon endroit pour une idée. Il cesse de l’être à un moment précis, souvent plus tôt qu’on déménage. Un seul de ces signes suffit :

• Quelqu’un vous paie. Avec un client payant, « c’était en panne ce matin » devient une demande de remboursement. Le paiement amène aussi des factures, des données de carte traitées par un fournisseur et une adresse courriel qu’on doit pouvoir joindre.
• Les données sont irremplaçables. Des lignes de démo, ça se regénère. Six mois d’entrées d’un client, non. Le jour où la base contient la deuxième sorte, il faut une sauvegarde planifiée et la preuve qu’elle se restaure.
• Les utilisateurs voient les pannes avant vous. Si le premier signe de problème est un message d’un utilisateur, vous n’avez aucune surveillance. Une vérification de disponibilité gratuite et des alertes d’erreur règlent ça en dix minutes.
• L’appli se met en veille et les gens attendent. Les forfaits gratuits arrêtent souvent les applis inactives. Le premier visiteur après un creux attend un démarrage à froid, et le webhook d’un fournisseur de paiement peut expirer pendant ce temps.
• Vous distribuez l’adresse. Dès qu’elle figure sur une carte, une facture ou une fiche dans une boutique d’applis, ce doit être votre domaine. Quitter monappli.unhebergeur.app plus tard casse tous les liens et favoris.
• Vous recueillez des renseignements personnels. Une adresse courriel et un nom en sont. Les lois canadiennes s’appliquent dès la première fiche, pas à partir d’un certain nombre d’utilisateurs.

Pas Kubernetes, pas plusieurs régions. Pour un développeur seul, la production, c’est une courte liste de choses qui évitent de perdre des clients ou des données :

• L’appli reste en marche sans avoir besoin de trafic pour rester chaude.
• Elle répond sur votre domaine, en HTTPS renouvelé automatiquement.
• La base de données est sauvegardée au moins une fois par jour, et vous avez déjà restauré une de ces sauvegardes dans une base de test.
• Les erreurs vous arrivent par courriel, et un service externe vérifie la page d’accueil toutes les quelques minutes.
• Les secrets sont dans des variables d’environnement, pas dans le dépôt, et vous en gardez une copie ailleurs que chez l’hébergeur.
• La base de votre portable n’est pas celle de la production.

La plupart des projets perso sautent cette étape, alors qu’elle coûte peu quand la table des utilisateurs est petite. La LPRPDE vise les entreprises privées dans la plupart des provinces; la Loi 25 s’applique aux entreprises qui recueillent des renseignements sur des personnes au Québec. Aucune n’exempte les petites entreprises des obligations ci-dessous.

Cet ordre garde l’ancienne appli en service jusqu’à ce que la nouvelle ait fait ses preuves, et laisse un retour possible à chaque étape.

• Deux jours avant : baissez à 300 secondes le TTL de l’enregistrement DNS à modifier. Les résolveurs qui ont l’ancienne valeur en cache doivent attendre un ancien TTL complet : un enregistrement à 86 400 exige une journée entière. Chez Cloudflare, le minimum est de 60 secondes hors forfait Enterprise.
• Copiez les variables d’environnement. Listez chaque variable de l’ancien hébergeur et définissez-la dans le nouveau projet. Générez de nouveaux secrets quand c’est possible; un ancien secret qui a fui reste compromis.
• Déployez d’abord sur l’adresse de la plateforme. Créez un compte, téléversez un fichier, déclenchez le webhook de paiement en mode test. Corrigez ce qui casse pendant que personne ne regarde.
• Gelez les écritures. Mettez l’ancienne appli en maintenance ou en lecture seule, pour que rien n’arrive dans l’ancienne base après l’export.
• Exportez, restaurez, comparez. Utilisez pg_dump -Fc, restaurez dans la nouvelle base et comparez le nombre de lignes des tables principales.
• Sauvegardez la nouvelle base tout de suite, avant la première écriture d’un utilisateur. C’est votre point de départ connu.
• Changez le DNS. Ajoutez le domaine chez le nouvel hébergeur, pointez l’enregistrement et attendez l’émission du certificat HTTPS. Vérifiez depuis un téléphone sur données mobiles, qui passe par un autre résolveur que votre portable.
• Gardez l’ancien hébergeur une semaine, arrêté mais pas supprimé, avec son dernier export. Remontez ensuite le TTL à une heure ou plus.
• Restaurez une fois. Restaurez la sauvegarde la plus récente dans une base de test et ouvrez-la. Avant ça, vous avez des fichiers, pas des sauvegardes.

# 2 jours avant : baisser le TTL de l’enregistrement à changer, puis vérifier
dig +noall +answer app.example.com      # la 2e colonne est le TTL en secondes

# Bascule : arrêter les écritures sur l’ancien hébergeur, puis exporter
pg_dump -Fc --no-owner "$OLD_DATABASE_URL" -f backup.dump

# Restaurer dans la nouvelle base et comparer le nombre de lignes
canner db import backup.dump
psql "$OLD_DATABASE_URL" -c "select count(*) from users"
psql "$NEW_DATABASE_URL" -c "select count(*) from users"

Payez d’abord ce dont l’absence fait fuir les clients : une appli éveillée et un domaine. Le reste a presque toujours un palier gratuit suffisant jusqu’à l’arrivée d’un vrai trafic. Lancer un SaaS avec un petit budget détaille une facture mensuelle complète.