Le WordPress d'aujourd'hui, décodé pour les développeurs

IA & MCP

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.

Par Clément Hadrot • 9 mars 2026 • 4 min de lecture • Aucun commentaire
Un an de nettoyage : des abilities en excès retirées de sites d'artisans

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éeNombreRaison principale
Génération de devis automatisée non activée14Fonctionnalité testée puis abandonnée par le client
Modification de formulaires de contact9Aucun agent connecté sur ces sites
Export de données de prospects7Intégration tierce jamais mise en place
Modification de paramètres SEO4Doublon 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.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi