npm install ou pip install suffit techniquement à ajouter un module à un serveur MCP (Model Context Protocol, apparu fin 2024) déjà en fonctionnement. Techniquement, oui. Prudemment, non : contrairement à une extension WordPress publiée sur le dépôt officiel, qui passe par une revue humaine minimale avant sa mise en ligne, un module communautaire distribué via un gestionnaire de paquets généraliste ne subit aucun filtre équivalent.
Un serveur MCP qui expose des outils à un agent IA connecté à un site WordPress mérite le même niveau de précaution qu’un serveur de production classique, avec une contrainte supplémentaire : les outils qu’il expose peuvent déclencher des actions sur le site lui-même. Un module d’extension compromis n’affecte donc pas seulement le serveur MCP, mais potentiellement toute la surface qu’il contrôle.
Identifier la provenance réelle du module
Avant toute installation, une recherche rapide permet de répondre à trois questions : qui maintient ce module, depuis combien de temps, et combien de personnes l’utilisent réellement. Un module publié la semaine précédente par un compte créé le même jour, sans historique de contributions ni dépôt de code visible, constitue un signal d’alerte suffisant pour reporter l’installation.
Le dépôt source doit être accessible publiquement (GitHub ou équivalent), avec un historique de commits cohérent dans le temps et plusieurs contributeurs si le module prétend être largement adopté. L’absence de dépôt visible, ou un dépôt créé juste avant la publication du paquet, doit systématiquement interrompre le processus d’installation.
Vérifier la signature du paquet
Les registres de paquets npm prennent en charge la vérification de provenance depuis plusieurs années : la commande suivante affiche les métadonnées de provenance disponibles pour un paquet donné.
npm view nom-du-module-mcp dist.integrity
npm audit signatures
La première commande affiche le hachage d’intégrité déclaré pour la version installée ; la seconde vérifie que les paquets installés correspondent à des signatures reconnues par le registre. Un résultat d’échec ne signifie pas nécessairement une compromission, mais impose une vérification manuelle supplémentaire avant de poursuivre.
Lire le code avant de l’exécuter
Un module MCP typique reste de taille raisonnable : quelques centaines à quelques milliers de lignes pour la majorité des outils simples. Une lecture, même rapide, du fichier principal et de ses dépendances directes permet de repérer les signaux les plus évidents :
- Des appels réseau vers des domaines qui n’ont aucun rapport avec la fonction annoncée du module
- Du code fortement obscurci ou minifié dans un paquet censé être lisible en développement
- Des dépendances transitives inhabituellement nombreuses pour un outil simple
Automatiser une partie de cette lecture
Un outil d’analyse statique comme Semgrep, appliqué avec des règles génériques de détection de code suspect (appels réseau dynamiques, exécution de code depuis une chaîne), accélère cette revue sans la remplacer entièrement. Ce type d’outil signale des motifs à examiner, il ne certifie jamais l’absence de risque.
Tester en environnement isolé avant la production
Le module s’installe d’abord sur une instance de serveur MCP séparée, connectée à un site WordPress de test sans donnée réelle, avec un jeton d’application à portée volontairement restreinte. Cette étape permet d’observer le comportement réel du module (appels réseau effectués, fichiers lus, mémoire consommée) avant de l’exposer à un environnement de production.
{
"mcpServers": {
"test-module": {
"command": "node",
"args": ["./modules/nom-du-module/index.js"],
"env": {
"WP_APP_PASSWORD": "jeton-de-test-portee-restreinte"
}
}
}
}
Un module MCP qui refuse de fonctionner sans un jeton à portée large n’a probablement pas été conçu avec le principe de moindre privilège en tête : c’est un motif suffisant pour chercher une alternative.
Garder une trace de la décision d’installation
Une fois le module validé, consigner la date de vérification, la version installée et le hachage vérifié dans un fichier de suivi versionné évite de devoir refaire cette analyse à chaque mise à jour de dépendance. Une mise à jour mineure du module devrait déclencher une nouvelle vérification rapide, pas une confiance automatique reconduite indéfiniment.
Pour aller plus loin
La vérification de provenance d’un module MCP communautaire suit globalement la même logique qu’une revue d’extension WordPress avant achat : identité du mainteneur, historique du dépôt, lecture du code, test isolé. La différence tient à la surface d’impact : un module compromis dans ce contexte contrôle potentiellement des actions automatisées sur un site en production, ce qui justifie de ne jamais sauter l’étape de test isolé, même sous pression de calendrier.
