La première fois qu’un client nous a demandé d’autoriser un agent à modifier directement du contenu en production, notre réponse a été de construire une checklist plutôt que de répondre au cas par cas. Depuis, cette liste s’est enrichie de chaque projet, et elle sert désormais de porte d’entrée obligatoire avant toute mise en écriture réelle.
Elle ne remplace pas une réflexion complète sur les garde-fous ou la conformité réglementaire, déjà traitée par ailleurs : elle sert de passage en revue rapide, point par point, juste avant l’activation.
Avant l’activation : préparation
- Un environnement de recette isolé reproduit fidèlement la production, données comprises.
- L’agent a été testé sur ce clone pendant au moins deux semaines sans incident bloquant.
- Chaque outil MCP exposé a un schéma d’entrée strict, sans paramètre libre non validé.
- Les identifiants de contenu ciblés (ID, slug) sont vérifiés avant toute action, jamais devinés par similarité de titre.
- Un compte utilisateur dédié à l’agent existe, distinct de tout compte humain.
Permissions et périmètre
- Le compte de l’agent a le rôle le plus restreint possible, jamais
administratorpar défaut. - Les types de contenu autorisés en écriture sont listés explicitement, pas déduits implicitement.
- Les statuts autorisés en sortie sont limités : un agent qui propose du contenu publie en
draftoupending, jamais directement enpublish, sauf décision explicite documentée. - Aucun outil n’autorise la suppression définitive de contenu ; la corbeille reste le seul chemin possible.
- Les capacités WordPress (
edit_posts,publish_posts…) attribuées au compte agent sont revues une à une, pas copiées d’un rôle existant sans vérification.
Journalisation et traçabilité
- Chaque appel d’outil est journalisé avec l’horodatage, le paramètre reçu et le résultat produit.
- Le prompt ou l’instruction ayant déclenché l’action est conservé, pas seulement l’action elle-même.
- Les journaux sont accessibles à une personne humaine désignée, pas seulement archivés sans consultation prévue.
- Une alerte est déclenchée automatiquement au-delà d’un seuil d’appels sur une fenêtre de temps donnée.
Réversibilité et rollback
- Chaque action d’écriture a un chemin de retour arrière documenté et testé, pas seulement supposé possible.
- Les révisions de contenu WordPress sont activées et conservées suffisamment longtemps pour couvrir une action de l’agent.
- Une sauvegarde récente de la base de données existe avant la première activation en production.
- Une procédure écrite précise qui coupe l’accès de l’agent en cas d’incident, et en combien de temps.
Validation finale
- Une personne responsable a explicitement validé l’activation, pas seulement l’équipe technique.
- Une date de première revue est fixée à l’avance, généralement deux à quatre semaines après l’activation.
Un point coché sans preuve n’est pas un point coché. Chaque ligne de cette liste doit pouvoir être démontrée, pas seulement affirmée.
Ce que cette checklist ne couvre pas
Elle ne traite pas en détail les questions de conformité au RGPD ni les garde-fous conversationnels plus larges (limites de ton, refus de certaines demandes) : ces sujets méritent un traitement dédié, déjà abordé ailleurs sur ce blog. Elle se concentre volontairement sur le passage technique et organisationnel entre un agent qui propose et un agent qui agit réellement sur un site en production.
Comment nous l’utilisons réellement en projet
Dans la pratique, cette checklist ne se remplit jamais en une seule séance. Elle sert de fil conducteur à trois réunions distinctes espacées de quelques jours : une première où l’équipe technique valide les points de préparation et de permissions, une deuxième où la personne responsable côté client examine la journalisation et les scénarios de rollback, et une troisième, juste avant l’activation, où chaque point est repassé en revue avec la date de première évaluation déjà fixée au calendrier.
Cet étalement dans le temps n’est pas une lourdeur inutile : il a permis, sur plusieurs projets, de repérer un point mal préparé avant l’activation plutôt qu’après. Un exemple concret rencontré récemment : lors de la deuxième réunion d’un projet de gestion de fiches produit, l’équipe s’est rendu compte que la procédure de coupure d’accès en cas d’incident existait sur le papier, mais que personne n’avait vérifié qui, concrètement, détenait les identifiants nécessaires pour l’exécuter un samedi soir. Ce genre de détail, invisible dans une checklist cochée trop vite, se révèle précisément quand on prend le temps de la discuter point par point plutôt que de la parcourir en diagonale.
Un exemple de fiche de suivi
| Point | Statut | Preuve associée |
|---|---|---|
| Environnement de recette isolé | Validé | Lien vers le clone de test |
| Rôle restreint pour le compte agent | Validé | Capture des capacités attribuées |
| Procédure de coupure d’accès | À compléter | Identifiants à désigner |
Cette dernière colonne, la preuve, est celle que nous ajoutons systématiquement depuis que nous avons constaté à quel point un point coché sans justification concrète finit par être oublié dès la réunion suivante.
Pour aller plus loin
Cette liste évolue à chaque incident rencontré en projet. Sa valeur ne vient pas de son exhaustivité théorique, mais du fait qu’elle a été construite à partir de situations réelles où l’un de ces vingt points, ignoré, a causé un problème concret. Nous vous encourageons à l’adapter à votre contexte plutôt qu’à la suivre telle quelle : certains projets à faible enjeu peuvent s’en passer, d’autres devraient en ajouter.
