Migrer la plateforme vers un nouveau VPS

Ce document est un plan à exécuter, actualisé le 20 octobre 2026. Il ne confirme aucune création de compte, migration de données, modification DNS ou mise en production déjà réalisée. Chaque étape comporte un résultat à vérifier avant de poursuivre.

Périmètre confirmé et décisions à compléter

• OVH est le registrar de leclosdeseucalyptus.com et leclosdeseucalyptus.fr ; les domaines restent enregistrés chez OVH. Changer leurs serveurs DNS ne transfère pas leur enregistrement.
• Le site public actuellement hébergé sur Heroku sera remplacé. Sa base de données ne sera pas importée. Son inventaire d’URL reste utile pour les redirections et le référencement.
• Le domaine canonique cible est https://www.leclosdeseucalyptus.com.
• La nouvelle plateforme comprend SvelteKit, le backend Go/PocketBase, Dokploy, le portail documentaire et Storybook, avec des environnements séparés.
• Un nouveau compte Cloudflare et un nouveau compte/organisation OpenAI API sont prévus.
• [email protected] est et restera hébergée chez OVH. La migration web ne déplace ni cette boîte, ni ses messages. Ses enregistrements de messagerie doivent être conservés.
• Les autres adresses/alias éventuels, le fournisseur DNS actuellement autoritaire, la disponibilité des anciens comptes et les données éditoriales Harmony à conserver restent à inventorier.

L’absence d’import de données Heroku ne signifie pas que les contenus, médias, utilisateurs et configurations déjà préparés dans PocketBase doivent être perdus. Choisir explicitement entre une restauration de cette base Harmony et une initialisation de production contrôlée.

Architecture cible

Hôte proposé	Destination	Accès et indexation
www.leclosdeseucalyptus.com	Web de production sur le nouveau VPS	Public et indexable après ouverture
leclosdeseucalyptus.com	Redirection permanente vers www	Chemin et paramètres conservés, sauf mapping d’ancienne URL
leclosdeseucalyptus.fr et www.leclosdeseucalyptus.fr	Redirection vers le domaine canonique .com	Une seule destination publique de référence
preview.leclosdeseucalyptus.com	Web de staging	Cloudflare Access et noindex
*.preview.leclosdeseucalyptus.com	Previews web de PR	Access, noindex, durée de vie limitée
api.leclosdeseucalyptus.com	Backend production, si une exposition HTTPS est nécessaire	Authentification applicative ; administration protégée
api-preview.leclosdeseucalyptus.com et ses previews	Backend de recette	Données et accès isolés
docs.leclosdeseucalyptus.com	Documentation	Décider explicitement de son accès et de son indexation
storybook.leclosdeseucalyptus.com	Storybook	Accès de recette, non indexable
dokploy.leclosdeseucalyptus.com	Administration Dokploy	Accès réservé aux opérateurs

Les noms supplémentaires sont une proposition, à valider avant de créer les applications. Un wildcard ne couvre pas l’hôte racine : configurer aussi preview et api-preview. Le web contacte de préférence son backend sur le réseau Docker privé, via API_BASE_URL. Le domaine ne doit pas rediriger les visiteurs vers une adresse IP : le DNS désigne le VPS, puis Traefik route le nom d’hôte vers le bon conteneur.

Pour une machine unique, retenir 4–8 vCPU, 16 Go de RAM et au moins 160 Go NVMe. Pour isoler la production : prévoir un VPS production de 4 vCPU/8 Go et un serveur séparé pour staging/previews. Les configurations détaillées sont dans le guide des services.

Ordre des opérations et responsabilités

Phase	Responsable principal	Condition de sortie
1. Inventaire et URL historiques	Opérateur + responsable du site	Accès, sauvegardes, DNS et URLs recensés
2. Nouveaux comptes et VPS	Opérateur	Accès de secours et infrastructure disponibles
3. Services externes et CI	Opérateur + développeur	Secrets et destinations de livraison validés
4. Déploiement de recette	Développeur + validateur	Parcours fonctionnels et restauration testés
5. Préparation Google et redirections	Responsable du site + développeur	Propriétés vérifiées, mapping et prérequis SEO prêts
6. Délégation DNS Cloudflare	Opérateur	Deux zones actives ; Heroku continue de répondre
7. Copie finale Harmony et préparation production	Opérateur	Nouvelle plateforme cohérente, protégée et testée
8. Bascule des origines et ouverture	Opérateur + validateur	Site, e-mails, formulaires et indexation conformes
9. Surveillance et retrait de l’ancien hébergement	Opérateur	Stabilité et sauvegardes confirmées

