Qu'est-ce que les shortcodes WordPress ? Un guide pratique

Les shortcodes WordPress sont de courts extraits de texte entourés de crochets (comme [contact-form] ou [gallery ids="1,2,3"]) que WordPress remplace par du contenu dynamique lors du rendu d'un article ou d'une page. Ils ont été introduits dans WordPress 2.5 (2008) et sont devenus, pendant plus d'une décennie, la façon dominante dont les plugins ajoutaient du contenu complexe au contenu. Depuis le déploiement de l'éditeur de blocs Gutenberg dans WordPress 5.0 (2018), les shortcodes ont un successeur : les blocs. Mais les shortcodes ne vont pas disparaître. Ils fonctionnent toujours, des millions de sites en dépendent, et de nombreux plugins continuent de les livrer en complément ou à la place des blocs.

À quoi ressemble un shortcode WordPress ?

Le shortcode de base est un nom entre crochets :

[gallery]

WordPress voit cela dans le contenu de l'article, cherche le handler enregistré pour gallery, exécute la fonction PHP, et remplace la balise par le HTML que le handler émet. Le visiteur voit une galerie ; l'éditeur voit [gallery].

Les shortcodes peuvent prendre des paramètres (appelés attributs) :

[gallery ids="42,43,44" columns="3" link="file"]

Et ils peuvent envelopper du contenu (appelés shortcodes englobants) :

[highlight color="yellow"]Texte important[/highlight]

Le handler du shortcode reçoit les attributs et le contenu interne, les traite en PHP, et retourne le HTML à insérer dans la page. Le visiteur ne voit jamais les crochets ; il voit la sortie rendue.

Quelle est la différence entre un shortcode et un bloc Gutenberg ?

Les deux produisent du contenu dynamique ; ils diffèrent dans où et comment ce contenu est généré.

• Les shortcodes sont côté serveur. La balise entre crochets reste dans le contenu de l'article stocké en base de données. Quand la page est demandée, WordPress parse le contenu, trouve le shortcode, exécute le handler PHP, et substitue la sortie. La vue éditeur montre toujours la syntaxe brute avec crochets.
• Les blocs sont stockés comme HTML rendu (avec des commentaires de métadonnées). Quand vous sauvegardez un article dans l'éditeur de blocs, le plugin du bloc génère le HTML final et le stocke en base de données. L'éditeur montre un aperçu live du bloc rendu, pas une balise. En frontend, pas de PHP exécuté pour rendre la plupart des blocs ; le HTML est servi directement.

Conséquences pratiques :

• Performance. Les blocs sont plus rapides en frontend parce qu'il n'y a pas d'étape parse-et-remplace. Les shortcodes déclenchent un scan regex de chaque article à chaque rendu.
• Expérience d'édition. Les blocs montrent à quoi ressemblera la sortie rendue pendant que vous éditez. Les shortcodes ne montrent que la balise ; vous prévisualisez le résultat.
• Portabilité. Si vous désactivez le plugin qui fournit un bloc, le HTML stocké reste généralement visible (figé à la version lors du dernier enregistrement). Si vous désactivez le plugin qui fournit un shortcode, la balise entre crochets reste dans le contenu comme texte brut, ce qui paraît généralement cassé.
• Réutilisabilité. Les shortcodes peuvent être ajoutés partout où PHP s'exécute, y compris dans les widgets, templates et extraits. Les blocs sont conçus pour la zone de l'éditeur de blocs, bien que les "Blocs Réutilisables" et le mouvement FSE (full-site editing) comblent cet écart.

Quels shortcodes intégrés à WordPress sont encore livrés dans le core ?

Le core WordPress a historiquement livré une poignée de shortcodes. À 2026, les survivants dans le codebase :

• [gallery] — Galerie d'images. Toujours utilisé par l'éditeur classique et comme fallback quand le bloc Galerie est converti.
• [caption] — Enveloppe une image avec une légende. Largement remplacé par le bloc Image mais toujours émis dans certains flux.
• [audio] et [video] — Lecteur HTML5 natif pour les médias auto-hébergés.
• [embed] — Force une URL à être intégrée via le handler oEmbed. Rarement nécessaire car WordPress auto-intègre la plupart des URLs.
• [playlist] — Playlists audio et vidéo. Usage de niche.

La grande majorité des shortcodes dans tout vrai site WordPress vient des plugins et thèmes, pas du core.

Quels types de plugins utilisent des shortcodes ?

Cinq catégories couvrent presque tout l'usage réel des shortcodes :

