Lors du dernier WordCamp Paris, j'ai eu le plaisir de partager notre expertise sur la dette technique sur le CMS WordPress, une problématique que nous voyons tout le temps des préconisations d'audit SEO ou lors de nos prestations de création de sites. Et voici un article complet pour comprendre et anticiper tous nos choix et nos développements mis en place sur notre CMS (et sur d'autres types de sites).
La dette technique, c’est quoi ?
C’est l’ensemble des choix que l’on fait et qui provoqueront des contraintes et un coût ultérieur. En d'autres termes, vous décidez d'un développement, d'une stratégie, d'une refonte ou encore d'un contenu, et cette décision va impacter ce que vous pourrez faire dans l'avenir (ainsi que le coût, les contraintes, les délais et la faisabilité de tous vos choix futurs).
Il faut savoir que nos choix influent sur :
- les résultats de notre site Internet (conversions, positionnement en référencement naturel, image de marque, etc.) ;
- les temps de développement ;
- les compétences nécessaires pour faire évoluer ou gérer son site ;
- la maintenabilité (mises à jour, évolutions possibles, sécurité, etc.) ;
- la faisabilité des choix futurs (nouvelles fonctionnalités, nouvelle structure, etc.).
Peut-on l’éviter ?
La réponse est malheureusement non : quel que soit votre projet web (ou informatique d'ailleurs), il est impossible de ne pas avoir de dette technique. Le but, c'est de l'anticiper et de savoir la gérer au maximum, que vous soyez à votre compte ou que vous dépendiez d'une vraie DSI (direction des systèmes d'information).
D'ailleurs, une dette technique n'est pas l'apanage des sites Internet ou de l'informatique. Prenez par exemple une maison : les choix réalisés lors de la construction de celle-ci auront forcément un impact sur ce que vous pourrez faire par la suite ou non (et sur le coût de certains de vos futurs travaux).
D’où vient la dette technique ?
A vrai dire, elle vient de plusieurs choses en même temps :
- l'incompétence (mauvais référenceur, mauvais développeur, etc.)
- le manque de temps et de budget ;
- un cahier des charges mal pensé ;
- de mauvais tests (manuels ou automatisés) ;
- une documentation incomplète ou mal formulée ;
- un manque de formation ;
- le non respect des bonnes pratiques de développement ;
- des évolutions non prévues.
Parfois, on fait des choix délibérés ("pas le temps, on met en ligne le site") et parfois c'est une réelle méconnaissance ou une mauvaise anticipation du futur. Un moyen simple pour la mesurer est de faire attention à toutes les contraintes auxquelles vous êtes (ou allez être) soumis :
- des dépendances (envers une technologie, un outil, une personne, etc.) ;
- de l’insatisfaction et/ou des bugs remontés par les utilisateurs ;
- le coût et le temps des développements futurs ;
- les résultats obtenus ou non par votre projet web ;
- la complexité du code et/ou des outils ;
- le besoin grandissant de formations pour les utilisateurs tout comme pour les développeurs ;
- la trop grande centralisation de la compétence.
On peut ainsi mesurer l'évolution du pourcentage de retour négatif parmi les utilisateurs, ou encore lister le nombre de librairies ou technologies qui doivent rester en place pour que le site continue de fonctionner correctement.
On fait quoi ?
Quand on parle de dette technique, il faut agir sur plusieurs points :
- on la mesure ;
- on anticipe ;
- on constate les contraintes que chacun de nos choix peut induire ;
- et surtout, on la réduit dès que possible !
Il y a notamment une simple question à se poser systématiquement :
Si le coût est plus élevé que le retour sur investissement potentiel, votre dette technique est trop importante
Et c'est là où le bât blesse : c'est toujours dur de se dire que l'on doit tout remettre à plat (coût plus élevé à court terme) que d'essayer de "bricoler" l'existant (et le coût est quasi systématiquement plus élevé sur le long terme).
La dette technique de WordPress
WordPress, c'est de la m*****
Maintenant que nous savons ce qu'est la dette technique, il est temps de passer au cœur du sujet : de quoi parle t-on exactement quand on évoque la dette technique sur un CMS tel que WordPress ?
Les choix faits sur cet outil (thème utilisé, extensions installées, prestataires sélectionnés, fonctionnalités personnalisées, formations menées ou non, etc.) vont impacter la vie de votre site. Cette dette technique va ainsi provoquer de nombreuses problématiques sur WordPress :
- un site lent ;
- un site piraté ;
- un site mal référencé ;
- un site peu évolutif ;
- un site complexe à utiliser (par les internautes et mais aussi par les administrateurs) ;
- etc.
Et vous vous retrouvez alors avec des gens qui vous disent que "WordPress, c'est de la merde".
Posez vous ces questions sur WP !
Pour chaque choix que vous allez faire ou que vous avez fait, demandez-vous toujours les éléments suivants :
- en ai-je réellement besoin ?
- quel est l’impact et le retour sur investissement potentiel ?
- dans le cas où il s’agit de code :
- est-il testé, commenté et documenté ?
- respecte-t-il les standards de code de WordPress ?
- les utilisateurs sont-ils formés ?
- le reste du site sera t-il impacté ?
- puis-je revenir en arrière facilement ?
Chaque nouvelle fonctionnalité ou chaque nouveau développement doit aussi être mis en place selon le coût futur et le bénéfice espéré. Quel est le gain potentiel de la fonctionnalité ou du développement que l'on veut faire ? Et surtout, quelles sont les contraintes que cela va apporter sur le long terme ?
Faire les bons choix techniques sur WordPress
Maintenant, passons en revue quelques conseils de base qui permettent de réduire la dette technique sur ce CMS.
Hébergement
Commencez d'abord par choisir un hébergeur de qualité sur lequel vous aurez accès à des versions récentes de PHP, SQL ou encore d'Apache. Regardez aussi la puissance allouée par l'hébergement, notamment le processeur et la mémoire limite (ce qui devrait exclure d'office les offres les plus bases du marché).
Il est aussi intéressant de regarder si vous avez la main ou non sur la tout ou partie de la configuration du serveur (par l'interface de l'hébergeur) ou encore via le fichier .htaccess.
PS : on aime beaucoup Infomaniak à l'agence (lien affilié).
Les réglages de WordPress
Voici aussi quelques réglages basiques pour avoir le moins d'impact négatif sur le futur de votre site :
- onglet général : désactivez l'inscription pour tous les utilisateurs (sauf si vous n'avez pas le choix) ;
- onglet lecture :
- tronquez le flux RSS (pour ne pas faciliter le vol de contenus) ;
- ne cochez jamais la case "Ne pas indexer". Si tel est votre désir, une protection .htaccess est bien plus efficace ;
- onglet discussion
- modérez toujours les commentaires ;
- ne divisez pas les commentaires en sous-pages (pour ne pas avoir à indexer et/ou rediriger des pages inutiles) ;
- n'activez pas les commentaires imbriqués (sauf si votre thème a correctement été conçu au niveau SEO et ergonomique) ;
- onglet permaliens : ayez uniquement le nom de l’article dans les URL (cela permet de modifier, supprimer ou ajouter des catégories dans le futur en ayant le moins de redirections 301 à mettre en place).
Les thèmes et extensions de WP
D'abord, commençons par l'essentiel. Théoriquement, vous devez avoir une séparation stricte entre les contenus et les fonctionnalités présentes dans les extensions, et le rendu visuel via votre thème. Si en changeant de thème vous perdez des contenus dans l'administration du site et pour les visiteurs, c'est que cette simple règle n'a pas été respectée : votre thème ne doit pas contenir des contenus car sinon cela vous force à conserver votre thème ou à faire des développements supplémentaires lors de la création d'un nouveau thème (lors d'une refonte par exemple).
Ensuite, d'autres points techniques doivent être contrôlés sur WordPress :
- si ce n’est pas un thème créé sur mesure pour vous et qu'il s'agit d'un thème payant ou gratuit, il FAUT créer un thème enfant ;
- le thème ne doit contenir que les fonctionnalités nécessaires, pas une de plus (évitez les thèmes WordPress payants). Par exemple, si votre thème vous permet d'avoir des témoignages, des portfolios, des sliders ou encore des avis clients, il faut que vous utilisiez ces fonctions, sinon cela surcharge inutilement votre site et complexifie la maintenance et les futurs développements ;
- comparez votre thème avec le thème par défaut, notamment au niveau :
- du temps de chargement ;
- de la compatibilité mobile ;
- des données structurées ;
- de la traduction.
Il est ensuite intéressant de tester et valider le code de vos extensions et du thème. Vous pouvez utiliser par exemple les extensions suivantes :
- Debug Bar
- Query Monitor
- P3 plugin profiler
- Rewrite Rules Inspector
- RTL Tester
- WP Crontrol
- Theme Check
Regardez aussi les logs de WordPress et du serveur. Et pensez aussi à regarder les données de la Search Console de Google.
Votre propre code et la technique
Release early, release often
Quand on développe, on conseille de livrer et mettre en ligne des portions réduites de code. Vouloir tout publier d'un seul coup est le meilleur moyen de ne pas réussir à gérer les retours de bugs et les futurs évolutions. Testez donc souvent, sur des éléments précis de votre développement (vive l'intégration continue et les sprints de développement).
En plus de cela, pensez à ces points techniques :
- des tests unitaires ;
- des tests externes, par exemple avec :
- faites des Code Reviews ;
- pensez aux méthodes agiles ;
- n'hésitez pas à avoir votre propre framework ;
- mettez en place une vrai gestion de projet pour chaque création, refonte ou développement (avec une recette, des livrables, un planning, etc.) ;
- pensez en amont votre code :
- sur papier ;
- avec une conception UML ;
- en discutant avec d'autres développeurs ;
- etc.
Les utilisateurs
Le personnes qui utilisent et gèrent votre site vont aussi avoir un impact sur les coûts et contraintes futures. Il faut donc les "cadrer" :
- attribuez leur uniquement les bons droits et un accès unique par personne ;
- forcez-les à effectuer certaines actions (exemple : impossible de publier si aucune image à la une n'a été définie) ;
- mettez des alertes en place (l'utilisateur à supprimé un article sur votre WordPress) ;
- définissez un calendrier éditorial ;
- méfiez-vous d’eux ;
- Et surtout, formez-les (attention parfois à la conduite du changement, certains utilisateurs peuvent être réfractaires) !
La stratégie à adopter avec la dette technique
A tout moment, vous devez vous demander (et savoir) :
- Quels sont les problèmes actuels du site ?
- Quelles sont les futures évolutions prévues ?
- Quelles sont les évolutions potentielles ?
- Comment le secteur d’activité évolue ?
- Comment les technologies évoluent (par exemple avec l'arrivée imminente de Gutenberg sur WordPress) ?
Si vous vous posez toutes ces questions régulièrement, vous devriez réussir à réduire et maîtriser votre dette technique. Elle existera toujours, mais sera sans doute moins importante.
Les slides de la conférence sur la dette technique
Cette conférence a été donné lors du dernier WordCamp Paris.
Vous pouvez télécharger les slides au format PDF juste ici "WordCamp Paris 2018 - Dette technique et WordPress" et vous pouvez voir la vidéo, les photos et les slides de la conférence ci-dessous :
https://fr.slideshare.net/SeoMix/dette-technique-et-wordpress-90407691
4 Commentaires
Bonjour Daniel,
Mon site WordPress est hébergé chez OVH. Les incidents qui ont eu lieu ces derniers mois sont-ils mauvais pour le référencement ? Merci d'avance.
Cela peut effectivement nuire au référencement naturel, mais cela va aussi nuire à l'expérience utilisateur et aux conversions. Après, il faut regarder ce qu'il en est réellement car un incident court et ponctuel n'aura au final que peu d'impact.
n’hésitez pas à avoir votre propre framework ;
> 99% du temps, créer un framework, c'est créer de la dette car sa maintenance est bien souvent négligée, et en tant que développeur, les compétences évoluants, il est rare de vouloir maintenir un socle bâti 4-5 ans plus tôt.
Pas faux du tout : tout dépend de la complexité du framework et de l'implication de l'entreprise dedans
Laisser un commentaire