Cinq composants MCP pour MODX testés face aux défaillances : l’agent annonce un succès alors que seule la moitié des modifications a été enregistrée

Une tâche classique consiste à choisir un composant MCP pour confier à un agent IA les opérations courantes sur des sites. Mais le développeur d’un studio web travaillant avec MODX 2 et 3 a examiné le code et découvert une boucle qui met à jour les champs supplémentaires d’une page sans vérifier le résultat de setTVValue(). Le premier champ a été enregistré, le second non, mais le gestionnaire a annoncé un succès. L’agent croira cette réponse et dira à l’utilisateur que tout est terminé.

Cette observation a donné lieu à une petite étude. L’auteur a sélectionné cinq projets : karamble/modxmcp, dampilov94/mcp-component, rumata-estor/modx3-mcp, modxcms/modAI et ShevArtV/mxBoard. Il a figé les sources au 26 octobre 2026 et effectué 25 vérifications sous PHP 8.3.6. Les véritables classes des composants ont été utilisées, mais des objets de test remplaçaient une instance MODX et une base de données réelles. Certains tests reproduisaient délibérément des erreurs : un résultat PASS ne signifie donc pas toujours que le composant se comporte correctement.

Avec quels droits l’agent agit-il ?

Imaginez un gestionnaire de contenu autorisé à travailler uniquement sur les actualités. Si on lui fournit un assistant IA, de quels droits cet assistant disposera-t-il ? Deux modèles ont été trouvés dans les sources. karamble vérifie à la fois l’autorisation d’effectuer l’opération et l’accès à la ressource concernée. L’issue n°11 décrivait même une véritable faille : via MCP, un utilisateur aux droits limités pouvait obtenir des données qu’il ne voyait pas dans l’interface d’administration. Elle a été corrigée dans la version 1.2.0.

Avec dampilov94 et rumata-estor, il est possible de limiter les groupes de commandes, mais celles-ci sont exécutées par un compte de service doté de droits administrateur. Cela convient aux tâches d’administration, mais pas aux assistants personnels d’employés soumis à leurs propres restrictions.

Données obsolètes et réponses perdues

Le prix affiché sur une page est de 1 000 roubles. L’agent le lit, puis un employé le porte entre-temps à 1 100. L’agent écrit 1 200 et la modification humaine disparaît. Dans le code de dampilov94, l’ancienne valeur n’est pas comparée. rumata-estor vérifie la valeur attendue et renvoie le statut STALE_STATE ; lors du test, ce mécanisme a préservé la modification humaine. Mais cette vérification est facultative : si le client ne transmet pas la précondition, l’écriture est effectuée. En outre, la vérification et l’écriture sont séparées, sans comparaison atomique au niveau de la base de données.

Les répétitions posent un autre problème. Si le serveur crée une page, mais que la réponse se perd, l’agent peut répéter la commande et produire un doublon. Le RequestStore de dampilov94 conserve l’état à partir de l’identifiant de la requête. Un doublon exécuté en parallèle reçoit le code 409, une requête terminée renvoie la réponse enregistrée et toute modification des arguments sous le même identifiant provoque le rejet de la requête. Avec un nouvel identifiant, toutefois, la commande est exécutée de nouveau.

Le verrouillage de fichier de rumata-estor a obligé le deuxième processus à attendre 350 ms. Un troisième processus, qui ignorait l’existence de ce verrou, a néanmoins modifié le fichier sans difficulté. L’interface d’administration MODX standard se comportera de la même façon. L’identifiant de requête, le verrouillage et la vérification de la valeur attendue répondent à des problèmes différents et ne se remplacent pas mutuellement.

Écriture partielle et validation

rumata-estor encapsule l’écriture des TV dans une transaction : si setTVValue() renvoie false, un rollback est déclenché. Lors du test, les valeurs sont revenues à leur état initial. modAI ne vérifie pas le résultat de la mise à jour du cache ; pendant le test, l’outil a annoncé un succès malgré une valeur false. karamble relit la ressource après la modification. mxBoard sépare l’exécution d’une tâche de sa validation : un exécutant n’a pas pu fermer la tâche d’un autre utilisateur.

Que faire ?

Les limites de l’étude sont clairement exposées : l’auteur n’a pas encore exécuté de véritable instance MODX avec MySQL et un modèle de langage, et le rollback n’a été vérifié que sur un mock. La conclusion s’applique néanmoins à tout CMS et à toute application dans lesquels un agent est autorisé à modifier des données de production. Avant le lancement, déterminez au nom de qui il agit. Exigez que le client transmette un identifiant de requête et la valeur attendue. Vérifiez le résultat de chaque écriture, pas seulement celui du dernier appel. Enfin, ne considérez pas le « succès » annoncé par l’agent comme la preuve que tout a bien été enregistré sur le site.