On s’imagine qu’une base de données volée chez un hébergeur, c’est un problème de RSSI, de notification CNIL et de changement de mots de passe en urgence. Oui, bien sûr. Mais quand on gère un site à fort trafic, l’incident OVH de début 2026 a surtout révélé une vérité que personne n’enseigne dans les formations SEO : une BDD compromise peut faire plus de dégâts sur vos positions Google qu’une migration ratée. Pas à cause de la pénalité « site piraté » que Google détecte parfois, mais à cause d’un effondrement mécanique de la performance que la Search Console ne vous remontera jamais avec une petite alerte rouge. Elle vous le dira à sa façon : des URLs « découvertes mais non indexées » qui s’accumulent, un temps passé à télécharger la page qui double, un LCP qui passe au rouge sur toute la catégorie. Et vous, vous cherchez du côté d’un bundle JS alors que le coupable mouline dans un datacenter à Roubaix.
Une BDD piratée, c’est du TTFB sous stéroïdes
Quand un attaquant exfiltre le contenu d’une base OVH, il ne se contente pas de copier des fiches clients. Il exécute des requêtes souvent massives, parfois pendant des heures, en saturant les disques et le buffer pool. Résultat immédiat : chaque requête légitime se met à ramer. Le pire, c’est que les pages servies peuvent paraître « fonctionner » parce que le rendu côté client ne flanche pas, mais le Time To First Byte, lui, dévisse. On a vu des TTFB passer de 120 ms à 2,8 secondes en une après-midi, sans aucune alerte sur le front parce que le CDN masquait la latence pour les visiteurs déjà connectés. Sauf que Googlebot, lui, ne bénéficie pas du cache CDN local. Il tape le serveur d’origine. Du coup, chaque crawl enregistre un temps de réponse dégradé et l’algorithme de planification réduit la cadence.
⚠️ Attention : un TTFB dégradé n’impacte pas que l’image de marque. Quand il dépasse 800 ms de manière constante, Google peut interpréter le serveur comme surchargé et diminuer le crawl de 30 à 40 % sans prévenir.
Le crawl budget assassiné sans préavis
J’ai un client qui a découvert le piratage de sa base de données OVH en ouvrant le rapport de couverture d’indexation, pas le ticket de l’hébergeur. Sur un mois, il perdait 15 000 pages dans l’index. Le support OVH n’avait pas encore fini son diagnostic que nous, on avait déjà les logs : des centaines d’erreurs 500 intermittentes, des temps de réponse moyens au-dessus de 2 secondes, et une facture de crawl en chute libre. Les moteurs de recherche ne sont pas patients. Si votre serveur bafouille, Googlebot ne campe pas en espérant que ça aille mieux : il désalloue du budget de crawl et repasse plus tard. Si « plus tard » tombe après la publication d’une nouvelle collection ou d’un article stratégique, vous pouvez attendre trois semaines pour que la page soit indexée. Et trois semaines en e-commerce, c’est un lancement mort-né.
Le mécanisme est documenté depuis longtemps. Ce qui l’est moins, c’est la corrélation directe entre un incident de sécurité et une baisse du crawl budget. On parle souvent d’optimiser le fichier robots.txt, de supprimer les facettes infinies, d’améliorer le maillage interne. Mais si votre machine de base de données est sous l’emprise d’une exfiltration, toute cette ingénierie est anéantie en quelques heures. Un audit optimisation core web vitals peut vous aider à cartographier les dépendances entre le serveur SQL et les métriques de performance, mais encore faut-il penser à le relancer après un incident de sécurité, ce que presque personne ne fait.
La charge fantôme des connexions non fermées
Au-delà du vol de données lui-même, un piratage exploite souvent une faille applicative : mauvaise gestion des connexions à la base, absence de timeout, pool mal dimensionné. L’attaquant n’a pas besoin de sortir la totalité de la base en une seule requête. Il peut générer des milliers de connexions lentes qui épuisent le nombre de threads disponibles. Et là, même quand la brèche est colmatée, il reste un héritage dégueulasse : un pool de connexions configuré pour la paix, pas pour la guerre. Les développeurs ont mis max_connections=200 parce que « 200 c’est bien » et que personne n’a jamais mesuré la consommation réelle. Résultat, après l’incident, le redémarrage du serveur ne règle rien, il faut patch le code.
C’est exactement le genre de situation où un IDE boosté à l’IA comme Claude Code ou Cursor change la manière de diagnostiquer. Plutôt que de fouiller à la main les fichiers de configuration MySQL et les chaînes de connexion dans vingt micro-services, un assistant qui comprend votre base de code peut identifier en quelques minutes les endpoints qui ne referment jamais leurs curseurs ou qui utilisent des connexions persistantes sans timeout. Un gain de temps qui, en post-incident, évite que le TTFB reste élevé pendant une semaine de plus.
Le piège des sauvegardes automatiques OVH
Beaucoup croient qu’activer les sauvegardes automatisées OVH suffit à dormir sur ses deux oreilles. C’est vrai pour la restauration des données, mais totalement faux pour la performance post-incident. Quand une base est restaurée après un piratage, elle est souvent réinjectée dans un environnement qui n’a pas changé : mêmes identifiants, mêmes droits, mêmes applications qui la sollicitent. Si la cause racine est une faille SQL dans une API publique, la base restaurée sera à nouveau vulnérable. Pire, la phase de restauration elle-même peut saturer le serveur : une base de 200 Go restaurée depuis un backup OVH en pleine journée, c’est une charge supplémentaire qui coïncide avec le trafic organique. Le TTFB explose une seconde fois, et Googlebot se souvient de la double peine.
Dans un article sur le state management React avec Zustand, j’expliquais comment des appels API redondants dus à une mauvaise gestion d’état client pouvaient inonder la base de données. Après un incident de sécurité, ces défauts deviennent critiques. Ne pas dupliquer une session, ne pas relancer un fetch à chaque useEffect non maîtrisé : ce sont des principes de performance qui, en temps normal, font gagner 200 ms. En temps de crise, ils font gagner des heures de disponibilité.
Pourquoi Google n’affiche pas d’alerte « sécurité » mais vous sanctionne quand même
Le mythe veut qu’un site piraté reçoive une notification « Ce site peut être piraté » dans les SERP ou une alerte dans Search Console. Ça arrive, mais seulement si Google détecte une injection de contenu visible : des liens de spam, du pharma hack, une redirection. Quand le piratage se limite à une exfiltration silencieuse de la base, sans altération des pages, Google ne lève aucun drapeau. Votre site n’est pas « hacked » aux yeux de l’utilisateur. Pourtant, il subit de plein fouet la dégradation des signaux de classement : temps de réponse, disponibilité, taux d’erreurs 500. En clair, vous perdez des positions sans jamais savoir que la cause n’est pas une concurrence accrue, mais un vol de données dont vous n’avez pas encore mesuré l’impact sur la performance.
💡 Conseil : après tout incident de sécurité, lancez un audit de performance ciblé sur les endpoints qui sollicitent la base. Ne vous fiez pas au rapport Lighthouse global qui pourrait être neutralisé par le cache navigateur. Utilisez l’API CrUX pour voir la distribution réelle des métriques par type de page.
Reconstruire la confiance de Googlebot après un incident OVH
Une fois la base restaurée et sécurisée, le plus dur n’est pas technique, c’est la patience. Googlebot a réduit la fréquence de crawl, et il ne l’augmentera pas avant d’avoir constaté plusieurs jours de stabilité. Pour accélérer le processus, il faut d’abord lui fournir un sitemap propre et à jour, surtout si des URLs ont été générées en erreur pendant l’incident. Ensuite, il faut surveiller le rapport de statistiques de crawl comme le lait sur le feu. Une remontée progressive du nombre de requêtes crawlées par jour est le signe que la machine reprend confiance. On peut aussi forcer prudemment une recrawl via l’outil d’inspection d’URL pour les pages stratégiques, mais sans en abuser.
Cette phase de convalescence est le moment idéal pour tester des optimisations que vous repoussiez. Par exemple, segmenter les connexions à la base en lecture seule pour les pages de catégorie, implémenter un cache applicatif pour les requêtes coûteuses, ou revoir la stratégie de chargement lazy des commentaires. Ce sont des leviers qui, en temps normal, améliorent le LCP de quelques centaines de millisecondes ; après un incident, ils montrent à Google que votre temps de réponse n’est pas seulement revenu à la normale, mais qu’il est devenu structurellement plus robuste.
Questions fréquentes
Les backups OVH automatiques protègent-ils contre un piratage ?
Elles permettent de restaurer les données, pas de stopper l’attaque. Si la faille applicative persiste, la base restaurée sera à nouveau compromise. Les backups réduisent le temps d’indisponibilité des données, mais l’impact sur le TTFB et le crawl subsiste tant que la brèche n’est pas corrigée dans le code.
Faut-il changer d’hébergeur quand sa BDD OVH a été piratée ?
Changer d’hébergeur ne règle rien si la vulnérabilité est côté applicatif. Beaucoup de piratages exploitent une injection SQL, pas une faille de l’infrastructure OVH. Avant de migrer, auditez votre code. L’hébergeur peut vous fournir les logs, mais la correction vous incombe.
Un piratage de BDD peut-il impacter les données structurées et le rich snippet ?
Indirectement, oui. Si les données structurées sont générées dynamiquement depuis la base, une corruption partielle ou une lenteur côté serveur peut renvoyer des JSON-LD incomplets ou des erreurs 500. Cela peut faire disparaître un rich snippet produit jusqu’à la résolution complète du problème de performance.
