J’ai inscrit deux applications WordPress dans Cloudways Site Manager pour ce test, l’une via l’écran d’onboarding caché dans la barre latérale d’une application, l’autre via le flux groupé qui se trouve au niveau du compte.
De là, j’ai lancé un vrai Safe Update sur quatre plugins, créé un planning d’auto-update partagé couvrant les deux sites, activé le logging d’activité, et passé assez de temps dans le dashboard au niveau du compte pour comprendre où la même information apparaît à plus d’un endroit, et pourquoi ça compte plus qu’on ne le croit.
Site Manager a remplacé un ancien add-on Cloudways appelé SafeUpdates. Comprendre ce que SafeUpdates ne pouvait pas faire explique presque toutes les décisions de conception du produit actuel.
SafeUpdates tournait entièrement en SSH, ce qui créait un ensemble de problèmes bien précis pour toute personne gérant plus de quelques sites :
Les agences qui géraient vingt installations WordPress ou plus ont dit à Cloudways, en gros, que l’outil fonctionnait jusqu’au moment où il ne suivait plus la montée en charge, et la montée en charge était précisément la raison pour laquelle elles étaient sur Cloudways au départ.
Site Manager est la réponse directe à ce retour. Ce contexte est important pour lire la suite de ce test, parce qu’il explique pourquoi certaines parties du produit paraissent étonnamment mûres pour quelque chose encore en Public Preview, et pourquoi d’autres parties, comme l’étape d’onboarding que vous rencontrerez dès le premier jour, montrent encore les coutures.
Avec ce contexte en place, la question suivante est celle du périmètre : qu’est-ce que cet outil couvre réellement. Avant d’entrer dans l’onboarding, les mises à jour et la planification, il vaut mieux être précis sur ce que Site Manager couvre et ce qu’il ne couvre pas, parce que la réponse honnête est plus nuancée qu’un simple oui ou non.
Toutes les applications disponibles à l’enrôlement dans le Site Manager au niveau du compte, que ce soit via l’écran par application ou via l’assistant en masse sous Integrations, provenaient d’un serveur déjà présent dans mon compte Cloudways.
Il n’y avait aucun champ pour coller des identifiants d’une installation hébergée ailleurs, ni de connecteur pour un site tournant chez un autre hébergeur.
L’ensemble des fonctionnalités couvertes dans ce test, Safe Update, le clone de staging, les tests de régression visuelle, les logs d’activité, la planification à l’échelle du portefeuille, tout cela vit dans cette couche native hébergée par Cloudways.
Cloudways propose aussi un plugin WordPress gratuit, lui aussi appelé Cloudways Site Manager, co-développé avec WP Remote.
Contrairement au dashboard natif, ce plugin s’installe directement sur un site WordPress, quel que soit l’hébergeur, ce qui lui permet d’intégrer un site externe, non Cloudways, dans une version de la même vue centralisée.
C’est un produit réellement différent du dashboard natif, toutefois, et l’écart entre les deux compte :
| Capacité | Site Manager natif (applications hébergées sur Cloudways) | Plugin Site Manager (n’importe quel hébergeur) |
|---|---|---|
| Dashboard centralisé | Oui | Oui |
| Mises à jour du core, des plugins, des thèmes | Oui | Oui |
| Safe Update (clone de staging + régression visuelle) | Oui | No |
| Caching au niveau serveur (Varnish, Redis, Cloudflare) | Oui | No |
| Logs d’activité | Oui (Pro) | Pas équivalent |
| Coût | Gratuit (Basic) / payant (Pro) | Gratuit |
Le plugin désactive aussi les mises à jour automatiques natives de WordPress lorsqu’il est actif, un choix délibéré de Cloudways pour éviter les conflits pendant la gestion à distance.
Cloudways indique clairement que la voie du plugin est un tremplin plutôt qu’une destination : si vous voulez la stack complète, sauvegardes automatiques, staging en un clic, intégration Cloudflare, caching managé, la bonne pratique annoncée est de migrer le site externe vers Cloudways plutôt que de le gérer à distance sur le long terme.
Pour une agence dont le portefeuille est entièrement hébergé sur Cloudways, rien de tout cela n’a d’importance. Pour toute personne qui garde encore quelques sites ailleurs, et la plupart des agences avec qui j’ai échangé au fil des années ont au moins quelques sites dans ce cas, le plugin est une vraie option pour le monitoring de base et les mises à jour, mais pas un substitut à ce que fait le dashboard natif.
Avec la question du périmètre réglée, la partie pratique commence ici : enrôler effectivement une application WordPress. Cloudways propose deux portes d’entrée vers Site Manager natif, et elles ne se valent pas pour le même usage.
Voici exactement comment j’y suis allé la première fois. Depuis le dashboard d’accueil Cloudways, j’ai cliqué sur mon serveur, puis sur l’application WordPress qui s’y trouvait, ce qui m’a amené sur la page Access Details de cette app.
La barre latérale de gauche y liste Access Details, Staging Management, Monitoring, Application Security, Domain Management, puis Site Manager, marqué d’un badge “New”. En cliquant dessus, je suis allé directement sur un écran intitulé “Simplify App Management with Site Manager,” entièrement centré sur cette seule application, avec deux cartes de plans côte à côte, Basic et Pro.
J’ai cliqué sur Get Pro. C’est là que les choses ont dérapé.
L’écran a changé pour “Subscribing to the Site Manager Plan…” avec un message expliquant que Cloudways installait le plugin et synchronisait les données du site, et que cela pouvait prendre quelques minutes selon la taille de l’application.
Ça a tourné pendant environ deux minutes puis a échoué, en revenant avec une notification d’erreur rouge : “Please delete existing plugin and install again.” Je n’avais aucune installation préalable à supprimer, donc le message ne m’indiquait pas ce qui avait réellement mal tourné.
J’ai cliqué une deuxième fois sur Get Pro, sur le même écran de plan, sans rien changer. Cette tentative a fonctionné. Elle a duré environ trois minutes et s’est terminée avec une notification verte confirmant que j’étais abonné au plan Site Manager, en me déposant sur la page Site Manager Overview de l’app, avec le nombre de plugins, le nombre de thèmes, un score de performance et un tableau Manage Updates déjà remplis et prêts.
C’est le chemin à utiliser dès que vous avez plus d’un site à gérer, et voici exactement comment je l’ai trouvé et utilisé.
Depuis le dashboard d’accueil Cloudways, la navigation à gauche affiche une rangée d’icônes : Home, Flexible, Autonomous, Integrations, et Agency Partners. J’ai cliqué sur Integrations. Cela a ouvert un panneau de cartes, parmi lesquelles Site Manager (marqué “New”), Application Migration, DNS Made Easy, CookieYes, et Equalize Digital Accessibility Checker.
Cliquer sur la carte Site Manager m’a amené sur un écran complètement différent du Chemin 1, qui vit sous le fil d’Ariane Integrations → Add-Ons → Site Manager, avec sa propre rangée d’onglets : Overview, Manage Updates, Auto Updates, History.
Cette page Overview est le vrai poste de commande. Elle affiche des statistiques globales du compte, Total Apps on Site Manager, Apps on Free Plan, Apps on Pro Plan, Apps with Auto Updates, et, en dessous, un tableau Manage Applications listant chaque app déjà enrôlée.
Pour en intégrer d’autres, j’ai cliqué sur Add Apps to Site Manager en haut à droite de ce tableau. Cela a ouvert un assistant en deux étapes :
Une note au-dessus de la liste expliquait qu’il exclut les apps de staging, les apps sur des serveurs arrêtés, et toute app déjà sous l’ancien add-on SafeUpdates. J’ai coché l’app voulue et cliqué sur Select Plan.
L’ensemble du flux a pris moins d’une minute une fois arrivé à l’assistant, et il s’appliquait à toutes les apps que j’avais cochées à l’étape 1 en même temps, sans répéter le choix du plan pour chaque site.
Après avoir enrôlé des apps via les deux chemins, voici le constat qui a changé ma façon de voir la maintenance quotidienne de ce produit. J’ai ajouté une deuxième application WordPress à un serveur qui avait déjà Site Manager en train de gérer activement une autre app sur ce même serveur.
Je m’attendais à ce que la nouvelle app apparaisse automatiquement, puisqu’elle se trouvait juste à côté d’une app que Site Manager connaissait déjà. Ce n’est pas arrivé. Le compteur “Total Apps on Site Manager” du dashboard au niveau du compte est resté exactement au même niveau jusqu’à ce que je passe manuellement la nouvelle app par l’onboarding.
C’est un choix de conception, mais un choix de conception qui a un coût opérationnel :
Site Manager se divise en un vrai niveau gratuit utile et un niveau Pro qui débloque les fonctionnalités autour desquelles une agence construirait réellement un workflow.
| Fonctionnalité | Basic (Gratuit) | Pro |
|---|---|---|
| Site Overview | Oui | Oui |
| Gérer les utilisateurs, thèmes, plugins | Oui | Oui |
| Quick Updates | Oui | Oui |
| WordPress Single Sign-On | Oui | Oui |
| Dashboard centralisé | Oui | Oui |
| Safe Updates (clone de staging + test de régression) | No | Oui |
| Mises à jour automatiques planifiées | No | Oui |
| Surveillance des performances du site | No | Oui |
| Logs d’activité | No | Oui |
| Historique des mises à jour | No | Oui |
Basic n’est pas une version d’essai bridée. Il inclut un vrai aperçu du site, la possibilité de gérer utilisateurs, thèmes et plugins sans passer par wp-admin, un accès Single Sign-On WordPress en un clic, Quick Updates, et, point notable, le dashboard centralisé lui-même.
Cloudways n’a pas réservé l’expérience de base “voir tous vos sites au même endroit” derrière un paywall. Ce qui est réservé, c’est tout ce qui rend ce dashboard assez fiable pour agir sans le surveiller en permanence.
Pro est actuellement gratuit à l’usage pendant la Public Preview, quel que soit son prix affiché, qui est de $3 par app et par mois, avec une baisse à $2 par app une fois que vous dépassez cinq applications.
Ce seuil de remise mérite un calcul avant de supposer que Pro reste bon marché à grande échelle :
| Sites gérés | Coût Pro (prix affiché) |
|---|---|
| 3 sites | $9/mois |
| 5 sites | $10/mois ($2/app) |
| 10 sites | $20/mois |
| 25 sites | $50/mois |
| 50 sites | $100/mois |
Aucun de ces montants n’est déraisonnable face au coût potentiel d’une seule mise à jour cassée et sans sauvegarde pour la confiance d’un client, mais une tarification par app signifie que la facture augmente en ligne droite avec votre portefeuille, pas avec les paliers de remises plus marqués que proposent certains outils concurrents aux niveaux supérieurs.
Une fois l’enrôlement et le prix clarifiés, le reste de ce test couvre ce à quoi ressemble l’usage quotidien, en commençant par un élément d’architecture qui mérite d’être compris.
C’est la partie de la conception de Site Manager qui m’a demandé le plus de temps pour être vraiment comprise, et elle n’est expliquée nulle part dans l’interface elle-même.
Ce sont trois portes d’entrée vers la même pièce. La vue par application est pour quelqu’un qui travaille déjà dans ce site précis et qui remarque au passage une mise à jour en attente. L’action au niveau du compte est pour quelqu’un qui balaie tout le portefeuille et décide d’agir tout de suite sur un site.
L’onglet de planification sert à retirer l’humain de la boucle complètement.
Des trois portes décrites juste avant, cette section couvre les deux premières, la vue par app et l’action de ligne au niveau du compte, puisque les deux ouvrent le même mécanisme de mise à jour.
Tous les plans offrent Quick Update. L’appliquer prend quelques secondes : la mise à jour s’installe directement en production sans vérification de compatibilité et sans sauvegarde préalable.
Le texte de l’interface Cloudways est honnête sur le compromis, en avertissant que cela “peut comporter des risques si les mises à jour ne sont pas compatibles.”
Je n’ai pas exécuté de Quick Update pendant ce test, donc je ne peux pas décrire de première main à quoi ressemble un échec à l’écran. C’est une vraie lacune dans ce test, et je considérerais toute affirmation sur le comportement d’échec de Quick Update, de ma part ou de n’importe qui d’autre qui ne l’a pas déclenché, avec la prudence qui s’impose.
Safe Update est là où Pro justifie son prix, et ça vaut la peine de détailler le processus, parce qu’il est plus complexe que “sauvegarde, puis mise à jour.”
Voici exactement comment je l’ai lancé. Depuis le tableau Overview au niveau du compte sous Integrations → Site Manager, j’ai trouvé la ligne de l’app avec des mises à jour en attente et cliqué sur le menu à trois points Actions au bout de cette ligne. Il a ouvert quatre options : WP-Admin, App Overview, Manage Updates, et Manage Plan. J’ai cliqué sur Manage Updates.
Cela a ouvert une modale listant chaque plugin avec une mise à jour en attente, quatre dans mon cas, Breeze, Elementor, Object Cache Pro, et WP ULike, chacun affiché comme un élément coché avec sa version actuelle et la version cible.
En dessous de la liste se trouvaient deux options radio : Quick Update et Safe Update, chacune avec une description d’une ligne du compromis. J’ai sélectionné Safe Update et cliqué sur Proceed.
Au lieu d’un simple spinner de progression, la modale qui s’est ouverte ensuite affiche une checklist par étapes mise à jour en temps réel.
Environnement de staging :
Production :
J’ai lancé l’exécution à 6:21 pm et elle s’est terminée à 6:27 pm. Six minutes, pour quatre plugins, sur un cycle complet staging puis production. La modale elle-même laisse entendre que cela “prend généralement moins d’une minute”, ce que mon exécution a dépassé de beaucoup.
Ce décalage entre l’estimation affichée et le temps réel vaut la peine d’être anticipé plutôt que de vous surprendre si vous lancez Safe Update sur un lot de plugins pendant une fenêtre de maintenance, prévoyez des minutes, pas des secondes, surtout à mesure que le nombre de plugins augmente.
Une notification de succès a confirmé le résultat, et dès la fin, l’onglet History au niveau du compte l’a consigné comme “On-Demand Successful: Plugins (4)” avec un lien vers le détail complet.
Cette fermeture de la boucle, voir une action se dérouler puis pouvoir immédiatement pointer vers une trace permanente de ce qui s’est passé, c’est exactement le genre de preuve face au client dont une agence a besoin, et que SafeUpdates n’offrait jamais.
Ils se trouvent tous les deux dans le flux de planification plutôt que dans l’écran de mise à jour à la demande, ce qui les rend faciles à manquer :
Ensemble, ces deux réglages par défaut déterminent si une exécution nocturne sans surveillance vous réveille avec un plugin signalé à part dans une file, ou avec tout un site bloqué au milieu d’une mise à jour parce qu’un thème incompatible a arrêté tout le processus. À vérifier avant de faire confiance à un planning qui doit tourner sans surveillance.
Ça couvre les deux premières portes. Cette section couvre la troisième : retirer l’humain de la boucle complètement. L’onglet Auto Updates, accessible depuis la même page Site Manager au niveau du compte, est l’endroit où le pitch “gérer plusieurs sites comme s’il n’y en avait qu’un” tient ses promesses ou s’écroule. Dans mon cas, il a tenu ses promesses.
Voici exactement comment je l’ai configuré. Depuis Integrations → Site Manager, j’ai cliqué sur l’onglet Auto Updates dans la rangée du haut.
Avec rien de planifié pour l’instant, la page affichait un état vide, “No Auto Updates Schedule,” avec un seul bouton : Set Auto Update Schedule.
En cliquant dessus, j’ai ouvert un assistant, “Set Auto Update Schedule,” qui déroulait les éléments suivants d’un seul passage :
Un second écran s’est ensuite ouvert, “Create Auto Update Schedule,” couvrant :
Cliquer sur Set AutoUpdate Schedule en bas a enregistré le tout, appliqué à toutes les apps que j’avais sélectionnées à l’étape 2, sans devoir répéter la configuration site par site.
Les trois portes et les mécanismes de mise à jour derrière elles couvrent le comment. Cette dernière fonctionnalité couvre la preuve : un enregistrement permanent de ce qui s’est passé, séparé du processus de mise à jour lui-même.
Voici exactement comment je l’ai activée.
Depuis la page Site Manager Overview de cette app, la même page qui s’affiche après l’abonnement via le Chemin 1, une carte intitulée “Activity Logs are Disabled” se trouve à côté du cercle de performance, avec une courte description et un seul bouton : Enable Activity Logs.
J’ai cliqué dessus, et la carte s’est mise à jour immédiatement, sans modale de confirmation, sans étape supplémentaire. En vérifiant juste après le tableau Manage Applications au niveau du compte, sous Integrations → Site Manager, la colonne Activity Logs pour cette app était déjà passée de Disabled à Enabled, sans avoir besoin de rafraîchir la page.
Cette fonctionnalité est réservée à Pro, et elle sert à répondre à une question que toute agence finit par entendre d’un client : qui a changé quoi, et quand ?
Sans cela, la réponse vit généralement dans un plugin de logs WordPress qui écrit dans la base de données du site, ce qui l’alourdit avec le temps et n’offre aucune protection contre la falsification. Avoir cet historique en dehors de l’installation WordPress elle-même, dans la couche hébergement, constitue un niveau de confiance sensiblement différent pour tout ce qui est orienté client.
Avec l’ensemble des fonctionnalités, leurs coûts et leurs limites sur la table, la dernière question est simplement de savoir si cela correspond à votre portefeuille précis.
L’usage le plus évident est une agence ou un développeur freelance qui gère plusieurs, idéalement beaucoup, de sites WordPress qui vivent déjà entièrement sur Cloudways, où une mise à jour cassée a un vrai coût en confiance client plutôt qu’un simple désagrément personnel.
Le workflow Safe Update et la planification groupée existent précisément pour résoudre le problème qui apparaît dès qu’on n’est plus à un stade où vérifier chaque site individuellement reste raisonnable.
C’est un bon choix partiel pour toute personne avec un portefeuille mixte. Le plugin gratuit Site Manager peut intégrer des sites externes pour le monitoring de base et les mises à jour, mais les fonctionnalités qui rendent le dashboard natif digne d’être payé, Safe Update basé sur le staging, la régression visuelle, les logs d’activité, restent hors de portée jusqu’à ce que ces sites soient réellement migrés vers Cloudways.
C’est tout simplement inutile pour un propriétaire d’un seul site. Le niveau gratuit fonctionnerait techniquement, mais tout le produit existe pour résoudre un problème à l’échelle d’un portefeuille qu’un seul site ne crée jamais.
Oui, le site manager mérite d’être adopté, à une condition : que vos sites vivent déjà sur Cloudways. Dans cette limite, Site Manager tient ses promesses, un vrai dashboard cross-app, un chemin Safe Update qui sauvegarde avant de toucher la production, et une planification groupée qui traite les mises à jour comme une action à l’échelle de la flotte plutôt que comme une corvée site par site.
En dehors de cette limite, c’est un outil plus léger avec une incitation claire à migrer intégrée. Le meilleur cas d’usage est une agence qui regroupe des sites clients sur Cloudways et qui a besoin d’un seul endroit pour prouver ce qui a changé et quand.
| Description | Expert Review |
|---|---|
| Hébergement WordPress géré avec rapidité, sécurité, et mises à jour sans traca... | Read Wordpress Hosting Review |
| Hébergement cloud flexible, à hautes performances avec des ressources évolutives e... | Read Cloud Hosting Review |
| Hébergement de messagerie sécurisé et efficace, adapté aux besoins de communicati... | Read Email Hosting Review |
| Hébergement Magento optimisé avec des vitesses rapides et des performances e-commer... | Read Magento Hosting Review |
| Read WooCommerce hosting Review | |
| Read VPS Hosting Review |
Oui. Cloudways Site Manager est un add-on natif qui centralise les mises à jour, la surveillance des performances et les journaux d’activité pour les applications WordPress déjà hébergées dans votre compte Cloudways. Un plugin compagnon séparé et gratuit étend une surveillance plus légère et la gestion des mises à jour aux sites WordPress hébergés n’importe où.
Pas via le tableau de bord natif testé dans cette revue, qui est limité aux applications déjà hébergées sur Cloudways. Un plugin gratuit, également appelé Cloudways Site Manager et co-développé avec WP Remote, peut intégrer des sites externes pour la surveillance et les mises à jour du core, des plugins et des thèmes, mais sans le Safe Update avec clone de staging, tests de régression visuelle, ni le cache au niveau du serveur.
Le niveau Basic est gratuit et couvre l’aperçu du site, la gestion des utilisateurs et des plugins, ainsi que les Quick Updates. Pro ajoute les Safe Updates, la planification, le suivi des performances et les journaux d’activité pour 3 $ par application et par mois, avec un tarif qui baisse à 2 $ à partir de cinq applications ou plus, et c’est actuellement gratuit pendant la Public Preview.
Quick Update applique les changements directement en production en quelques secondes, sans sauvegarde ni vérification de compatibilité. Safe Update crée une copie de staging, vérifie la compatibilité, met à jour chaque package, lance un test de régression visuelle, et ne passe en production que si ce test réussit.
Oui. Les nouvelles applications ne s’inscrivent jamais automatiquement, même quand on les ajoute à un serveur qui a déjà d’autres applications Site Manager en cours d’exécution dessus. Chaque site a besoin de sa propre étape d’intégration, soit individuellement, soit via l’assistant en lot dans Integrations.
Répondez à quelques questions simples et trouvez la solution parfaite pour vous !
Commencer la recherche d'hébergement