Planifier la délégation DNS et le changement d’hébergement dans deux opérations distinctes. Prévoir plusieurs jours pour les préparatifs et une fenêtre de bascule avec opérateur disponible. La durée réelle dépend des volumes à transférer, des certificats et des caches DNS ; aucune absence totale d’interruption n’est garantie sans répétition préalable.

Fixer avant la bascule le délai maximal de retour au service (RTO), la perte de données acceptable (RPO) et la rétention des copies. L’objectif de la copie finale Harmony est de ne perdre aucune écriture conservée grâce au gel ; le délai de restauration doit être mesuré en répétition. Voir sauvegardes et restauration.

Phase 1 — Inventorier et constituer le dossier de migration

1. Confirmer les propriétaires et accès de secours : OVH, Heroku, VPS actuel Harmony, GitHub, Cloudflare, OpenAI, SMTP, MapTiler et Google. Activer la MFA et conserver les codes de secours dans le coffre de l’organisation.
2. Exporter les zones DNS des deux domaines : A, AAAA, CNAME, MX, TXT, CAA, SRV et sous-domaines. Relever les serveurs autoritaires, TTL, DNSSEC et les cibles de domaines personnalisés Heroku.
3. Recenser les règles hors DNS : redirections OVH, proxy Cloudflare éventuel, Access, cache, WAF, certificats, tunnels, tokens et destinations de sauvegarde. Un export DNS seul ne les contient pas.
4. Vérifier les e-mails : adresses utilisées, MX, SPF, DKIM, DMARC et prestataire d’envoi. Pour [email protected], conserver le service OVH et recopier ses enregistrements exacts dans les nouvelles zones DNS. Tester réception et envoi avant et après la délégation. Conserver ces éléments tant que leur remplacement n’est pas validé ; ils sont indépendants de la base du site Heroku.
5. Relever les applications et volumes Harmony, images sha-…, versions, tâches périodiques, paramètres PocketBase, rétention des sauvegardes et taille des médias.
6. Créer un mapping des URL publiques Heroku à partir du site accessible et, si disponibles, de Search Console et des anciens sitemaps. Recenser aussi les URL du .fr, documents, images liées depuis l’extérieur et principales pages recevant du trafic.

Le dossier contient : export DNS, mapping CSV ancienne_url,nouvelle_url,statut, manifeste des images/volumes, références de secrets dans le coffre, critères d’acceptation et contacts des opérateurs. Il ne contient ni clé API, ni mot de passe, ni URL privée de calendrier.

Validation : chaque accès a été testé ; les e-mails et les URL importantes sont identifiés. Ne pas lancer la bascule avec une dépendance critique sans propriétaire.

Phase 2 — Créer les comptes et préparer le VPS

1. Créer les comptes sous une identité appartenant à l’exploitant, avec facturation et récupération indépendantes d’un seul prestataire. Garder les anciens accès jusqu’à la fin de la migration.
2. Installer Ubuntu 24.04 LTS et une version Dokploy compatible avec les scripts du projet. Les procédures de sauvegarde exigent Dokploy 0.29.13 ou plus récent ; valider l’API de la version choisie.
3. Préparer SSH par clés, mises à jour, horloge, pare-feu, supervision et stockage. Seuls les services prévus sont exposés ; ne pas publier les ports internes web/backend ou SQLite.
4. Configurer le panneau Dokploy en HTTPS et son accès opérateur. Vérifier l’accès de secours avant de fermer son accès initial par IP/port.
5. Créer des applications, réseaux et volumes distincts pour production, staging et previews. Appliquer des limites de ressources à la recette ; limiter les builds et previews simultanés.
6. Préparer des certificats d’origine valides pour les hôtes cibles avant l’ouverture. Un certificat ACME public facilite aussi la recette directe et le retour arrière.

Validation : redémarrage du VPS testé, accès opérateur conservé, HTTPS et espace disque vérifiés. Ne pas exposer une copie de données réelles sur un domaine temporaire accessible anonymement.

Phase 3 — Préparer les nouveaux services et secrets

Cloudflare et sauvegardes R2

