Cacher la barre d’admin WordPress selon le rôle

Si vos clients vous appellent parce que “la barre noire en haut” gâche leur site, vous avez déjà rencontré le problème : la barre d’admin WordPress (Admin Bar) s’affiche pour les utilisateurs connectés, même quand ils n’ont rien à faire dans l’administration.

Sur WordPress 6.9.4 (avril 2026), vous pouvez masquer cette barre proprement, sans bidouiller le cœur (core) et sans casser l’éditeur de blocs. Le but ici : la masquer pour certains rôles (abonné, contributeur, parfois auteur), tout en la gardant pour les administrateurs/éditeurs.

Le problème / Le besoin

La barre d’admin WordPress s’affiche en haut du site pour tout utilisateur connecté qui a l’option “Afficher la barre d’outils lors de la consultation du site” activée dans son profil. Pour un blog perso, ce n’est pas grave. Pour un site client, une boutique, un espace membre, c’est souvent vécu comme un “élément technique” inutile, voire anxiogène.

Ce tutoriel s’adresse aux blogueurs débutants (et aux personnes qui gèrent un site pour d’autres) qui veulent :

Masquer la barre d’admin sur le front-end pour certains rôles (ex. abonnés).
Éviter les effets de bord (éditeur, barre d’outils dans wp-admin, permissions).
Faire ça proprement avec un hook (action/filtre) WordPress, compatible WordPress 6.9.4+ et PHP 8.1+.

Où coller le code (recommandation) : créez un petit plugin “maison” (ou un mu-plugin). Évitez de mettre ce snippet dans functions.php si vous débutez : un changement de thème peut le faire disparaître. Je vous donne les trois options plus bas, mais je conseille un plugin custom.

Les fonctions et hooks WordPress que vous allez utiliser (avec doc officielle) :

show_admin_bar() : active/désactive l’affichage de la barre d’admin.
Filtre show_admin_bar : permet de décider dynamiquement si la barre doit s’afficher.
current_user_can() : vérifie une capacité (capability) de l’utilisateur courant.
wp_get_current_user() : récupère l’objet utilisateur courant (dont ses rôles).
is_admin() : détecte si on est dans l’admin (wp-admin) ou non.

Prérequis (version et contexte)

Tout ce qui suit cible WordPress 6.9.4 et PHP 8.1+. Si vous suivez un ancien tutoriel qui parle de wp_before_admin_bar_render pour “désactiver” la barre, vous verrez vite ses limites : ce hook sert surtout à modifier le contenu de la barre, pas à la supprimer proprement.

Résumé rapide

On va masquer la barre d’admin sur le front-end selon le rôle (ou mieux : selon une capacité).
On utilisera le filtre show_admin_bar (solution propre, maintenable).
On évitera de masquer la barre dans wp-admin (sinon certains écrans deviennent pénibles).
On fournira une variante “simple (rôle)” et une variante “pro (capability)”.
On ajoutera une option facile pour désactiver la barre uniquement sur certaines pages (ex. page “Mon compte”).

Quand utiliser cette solution

Vous avez des abonnés (newsletter, espace membre) qui se connectent uniquement au front-end.
Vous avez des auteurs qui publient via un formulaire front-end, pas via wp-admin.
Vous utilisez un plugin de membership / LMS / forum et vous voulez une interface “propre”.
Vous avez un site client avec Elementor/Divi/Avada : la barre d’admin “décale” parfois le header sticky, et ça génère des tickets support.

Quand ne PAS utiliser cette solution

Vous cherchez à sécuriser votre site : masquer la barre d’admin n’empêche pas l’accès à /wp-admin. Pour ça, il faut gérer les capacités, les rôles, et éventuellement restreindre l’accès (plugin de sécurité, règles serveur).
Vous voulez empêcher un rôle d’accéder à l’admin : utilisez des capacités (capabilities) et/ou redirections contrôlées, pas juste un masquage visuel.
Vous avez une équipe éditoriale : la barre d’admin est un outil de productivité (édition rapide, accès au tableau de bord). La masquer à tout le monde est souvent contre-productif.

