Créer un plugin WordPress custom en 2026 : structure, hooks, internationalisation

Depuis que je développe sous WordPress (2015, ça ne me rajeunit pas), j’ai créé ou maintenu plus de quarante plugins custom pour des clients allant de la startup parisienne à l’ETI industrielle. Et je constate chaque année la même chose : beaucoup de développeurs débutants empilent des extensions tierces là où un plugin sur mesure de 200 lignes réglerait le problème proprement. En 2026, avec WordPress 6.8 et l’écosystème qui a considérablement mûri, créer son propre plugin n’a jamais été aussi accessible. Encore faut-il le faire correctement.

Je vous propose ici le guide que j’aurais aimé avoir à mes débuts : la structure de fichiers, le fonctionnement des hooks, l’internationalisation, la sécurité, et les vrais coûts d’un plugin custom. Avec du code, des retours terrain, et zéro bullshit marketing.

Pourquoi créer un plugin custom plutôt qu’utiliser une extension existante

La question mérite d’être posée avant d’écrire la moindre ligne de code. Dans mon activité, je recommande un plugin custom dans trois situations précises :

• Le besoin métier est spécifique : vous avez besoin d’un système de réservation qui s’intègre à votre ERP maison, ou d’un formulaire de devis qui calcule des prix selon une grille tarifaire complexe. Aucune extension générique ne couvrira ça sans bidouilles.
• La performance est critique : j’ai audité des sites qui chargeaient 47 requêtes SQL supplémentaires à cause d’un seul plugin polyvalent alors que la fonctionnalité utilisée n’en nécessitait que 3. Un plugin custom n’embarque que ce dont vous avez besoin.
• La maintenabilité à long terme : dépendre d’une extension tierce qui peut être abandonnée, rachetée ou modifiée sans préavis représente un vrai risque. Un plugin que vous contrôlez, c’est un plugin que vous maîtrisez.

En revanche, pour des besoins standards comme les formulaires de contact, un SEO basique ou la gestion de cache, les extensions éprouvées du répertoire officiel restent souvent le meilleur choix. Le développement custom a un coût, et il faut que ce coût soit justifié par un gain réel.

Structure des fichiers d’un plugin WordPress en 2026

Un plugin WordPress, dans sa forme la plus simple, c’est un seul fichier PHP placé dans wp-content/plugins/. Mais dès que votre extension dépasse la centaine de lignes, une organisation rigoureuse devient indispensable. Voici la structure que j’utilise systématiquement sur mes projets clients :

mon-plugin/
├── mon-plugin.php              # Fichier principal (bootstrap)
├── uninstall.php               # Nettoyage à la suppression
├── readme.txt                  # Description pour le répertoire WP
├── languages/
│   ├── mon-plugin-fr_FR.po
│   └── mon-plugin-fr_FR.mo
├── includes/
│   ├── class-mon-plugin.php        # Classe principale
│   ├── class-mon-plugin-loader.php # Gestionnaire de hooks
│   └── class-mon-plugin-i18n.php   # Internationalisation
├── admin/
│   ├── class-mon-plugin-admin.php  # Logique back-office
│   ├── css/
│   └── js/
├── public/
│   ├── class-mon-plugin-public.php # Logique front-end
│   ├── css/
│   └── js/
└── templates/
    └── template-parts/

Le fichier principal mon-plugin.php contient l’en-tête obligatoire que WordPress utilise pour identifier votre extension :

