Un collaborateur ouvre une page WordPress : sa présence peut être visible. Un autre commence à modifier un article : WordPress peut indiquer qu’il est en train de travailler dessus.

Mais que se passe-t-il lorsque celui qui modifie la page n’est plus une personne ?

Depuis sa version 0.13.0, Presence API, un feature plugin expérimental développé sous l’égide de l’équipe WordPress Core, sait matérialiser la présence d’un agent IA lorsqu’il enregistre un contenu via REST ou MCP. L’administration peut alors afficher cet agent à côté des collaborateurs humains, avec un badge « Agent ». (⁠Make WordPress)

La nouveauté pourrait sembler anecdotique. Elle ne l’est pas.

À mesure que les agents IA obtiennent le droit non seulement de consulter des données mais aussi de modifier un CMS, un CRM, un ERP ou une plateforme e-commerce, une question devient incontournable :

comment gouverner des logiciels capables d’agir directement dans les outils de l’entreprise ?

WordPress commence à apporter une petite partie de la réponse : rendre leur activité visible.

Mais voir un agent travailler n’est ni l’authentifier, ni contrôler ses permissions, ni conserver l’historique de ses actions.

Et cette distinction va devenir essentielle.

Sommaire

• Presence API : WordPress expérimente une couche de présence⁠
• Ce qui change pour les agents IA⁠
• Un badge Agent ne signifie pas que WordPress a détecté une IA⁠
• 75 secondes de présence ne constituent pas un historique⁠
• MCP rend la question beaucoup plus concrète⁠
• Présence, identité, permissions, logs et audit : ne mélangeons pas tout⁠
• Quels droits donner réellement à un agent IA ?⁠
• Avant de laisser un agent modifier un outil métier : 10 questions⁠
• Et si l’agent se trompe, qui est responsable ?⁠
• Le sujet dépasse déjà largement WordPress⁠
• Que retenir de cet article ?⁠

⁠Presence API : WordPress expérimente une couche de présence

Commençons par une précision importante : Presence API n’est pas une fonctionnalité intégrée au cœur de WordPress.

Au 5 octobre 2026, il s’agit toujours d’un feature plugin expérimental, c’est-à-dire un projet destiné à expérimenter une fonctionnalité qui pourrait éventuellement être proposée un jour à WordPress Core.

La publication officielle du 2 octobre présente la version 0.14.0, compatible avec WordPress 7.0 ou supérieur et PHP 7.4 ou supérieur. WordPress.org la décrit elle-même comme une exploration de ce que pourrait devenir une couche de présence généralisée dans une future version de WordPress. (⁠Make WordPress)

Son objectif initial dépasse d’ailleurs largement l’IA.

Presence API cherche à donner à WordPress une connaissance en temps presque réel des personnes présentes dans l’administration : qui est connecté, sur quel écran et, lorsque cela concerne un contenu, qui est en train de l’éditer.

Les informations transitent notamment via la Heartbeat API et sont stockées dans une table dédiée wp_presence. Pour les utilisateurs classiques, les données de présence sont temporaires, avec une durée de vie de 150 secondes par défaut. (⁠WordPress.org)

Cela permet par exemple d’afficher les utilisateurs actuellement présents, les éditeurs travaillant sur un contenu ou encore, sur un multisite, une vue de l’activité à l’échelle du réseau.

Autrement dit : WordPress expérimente une sorte de « qui est là et sur quoi travaille-t-il ? » à l’échelle de l’administration.

Et c’est précisément cette logique qui devient intéressante lorsque « qui » n’est plus forcément un humain.

Ce qui change pour les agents IA

Un agent connecté à WordPress via une API ne se comporte pas comme quelqu’un devant son navigateur.

Lorsqu’un utilisateur humain travaille dans l’administration, WordPress peut régulièrement recevoir des signaux via sa Heartbeat API.

Un agent intervenant via REST ou MCP, lui, n’envoie pas ce Heartbeat. Il peut recevoir une instruction, effectuer une opération puis disparaître jusqu’à la prochaine demande.

Presence API a donc dû adopter un autre mécanisme.

