Le WordPress d'aujourd'hui, décodé pour les développeurs

IA & MCP

Antipattern : donner à un agent IA les mêmes droits que l’administrateur du site

Pourquoi confier à un agent IA un compte administrateur partagé constitue une faute de sécurité, ce qu'on observe le plus souvent chez des freelances pressés par un délai court, et comment construire un rôle restreint à la place.

Par WordPress Développement • 3 février 2025 • 4 min de lecture • Aucun commentaire
Antipattern : donner à un agent IA les mêmes droits que l'administrateur du site

« Vous avez atteint votre quota d’appels, merci de patienter » : ce message, reçu au milieu d’une démonstration client, a poussé un développeur freelance à accorder en urgence à son agent IA les mêmes droits que son propre compte administrateur, le temps de débloquer une tâche bloquée par une permission manquante. Cette solution de facilité, censée durer une heure, est restée en place plusieurs semaines.

Ce type de raccourci se rencontre fréquemment chez des développeurs indépendants travaillant seuls, sous la pression d’un délai serré, sans processus de revue de sécurité en place pour repérer ce genre d’oubli une fois la tâche urgente terminée.

Ce qu’on observe chez des freelances pressés

Le scénario se répète avec des variations mineures : un agent IA doit accomplir une tâche précise (mettre à jour des fiches produit, modérer des commentaires, générer des brouillons d’articles), et une permission manquante bloque son exécution. Plutôt que d’identifier précisément la capacité manquante, la solution la plus rapide consiste à attribuer au compte de l’agent le rôle d’administrateur dans son intégralité, qui inclut par défaut toutes les capacités possibles du site.

Cette solution fonctionne immédiatement, ce qui explique sa popularité sous pression : elle résout le blocage en quelques secondes, sans nécessiter de comprendre en détail le système de rôles et capacités de WordPress.

Pourquoi c’est une faute de sécurité

L'essentiel à retenir : Un agent avec un rôle administrateur peut modifier n'importe quel réglage, pas seulement la tâche prévue ; Un rôle personnalisé, limité aux capacités strictement nécessaires, réduit la surface de risque ; Le gain de temps initial d'un compte partagé se paie souvent au premier incident

Un compte administrateur peut, par définition, tout faire sur un site WordPress : installer une extension, modifier le thème actif, créer un autre compte administrateur, supprimer des contenus, changer les réglages de sécurité. Un agent IA connecté avec ce niveau de droits hérite de toutes ces capacités, y compris celles qu’aucune tâche prévue ne justifie.

  • Un prompt mal formulé, ou une réponse générée de façon inattendue par le modèle, peut déclencher une action destructrice que rien ne bloque au niveau des permissions.
  • Une clé d’API ou un jeton compromis donne alors accès à l’intégralité du site, plutôt qu’à un périmètre limité.
  • Aucune trace ne permet de distinguer, dans les journaux d’activité, une action légitime de l’agent d’une action qu’un humain aurait pu effectuer avec le même compte.

Ce dernier point complique particulièrement tout audit ultérieur : sans rôle dédié, il devient impossible de savoir, a posteriori, si une modification a été effectuée par l’agent ou par un administrateur humain partageant le même compte.

Quoi faire à la place

La bonne pratique consiste à créer un rôle personnalisé, dédié à l’agent, qui ne contient que les capacités strictement nécessaires à la tâche confiée. WordPress permet de définir un tel rôle avec la fonction add_role, en listant précisément les capacités autorisées plutôt que d’hériter de celles d’un rôle existant plus large.

add_role( 'agent_moderation', 'Agent de moderation IA', array(
    'read'                   => true,
    'edit_comment'           => true,
    'moderate_comments'      => true,
    'manage_options'         => false,
    'edit_theme_options'     => false,
    'install_plugins'        => false,
) );

Ce rôle, appliqué à un compte dédié utilisé uniquement par l’agent, garantit qu’aucune action en dehors de la modération de commentaires ne peut être exécutée avec ces identifiants, même en cas de comportement inattendu du modèle ou de compromission du jeton d’accès.

Identifier précisément la capacité manquante

Plutôt que d’élargir les droits par tâtonnement, il est plus rigoureux de consulter la documentation des rôles et capacités de WordPress pour repérer la capacité exacte requise par l’action bloquée. Un blocage lors de la publication d’un commentaire modéré, par exemple, pointe généralement vers la capacité moderate_comments, sans qu’il soit nécessaire d’accorder l’ensemble des droits d’un éditeur ou d’un administrateur.

Un rôle trop large ne se voit jamais tant que rien ne se passe mal : c’est précisément ce qui le rend dangereux, il fonctionne exactement comme un rôle restreint jusqu’au jour où il ne le fait pas.

Ce que cette précaution ne couvre pas

La question de l’audit régulier des journaux d’activité, pour vérifier que le rôle restreint reste effectivement respecté dans le temps et n’a pas été élargi par une modification ultérieure, relève d’une pratique distincte qui mérite un traitement à part entière, non abordé ici.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi