alwaysdata ou PlanetHoster pour vérifier le transfert d’un thème WordPress

Quand le thème reçu a la bonne taille et le mauvais contenu

Vous avez validé une nouvelle version du thème enfant sur un environnement de recette. Vous envoyez ensuite les fichiers modifiés vers le site qui doit prendre le relais. Le client de transfert termine sans erreur. Pourtant, sur la page de recette, l’équipe voit encore l’ancienne couleur d’un bouton. Avant de vider les caches ou de modifier les réglages du thème, téléchargez le fichier `style.css` de la cible et comparez son empreinte avec celle du fichier qui a été validé. Si les deux empreintes diffèrent, vous avez une divergence sur disque à corriger avant de reprendre les contrôles côté navigateur.

Une modification de `#123456` en `#654321` conserve la longueur du fichier. Si la date de modification est elle aussi identique, par exemple parce que deux exports conservent le même horodatage, un transfert incrémental qui compare ces deux métadonnées peut passer à côté de la différence. Le fichier est bien présent dans le bon répertoire. Une modification d’un autre fichier du thème peut même avoir été transférée dans la même opération, ce qui laisse sur la cible un mélange de versions.

Le choix entre alwaysdata et PlanetHoster porte ici sur la façon de retrouver le bon site, d’autoriser l’accès au bon dossier et de relire ce qui y a été reçu. Les deux fournisseurs documentent un accès SFTP. La preuve d’intégrité vient de votre version approuvée et de la lecture des fichiers distants. Un transfert, une prévisualisation de la page et un contrôle d’intégrité ont donc chacun un résultat à consigner séparément.

Deux périmètres commerciaux à comparer au 11 novembre 2026

Chez alwaysdata, le Cloud Public Plus Small est affiché à 5 € HT par mois en facturation annuelle, soit 60 € HT pour douze mois. En facturation mensuelle, la grille indique 6 € HT par mois, soit 72 € HT si le même tarif s’applique pendant douze mois. Elle indique aussi 50 Go pour le compte et des ressources de 1 Go de mémoire vive et 1 CPU pour Small. Le stockage du compte sert à plusieurs usages. Avant de choisir ce niveau, comptez les fichiers des sites, les bases et les courriels qui y occupent effectivement de la place, ainsi que les fichiers que vous prévoyez de garder pour la recette.

Chez PlanetHoster, The World présente au 11 novembre un tarif de lancement de 5,49 € par mois sur un cycle de 24 mois pour le pack de dix Projets Web Standard. L’équivalent sur ce cycle est de 131,76 €, calculé à partir du tarif affiché. Les conditions de PlanetHoster indiquent des prix toutes taxes comprises. Pour une commande destinée à la France, vérifiez au panier le montant TTC, l’échéancier et le prix de renouvellement. Le détail de l’offre indique 10 Go NVMe/SSD par projet Standard et présente séparément le stockage objet N0C. Pour dimensionner la recette, comptez le dossier WordPress et le thème sur le disque du projet concerné.

Les montants correspondent à des bases différentes : un compte avec une durée de facturation au choix chez alwaysdata, un pack sur deux ans au prix de lancement chez PlanetHoster. Relevez le total du premier cycle, le prix du renouvellement et le traitement fiscal dans le même panier avant de calculer un coût par site. La comparaison reste exploitable si vous n’utilisez qu’un projet du pack : notez alors le coût total que vous engagez et l’emplacement dans lequel vous vérifierez les fichiers. Les conditions PlanetHoster prévoient un renouvellement automatique par défaut et demandent de le désactiver au plus tard 30 jours avant l’échéance si vous souhaitez arrêter le service. Chez alwaysdata, consultez la version validée du contrat dans Abonnements → Contrats.

Figer la version approuvée avant de lancer la copie

Créez un dossier de livraison pour le thème enfant, sous un identifiant de version que l’équipe peut retrouver. Prenez comme racine le dossier `atelier-enfant` et enregistrez chaque chemin relatif avec son empreinte SHA-256 dans un fichier manifeste conservé à côté de l’archive approuvée. `style.css` et `assets/menu.js` doivent avoir ces mêmes chemins lorsque vous les relisez sur la cible. Si vous commencez l’inventaire à la racine de WordPress sur un serveur et à la racine du thème sur l’autre, vous obtiendrez des écarts de chemins même avec des fichiers identiques.

