Trois mises à jour de sécurité en un mois : pourquoi nous changeons notre modèle d'entretien

Depuis juillet, les sites de nos clients ont nécessité parfois jusqu'à trois interventions de sécurité en l'espace d'un mois. Ce n'est pas simplement un été plus mouvementé que les autres. Le rythme de découverte des vulnérabilités s'accélère, notamment parce que l'intelligence artificielle permet maintenant d'analyser du code à une vitesse et à un coût qui étaient impensables il y a encore quelques années.

Cette nouvelle réalité cadre de moins en moins avec la façon dont l'industrie, nous inclus, abordait traditionnellement l'entretien web.

Voici ce qui a changé et, surtout, ce que nous mettons en place chez ctrlweb pour nous y adapter.

‍

Ce qui s'est passé cet été

‍

Le 17 juillet, l'équipe de sécurité de WordPress publiait un correctif d'urgence pour une faille baptisée wp2shell. Deux vulnérabilités combinées permettaient à un attaquant anonyme (sans compte ni mot de passe) d'exécuter du code sur une installation WordPress standard.

L'exploitation a commencé dans les heures suivantes. Des attaquants ont notamment déployé des portes dérobées persistantes, dont certaines se présentaient comme des extensions de sécurité légitimes.

Trois semaines plus tard, le 6 août, WordPress publiait la version 7.0.3, qui corrigeait douze nouvelles vulnérabilités, sans lien avec la précédente.

Ajoutez à cela les mises à jour régulières du cœur et des extensions : en un mois, nous avons dû intervenir trois fois sur certains sites pour des enjeux de sécurité distincts.

Ce n'est pas nécessairement que WordPress est devenu moins sécuritaire. C'est surtout que la capacité de l'industrie à trouver des vulnérabilités vient de changer.

‍

Trouver une faille coûte beaucoup moins cher qu'avant

‍

La chaîne wp2shell n'a pas été découverte après des mois d'analyse manuelle. Searchlight Cyber a utilisé un modèle d'IA de pointe pour analyser le cœur de WordPress. Le résultat : une faille permettant de prendre le contrôle d'un site à distance, sans aucun identifiant.

Environ dix heures de travail et 25 $ de coûts de calcul.

Pour la version 7.0.3, certaines vulnérabilités ont également été découvertes par des entreprises spécialisées dans les tests de sécurité assistés par IA.

C'est là que se trouve le changement de fond : l'analyse approfondie de code, qui demandait auparavant beaucoup de temps et une expertise humaine spécialisée, peut maintenant être réalisée à une échelle beaucoup plus grande.

Les chiffres de l'industrie vont dans le même sens :

• FIRST prévoit environ 66 000 vulnérabilités publiées en 2026, soit plus de 46 % au-delà de sa projection initiale.
• En mai 2026, GitHub a publié 1 560 avis de sécurité, son plus haut total mensuel à ce jour, sans que cela suffise à absorber le volume de signalements entrants.
• Le noyau Linux a vu 432 vulnérabilités divulguées en deux jours.
• La fondation Apache, qui participe à un programme de découverte assistée par IA, a vu le nombre de vulnérabilités publiées augmenter de plus de 170 %.

Il est encore trop tôt pour savoir quelle part de cette hausse correspond à une vague temporaire de vieux bogues maintenant plus faciles à découvrir, et quelle part représente un nouveau rythme durable.

Pour l'entretien d'un site web, la conséquence est toutefois la même : il faut être prêt à intervenir plus régulièrement.

‍

Ce n'est pas seulement un problème WordPress

‍

La conclusion facile serait de dire : « Quittez WordPress. » Ce serait trop simple.

WordPress est particulièrement exposé en raison de sa très grande part de marché : une vulnérabilité exploitable peut transformer instantanément des millions de sites en cibles potentielles. Mais les autres technologies n'y échappent pas.

Craft CMS a lui aussi connu plusieurs vulnérabilités importantes cette année. Un exemple illustre bien le phénomène : une faille corrigée au début de l'année est réapparue quelques mois plus tard ailleurs dans le même logiciel, parce que la correction n'avait jamais été appliquée à cette seconde occurrence. C'est exactement le genre d'oubli qu'une analyse automatisée repère sans effort : elle ne se fatigue pas de vérifier toutes les variantes d'un même problème.

Laravel affiche un volume plus faible dans le framework lui-même, mais son écosystème de dépendances peut également être ciblé, notamment à travers la chaîne d'approvisionnement logicielle.

Le choix de la plateforme change le profil de risque. Il n'élimine pas le besoin d'entretien.

‍

Plus de vulnérabilités ne veut pas dire plus d'urgences

‍

C'est une nuance importante.

Le nombre de vulnérabilités découvertes augmente fortement. La proportion de celles qui nécessitent une intervention immédiate, beaucoup moins.