Depuis la version 0.13.0, lorsqu’un utilisateur identifié comme agent enregistre un contenu, le plugin crée une entrée de présence correspondant à cet agent dans l’espace associé au contenu. L’agent peut alors apparaître dans la barre d’administration et dans la colonne des éditeurs, accompagné d’un badge « Agent ». (⁠Make WordPress)

Imaginez une page « Tarifs » ouverte par Julie, responsable marketing.

Un agent connecté via MCP reçoit parallèlement l’instruction de mettre à jour certaines informations de cette même page.

Si l’intégration est correctement configurée, Presence API peut matérialiser les deux acteurs :

Julie — humaine.

Agent — automatisé.

Ce n’est pas encore un système de gouvernance des agents.

Mais l’interface commence à reconnaître qu’une action éditoriale peut désormais provenir d’une autre catégorie d’acteur.

Un badge Agent ne signifie pas que WordPress a détecté une IA

Il faut ici éviter un raccourci tentant.

Presence API n’analyse pas une requête pour déterminer : « tiens, ceci ressemble à ChatGPT ».

Elle ne détecte pas automatiquement l’intelligence artificielle.

Le plugin demande si l’utilisateur concerné doit être considéré comme un agent. Lorsqu’une intégration compatible fournit cette information, notamment via la fonction wpai_is_agent_user(), Presence API peut l’exploiter. Un autre plugin peut également fournir cette réponse via le filtre wp_presence_is_agent_user.

Sans mécanisme déclarant cet utilisateur comme agent, aucun badge Agent n’est ajouté. (⁠Make WordPress)

La nuance est fondamentale.

L’identité d’un agent ne devrait justement pas dépendre d’une tentative de déduction après coup. Elle devrait être explicite.

C’est d’ailleurs un sujet encore en construction dans l’écosystème WordPress. Les travaux autour des « agent users » partent d’un problème très concret : un agent agit historiquement au nom d’un compte WordPress humain et hérite de son identité et de ses permissions. Cela complique ensuite une question pourtant élémentaire : qui a réellement effectué cette action ? (⁠GitHub)

La feuille de route WordPress 7.2 cite désormais explicitement l’identité et la délégation des agents parmi les pistes explorées : disposer d’identités auditables, de permissions adaptées et d’accès pouvant être administrés indépendamment des comptes humains. Ces travaux restent expérimentaux et ne garantissent pas leur intégration à WordPress 7.2. (⁠Make WordPress)

La bonne direction est probablement celle-ci : un agent ne devrait pas être un administrateur humain auquel on aurait simplement confié une clé API.

75 secondes de présence ne constituent pas un historique

Autre nuance importante : que signifie exactement la « présence » d’un agent ?

Pour un agent REST ou MCP, Presence API ne mesure pas le temps pendant lequel une intelligence artificielle réfléchit, travaille ou reste connectée.

Elle constate une action.

Lorsqu’un agent identifié comme tel enregistre un contenu, une entrée est créée. D’après la publication WordPress du 2 octobre, cette entrée expire environ 75 secondes après le dernier enregistrement, avec la configuration par défaut. (⁠Make WordPress)

Cela signifie qu’un agent ayant enregistré une page il y a quelques secondes peut encore apparaître comme présent.

Cela ne signifie pas nécessairement qu’il est toujours en train de travailler.

Et surtout, une fois l’entrée expirée, Presence API n’a pas vocation à devenir votre journal d’audit historique.

C’est précisément là que trois notions commencent à se séparer :

présence : qui semble actif maintenant ?

journalisation : quelles actions ont été enregistrées ?

audit : peut-on reconstruire de manière fiable qui a fait quoi, quand, avec quelles permissions et éventuellement à partir de quelle instruction ?

Voir « Agent — actif sur cette page » est utile.

Pouvoir expliquer trois semaines plus tard pourquoi son prix est passé de 149 € à 14,90 € l’est probablement davantage.

MCP rend la question beaucoup plus concrète

Pourquoi ce sujet émerge-t-il maintenant ?

Parce que les agents obtiennent progressivement des moyens standardisés d’interagir avec les applications.

Le MCP Adapter officiel de WordPress fait partie de cette évolution. Il sert de passerelle entre l’Abilities API de WordPress et le Model Context Protocol. Des capacités WordPress peuvent ainsi être exposées sous forme d’outils utilisables par des clients compatibles MCP. (⁠GitHub)