<?php
/**
 * Plugin Name:       Mon Plugin Custom
 * Plugin URI:        https://example.com/mon-plugin
 * Description:       Description courte de la fonctionnalité.
 * Version:           1.0.0
 * Requires at least: 6.4
 * Requires PHP:      8.1
 * Author:            Thomas Lefèvre
 * Author URI:        https://synergie-web.fr
 * License:           GPL v2 or later
 * Text Domain:       mon-plugin
 * Domain Path:       /languages
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit; // Empêche l'accès direct au fichier
}

define( 'MON_PLUGIN_VERSION', '1.0.0' );
define( 'MON_PLUGIN_PATH', plugin_dir_path( __FILE__ ) );
define( 'MON_PLUGIN_URL', plugin_dir_url( __FILE__ ) );

require_once MON_PLUGIN_PATH . 'includes/class-mon-plugin.php';

function mon_plugin_run() {
    $plugin = new Mon_Plugin();
    $plugin->run();
}
mon_plugin_run();

Plusieurs points importants dans ce code. La vérification ABSPATH empêche quiconque d’appeler le fichier directement via son URL. Les constantes VERSION, PATH et URL centralisent les informations réutilisées partout dans le plugin. Et le champ Requires PHP: 8.1 est crucial en 2026 car WordPress affichera un avertissement si le serveur ne respecte pas cette exigence, conformément aux exigences officielles de l’en-tête plugin WordPress.

Hooks WordPress : comprendre les actions et les filtres

Les hooks sont le mécanisme central de l’architecture WordPress. Sans eux, impossible de modifier le comportement du CMS sans toucher au code source. Je les explique toujours à mes clients avec cette analogie : les hooks sont des prises électriques dans un mur. Votre plugin est l’appareil que vous branchez dessus.

Il existe deux types de hooks :

Les actions (add_action) permettent d’exécuter du code à un moment précis du cycle WordPress. Par exemple, ajouter un script CSS dans le header, envoyer un email après la publication d’un article, ou créer une table en base de données à l’activation du plugin.

// Exécuter du code quand WordPress charge le front-end
add_action( 'wp_enqueue_scripts', 'mon_plugin_charger_styles' );

function mon_plugin_charger_styles() {
    wp_enqueue_style(
        'mon-plugin-style',
        MON_PLUGIN_URL . 'public/css/style.css',
        array(),
        MON_PLUGIN_VERSION
    );
}

// Exécuter du code à l'activation du plugin
register_activation_hook( __FILE__, 'mon_plugin_activation' );

function mon_plugin_activation() {
    // Créer les tables, options par défaut, etc.
    add_option( 'mon_plugin_version', MON_PLUGIN_VERSION );
    flush_rewrite_rules();
}

Les filtres (add_filter) interceptent une donnée, la modifient, et la retournent. Ils ne déclenchent pas une action : ils transforment un contenu. C’est une distinction fondamentale que beaucoup de développeurs juniors confondent.

// Modifier le contenu d'un article avant affichage
add_filter( 'the_content', 'mon_plugin_ajouter_cta' );

function mon_plugin_ajouter_cta( $content ) {
    if ( is_single() && in_the_loop() && is_main_query() ) {
        $cta = '<div class="mon-plugin-cta">';
        $cta .= '<p>Besoin d\'un devis ? Contactez-moi.</p>';
        $cta .= '</div>';
        $content .= $cta;
    }
    return $content; // TOUJOURS retourner la valeur dans un filtre
}

Un piège classique : oublier le return dans un filtre. Résultat : le contenu disparaît complètement. J’ai vu ce bug en production plus souvent que je ne voudrais l’admettre. Autre point essentiel : la priorité (troisième paramètre de add_action et add_filter, par défaut 10) détermine l’ordre d’exécution. Plus le chiffre est bas, plus le hook s’exécute tôt.

Depuis WordPress 6.5, les hooks peuvent également être enregistrés via des attributs PHP 8, une approche que je trouve plus lisible pour les gros plugins avec des dizaines de hooks :

// Approche moderne avec le système de hooks OOP
class Mon_Plugin_Public {

    public function __construct() {
        add_action( 'wp_enqueue_scripts', array( $this, 'enqueue_styles' ) );
        add_filter( 'the_title', array( $this, 'modifier_titre' ), 10, 2 );
    }

    public function enqueue_styles() {
        wp_enqueue_style( 'mon-plugin', MON_PLUGIN_URL . 'public/css/style.css', array(), MON_PLUGIN_VERSION );
    }

    public function modifier_titre( $title, $post_id ) {
        // Logique de modification
        return $title;
    }
}

Internationalisation : rendre votre plugin multilingue

L’internationalisation (i18n) est souvent reléguée au second plan par les développeurs pressés. C’est une erreur que j’ai moi-même commise à mes débuts. Même si votre plugin est destiné à un client francophone unique, préparer le terrain pour le multilingue ne coûte presque rien au développement initial et vous évitera une refonte douloureuse plus tard.

Le principe est simple : chaque chaîne de texte visible par l’utilisateur doit passer par une fonction de traduction WordPress. Les deux fonctions principales sont __( ) (retourne la traduction) et _e( ) (affiche directement la traduction) :

// Retourner une chaîne traduite
$message = __( 'Votre formulaire a été envoyé.', 'mon-plugin' );

// Afficher directement une chaîne traduite
_e( 'Paramètres du plugin', 'mon-plugin' );

// Traduction avec placeholder (sprintf)
$count = 5;
$texte = sprintf(
    /* translators: %d est le nombre d'éléments traités */
    __( '%d éléments ont été traités avec succès.', 'mon-plugin' ),
    $count
);

