Agence WordPress à Paris

Oui pour les sites éditoriaux, institutionnels et vitrines, à condition de maîtriser les extensions, la structure de contenu et la sécurité.

WordPress fait tourner une part considérable du web et ce n’est pas un hasard : pour publier du contenu, gérer des gabarits et confier l’administration à une équipe non technique, il est difficile à battre. Les critiques qu’on lui adresse portent presque toujours sur son usage plutôt que sur l’outil — un site lent et vulnérable est un site à trente extensions non maintenues, pas une conséquence du socle.

Là où nous ne le recommandons pas : une application métier avec des droits fins et des règles de calcul, où il faudrait détourner le modèle de contenu ; et un catalogue e-commerce complexe, où une solution dédiée est plus directe.

Trois conditions rendent un WordPress d’entreprise durable : un nombre d’extensions maîtrisé et justifié une par une, des types de contenu structurés plutôt que des pages libres, et un contrat de mise à jour. Sans la troisième, le site se dégrade en dix-huit mois.

Selon le besoin. Un constructeur facilite l’autonomie éditoriale mais peut alourdir les pages ; un système de blocs maîtrisé est souvent préférable.

Le compromis est réel et mérite d’être posé plutôt que tranché par principe. Un constructeur donne à votre équipe une liberté de mise en page immédiate, sans nous appeler. Il produit en retour un balisage plus lourd, une dépendance forte à une extension tierce, et une difficulté à maintenir la cohérence visuelle — au bout d’un an, vos pages ne se ressemblent plus.

Notre préférence va à l’éditeur de blocs natif avec des blocs développés pour vos besoins : chaque bloc correspond à un type de contenu de votre site, il est cohérent par construction, et il ne dépend d’aucun éditeur tiers. La liberté est moindre, la durabilité meilleure.

Quand l’autonomie de mise en page est une exigence forte — une équipe marketing qui produit des pages de campagne chaque mois —, nous installons un constructeur et nous encadrons son usage par des gabarits verrouillés. C’est un choix documenté, pas un défaut.

Oui. Des blocs dédiés permettent de publier des contenus structurés et cohérents sans dépendre d’un empilement d’extensions.

Un bloc sur mesure encapsule un type de contenu de votre site : une fiche d’équipe, un tableau de tarifs, un témoignage, un bloc de chiffres clés, un encadré d’avertissement. La personne qui publie remplit des champs plutôt que de reconstruire une mise en page, ce qui garantit le rendu et l’accessibilité.

Le gain se voit à l’usage sur trois plans. La cohérence, parce qu’un bloc ne peut pas être mal assemblé. La réutilisation, parce que les données saisies peuvent alimenter un autre gabarit — une fiche d’équipe apparaît sur la page équipe et sur les articles de la personne. Et la maintenance, parce qu’un changement de style s’applique partout d’un coup.

Compter une demi-journée à deux jours par bloc selon sa complexité. Sur un site d’entreprise, six à dix blocs couvrent l’essentiel des besoins éditoriaux, et c’est un investissement qui remplace trois ou quatre extensions.

Lorsque le contenu doit alimenter plusieurs interfaces ou qu’une architecture front spécifique est nécessaire. Pour un site classique, l’approche standard reste plus simple.

Le cas qui le justifie vraiment : un même contenu consommé par un site public, une application mobile et un écran en point de vente. Là, WordPress devient une source de contenu et chaque interface se développe séparément — c’est cohérent et c’est ce pour quoi cette architecture existe.

Les cas où elle est choisie sans raison sont plus nombreux. Découpler pour la performance n’est presque jamais nécessaire : un WordPress avec un cache de page en amont sert des pages en quelques dizaines de millisecondes. Découpler pour la modernité ajoute une couche à maintenir, un déploiement à orchestrer, et fait perdre l’aperçu, l’édition en contexte et une partie de l’écosystème d’extensions.

Le coût est concret : comptez trente à cinquante pour cent de plus à la construction, et une dépendance à deux compétences au lieu d’une pour la maintenance. Nous le disons avant, pas après.