Prérequis / avant de commencer

Sauvegarde et environnement

Faites une sauvegarde (fichiers + base de données) avant de toucher au code.
Testez si possible sur une préproduction (staging). J’ai souvent vu un simple point-virgule manquant mettre un site en erreur fatale.
Vérifiez votre version PHP : PHP 8.1 minimum recommandé. Beaucoup d’erreurs “bizarres” viennent d’un PHP trop ancien.

Où mettre le code (3 options)

mu-plugin (idéal) : le code est chargé automatiquement et ne dépend pas du thème. Chemin : wp-content/mu-plugins/.
plugin custom : recommandé si vous voulez pouvoir activer/désactiver proprement. Chemin : wp-content/plugins/.
thème enfant : fichier functions.php du thème enfant. Ça marche, mais si vous changez de thème, vous perdez le comportement.

Outils utiles

Un accès FTP/SFTP ou le gestionnaire de fichiers de votre hébergeur.
Un éditeur de code (VS Code).
Un plugin de logs (optionnel) si vous dépannez souvent.

Rappel sécurité

On ne modifie jamais les fichiers du cœur WordPress. Et on ne “cache” pas une fonctionnalité en pensant que ça sécurise : c’est du cosmétique. Pour la sécurité, référez-vous aux capacités et à la gestion des accès.

L’approche naïve (et pourquoi l’éviter)

Voici un snippet que je vois encore passer (ou des variantes) :

<?php
// ❌ Exemple naïf : désactive la barre d'admin pour tout le monde, partout.
add_filter('show_admin_bar', '__return_false');

Pourquoi c’est un problème :

Vous masquez la barre pour les administrateurs aussi, donc vous perdez un raccourci utile.
Vous ne distinguez pas le front-end de wp-admin. Ça peut gêner des workflows (édition, profil, etc.).
Vous n’avez aucune logique métier : pas de rôles, pas de capacité, pas d’exception.

Autre approche naïve : masquer en CSS.

/* ❌ Cache visuellement seulement, sans empêcher le markup ni les ajustements de layout */
#wpadminbar { display: none !important; }
html { margin-top: 0 !important; }

Pourquoi je l’évite : WordPress ajoute des marges/offsets pour la barre, certains thèmes/page builders gèrent ça différemment, et vous vous retrouvez avec des headers qui “sautent”. Et surtout : la barre est toujours générée (moins propre, parfois plus de conflits).

La bonne approche — tutoriel pas à pas

On va utiliser le filtre show_admin_bar. Un filtre (filter hook) est un point d’extension où WordPress vous laisse modifier une valeur (ici : afficher la barre ou non). À l’inverse, une action (action hook) sert à déclencher du code à un moment donné, sans forcément renvoyer une valeur.

Étape 1 — Créer un plugin minimal (recommandé)

Créez un fichier :

wp-content/plugins/bpcab-masquer-admin-bar/bpcab-masquer-admin-bar.php

Collez-y le code de l’étape 3 (je vous le donne juste après). Ensuite, allez dans Extensions > Installées et activez-le.

Étape 2 — Choisir la règle : rôle ou capacité

Deux manières de décider :

Par rôle (subscriber, contributor, author…) : simple à comprendre, mais moins flexible si un plugin modifie les rôles.
Par capacité (ex. edit_posts, manage_options) : plus robuste. WordPress fonctionne surtout par capacités. Un rôle n’est qu’un “pack” de capacités.

Dans mon expérience, la règle la plus stable pour un blog : afficher la barre uniquement aux utilisateurs capables d’éditer du contenu (ex. edit_posts). Comme ça, les abonnés ne la voient pas, les auteurs/éditeurs oui.

Étape 3 — Ajouter le filtre show_admin_bar

On va :

Ne rien changer dans wp-admin (on laisse l’admin tranquille).
Masquer la barre sur le front-end si l’utilisateur n’a pas la capacité choisie.