// Pluriel conditionnel
$texte = sprintf(
    _n(
        '%d élément traité.',
        '%d éléments traités.',
        $count,
        'mon-plugin'
    ),
    $count
);

Le text domain ('mon-plugin' dans les exemples) doit correspondre exactement au slug de votre plugin. C’est ce qui permet à WordPress de charger le bon fichier de traduction. Le chargement se fait dans votre classe d’internationalisation :

class Mon_Plugin_I18n {

    public function load_plugin_textdomain() {
        load_plugin_textdomain(
            'mon-plugin',
            false,
            dirname( plugin_basename( __FILE__ ) ) . '/../languages/'
        );
    }
}

// Dans votre classe principale
add_action( 'plugins_loaded', array( $this->i18n, 'load_plugin_textdomain' ) );

Pour générer les fichiers .pot, .po et .mo, j’utilise WP-CLI avec la commande wp i18n make-pot qui scanne automatiquement toutes les chaînes traduisibles. L’outil la documentation officielle WordPress sur l’internationalisation détaille l’ensemble du processus. Depuis 2024, WordPress supporte aussi nativement les fichiers .l10n.php qui sont plus performants que les anciens fichiers .mo : le chargement est jusqu’à 3,5 fois plus rapide selon les benchmarks de l’équipe core.

Si votre plugin utilise du JavaScript (blocs Gutenberg, interfaces React), n’oubliez pas le pendant JS de l’internationalisation avec wp_set_script_translations(). C’est un oubli fréquent sur les projets qui utilisent des page builders comme Gutenberg.

Sécurité et bonnes pratiques de développement

La sécurité d’un plugin WordPress n’est pas une option, c’est une obligation. En 2025, 97 % des vulnérabilités WordPress provenaient des plugins et thèmes selon le rapport annuel de Patchstack. Voici les pratiques que j’applique systématiquement et que je considère comme non négociables.

Validation et assainissement des données : toute donnée entrante doit être nettoyée. WordPress fournit une batterie de fonctions dédiées :

// Assainir un champ texte
$nom = sanitize_text_field( $_POST['nom'] );

// Assainir un email
$email = sanitize_email( $_POST['email'] );

// Assainir une URL
$url = esc_url_raw( $_POST['url'] );

// Échapper pour l'affichage HTML
echo esc_html( $nom );
echo esc_attr( $valeur_attribut );
echo esc_url( $lien );

Nonces (jetons de sécurité) : chaque formulaire et chaque requête AJAX doit inclure un nonce que vous vérifiez côté serveur. Sans ça, votre plugin est vulnérable aux attaques CSRF :

// Créer le nonce dans le formulaire
wp_nonce_field( 'mon_plugin_save_action', 'mon_plugin_nonce' );

// Vérifier le nonce au traitement
if ( ! isset( $_POST['mon_plugin_nonce'] ) ||
     ! wp_verify_nonce( $_POST['mon_plugin_nonce'], 'mon_plugin_save_action' ) ) {
    wp_die( __( 'Vérification de sécurité échouée.', 'mon-plugin' ) );
}

Vérification des capacités : avant toute opération sensible, vérifiez que l’utilisateur a les droits nécessaires avec current_user_can(). Ne vous fiez jamais au seul fait que l’utilisateur est connecté.

Requêtes SQL préparées : si vous devez écrire du SQL brut (à éviter quand les fonctions natives suffisent), utilisez toujours $wpdb->prepare() :

global $wpdb;
$resultats = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->prefix}mon_plugin_table WHERE statut = %s AND user_id = %d",
        'actif',
        get_current_user_id()
    )
);

Préfixage systématique : toutes vos fonctions, classes, constantes et options doivent être préfixées avec un identifiant unique. C’est la seule façon d’éviter les conflits avec d’autres plugins. J’utilise le format mon_plugin_ pour les fonctions et Mon_Plugin_ pour les classes. En 2026, les namespaces PHP sont aussi une excellente option si vous ciblez PHP 8.1+.

La CNIL rappelle dans son guide RGPD pour les développeurs que tout plugin qui collecte des données personnelles doit intégrer les mécanismes de consentement et de suppression dès la conception. Si votre plugin stocke des données utilisateur, implémentez les hooks wp_privacy_personal_data_exporters et wp_privacy_personal_data_erasers.

