Dérive de site : pourquoi les sites web cassent sans que personne n’y touche
Votre site a cassé après une mise à jour — ou ne fonctionne plus sans aucune mise à jour ? C’est la dérive de site. « On n’a rien changé » est la phrase la plus courante du support web — et elle n’est presque jamais vraie. Quelqu’un, ou quelque chose, a changé : une mise à jour automatique a tourné pendant la nuit, un assistant IA a réécrit un composant, un script tiers a publié une nouvelle version, une règle de pare-feu s’est durcie. Ce guide passe en revue les dix causes de dérive que nous voyons le plus, ce que chacune casse, et comment la repérer avant vos clients.
Ce qu’est la dérive de site
La dérive de site, c’est l’écart entre le site que vous avez testé et celui que reçoivent vos visiteurs aujourd’hui. Elle s’accumule à partir de changements que personne n’a examinés ensemble : une mise à jour d’extension ici, un réglage CDN là, un script qui charge une version plus récente de lui-même. Aucun ne semble dangereux isolément, et la plupart s’appliquent automatiquement.
La dérive se manifeste rarement par une panne totale. La page d’accueil charge toujours, donc la surveillance de disponibilité reste au vert. Ce qui casse, c’est un parcours : le bouton d’ajout au panier qui ne répond plus, un champ de commande disparu, un e-mail de confirmation qui n’arrive plus, une image produit qui renvoie une 404. Ce sont les pannes qui coûtent des ventes — et précisément celles qu’un simple ping ne voit pas.
Pourquoi « personne n’y a touché » n’est presque jamais vrai
Un site moderne n’est pas un seul logiciel. Une boutique WordPress typique fait tourner le cœur de WordPress, un thème, vingt à cinquante extensions, un environnement PHP, un serveur web, un cache, un CDN, un pare-feu, une passerelle de paiement et une douzaine de scripts tiers — chacun maintenu par une équipe différente, avec son propre calendrier de versions, et beaucoup configurés pour se mettre à jour seuls.
Un site construit avec des outils d’IA ou un framework moderne a la même forme : du code généré, des dépendances npm, des réglages par défaut de l’hébergeur, une configuration en edge et des API externes. Quand quelque chose casse, la question n’est pas de savoir si quelque chose a changé, mais quelle couche a changé, et quand. Les dix causes ci-dessous sont les premiers endroits où regarder.
1. Mises à jour du cœur de WordPress, des extensions et des thèmes
Les mises à jour sont la première source de dérive de site sous WordPress — elles sont derrière la plupart des « une mise à jour WordPress a cassé mon site » — et la plupart se font sans surveillance : les versions mineures du cœur s’installent automatiquement, et depuis WordPress 5.5 les extensions et les thèmes peuvent aussi se mettre à jour seuls. Une mise à jour correcte isolément peut quand même entrer en conflit avec une autre extension, modifier un hook dont dépend votre thème ou renommer les classes CSS ciblées par vos personnalisations.
WooCommerce ajoute son propre piège : les thèmes surchargent les modèles WooCommerce, et quand WooCommerce met à jour un modèle, la copie obsolète de votre thème continue de s’afficher. Le panier ou la commande peuvent perdre un champ ou un nonce sans la moindre erreur visible. La solution n’est pas d’arrêter les mises à jour — les extensions obsolètes sont un risque de sécurité —, mais de retester les parcours importants — la commande, la structure des pages et la mise en page — juste après chaque mise à jour. C’est exactement ce que fait Relvato : son extension WordPress signale chaque mise à jour d’extension, de thème et du cœur dès qu’elle a lieu, et Relvato relance vos contrôles de commande, visuels et de structure en quelques minutes.
2. Code généré par IA et régressions du vibe coding
Les outils de programmation par IA font des changements rapides et étendus. Demandez à un assistant de « nettoyer le formulaire d’inscription » et il peut aussi renommer une route, supprimer un champ caché dont votre CRM avait besoin, retirer l’attribut de suivi sur lequel reposait votre analytique, ou régénérer un composant de zéro sans le cas particulier corrigé le mois dernier. Des outils comme Lovable, Bolt, v0 et Cursor peuvent réécrire des dizaines de fichiers en un seul prompt.
Le résultat est une régression qui a l’air voulue : le code est propre, il compile, la page s’affiche. Rien ne plante ; un bouton n’envoie simplement plus rien, ou un lien pointe vers une route déplacée. La relecture en attrape une partie, mais pas ce qui se passe sur un parcours complet. Relancer vos parcours clés après chaque push sur GitHub — pas seulement les tests unitaires — est ce qui la fait apparaître. La GitHub App de Relvato le fait à chaque push : elle relance vos vrais parcours utilisateurs dans un navigateur, pour qu’un champ supprimé ou une route déplacée soient signalés avant que vos clients ne tombent dessus.
3. Scripts tiers et ressources externes
Une grande partie de ce qu’exécutent vos visiteurs n’est pas hébergée chez vous : widgets de chat, SDK de paiement et antifraude, gestionnaires de balises, analytique, outils de test A/B, polices, cartes, badges d’avis et images sur un CDN. Ils se mettent à jour à leur propre rythme, et si vous les chargez depuis l’URL du fournisseur, vous recevez la nouvelle version dès sa publication — ou plus rien, s’il l’abandonne.
L’incident polyfill.io en 2024 a montré le cas extrême : un script très répandu a changé de propriétaire et s’est mis à servir du code malveillant à plus de 100 000 sites. Les cas du quotidien sont plus discrets — un widget de chat qui masque désormais le bouton de commande sur mobile, un conteneur du gestionnaire de balises modifié par quelqu’un, un point d’accès SDK obsolète qui renvoie une erreur, une image supprimée d’un CDN. Surveillez les erreurs JavaScript non interceptées, les images externes cassées et les nouvelles origines de scripts sur vos pages clés.
4. Changements de pare-feu, de WAF et de protection anti-bots
Les couches de sécurité changent sans aucun déploiement : une règle Cloudflare est durcie, un hébergeur active Imunify360 ou des règles ModSecurity plus strictes, une extension de sécurité met à jour sa liste de blocage, le mode anti-bots est activé. Chacun de ces changements peut se mettre à filtrer ou bloquer du trafic légitime — callbacks de paiement, webhooks, requêtes API de votre propre application, moteurs de recherche et robots IA, ou vrais clients derrière un VPN.
Ces pannes sont difficiles à voir de l’intérieur : vous êtes connecté, sur liste blanche ou sur une IP de confiance, donc tout fonctionne pour vous. Les visiteurs voient une page « Please wait while your request is being verified » ou une erreur 403. Quand la surveillance est bloquée elle aussi, un bon outil vous dit quelle couche en est responsable — l’edge du CDN, le pare-feu serveur de l’hébergeur ou une extension WordPress —, car chacune se corrige à un endroit différent (comment autoriser la surveillance).
5. Changements d’hébergement, de PHP et de serveur
Les hébergeurs mettent à jour les versions de PHP, déplacent les comptes vers de nouveaux serveurs, changent les limites de mémoire et modifient la configuration du serveur web — parfois avec un e-mail que vous n’avez pas lu. Chaque version de PHP rend des fonctions obsolètes ou les supprime : une extension qui fonctionnait hier peut se mettre à afficher des notices « Deprecated » sur vos pages, ou déclencher une erreur fatale qui remplace la commande par l’écran WordPress « Il y a eu une erreur critique sur ce site ».
Les migrations apportent leur propre dérive : un autre chemin serveur, une extension PHP manquante, un cron qui ne tourne plus et bloque les e-mails programmés et les renouvellements d’abonnements, ou des droits de fichiers qui empêchent les téléversements. Après tout changement d’hébergement, analysez vos pages clés à la recherche d’erreurs PHP et WordPress visibles, et vérifiez que les tâches de fond continuent d’être traitées.
6. Configuration du cache et du CDN
Le cache est invisible jusqu’à ce qu’il mette en cache la mauvaise chose. Un cache pleine page ou une règle CDN qui stocke la commande, le panier ou une page connectée peut servir la session d’un client à un autre, afficher un panier vide ou casser la connexion et les codes promo pour tout le monde. Les optimisations automatiques de plateforme de Cloudflare et les règles de cache agressives sont des coupables fréquents quand elles sont activées sans exclusions.
L’inverse arrive aussi : vider le cache après un déploiement révèle une page lente qui était masquée, ou un réglage de minification abîme un script. Comme la panne dépend de qui a demandé la page en premier, elle peut aller et venir — c’est pourquoi il faut un vrai navigateur qui vérifie le parcours client réel — comme une commande connectée ou la connexion —, pas seulement un code de statut.
7. Modifications courantes de contenu et de réglages
Toutes les pannes ne viennent pas du code. Quelqu’un renomme une page et tous les liens du menu vers l’ancienne URL renvoient désormais une 404. Un produit est supprimé et son image disparaît de trois pages catégorie. La case « Demander aux moteurs de recherche de ne pas indexer ce site » cochée en préproduction l’est toujours après le lancement. La commande en tant qu’invité est désactivée pour un test et jamais réactivée.
Ces modifications se font dans l’administration, souvent par des personnes qui ne les voient pas comme des changements du site. Ce sont aussi les plus faciles à repérer automatiquement : liens et images cassés sur les pages clés, noindex inattendu et commande qui oblige soudain les invités à se connecter sont autant de contrôles déterministes.
8. Ce qui expire en silence
Certaines pannes sont programmées le jour même où vous configurez quelque chose. Les certificats SSL expirent quand le renouvellement automatique échoue sans prévenir. Les noms de domaine expirent quand la carte enregistrée arrive à échéance. Les clés API et les identifiants de la passerelle de paiement sont renouvelés ou révoqués. Les licences d’extensions premium expirent, et l’extension ne reçoit plus les mises à jour de sécurité et de compatibilité que le reste de votre pile tient pour acquises.
L’expiration est la dérive la plus évitable, car la date est connue à l’avance. Vérifier la période de validité du certificat et tester les moyens de paiement que vos clients utilisent vraiment transforme une panne surprise en simple rappel.
9. Changements chez les fournisseurs de paiement, de livraison et d’API
Votre tunnel de commande dépend de services que vous ne contrôlez pas. Les prestataires de paiement retirent des versions d’API, changent les formats de webhook et durcissent les règles d’authentification forte ; les services de livraison et de taxes modifient tarifs et points d’accès ; les fournisseurs d’e-mail ajustent limites d’envoi et exigences d’authentification. Une passerelle peut disparaître discrètement de la commande parce que son extension exige désormais un réglage plus récent.
Le symptôme est généralement partiel : la plupart des commandes passent encore, mais un moyen de paiement manque, 3-D Secure échoue sur certaines cartes, ou les e-mails de confirmation n’arrivent plus. Vérifier que chaque moyen de paiement attendu est toujours proposé, et que les e-mails de confirmation arrivent réellement en boîte de réception, le repère sans effectuer de vrais paiements.
10. Compromissions de sécurité
Les attaquants provoquent la dérive volontairement et tentent de la garder invisible. Une extension vulnérable est exploitée pour injecter un skimmer de cartes dans la commande, un fichier backdoor est déposé dans le dossier des téléversements, un modèle du thème est modifié, ou un compte client est discrètement promu administrateur. Le site continue de fonctionner — c’est tout l’objectif.
Pour le repérer, il faut comparer à un état connu et sain : les fichiers du cœur et des extensions à leurs sommes de contrôle officielles, les fichiers de votre thème à une référence approuvée, la liste des administrateurs à celle attendue, et les origines externes qui chargent des scripts sur la commande à celles approuvées. Associez cela à une analyse de vulnérabilités pour corriger avant l’exploitation, pas après.
Comment repérer la dérive avant vos clients
Le schéma est le même pour les dix causes : quelque chose hors de votre processus de relecture a changé, et un parcours utilisateur a cassé sans erreur que vous remarqueriez. Les contrôles planifiés aident, mais laissent un trou entre le changement et la prochaine exécution. Le plus efficace est de revérifier juste après les changements qui causent la dérive — une mise à jour d’extension, de thème ou du cœur, un push sur votre dépôt, un changement de configuration — et de garder un rythme régulier pour tout le reste.
Relvato est construit autour de cette idée. Sous WordPress, son extension signale les mises à jour dès qu’elles ont lieu, et Relvato relance les contrôles susceptibles d’être touchés : parcours de commande et de connexion, régression visuelle et dérive structurelle, analyses d’erreurs et de liens cassés, et intégrité des fichiers et du thème. Sur n’importe quelle pile, un push sur un dépôt GitHub connecté fait de même. Quand un pare-feu bloque les contrôles, Relvato nomme la couche pour que vous sachiez où l’autoriser, et les références approuvées évitent que les changements voulus déclenchent deux fois une alerte.
Les 10 causes de dérive en un coup d’œil
| Cause | Ce qui change | Symptôme typique | Comment le repérer |
|---|---|---|---|
| Mises à jour WordPress | Cœur, extensions, thèmes, modèles WooCommerce | Champ de commande manquant, conflit d’extensions, mise en page modifiée | Contrôles de commande, visuels et de structure après chaque mise à jour |
| Code généré par IA | Composants, routes, formulaires, attributs de suivi | Bouton qui n’envoie plus, route déplacée, champ supprimé | Relancer les parcours clés à chaque push |
| Scripts tiers | Widgets, SDK, gestionnaires de balises, ressources CDN | Erreurs JavaScript, boutons bloqués, images cassées, nouvelles origines de scripts | Analyse d’erreurs, liens cassés, contrôle des origines de scripts |
| Pare-feu et WAF | Règles CDN, pare-feu serveur, extensions de sécurité | Pages de vérification, erreurs 403, webhooks et robots bloqués | Contrôles qui nomment la couche bloquante |
| Hébergement et PHP | Version de PHP, serveur, cron, extensions PHP | Notices Deprecated, écran d’erreur critique, tâches bloquées | Analyse d’erreurs et contrôle des tâches de fond |
| Cache et CDN | Cache de pages, règles de cache, minification | Panier vide, connexion cassée, sessions mélangées | Parcours de commande et de connexion dans un vrai navigateur |
| Contenu et réglages | Pages, menus, produits, réglages d’indexation et de commande | Liens 404, images manquantes, noindex, commande invité désactivée | Contrôles de liens cassés, SEO et commande |
| Ce qui expire | SSL, domaines, clés API, licences | Alertes de certificat, pannes, mises à jour manquantes | Contrôles d’expiration SSL et des moyens de paiement |
| Fournisseurs de paiement et d’API | API de paiement, webhooks, envoi d’e-mails | Moyen de paiement manquant, échec 3-D Secure, pas d’e-mail de confirmation | Contrôles des moyens de paiement et de la délivrance des e-mails |
| Compromissions de sécurité | Fichiers du cœur et du thème, administrateurs, scripts de commande | Skimmer sur la commande, administrateur intrus, backdoor déposée | Intégrité des fichiers et du thème, liste des administrateurs, analyse de vulnérabilités |
FAQ sur la dérive de site
Qu’est-ce que la dérive de site ?
La dérive de site est l’écart progressif entre le site que vous avez testé la dernière fois et celui que reçoivent maintenant les visiteurs, causé par des changements que personne n’a examinés ensemble — mises à jour automatiques, scripts tiers, changements d’hébergement et de pare-feu, modifications de contenu. Elle casse généralement un parcours, comme la commande ou l’inscription, plutôt que de mettre tout le site hors ligne.
Pourquoi mon site a-t-il cassé alors que je n’ai rien changé ?
Parce que quelque chose d’autre a changé. Les coupables les plus fréquents sont les mises à jour automatiques du cœur de WordPress, des extensions ou des thèmes, un script tiers publié dans une nouvelle version, une mise à niveau de l’hébergement ou de PHP, une règle de pare-feu ou de CDN modifiée, ou un certificat ou une clé API expirés. Regardez ce qui a été mis à jour ou modifié dans les heures précédant le problème.
Faut-il désactiver les mises à jour automatiques de WordPress pour éviter la dérive ?
En général, non. Les extensions obsolètes sont l’une des principales portes d’entrée des compromissions : désactiver les mises à jour échange la dérive contre un risque de sécurité. Il est plus sûr de continuer à mettre à jour et de retester automatiquement vos parcours clés — commande, connexion, formulaires — juste après chaque mise à jour.
Comment repérer les pannes causées par du code généré par IA ?
Traitez chaque changement assisté par IA comme un déploiement : exécutez les vrais parcours utilisateurs, pas seulement la compilation. Les contrôles qui comparent la structure des pages et les captures à une référence approuvée repèrent les champs supprimés et les boutons déplacés, et les lancer à chaque push sur votre dépôt attrape la régression avant les utilisateurs.
À quelle fréquence faut-il vérifier un site ?
Juste après les changements, et en plus selon un rythme régulier. Les contrôles déclenchés par événement repèrent la dérive quelques minutes après une mise à jour ou un déploiement ; un planning quotidien ou hebdomadaire couvre les changements que vous ne voyez pas venir, comme un certificat qui expire ou la mise à jour d’un script tiers.