<?php
/**
 * Plugin Name: BPCAB - Masquer la barre d’admin selon le rôle/capacité
 * Description: Masque la barre d’admin sur le front-end pour certains utilisateurs (WP 6.9.4+, PHP 8.1+).
 * Version: 1.0.0
 * Author: Votre Nom
 * License: GPL-2.0-or-later
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit; // Sécurité : empêche l'accès direct au fichier.
}

/**
 * Décide si la barre d'admin doit être affichée.
 *
 * @param bool $show Valeur actuelle (WordPress/Plugins).
 * @return bool
 */
function bpcab_masquer_admin_bar_selon_capacite( $show ) {
	// Ne pas toucher aux écrans d'administration.
	if ( is_admin() ) {
		return $show;
	}

	// Si l'utilisateur n'est pas connecté, aucune barre de toute façon.
	if ( ! is_user_logged_in() ) {
		return $show;
	}

	/**
	 * Règle principale :
	 * - On affiche la barre uniquement si l'utilisateur peut éditer des articles.
	 * - Les abonnés (subscriber) ne l'ont pas, en général.
	 *
	 * Documentation : https://developer.wordpress.org/reference/functions/current_user_can/
	 */
	if ( current_user_can( 'edit_posts' ) ) {
		return $show; // On respecte la préférence utilisateur si WP la gère.
	}

	// Sinon, on masque.
	return false;
}
add_filter( 'show_admin_bar', 'bpcab_masquer_admin_bar_selon_capacite', 20 );

Pourquoi la priorité 20 ? Parce que certains plugins ajoutent aussi ce filtre. En mettant 20, vous passez après la valeur par défaut, sans être “trop agressif”. Si un plugin force false à 999, il gagnera quand même : on verra ça en dépannage.

Étape 4 — Tester avec un compte “Abonné”

Créez un utilisateur “abonné”.
Connectez-vous avec ce compte.
Visitez une page du site (front-end) : la barre doit être absente.
Connectez-vous avec un “auteur” : la barre doit être présente.

Code complet

Voici une version plus complète, avec :

une liste de rôles à masquer (option simple),
une règle par capacité (option robuste),
une exception par page (ex. ne jamais afficher sur “Mon compte”),
un mode “debug” minimal (facultatif) via error_log.

Où coller ce code : dans un plugin custom (recommandé) ou dans un mu-plugin. Si vous choisissez functions.php, faites-le dans un thème enfant.

<?php
/**
 * Plugin Name: BPCAB - Admin Bar par rôles (front-end)
 * Description: Masque la barre d’admin WordPress pour certains rôles/utilisateurs sur le front-end. Compatible WP 6.9.4+ / PHP 8.1+.
 * Version: 1.1.0
 * Author: Votre Nom
 * License: GPL-2.0-or-later
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Activez/désactivez un petit log dans debug.log.
 * Nécessite WP_DEBUG_LOG = true dans wp-config.php.
 */
function bpcab_admin_bar_debug_enabled() : bool {
	return defined( 'WP_DEBUG' ) && WP_DEBUG && defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG;
}

/**
 * Détermine si la barre d'admin doit être masquée pour l'utilisateur courant.
 *
 * Logique (front-end uniquement) :
 * 1) Non connecté : ne rien changer.
 * 2) Admin (wp-admin) : ne rien changer.
 * 3) Exception URL/page : masquer quoi qu'il arrive (optionnel).
 * 4) Si l'utilisateur a une capacité "éditeur" : on laisse la barre.
 * 5) Sinon : on masque.
 *
 * @param bool $show Valeur actuelle.
 * @return bool
 */