Par des mises à jour régulières, la limitation des extensions, des accès restreints, une authentification renforcée et une surveillance des anomalies.

Trois mesures empêchent l’essentiel des intrusions que nous constatons, et aucune n’est coûteuse. Les mises à jour du cœur et des extensions, appliquées rapidement pour les correctifs de sécurité — la plupart des sites compromis l’ont été par une faille publiée depuis des semaines. L’authentification à deux facteurs sur les comptes d’administration. Et la suppression des comptes inutilisés, notamment ceux des anciens prestataires.

S’y ajoutent des réglages qui coûtent une heure : interdire l’édition de fichiers depuis l’administration, limiter les tentatives de connexion, désactiver l’énumération des utilisateurs, et restreindre l’exécution de code dans le dossier des téléversements.

Ce qui ne protège pas, malgré sa réputation : changer l’adresse de connexion. Cela réduit le bruit dans les journaux et rien d’autre.

Et une sauvegarde externalisée et réellement restaurée, parce que la question n’est pas seulement d’empêcher mais de pouvoir revenir.

Oui après audit du thème, des extensions, de la structure de contenu, des performances et de l’état de sécurité.

L’audit cherche d’abord ce qui bloquera : un thème dont les sources ne sont pas fournies, des modifications faites directement dans le cœur ou dans un thème parent, et des extensions abandonnées par leur éditeur. Ces trois éléments déterminent si le site peut évoluer ou s’il faut envisager une refonte.

Il regarde ensuite la structure de contenu, qui est le point le plus révélateur. Un site dont tout est en pages libres avec des blocs assemblés à la main ne se refond pas facilement, parce qu’il n’y a pas de données à reprendre — seulement des mises en page. Un site avec des types de contenu structurés se migre presque mécaniquement.

Et l’état de sécurité, en dernier mais avec priorité de traitement : version du cœur, extensions à failles connues, comptes actifs, présence de fichiers inhabituels. Un site déjà compromis se nettoie avant toute autre intervention, et cela se chiffre à part.

Oui. Les types de contenu, les champs et les gabarits sont pensés pour rester compréhensibles par vos équipes, avec formation et documentation.

Ce qui rend un WordPress administrable n’est pas l’outil mais la modélisation. Un champ nommé « texte 2 » sur un gabarit oblige à deviner ; un champ nommé « accroche affichée sous le titre » se remplit sans hésiter. Nous nommons donc les champs du point de vue de la personne qui publie, avec une aide contextuelle courte, et nous masquons ce qui ne la concerne pas.

Deux règles complètent cela. Les champs obligatoires le sont réellement, pour qu’une page ne puisse pas être publiée incomplète. Et l’aperçu correspond au rendu final, ce qui suppose de ne pas construire les gabarits d’une manière que l’éditeur ne sait pas prévisualiser.

La formation se tient avant la mise en production, sur votre site réel, avec les personnes concernées. Le support remis est une suite de procédures illustrées de vos propres écrans — c’est ce qui sert à quelqu’un arrivé six mois plus tard.

Les correctifs de sécurité sont appliqués rapidement. Les mises à jour majeures passent par un environnement de préparation avec vérification des gabarits et des fonctions.

Le rythme : mensuel pour les mises à jour ordinaires, immédiat pour les correctifs critiques. Chaque intervention suit la même séquence — sauvegarde, application sur l’environnement de préparation, contrôle des gabarits et des formulaires, puis production. Sauter l’étape de préparation fait gagner une heure et coûte une journée les fois où une extension casse un affichage.

Ce qui casse le plus souvent, par ordre : une extension de formulaire, une extension de mise en cache mal reconfigurée, et un conflit entre deux extensions qui touchent au même endroit. Nous contrôlons donc systématiquement les formulaires et les pages de rayon après chaque vague.

Un point à vérifier dans tout contrat, y compris le nôtre : ce qui se passe quand une mise à jour casse le site. Le délai de rétablissement et la responsabilité doivent être écrits avant, sinon la discussion a lieu au pire moment.