Pourquoi les sites web cassent en silence dans les autres navigateurs

Le signalement a un air familier : « Chez moi, la page a l'air cassée. » La développeuse ouvre la page, voit — rien. Tout est à sa place. Seul le rappel téléphonique éclaire la situation : le client utilise Safari sur iPhone, elle Chrome sur ordinateur de bureau. Entre les deux se glissent deux moteurs de rendu, plusieurs largeurs d'écran et une série de différences silencieuses dont aucune n'a jamais produit le moindre message d'erreur.

Que le même site puisse avoir une autre allure selon le navigateur n'est pas un accident d'exploitation, mais de l'architecture. Au cœur de chaque navigateur travaille un moteur de rendu qui traduit HTML et CSS en pixels. Trois familles se partagent aujourd'hui la quasi-totalité du marché : Blink anime Chrome, Edge et la plupart des dérivés plus modestes de Chromium, Gecko anime Firefox, WebKit anime Safari — et sur l'iPhone, pratiquement tous les navigateurs répandus effectuent aujourd'hui encore leur rendu avec WebKit, même quand l'icône affiche Chrome ou Firefox.

Ces moteurs sont des implémentations indépendantes des mêmes standards du web. Les standards décrivent ce qu'une propriété CSS doit produire — mais ils laissent des marges, ils sont mis en œuvre à des rythmes différents, et il arrive que deux équipes de développement comprennent différemment la même formulation. Le résultat, ce sont trois programmes qui lisent le même document et aboutissent à des images légèrement différentes. La plupart du temps, les différences sont invisiblement petites. Parfois non.

Le point décisif : ces différences restent muettes. CSS a été conçu à dessein pour tolérer les erreurs. Une propriété qu'un navigateur ne connaît pas est simplement ignorée — sans avertissement, sans plantage, sans entrée dans le moindre journal. Ce qui est une bénédiction lors de l'introduction de techniques nouvelles, parce que les vieux navigateurs ne sanctionnent pas les feuilles de style modernes par une panne totale, devient un piège au quotidien : la page ne casse pas, elle a seulement l'air fausse. Et personne ne l'apprend tant que personne ne regarde.

Les points de rupture typiques se laissent classer. Il y a d'abord les fonctions CSS récentes qu'un moteur maîtrise déjà et qu'un autre ne maîtrise pas encore, ou autrement dans le détail. Il y a les questions d'interprétation de la mise en page — la façon dont Flexbox et Grid traitent les largeurs minimales, les retours à la ligne ou les conteneurs imbriqués, là où la spécification laisse une marge d'interprétation. Et il y a les classiques : les éléments de formulaire comme les listes déroulantes, les cases à cocher et les champs de date, que chaque navigateur dessine à son propre goût et que l'on ne peut remodeler que dans une mesure limitée.

Un exemple de la première catégorie rend le schéma tangible. La propriété CSS gap, qui règle les espacements entre éléments, était disponible tôt dans tous les moteurs pour la mise en page Grid — dans le contexte de Flexbox, en revanche, Safari ne l'a prise en charge que nettement plus tard que Chrome et Firefox. Une navigation dont les entrées de menu étaient tenues à distance par Flexbox et gap avait fière allure dans deux moteurs ; dans les versions plus anciennes de Safari, les entrées se collaient les unes aux autres. Aucun message d'erreur, aucun plantage, techniquement tout fonctionnait — la page paraissait seulement tassée et négligée sur une partie des iPhone. Le remède, dans de tels cas, est une solution de repli avec des marges extérieures classiques ; encore faut-il savoir que la différence existe. C'est là, précisément, le véritable obstacle des ruptures silencieuses : elles ne figurent dans aucune liste d'erreurs. Elles ne figurent que dans l'image.

S'y ajoutent des différences qui ne figurent pas du tout dans la feuille de style. Les polices sont rendues différemment sur chaque système d'exploitation et occupent des largeurs différentes ; un titre qui tient sur une ligne dans un environnement passe à la ligne dans l'autre et pousse tout ce qui se trouve dessous vers le bas. Les barres de défilement prennent, selon le système, de la place au contenu ou se posent par-dessus — et modifient ainsi la largeur disponible. Les unités de viewport se comportent différemment sur les appareils mobiles, selon la manière dont le navigateur comptabilise les barres d'adresse qui apparaissent et disparaissent.