function bpcab_control_show_admin_bar( $show ) {
	// 1) Admin : on ne touche pas.
	if ( is_admin() ) {
		return $show;
	}

	// 2) Non connecté : WordPress ne montrera pas la barre.
	if ( ! is_user_logged_in() ) {
		return $show;
	}

	// 3) Exceptions : pages où on masque toujours (ex : page "Mon compte").
	// Remplacez les slugs par les vôtres, ou videz le tableau si inutile.
	$always_hide_on_slugs = array( 'mon-compte', 'connexion' );

	if ( function_exists( 'is_page' ) && ! empty( $always_hide_on_slugs ) && is_page( $always_hide_on_slugs ) ) {
		if ( bpcab_admin_bar_debug_enabled() ) {
			error_log( '[BPCAB] Admin bar masquée : exception de page (slug).' );
		}
		return false;
	}

	/**
	 * 4) Stratégie robuste : capacité.
	 * - manage_options : typiquement administrateur.
	 * - edit_posts : auteurs/éditeurs (souvent).
	 *
	 * Vous pouvez ajuster selon votre site :
	 * - Pour n'afficher qu'aux admins : utilisez manage_options uniquement.
	 * - Pour afficher aux éditeurs aussi : edit_pages, edit_others_posts, etc.
	 */
	$capabilities_that_can_see = array( 'edit_posts' );

	foreach ( $capabilities_that_can_see as $cap ) {
		if ( current_user_can( $cap ) ) {
			return $show;
		}
	}

	/**
	 * 5) Stratégie simple (complément) : rôles explicitement masqués.
	 * Utile si vous avez des rôles personnalisés (membership) et que vous voulez être explicite.
	 */
	$user = wp_get_current_user();
	$roles_to_hide = array( 'subscriber', 'customer' ); // "customer" est courant avec WooCommerce.

	if ( $user instanceof WP_User && ! empty( $user->roles ) ) {
		foreach ( $user->roles as $role ) {
			if ( in_array( $role, $roles_to_hide, true ) ) {
				if ( bpcab_admin_bar_debug_enabled() ) {
					error_log( '[BPCAB] Admin bar masquée : rôle détecté = ' . $role );
				}
				return false;
			}
		}
	}

	// Par défaut, si aucune capacité n'a matché, on masque.
	return false;
}
add_filter( 'show_admin_bar', 'bpcab_control_show_admin_bar', 20 );

Explication du code

Explication simple (sans jargon)

WordPress décide d’afficher ou non la barre d’admin via une “porte” appelée show_admin_bar. On se branche dessus et on dit :

“Si vous êtes dans l’administration, je ne change rien.”
“Si vous êtes sur certaines pages, je cache.”
“Si vous avez le droit d’éditer des articles, je laisse.”
“Sinon, je cache.”

Explication technique (hooks, filtres, capacités)

Filtre show_admin_bar : c’est un hook de type filtre. WordPress lui passe une valeur booléenne (true/false). Votre fonction renvoie la valeur finale. Doc : show_admin_bar (hook).

Capacité (capability) : c’est un droit atomique, comme edit_posts. WordPress vérifie ces droits via current_user_can(). Les rôles (abonné, auteur…) ne sont qu’un ensemble de capacités.

Rôle : stocké dans l’objet utilisateur retourné par wp_get_current_user(). Je l’utilise en complément parce que beaucoup de sites ont des rôles personnalisés (membership, WooCommerce, LMS) et veulent une règle explicite.

is_admin() : malgré son nom, ça ne veut pas dire “l’utilisateur est admin”. Ça veut dire “on est dans l’interface d’administration”. Doc : is_admin().

Pourquoi je ne force pas show_admin_bar() directement

show_admin_bar() est utile, mais le filtre est plus flexible. Surtout si d’autres plugins veulent aussi influencer l’affichage. En pratique, le filtre est l’endroit le plus propre pour centraliser la règle.

Variantes et cas d’usage

Variante 1 — Masquer uniquement pour le rôle “Abonné” (ultra simple)

Si vous voulez du très simple et que votre site n’a pas de rôles custom :

<?php
if ( ! defined( 'ABSPATH' ) ) { exit; }

function bpcab_hide_admin_bar_for_subscribers( $show ) {
	if ( is_admin() || ! is_user_logged_in() ) {
		return $show;
	}

	$user = wp_get_current_user();
	if ( $user instanceof WP_User && in_array( 'subscriber', (array) $user->roles, true ) ) {
		return false;
	}

	return $show;
}
add_filter( 'show_admin_bar', 'bpcab_hide_admin_bar_for_subscribers', 20 );