Créer les zones .com et .fr dans le nouveau compte, sans basculer leurs serveurs DNS immédiatement. Importer les enregistrements à partir de l’export réel ; vérifier chaque cible, surtout celles de Heroku et de la messagerie. Préparer Access pour les seuls hôtes et chemins privés.

Si R2 est utilisé, créer une destination de sauvegarde dans le nouveau compte, avec des credentials limités aux buckets utiles. Configurer Dokploy, effectuer un backup et une restauration de test. Pour conserver l’historique, copier les archives nécessaires puis vérifier inventaire, tailles et sommes de contrôle ; un ETag multipart n’est pas automatiquement un hash du fichier. Conserver les anciennes archives selon la rétention convenue, sans déplacer ou supprimer la seule copie.

Les applications Access, leurs audiences, tokens de service et identifiants de zone/bucket doivent être recréés ou adaptés. Une configuration de l’ancien compte ne garantit pas l’accès dans le nouveau.

OpenAI API

Créer l’organisation et la facturation cibles, puis deux projets, par exemple harmony-production et harmony-staging. Utiliser un compte de service et une clé distincte par environnement, avec les autorisations nécessaires à l’API Responses utilisée par l’adaptateur.

Configurer les modèles autorisés, quotas et alertes de consommation. Distinguer les alertes de budget des limites bloquantes : si une limite ferme est souhaitée, vérifier qu’un hard spend limit est effectivement configuré et tester la gestion d’un refus de quota. Ne pas supposer que crédits, permissions ou historique de l’ancien compte suivent automatiquement le nouveau.

Injecter HARMONY_OPENAI_API_KEY côté backend, ainsi que HARMONY_AI_PROVIDER, les profils de modèles et HARMONY_AI_TRANSLATION_MODEL. Conserver les limites applicatives de temps et de taille. Tester une petite génération et une traduction sur des contenus fictifs, puis contrôler ai_runs et la consommation du nouveau projet. L’IA peut rester explicitement désactivée si elle n’est pas prête ; cette décision doit être visible dans la recette.

Références : gestion des projets OpenAI et limites de dépenses.

SMTP, MapTiler et autres dépendances

L’hébergement de la boîte [email protected] reste chez OVH. Le choix du relais pour les e-mails transactionnels de Harmony est distinct : vérifier s’il utilise le SMTP OVH ou un autre prestataire, ses credentials et ses quotas, sans déduire ce choix du seul hébergement de la boîte. Aucun serveur de messagerie n’est à installer sur le nouveau VPS pour cette migration.

• SMTP : conserver ou recréer le relais et l’identité d’envoi ; injecter les variables HARMONY_SMTP_HOST, HARMONY_SMTP_PORT, HARMONY_SMTP_USER, HARMONY_SMTP_PASSWORD. Vérifier les sorties réseau vers le relais et les domaines SPF/DKIM/DMARC. La migration du VPS ne doit pas modifier les MX si la réception des e-mails reste chez le même prestataire.
• PocketBase : vérifier configs/email pour l’expéditeur et les destinataires métier, et configs/site pour l’identité et les liens. Les credentials SMTP viennent des variables serveur dans l’implémentation actuelle, même si d’anciens guides mentionnent des champs SMTP en base.
• MapTiler : autoriser les nouveaux domaines sur la clé existante ou créer une clé du compte cible, puis configurer PUBLIC_MAPTILER_KEY. Vérifier carte publique et carte du back-office.
• Calendriers : conserver les URL et leur clé de chiffrement si la base Harmony est restaurée. Valider imports et exports avec un calendrier de test ; modifier les abonnements externes utilisant un ancien hostname seulement après validation de leurs nouveaux liens.
• Google Fonts et images Unsplash : vérifier les chargements sur le nouveau domaine ; aucune migration de compte API n’est nécessaire pour les ressources actuellement appelées directement.

Validation : un e-mail arrive chez un destinataire de test, les cartes chargent et la génération fonctionne avec le nouveau compte ou est désactivée de façon explicite.

Phase 4 — Déployer et restaurer la recette

Déployer une paire d’images web/backend validée, avec SHAs enregistrés. Éviter d’associer le changement de serveur à une mise à niveau improvisée de PocketBase ou à des migrations non testées. Storybook et la documentation utilisent leurs builds statiques dédiés.

Utiliser un hôte de recette déjà actif ou une protection réseau indépendante (VPN/accès limité). Ne pas dépendre uniquement d’Access sur une zone Cloudflare encore Pending pour protéger une copie.

