Combien de sites, parmi ceux qu’une agence a livrés puis progressivement laissés sans contrat de maintenance actif, continuent de déclarer des abilities capables d’être appelées par un agent IA ? Une agence de développement WordPress d’une dizaine de personnes s’est posé la question après la fin du support étendu de WordPress 6.9, et la réponse l’a surprise.
L’Abilities API, utilisable depuis l’été 2025 et intégrée nativement à WordPress avec la version 6.9 en décembre 2025, permet à une extension de déclarer des capacités consultables et appelables par un agent externe. Plusieurs extensions installées sur d’anciens sites de l’agence avaient adopté cette API dès sa disponibilité, sans que personne, une fois le projet livré, ne pense à revenir vérifier ce qui restait exposé.
La méthode d’audit retenue
L’équipe a listé l’ensemble des sites hébergés pour d’anciens clients sans contrat de maintenance actif depuis plus d’un an, soit une trentaine de sites au total. Sur chacun, un script a interrogé la fonction wp_get_abilities() pour recenser les abilities déclarées, indépendamment de leur usage réel constaté.
Ce que l’audit a trouvé
Sur les trente sites audités, six présentaient des abilities encore actives, pour un total de onze abilities recensées. La plupart provenaient d’extensions de gestion de contenu ou de formulaires, installées à une époque où les équipes testaient les premières intégrations d’agents, sans jamais désactiver ces capacités après la fin du test.
Le détail des abilities retrouvées
| Type d’ability | Nombre de sites concernés | Risque estimé |
|---|---|---|
| Création de contenu automatisée | 4 | Modéré : contenu publiable sans relecture |
| Modification de formulaires de contact | 3 | Faible : impact limité au formulaire |
| Export de données de contact | 2 | Élevé : exposition de données personnelles |
| Modification de paramètres SEO | 2 | Modéré : impact sur le référencement |
Le cas le plus préoccupant concernait l’export de données de contact, une ability testée à l’époque pour un projet d’intégration avec un service tiers finalement abandonné, mais jamais retirée du code de l’extension déployée en production.
Le script d’audit utilisé
function auditer_abilities_site(): array {
$abilities = wp_get_abilities();
$resultats = array();
foreach ( $abilities as $ability ) {
$resultats[] = array(
'nom' => $ability->get_name(),
'description' => $ability->get_description(),
'source' => $ability->get_meta( 'plugin', 'inconnu' ),
);
}
return $resultats;
}Cette fonction, lancée site par site via un script WP-CLI dédié, a permis de constituer un inventaire complet en une seule après-midi, bien plus rapide qu’une revue manuelle du code de chaque extension installée.
Pourquoi ces abilities étaient passées inaperçues
Les sites concernés n’avaient pas de contrat de maintenance actif, donc aucune revue périodique des extensions installées. Les abilities déclarées ne provoquaient aucun symptôme visible pour le client, qui n’avait aucune raison de signaler quoi que ce soit à l’agence tant que le site fonctionnait normalement au quotidien.
- Aucune de ces abilities n’était mentionnée dans la documentation de livraison initiale du projet.
- Les mises à jour d’extensions ultérieures avaient parfois ajouté de nouvelles abilities sans que personne ne le remarque.
- Le client n’avait, dans la plupart des cas, aucune connaissance de l’existence même de ces capacités.
Une capacité déclarée et jamais utilisée n’est pas une capacité neutre : elle reste une porte ouverte, même si personne ne l’a encore poussée.
En résumé
Cet audit a conduit l’agence à intégrer une vérification des abilities déclarées dans sa procédure de fin de contrat de maintenance, plutôt que de laisser cette question sans réponse. Pour toute agence gérant plusieurs dizaines de sites clients, un inventaire régulier des abilities actives, y compris sur les projets sans suivi actif, permet d’éviter qu’une fonctionnalité testée puis oubliée ne devienne un risque silencieux des années plus tard.
