# En 2026, les vérifications avant de laisser un agent IA toucher un site en ligne

> Des rôles au rollback, la liste complète des vérifications finales avant un premier déploiement d'un agent capable d'écrire sur un site en production.

- Auteur : Clément Hadrot
- Publié le : 2026-02-09
- Mis à jour le : 2026-02-09
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/verifications-agent-ia-ecriture-site-2026/

## L’essentiel

- Sept vérifications avant toute écriture en production
- Aucune ne remplace les autres, chacune couvre un risque distinct
- Le rollback reste le point le plus souvent négligé

WordPress 6.9, sorti en décembre 2025, a généralisé l'Abilities API et rendu bien plus courante la question suivante : maintenant que la déclaration de capacités pour un agent est devenue une pratique presque standard, quelles vérifications reste-t-il à faire avant d'autoriser la première écriture réelle sur un site en production ?

Cette liste rassemble sept vérifications, issues de plusieurs déploiements observés depuis le début de l'année, qui reviennent systématiquement dans les projets qui se sont bien passés — et dont l'absence, à l'inverse, a précédé les incidents les plus sérieux rencontrés sur d'autres projets.

## 1. Un rôle applicatif dédié à l'agent

L'agent doit disposer d'un rôle WordPress créé spécifiquement pour lui, avec des capacités ajoutées une à une via `add_cap()`, jamais hérité d'un rôle administrateur existant même temporairement, pas même pour un test.

## 2. Des abilities déclarées, listées, documentées

Chaque ability accordée à l'agent doit apparaître dans une documentation accessible à l'équipe, avec sa description, son périmètre exact et la raison de son existence. Une ability non documentée est une ability qu'on oubliera de retirer le jour où elle ne sert plus.

> L'essentiel à retenir : Sept vérifications avant toute écriture en production ; Aucune ne remplace les autres, chacune couvre un risque distinct ; Le rollback reste le point le plus souvent négligé

## 3. Un plafond de volume par session

Aucune écriture massive ne doit pouvoir se produire en une seule session sans confirmation intermédiaire. Un seuil bas, révisable à la hausse une fois la confiance établie, protège contre les instructions ambiguës qui déclenchent un traitement plus large que prévu.

## 4. Un journal d'audit consultable en dehors du code

Le journal des actions de l'agent doit être consultable par une personne non technique de l'équipe, pas seulement retrouvable dans les journaux serveur. Une interface simple, même minimale, fait une vraie différence lors d'une revue mensuelle.

## 5. Une procédure de rollback testée, pas seulement théorique

C'est le point le plus souvent négligé selon ce retour d'expérience : une procédure de rollback documentée mais jamais réellement exécutée en conditions de test a de bonnes chances de ne pas fonctionner le jour où elle devient nécessaire. Un test de restauration, même sur un environnement de test, doit précéder la mise en production.

```
# Exemple de test de rollback via WP-CLI, sur un environnement de test
wp db export avant-test-agent.sql
wp eval-file simuler-ecritures-agent.php
wp db import avant-test-agent.sql
wp post list --post_type=article --posts_per_page=5
```

## 6. Une confirmation humaine pour les actions irréversibles

Publication définitive, suppression, envoi externe (e-mail, paiement) : ces catégories d'actions doivent systématiquement passer par une étape de confirmation humaine, indépendamment de la confiance accumulée envers l'agent sur d'autres types d'actions.

## 7. Une revue périodique du périmètre accordé

Les besoins évoluent, les abilities accordées ont tendance à s'accumuler sans jamais être retirées. Une revue trimestrielle, calée par exemple sur les mises à jour majeures de WordPress, permet de retirer ce qui ne sert plus.

- Ces sept points se vérifient dans l'ordre indiqué, mais aucun ne peut être sauté sans augmenter le risque global.
- Un projet qui coche les sept cases reste plus simple à auditer qu'un projet qui en a sauté deux ou trois « pour gagner du temps ».
- La documentation de chaque point doit survivre au départ de la personne qui l'a mis en place.

> Une procédure de rollback qu'on n'a jamais testée n'est pas une procédure : c'est une intention, et les intentions ne restaurent pas une base de données.

## Un exemple de checklist appliquée à un projet réel

Sur un projet de taille moyenne mené récemment, ces sept points ont été traités en un peu moins de trois semaines avant le premier déploiement réel d'un agent d'écriture, avec un responsable technique désigné pour chaque point plutôt qu'une seule personne cumulant toutes les vérifications.

| Vérification | Responsable | Temps estimé |
| --- | --- | --- |
| Rôle applicatif dédié | Développeur backend | 1 jour |
| Documentation des abilities | Chef de projet | 2 jours |
| Plafond de session | Développeur backend | 1 jour |
| Journal d'audit consultable | Développeur front-end | 3 jours |
| Test de rollback | Administrateur système | 2 jours |
| Confirmations irréversibles | Développeur backend | 2 jours |
| Calendrier de revue périodique | Chef de projet | 0,5 jour |

Cette répartition par responsable, plutôt que par une seule personne isolée, a permis de traiter les sept points en parallèle sans allonger démesurément le calendrier global du projet, tout en gardant une trace claire de qui avait validé quoi avant la mise en production.

## En résumé

Aucune de ces sept vérifications n'est spécifique à un secteur d'activité ou à une taille de site particulière : elles s'appliquent aussi bien à une association qu'à un site marchand de taille importante. Ce qui varie, c'est le niveau d'exigence appliqué à chacune selon la sensibilité des données concernées. Ce qui ne varie pas, c'est la nécessité de les traiter toutes avant la première écriture réelle en production, sans en écarter aucune par manque de temps.