Pour la base Harmony à conserver : produire une sauvegarde cohérente de tout /app/pb_data, incluant base et fichiers, et la restaurer sur un volume isolé. Une copie manuelle du répertoire exige l’arrêt de PocketBase ; ne pas copier une SQLite active comme si c’était un simple fichier. Conserver aussi les secrets de chiffrement dans le coffre et l’image compatible avec la sauvegarde. Référence : production et sauvegardes PocketBase.

Une restauration de répétition contenant des données réelles reste privée et ne doit pas exécuter d’envois e-mail, de synchronisations ou d’autres jobs ayant des effets réels. Le code démarre des tâches périodiques : vérifier leur neutralisation avant de démarrer cette copie. Si les interrupteurs nécessaires n’existent pas, préparer cette capacité avant la répétition ; ne pas supposer que désactiver l’IA neutralise les autres jobs.

Ne pas lancer les fixtures de démonstration sur la production restaurée. HARMONY_SEED_ON_EMPTY concerne le staging ; une base de production vide doit être identifiée et préparée volontairement, pas confondue avec un volume mal monté.

Variables qui doivent rester stables ou être remplacées

Élément	Traitement
HARMONY_TOTP_ENCRYPTION_KEY	Conserver exactement la clé qui chiffre les secrets à migrer
HARMONY_CALENDAR_ENCRYPTION_KEY	Conserver exactement la clé des URL chiffrées à migrer
Secrets PocketBase utilisés comme fallback	Conserver la base/settings ; ne pas générer un nouveau fallback sans migration
Clé de chiffrement des settings PocketBase, si utilisée	Conserver sa valeur et les arguments de lancement correspondants
Clés OpenAI, R2, Cloudflare et Dokploy	Créer les nouvelles clés du compte cible et valider leurs permissions
Token de notification de release	Garder la même valeur entre backend et secret GitHub consommateur, ou effectuer une rotation coordonnée
API_BASE_URL	Nouvelle adresse backend privée joignable depuis le conteneur web
HARMONY_PUBLIC_SITE_URL	https://www.leclosdeseucalyptus.com pour les liens e-mail de production

Si le web utilise API_TOKEN pour des lectures système, vérifier ses droits dans la base restaurée et préparer sa rotation ; ne pas partager un token de production avec staging.

Les secrets TOTP et calendriers existants deviennent illisibles si leur clé change sans rechiffrement. Les cookies d’un ancien domaine ne sont pas transférés au nouveau : prévoir une reconnexion des utilisateurs, tout en conservant leurs moyens TOTP si la base est restaurée.

GitHub et livraison

Recréer les applications Dokploy produit de nouveaux identifiants. Mettre à jour les environnements GitHub concernés après le test manuel de la cible, en suspendant les déploiements automatiques pendant le changement : DOKPLOY_URL, IDs des applications et des backups, health URLs et WEB_URL. Recréer le token Dokploy et valider les droits de lecture GHCR.

Pour la production, contrôler aussi DOKPLOY_BACKEND_APPLICATION_ID, DOKPLOY_WEB_APPLICATION_ID, DOKPLOY_BACKEND_VOLUME_BACKUP_ID, BACKEND_HEALTH_URL, WEB_HEALTH_URL et BACKEND_RELEASE_NOTIFICATION_URL. Suivre la livraison officielle avec des images immuables et la version appropriée ; ne pas utiliser latest pour cette migration.

Le workflow officiel vérifie la politique déclarée dans la variable SEO_INDEXING_ENABLED de l’environnement GitHub de production (false par défaut). La maintenir alignée avec la variable du même nom dans Dokploy : pendant la préparation privée, les deux restent à false et la réponse doit contenir noindex. Lors de l’ouverture publique, passer les deux à true et appliquer aussi l’origine et les hôtes autorisés décrits en phase 8. Le contrôle échoue si la réponse ne correspond pas à la politique déclarée ; un déploiement préparatoire en noindex est donc pris en charge.

Ne pas protéger indistinctement tout le hostname backend par Access : le BFF, les health checks et la notification de release doivent encore pouvoir l’atteindre avec les moyens d’authentification prévus. Protéger séparément la console PocketBase et tester les appels de CI depuis l’extérieur.

Validation : restauration, login/TOTP, contenus, médias, formulaires, devis PDF, notifications SSE, imports et calendriers testés ; aucun envoi réel involontaire depuis la copie de répétition.

Phase 5 — Préparer Google, les URL et les redirections

