Pourquoi votre agence web ne met pas a jour votre site (et pourquoi c'est un probleme)

Le modele "construire et oublier"

Voici quelque chose que la plupart des agences web ne vous diront jamais : des qu'elles vous remettent votre site termine, elles cessent d'y penser. La facture est payee, le projet est clos, l'equipe passe au client suivant. Votre site reste sur un serveur quelque part, executant le meme code qu'au lancement, devenant un peu plus vulnerable chaque semaine qui passe.

Ce n'est pas un probleme marginal. C'est l'etat par defaut du secteur web, en particulier au Tessin et dans toute la Suisse. J'ai audite des centaines de sites web de PME au fil des ans, et le schema est d'une regularite affligeante : un site construit il y a deux ou trois ans, avec un CMS obsolete, des plugins qui n'ont pas ete touches depuis le jour du lancement. L'agence qui l'a construit ? Elle est passee a autre chose. Elle n'existe peut-etre meme plus.

Les consequences sont reelles. Un site web non mis a jour est une porte ouverte pour les attaquants. Si vous voulez comprendre les risques specifiques, nous les avons couverts en detail dans notre article sur les risques d'un site web non mis a jour. Mais aujourd'hui, je veux me concentrer sur le pourquoi et ce que vous, en tant que dirigeant d'entreprise, pouvez faire.

Pourquoi les agences ne mettent pas a jour votre site

Il n'y a pas de contrat de maintenance

La raison la plus courante est la plus simple : personne n'a convenu de maintenir le site. L'agence vous a devis le design, le developpement et le lancement. La maintenance ne faisait pas partie du perimetre, n'a jamais ete discutee, jamais chiffree. Une fois le site en ligne, l'agence n'a aucune obligation contractuelle d'y toucher a nouveau.

Du point de vue de l'agence, cela a parfaitement un sens financier. La maintenance est un travail a faible marge. Il faut suivre des dizaines ou des centaines de sites clients, chacun avec des versions CMS differentes, des plugins differents, des environnements d'hebergement differents. Cela signifie gerer les echecs de mise a jour, les mises en page cassees et les problemes de compatibilite, le tout pour des honoraires mensuels qui couvrent a peine le temps investit.

Alors la plupart des agences ne la proposent tout simplement pas. Ou elles la proposent comme une reflexion apres coup, un poste dans le devis que le client supprime pour contenir le budget.

La culture du "n'y touchez pas si ca marche"

Il y a une attitude profondement enracinee dans beaucoup d'agences, surtout les plus petites : si le site tourne, on n'y touche pas. Mettre a jour le coeur de WordPress, ou Joomla, ou quel que soit le CMS utilise, c'est risquer la casse. Une mise a jour de plugin pourrait entrer en conflit avec le theme. Une mise a jour de version PHP pourrait causer des erreurs fatales. Et si quelque chose casse, le client appelle, et l'agence doit reparer gratuitement (ou pour un montant qui cree des frictions).

Alors le calcul devient : ne rien faire et rien ne casse. Mettre a jour et quelque chose pourrait casser. Pour une agence sans revenus de maintenance, le choix rationnel est clair. Ne rien faire.

Le probleme, bien sur, c'est que "rien ne casse" n'est vrai qu'en apparence. Sous le capot, les vulnerabilites connues s'accumulent. Les attaquants recherchent precisement ces installations obsoletes. Le site peut sembler fonctionner pendant des annees jusqu'au jour ou il est compromis, defigure ou utilise pour distribuer des logiciels malveillants. A ce moment-la, l'agence a disparu depuis longtemps.

Pas d'environnement de staging

Un environnement de staging est une copie de votre site web ou les mises a jour peuvent etre testees avant d'etre appliquees au site en production. C'est une pratique standard dans le developpement web professionnel. C'est aussi quelque chose que la plupart des projets de sites web pour PME n'incluent jamais.

Sans environnement de staging, chaque mise a jour est appliquee directement en production. Si quelque chose tourne mal, votre site en production tombe. C'est pourquoi beaucoup d'agences et leurs clients evitent completement les mises a jour. Le risque d'une panne visible semble pire que le risque invisible d'une vulnerabilite de securite.

Mettre en place un environnement de staging n'est ni couteux ni complique. La plupart des hebergeurs de qualite proposent le staging en un clic. Mais cela doit faire partie du workflow des le depart, et quelqu'un doit etre responsable de son utilisation.

La peur de casser les choses

C'est etroitement lie au probleme du staging, mais ca va plus loin. Beaucoup d'agences, en particulier les plus petites qui servent le marche des PME, n'ont pas une expertise technique approfondie du CMS qu'elles deploient. Elles savent comment installer WordPress, choisir un theme, configurer quelques plugins et livrer un site qui a belle allure. Mais elles n'ont pas l'experience pour appliquer des mises a jour en toute confiance, resoudre les problemes de compatibilite ou se remettre de mises a niveau echouees.

Quand on n'est pas confiant dans sa capacite a reparer ce qu'une mise a jour pourrait casser, on evite de mettre a jour. C'est la nature humaine. Mais le resultat est que des milliers de sites web d'entreprises restent sans correctifs pendant des annees, accumulant des vulnerabilites connues que n'importe quel script kiddie peut exploiter.

Le fosse de responsabilite client-agence

Demandez a un dirigeant d'entreprise : qui est responsable de la securite de votre site web ? La plupart diront "mon agence web". Demandez a l'agence web : qui est responsable de la securite du site du client ? La plupart diront "le client, sauf si nous avons un contrat de maintenance".

Ce fosse est l'endroit ou la securite meurt. Aucune des deux parties ne croit que c'est son travail, alors personne ne le fait. Le dirigeant suppose que l'agence s'en occupe. L'agence suppose que le client sait qu'il doit demander (et payer) une maintenance continue. Les deux suppositions sont fausses, et le site reste expose.

En Suisse, la situation juridique ajoute une couche supplementaire. Selon la Loi federale revisee sur la protection des donnees (nLPD/revLPD), le responsable du traitement (c'est-a-dire l'entreprise qui collecte des donnees personnelles via le site web) est responsable des mesures techniques adequates. "Mon agence n'a pas mis a jour le site" n'est pas une defense si les donnees des clients sont compromises par une vulnerabilite connue.

Signes d'alerte : votre agence neglige la securite

Comment savoir si votre agence web laisse votre site expose ? Voici des indicateurs concrets :

• Vous n'avez jamais recu de rapport de maintenance. Si personne ne vous a jamais dit ce qui a ete mis a jour et quand, rien n'a ete mis a jour.
• Vous ne savez pas quelle version CMS votre site utilise. Si votre agence n'a jamais mentionne un numero de version, elle ne le suit pas.
• Vous n'avez pas d'environnement de staging. Si vous ne pouvez pas tester les modifications avant qu'elles passent en production, les mises a jour sont soit risquees, soit inexistantes.
• Votre agence repond aux questions de securite avec des assurances vagues. "Ne vous inquietez pas, l'hebergeur s'en occupe" n'est pas une reponse. Les hebergeurs gerent la securite au niveau serveur. La securite au niveau application (votre CMS, les plugins, les themes) est votre responsabilite.
• On ne vous a jamais demande d'approuver ou de planifier des mises a jour. Un partenaire de maintenance responsable communique sur les mises a jour prevues, surtout les mises a niveau de versions majeures.
• L'agence n'a pas de processus de securite documente. Demandez : que se passe-t-il quand une vulnerabilite critique est divulguee dans un plugin que nous utilisons ? S'ils ne peuvent pas decrire leur processus, ils n'en ont pas.
• Vos plugins incluent des elements abandonnes ou supprimes. Verifiez le panneau d'administration de votre CMS. Si des plugins affichent "Ce plugin a ete ferme" ou n'ont pas ete mis a jour depuis plus d'un an, vous avez un probleme. Notre article sur les vulnerabilites des plugins CMS explique pourquoi c'est important.

Questions que tout dirigeant d'entreprise devrait poser a son agence

Si une agence web gere actuellement votre site, planifiez un appel et posez ces questions. Leurs reponses vous diront tout ce que vous devez savoir :

1. Quelle version CMS mon site utilise-t-il, et est-ce la derniere ? Ils devraient pouvoir repondre immediatement. S'ils doivent "verifier et vous rappeler", c'est un signal d'alarme.
2. Combien de plugins/extensions sont installes, et sont-ils tous a jour ? Ils devraient le savoir. Ils devraient aussi pouvoir vous dire quels plugins ont ete abandonnes par leurs developpeurs.
3. Quelle version PHP mon site utilise-t-il ? Si c'est en dessous de 8.2 (en 2025), vous avez besoin d'un plan de mise a niveau.
4. Avez-vous un environnement de staging pour mon site ? Si la reponse est non, demandez pourquoi et ce qu'il faudrait pour en mettre un en place.
5. Quel est votre processus quand une vulnerabilite critique est divulguee ? La bonne reponse inclut la surveillance des bases de donnees de vulnerabilites, l'evaluation de l'impact, le test du correctif sur le staging et le deploiement rapide. Toute reponse moins specifique est une non-reponse.
6. Qui est responsable des mises a jour de securite ? Est-ce dans notre contrat ? Obtenez des clarifications par ecrit. Les accords verbaux valent le papier sur lequel ils sont imprimes.
7. Que se passe-t-il si mon site est pirate ? Avez-vous un plan de reponse aux incidents ? Un partenaire professionnel a un processus documente : isoler, enqueter, restaurer a partir de la sauvegarde, corriger la vulnerabilite, surveiller les re-compromissions.
8. Pouvez-vous me montrer un journal de toutes les mises a jour appliquees au cours des 12 derniers mois ? Si aucun journal n'existe, aucune mise a jour n'a ete appliquee.

Ce a quoi ressemble un veritable contrat de maintenance

Si votre agence ne propose pas de maintenance, ou si son offre est vague ("nous gardons un oeil"), voici ce qu'un veritable accord de maintenance devrait inclure :

Perimetre et responsabilites

• Definition claire de ce qui est couvert : mises a jour du coeur CMS, mises a jour des plugins, mises a jour du theme, gestion de la version PHP, surveillance de la securite.
• Definition claire des delais de reponse : dans quel delai les correctifs de securite critiques seront-ils appliques ? (Acceptable : dans les 48 heures suivant la divulgation pour les CVE critiques. Non acceptable : "lors de la prochaine fenetre de maintenance planifiee, qui est trimestrielle.")
• Definition claire de ce qui n'est pas couvert : developpement de nouvelles fonctionnalites, modifications de contenu, modifications de design. Ceux-ci doivent etre definis et factures separement.

Processus de mise a jour

• Toutes les mises a jour testees dans un environnement de staging avant le deploiement en production.
• Sauvegardes automatiques effectuees avant chaque cycle de mise a jour.
• Procedure de rollback documentee et testee.
• Client informe des mises a jour majeures (ex. mises a niveau de versions majeures du CMS) avant qu'elles ne soient appliquees.

Reporting

• Rapport mensuel de maintenance montrant : ce qui a ete mis a jour, quelles vulnerabilites ont ete corrigees, tout probleme rencontre, statut actuel de tous les composants.
• Revue annuelle de securite resumant la maintenance de l'annee, les eventuels incidents et les recommandations.

Tarification

Combien devriez-vous vous attendre a payer ? Pour un site WordPress ou Joomla standard avec 10-20 plugins, un contrat de maintenance raisonnable en Suisse coute entre CHF 150 et CHF 400 par mois, selon la complexite du site et les garanties de delai de reponse. Cela couvre les cycles de mise a jour reguliers, la surveillance de la securite, les sauvegardes et la reponse basique aux incidents.

Si cela semble cher, comparez-le au cout d'un site web compromis : arret d'activite, obligations de notification de violation de donnees selon le droit suisse, dommages a la reputation et cout de la remediation d'urgence (qui se situe generalement entre CHF 2 000 et CHF 10 000 pour une compromission serieuse).

Cycles de mise a jour mensuels vs trimestriels

A quelle frequence les mises a jour doivent-elles etre appliquees ? La reponse depend du profil de risque, mais voici un cadre general :

Type de mise a jour	Frequence recommandee	Notes
Correctifs de securite critiques	Sous 48 heures	Pour les CVE avec CVSS 7.0+, attendre n'est pas acceptable
Mises a jour de securite regulieres	Hebdomadaire ou bimensuel	Correctifs de securite mineurs, patchs de plugins
Mises a jour fonctionnelles	Mensuel	Nouvelles fonctionnalites dans les plugins/themes, tester minutieusement
Mises a niveau de version majeure	Sous 30 jours apres la sortie stable	Versions majeures du coeur CMS, mises a niveau PHP, necessitent des tests sur staging
Audit de securite complet	Annuel	Revision de tous les composants, suppression des plugins inutilises, audit des acces

Les cycles de mise a jour trimestriels sont trop lents pour tout ce qui touche a la securite. Dans les trois mois entre les mises a jour, des dizaines de nouvelles vulnerabilites peuvent etre divulguees dans votre CMS et vos plugins. Les outils d'exploit automatises sont mis a jour dans les jours ou les heures suivant la publication d'un CVE. Un cycle trimestriel signifie que vous etes potentiellement expose pendant des mois.

Mensuel est la frequence minimale acceptable pour les mises a jour non critiques. Hebdomadaire est mieux. Les correctifs critiques doivent toujours etre appliques des qu'ils sont disponibles et testes.

Controle interne vs dependance a l'agence

Certains dirigeants, frustres par la negligence de l'agence, envisagent de prendre en charge la gestion du site web en interne. Cela merite une reflexion approfondie.

Arguments pour la gestion interne

• Controle direct : Vous decidez quand les mises a jour ont lieu, pas une agence qui pourrait deprioriser votre site.
• Reponse plus rapide : Quand une vulnerabilite critique sort, vous pouvez agir immediatement au lieu d'attendre que votre agence s'en occupe.
• Meilleure connaissance : Vous comprenez votre propre surface d'attaque parce que vous la gerez directement.
• Efficacite des couts a grande echelle : Si vous avez plusieurs sites ou une presence web complexe, une personne interne peut etre plus rentable que plusieurs contrats d'agence.

Arguments pour la gestion par agence

• Expertise : Une bonne agence a vu des centaines d'installations CMS et connait les schemas de defaillance courants.
• Outillage : Les agences qui prennent la maintenance au serieux utilisent des outils de surveillance, des systemes de mise a jour automatisee et des scanners de vulnerabilites qui seraient couteux pour une seule entreprise.
• Disponibilite : Si votre seule personne interne est en vacances quand un CVE critique sort, qui patche le site ?

Le juste milieu

Pour la plupart des PME, la meilleure approche est un modele hybride :

1. Possedez votre compte d'hebergement. Ne laissez jamais l'agence posseder votre hebergement. Vous devriez avoir un acces direct au serveur, au panneau d'administration du CMS et au registraire de domaine. Si l'agence disparait, vous pouvez toujours acceder a tout.
2. Possedez votre depot de code. Si du developpement sur mesure a ete fait, le code source devrait etre dans un depot que vous controlez (GitHub, GitLab, Bitbucket). L'agence peut avoir un acces contributeur, mais vous possedez le depot.
3. Contractualisez la maintenance separement. Votre prestataire de maintenance n'a pas besoin d'etre la meme agence qui a construit le site. Avoir une partie differente qui audite et maintient le site peut mettre en lumiere des problemes que le developpeur original a manques.
4. Obtenez un acces admin et une formation. Vous devriez pouvoir vous connecter a votre CMS et voir le tableau de bord. Vous devriez savoir comment verifier les versions des plugins. Vous devriez savoir a quoi ressemble un avertissement de securite.
5. Ayez une sauvegarde que vous controlez. Les sauvegardes automatiques doivent aller dans un emplacement de stockage que vous possedez, pas seulement le serveur de l'agence. Si l'agence fait faillite, vos sauvegardes doivent rester accessibles.

Ce qui se passe quand la maintenance est negligee

Permettez-moi de decrire un scenario que nous voyons regulierement. Une PME tessinoise a fait construire son site web il y a quatre ans par une agence locale. Il tourne sous WordPress 5.9 avec 22 plugins. PHP 7.4. L'agence qui l'a construit ne propose plus de maintenance. Le dirigeant se connecte pour mettre a jour le contenu occasionnellement mais ignore les badges "mises a jour disponibles" dans le tableau de bord parce que "la derniere fois que j'ai essaye, quelque chose s'est casse."

Un lundi matin, les clients commencent a signaler que le site redirige vers un site de spam pharmaceutique. Google a deja signale le domaine avec un avertissement "Ce site a peut-etre ete pirate". Les classements dans les moteurs de recherche se sont evapores. Le formulaire de contact a envoye du spam a toute la base de donnees clients.

Le nettoyage a pris trois semaines et a coute CHF 8 500. Les dommages a la reputation ont pris beaucoup plus de temps a recuperer. Tout cela parce qu'une vulnerabilite connue dans un plugin, corrigee par le developpeur huit mois plus tot, n'avait jamais ete appliquee.

Ce n'est pas une histoire inventee. C'est un composite de cas reels que nous avons traites. Les details changent (parfois c'est une page d'accueil defiguree, parfois c'est un mineur de cryptomonnaie qui tourne sur le serveur, parfois ce sont des donnees clients volees), mais la cause profonde est toujours la meme : personne ne maintenait le site.

L'alternative du site statique

Il existe une approche differente qui elimine beaucoup de ces problemes de maintenance : les generateurs de sites statiques et l'architecture JAMstack moderne. Les sites construits avec des outils comme Astro, Next.js ou Hugo n'ont pas de CMS traditionnel qui tourne sur le serveur. Pas de PHP, pas de base de donnees, pas d'ecosysteme de plugins a patcher. La surface d'attaque est considerablement reduite.

Cela ne signifie pas que les sites statiques ne necessitent aucune maintenance. Les dependances doivent toujours etre mises a jour, les configurations d'hebergement comptent toujours, et toute fonctionnalite dynamique (formulaires de contact, recherche, e-commerce) introduit sa propre surface d'attaque. Mais la posture de securite de base est bien meilleure qu'une installation CMS traditionnelle.

Si vous envisagez une refonte de site ou un nouveau site, il vaut la peine d'explorer si une architecture moderne pourrait reduire votre charge de maintenance continue. Nous en avons parle plus en detail dans notre comparaison WordPress vs. JAMstack.

Passer a l'action

Si vous avez lu jusqu'ici, vous reconnaissez probablement certains de ces schemas dans votre propre situation. Voici quoi faire ensuite :

1. Decouvrez ce que votre site execute. Connectez-vous au panneau d'administration de votre CMS et notez la version CMS, la version PHP et le nombre de plugins/extensions. Si vous n'avez pas d'acces admin, c'est le probleme numero un.
2. Verifiez quand les choses ont ete mises a jour pour la derniere fois. La plupart des plateformes CMS affichent la date de derniere mise a jour pour chaque plugin. Si tout a ete mis a jour pour la derniere fois a la date du lancement original, vous avez votre reponse.
3. Parlez a votre agence. Utilisez les questions listees ci-dessus. Obtenez des reponses claires par ecrit. S'ils ne peuvent pas ou ne veulent pas repondre, commencez a chercher un nouveau partenaire de maintenance.
4. Faites faire une evaluation de securite. Un audit de securite independant de votre site web vous montrera exactement ou vous en etes. Il ne s'agit pas de blamer votre agence; il s'agit de comprendre votre risque.
5. Mettez en place un plan de maintenance. Qu'il soit interne, via votre agence ou via un partenaire specialise, mettez en place une maintenance continue avec des responsabilites et des calendriers clairs.

Votre site web n'est pas un projet ponctuel. C'est un element vivant d'infrastructure qui necessite une attention continue, au meme titre que votre reseau de bureau, votre logiciel de comptabilite ou vos locaux physiques. Les agences qui construisent et oublient ne sont pas malveillantes; elles optimisent simplement pour leur propre modele economique. C'est a vous de vous assurer que quelqu'un optimise pour votre securite.

Si vous avez besoin d'aide pour evaluer votre situation actuelle ou mettre en place un plan de maintenance adequat, contactez-nous. Nous travaillons avec des PME dans tout le Tessin et la Suisse pour combler le fosse de la maintenance et garder les sites web securises.