Limite : si un plugin transforme “subscriber” en autre chose, votre règle ne suit pas.

Variante 2 — N’afficher la barre qu’aux administrateurs

Pratique sur des sites où seuls les admins gèrent le contenu :

<?php
if ( ! defined( 'ABSPATH' ) ) { exit; }

function bpcab_only_admins_can_see_admin_bar( $show ) {
	if ( is_admin() || ! is_user_logged_in() ) {
		return $show;
	}

	// manage_options est une capacité typiquement réservée aux admins.
	if ( current_user_can( 'manage_options' ) ) {
		return $show;
	}

	return false;
}
add_filter( 'show_admin_bar', 'bpcab_only_admins_can_see_admin_bar', 20 );

Variante 3 — Masquer selon un rôle personnalisé (membership)

Exemple : un plugin de membership crée un rôle member. Vous voulez cacher la barre pour ce rôle, mais la garder pour author et editor.

<?php
if ( ! defined( 'ABSPATH' ) ) { exit; }

function bpcab_hide_admin_bar_for_custom_role( $show ) {
	if ( is_admin() || ! is_user_logged_in() ) {
		return $show;
	}

	$user = wp_get_current_user();
	$roles_to_hide = array( 'member', 'vip_member' );

	if ( $user instanceof WP_User && array_intersect( $roles_to_hide, (array) $user->roles ) ) {
		return false;
	}

	return $show;
}
add_filter( 'show_admin_bar', 'bpcab_hide_admin_bar_for_custom_role', 20 );

Variante 4 — Masquer la barre mais garder le décalage (cas très rare)

Je le fais rarement, mais sur certains thèmes très sensibles au layout, vous pouvez préférer garder l’espace en haut. Là, on n’est plus sur “masquer la barre” mais sur “éviter que le header saute”. Ça se traite plutôt au niveau CSS du thème. Si vous en êtes là, c’est souvent le thème qui gère mal l’offset.

Compatibilité Divi 5 / Elementor / Avada

Le filtre show_admin_bar agit au niveau WordPress, donc il est compatible avec Divi 5, Elementor et Avada. Les soucis viennent plutôt de l’UI :

headers “sticky” qui se décalent quand la barre apparaît/disparaît,
barres de prévisualisation des builders qui s’ajoutent par-dessus.

Divi 5

Divi a ses propres barres en mode édition visuelle. La règle que j’applique souvent :

masquer la barre d’admin pour les rôles “client”/“abonné”,
la laisser pour les éditeurs et admins.

Le code par capacité (edit_posts) colle bien à ce besoin. Si vous avez un rôle “Client” sans capacité d’édition, il n’aura pas la barre.

Elementor

Elementor affiche des contrôles en haut quand vous éditez. Masquer la barre d’admin ne casse pas Elementor, mais évitez de masquer dans wp-admin : certains écrans de configuration et d’édition s’appuient sur des repères d’interface.

Avada (Fusion Builder)

Avada gère souvent des headers complexes. Si vous observez un “saut” du header quand vous vous connectez/déconnectez, ce n’est pas un bug de notre snippet : c’est le thème qui réagit à la présence/absence de la barre. La bonne pratique : testez connecté/déconnecté et ajustez le header sticky si nécessaire. Dans 90% des cas, le filtre suffit.

Vérifications après mise en place

