Un site peut fonctionner aujourd'hui et ne plus être adapté demain. La maintenance sert aussi à éviter qu'il vieillisse.
Cet été, nous sommes intervenus sur la plateforme e-commerce de Vertical’Art, que nous accompagnons et faisons évoluer au quotidien.
Et derrière ce que les utilisateurs appellent simplement le shop, l’architecture est loin d’être standard : un WordPress headless pour administrer les contenus et le catalogue, un front développé en React avec rendu côté serveur (SSR), le tout déployé sur une infrastructure Kubernetes.
La plateforme doit par ailleurs répondre à deux usages : être accessible normalement sur le web, mais également fonctionner sur les tablettes installées directement dans les salles d’escalade.
L’intervention a été l’occasion d’agir sur plusieurs niveaux : application, performances, infrastructure, réseau et sécurité.
Une bonne partie de ce travail restera totalement invisible pour les utilisateurs. Sauf peut-être un détail : le site répond désormais globalement trois fois plus vite.
C’est aussi ça, pour nous, la maintenance. Ne pas seulement conserver ce qui existe. Le faire évoluer.
Nos outils de supervision mesurent en continu les temps de réponse du shop Vertical’Art et de son back-office. L’intervention nous permet donc de comparer objectivement la situation avant et après les optimisations.
On parle souvent de livraison lorsqu’un site est mis en production. Le mot est pratique. Mais techniquement, il raconte assez mal ce qui se passe ensuite.
WordPress évolue. React évolue. PHP évolue. Kubernetes évolue. Les bibliothèques, les navigateurs, les protocoles et les standards de sécurité aussi. Certaines technologies finissent même par ne plus être activement développées.
Cela ne signifie pas qu’il faut tout réécrire dès qu’une brique vieillit. Cela signifie qu’il faut le savoir, surveiller les dépendances et anticiper la suite.
Même sans toucher à une ligne de code, un projet numérique vieillit. C’est pour ça que maintenir ne peut pas simplement vouloir dire conserver en l’état.
Le shop Vertical’Art ne repose pas sur une installation WordPress classique. WordPress fonctionne en headless pour administrer les contenus et le catalogue. L’interface est développée séparément en React, avec un rendu côté serveur (SSR). L’ensemble est ensuite déployé sur une infrastructure orchestrée avec Kubernetes.
Cette architecture répond aux usages particuliers de la plateforme, accessible sur le web mais également depuis des tablettes installées directement dans les salles. Sa maintenance ne peut donc pas s’arrêter au CMS.
Lors de cette intervention, nous avons travaillé sur WordPress et ses dépendances, mais aussi sur l’orchestration Kubernetes, la répartition de charge, le routage réseau, les DNS ou encore la gestion des certificats SSL. Nous avons également ajouté un second répartiteur de charge pour pouvoir réaliser certains tests sans perturber la production.
Plus une architecture est spécifique, plus sa maintenance demande de comprendre comment toutes ses briques interagissent.
Images, JavaScript, CSS, cache, Core Web Vitals : quand on parle de performance web, on regarde souvent ce qui se passe côté navigateur. Mais une page rapide commence bien avant.
Sur cette plateforme, une partie importante du travail a porté sur la manière dont les données du catalogue sont préparées et préchargées côté serveur.
Nous avons optimisé ce fonctionnement et fait évoluer parallèlement l’infrastructure qui l’exécute.
Nos outils de supervision mesurent en continu les temps de réponse du shop et du back-office. Après l’intervention, les courbes ont chuté très nettement. Le site répond désormais globalement trois fois plus vite.
Et lorsque cette même plateforme est utilisée sur le web mais aussi sur les tablettes présentes dans les salles d’escalade, performance et disponibilité ne sont plus seulement des indicateurs techniques. Elles font partie du service.
Tout ne s’est pas fait uniquement dans une logique d’optimisation. Un incident nous a également permis d’identifier des mécanismes qui pouvaient être améliorés.
Nous avons revu une partie de la configuration DNS pour accélérer certaines transitions entre serveurs, corrigé un problème de routage affectant des accès HTTPS et vérifié le renouvellement automatique des certificats SSL.
Le routage a également été ajusté afin que WordPress puisse correctement identifier les adresses IP derrière les différentes couches de l’infrastructure, une information importante pour la traçabilité, le diagnostic et certains mécanismes de sécurité.
L’objectif n’est pas de promettre qu’une infrastructure ne connaîtra jamais d’incident. Notre travail consiste à réduire leur probabilité, limiter leur impact et apprendre de chacun d’entre eux. Un problème résolu ne devrait pas simplement disparaître de la liste des tickets. Il devrait rendre le système plus robuste.
C’est finalement notre manière de voir la maintenance. Surveiller. Mesurer. Mettre à jour. Optimiser. Faire évoluer certaines briques. Anticiper celles qu’il faudra remplacer demain.
La maintenance ne consiste pas à figer un projet dans le temps. Elle lui permet de continuer à avancer.

Fail early, fail often, fail forward.
Derrière la formule un peu startup se cache une idée assez simple : dans un projet numérique, le problème n'est pas de se tromper. C'est de mettre trop longtemps à s'en rendre compte.

Une refonte transforme un site. Elle n’efface pas pour autant l’histoire que Google connaît déjà de lui.

En quelques années, l'intelligence artificielle est passée d'une technologie de niche à un outil utilisé quotidiennement par des millions de professionnels.
Cette accélération est spectaculaire. Elle mérite aussi que l'on prenne un peu de recul.