# Un an de nettoyage : des abilities en excès retirées de sites d’artisans

> Retour sur un audit qui a supprimé des dizaines d'abilities inutilisées, déclarées par des extensions sur des sites vitrines d'artisans, et la méthode suivie pour ce nettoyage.

- Auteur : Clément Hadrot
- Publié le : 2026-03-09
- Mis à jour le : 2026-03-09
- Catégorie : IA & MCP
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/nettoyage-abilities-exces-sites-artisans/

## L’essentiel

- Une ability inutilisée depuis six mois est une candidate au retrait
- Le nettoyage a réduit la surface d'attaque sans supprimer de fonctionnalité utile
- La méthode s'appuie sur des journaux d'appel, pas sur des suppositions

Cinquante-deux abilities recensées, trente-quatre retirées : c'est le bilan d'une année de nettoyage menée sur un parc d'une vingtaine de sites vitrines appartenant à des artisans du bâtiment — plombiers, électriciens, menuisiers — tous construits sur WordPress par la même petite agence régionale. La méthode suivie n'a rien de spectaculaire, mais elle a demandé de la constance sur la durée.

Le point de départ n'était pas un incident de sécurité, mais une simple observation : plusieurs extensions installées sur ces sites avaient adopté l'Abilities API dès sa généralisation avec WordPress 6.9, sans que personne ne se demande, extension après extension, si ces capacités correspondaient à un usage réel ou à une fonctionnalité activée par défaut et jamais utilisée.

## Le point de départ : un inventaire simple

La première étape a consisté à recenser, via `wp_get_abilities()`, l'ensemble des abilities déclarées sur chacun des vingt sites du parc. Cet inventaire initial a fait remonter cinquante-deux abilities distinctes, réparties de façon inégale : certains sites n'en déclaraient aucune, d'autres jusqu'à sept ou huit.

## La méthode : observer avant de supprimer

Plutôt que de retirer immédiatement les abilities jugées suspectes, l'équipe a mis en place une journalisation systématique des appels effectifs, sur une période de six mois, avant toute décision de suppression. Ce délai a permis de distinguer les abilities réellement inutilisées de celles simplement peu fréquentes mais légitimes.

> L'essentiel à retenir : Une ability inutilisée depuis six mois est une candidate au retrait ; Le nettoyage a réduit la surface d'attaque sans supprimer de fonctionnalité utile ; La méthode s'appuie sur des journaux d'appel, pas sur des suppositions

## Le script de journalisation utilisé

```
function journaliser_appel_ability( string $ability_name, callable $callback ): callable {
    return function ( ...$args ) use ( $ability_name, $callback ) {
        global $wpdb;
        $wpdb->insert(
            $wpdb->prefix . 'journal_appels_abilities',
            array(
                'ability' => $ability_name,
                'date'    => current_time( 'mysql' ),
                'site'    => get_bloginfo( 'url' ),
            )
        );
        return call_user_func_array( $callback, $args );
    };
}

// Chaque execute_callback déclaré est enveloppé par cette fonction
// avant l'enregistrement de l'ability, pour tracer chaque appel réel.
```

Au bout de six mois, une requête simple sur cette table de journal a suffi à identifier les abilities n'ayant reçu aucun appel enregistré, candidates naturelles au retrait, à condition de vérifier au préalable qu'aucun processus externe ne les appelait en dehors du périmètre surveillé.

## Ce que le nettoyage a réellement retiré

| Type d'ability retirée | Nombre | Raison principale |
| --- | --- | --- |
| Génération de devis automatisée non activée | 14 | Fonctionnalité testée puis abandonnée par le client |
| Modification de formulaires de contact | 9 | Aucun agent connecté sur ces sites |
| Export de données de prospects | 7 | Intégration tierce jamais mise en place |
| Modification de paramètres SEO | 4 | Doublon avec une extension SEO existante |

## Ce qui a été conservé, et pourquoi

Les dix-huit abilities restantes correspondaient soit à un usage effectivement constaté dans les journaux, soit à un besoin identifié pour une évolution proche déjà planifiée avec le client. Aucune ability n'a été conservée par simple prudence ou par manque de temps pour trancher : chaque décision, dans un sens ou dans l'autre, a été documentée.

- Les décisions de retrait ont été validées site par site avec les artisans concernés, pas décidées unilatéralement par l'agence.
- Aucune régression fonctionnelle n'a été signalée après les retraits effectués.
- Le processus de journalisation reste actif en continu, pas seulement pendant la période d'audit.

> Une ability qu'on retire par précaution après six mois d'inactivité coûte beaucoup moins cher qu'une ability qu'on découvre exploitée après plusieurs années d'oubli.

## En résumé

Ce nettoyage n'a rien changé à l'expérience des visiteurs des sites concernés, ni à celle des artisans qui les utilisent au quotidien pour présenter leur activité. Il a en revanche réduit sensiblement la surface exposée à un éventuel agent tiers mal intentionné, sans reposer sur des suppositions : chaque suppression s'est appuyée sur six mois de données d'usage réelles, ce qui donne à l'agence une confiance raisonnable dans la pertinence de ses choix.