Le dossier approuvé peut contenir du CSS, des scripts, des modèles PHP ou des ressources compilées. Si votre procédure construit des fichiers à partir de sources, faites l’inventaire après cette construction et transférez les résultats approuvés. Pour un thème enfant, identifiez aussi le dossier du thème parent déclaré par le champ `Template` dans l’en-tête de `style.css`. Vérifiez que le parent requis est présent sur la cible et que la version du thème parent y a été validée. Placez ce contrôle à côté du manifeste : le thème parent a son propre périmètre.

Pour un transfert limité au thème, repérez les fichiers WordPress qui restent sous la responsabilité de l’environnement de destination. `wp-config.php`, les extensions, les téléversements et la base de données ont chacun leur cycle de mise en production. Gardez une copie de la version du thème qui fonctionne déjà sur la cible et associez-lui un manifeste distinct. Si vous devez revenir en arrière, vous pourrez vérifier les fichiers restaurés avec le même procédé, y compris les fichiers que la nouvelle version aurait ajoutés.

• Identifier le dossier du thème actif et la version attendue du thème parent.
• Conserver ensemble l’archive approuvée et son manifeste de chemins relatifs.
• Capturer la version du thème qui fonctionne sur la cible avant toute écriture.

Chez alwaysdata, relier le compte SFTP au dossier du site

Dans l’administration alwaysdata, ouvrez d’abord la configuration du site de recette et relevez le répertoire vers lequel il pointe. Dans Accès distant → SSH/SFTP, récupérez l’identifiant autorisé et l’empreinte de la clé du serveur. La documentation indique un hôte de la forme `ssh-[compte].alwaysdata.net` et le port 22. Une fois connecté, remontez du dossier `wp-content/themes` jusqu’à la racine relevée dans l’administration pour vérifier que vous êtes dans le site voulu. Plusieurs sites d’un compte peuvent contenir un thème portant le même nom.

En SSH, la documentation indique que les utilisateurs peuvent accéder à l’ensemble du compte même si leur répertoire de départ est plus bas. L’option de shell SFTP uniquement impose un cloisonnement documenté. Contrôlez avec l’identifiant prévu quels dossiers sont effectivement visibles. Pour une intervention limitée à la recette, la lecture du thème doit être possible avec ce même accès. Si vous disposez uniquement de SFTP, téléchargez le dossier reçu vers un répertoire local vide et calculez les empreintes sur cette copie.

Si plusieurs sites alwaysdata partagent la même livraison, faites un relevé par site et par chemin de thème. Une validation sur le premier site ne décrit pas l’état du second. Conservez une ligne avec l’identifiant du compte, la racine vérifiée, la version approuvée et le résultat. Les autres chemins visibles dans la session SFTP restent en dehors de l’opération.

Chez PlanetHoster, identifier le projet avant le dossier du thème

Dans l’Espace Client PlanetHoster, ouvrez les détails du Projet Web de recette. La rubrique d’accès SFTP/SSH affiche le nom du serveur, l’identifiant et le port. La documentation donne le port 5022 pour The World sur N0C. Faites correspondre le domaine de recette, le projet sélectionné et le chemin de l’installation WordPress. Si plusieurs projets réutilisent le même thème enfant, la seule présence de `atelier-enfant` ne confirme pas le projet. Relevez ces trois informations ensemble pour que la personne qui relira l’opération puisse retrouver le même dossier.

L’intérêt du pack pour une équipe qui gère plusieurs sites tient au découpage en Projets Web. On peut rattacher le résultat d’un transfert à un projet précis et retrouver les informations de connexion dans sa fiche. En contrepartie, le relevé doit être refait pour chaque projet où le thème est déployé. Un rapport portant sur une URL de recette ne suffit pas à signer l’ensemble du pack, même si tous les projets démarrent depuis la même archive.