Testez avec au moins 2 comptes : un admin et un abonné.
Vérifiez le front-end : aucune barre noire en haut.
Vérifiez wp-admin : la barre d’admin (ou toolbar) doit rester normale.
Testez une page critique (accueil, article, page de compte).
Si vous avez un cache (plugin/serveur/CDN), videz-le après activation.

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
La barre s’affiche encore pour les abonnés	Le code n’est pas chargé (mauvais fichier/emplacement)	Extensions > Installées : le plugin est-il activé ?	Activez le plugin, ou passez en mu-plugin
La barre a disparu même pour l’admin	Un autre snippet force `__return_false`	Recherchez `show_admin_bar` dans le thème/plugins	Supprimez l’autre snippet ou ajustez priorités
Header qui “saute” connecté/déconnecté	CSS du thème/builder sensible à l’offset	Comparez la mise en page connecté vs non connecté	Ajustez le header sticky (thème/builder), évitez CSS brutal
Erreur fatale après collage	Point-virgule/parenthèse manquante	Regardez les logs PHP / écran d’erreur	Corrigez la syntaxe, revenez à une version propre

Si ça ne marche pas

1) Vérifiez que le code est au bon endroit

Si vous l’avez mis dans functions.php : êtes-vous dans le thème enfant actif ?
Si vous l’avez mis dans un plugin : est-il activé ?
Si vous utilisez un plugin de snippets : j’ai souvent vu des snippets “désactivés” après une mise à jour ou une migration.

2) Cherchez un conflit avec un autre filtre show_admin_bar

Beaucoup de plugins ajoutent ce filtre. Pour diagnostiquer rapidement, vous pouvez temporairement changer la priorité à 999 :

<?php
add_filter( 'show_admin_bar', 'bpcab_control_show_admin_bar', 999 );

Si ça marche à 999, c’est qu’un autre code passe après vous. Ensuite, l’objectif est d’identifier qui (thème, plugin, snippet) et de décider la règle finale.

3) Videz les caches (souvent oublié)

Cache plugin (WP Rocket, LiteSpeed Cache, etc.).
Cache serveur (hébergeur).
Cache navigateur (testez en navigation privée).

4) Vérifiez la capacité choisie

Si vous utilisez edit_posts mais que vos “auteurs” n’ont pas cette capacité (rôle custom), ils perdront la barre. Dans ce cas :

soit vous changez la capacité (ex. read est trop large, évitez),
soit vous ajoutez le rôle custom dans $roles_to_hide / ou l’inverse (liste blanche).

5) Vérifiez la version PHP

Si votre hébergeur est en PHP 7.4, vous allez rencontrer des incompatibilités modernes. Référez-vous à la doc PHP : PHP Supported Versions.

Pièges et erreurs courantes

Erreur	Cause	Solution
Coller le code dans le mauvais fichier	Snippet mis dans le thème parent ou dans un plugin non activé	Utilisez un plugin custom ou un mu-plugin, et vérifiez l’activation
Erreur “Parse error: syntax error”	Parenthèse ou point-virgule manquant	Recollez le code complet, comparez ligne par ligne, utilisez un éditeur avec coloration
Confusion `is_admin()`	`is_admin()` détecte l’interface, pas le rôle admin	Utilisez `current_user_can('manage_options')` pour cibler les admins
Utiliser un hook inadapté	Utiliser une action d’admin bar render au lieu du filtre `show_admin_bar`	Branchez-vous sur `show_admin_bar` pour décider l’affichage
La barre disparaît partout (y compris pour l’admin)	Un autre snippet force `__return_false`	Recherchez `add_filter('show_admin_bar'` dans le code, supprimez le doublon
Conflit de priorité	Un plugin met une priorité plus élevée	Testez à 999, puis identifiez le plugin fautif et arbitrez la règle
Tester en production sans sauvegarde	Changement direct sur le site live	Staging + sauvegarde + déploiement
Code d’un vieux tutoriel incompatible	Snippet CSS brutal, ou logique basée sur des rôles non standards	Revenez au filtre `show_admin_bar` et à une règle par capacité
“Ça marche chez moi, pas chez le client”	Cache, CDN, ou thème différent	Test en navigation privée, purge cache, vérifier le thème actif

Conseils sécurité, performance et maintenance

Sécurité

Masquer la barre d’admin ne protège rien. Un utilisateur peut toujours tenter /wp-admin si ses capacités le permettent.
Si votre objectif est de limiter l’accès à l’admin, mettez en place une règle dédiée (capabilities, redirection, restriction d’accès). Ne mélangez pas les deux sujets.