Créer ou reprendre, avec le compte Google de l’exploitant, les propriétés Domain de Search Console pour .com et .fr. Ajouter les TXT de validation chez le fournisseur DNS actuellement autoritaire pour valider les propriétés avant la délégation, puis les recopier dans les nouvelles zones Cloudflare. Conserver les validations existantes utiles. Si une propriété est déjà détenue, ajouter le nouvel utilisateur/propriétaire avant de retirer l’ancien accès.

Référence : validation de propriété Search Console.

Le domaine principal reste .com : un changement d’hébergeur seul ne nécessite pas l’outil « Changement d’adresse ». Si un domaine ou sous-domaine indexé est réellement abandonné au profit d’un autre, vérifier le cas et les prérequis de cet outil avant utilisation. Ne pas l’utiliser pour une simple normalisation avec/sans www. Pour un véritable transfert du .fr indexé vers le .com, valider les propriétés source/cible et les variantes concernées, puis effectuer la demande après la mise en place des redirections, si le cas est éligible. Voir changement d’hébergement et migration d’URL, ainsi que les conditions de l’outil Changement d’adresse.

Travaux SEO à terminer avant l’ouverture

• Préparer le mapping des anciennes pages Heroku vers leurs équivalents publiés dans Harmony. Rediriger directement vers la destination finale ; une page supprimée sans équivalent peut répondre 404/410 plutôt que d’envoyer tous les anciens liens vers l’accueil.
• Les routes /robots.txt, /sitemap.xml et les liens hreflang sont livrés : #219, résolu par la PR #247, fusionnée dans develop le 13 octobre 2026. Ils utilisent les seules traductions publiques complètes certifiées par le backend. Vérifier leur réponse sur l’image réellement déployée et les contenus définitifs ; une fusion GitHub ne prouve ni le déploiement ni l’ouverture de l’indexation.
• Les métadonnées #216, les pages éditoriales #217, la politique d’indexation #212 et les données structurées #223 sont également livrées dans le code. Le mapping des redirections #214 et la recette de lancement #224 restent ouverts au 20 octobre 2026. Les terminer avant l’ouverture, en coordination avec le lot SEO #211.
• Vérifier titres, descriptions, canonical, liens internes, versions linguistiques/hreflang, données structurées pertinentes, favicon, coordonnées et textes légaux sur les pages finales.
• Ne pas inclure login, back-office, API, staging, previews ou liens privés dans le sitemap. robots.txt ne constitue pas un contrôle d’accès ; préserver authentification et noindex.
• La propriété Search Console doit pouvoir inspecter le site public sans login Access ou challenge bloquant Googlebot. Contrôler aussi les ressources nécessaires au rendu.

Le sitemap généré par Astro pour le portail documentaire ne remplace pas celui du site public.

Si une fiche Google Business Profile existe pour la résidence, conserver cette fiche et ses avis, vérifier sa propriété, puis mettre à jour son lien web et ses informations cohérentes avec le site. Google Analytics 4 est facultatif et distinct du SEO : aucune intégration GA4 active n’a été identifiée dans le code. Si elle est souhaitée, préparer le suivi et le dispositif de consentement adapté dans un travail séparé avant activation.

Validation : propriétés Google accessibles, URLs importantes mappées et livrables SEO testés.

Phase 6 — Déléguer les DNS au nouveau compte Cloudflare

La délégation se fait chez OVH pour chacun des deux domaines. Elle ne déplace pas encore le trafic vers le nouveau VPS : conserver à ce stade les cibles Heroku et les enregistrements mail.

1. Identifier les DNS actuels : si OVH les gère, il s’agit d’un premier ajout à Cloudflare ; si un ancien compte Cloudflare les gère, suivre sa procédure de changement de compte. Dans ce second cas, traiter aussi les prérequis relatifs aux abonnements/add-ons et préparer la continuité des certificats ; ne pas supposer que les options payantes sont transférées.
2. Vérifier DNSSEC. Avant un changement de fournisseur/compte, traiter le DS existant chez le registrar et attendre la disparition de l’ancienne chaîne de confiance. Un DS obsolète peut empêcher la résolution. Préparer la réactivation avec le nouveau compte après validation.
3. Importer/vérifier les deux zones, leurs cibles d’origine réelles et les règles nécessaires. Ne pas reprendre les IP de proxy Cloudflare comme adresses de l’hébergement.
4. Remplacer les NS chez OVH par ceux attribués au nouveau compte, domaine par domaine. Vérifier l’état Active et la résolution depuis plusieurs réseaux avant de poursuivre.
5. Vérifier certificats et accès. Une zone Pending peut répondre avec les IP d’origine ; sa protection ne doit pas reposer uniquement sur Access. Les certificats et réglages de l’ancien compte ne sont pas automatiquement transférés.
6. Réactiver DNSSEC de façon coordonnée et vérifier le nouveau DS. Ne pas supprimer prématurément la zone OVH ou les exports permettant de reconstruire les anciens enregistrements.

