# Pourquoi nous avons arrêté les widgets classiques pour nos clients > Un retour d'expérience sur la bascule complète vers les blocs pour tout nouveau projet, et le seul cas où un vieux widget survit encore chez nous. - Auteur : Clément Hadrot - Publié le : 2024-04-04 - Mis à jour le : 2024-04-04 - Catégorie : Extensions - URL : https://wpmoderne.dev.wordpress-developpement.fr/extensions/pourquoi-arrete-widgets-classiques-clients/ ## L’essentiel - La zone de widgets classique n'a plus été notre choix par défaut depuis deux ans - Un seul cas technique justifie encore un widget PHP - Le gain se voit surtout côté formation des clients Il y a encore trois ans, chaque nouvelle extension maison livrée à un client embarquait presque systématiquement un ou deux widgets classiques : un bloc d'horaires d'ouverture, un formulaire de contact rapide, un flux de témoignages. C'était rapide à écrire avec l'API `WP_Widget`, prévisible, et les clients savaient s'en servir depuis des années. Aujourd'hui, ce réflexe a disparu de notre process. Ce changement ne vient pas d'un effet de mode. Il s'est imposé progressivement, projet après projet, à mesure que l'éditeur de site s'est stabilisé et que nos clients ont commencé à composer leurs pages entièrement en blocs, thèmes bloc compris. Ce billet raconte ce basculement, pas une démonstration technique de migration, mais un constat d'agence après plusieurs dizaines de projets. ## Le confort trompeur des widgets classiques L'API `WP_Widget` avait un vrai mérite : un formulaire de réglages en HTML simple, un rendu PHP prévisible, aucune notion de rendu côté client à gérer. Pour une équipe habituée au PHP pur, c'était souvent le chemin le plus court entre un besoin client et une fonctionnalité livrée. Le problème n'était pas la technique, mais l'expérience qu'elle offrait ensuite au client final. Un widget classique vit isolé dans un écran séparé de l'éditeur de contenu. Le client devait naviguer vers *Apparence > Widgets*, chercher la bonne zone, glisser le bon widget, puis revenir sur sa page pour vérifier le résultat. Ce va-et-vient perdait presque tous les clients non techniques, qui finissaient par nous solliciter pour un simple changement de texte dans un encart. ## Le déclic : composer entièrement en blocs À partir du moment où nos thèmes ont basculé vers des templates de site complets, la zone de widgets a cessé d'être le seul endroit où placer un contenu de barre latérale ou de pied de page. Un bloc personnalisé, inséré directement dans le flux de l'éditeur, offre un aperçu en temps réel, sans changer d'écran, sans recharger la page pour vérifier le rendu. > L'essentiel à retenir : La zone de widgets classique n'a plus été notre choix par défaut depuis deux ans ; Un seul cas technique justifie encore un widget PHP ; Le gain se voit surtout côté formation des clients Pour un client qui gère lui-même son contenu au quotidien, cette continuité change tout. Il compose sa page du haut vers le bas, insère le bloc d'horaires d'ouverture au même endroit que son texte, ajuste, prévisualise, publie, sans jamais quitter l'écran de l'éditeur. Le nombre de tickets de support liés à « je ne trouve pas où modifier l'encart » a chuté de façon nette après cette bascule. ## Le seul cas où un widget classique survit encore Il existe toutefois une exception que nous assumons pleinement : les thèmes clients plus anciens, non convertis en thème bloc, où la zone de widgets reste le seul point d'extension disponible dans le pied de page ou la barre latérale du thème. Réécrire entièrement un thème classique juste pour introduire des zones de blocs serait disproportionné pour certains budgets, notamment sur des sites vitrines peu évolutifs qui ne seront pas refondus avant plusieurs années. Dans ce cas précis, nous continuons à enregistrer un widget minimal, mais son rôle se limite désormais à afficher un bloc réutilisable choisi par le client dans une liste déroulante, plutôt qu'à exposer des champs de réglages complexes. Le widget devient une simple passerelle vers l'éditeur de blocs, pas un formulaire à lui seul. ### Ce que cette approche a changé dans nos livraisons - Moins de code de formulaire à écrire et à maintenir pour chaque nouvelle fonctionnalité de contenu. - Une seule interface à former auprès des clients, l'éditeur de blocs, plutôt que deux écrans distincts. - Des demandes de support en baisse sur la question récurrente de « où modifier ce contenu ». ## Ce que nous avons dû accepter de perdre Cette bascule n'a pas été indolore. Certains automatismes des widgets classiques, comme leur affichage conditionnel par type de page directement dans l'interface native, n'ont pas d'équivalent aussi simple côté blocs sans passer par des blocs conditionnels personnalisés ou par le futur système de liaison de blocs. Sur deux projets, nous avons dû construire un petit bloc dédié uniquement pour retrouver ce comportement, ce qui a demandé plus de code que l'ancien widget ne nous en coûtait. De même, certains clients très habitués à l'ancienne interface ont eu besoin d'un temps d'adaptation, notamment ceux qui géraient leur contenu depuis des années sans avoir jamais touché à l'éditeur de blocs pour autre chose que le corps de leurs articles. > Notre repère interne est simple désormais : si un thème client est déjà un thème bloc, ou en passe de le devenir, aucun nouveau widget classique n'est écrit, sans discussion. C'est la seule règle qui a vraiment simplifié nos choix d'architecture au quotidien. ## Notre verdict Arrêter les widgets classiques n'a pas été une décision technique en soi, mais une décision d'expérience client. Le code des deux approches se vaut à peu près en complexité de développement. Ce qui a changé, c'est le nombre de clics et d'écrans qu'un client non technique doit traverser pour modifier son propre contenu. Sur ce critère, les blocs ont gagné chez nous, projet après projet, et nous ne voyons pas de raison de revenir en arrière pour les nouveaux sites.