Pourquoi certains sites chargent-ils le texte mais pas les images avec un VPN ? Le problème peut être le tunnel, pas le site

Le site n’était pas vraiment en panne. C’est justement ce qui m’a fait perdre du temps.

Je devais commander une pièce avant la fermeture du service d’expédition. La page produit s’ouvrait normalement : nom, prix, dimensions, bouton d’achat.

À la place des photos, en revanche, j’avais des rectangles gris. Actualiser. Toujours gris.

Navigation privée. Même chose. J’ai vidé le cache, désactivé une extension, essayé un autre navigateur.

Le texte continuait à apparaître presque immédiatement. Les images, non. Puis j’ai coupé le VPN.

Toutes les photos sont arrivées. Je l’ai réactivé. Rectangles gris.

À cet instant, j’ai pensé avoir compris : le site devait simplement bloquer les VPN. C’était une explication rassurante parce qu’elle était simple. Elle était aussi trop simple.

Une page web n’arrive pas en un seul morceau

Le détail qui m’avait échappé était pourtant visible depuis le début. Le site ne refusait pas réellement de me parler. Il m’avait déjà envoyé son texte.

Un navigateur ne reçoit pas une page comme un document fermé contenant immédiatement tout ce qu’il faut afficher. Il récupère le HTML, commence à construire la page, puis demande séparément les images, les feuilles de style, les scripts et les autres ressources qu’il rencontre.

Certaines de ces ressources peuvent en plus être distribuées par une infrastructure différente de celle qui a envoyé le HTML. Les CDN servent couramment les images, CSS et JavaScript séparément du contenu principal.

Autrement dit, voir le titre et le prix d’un produit ne prouve pas que le chemin utilisé pour récupérer ses photos fonctionne correctement.

Ma page n’était donc plus « chargée ou bloquée ». Elle ressemblait plutôt à une livraison en plusieurs colis : les premiers étaient arrivés, les suivants s’étaient perdus quelque part. Et le VPN se trouvait précisément sur leur trajet.

Sous une seule page, plusieurs chemins peuvent cohabiter

Ce comportement est d’autant moins étrange aujourd’hui que les connexions Internet françaises ne reposent plus sur un environnement parfaitement uniforme.

Le baromètre IPv6 de l’Arcep publié en juillet 2026 montre l’ampleur de la transition : fin 2025, 94 % des clients fixes grand public avaient IPv6 activé, alors que 38 % des sites web étaient disponibles en IPv6. IPv4 et IPv6 continuent donc à cohabiter, avec différents mécanismes permettant aux deux mondes de fonctionner ensemble.

Cela ne signifie pas qu’IPv6 est responsable de mes images grises.

Ce chiffre m’a surtout rappelé une chose : derrière une page qui paraît simple, mon navigateur peut ouvrir plusieurs connexions dont les chemins ne se comportent pas exactement de la même manière.

Puis j’ajoute un VPN. Le trafic entre dans un tunnel, avec son propre emballage.

Et c’est là qu’une vieille notion de réseau que j’avais toujours considérée comme un problème d’administrateur système est devenue beaucoup plus concrète.

La MTU.

Mon tunnel pouvait laisser passer les petits paquets et trébucher sur les gros

MTU signifie Maximum Transmission Unit. Le nom est plus compliqué que l’idée. Imaginez une série de portes sur le chemin entre mon ordinateur et le serveur.

Mon ordinateur prépare des cartons. Le tunnel VPN ajoute une couche d’emballage autour. Tout fonctionne tant que le carton final passe par la porte la plus étroite.

S’il devient trop gros, le réseau doit normalement comprendre qu’il faut utiliser une taille plus adaptée. Lorsque ce mécanisme échoue, on peut obtenir ce que l’IETF décrit depuis longtemps comme un « PMTU black hole » : les petites communications continuent à passer, tandis que certains transferts plus importants bloquent ou expirent.

Soudain, mes rectangles gris n’avaient plus rien d’absurde. Le HTML arrivait. La page commençait à se dessiner.

Puis certaines ressources plus lourdes restaient suspendues. Je n’avais plus besoin d’imaginer un site capable de détecter mon VPN et de décider mystérieusement : « le texte, oui ; les photos, non ». Le tunnel lui-même pouvait être la partie qui coinçait.

Un utilisateur WireGuard avait rencontré un symptôme presque identique

Une discussion publique autour de WireGuard m’a surtout convaincu d’arrêter de traiter cette piste comme une curiosité théorique.

Un utilisateur racontait qu’un tunnel parfaitement utilisable chez lui devenait problématique sur certains réseaux à l’étranger : pages qui expiraient, photos Twitter ou WhatsApp qui ne chargeaient plus, images absentes sur certains sites.

Sans WireGuard, le réseau fonctionnait. Avec OpenVPN vers la même machine, il fonctionnait aussi. La discussion s’est orientée vers la MTU. Après l’avoir réduite, l’utilisateur a indiqué que le problème avait disparu lors de son test suivant.

Ce qui m’intéressait n’était pas de décréter que chaque rectangle gris venait forcément de là. C’était le motif. Un VPN peut sembler fonctionner parce que la page commence à charger, tout en échouant sur une partie des ressources qui arrivent ensuite.

À partir de là, changer encore une fois de navigateur n’avait plus beaucoup de sens.

Mon grand VPN me donnait beaucoup de moyens de chercher

J’utilisais déjà un fournisseur connu. Il avait de nombreuses localisations, plusieurs protocoles et suffisamment d’options pour mener un vrai diagnostic. J’ai changé de serveur français.