La majorité des nouvelles failles publiées ne représentent pas une menace immédiate pour un site vitrine ou un site corporatif typique. Le travail d'entretien ne consiste donc pas simplement à appliquer davantage de mises à jour : il consiste de plus en plus à évaluer le risque et à déterminer la bonne réponse.

Prenons deux événements de cet été.

wp2shell faisait l'objet d'une exploitation automatisée à grande échelle peu après sa divulgation. Dans un cas comme celui-là, il faut intervenir rapidement et vérifier non seulement que le correctif est appliqué, mais aussi que le site n'a pas été compromis pendant sa période d'exposition.

La faille du 6 août, elle, était sérieuse, mais son exploitation nécessitait davantage de conditions et d'interaction humaine. Elle devait être corrigée rapidement, sans pour autant justifier le même niveau d'urgence.

Distinguer ces situations exige du contexte et du jugement. Et c'est précisément là que le modèle traditionnel de banque d'heures atteint ses limites.

‍

Pourquoi la banque d'heures fonctionne moins bien

‍

Notre recommandation historique se situait autour de trois heures d'entretien par mois pour un site d'entreprise standard. Certains clients choisissaient plutôt une banque annuelle plus petite, utilisée au fil des besoins.

Pendant longtemps, ce modèle était raisonnable : quelques mises à jour importantes par année, des mises à jour d'extensions périodiques, et l'enveloppe était généralement suffisante.

Aujourd'hui, une seule vulnérabilité critique peut demander plusieurs interventions : mise à jour, validation du correctif, inspection des journaux, recherche d'éléments suspects et vérification du bon fonctionnement du site.

Mais le principal problème n'est pas nécessairement le nombre total d'heures. C'est le délai de réaction.

Lorsqu'une vulnérabilité critique est publiée et que le solde d'une banque d'heures est presque épuisé, nous pouvons nous retrouver à devoir demander une autorisation avant d'intervenir. Le client doit alors prendre rapidement une décision budgétaire à partir d'une situation technique qu'il n'a pas nécessairement les moyens d'évaluer lui-même. Pendant ce temps, les outils automatisés qui recherchent les sites vulnérables continuent de fonctionner.

Une banque d'heures convient très bien à du travail prévisible. Elle convient beaucoup moins à des interventions de sécurité qui arrivent de façon irrégulière et pour lesquelles le délai de réaction peut être déterminant.

‍

Un enjeu qui dépasse le technique

‍

Il y a un aspect qu'on oublie souvent dans le calcul.

Au Québec, si un site compromis contient des renseignements personnels (un simple formulaire de contact en contient), la situation ne se règle pas uniquement par un nettoyage technique. La Loi 25 exige de consigner l'incident dans un registre, d'évaluer s'il présente un risque de préjudice sérieux et, le cas échéant, d'en informer la Commission d'accès à l'information ainsi que les personnes touchées. Le registre doit être conservé au moins cinq ans et la Commission peut en demander une copie.

Autrement dit, le coût réel d'une compromission comprend un volet de conformité, avec des délais à respecter. C'est une raison de plus de traiter l'entretien de sécurité comme de la prévention plutôt que comme une réparation.

‍

Ce que nous mettons en place

‍

À compter de cet automne, nous allons donc progressivement faire évoluer nos mandats d'entretien vers des forfaits mensuels, plutôt que des banques d'heures.

Il y a trois raisons principales.

1. La capacité d'intervenir est prévue d'avance.

Lorsqu'une vulnérabilité critique applicable à votre site est publiée, nous pouvons intervenir sans devoir commencer par produire un devis ou vérifier le solde d'une banque d'heures.

‍

2. Le coût devient prévisible.

Un montant mensuel fixe est beaucoup plus simple à budgéter qu'une intervention imprévue importante.

‍

3. Le risque est mutualisé.

Tous les sites ne nécessiteront pas une intervention importante au même moment ni avec la même fréquence.

En regroupant l'entretien de plusieurs sites dans un modèle récurrent, nous pouvons absorber cette variation et maintenir une capacité d'intervention disponible lorsqu'un client en a réellement besoin.

Concrètement, selon le forfait choisi, l'entretien peut couvrir :

• les mises à jour planifiées du cœur, des extensions et des thèmes, avec vérification après déploiement;
• l'intervention sur les vulnérabilités critiques couvertes par le forfait, sans décompte d'heures;
• la surveillance de la disponibilité du site;
• la vérification des sauvegardes;
• la veille des avis de sécurité applicables à votre environnement technologique;
• un rapport périodique des interventions réalisées.

‍

Nous offrirons différents niveaux de service selon le profil du site. Une vitrine corporative simple n'a évidemment pas les mêmes besoins qu'un site transactionnel qui traite des données clients.

Si vous êtes actuellement sur une banque d'heures, rien ne sera annulé unilatéralement. Le solde inutilisé pourra être crédité au moment de la transition vers un forfait. Nous communiquerons avec chaque client concerné individuellement.

‍

