Développeur WordPress expert ce que le CMS peut vraiment faire

01

Le thème enfant surcharge les styles et templates du thème parent sans perdre les modifications aux mises à jour. Le plugin ajoute des fonctionnalités indépendamment du thème. Personnalisations visuelles : thème enfant. Fonctionnalités métier : plugin.

Oui. WordPress peut être utilisé sans Gutenberg, et c’est souvent la meilleure décision sur un site avec un builder visuel (Avada, Divi, Elementor, Bricks). Quand un builder prend en charge la totalité des layouts de page, Gutenberg crée des conflits de styles et alourdit l’interface. Je désactive Gutenberg sur tous les projets où il n’apporte pas de valeur concrète. Sur les projets Full Site Editing où le thème en a besoin, je l’utilise, mais en isolant soigneusement son scope pour éviter les interférences avec le reste du site.

Via l’API REST native ou des webhooks. Déclenchement de workflows n8n depuis des actions WordPress, ou création de contenu WordPress depuis des workflows n8n, c’est la base de l’automatisation WordPress.

Pas native. En revanche, une PWA offre une expérience proche d’une app mobile depuis le navigateur : installation sur l’écran d’accueil, notifications push. WordPress sert de backend via l’API REST. C’est ce que j’ai développé pour Les 3 Marmites en 5 jours.

Oui avec TranslatePress. La configuration du hreflang, des sitemaps multilingues et de la structure d’URLs est critique pour le SEO international, je les configure directement.

WordPress est RGPD-compatible par défaut depuis la version 4.9.6, il inclut des outils natifs pour l’export et la suppression des données personnelles. En pratique, la conformité dépend surtout de la configuration des plugins tiers : formulaires de contact, analytics, outils de chat, pixels publicitaires. Ce sont ces plugins qui collectent des données et qui doivent être correctement configurés avec consentement explicite. J’intègre systématiquement une vérification RGPD dans mes audits et mes refontes, cookies, formulaires, scripts tiers, mentions légales.

Oui. WordPress expose ses données via l’API REST ou GraphQL (WPGraphQL), tandis qu’un frontend Next.js ou Gatsby consomme ces données. C’est une architecture plus complexe, pour la plupart des projets, un WordPress classique bien optimisé reste plus adapté.

WordPress.com est une plateforme hébergée gérée par Automattic, vous créez un compte, vous avez un site en quelques minutes, mais vous êtes limité dans les plugins que vous pouvez installer, les thèmes que vous pouvez modifier et le code que vous pouvez toucher. WordPress.org, c’est le logiciel open source que vous installez sur votre propre hébergeur. Vous avez un contrôle total sur le code, les fichiers, la base de données. C’est sur WordPress.org que je travaille exclusivement, c’est la seule version qui permet de faire ce qu’on décrit sur cette page.

Ça dépend entièrement de la complexité du besoin. Un plugin simple, un custom post type avec quelques champs ACF et une page d’administration basique, se développe en 2 à 3 jours. Un plugin d’intégration API avec synchronisation en temps réel, gestion des erreurs, cache des réponses et interface d’administration complète, c’est plutôt 8 à 15 jours. Le plugin de synchronisation Amazon pour Achetez le Meilleur, catalogue de milliers de produits mis à jour chaque nuit, a pris 10 jours de développement plus 3 jours de tests et ajustements.

Oui, à condition que l’infrastructure soit dimensionnée pour ça. WordPress en lui-même n’est pas le goulot d’étranglement, c’est l’hébergement, la configuration du cache et l’optimisation des requêtes MySQL qui déterminent la capacité à encaisser du trafic. Des sites comme TechCrunch ou The New York Times ont tourné sous WordPress. Pour les projets à fort trafic, je recommande un hébergement avec cache serveur Redis ou Varnish, un CDN pour les assets statiques, et une configuration object cache pour les requêtes répétitives.