La deuxième grande source de ruptures silencieuses, ce sont les largeurs d'écran. Le design adaptatif définit des points de bascule — les points de rupture —, où la mise en page se réorganise : la navigation se replie en icône de menu, les colonnes s'empilent les unes sur les autres, les espacements se réduisent. On teste, l'expérience le montre, aux largeurs standards des appareils courants. Or c'est entre les deux que ça casse : à des tailles de fenêtre inhabituelles, sur des tablettes en mode paysage, avec des fenêtres réduites de moitié sur de larges écrans de bureau.

Une particularité frappe particulièrement fort les sites germanophones : les longs mots composés. Là où l'anglais aligne trois mots courts, l'allemand pose « Datenschutzgrundverordnung », son mot unique pour le RGPD — un mot qui refuse de se couper, déborde de son conteneur ou fait exploser une navigation dès que la place manque. Les interfaces traduites, impeccables dans l'original anglais, comptent donc parmi les candidates les plus fiables aux problèmes de retour à la ligne.

Du reste, même une page qui s'affiche aujourd'hui correctement partout ne le reste pas d'elle-même. Les navigateurs se mettent à jour tout seuls à un rythme soutenu, les moteurs de rendu modifient des détails de leur comportement — et le site change d'apparence sans que quiconque ait déployé quoi que ce soit. Le test soigneux réalisé au lancement est donc un instantané, pas un état permanent. La même chose vaut dans l'autre sens : chaque mise à jour du CMS, chaque nouvelle extension, chaque changement de texte peut provoquer des décalages.

Derrière tout cela se cache un problème psychologique de fond que tout le monde connaît dans le quotidien du développement : « works on my machine ». Qui construit une page la voit cent fois dans son propre navigateur sur son propre écran — et prend inconsciemment cette vue pour la vérité. Les visiteuses et visiteurs se répartissent pourtant entre des moteurs, des classes d'appareils et des tailles de fenêtre, et aucun d'eux ne se manifeste de lui-même quand quelque chose glisse. Rares sont les gens qui écrivent un courriel lorsqu'un menu se chevauche. Ils partent, tout simplement.

Le cas rare où quelqu'un se manifeste malgré tout n'en est que plus précieux — à condition que le signalement soit traité avec méthode. Une démarche éprouvée compte quatre étapes. Premièrement, se renseigner sur l'environnement : quel navigateur, quel appareil, quelle largeur de fenêtre approximative ? Sans ces indications, toute recherche relève de la devinette. Deuxièmement, reproduire dans le moteur adéquat, pas dans une simulation — au besoin via un service de captures d'écran, si aucun appareil doté du bon moteur n'est à portée de main ; comment se déroule un tel passage de contrôle, ScanU le décrit étape par étape. Troisièmement, circonscrire le mécanisme concerné : la mise en page casse-t-elle à un point de bascule, une fonction CSS manque-t-elle, une police est-elle plus large ? La réponse détermine la réparation — les problèmes de point de rupture se règlent dans sa propre feuille de style, les fonctions manquantes réclament une solution de repli, les problèmes de police souvent seulement des conteneurs plus généreux. Et quatrièmement, l'étape qui saute le plus souvent : après la correction, réexaminer tous les moteurs. Qui ne vérifie que l'endroit signalé passe facilement à côté du fait que la réparation a décalé quelque chose ailleurs.

À ce stade, l'objection viendrait naturellement que les outils de développement des navigateurs ont réglé le problème depuis longtemps : chaque navigateur moderne embarque un mode appareil qui simule les tailles d'écran des téléphones et des tablettes. L'objection méconnaît ce que ce mode fait réellement. Qui choisit la vue iPhone dans Chrome obtient une fenêtre étroite avec une résolution adaptée et un identifiant mobile — mais le rendu continue d'être assuré par Blink, le moteur de Chrome. Cette simulation ne montre pas les particularités WebKit du véritable navigateur de l'iPhone, pas davantage les particularités Gecko de Firefox. Pour travailler sur les points de rupture, le mode appareil est un excellent outil ; comme preuve de compatibilité entre navigateurs, il ne vaut rien. Un moteur ne se simule pas, il se change.