Dans les deux interfaces, le panneau sert à trouver l’accès et le bon dossier. Si votre équipe dispose d’une session SSH et d’outils de hachage, elle peut produire un inventaire directement dans ce dossier. La disponibilité de `rsync` et de `sha256sum` dépend de la session utilisée. Vérifiez les commandes avant de les mettre dans la procédure. Avec un accès SFTP seul, la relecture dans un dossier local neuf permet d’effectuer le même rapprochement sur les octets téléchargés.

Distinguer la sélection avant transfert et la preuve après transfert

Si vous utilisez rsync, son manuel indique que la sélection rapide habituelle repose sur la taille et la date de modification. L’option `--checksum` lui demande de comparer des sommes de contrôle avant de choisir les fichiers à transférer. Une simulation avec `--dry-run --itemize-changes --checksum` rend ce choix visible avant toute écriture. Prévoyez du temps pour la lecture des fichiers de part et d’autre si le dossier est volumineux. Limitez le contrôle au dossier du thème et renseignez explicitement le sens du transfert.

Avec un client SFTP, vérifiez le mode utilisé lors de la synchronisation ou lorsqu’un fichier du même nom existe. Si le mode choisi saute les fichiers de mêmes taille et date, remplacez explicitement les chemins signalés par le manifeste. Reprenez ensuite l’inventaire du dossier distant. Un téléchargement dans un dossier local qui contenait déjà des fichiers peut réintroduire un filtre ou masquer une suppression. Commencez donc la relecture dans un nouveau dossier, puis calculez un inventaire récursif qui inclut les fichiers cachés s’ils font partie de la version approuvée.

Le manifeste de publication permet une autre vérification : le contenu relu sur la cible correspond-il toujours à la version approuvée ? Si vous le régénérez après un changement sur la source, la comparaison risque d’approuver une version que l’équipe n’a jamais signée. Conservez le premier manifeste avec la livraison. Comparez le dossier d’envoi à ce manifeste avant le transfert, puis la cible après la dernière écriture. Si la préparation du déploiement produit des fichiers variables sur place, définissez le moment où le thème devient vérifiable et faites approuver le périmètre avant de relancer la copie.

• Sous PowerShell, depuis chacun des deux dossiers du thème, lancer `Get-FileHash -LiteralPath ./style.css -Algorithm SHA256`. Comparer la colonne `Hash`. Pour signer la livraison, appliquer le contrôle à chaque chemin du manifeste.

Traiter chaque écart et vérifier le retour arrière

Classez les écarts par chemin : fichier manquant, empreinte différente ou fichier supplémentaire. Un fichier manquant se reprend depuis l’archive approuvée. Pour une empreinte différente, comparez d’abord le fichier d’envoi à l’archive, puis remplacez le fichier concerné sur la cible. Pour un chemin supplémentaire, vérifiez s’il reste référencé par le thème ou s’il relève d’une génération locale. Dans ce dernier cas, déterminez si son emplacement doit changer ou si sa présence fait partie d’un périmètre approuvé et documenté. Quand le fichier est confirmé obsolète, sauvegardez-le hors de l’arborescence servie avant de le retirer et refaites l’inventaire.

Prévoyez que des requêtes puissent arriver pendant que des fichiers sont remplacés. Sur une recette privée, vous pouvez vérifier la version finale après l’opération. Pour la mise en ligne, utilisez la procédure validée par votre équipe, par exemple une fenêtre de maintenance ou un changement de dossier déjà testé lorsque l’environnement le permet. Prenez en compte les droits et le chemin lu par WordPress. Si une copie s’interrompt après le premier fichier, reprenez à partir du manifeste figé et relisez tout le thème. Le journal de transfert indique ce que le client a tenté, tandis que l’inventaire donne l’état obtenu.

Si vous choisissez de revenir en arrière, restaurez la version sauvegardée avec son propre manifeste. Vérifiez notamment qu’un fichier ajouté lors de la nouvelle version a disparu du périmètre restauré. Ouvrez ensuite une page qui utilise le thème, puis contrôlez les fonctionnalités qui ont motivé le changement. Pour un CSS, vérifiez aussi la réponse réseau réellement consommée par le navigateur. Si le fichier sur disque est correct mais que l’ancienne couleur reste affichée, regardez l’URL de la feuille chargée, sa version et les couches de cache avant de reprendre une copie.