Référence : migration entre comptes Cloudflare. Le cas Cloudflare Registrar ne s’applique pas à l’enregistrement actuel chez OVH. La baisse du TTL des enregistrements A/CNAME aide une future bascule d’origine ; elle ne supprime pas les délais de cache de la délégation NS. Pour les enregistrements proxifiés, tenir compte du TTL géré par Cloudflare.

Validation : le site Heroku et les e-mails fonctionnent encore avec les nouveaux DNS, et les services de recette sont protégés. Ce point est une étape indépendante de la bascule VPS.

Phase 7 — Préparer la production définitive

1. Terminer la recette sur le VPS avec des hôtes temporaires protégés, noindex, et les secrets du bon environnement. Une origine SvelteKit fixe doit correspondre au hostname effectivement utilisé pendant cette recette ; une mauvaise configuration peut casser les POST CSRF.
2. Préparer le routage HTTPS pour www, l’apex .com, les deux variantes .fr et les hôtes techniques. Utiliser Cloudflare SSL/TLS Full (strict) avec un certificat d’origine valide ; vérifier les certificats edge et origine avant de dépendre du proxy. Éviter le mode Flexible.
3. Pour la copie finale d’une base Harmony existante, geler ses écritures et arrêter le backend source, tâches périodiques comprises. Sauvegarder le volume complet, vérifier l’archive, transférer par un canal protégé, restaurer et comparer les contenus/comptages attendus.
4. Vérifier montage, propriétaire et permissions du volume. Démarrer le backend cible une seule fois comme écrivain effectif ; garder l’ancien backend arrêté. Prévoir une copie initiale de répétition pour estimer le temps nécessaire, sans promettre une synchronisation SQLite à chaud.
5. Si une nouvelle base de production a été choisie, valider ses contenus, médias, comptes et configurations ; ne pas importer la base Heroku ni publier les fixtures de démonstration.
6. Configurer les variables web finales et vérifier le proxy, les IP clients utilisées pour les limites de tentative, l’absence de buffering SSE et les limites d’upload de chaque couche.

Revoir les règles de cache héritées : ne pas mettre en cache les POST, login, back-office, API ou réponses personnalisées. À la bascule, purger les caches publics susceptibles de conserver l’ancien HTML ou un header noindex, puis refaire les contrôles anonymes.

# Origine canonique de la production ; à activer selon l’étape de mise en ligne.
SEO_PUBLIC_ORIGIN=https://www.leclosdeseucalyptus.com
SEO_INDEXING_ENABLED=false
SEO_INDEXING_ALLOWED_HOSTS=
# Pour un serveur adapter-node dédié à cette origine publique.
ORIGIN=https://www.leclosdeseucalyptus.com

Staging et previews conservent false et une liste vide. Le portail Astro utilise ses propres PUBLIC_DOCUMENTATION_URL et PUBLIC_STORYBOOK_URL, définis au build. Mettre à jour aussi les liens d’e-mails, callbacks et consommateurs de calendriers contenant les anciennes adresses.

Validation : login et soumission de formulaire fonctionnent avec les headers du proxy réel, le certificat final est valide, les données attendues sont présentes et les backups cibles restaurables.

Phase 8 — Basculer les domaines et ouvrir le site

Avant le créneau, enregistrer les anciennes cibles Heroku, la nouvelle IP, les SHAs, l’heure et les sauvegardes. Si les anciens formulaires risquent de recevoir des demandes pendant la transition, prévoir leur mise en maintenance et un contact alternatif ; ne pas perdre des demandes récentes sous prétexte que l’historique Heroku n’est pas importé.