Comment trouve-t-on des ruptures qui ne se signalent pas ? La voie traditionnelle est le travail manuel : une armoire pleine d'appareils de test ou une liste de navigateurs que quelqu'un parcourt après chaque modification. Cela fonctionne, mais passe mal à l'échelle — trois navigateurs multipliés par trois classes d'appareils donnent déjà neuf vues par page, et le soin diminue, l'expérience le montre, à chaque répétition. La voie plus systématique, ce sont les services de captures d'écran, qui parallélisent ce contrôle visuel. ScanU, par exemple, produit après la saisie d'une URL, en une trentaine de secondes, des captures dans Chrome, Firefox et Safari, chaque fois en vues mobile, tablette et bureau ; quelles combinaisons d'appareils sont disponibles, la présentation des fonctions de ScanU en dresse la liste. Au lieu d'ouvrir neuf fenêtres l'une après l'autre, on voit une grille d'images — et les valeurs aberrantes sautent aux yeux.

Cela devient vraiment intéressant dans la répétition. Les services de ce type comparent l'état actuel à un état de référence enregistré et marquent les écarts dans une confrontation directe. La question vague « la page a-t-elle bonne allure partout ? » se mue ainsi en une question nettement plus précise : « quelque chose a-t-il changé depuis le dernier état vérifié ? » — une question à laquelle on peut répondre même lorsque plus personne n'a en tête l'aspect qu'avait la page la semaine passée.

Ici encore, l'honnêteté est de mise : les captures montrent des états, pas des enchaînements. Ce qui se passe au survol de la souris, si un menu se déplie proprement, comment la page se comporte au défilement ou avec une connexion lente — rien de tout cela n'apparaît sur une image statique. Une fenêtre de navigateur rendue ne remplace pas davantage la sensation du matériel réel : la manipulation tactile, les performances d'appareils plus anciens, les particularités de telle ou telle version de système. Avant un lancement important, attraper un vrai téléphone reste une bonne idée, et une capture ne remplace de toute façon pas les tests fonctionnels.

Quelle quantité d'efforts le sujet mérite, personne n'a à en décider de façon générale — ce sont ses propres statistiques de fréquentation qui donnent la direction. Elles montrent par quels navigateurs, quelles classes d'appareils et quelles largeurs d'écran arrivent les visiteuses et visiteurs réels, et donc quelles combinaisons méritent la priorité dans la liste de contrôle. Deux réserves s'imposent cependant. Premièrement, la statistique ne mesure que qui vient — pas qui, à cause d'un affichage cassé, ne reste même pas ; un moteur faiblement représenté peut donc être aussi la conséquence d'un problème, et pas seulement le signe d'une faible pertinence. Deuxièmement, les parts diffèrent considérablement selon le public visé et la situation d'usage : une offre que l'on lit le soir sur le canapé n'a pas la même répartition d'appareils qu'un portail spécialisé pour le quotidien du bureau. La liste de contrôle devrait donc suivre ses propres chiffres, non des panoramas généraux du marché.

Pour le quotidien, une routine simple suffit souvent : après chaque modification de styles ou de gabarits, contrôler les pages les plus importantes sur les trois familles de moteurs ; après les grandes versions de navigateurs, passer une fois l'existant en revue ; lors des refontes, examiner sciemment aussi les largeurs intermédiaires, et pas seulement les formats standards. Qui redoute l'effort commence petit — la page française de ScanU présente le service, dont le palier gratuit, avec un projet et 500 crédits par mois, suffit aux premiers pas.

Le cœur du problème, lui, subsiste, et c'est peut-être là le véritable enseignement : les navigateurs resteront à l'avenir des programmes indépendants dotés de leurs propres moteurs, les standards continueront de laisser des marges, et CSS continuera de se taire plutôt que d'avertir. Les ruptures silencieuses ne sont pas le signe d'un travail bâclé, mais une propriété systémique du web. Y faire face est donc avant tout une question de visibilité : qui regarde régulièrement son propre site avec les yeux des trois moteurs — peu importe l'outil — retire au silence son efficacité.