L’Abilities API elle-même est intégrée à WordPress depuis la version 6.9. Elle fournit un cadre permettant de déclarer des actions avec leurs entrées, leurs sorties et leurs contrôles de permissions. Les travaux Core ont jusqu’ici volontairement privilégié des capacités prudentes, notamment en lecture, tandis que des capacités d’écriture restent un sujet d’expérimentation. (⁠Make WordPress)

Le MCP Adapter 0.7.0, publié lui aussi le 2 octobre et désormais distribué dans le répertoire WordPress.org, expose ces capacités à des clients MCP avec des contrôles d’authentification et de permissions. Une capacité n’est d’ailleurs pas automatiquement exposée : le modèle prévoit un mécanisme explicite d’exposition. (⁠GitHub)

MCP n’est donc pas « l’IA qui contrôle WordPress ».

C’est une couche d’interopérabilité.

Mais dès lors qu’une capacité exposée permet une écriture, un agent peut potentiellement passer de :

« analyse cette page »

à :

« modifie cette page ».

C’est à ce moment que la gouvernance cesse d’être théorique.

Nous avions déjà observé cette évolution avec les ⁠agents IA capables d’intervenir directement dans les catalogues e-commerce : l’enjeu n’est plus uniquement de produire une réponse pertinente, mais d’encadrer une capacité d’action.

Présence, identité, permissions, logs et audit : ne mélangeons pas tout

L’expérimentation WordPress est intéressante justement parce qu’elle permet de distinguer plusieurs briques souvent regroupées sous le mot très vague de « sécurité ».

1. La visibilité de la présence

Elle répond à :

« Qui semble agir maintenant ? »

Presence API travaille principalement à ce niveau.

2. L’authentification et l’identité

Elles répondent à :

« Qui est cet acteur ? »

Un agent devrait idéalement disposer d’une identité propre, identifiable et révocable, plutôt que d’emprunter indistinctement celle d’un collaborateur.

3. Les permissions

Elles répondent à :

« Qu’a-t-il le droit de faire ? »

Lire les articles ne signifie pas pouvoir les modifier.

Modifier un brouillon ne signifie pas pouvoir le publier.

Mettre à jour une fiche produit ne signifie pas pouvoir changer son prix.

Et administrer du contenu ne devrait certainement pas impliquer automatiquement la possibilité d’installer une extension ou de créer un administrateur.

4. La journalisation

Elle répond à :

« Qu’a-t-il fait ? »

Création d’un contenu, modification d’un prix, changement de statut, suppression d’une donnée…

Ces événements doivent pouvoir être enregistrés dans le temps.

5. La validation humaine

Elle répond à :

« Peut-il exécuter cette action seul ? »

Un agent peut parfaitement être autorisé à préparer une modification sans être autorisé à la rendre publique.

Cette distinction est probablement l’une des plus importantes pour déployer progressivement des agents dans une entreprise.

6. L’audit

Enfin, l’audit cherche à répondre à une question beaucoup plus complète :

« Peut-on reconstruire précisément ce qui s’est passé ? »

Quel agent ?

Quelle action ?

À quelle heure ?

Sur quelle donnée ?

Avec quelle autorisation ?

Quel était l’état précédent ?

Une validation humaine était-elle nécessaire et, si oui, qui l’a donnée ?

Peut-on revenir à la situation antérieure ?

Presence API apporte de la visibilité. Elle ne remplace aucune de ces autres couches.

Et c’est probablement le principal enseignement à retenir de cette expérimentation.

Quels droits donner réellement à un agent IA ?

Le mauvais réflexe serait de raisonner ainsi :

« Il doit gérer WordPress, donnons-lui un compte administrateur. »

Un collaborateur humain possède déjà généralement plus de droits que ceux qu’il utilise quotidiennement. Appliquer la même logique à un acteur automatisé capable d’enchaîner rapidement plusieurs opérations serait peu pertinent.

Le principe devrait plutôt être celui du moindre privilège : donner uniquement les droits nécessaires à la mission.

Prenons un agent chargé d’aider une équipe éditoriale.

Il pourrait avoir le droit de :

