Le 4 octobre 2026, vers midi, mes petits programmes qui vérifient mon comparateur après chaque mise en ligne ont tous reçu la même réponse : « 403 », accès refusé. Pourtant, dans mon navigateur, le site s'ouvrait normalement. Voici ce qui se passait, et comment je travaille depuis.

Ce que j'ai vu

Une erreur 403 veut dire : « le serveur a compris la demande, mais refuse d'y répondre ». En ouvrant le site dans un navigateur, j'ai vu passer, une ou deux secondes, une page d'attente : « Checking your browser ». Puis le site s'affichait.

Cette page vient du CDN de Hostinger. Un CDN est un réseau de serveurs qui garde une copie du site pour le servir plus vite. Celui de Hostinger sert aussi de filtre : quand il soupçonne un robot, il lui pose un petit test que seul un vrai navigateur sait passer.

Un humain ne voit presque rien. Un programme simple, comme mes scripts de vérification, échoue au test et reçoit 403.

Pourquoi elle s'est déclenchée

Je n'ai pas de certitude, mais le coupable le plus probable, c'était moi. Après chaque mise en ligne, mon script vérifiait tout le site d'un coup : chaque page, et surtout les 545 anciennes adresses d'un précédent site, une par une, pour contrôler qu'elles redirigent bien. Environ 600 demandes en quelques minutes, depuis la même connexion.

Pour un filtre anti-robots, ça ressemble exactement à une attaque ou à un aspirateur de site. Il a fait son travail.

Ce que je n'ai pas fait

On trouve des astuces pour faire passer un programme pour un navigateur et franchir ce genre de test. Je ne l'ai pas fait. Cette protection défend mon site, et la contourner, c'est apprendre à mes outils à faire ce que font les mauvais robots.

Je n'ai pas non plus coupé la protection : elle ne gênait que mes propres contrôles.

Comment je vérifie mon site maintenant

• Des contrôles légers après chaque mise en ligne. Une dizaine d'adresses choisies : les nouvelles pages, une ancienne adresse redirigée, une page absente pour voir la page d'erreur. Et pas 600.
• Dans un vrai navigateur. J'ouvre ces pages comme un visiteur, ce qui teste aussi l'affichage.
• Le gros contrôle seulement quand il le faut, par exemple après avoir changé les règles de redirection, et sur la copie locale du site plutôt qu'en ligne.

La page d'attente s'affichait encore brièvement le jour même vers 13 h 30. Le lendemain, elle ne s'affichait plus du tout. Si elle restait en permanence pour vos visiteurs, le réglage se trouve dans le panneau de Hostinger : c'est là qu'il faudrait regarder, plutôt que de chercher à la contourner.

Et Google, dans tout ça ?

C'était ma première inquiétude : si mes scripts sont bloqués, Google l'est-il aussi ? Rien ne l'indique. Les protections de ce genre reconnaissent les robots des grands moteurs de recherche. Et la Search Console de ce site montre des milliers d'apparitions dans Google sur la même période.

Deux autres surprises du même CDN

Ce n'était pas ma première rencontre avec ce CDN. Il garde aussi ses copies longtemps :

• Le fichier de style : après une mise à jour, l'ancien est resté affiché environ 33 heures. Depuis, mon site ajoute un numéro de version à la fin de l'adresse du fichier de style. Chaque modification change l'adresse, et le CDN va chercher la nouvelle version.
• Les images sont gardées sept jours. Pour changer une photo tout de suite, je change son nom de fichier.

Ce que j'en retiens

• Un 403 sur un site qui marche dans le navigateur, c'est souvent une protection, pas une panne.
• Mes propres outils peuvent ressembler à une attaque. Moins de demandes, mieux choisies, valent mieux.
• Ne pas contourner une protection qui fait son travail.

La vitesse d'un site dépend beaucoup de ce CDN et de ses copies. Je détaille ce qui compte vraiment sur ma page sur l'optimisation de la vitesse d'un site. Et si vous hébergez aussi un site en HTML simple, j'ai raconté sa mise en ligne pas à pas dans mon article sur l'hébergement chez Hostinger.

Tarmou