1. Réunir l’opérateur et le validateur, confirmer les critères GO ci-dessous et suspendre les livraisons concurrentes. Vérifier une dernière fois le backup et les e-mails de test.
2. Modifier dans le nouveau compte Cloudflare les A/AAAA ou CNAME des hôtes concernés pour pointer vers le VPS et son routage. Retirer un AAAA obsolète si le nouveau chemin IPv6 n’est pas opérationnel. Ne pas modifier MX/SPF/DKIM/DMARC pour une simple migration web.
3. Activer les redirections de l’apex .com, du .fr et de www.fr vers https://www.leclosdeseucalyptus.com. Utiliser un statut permanent 301 ou 308 pour les redirections de lancement validées. Combiner le mapping d’anciennes URL avec la conservation du chemin et de la query string ; éviter les boucles et chaînes. Le certificat doit aussi être valide sur les hôtes qui redirigent.
4. Tester anonymement le domaine final. Une redirection canonique doit être appliquée avant de présenter un formulaire afin qu’il soit ouvert et soumis sur sa bonne origine.
5. Retirer la protection de préparation du site public seulement après validation. Conserver Access sur staging, previews et administration ; garder l’authentification du back-office.
6. Activer l’indexation publique et redéployer le conteneur web avec la configuration finale.

SEO_PUBLIC_ORIGIN=https://www.leclosdeseucalyptus.com
SEO_INDEXING_ENABLED=true
SEO_INDEXING_ALLOWED_HOSTS=www.leclosdeseucalyptus.com
ORIGIN=https://www.leclosdeseucalyptus.com

Pour les redirections Cloudflare, utiliser une règle de hostname précise, une destination HTTPS canonique et la conservation des paramètres. Les pages qui ont changé de chemin nécessitent leur mapping explicite. Référence : exemples de redirections.

Recette immédiate

Le mode TLS est décrit dans la documentation Full (strict).

Contrôle	Résultat attendu
DNS .com et .fr, avec/sans www	Cibles voulues, pas d’ancien IPv6 ou de boucle
TLS edge et origine	Certificats valides et routage conforme
/healthz et /api/hello	Révisions web/backend attendues ; ne pas se contenter d’un 200
Anciennes URL importantes	Destination équivalente, ou 404/410 décidé
Pages publiques dans les langues disponibles	Contenus et images corrects, liens vers le domaine canonique
Login, TOTP, récupération de mot de passe	Actions exécutées, e-mails reçus, aucune erreur CSRF
Contact, réservation, devis PDF	Une demande conservée et une livraison testée, sans doublon
Notifications SSE et uploads	Flux utilisables derrière Cloudflare/Traefik
Calendriers et cartes	Déchiffrement/synchronisation et ressources externes fonctionnels
SEO production	Indexable, canonical correct, robots et sitemap validés
SEO staging/previews	Toujours protégés et noindex
Messagerie des deux domaines	Réception et émission inchangées si prestataire conservé

Le test d’e-mail doit utiliser un destinataire autorisé et le test de réservation des données identifiées comme test. Consigner les identifiants pour éviter leur traitement comme de vraies demandes.

Phase 9 — Activer le suivi Google et stabiliser

1. Soumettre dans Search Console le sitemap final effectivement disponible. Inspecter l’accueil, les pages appartements et les anciennes URL redirigées avec l’outil de test en direct.
2. Contrôler canonical retenu, indexabilité, rendu mobile et ressources bloquées. Prévoir un suivi d’indexation sur plusieurs semaines ; l’indexation immédiate n’est pas garantie.
3. Mettre à jour la fiche Google Business Profile existante et les liens d’annuaires ou de partenaires.
4. Surveiller à T+15 min, T+1 h, T+24 h, puis quotidiennement la première semaine : 5xx, 404, RAM/disque, redémarrages, jobs, e-mails, backups et consommation des nouveaux comptes.
5. Réactiver les livraisons automatiques seulement lorsque toutes leurs cibles et tokens pointent vers la nouvelle infrastructure. Déclencher une livraison contrôlée et vérifier les révisions.
6. Conserver l’application Heroku, ses domaines personnalisés et certificats pendant la fenêtre de retour arrière convenue, par exemple 7–14 jours, avec son coût temporaire enregistré. Conserver plus longtemps les redirections des URL historiques pertinentes.

Les anciens hôtes techniques Harmony, notamment sous px-playground.fr, ne doivent pas devenir des copies publiques indexables du nouveau site. Les maintenir en recette protégée/non indexable ou les retirer selon le périmètre réellement abandonné, sans redirection aveugle des routes privées.