• lire les articles existants ;
• rechercher des contenus ;
• créer un brouillon ;
• modifier ses propres brouillons.

Sans nécessairement pouvoir :

• publier ;
• supprimer définitivement un article ;
• modifier les comptes utilisateurs ;
• changer la configuration du site ;
• installer des extensions.

Pour un catalogue e-commerce, la granularité peut aller encore plus loin.

Un agent chargé d’améliorer les descriptions produits peut avoir besoin de modifier le contenu éditorial d’une fiche sans avoir le moindre besoin de toucher au prix, au stock ou aux règles promotionnelles.

La question pertinente n’est donc pas :

« L’agent peut-il accéder à WordPress ? »

Mais :

« Pour accomplir cette mission précise, quelles sont les actions minimales dont il a réellement besoin ? »

Avant de laisser un agent modifier un outil métier : 10 questions

Avant d’autoriser un agent à écrire dans WordPress — ou demain dans un CRM, un ERP, un PIM ou n’importe quel outil métier — une grille relativement simple permet déjà d’éviter beaucoup d’ambiguïtés.

1. Que peut-il lire ?

L’agent a-t-il accès à tout le système ou uniquement aux données nécessaires à sa mission ?

2. Que peut-il modifier ?

Les droits d’écriture sont-ils limités à certains objets, champs ou catégories d’informations ?

3. Peut-il publier ou seulement préparer ?

Créer un brouillon et publier directement sont deux niveaux d’autonomie très différents.

4. Les actions sensibles nécessitent-elles une validation humaine ?

Publication, suppression, changement tarifaire, envoi externe ou modification d’un statut critique peuvent justifier une confirmation.

5. Chaque action est-elle attribuable à l’agent qui l’a réalisée ?

Un compte humain générique utilisé par plusieurs agents rend rapidement cette attribution impossible.

6. Existe-t-il un historique exploitable ?

Pas simplement une trace technique obscure : un historique permettant réellement de comprendre les actions effectuées.

7. Peut-on revenir facilement en arrière ?

Une automatisation fiable n’est pas celle qui ne se trompe jamais. C’est aussi celle dont les erreurs restent récupérables.

8. Les permissions sont-elles limitées au strict nécessaire ?

Si l’agent rédige des contenus, pourquoi pourrait-il administrer les utilisateurs ?

9. Que se passe-t-il s’il interprète mal une instruction ?

Une consigne ambiguë ne doit pas automatiquement se transformer en action irréversible.

10. Comment révoquer immédiatement son accès ?

Il faut pouvoir désactiver l’agent sans couper le compte ou les accès d’un collaborateur humain.

Cette grille n’est pas spécifique à l’IA.

Elle reprend des principes classiques de gestion des accès et de gouvernance des systèmes d’information.

La nouveauté est simplement qu’un nouveau type d’utilisateur arrive à la porte.

Et qu’il travaille vite.

Et si l’agent se trompe, qui est responsable ?

Le badge « Agent » apporte également une information utile sur un autre sujet : l’attribution.

Supposons qu’un agent modifie une information erronée sur une page publique.

Qui est responsable ?

Le modèle qui a produit la mauvaise information ?

L’outil qui l’a exécutée ?

Le collaborateur qui a rédigé l’instruction ?

L’entreprise qui a autorisé l’agent à publier sans validation ?

Techniquement, un système de présence ne répond évidemment pas à cette question.

Mais il met en évidence une réalité : dès lors qu’une entreprise autorise un agent à agir, elle doit définir les conditions de cette délégation.

Un workflow peut par exemple prévoir :

Agent → prépare → humain valide → publication.

Pour certaines opérations parfaitement réversibles et à faible impact :

Agent → exécute → journalisation → contrôle a posteriori.

Et pour une opération particulièrement sensible :

Agent → propose → humain autorise explicitement → exécution → journalisation.

Il n’existe donc pas un unique niveau d’autonomie pertinent.

Il dépend du risque associé à chaque action.

L’autonomie d’un agent qui reformule une meta-description n’a aucune raison d’être gouvernée comme celle d’un agent capable de modifier 15 000 tarifs dans un ERP.

Le sujet dépasse déjà largement WordPress

