OVHcloud ou Monarobase pour vérifier la cible d’une commande WP-CLI

Deux sites, une seule commande et un doute sur la cible

Une équipe prépare la nouvelle version du site WordPress d’une association. La copie et le site public partagent un hébergement et le même accès SSH. Les deux affichent le même nom. Avant de modifier un réglage avec WP-CLI, le technicien retrouve le dossier de la copie. Une erreur de configuration laissée par le clonage peut pourtant relier ce dossier à la base active. La commande réussira alors sur les données de production.

La recette consiste à confirmer trois éléments dans la même session. Identifiez le chemin réel de l’installation, la base utilisée par WordPress et le préfixe des tables visées. Gardez l’URL comme indice supplémentaire. Une copie récente peut encore porter les mêmes valeurs de site que la production. Pour lever le doute, confrontez les résultats à un inventaire préparé avant le test et à un témoin propre à la copie.

OVHcloud Hébergement Web Pro documente le dossier racine de chaque nom dans son panneau et l’accès SSH. Monarobase WordPress Classic annonce WP-CLI préinstallé et documente le clonage vers un sous-domaine. Dans les deux cas, l’accès aux fichiers et la base choisie par la configuration sont deux choses à vérifier. Le scénario concerne deux installations WordPress autonomes sur le même hébergement.

Comparer les offres et les conditions de coexistence

Sur la page France d’OVHcloud, Pro affiche 1,99 € HT par mois pour la première période de douze mois, soit 23,88 € HT. Le renouvellement indiqué à 9,99 € HT par mois représente 119,88 € HT pour douze mois au même tarif. La carte annonce 250 Go de stockage SSD, un vCore, 2 Go de mémoire et dix bases de 2 Go. L’accès SSH est inclus. La documentation précise que cet accès reste celui d’un utilisateur de l’hébergement mutualisé.

Chez Monarobase, la page WordPress affiche Classic à partir de 5,95 € HT pour un mois. À ce repère, douze mois représentent 71,40 € HT, sous réserve du cycle et du prix proposés. La formule annonce 50 Go de SSD NVMe, 2 Go de mémoire, un CPU, 20 Mo/s d’entrées-sorties et 1 To de transfert par mois. Elle comprend un compte cPanel avec deux sites additionnels, un environnement de test et WP-CLI préinstallé selon la carte.

Vérifiez les échéances pendant lesquelles l’équipe doit garder la copie et le site public accessibles. La page Classic ne présente pas un tarif de renouvellement distinct. Les conditions Monarobase décrivent une reconduction automatique par carte et un ticket de résiliation au moins sept jours avant le renouvellement. La FAQ générale décrit aussi un parcours sans renouvellement tacite et une reconduction sur demande. Faites confirmer le prix, la durée et la règle appliquée au mode de paiement choisi.

Pour OVHcloud, relevez dans le panneau le mode de renouvellement et les services qui lui sont liés. Le domaine et l’hébergement peuvent avoir des échéances différentes. Les prix du 11 novembre 2026 servent à comparer le coût de la coexistence. Pour la recette technique, vérifiez également la place disponible dans le forfait et dans chaque base. La limite de 2 Go par base chez OVHcloud Pro compte même lorsque la capacité de stockage web laisse de la marge.

Préparer une référence avant la session SSH

Notez le nom d’hébergement, le compte SSH, le domaine de recette et le dossier racine tel qu’il est déclaré dans le panneau. Relevez aussi le dossier qui contient effectivement WordPress. Il peut se trouver dans un sous-répertoire du dossier servi. Donnez à la copie une base séparée et, si le panneau le permet, un utilisateur qui n’a aucun droit sur la base active. Cette séparation limite les effets d’un réglage erroné et rend la recette plus facile à vérifier.

Préparez un tableau de correspondance pour la production et la copie. Inscrivez le chemin absolu, le serveur de base, le nom de la base, le préfixe des tables et les adresses attendues. Une base de même nom peut exister sur deux serveurs. Un hébergement peut aussi contenir deux jeux de tables dans une seule base. Vérifiez les deux niveaux. Conservez un témoin distinct pour chaque site, par exemple la valeur d’une option de recette sur la copie et le slogan courant sur le site actif.

Le nom de domaine et le chemin d’exécution se décident séparément. WP-CLI documente l’option globale --path pour choisir les fichiers WordPress. L’option --url simule le contexte d’une requête et sert à choisir un site dans un réseau WordPress multisite. Elle ne choisit pas à elle seule un autre dossier ni les identifiants de connexion d’une installation autonome. Le libellé Multisite d’un panneau d’hébergement peut simplement désigner plusieurs domaines rattachés au même espace.

