Il y a le métier que le client voit, et celui qu’il ne voit jamais. Le premier, ce sont les maquettes, les textes, les photos, la mise en ligne. Le second, c’est vérifier que dix-neuf sites sont toujours à jour, correctement durcis, sauvegardés, et qu’aucun d’eux ne sert une page périmée à un visiteur. Ce travail invisible ne se facture pas et ne se voit pas, mais c’est lui qui décide si un abonnement tient dans le temps.
Depuis plusieurs mois, nous exploitons ce parc à travers le MCP de Cloudways branché sur Claude. Voici ce que cela change réellement, ce que cela ne change pas, et les manques que nous avons remontés à leur équipe produit.
Ce qu’est un MCP, sans jargon
Un serveur MCP est un connecteur normalisé. Il expose les fonctions d’un service, ici l’API de Cloudways, dans un format qu’un assistant conversationnel sait lire et utiliser. Le protocole lui-même est ouvert : n’importe quel éditeur peut publier le sien, et c’est ce qui explique qu’il en apparaisse un nouveau chaque semaine.
Concrètement : au lieu d’ouvrir une console, de cliquer application par application et de recopier des valeurs dans un tableur, on demande, en français, l’état de tout le parc, et on l’obtient.
La bascule n’est pas celle de la vitesse de frappe. Elle est ailleurs : une vérification qui coûtait une journée devient assez peu coûteuse pour être faite souvent. Or une vérification annuelle ne sert à rien. C’est la fréquence qui protège, pas la profondeur, et c’est exactement ce qui sépare un parc suivi d’un parc qu’on laisse vieillir sans y toucher.
Ce que cela change, mesures à l’appui
| Tâche | Avant | Avec le MCP |
|---|---|---|
| Revue de configuration et de sécurité de toutes les applications | Une journée de travail | Quelques minutes, relancée souvent |
| Vérification du durcissement, application par application | Fastidieuse, donc partielle | Exhaustive, rien n’est oublié |
| Purge du cache après correction | Manuelle, donc parfois oubliée | Intégrée à la boucle de recette |
| Tri des vulnérabilités du parc | Site par site | En une seule session, priorisée |
Trois trouvailles concrètes issues de ces audits valent mieux qu’un discours.
Une base de données obèse pour rien. Sur une boutique WooCommerce, une table de journalisation laissée par une extension de sécurité désinstallée pesait 2,8 Go, soit environ 98 % de l’empreinte de la base. Personne ne la lisait depuis des mois. Sans revue du parc, elle aurait continué à grossir, à ralentir les sauvegardes et à gonfler les restaurations.
Un cache d’opcodes sous-dimensionné. Le cache de code compilé du serveur était réglé à une fraction de ce que le parc réclamait. La mesure a montré une table de hachage saturée à deux reprises, ce qui remettait le cache à zéro et faisait retomber son taux d’efficacité. Le réglage corrigé, mesures à l’appui, se voit sur toutes les pages, et la vitesse d’affichage se paie directement en positions.
Des alertes qui mentaient. Le scanner de vulnérabilités signalait des extensions déjà à jour. En recoupant, pour chaque site, la version réellement installée avec celle annoncée, la moitié des alertes se sont révélées être des faux positifs. C’est exactement ce qu’il faut vérifier avant d’automatiser quoi que ce soit : une donnée périmée automatisée devient une erreur industrialisée.
Notre méthode : la confiance se construit par ennui
Nous n’avons jamais accordé la moindre confiance a priori à cet outil, et c’est la raison pour laquelle nous l’utilisons aujourd’hui sur tout le parc.
- Lecture seule d’abord. Pendant les premières semaines, l’assistant ne fait que lire : serveurs, applications, réglages, sauvegardes. Chaque réponse est comparée à la console. Une réponse fausse aurait suffi à tout arrêter.
- Puis des actions sans enjeu. La purge de cache est le premier geste d’écriture que nous avons autorisé : si elle se déclenche à tort, le pire qui arrive est une page recalculée.
- Jamais de décision déléguée. Une mise à jour d’extension majeure sur une boutique en production reste un choix humain, précédé d’une sauvegarde et suivi d’un contrôle. L’outil accélère le constat, pas l’arbitrage.
C’est austère, et c’est précisément le point. La confiance ne s’est pas installée parce que l’outil impressionne, mais parce que chaque affirmation a été vérifiée jusqu’à ce que la vérification devienne inutile.
Les manques que nous avons remontés
Nous avons envoyé ce retour par écrit à l’équipe produit de Cloudways, qui l’a inscrit à sa feuille de route trimestrielle. Le voici tel quel, parce qu’un retour d’expérience honnête vaut mieux qu’un satisfecit.
- La purge de cache par URL. Aujourd’hui la purge est globale à une application. Rafraîchir une seule page corrigée impose donc de vider tout le cache d’une boutique fréquentée. Une note de documentation manque aussi : le cache de périphérie ne sert que les adresses sans paramètres, ce qui nous a coûté quelques heures de recherche.
- La durée de rétention des sauvegardes dans l’API. La fréquence y est exposée, la durée non. Nous en avons besoin pour écrire des engagements exacts dans nos contrats, et il a fallu aller la chercher à la main.
- Des données de vulnérabilité plus fraîches. Le recoupement avec la version réellement installée rendrait ces alertes exploitables par une automatisation, ce qu’elles ne sont pas encore.
- La visibilité des réglages de performance avancés. Le plafond de fichiers du cache d’opcodes ou le cache de tables de la base ne sont accessibles que par le support. Même en lecture seule, les exposer ferait gagner un aller-retour à chaque diagnostic.
Il en manque un cinquième, plus structurant : la portée des jetons d’accès. Un jeton d’API Cloudways ouvre le compte entier. Pour une agence, l’unité qui compte est l’application, pas le compte. Tant qu’un jeton ne peut pas être limité à une application précise, en lecture seule si on le souhaite, aucun outil autonome tiers ne touchera nos serveurs de production. C’est une règle que nous ne négocions pas, et nous l’avons dit à Cloudways aussi clairement qu’ici.
Ce que cela ne répare pas
Un assistant branché sur une infrastructure ne corrige aucun défaut de conception. Un site lourd reste lourd, une extension qui exécute quarante requêtes par page reste coûteuse, un thème mal fichu le reste aussi. Le risque est même de masquer le problème derrière un cache bien réglé, jusqu’au jour où une page non mise en cache s’effondre sous le trafic. Notre méthode pour diagnostiquer la vraie cause d’un site lent ne change pas d’un iota, et le jour où un site tombe pour de bon, c’est la préparation qui compte, pas l’outil.
Même remarque côté sécurité. Voir l’état de durcissement de dix-neuf applications en une minute est précieux, mais cela ne remplace ni les gestes de fond de notre guide pour sécuriser WordPress en profondeur, ni les huit mesures essentielles que nous appliquons à chaque mise en ligne. Un tableau de bord vert n’a jamais empêché une mise à jour de casser un site, ni un site d’être piraté.
Pourquoi cela nous ressemble
Il y a une lecture de sobriété dans tout cela, et elle n’est pas décorative. Cesser de recalculer mille fois la même page, purger un cache au bon moment plutôt qu’au hasard, supprimer 2,8 Go de journaux que personne ne lira, prolonger la vie d’un site au lieu de le refaire : c’est de l’énergie qui n’est pas dépensée. C’est la même logique que celle que nous appliquons au choix d’un hébergement réellement sobre.
Cloudways nous a interrogés cet été sur cette façon de travailler, pour une étude de cas et un portrait d’agence à paraître sur leur site. Nous avons répondu avec les mêmes chiffres que ceux de cet article, et avec les mêmes réserves : nous ne recommandons un outil que si nous acceptons d’en décrire les limites. Nous ajouterons les liens ici dès leur publication.
Ce que nous en retenons
Le MCP n’a pas rendu notre travail plus impressionnant, il l’a rendu plus honnête. Nous promettons aujourd’hui à nos clients des choses que nous pouvons vérifier devant eux, en quelques secondes, sur leur site précisément. Pour une agence tenue par une seule personne, c’est ce qui permet de suivre un parc entier sans rogner sur le soin apporté à chaque site, et sans faire de promesse que l’on ne saurait pas tenir.
Si vous exploitez plusieurs sites et que la revue de parc est devenue une corvée que vous repoussez, le sujet mérite une heure de votre temps. Commencez par mesurer honnêtement ce que vous coûte aujourd’hui une vérification complète : c’est ce chiffre, et non la nouveauté de l’outil, qui vous dira s’il a sa place chez vous.
Pour aller plus loin avec Aloha Pixel
- Hébergement web : bien choisir l’hébergement de son site internet
- Hébergement de site web à Pau : le guide complet
- Sécuriser son site WordPress : les 8 mesures essentielles
- Ce que coûte vraiment un site laissé sans maintenance
- Nos sites web en abonnement, hébergement et suivi compris
- Faire intervenir l’agence sur votre parc
- Parler de votre infrastructure avec nous
