Image qui ne s'affiche pas sur votre site
Si une image ne s'affiche chez aucun visiteur, le défaut est sur le site : le serveur répond par une erreur au lieu d'envoyer le fichier, parce qu'il a été supprimé, déplacé ou que son adresse est fausse. Si elle ne manque que chez vous ou chez un seul visiteur, la cause est plus souvent sur l'appareil : une extension, une connexion, un réglage.
Les images ne sont pas seules en cause : feuilles de style, scripts et polices manquent de la même façon, souvent sans que rien ne se voie. Ces fichiers introuvables font partie de ce que relève l'audit de fiabilité d'un site.
Chez le visiteur ou sur le site : deux problèmes différents
La plupart des réponses en ligne s'adressent au visiteur : vider le cache, changer de navigateur. Elles règlent un problème local. Quand le défaut est sur le site, chaque visiteur reçoit la même erreur, et rien de ce qu'il fait ne la corrige.
Chaque fichier demandé par une page reçoit un code de réponse. Les codes de statut HTTP de la famille 400 signalent une demande que le serveur ne peut pas satisfaire, le plus connu étant le 404, « introuvable ». Ceux de la famille 500 signalent une panne du serveur. Dans les deux cas, le fichier n'arrive pas.
Une image manquante se voit, un script ou une police non
Le navigateur ne signale rien au visiteur. Il affiche la page avec ce qu'il a reçu, et l'effet dépend du fichier qui manque.
- Une image : un cadre vide ou une icône cassée à sa place, souvent sur une fiche produit ou une page de présentation.
- Une feuille de style : la mise en page se défait en partie, ou entièrement si c'est la feuille principale.
- Un script : la fonction qu'il portait ne répond plus, comme avec une erreur JavaScript, mais sans qu'aucun script n'ait échoué. Le fichier n'est simplement jamais arrivé.
- Une police : le texte s'affiche dans une police de remplacement. Le contenu reste lisible, la page ne ressemble plus à votre charte.
D'où viennent les fichiers introuvables
Un fichier introuvable a presque toujours une origine qu'on peut dater : un changement sur le site, ou chez un service dont il dépend.
- Une migration ou une refonte : les fichiers changent de dossier, mais les pages et les articles écrits avant continuent de pointer vers les anciennes adresses.
- Un fichier supprimé de la médiathèque alors qu'une page l'utilise encore. Rien ne prévient au moment de la suppression.
- Une ressource servie par un autre service qui a disparu ou changé d'adresse : un module intégré, une bibliothèque hébergée ailleurs, un service arrêté.
- Un service de redimensionnement d'images qui refuse une demande mal formée : il répond par une erreur 400 plutôt qu'un 404, et l'image manque tout autant.
Pourquoi le propriétaire du site ne le voit pas
Votre navigateur garde une copie des fichiers déjà reçus et la réutilise tant qu'elle est considérée comme fraîche, sans rien redemander au serveur. La documentation de référence sur la mise en cache HTTP décrit ce fonctionnement. Un fichier supprimé du serveur peut donc continuer de s'afficher chez vous, alors que chaque nouveau visiteur reçoit une erreur.
D'autres raisons s'ajoutent : vous consultez le site connecté, sur les pages que vous connaissez, et les images placées plus bas ne se chargent qu'au défilement. Le défaut vit sur une page que vous n'ouvrez pas, ou à un endroit que vous ne faites pas défiler.
Ce que l'audit relève, et ce qu'il écarte
L'audit charge chaque page de l'échantillon dans un navigateur, comme un premier visiteur. Il la fait défiler pour déclencher les images chargées à la demande, puis relève chaque fichier que la page a réellement demandé et le code reçu. Le rapport donne l'adresse du fichier, son code exact et les pages concernées.
Une ressource compte comme cassée quand elle reçoit un code de la famille 400 ou 500. Trois cas sont écartés, parce qu'ils ne désignent pas un fichier manquant :
- Une ressource protégée (codes 401 et 403) : elle demande une connexion ou une autorisation. C'est noté comme une observation, pas comme un défaut.
- Un refus temporaire du serveur (codes 429 et 503). Pendant un audit, il est le plus souvent provoqué par le rythme de nos propres visites, et le même fichier répond souvent normalement quand on le redemande.
- Une adresse présente dans le code que la page ne demande jamais, par exemple une image de repli que le navigateur n'a pas eu besoin de charger. Seul ce qu'un visiteur reçoit compte.
Le navigateur écrit aussi un message dans la console quand un fichier ne se charge pas. Ce message est le même défaut vu une seconde fois : l'audit le compte ici, une seule fois, et pas comme une erreur JavaScript. Un seul fichier manquant, demandé par le modèle commun, peut ainsi apparaître sur toutes les pages du site : l'avertissement ne compte alors qu'une fois, et le rapport cite les pages touchées.
Ce qui se corrige simplement, ce qui demande un projet
Un fichier demandé par le modèle commun du site, un logo, une icône ou un fichier de configuration, se corrige une fois pour toutes les pages : remettre le fichier, ou retirer la référence. Un service tiers disparu se remplace ou se retire.
Après une migration, des centaines de pages peuvent pointer vers d'anciennes adresses. Les réécrire, ou rediriger les anciennes adresses vers les nouvelles, est un chantier à planifier, et il se vérifie ensuite page par page.
Ce que cette vérification ne dit pas
Nous voyons les fichiers demandés par les pages de l'échantillon, au chargement et pendant le défilement. Ceux qui ne se chargent qu'après un clic, dans une galerie, un onglet ou une page connectée, restent hors de portée.
Un fichier qui échoue par intermittence peut répondre normalement au moment de notre visite. Nous relevons le code reçu, pas la raison pour laquelle le fichier a disparu.
À lire ensuite
Erreurs JavaScript : ce qu'elles cassent
Une erreur JavaScript au chargement peut bloquer un menu ou un formulaire, ou ne rien changer du tout. Ce qui fait la différence, et ce que l'audit relève.
Lire le guide →