Choisissez un témoin déjà présent dans une copie que vous avez identifiée. Si vous devez en créer un, ajoutez-le lors de la préparation de la base de recette, avant de la raccorder au site. Vous pouvez aussi relever une différence connue dans une sauvegarde importée. Consignez la valeur attendue en dehors de l’installation. Écrire un nouveau témoin dans la session dont vous cherchez à identifier la cible ferait perdre l’intérêt de ce contrôle préalable.

Lire l’installation réellement chargée par WP-CLI

Dans le terminal, placez le chemin absolu de la copie dans une variable que vous réutiliserez. La commande wp config path avec --path donne le fichier de configuration trouvé. Comparez ce résultat au dossier attendu et contrôlez le chemin physique. Un lien symbolique ou un répertoire courant conservé d’une session précédente peut conduire à une autre installation. Si WordPress a été déployé dans un sous-dossier, utilisez le chemin de ses fichiers.

Relevez ensuite les valeurs visibles avec wp option get home et wp option get siteurl, toujours avec le même --path. Ces valeurs peuvent être fixées par la configuration de WordPress et peuvent rester identiques après un clonage. Continuez le contrôle avec une commande de lecture qui affiche la base active, le préfixe et, le cas échéant, l’identifiant de site dans le réseau. Le fichier wp-config.php peut obtenir ses valeurs depuis l’environnement. Comparez donc aussi la connexion effective, pas seulement le texte du fichier.

La fiche de commandes jointe donne un exemple qui interroge la base avec SELECT DATABASE() et affiche le préfixe de la session WordPress. Vérifiez également le serveur déclaré dans la configuration effective. Un nom de base seul ne suffit pas s’il peut être réutilisé ailleurs. Si l’hébergement n’autorise pas l’interrogation, utilisez la preuve disponible dans le panneau et un témoin de lecture propre à la copie. En l’absence de preuve sur la base ou le préfixe, reportez l’écriture.

OVHcloud Pro. Relier le domaine au bon dossier

Dans l’espace client, ouvrez l’hébergement et sa liste de sites rattachés. Le guide OVHcloud demande de sélectionner un dossier racine pour chaque nom. Comparez celui du domaine public à celui de la copie. Deux noms peuvent volontairement servir les mêmes fichiers. Si vous constatez ce cas alors que les sites devaient être séparés, créez ou corrigez la copie avant de continuer. Le nom du sous-domaine seul ne garantit pas un autre dossier.

Le guide SSH indique où trouver le serveur, le port et l’utilisateur autorisé dans l’espace client. Une fois connecté, vérifiez la présence de WP-CLI dans cette session. L’offre Pro annonce SSH, tandis que la disponibilité de la commande et la version de PHP en ligne de commande doivent être vérifiées sur l’environnement utilisé. Si vous utilisez un exécutable WP-CLI déjà autorisé sur ce compte, relevez sa version et gardez la même commande pour les contrôles et l’opération prévue.

Faites correspondre la base de la copie aux bases de l’hébergement dans le panneau. Le nombre de bases proposé facilite la séparation des données. Vérifiez la place de la copie et les droits de son utilisateur avant d’y importer un site volumineux. Gardez un inventaire de la racine et de la base de production afin de repérer un croisement. Rejouez la lecture de la configuration dès que le clone ou ses variables d’environnement changent.

Monarobase Classic. Vérifier la destination du clone

Le guide Monarobase décrit le clonage depuis Installatron dans cPanel. Il demande que le site soit installé ou importé dans l’outil et que le sous-domaine de destination existe. Lorsque vous choisissez cette destination, relevez le champ Dossier. Le guide indique de le laisser vide si le clone doit occuper la racine du sous-domaine. Vérifiez après clonage la racine, la base et le préfixe effectifs, même lorsque la page de la copie s’ouvre.

La carte Classic annonce WP-CLI préinstallé. Le guide SSH décrit la connexion par clé. Vérifiez sur le compte les droits accordés et le chemin de connexion dans la session ouverte. Les sites additionnels de Classic peuvent partager le même compte cPanel. Si les opérateurs du site de recette n’ont pas besoin de toucher à la production, demandez comment séparer leurs accès et les droits de base.

