Avec la généralisation du client MCP natif dans WordPress 7.0 et la multiplication des serveurs MCP tiers proposés par des éditeurs indépendants, souvent hors du répertoire officiel des extensions et sans le même niveau de revue que celui-ci, la question de la provenance de ces modules devient centrale. Un module MCP mal intentionné, ou simplement mal conçu, peut demander des permissions bien plus larges que sa fonction annoncée, avec un impact potentiellement supérieur à celui d’une extension WordPress classique, puisqu’il agit souvent avec un accès direct à des outils d’écriture sur le site.
Cette checklist détaille les sept vérifications à effectuer avant de connecter un module MCP tiers à un site client en production, dans un ordre pensé pour écarter rapidement les cas les plus problématiques avant d’investir du temps sur les vérifications les plus approfondies.
1. Vérifier la source de publication du module
La première vérification, la plus rapide, consiste à identifier où le module est réellement publié et maintenu : un dépôt GitHub public avec un historique de commits régulier et plusieurs contributeurs identifiables inspire davantage confiance qu’un fichier téléchargé depuis un site web isolé, sans aucune trace de code source consultable. L’absence de code source ouvert n’est pas rédhibitoire en soi, mais elle impose de reporter une part de la confiance sur la réputation de l’éditeur, qu’il faut alors vérifier séparément.
# Vérifier l'activité récente d'un dépôt GitHub avant d'aller plus loin
gh api repos/editeur/module-mcp --jq '.pushed_at, .stargazers_count, .open_issues_count'2. Lister exhaustivement les permissions demandées
Chaque module MCP déclare, au moment de sa connexion, la liste des outils qu’il souhaite exposer et les permissions WordPress associées. Cette liste doit être comparée méthodiquement à la fonction annoncée du module dans sa documentation : un module qui se présente comme un « assistant de rédaction SEO » ne devrait jamais demander l’accès à des outils de gestion des utilisateurs ou de modification des réglages globaux du site.
wp mcp module inspect editeur-seo/assistant-redaction --format=json | \
jq '.outils_exposes[] | {nom, permission_requise}'Sur un audit récent mené pour un client du secteur immobilier, cette vérification a révélé qu’un module se présentant comme un simple générateur de méta-descriptions demandait, sans aucune justification apparente dans sa documentation, une permission d’écriture sur les commentaires du site, un périmètre totalement disproportionné par rapport à sa fonction annoncée.
3. Vérifier la signature du module quand elle existe
Certains éditeurs de modules MCP proposent désormais une signature cryptographique de leurs paquets, permettant de vérifier que le code reçu correspond bien à celui publié par l’éditeur, sans altération intermédiaire (par exemple lors d’une distribution via un miroir tiers non officiel) :
gpg --verify module-mcp-1.4.0.sig module-mcp-1.4.0.tar.gzL’absence de signature ne doit pas être interprétée comme une preuve de malveillance, cette pratique restant encore peu répandue dans l’écosystème MCP naissant, mais sa présence constitue un signal positif fort, et son échec de vérification (une signature présente mais invalide) doit systématiquement interrompre l’installation.
4. Auditer un extrait de code représentatif, même sans tout relire
Pour un module open source, une lecture ciblée du code source, même partielle, permet de repérer rapidement des motifs préoccupants : des appels réseau vers des domaines non mentionnés dans la documentation, des tentatives de lecture de fichiers sensibles (wp-config.php, journaux de connexion), ou du code fortement obfusqué sans raison légitime apparente :
grep -rn "file_get_contents\|curl_exec\|fetch(" src/ | grep -v "domaine-officiel-attendu"5. Vérifier la fraîcheur de maintenance du module
Un module dont la dernière mise à jour remonte à plus d’un an mérite une vigilance renforcée, en particulier dans un écosystème aussi récent et évolutif que celui du protocole MCP, où les bonnes pratiques de sécurité continuent d’évoluer rapidement. Un module abandonné peut contenir des dépendances obsolètes ou des failles connues jamais corrigées, à l’image de ce qui se produit avec les extensions WordPress classiques laissées à l’abandon.
6. Tester en environnement isolé avant toute connexion en production
Avant toute connexion sur le site d’un client, le module doit être testé sur un environnement de recette, isolé du site de production, avec une surveillance active du trafic réseau sortant généré pendant son utilisation :
tcpdump -i any -w capture-test-mcp.pcap host exemple-dev.wordpress-developpement.fr &
# Utiliser le module normalement pendant quelques minutes, puis analyser
tshark -r capture-test-mcp.pcap -Y "http.request" -T fields -e http.hostToute connexion sortante vers un domaine non mentionné dans la documentation officielle du module doit être investiguée avant d’autoriser sa mise en production, quelle que soit la légitimité apparente du module par ailleurs.
7. Documenter la décision, positive ou négative
Que le module soit finalement approuvé ou écarté, la décision et les éléments qui l’ont motivée méritent d’être consignés dans un registre accessible à l’équipe, pour éviter qu’un même module ne soit réévalué depuis zéro par une autre personne quelques mois plus tard, ou pire, installé par erreur après avoir été précédemment écarté pour une raison oubliée entre-temps :
| Module | Décision | Motif |
|---|---|---|
| assistant-redaction (éditeur-seo) | Refusé | Permission d’écriture sur les commentaires sans justification |
| generateur-alt-images (studio-visuel) | Approuvé | Code source vérifié, permissions cohérentes, maintenance active |
Un module MCP qui ne peut pas justifier chacune des permissions qu’il demande ne mérite pas la confiance qu’on lui accorderait par défaut, même s’il vient d’un éditeur par ailleurs réputé.
Ce qu’il faut retenir
La multiplication des modules MCP tiers, souvent distribués en dehors des canaux officiels et avec un niveau de revue très inégal, appelle une rigueur au moins équivalente à celle déjà appliquée à l’installation d’une extension WordPress classique, avec une attention particulière portée aux permissions demandées, disproportionnées dans un nombre non négligeable de cas observés jusqu’ici. Cette checklist ne remplace pas un jugement au cas par cas, mais elle structure une démarche reproductible, applicable avant chaque nouvelle connexion envisagée sur un site de production.