• Comparer la cible au manifeste et consigner chaque chemin en écart.
• Corriger les fichiers depuis la version approuvée et consigner la décision sur les fichiers supplémentaires.
• Rejouer la vérification sur l’ensemble du thème et contrôler une page représentative.

Ce que montre la recette locale rejouée le 11 novembre

L’exercice joint crée deux arborescences WordPress fictives et effectue des copies réelles de fichiers avec Python. Les deux versions de `style.css` ont la même taille et le même horodatage. Au premier passage, `assets/aide.css`, absent de la cible, est ajouté et `assets/menu.js`, dont la taille a changé, est mis à jour. Le filtre laisse `style.css` en place. La comparaison SHA-256 signale ce fichier comme différent et repère aussi `obsolete.css`, qui appartient à la version précédente.

Le script force ensuite la copie de `style.css`. Il relit l’arborescence et constate que le fichier supplémentaire subsiste. Après avoir mis de côté ce fichier précis, la cible correspond au manifeste. Le script altère alors la source en conservant les mêmes métadonnées. La cible reste conforme à la version approuvée et la source échoue au contrôle, ce qui bloque sa réutilisation pour un nouveau déploiement. Enfin, le test restaure la version précédente depuis sa copie de secours, vérifie son inventaire et compare le fichier de configuration fictif à son état initial.

Les neuf contrôles ont réussi avec Python 3.14.4 depuis l’archive extraite. Le ZIP contient le script et les instructions. Son compte rendu indique les deux empreintes différentes de `style.css` et les chemins relevés à chaque étape. Le filtre taille/date est modélisé en Python. Les opérations de copie et de relecture ont eu lieu sur le disque local. Les connexions aux deux offres reposent sur leur documentation publique.

• Extraire le ZIP et lancer `python recette.py` depuis le dossier extrait.
• Comparer `apres_transfert`, `apres_reprise_css` et `apres_mise_a_part` dans le rapport JSON.
• Vérifier les champs de dérive de la source et de retour arrière avant d’adapter l’exercice à une recette autorisée.

Choisir selon la façon dont l’équipe exploite ses sites

Choisissez le périmètre alwaysdata Plus Small si vous souhaitez gérer la recette dans un compte et que ses ressources couvrent les sites, bases et autres usages que vous y placez. Pour la procédure de réception, notez le dossier configuré pour chaque site et choisissez l’accès SFTP adapté aux personnes qui interviennent. La facturation mensuelle donne un point de départ chiffré pour une recette de durée courte. Si le compte héberge aussi des sites en production, confirmez les chemins visibles et les droits depuis l’accès prévu avant de donner les instructions de transfert.

Examinez PlanetHoster The World si votre équipe veut organiser le suivi par Projet Web. Le pack de dix Standard a un intérêt si vous avez un usage prévu pour plusieurs projets et si le disque par projet correspond à vos installations. Rapprochez le tarif de lancement de votre durée d’utilisation et faites confirmer le coût de renouvellement pour ce pack. Dans le rapport de recette, associez chaque projet à un domaine, un dossier WordPress et un résultat d’inventaire. Sur un site unique, comparez le coût du pack entier avec la configuration dont vous avez besoin.

Pour donner le feu vert à un transfert, demandez la même preuve dans les deux cas : un manifeste signé ou archivé avec la version, l’identification du dossier effectivement relu et un relevé sans fichier manquant, différent ou en trop. Ajoutez le résultat d’un contrôle de page, puis gardez l’identifiant de la version précédente vérifiée. Une autre personne peut ainsi refaire les étapes à partir du même fichier approuvé, même si le client de transfert, le panneau ou l’hébergeur change.

Pour aller plus loin

• Lire la fiche alwaysdata
• Lire la fiche PlanetHoster
• Comparer les extensions de migration WordPress
• Télécharger l’exercice de transfert du thème (ZIP)