Et si un forfait complet n'est pas justifié?

‍

Tous les sites n'ont pas besoin du même niveau d'entretien. Pour certains projets, un forfait complet n'est tout simplement pas justifié économiquement. Dans ces cas-là, il existe d'autres options.

Un niveau minimal consacré à la sécurité.
Pas de retouches de contenu ni d'optimisation : uniquement les interventions de sécurité critiques prévues au mandat et les avis nécessaires.

Un hébergement géré offrant des protections supplémentaires.
Certains hébergeurs spécialisés peuvent déployer des protections au niveau de leur infrastructure lorsqu'une vulnérabilité importante apparaît. Ces mesures ne remplacent pas les mises à jour, mais elles peuvent réduire l'exposition pendant la période nécessaire pour intervenir.

Reconsidérer la plateforme.
Un site vitrine de huit pages modifié trois fois par année n'a pas nécessairement besoin d'un CMS dynamique complet. Dans certains cas, simplifier l'architecture peut réduire considérablement les besoins d'entretien.

Il existe aussi un risque qui n'a rien à voir avec le forfait choisi : les sites oubliés.

Environnements de préproduction, anciennes campagnes, sous-domaines hérités, anciennes versions conservées « au cas où » : ces sites sont exposés aux mêmes scans automatisés que votre site principal, mais ils sont souvent beaucoup moins surveillés.

Si vous ne savez plus exactement ce qui est encore accessible sous votre nom de domaine, nous pouvons en faire l'inventaire avec vous.

‍

Où allons-nous?

‍

L'intelligence artificielle accélère la découverte de vulnérabilités. Elle accélère également la capacité des équipes de sécurité à analyser du code, développer des correctifs et détecter les comportements suspects.

À terme, cette évolution pourrait rendre les logiciels plus sécuritaires en permettant de découvrir et de corriger beaucoup plus rapidement des problèmes qui seraient autrement restés invisibles pendant des années. Mais cette transition ne se fera pas du jour au lendemain.

Entre-temps, exploiter un site web signifie accepter une réalité assez simple : les vulnérabilités peuvent être découvertes plus rapidement et plus fréquemment qu'avant.

La réponse n'est pas de paniquer ni de traiter chaque nouvelle faille comme une urgence. C'est de disposer d'un processus pour surveiller ce qui concerne réellement votre site, évaluer le niveau de risque et intervenir au bon moment.

Autrement dit, l'entretien de sécurité devient progressivement une dépense permanente et prévisible, au même titre que l'hébergement ou le nom de domaine, plutôt qu'une dépense exceptionnelle qu'on espère ne jamais avoir à faire.

C'est exactement ce que nous voulons permettre avec notre nouveau modèle de forfaits mensuels.

‍

Vous avez des questions sur votre entretien actuel ou sur les interventions effectuées sur votre site depuis juillet ?
Écrivez-nous. Nous pouvons faire le point avec vous, y compris sur les environnements ou anciens sites que vous avez peut-être oubliés.

‍

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

‍

Sources

‍Article rédigé le 7 août 2026. Les versions et correctifs mentionnés reflètent l'information disponible à cette date.

wp2shell (WordPress, 17 juillet 2026)

• SecurityWeek, « WP2Shell WordPress Vulnerabilities Exploited in the Wild » (versions touchées, mises à jour forcées)
• Rapid7, analyse technique et recommandations de vérification post-correctif
• Wiz Research, exploitation observée et déploiement de portes dérobées
• BleepingComputer, portes dérobées et extensions malveillantes installées

WordPress 7.0.3 (6 août 2026)

• WordPress.org, annonce de la version 7.0.3
• WordPress.org, notes de version détaillées
• Patchstack, analyse des douze vulnérabilités (source du délai de dix heures et du coût de 25 $ pour la découverte de wp2shell, ainsi que de l'attribution des découvertes à des entreprises de tests de sécurité assistés par IA)

Volume de vulnérabilités et découverte assistée par IA

• Help Net Security, prévision de FIRST pour 2026 (66 000 vulnérabilités, 46 % au-delà de la projection initiale, proportion stable des cas urgents)
• GitHub Blog, « Inside the Advisory Database and what happens when vulnerability volume breaks records » (1 560 avis publiés en mai 2026)
• Open Source For You, 432 vulnérabilités du noyau Linux divulguées en deux jours
• VulnCheck, « The First CVE Wave » (hausse de plus de 170 % chez Apache)
• APNIC, synthèse de la mise à jour de prévision de FIRST

Craft CMS et Laravel

• CVE Details, historique des vulnérabilités de Craft CMS (dont la faille réapparue à un second endroit du code)
• Snyk, avis sur la compromission de la chaîne d'approvisionnement Laravel-Lang
• The Hacker News, compromission des paquets Laravel-Lang

Loi 25 (Québec)

• Commission d'accès à l'information du Québec, incidents de confidentialité et mesures de sécurité pour les entreprises