C’est finalement pour cette raison que Presence API mérite d’être regardée au-delà de l’écosystème WordPress.

Le CMS fournit simplement un exemple particulièrement visible d’une transformation beaucoup plus large.

Aujourd’hui, un agent peut lire une base documentaire.

Demain — et dans certains environnements, déjà aujourd’hui — il peut également :

• modifier une page ;
• créer un article ;
• enrichir une fiche produit ;
• mettre à jour une opportunité commerciale dans un CRM ;
• manipuler certaines données d’un ERP ;
• préparer une campagne ;
• déclencher une automatisation ;
• appeler plusieurs outils successivement pour accomplir une tâche.

Nous entrons progressivement dans une phase où l’agent n’est plus seulement une interface conversationnelle placée devant le système d’information.

Il devient l’un de ses acteurs.

C’est également ce qui rend les évolutions autour du ⁠commerce agentique et des agents capables d’intervenir dans le parcours e-commerce intéressantes : la question se déplace progressivement de ce que le modèle sait comprendre vers ce que les systèmes acceptent de le laisser exécuter.

À partir de là, cinq sujets deviennent indissociables :

identité, permissions, historique, validation et rollback.

WordPress expérimente pour l’instant essentiellement la première manifestation visible de cette évolution : montrer qu’un agent vient d’intervenir sur un contenu.

C’est peu.

Mais conceptuellement, c’est important.

Pendant des années, nos logiciels ont principalement dû distinguer des utilisateurs et leurs rôles.

Ils vont désormais devoir distinguer des humains, des services automatisés et des agents capables de prendre eux-mêmes certaines décisions intermédiaires pour atteindre un objectif.

La question ne sera donc bientôt plus seulement :

« Que sait faire cet agent ? »

Elle deviendra :

« Qu’avons-nous décidé de l’autoriser à faire, sous quelle identité, avec quelles limites — et serons-nous capables de retrouver précisément ce qu’il a fait ? »

Que retenir de cet article ?

• Presence API n’est pas intégrée à WordPress Core. Au 5 octobre 2026, elle reste un feature plugin expérimental, actuellement en version 0.14.0. (⁠Make WordPress)
• Depuis la version 0.13.0, un agent identifié comme tel peut générer une entrée de présence lorsqu’il enregistre un contenu via REST ou MCP. (⁠Make WordPress)
• L’agent apparaît alors dans certaines interfaces avec un badge « Agent », mais WordPress ne détecte pas automatiquement qu’une requête provient d’une IA.
• Pour les agents, cette présence expire environ 75 secondes après le dernier enregistrement : ce n’est donc ni une mesure de temps de travail ni un historique d’activité. (⁠Make WordPress)
• Presence API répond essentiellement à « qui semble agir maintenant ? ». Authentification, permissions, journalisation, validation humaine et audit répondent à d’autres besoins.
• MCP rend cette distinction particulièrement importante dès lors que des capacités d’écriture sont exposées à des agents.
• Un agent devrait disposer uniquement des permissions nécessaires à sa mission et, lorsque cela est possible, d’une identité distincte et révocable.
• Plus un agent obtient de capacités d’action, plus l’attribution, l’historique, la validation et la possibilité de revenir en arrière deviennent importantes.

Le véritable enjeu des agents IA en entreprise ne sera bientôt plus seulement de savoir ce qu’ils savent faire.

Il sera de savoir ce qu’on les autorise à faire — et de pouvoir retrouver précisément ce qu’ils ont fait.

Sources

WordPress Core — Presence API: What’s new, 2 octobre 2026
⁠Lire la publication officielle WordPress Core

WordPress.org — Presence API
⁠Consulter la fiche du feature plugin Presence API

WordPress Core — Presence API Feature Plugin, 27 avril 2026
⁠Consulter la présentation initiale du projet

WordPress — MCP Adapter
⁠Consulter le dépôt officiel MCP Adapter

WordPress Core — Expanding WordPress Core Abilities
⁠Consulter la proposition autour des Core Abilities

WordPress Core — Roadmap to WordPress 7.2
⁠Consulter la roadmap WordPress 7.2

WordPress AI — Agent users et identité auditable
⁠Consulter le travail autour de l’identité des agents