Performance

Le filtre show_admin_bar est léger. Les appels à current_user_can() et wp_get_current_user() sont standards.
Évitez la solution CSS-only si vous cherchez un rendu propre : vous gardez du markup et des ajustements de layout.

Maintenance

Préférez une règle par capacité plutôt que par rôle, surtout si vous installez des plugins qui ajoutent des rôles.
Documentez votre choix : “barre visible si edit_posts”. Le jour où quelqu’un modifie les rôles, vous saurez quoi ajuster.
Si vous livrez ça à un client, mettez le code dans un plugin “site” (plugin custom). C’est plus durable qu’un functions.php.

Comment tester ce code proprement

Créez 3 utilisateurs : Abonné, Auteur, Administrateur.
Testez sur 3 pages : accueil, un article, une page “compte/connexion”.
Testez connecté/déconnecté, et en navigation privée.
Si vous avez un builder, testez aussi une page avec header sticky.
Activez temporairement WP_DEBUG_LOG et regardez wp-content/debug.log si vous avez activé le mode debug du plugin.

Ressources

FAQ

Est-ce que masquer la barre d’admin empêche l’accès à l’administration ?

Non. Ça masque seulement l’interface sur le front-end. L’accès à /wp-admin dépend des capacités utilisateur.

Pourquoi utiliser une capacité plutôt qu’un rôle ?

Parce que les rôles peuvent être modifiés par des plugins. Les capacités sont la “vraie” unité de permission dans WordPress. Une règle “si edit_posts alors afficher” résiste mieux aux changements.

Je veux masquer la barre uniquement sur mobile, c’est possible ?

Oui, mais ce n’est plus une décision “WordPress” : c’est du CSS (media queries). Je conseille d’abord de décider selon le rôle/capacité, puis d’ajuster le design si nécessaire.

Pourquoi ne pas juste décocher l’option dans le profil utilisateur ?

Ça marche utilisateur par utilisateur. Sur un site avec beaucoup de comptes, c’est ingérable. Et si vous créez des comptes automatiquement, vous voulez une règle globale.

Est-ce que ça casse Gutenberg / l’éditeur de blocs ?

Non, si vous limitez la règle au front-end et laissez wp-admin tranquille. C’est pour ça que le test is_admin() est là.

WooCommerce : je veux masquer la barre pour les “customers”.

Ajoutez customer dans $roles_to_hide (c’est déjà dans l’exemple complet). Gardez la règle par capacité pour le reste.

Je vois encore la barre pour certains abonnés, mais pas pour d’autres.

Deux causes fréquentes : (1) un cache qui sert une page “connectée” à l’autre utilisateur (mauvaise config), (2) un plugin qui force la barre via un filtre avec une priorité différente. Testez en navigation privée et montez la priorité à 999 pour confirmer.

Peut-on masquer la barre pour un utilisateur précis (par ID) ?

Oui. Récupérez l’utilisateur via get_current_user_id() et comparez à une liste. C’est pratique pour un compte “support” par exemple, mais évitez de multiplier les exceptions.

Est-ce que je dois régénérer les permaliens après ce changement ?

Non. On ne touche pas aux règles de réécriture (rewrite rules). Si quelqu’un vous dit de régénérer les permaliens pour ça, c’est un réflexe “fourre-tout”.

Pourquoi mon header se décale quand je me connecte ?

Parce que la barre d’admin modifie l’offset en haut de page. Une fois masquée, l’offset disparaît. Certains thèmes/builder ont des headers sticky sensibles à ce changement. La bonne correction se fait côté thème/builder (réglages sticky), pas en forçant du CSS global agressif.

Je peux mettre ce code dans un plugin de snippets ?

Oui, mais choisissez un plugin fiable, et gardez en tête qu’un snippet désactivé (ou non chargé à cause d’une erreur) fait revenir la barre. Pour un site client, un plugin custom ou un mu-plugin est plus robuste.