• Formulaires de contact. Contact Form 7 ([contact-form-7 id="123"]), WPForms, Gravity Forms et Formidable exposent tous des formulaires via shortcodes. Même quand ces plugins offrent aussi des blocs Gutenberg, le shortcode reste supporté pour la rétrocompatibilité.
• E-commerce. WooCommerce utilise des shortcodes pour le Panier, le Checkout, Mon Compte et les listings produits ([products limit="4"]). L'éditeur de blocs a maintenant des blocs équivalents, mais les shortcodes dominent toujours parce que la plupart des thèmes ont été construits autour d'eux.
• Page builders (en mode legacy). L'ancien Visual Composer, WPBakery et similaires produisent des shortcodes massifs imbriqués quand utilisés dans l'éditeur classique. Désactiver le page builder laisse un mur de balises [vc_row][vc_column]... comme texte brut dans l'article — un fameux problème de lock-in.
• Tableaux de prix, sliders, accordéons. La plupart des plugins de "widget de contenu" (Soliloquy, Smart Slider, Easy Pricing Tables) ont historiquement été livrés comme shortcodes. Beaucoup sont encore activement maintenus mais ont ajouté des blocs.
• Sites de membres et apprentissage. MemberPress, LearnDash et similaires restreignent le contenu avec des wrappers de shortcode comme [restrict role="member"]...[/restrict].

Comment un shortcode fonctionne-t-il réellement sous le capot ?

Trois lignes de code de plugin créent un shortcode. Cet exemple minimal enregistre un shortcode qui émet un surlignage jaune :

add_shortcode('highlight', function ($atts, $content = null) {
    $atts = shortcode_atts([
        'color' => 'yellow',
    ], $atts, 'highlight');

    return '<mark style="background:' . esc_attr($atts['color']) . '">' . do_shortcode($content) . '</mark>';
});

Ce qui se passe quand WordPress rend [highlight color="pink"]Bonjour[/highlight] :

1. WordPress exécute le filtre the_content, qui inclut do_shortcode().
2. do_shortcode() utilise une regex pour trouver les balises de shortcode dans le contenu de l'article.
3. Pour chaque correspondance, il appelle le handler enregistré avec les attributs (['color' => 'pink']) et le contenu interne ('Bonjour').
4. Le handler retourne une chaîne, qui remplace la balise du shortcode dans la sortie.
5. Le contenu de l'article est alors rendu au navigateur avec la balise substituée.

Le parsing regex à chaque rendu d'article est le coût de performance. Sur un site avec des milliers d'articles, sans cache et avec des shortcodes dans chaque article, cela s'additionne. Un cache de page (Redis, WP Super Cache) corrige cela en stockant le HTML final rendu et en sautant le parse.

Quand devrais-je encore utiliser des shortcodes en 2026 ?

Trois cas légitimes :

• Rétrocompatibilité. Si votre site utilise déjà des shortcodes de Contact Form 7, WooCommerce ou tout plugin établi, continuez à les utiliser. Convertir en masse de vieux articles en blocs est un projet de plusieurs jours avec peu de gain.
• En dehors de l'éditeur de blocs. Les widgets (dans les zones de widgets classiques), extraits, loops de types d'articles personnalisés, contenu de page builder, et emails envoyés via les templates Mailchimp acceptent encore les shortcodes mais pas les blocs. Les shortcodes fonctionnent dans tout contexte où do_shortcode() peut être appelé.
• Templates et code de thème. Mettre echo do_shortcode('[my-form id="3"]'); dans un template PHP est une façon d'une ligne d'injecter la sortie d'un plugin. Les blocs nécessiteraient un rendu de bloc côté serveur, ce qui est plus de code.

Pour une fonctionnalité vraiment nouvelle sur un nouveau site, préférez les blocs. Ils sont la direction du core WordPress, ont une meilleure expérience d'édition, et évitent l'overhead de parsing des shortcodes.

Qu'est-ce que le "shortcode bloat" et pourquoi est-ce important ?

Le shortcode bloat survient quand un site dépend de dizaines de shortcodes de plugins inactifs ou désactivés. Deux modes d'échec suivent :

• Plugin désactivé mais les balises restent. Vous désactivez un plugin de slider pour tester quelque chose. Chaque page qui avait [slider id="3"] affiche maintenant le texte littéral "[slider id="3"]" au lieu d'un slider. La correction est de réactiver le plugin ou de retirer manuellement toutes les balises de shortcode de la base de données, ce qui est fastidieux.
• Migration de page builder. Un site construit en Visual Composer ou WPBakery contient des shortcodes imbriqués comme [vc_row][vc_column width="1/2"][vc_column_text]Bonjour[/vc_column_text][/vc_column][/vc_row]. Changer de thème ou désactiver le builder révèle tout cela comme texte brut. C'est la source du point de douleur "je ne peux pas migrer mon site vers Gutenberg" qui a piégé des milliers de sites.

La prévention pragmatique : choisir des plugins sur lesquels vous vous engagez à long terme, et préférer des plugins qui supportent aussi les blocs pour pouvoir migrer graduellement. Pour les sites construits avant 2018, attendez-vous à un vrai projet de migration plutôt qu'à un basculement propre.

Puis-je créer mon propre shortcode sans écrire de plugin ?

Oui, trois manières :

