8 min de lecture
Sobriété numérique : choisir l'outil juste, pas l'outil à la mode
Quand un client me demande un site, je ne commence pas par « WordPress ou autre chose ». Je commence par « qu'est-ce que vous allez en faire au quotidien ». La réponse change tout, et elle surprend souvent.
La sobriété numérique, on en parle beaucoup côté écologie. Moi, je la prends par un autre bout, celui de l'honnêteté commerciale. Choisir une stack qui dépasse le besoin, c'est facturer du superflu. Empiler des animations qui n'apportent rien, c'est ralentir le site et fatiguer le visiteur. Dans les deux cas, le client paye pour quelque chose qui ne lui sert pas et qui souvent le dessert.
Petit cadrage avant de commencer. Je propose à la fois du WordPress et du site vitrine statique sans CMS, et je n'en vends qu'un des deux par client, jamais les deux. Le boulot consiste à choisir lequel.
Le réflexe « ça fait pro » coûte cher au client
Il y a un réflexe dans le métier qui consiste à empiler des fonctionnalités, des plugins et des effets parce que « ça fait pro ». Le client ne demande pas, mais on rajoute. Un slider plein écran, une animation au scroll sur chaque section, un parallax dans le header, une transition de page, un curseur custom, un compteur animé sur les chiffres clés. Et côté technique, un page builder pour gérer tout ça, plus une dizaine de plugins pour combler ses manques.
Le résultat se voit à la livraison. Le site est lent, lourd, fragile. Le client n'arrive plus à modifier une virgule sans casser la mise en page. Les Core Web Vitals sont dans le rouge. Les visiteurs habitués trouvent ça gonflant. Et le client, lui, paye une maintenance plus chère parce qu'il y a plus de surface à entretenir.
Tout ce que je viens de lister, je l'ai vu sur des sites repris. Aucun de ces effets n'aidait le client à vendre quoi que ce soit ni à mieux se faire trouver. Ils étaient là parce que le prestataire d'avant trouvait ça joli, ou parce qu'il fallait remplir la facture.
Côté édition, le page builder ajoute sa propre couche. À chaque modification, le client se retrouve face à des dizaines de réglages, options, onglets et inspecteurs. C'est exactement ce que décrit la loi de Hick : plus on multiplie les choix dans une interface, plus le temps de décision s'allonge et plus la peur de casser quelque chose grandit. Au final, le client renonce et rappelle son prestataire.
Trois questions avant de choisir une stack ou un effet
Avant de coder quoi que ce soit, je pose trois questions. Elles valent autant pour la stack que pour un élément visuel.
Quel est le besoin réel ? Pas le besoin perçu, pas le besoin vendu par les autres prestataires, pas le besoin imaginé par le client après avoir vu le site d'un concurrent. Le vrai : qui visite le site, pourquoi, qu'est-ce qu'il vient chercher en arrivant.
Quelle est la durée de vie attendue ? Un site qui doit publier trois articles par semaine pendant cinq ans n'a pas les mêmes contraintes qu'une vitrine de cinq pages qui changera trois fois en cinq ans. Une animation au scroll qui ne sert à rien aujourd'hui ne servira pas plus dans deux ans.
Qui maintient ? Le client lui-même, son prestataire d'origine, un autre dev plus tard. La sobriété rend la passation plus simple. Un site statique se reprend en deux heures par n'importe quel dev front, un WordPress avec quinze plugins peut décourager le successeur.
Si la fonctionnalité ou la stack ne passe pas ces trois questions, elle dégage.
Quand WordPress est le bon outil
WordPress est génial quand il sert ce pour quoi il est conçu : publier régulièrement et donner au client une vraie autonomie éditoriale. Un blog actif, une boutique en ligne, un site avec plusieurs auteurs, un catalogue qui bouge tout le temps. Là, le CMS prend tout son sens et chaque euro investi dans la stack se retrouve dans le quotidien du client.
C'est aussi le bon choix quand il faut connecter le site à un écosystème : adhésions, formations, paiements récurrents, intégration avec un CRM ou une newsletter. L'écosystème WordPress est mature, francophone, et la plupart des connecteurs existent déjà.
Je vends du WordPress, je continuerai à en vendre, et je crois à cet outil quand il est au bon endroit.
Quand un site statique HTML, PHP ou JS suffit
Pour une vitrine de trois à sept pages au contenu stable, sans publication régulière, sans boutique, sans espace adhérent, WordPress est surdimensionné. Le client paye un CMS qu'il n'utilisera presque jamais, et il en paye aussi la maintenance, les mises à jour de plugins, le risque de faille.
Sur ces projets, un site statique en HTML, PHP ou JavaScript sans CMS coche toutes les cases. Tarif plus serré, livraison plus rapide, hébergement autour de cinq euros par mois au lieu de quinze à vingt-cinq, zéro plugin à patcher, performance excellente par construction (sans promettre un score précis, ça dépendra toujours de l'hébergeur). Le seul inconvénient assumé : les modifications passent par moi, le client n'édite pas en autonomie.
Quand le client publie une fois par an, ce n'est pas un inconvénient, c'est une simplification.
Le mythe de l'autonomie WordPress
C'est la phrase que j'entends le plus souvent en rendez-vous : « je veux WordPress pour pouvoir modifier mon site moi-même ». Sur le papier, c'est imparable. Dans la vraie vie, ça l'est beaucoup moins.
Beaucoup de clients que je récupère n'ont jamais touché à leur site eux-mêmes. Ils passent par leur webmaster, leur dev ou l'agence d'origine pour des modifications qu'ils pourraient faire dans Gutenberg en quelques clics. L'autonomie promise par WordPress reste théorique pour une bonne partie des sites vitrines en production.
Ce n'est pas un reproche au client. Éditer un site web n'est pas son métier, et la peur de casser quelque chose le bloque dès qu'il ouvre l'admin. Résultat : il paye un CMS qu'il n'utilise pas, et il paye en plus son prestataire à chaque modification.
Et ce n'est pas réservé aux clients sans bagage technique. Je travaille par exemple pour une agence de communication, donc des gens dont c'est le métier de produire et de publier du contenu, et près de la moitié des modifications qu'on me confie pourraient se faire en deux clics dans l'admin : changer un texte, remplacer une image, publier une actualité. Si même une agence délègue ces gestes, ce n'est pas une question de compétence. C'est un arbitrage : pas le temps de s'en occuper, l'envie de ne pas être responsable si la prod casse, ou simplement l'habitude de confier la technique à un prestataire. Une preuve de plus que l'autonomie vendue par WordPress reste, pour beaucoup de sites, plus un argument qu'un usage.
La loi de Tesler résume bien ce qui se joue ici : tout système a une part de complexité irréductible, et la question n'est pas de la supprimer mais de décider qui la prend en charge. Avec WordPress, la complexité est en partie déposée chez le client (mises à jour, plugins, page builder à apprivoiser). Avec un site statique, elle reste chez le dev qui livre, et le client paye uniquement les modifications dont il a besoin.
Le site statique assume cette réalité au lieu de la masquer. Le client n'a jamais eu l'illusion qu'il modifierait son site seul, donc personne n'est déçu, et la facturation est claire dès le départ.
Le design aussi se met au régime
La sobriété ne s'arrête pas à la stack. Côté design, les mêmes questions valent. Une animation au scroll, ce n'est pas neutre. Elle ralentit la perception du contenu, gonfle les visiteurs habitués des sites pros, et casse l'accessibilité quand le réglage prefers-reduced-motion du système est ignoré. Pour certaines personnes, ces effets provoquent du motion sickness. Pour d'autres, ils perturbent les lecteurs d'écran et la navigation au clavier.
Un parallax dans un header n'aide personne à comprendre ce que vend l'entreprise. Une transition de page de huit cents millisecondes ajoute presque une seconde à chaque clic, alors que la loi de Doherty rappelle qu'au-delà de 400 ms l'attention décroche et la productivité chute. Un curseur custom rend la navigation moins prévisible : c'est la loi de Jakob qui s'applique, les visiteurs préfèrent que les sites se comportent comme ceux qu'ils connaissent déjà, pas comme une démo technique. Aucune de ces décisions ne sert le contenu, elles servent l'idée qu'on se fait d'un site qui « fait pro ».
Ça ne veut pas dire bannir tout mouvement. Une transition discrète sur un bouton au survol, un fade-in court sur une image qui se charge, ce sont des micro-interactions utiles qui guident le regard sans ralentir la lecture. Le bon test : est-ce que l'effet aide le visiteur à comprendre ce qui se passe, ou est-ce qu'il est là pour lui montrer qu'on sait coder.
Ce site comme preuve par l'exemple
Ce portfolio n'est pas sous WordPress. C'est du PHP vanilla compilé avec Tailwind, hébergé sur un mutualisé à cinq euros par mois. Il y a quasiment zéro animation décorative. La typographie, la hiérarchie et le rythme assument seuls le travail visuel.
Ce n'est pas un manifeste anti-CMS, c'est une application des trois questions à mon propre cas. Mon besoin : publier deux articles de blog par mois et présenter des projets qui changent une à deux fois par an. Ma durée de vie attendue : plusieurs années. Qui maintient : moi. Aucune de ces réponses ne justifie WordPress, donc je ne l'ai pas mis.
Si demain je voulais publier trois fois par semaine, je migrerais sans hésiter. L'outil suit le besoin, pas l'inverse.
Ce que ça change pour le client
Quand le client repart avec un site statique au lieu d'un WordPress, il n'a pas perdu en qualité, il a gagné en lisibilité de sa facture. Il paye le travail qui sert vraiment son projet, pas une dette technique qu'on lui demanderait d'entretenir pendant cinq ans.
Quand il repart avec un WordPress dont on a retiré le page builder et la moitié des animations, il a un site qui se charge plus vite, qui se maintient plus facilement, et qu'il pourra effectivement modifier le jour où il en aura besoin.
Le critère, dans les deux cas, n'est pas « est-ce que ça impressionne ». C'est « est-ce que ça sert le visiteur et le client qui paye ».
Et après ?
La sobriété numérique, prise du côté du métier, ce n'est pas une posture écolo. C'est de l'honnêteté commerciale. Refuser de vendre une stack et des effets qui ne servent pas le besoin du client, même quand ça réduit la facture immédiate. Se faire assez confiance pour dire « pour vous, ce sera ça et pas l'autre chose », plutôt que pousser systématiquement ce qui rapporte le plus.
Si vous hésitez entre WordPress et quelque chose de plus léger pour votre projet, on peut en parler trente minutes en visio. On regarde le besoin réel, on passe les trois questions, et on voit ensemble si une vitrine statique suffit ou si WordPress reste la bonne réponse. Et si vous êtes déjà sous WordPress, c'est l'occasion de faire le ménage dans les plugins et les effets qui ne servent plus, dans le cadre d'un contrat de TMA. Pour les fourchettes précises selon le type de projet, le détail figure dans mon article sur le chiffrage.