Les premières images sont apparues. J’ai cru avoir terminé. Puis j’ai ouvert une deuxième fiche produit.

Deux photos sur six. Autre serveur. Cette fois, la page d’accueil s’affichait correctement, mais une galerie restait bloquée.

Je pouvais continuer. Changer de protocole. Chercher un réglage MTU.

Tester plusieurs valeurs. Comparer IPv4 et IPv6. Reconnecter.

Actualiser. Recommencer. Pour quelqu’un qui veut contrôler précisément son tunnel, cette liberté est utile.

Mais j’avais une pièce à identifier et une commande à passer avant la fin de l’après-midi. Je n’avais pas ouvert mon ordinateur pour transformer une galerie de produits en séance de diagnostic réseau. C’est là que mon critère a changé.

Je ne cherchais plus le VPN qui me donnait le plus de moyens de comprendre pourquoi la page était cassée.

Je cherchais celui qui pouvait simplement me rendre la page entière.

J’ai essayé le petit service avant de toucher à la MTU

J’ai fermé le premier VPN et ouvert la seconde application.

Au lieu de commencer par choisir un protocole, une ville puis une série de paramètres, j’ai utilisé son mode automatique adapté à la connexion disponible.

Connexion. Retour au site. Actualiser.

Le titre est apparu. Le prix. Puis la première photo.

La deuxième. La galerie entière. J’ai ouvert une autre fiche.

Les images ont suivi.

Je suis revenu à la pièce qui m’intéressait, agrandi la photo du connecteur, lu la référence imprimée sur le côté et comparé avec celle que j’avais sur mon bureau.

C’était la bonne. Ajouter au panier. Paiement.

Confirmation. À ce moment-là, le problème était terminé.

Et c’est seulement après avoir passé la commande que j’ai eu envie de comprendre pourquoi je n’avais eu à modifier aucun de ces réglages que j’étais prêt à toucher quelques minutes plus tôt.

La technique devenait intéressante après le résultat, pas avant

Le service utilise un transport basé sur HTTP/3, lui-même construit sur QUIC. Pendant les essais préparés pour cet article, cette approche a permis aux pages problématiques de terminer leurs chargements sans que j’aie à régler manuellement la MTU ni à poursuivre la rotation des serveurs.

QUIC dispose justement de mécanismes destinés à tenir compte de la taille des datagrammes que le chemin peut réellement transporter. Sa spécification prévoit l’utilisation de méthodes de découverte de la MTU du chemin afin d’éviter de continuer à envoyer des paquets trop gros pour le passage disponible.

Je n’avais pas besoin de beaucoup plus de théorie. Mon premier tunnel ressemblait à quelqu’un qui insistait avec une valise trop grande devant le même compartiment. Le second s’adaptait mieux au passage.

Ce qui comptait pour moi était visible à l’écran : avec le premier, je regardais des rectangles gris ; avec le second, je pouvais zoomer sur la photo dont j’avais besoin.

J’ai ouvert d’autres pages avant de croire au résultat

Une seule galerie réussie pouvait être un hasard. J’ai donc rouvert plusieurs pages qui avaient présenté le même comportement pendant les essais. Un catalogue rempli de miniatures.

Une page d’actualité riche en photos. Un site où certaines images n’apparaissaient auparavant qu’après plusieurs actualisations. Cette fois, les pages allaient jusqu’au bout.

Pas seulement le texte. Les ressources visuelles aussi. Je n’ai même plus regardé immédiatement quel tunnel affichait le meilleur débit maximal.

Le chiffre avait perdu une bonne partie de son importance. Pour une page web, 300 Mbit/s qui me laissent quatre images grises sont moins utiles qu’un débit moins spectaculaire qui termine toutes les requêtes. Je pensais comparer des VPN selon leur vitesse.

Je devais comparer leur capacité à finir ce que la page avait commencé.

Toutes les images manquantes n’accusent pas le VPN

Il reste un contrôle très simple.

Si les mêmes images sont absentes lorsque le VPN est coupé, je cherche ailleurs : site, CDN, navigateur, extension ou ressource réellement indisponible. Cloudflare documente d’ailleurs plusieurs causes côté site pouvant produire des images manquantes.

Mais lorsque le motif ressemble à celui que j’avais devant moi — VPN coupé : images présentes ; premier VPN activé : images absentes ;

autre tunnel : images présentes — je ne commence plus par vider le cache cinq fois. Je regarde le tunnel.

Le petit service garde aussi une limite crédible : il dispose de moins de localisations et de moins de recul public que les grands fournisseurs installés depuis longtemps. Si je voulais sélectionner manuellement une ville très précise ou disposer d’un maximum de réglages réseau, mon fournisseur habituel resterait plus flexible.

Ce jour-là, cette flexibilité était précisément ce dont je n’avais plus envie.

Je n’ai finalement modifié aucun réglage réseau

J’avais commencé avec un problème qui ressemblait à un bug de navigateur. Puis j’avais imaginé un blocage volontaire des VPN. Quelques minutes plus tard, j’étais prêt à modifier la MTU.

Je n’ai finalement fait aucune de ces choses. J’ai changé de tunnel. La page s’est chargée jusqu’au bout.

La photo m’a permis d’identifier la pièce. La commande est partie.

Et mon critère est devenu beaucoup plus concret : quand un VPN laisse passer le texte mais abandonne les images, je préfère celui qui s’adapte assez bien au chemin pour terminer la page à celui qui me donne dix réglages supplémentaires pour comprendre pourquoi elle reste à moitié vide.