1. Dans le functions.php d'un thème enfant. Ajoutez l'appel add_shortcode(). Le shortcode devient disponible partout sur le site. Fonctionne mais le shortcode est lié à ce thème ; changez de thème et le shortcode disparaît.
2. Dans un mu-plugin custom. Créez wp-content/mu-plugins/my-shortcodes.php et mettez vos appels add_shortcode() dedans. Survit aux changements de thème et à la plupart des mises à jour. La solution plus propre.
3. Via un plugin "Code Snippets". Des plugins comme Code Snippets ou WPCode vous permettent d'ajouter du PHP via l'UI admin. Pratique si vous ne pouvez pas éditer les fichiers, mais ajoute une dépendance niveau admin pour du code qui idéalement vit dans des fichiers.

Quelles sont les erreurs courantes avec les shortcodes ?

• Oublier do_shortcode() sur le contenu interne. Si votre shortcode enveloppe du contenu (shortcode englobant), vous devriez appeler do_shortcode($content) sur la partie interne pour que les shortcodes imbriqués fonctionnent. Sans cela, [outer][inner][/outer] ne rend que le shortcode externe et laisse [inner] comme texte brut.
• Faire echo dans le handler. Les handlers de shortcode doivent retourner leur sortie, pas faire echo. Un shortcode echo se rend avant le contenu dans lequel il est intégré, cassant la mise en page de façons subtiles.
• Oublier esc_attr() sur les attributs. Sans échappement, les valeurs d'attribut fournies par l'utilisateur peuvent s'échapper du HTML et créer des vulnérabilités XSS. Échappez toujours ce que vous émettez.
• Shortcodes dans des widgets qui ne les exécutent pas. Certains types de widgets classiques (comme le widget Text basique pré-WordPress 4.9) n'auto-exécutent pas les shortcodes. Correction : add_filter('widget_text', 'do_shortcode');.
• Balises dans d'autres balises causant de la confusion de parsing. Un attribut de shortcode contenant un caractère crochet ([shortcode label="Click [here]"]) confond le parser. WordPress gère beaucoup de cas mais pas tous ; utiliser des entités HTML ([ et ]) est le workaround sûr.
• Ajouter des shortcodes à do_shortcode récursivement. À l'intérieur d'un handler de shortcode, appeler do_shortcode() sur du contenu qui contient le même shortcode crée une boucle infinie. WordPress a des gardes contre cela mais le symptôme est une page blanche ou une erreur d'épuisement de mémoire.

Comment trouver chaque shortcode utilisé sur mon site ?

Trois approches rapides :

1. Recherche en base de données. Exécutez une requête SQL contre wp_posts : SELECT DISTINCT REGEXP_SUBSTR(post_content, '\\[[a-z_-]+') FROM wp_posts WHERE post_status = 'publish';. Liste chaque balise de shortcode qui apparaît dans le contenu publié.
2. WP-CLI. wp shortcode list montre chaque handler de shortcode enregistré. Comparez à la liste de la base de données pour trouver les shortcodes utilisés mais qui n'ont plus de handler actif (probablement d'un plugin désactivé).
3. Les plugins type "Shortcode Cleaner" ou "Find My Blocks". Scannent le contenu pour l'usage de shortcodes et blocs. Utile avant de désactiver un plugin pour voir à quel point ses shortcodes sont largement utilisés.

Qu'en est-il de la sécurité ?

Les shortcodes eux-mêmes ne sont pas insécurisés ; la question est ce que le handler fait avec les attributs. Deux modèles de menace :

• Un utilisateur non fiable soumet du contenu contenant des shortcodes. Si un contributeur ou abonné peut soumettre des articles et que le shortcode exécute du code côté serveur (comme [exec command="..."] d'un plugin de dev), c'est un chemin d'exécution de code arbitraire. Le core WordPress retire les shortcodes du contenu soumis par des utilisateurs à privilèges bas par défaut ; ne défaites pas cette protection.
• Les attributs de shortcode sont émis de manière non sûre. Un shortcode mal écrit pourrait faire echo de [badge text="..."] directement dans la page sans échappement, permettant à un admin qui édite un article d'injecter des balises script. Restez à l'édition réservée aux admins pour les articles, et échappez toujours les valeurs d'attribut en écrivant des shortcodes custom.

Ce que vérifie InspectWP

Les shortcodes ne font pas directement partie d'un rapport de sécurité ou de performance InspectWP, mais leurs effets apparaissent à plusieurs endroits. Un site avec des shortcodes de plugins désactivés a typiquement des constats de "layouts cassés" (texte rendu contenant des crochets). Un site avec une utilisation lourde de shortcodes sans cache de page apparaît comme TTFB lent. Et un site où des shortcodes Visual Composer ou WPBakery fuient dans le HTML rendu (parce que le page builder est cassé ou désactivé) apparaît comme des erreurs de rendu et des violations d'accessibilité. Le pattern recommandé en 2026 est de continuer à utiliser les shortcodes pour des raisons legacy, préférer les blocs pour le nouveau contenu, et auditer votre site périodiquement pour les shortcodes dont les handlers ne sont plus enregistrés.