Erreurs JavaScript : ce qu'elles cassent

Une erreur JavaScript, c'est un script de la page qui s'arrête en cours de route. Son effet dépend de ce qu'il faisait : s'il ouvrait le menu ou vérifiait un formulaire, cette fonction ne répond plus ; s'il mesurait l'audience, le visiteur ne remarque rien.

Le reste de la page continue de fonctionner, et c'est pour cela qu'une erreur passe si souvent inaperçue. Les erreurs au chargement font partie de ce que vérifie l'audit des bugs et de la fiabilité d'un site.

Ce qui se passe quand un script échoue

Quand un script rencontre une erreur que rien ne prévoit, il s'interrompt. La documentation de référence de JavaScript le dit simplement : sans bloc qui intercepte l'erreur, « le programme sera terminé ». Les instructions qui suivaient ne s'exécutent pas.

Les autres scripts de la page, eux, continuent. Le navigateur n'affiche rien au visiteur : il inscrit l'erreur dans la console, un panneau réservé aux développeurs que personne n'ouvre en naviguant. Le visiteur constate seulement qu'un bouton ne fait rien.

Ce qu'une erreur peut casser, et ce qu'elle laisse intact

La gravité d'une erreur tient à la fonction du script arrêté, pas au message lui-même. Les mêmes mots dans la console peuvent signaler une panne du formulaire de devis ou un compteur de statistiques qui ne compte plus.

  • La navigation : sur mobile, le menu s'ouvre souvent par un script. S'il échoue, les pages restent en ligne mais le visiteur ne les trouve plus.
  • Les formulaires : un script qui vérifie les champs ou envoie la demande peut laisser le bouton sans effet, sans aucun message.
  • Le panier et la commande : ajout au panier, choix d'une taille, calcul des frais. Le visiteur voit le produit et ne peut pas l'acheter.
  • La mesure d'audience et les outils marketing : le visiteur ne voit aucune différence, mais vos chiffres de fréquentation sont faux sans que rien ne le signale.
  • Les éléments d'affichage, comme un carrousel ou une galerie : le contenu est là, mais une partie peut rester masquée.

Ce que nous relevons sur les sites audités

55 %présentent au moins une erreur d'exécution JavaScript au chargement de leurs pages

Ce pourcentage porte sur une trentaine de sites audités entre le 14 août 2026 et le 24 septembre 2026, ceux où le point a pu être vérifié. Beaucoup ont été audités parce qu'un défaut s'y voyait vite : le chiffre décrit nos audits, pas l'ensemble des sites.

Ce chiffre ne veut pas dire que ces sites sont en panne. Il dit qu'au moins un script a échoué ; l'effet dépend de ce que faisait ce script. C'est pour cette raison que le rapport cite chaque message et la page où il se produit, au lieu d'un simple total.

Tout ce que la console marque « erreur » n'en est pas une

L'outil d'audit de Google, Lighthouse, relève toutes les erreurs inscrites dans la console. Or la console mélange des messages de natures différentes, et un total brut compte des pannes qui n'en sont pas. Avant de compter, l'audit trie chaque message.

  • Les erreurs d'exécution : un script qui échoue pendant le chargement. Ce sont les seules comptées ici.
  • Les messages du navigateur sur la configuration du site, par exemple une politique de sécurité mal rédigée. Aucun script n'a échoué : ces messages relèvent de l'audit de sécurité.
  • Les messages sur un fichier qui n'a pas pu se charger. Le défaut, c'est le fichier manquant : il est compté une seule fois, avec les images et fichiers introuvables.
  • Les messages qu'un script du site écrit volontairement dans la console. La page fonctionne : ils sont notés pour mémoire, sans être comptés comme des erreurs.

Une erreur au chargement ne dit pas toujours ce qu'elle bloque. Quand cela peut se faire sans rien modifier chez vous, l'audit actionne aussi les contrôles de la page, car un bouton qui ne déclenche rien est une panne invisible sur une capture d'écran. Le rapport distingue ce qui a réellement été actionné de ce qui a seulement été observé.

Les scripts d'autres éditeurs comptent aussi

Une page charge souvent des scripts écrits par d'autres : fenêtre de discussion, mesure d'audience, publicité, vidéo intégrée, gestion du consentement. Ils s'exécutent dans votre page, et leurs erreurs apparaissent dans la même console que celles de votre code.

Le visiteur ne fait pas la différence : c'est votre site qui ne répond pas. L'audit compte donc ces erreurs avec les autres. Le message cité dans le rapport désigne souvent le fichier en cause, ce qui indique à qui s'adresser.

Ce qui se corrige simplement, ce qui demande un projet

Une erreur qui revient sur toutes les pages vient le plus souvent d'un élément commun : un modèle de page, une extension, un script ajouté dans l'en-tête. Une seule correction la supprime partout. Un script tiers en échec se met à jour, se reconfigure ou se retire, souvent sans toucher au reste du site.

Les erreurs qui tiennent au code propre du site demandent plus de travail, surtout quand elles viennent d'une bibliothèque ancienne ou d'une version dépassée du cadre de développement. Corriger une erreur qui ne casse rien reste utile : une console pleine de messages connus cache ceux qui apparaîtront demain.

Ce que cette vérification ne dit pas

Nous relevons les erreurs qui se produisent au chargement des pages de l'échantillon, puis pendant leur défilement. Les erreurs d'un parcours connecté, d'un espace client ou d'une étape qui suit l'envoi d'un formulaire restent hors de portée : l'audit n'envoie aucun formulaire et ne crée aucun compte.

Les pages sont chargées dans un seul navigateur. Une erreur propre à un autre navigateur, à un appareil ancien ou à une extension installée chez un visiteur peut nous échapper.

Par Quentin Mathis, Z29K · mis à jour le 28 septembre 2026

À lire ensuite

Image qui ne s'affiche pas sur votre site

Une image cassée pour tous vos visiteurs vient du site, pas de leur navigateur. Les causes, les fichiers qui cassent sans se voir, et ce que l'audit relève.

Lire le guide →