Comparez les valeurs de la copie avec les témoins de production avant de changer un réglage. Un ancien fichier de configuration, une variable d’environnement commune ou un préfixe repris d’un export peut fausser la cible. Si un point diffère, corrigez la copie par le parcours documenté et refaites tous les contrôles. Une adresse de recette qui affiche le bon écran ne remplace pas cette vérification.

Modifier un seul témoin et vérifier les deux sites

Gardez la valeur initiale du réglage et choisissez une modification réversible sur la copie privée. Dans cet exemple, le slogan WordPress sert de témoin. Avant d’écrire, relisez le chemin, la base, le préfixe et la valeur initiale depuis la même session. Si quelqu’un vient d’intervenir sur le clone, arrêtez-vous le temps de comparer la nouvelle configuration au relevé. Passez le même chemin explicite à la commande d’écriture.

Relisez ensuite le réglage sur la copie et vérifiez en lecture que la production conserve sa valeur. Un cache de page peut retarder l’apparition du slogan dans le navigateur. Utilisez la lecture de l’option pour vérifier l’écriture avant d’interpréter le rendu public. Notez le résultat et l’heure des deux contrôles dans la recette.

Pour remettre le slogan initial, relisez la valeur actuelle. Si elle correspond au témoin que vous avez posé, restaurez la valeur conservée et contrôlez-la. Si quelqu’un l’a modifiée entre-temps, consignez le conflit avant toute remise à l’ancienne valeur. Sur un site partagé, la lecture suivie d’une écriture n’est pas une opération atomique. Réservez la copie ou coordonnez l’intervention pour éviter une modification simultanée.

Rejouer un ciblage erroné dans une maquette locale

Le ZIP crée deux dossiers et deux bases SQLite temporaires. Les installations fictives partagent la même URL. La base de copie contient deux préfixes, chacun avec un slogan. La première tentative désigne le dossier de production. La deuxième vise le bon dossier mais la base active. La troisième vise la bonne base mais le jeu de tables qui porte le préfixe de production. Une quatrième échoue sur un témoin inattendu.

Après validation des trois identifiants et du témoin, la maquette modifie le slogan de la copie. Elle relit la nouvelle valeur, puis remet l’ancienne. Une modification plus récente introduite avant un second retour reste intacte, car SQLite vérifie la valeur attendue dans l’instruction d’écriture. Le rapport vérifie aussi que les tables voisines et le fichier de base actif sont inchangés.

Les refus et les écritures sont observés dans SQLite. L’exercice modélise les valeurs qu’un technicien doit lire dans WP-CLI. Il ne lance aucun WordPress ni session SSH. Les commandes de lecture jointes servent à refaire le contrôle dans une installation de recette autorisée. Vérifiez sur ce site le chemin effectif et le comportement de ses extensions, qui peuvent intervenir au chargement de WordPress.

Choisir l’offre qui permet de contrôler la cible

OVHcloud Pro convient si l’équipe sait faire correspondre les domaines, dossiers et bases depuis l’espace client, puis utiliser SSH pour vérifier l’installation chargée. Les dix bases de 2 Go donnent des emplacements séparés pour plusieurs copies. Une base dont la taille dépasse le plafond demande un autre dimensionnement, même si le disque Web est loin d’être plein.

Monarobase Classic convient si l’équipe utilise cPanel, souhaite cloner via Installatron et dispose de WP-CLI dans la session SSH prévue. Le compte unique peut suffire pour une petite équipe qui gère tous les sites. Si les accès doivent être séparés par projet, vérifiez les modalités du forfait avant de rendre la copie accessible à d’autres personnes.

Avant d’élargir l’intervention à une mise à jour ou à une importation, consignez la correspondance entre l’inventaire du panneau et la session qui écrit. Exigez la confirmation de la racine, de la base effective, du préfixe et du témoin. Après chaque changement de clone ou de droits, recommencez ce contrôle à partir de la lecture. Le coût du forfait et la facilité du clonage ne décident pas à la place de ces preuves.

• Relever les deux racines et les deux bases avant d’ouvrir SSH.
• Confirmer le fichier de configuration, la base effective et le préfixe avec un chemin explicite.
• Écrire puis relire le témoin de la copie.
• Vérifier l’état du site actif et conserver la valeur de retour.

Pour aller plus loin

• Lire la fiche OVHcloud
• Lire la fiche Monarobase
• Comparer les outils de migration WordPress
• Télécharger la recette de ciblage (ZIP)