Depuis web/, les commandes suivantes effectuent des lectures. Remplacer le SHA attendu par celui de l’image approuvée ; les secrets Access éventuellement nécessaires restent dans l’environnement de l’opérateur, jamais dans une commande publiée.

npm run check:indexing -- https://preview.leclosdeseucalyptus.com noindex
npm run check:indexing -- https://www.leclosdeseucalyptus.com index "$WEB_REVISION_ATTENDUE"
curl --fail --silent --show-error https://www.leclosdeseucalyptus.com/healthz
curl --silent --show-error -I https://leclosdeseucalyptus.com/
curl --silent --show-error -I https://www.leclosdeseucalyptus.fr/
dig NS leclosdeseucalyptus.com
dig NS leclosdeseucalyptus.fr
dig MX leclosdeseucalyptus.com

check:indexing valide une sélection de pages en cinq langues et la révision ; il ne remplace pas la validation du sitemap, des redirections, des formulaires ou des e-mails.

Retour arrière

Déclencher une décision de rollback si l’accès public, TLS, les données attendues ou les parcours critiques échouent sans correction courte et identifiée. Pour des erreurs d’IA seules, désactiver l’IA peut être une mesure de maintien du service plutôt qu’un retour complet sur Heroku.

Retour du site public vers Heroku

Rétablir dans les zones Cloudflare actives les anciennes cibles Heroku et les règles compatibles avec l’ancien site. Conserver ses domaines personnalisés et certificats est un prérequis. Ne pas changer simultanément les NS pour tenter un retour instantané : leurs caches sont indépendants. La restauration DNS peut prendre du temps selon les caches ; prévoir une maintenance si nécessaire.

Les redirections permanentes peuvent aussi être mises en cache par les navigateurs. Vérifier que les URL finales déjà publiées restent traitables lors du retour vers Heroku ; si l’ancien site ne connaît pas leurs nouveaux chemins, préparer un routage compatible ou une maintenance ciblée. Un retour DNS seul ne garantit pas le fonctionnement de ces liens.

Les demandes déjà reçues dans Harmony après ouverture restent dans sa base. Les sauvegarder et prévoir leur traitement via un accès privé ; elles ne sont pas automatiquement transférées à Heroku. Ne pas écraser la nouvelle base avec une sauvegarde ancienne pour restaurer uniquement le site public.

Retour d’un backend Harmony vers un ancien VPS

Si le nouveau backend a déjà accepté des écritures, geler ces écritures et sauvegarder son état cohérent avant de décider d’un transfert inverse ou d’une réparation. Vérifier la compatibilité de l’image avec le schéma. Garder un seul backend écrivain pendant toute la procédure. Un simple retour à la copie d’avant migration peut perdre contacts, réservations et modifications.

Retour des comptes fournisseurs

Conserver les anciens secrets fonctionnels dans le coffre pendant la fenêtre de retour convenue, sans les exposer ni les employer dans les nouveaux environnements par erreur. Un rollback OpenAI est un changement coordonné de clé/configuration, ou une désactivation de l’IA. Un rollback R2 rétablit une destination testée, sans supprimer les backups créés dans le nouveau compte. Une ancienne zone Cloudflare peut passer en état Moved Away puis être supprimée : le dossier de migration et les exports doivent permettre une reconstruction, sans dépendre de son maintien éternel.

Critères GO / NO-GO et clôture

• GO seulement si les accès de secours, les enregistrements mail, les certificats, le routage, les données attendues, les clés de chiffrement et la restauration sont validés.
• GO seulement si les pages/URLs importantes, les formulaires et la politique d’indexation sont testés ; l’état des livrables SEO encore à développer est explicite.
• NO-GO si une copie de production peut envoyer des e-mails ou exécuter des jobs réels pendant la répétition, si deux backends peuvent écrire indépendamment, ou si les données de retour ne sont pas identifiées.
• Avant clôture : première sauvegarde de production sur le nouveau compte restaurée en isolation, période d’observation terminée et demandes de test identifiées/traitées.
• Ensuite seulement : retirer les applications et accès obsolètes, révoquer les anciennes clés, puis arrêter la facturation Heroku et de l’ancien VPS selon les ressources réellement abandonnées. Garder OVH comme registrar des deux domaines et ne pas supprimer les services mail conservés.

Le compte rendu final consigne dates, changements DNS, révisions, preuves de recette, backups, opérateur et décision de clôture, sans valeurs secrètes.