Outils et workflow de développement en 2026

Le workflow de développement de plugins WordPress a considérablement évolué ces dernières années. Voici les outils que j’utilise quotidiennement sur mes projets.

Pour initialiser rapidement un squelette de plugin, WP-CLI reste imbattable :

# Générer le squelette complet d'un plugin
wp scaffold plugin mon-plugin --plugin_name="Mon Plugin Custom" --plugin_author="Thomas Lefèvre" --plugin_description="Description du plugin" --plugin_uri="https://example.com"

# Générer les tests PHPUnit
wp scaffold plugin-tests mon-plugin

# Générer un fichier .pot pour les traductions
wp i18n make-pot wp-content/plugins/mon-plugin/ wp-content/plugins/mon-plugin/languages/mon-plugin.pot

Côté versioning, j’utilise Git avec une branche main stable et des branches de feature. Chaque modification passe par une pull request, même quand je suis seul sur le projet. C’est une discipline qui m’a sauvé plus d’une fois. Pour la gestion de projet associée, une bonne méthode de gestion de projet fait toute la différence sur les plugins complexes.

Pour le déploiement, j’automatise avec GitHub Actions : à chaque tag de version, le workflow lance les tests, vérifie le coding standard, génère les fichiers de traduction et crée un zip prêt à installer. Sur les projets clients, je couple ça avec un déploiement automatique via SSH sur le serveur de staging.

Coûts et maintenance d’un plugin custom

Parlons argent, parce que c’est souvent le nerf de la guerre. Voici les fourchettes que je pratique et que j’observe chez mes confrères freelances en France en 2026 :

Ces tarifs incluent le développement, les tests, la documentation technique et la livraison sur Git. Ils n’incluent pas le design UX/UI qui est un poste séparé. Je facture personnellement à 450 € HT/jour en 2026 pour du développement WordPress custom.

La maintenance est un sujet que beaucoup de clients sous-estiment. Un plugin custom nécessite des mises à jour régulières pour rester compatible avec les nouvelles versions de WordPress et de PHP. Je recommande un audit trimestriel au minimum, qui comprend la vérification de compatibilité, les correctifs de sécurité et les optimisations de performance. Pour piloter cette maintenance dans la durée, suivre les étapes de la gestion de projet aide à ne rien oublier.

Un point que je soulève systématiquement en avant-vente : le coût de ne pas maintenir est toujours supérieur au coût de maintenir. Un plugin abandonné pendant deux ans peut nécessiter une réécriture complète lors d’une mise à jour majeure de WordPress, là où un suivi régulier n’aurait coûté que quelques heures par trimestre.

Publier votre plugin sur le répertoire officiel WordPress

Si votre plugin a une utilité générique, le publier sur le répertoire officiel WordPress.org peut avoir un vrai intérêt : visibilité, crédibilité, et retours de la communauté. Mais le processus de review est devenu plus strict ces dernières années. Voici ce que j’ai appris en publiant et en maintenant trois plugins sur le répertoire.

Les critères obligatoires pour l’acceptation :

• Respecter les WordPress Coding Standards (WPCS) : indentation, nommage, documentation inline
• Licence GPL v2 ou compatible : votre code ET toutes ses dépendances
• Aucune obfuscation de code : tout doit être lisible et auditable
• Pas de liens d’affiliation cachés, pas de tracking utilisateur sans consentement explicite
• Le plugin doit fonctionner immédiatement après activation sans nécessiter de compte externe obligatoire
• Fichier readme.txt conforme au format standard WordPress avec changelog, FAQ et captures d’écran

Le délai de review initial varie entre 5 et 15 jours ouvrés en 2026. L’équipe de review envoie souvent des demandes de correction ; ne les prenez pas personnellement, c’est le processus normal. Une fois accepté, les mises à jour se font via SVN (oui, en 2026, le répertoire WordPress utilise encore SVN) ou via un déploiement automatisé depuis GitHub.

Mon conseil : même si vous ne publiez pas votre plugin, développez-le comme si vous alliez le faire. Cela vous force à respecter les bonnes pratiques, à documenter votre code, et à penser à l’internationalisation dès le départ. C’est exactement le genre de rigueur qui distingue un plugin amateur d’un plugin professionnel.

Pour les développeurs qui veulent aller plus loin, combiner un plugin custom avec une bonne gestion de projet informatique et un hébergement adapté, éventuellement dans le cloud, permet de livrer des solutions WordPress vraiment robustes à ses clients.