Surfaces de la plateforme web : carte de revue

La cohérence de la plateforme web est un ordre de revue, pas un test unique. Ce hub relie le groupe plateforme et ajoute un enregistrement borné qui nomme la première surface qui s'écarte de l'entrée déclarée, en commençant par Concevoir des matrices de test par plateforme et version.

BotBrowser prend en charge le rejeu d'un profil autorisé sur une page en propre et peut rapporter des observations bornées du navigateur pour chaque surface ; il ne peut pas certifier la conformité aux standards, ne classe pas deux produits, ne prédit pas la décision d'un service tiers et ne remplace pas la revue du responsable de plateforme.

Résumé

• Regroupez le comportement en quatre surfaces : rendu et mise en page, exécution de scripts, négociation réseau et accès aux capacités.
• Notez l'entrée déclarée à côté de la valeur observée, pour la même version et la même page en propre.
• Nommez la première surface qui s'écarte, arrêtez-vous et transmettez-la à son responsable.
• La réduction, le repli et l'indisponibilité sont des états légitimes, pas des échecs.

Sommaire

• Les quatre surfaces
• Parcourir le groupe plateforme
• Mener une revue bornée
• Qualifier le premier écart
• Conclusion pratique

Les quatre surfaces

Le rendu et la mise en page couvrent ce que la page peint : polices, couleur, requêtes média et réaction du document au viewport. Une page n'est pas une surface unique. C'est un empilement de surfaces comme document, iframe et Worker que le navigateur implémente séparément, chacune avec sa spécification, son rythme de version et ses modes de défaillance. Quand une équipe demande si un navigateur prend en charge son application, elle pose en réalité quatre questions à la fois, et les réponses peuvent diverger. Les séparer fait la différence entre une revue qui finit sur un responsable nommé et un fil qui finit sur une conjecture. L'exécution de scripts couvre ce qui tourne : chargement de modules, workers, identité entre realms et contextes de longue durée. La négociation réseau couvre ce qui circule : en-têtes de requête, politique de réponse, exigences de contexte sécurisé et frontières inter-origines. L'accès aux capacités couvre ce que la page peut utiliser : politique de permissions, capteurs, stockage et fonctions expérimentales derrière les origin trials.

Dans une équipe courante, chaque surface a son responsable, et un changement dans l'une est vite attribué à une autre. Une application peut afficher correctement, exécuter ses scripts et négocier ses requêtes tout en restant incapable d'utiliser la caméra, le micro ou le presse-papiers, parce qu'une politique de permissions, une exigence de contexte sécurisé ou un choix antérieur de l'utilisateur a changé ce que la page peut demander. L'inverse existe aussi : la capacité est disponible et la mise en page qui l'accueille est cassée. Réviser les quatre surfaces séparément empêche un état de masquer l'autre. Une police qui s'affiche différemment après une mise à jour peut venir de la plateforme, du profil ou de la feuille de style. Un worker qui ne démarre pas peut être une politique de capacités, une erreur de script ou un fichier absent du paquet. Écrire le nom de la surface dans l'enregistrement est ce qui garde le diagnostic court.

Le rôle de BotBrowser est étroit : il maintient le profil déclaré cohérent entre les contextes pour qu'un écart de l'enregistrement soit attribuable à la surface en revue et non à une variable non maîtrisée. Pour comparer moteurs et produits, utilisez d'abord Moteur de navigateur et produit et attribuez la cause ensuite.

Parcourir le groupe plateforme

• Concevoir des matrices de test par plateforme et version décide quelles combinaisons sont réellement exécutées.
• Données de compatibilité d'API et replis couvre la détection et le repli progressif.
• Intégrité des API entre realms sépare les objets globaux de page, d'iframe et de worker.
• Le support d'une fonction n'est pas sa qualité sépare présence et comportement.
• Comportement de WebAssembly entre plateformes couvre une surface d'exécution compilée.
• Mesurer la performance avec User Timing enregistre des durées au lieu de les percevoir.
• Contextes sécurisés : pourquoi HTTPS est exigé explique une condition qui désactive des fonctions en silence.
• Politique de même origine et isolation de site fixe la frontière des tests entre surfaces.
• Requêtes média : respecter le choix de l'utilisateur traite les préférences comme une entrée de plateforme.
• Résilience des contextes de longue durée couvre la surface après la première minute.

Le hub possède l'ordre et la forme de l'enregistrement partagé. Chaque article lié possède le détail de sa surface et les défaillances qu'elle peut produire. Deux habitudes gardent le groupe utile. La première est de lire les articles dans l'ordre ci-dessus et non dans l'ordre de publication, car chaque surface réduit ce que la suivante peut expliquer. La seconde est d'envoyer le lecteur vers un article précis, et non vers la liste, dès que la revue a nommé un écart. Un hub qui devient une liste de lecture cesse d'être une carte de décision.

Le groupe fixe aussi un vocabulaire commun. « Support », « compatibilité » (matches-declared-media), « cohérence » et « protection » n'ont pas le même sens : le support dit si une capacité existe dans une version, la compatibilité si le repli de l'application fonctionne, la cohérence si deux contextes du même profil concordent, et la protection si une page peut utiliser une valeur pour isoler une personne ou un appareil. Employer un seul mot pour les quatre produit des revues intransférables.

Mener une revue bornée

Partez d'un fixture en propre, figez sa version et déclarez ce que l'application attend avant de lire quoi que ce soit. Lisez ensuite une ligne par surface dans le même contexte et notez le résultat à côté de l'entrée déclarée. L'enregistrement est une donnée, pas un rapport, et doit rester assez court pour être joint à un ticket.

{
  "runId": "platform-review-20261019-01",
  "declared": { "release": "Chrome 155", "profile": "fresh-temporary", "fixture": "app-shell@v7" },
  "observed": {
    "rendering": "matches-declared-media",
    "scriptExecution": "workers-available",
    "network": "request-headers-recorded",
    "capabilityAccess": "camera-denied"
  },
  "firstDifference": null,
  "testedOn": "2026-10-19"
}

Gardez hors de l'enregistrement les cookies, les identifiants de compte, les en-têtes bruts et tout résultat d'un détecteur tiers. Une capacité refusée volontairement est un état déclaré ; une capacité refusée sans l'avoir prévu est le premier écart, et l'enregistrement doit dire lequel des deux.

La commande de validation a produit cette ligne stdout :

{"slug":"browser-platform-surface-overview","linkedArticles":10,"svg":true,"docsReference":true}

Déclarez la version avant la surface. Notez la version du navigateur, la classe de profil, la version du fixture et la politique applicative que l'équipe veut soutenir. Une valeur déclarée est une entrée de la revue, pas une promesse sur ce que la page observera. Avec l'entrée à côté de l'observation, un écart ultérieur a un point de référence, et un ingénieur support distingue un changement de plateforme d'un fixture qui a livré un autre contenu.

Une page par revue. Une revue qui change de page entre les lignes ne sépare pas l'écart de surface de l'écart de page. Chargez une page en propre, notez sa version et lisez toutes les lignes depuis ce document ou depuis un worker qu'elle démarre volontairement. Si le flux exige deux pages, faites deux revues et reliez-les par runId au lieu de fusionner les lignes. Le premier écart reste ainsi attribuable.

Lisez les surfaces dans un ordre fixe. D'abord le rendu, car une mise en page cassée explique souvent la suite. Ensuite l'exécution de scripts, car un échec de worker ou de module imite une panne réseau. Puis la négociation réseau, car les en-têtes et la politique décident de ce que la page peut faire. Enfin l'accès aux capacités, car les permissions et les capteurs rapportent souvent leur état. Un ordre fixe rend deux revues comparables même si les opérateurs diffèrent.

Séparez présence et comportement. Un constructeur présent peut lever une erreur à l'appel ; une API peut exister et renvoyer une valeur réduite ; une permission peut être présente alors que l'appareil ne l'est pas. Notez présence et comportement dans des champs distincts. C'est la distinction que détaille Le support n'est pas la qualité, et la source la plus fréquente d'un faux diagnostic.

Notez les états réduits et indisponibles. Un user-agent réduit, un capteur indisponible et une permission refusée sont des résultats légitimes d'un navigateur respectueux de la vie privée. Les enregistrer comme états, et non comme échecs, garde la revue centrée sur le contrat applicatif. Si l'application exige une valeur indisponible, cette exigence appartient à l'entrée déclarée pour que la vérification échoue pour la raison indiquée.

Nommez le responsable de chaque surface. Le rendu relève en général du responsable plateforme ou design system, l'exécution des scripts de l'équipe applicative, la négociation réseau de l'infrastructure ou du fournisseur, et l'accès aux capacités du responsable produit qui a décidé la politique de permissions. Inscrire le responsable dans l'enregistrement pendant la revue évite un renvoi et rend le transfert exploitable.

Changez une entrée par essai. Figez le fixture, le profil et la route, puis changez une seule valeur déclarée. Une mise à jour de version, un changement de profil et un changement de politique sont trois expériences. Si deux entrées changent ensemble et que la ligne diffère, l'enregistrement ne peut pas dire laquelle a causé l'écart et le relecteur suivant recommence. C'est la même discipline que les matrices de test appliquent aux combinaisons.

Relancez après un changement significatif. Relancez la carte quand la version, le fixture, la classe de profil ou la politique changent, et mettez à jour testedOn au lieu d'écraser l'enregistrement précédent. Deux enregistrements datés montrent ce qui a changé et quand, ce dont une question de support a besoin. Les standards publics et les articles liés restent la référence des définitions.

Qualifier le premier écart

Si le rendu diffère, comparez le fixture et la feuille de style avant la version. Si l'exécution diffère, vérifiez si le code a tourné au niveau supérieur, dans un iframe ou dans un worker. Si le réseau diffère, comparez en-têtes et politique de réponse, y compris les exigences de contexte sécurisé. Si la capacité diffère, distinguez un refus déclaré d'un refus inattendu.

Arrêtez-vous au premier écart, nommez son responsable et conservez l'enregistrement. Une revue qui se termine par un écart nommé est plus utile qu'une liste de dix observations sans propriétaire.

Un écart de rendu qui n'apparaît que dans une langue relève en général du repli de police ou des métriques de texte, pas de la version ; regardez font-family, font-size et les familles demandées avant la version rapportée. Comparez le même jeu de glyphes avant et après le changement, et notez les familles demandées. Un écart qui n'apparaît que dans un contexte, iframe ou worker, appartient au responsable de ce contexte ; la page supérieure peut être correcte alors qu'un document intégré échoue.

Un écart d'exécution qui disparaît au rechargement est plus souvent un problème de cycle de vie qu'un problème de plateforme. Notez si le script s'est exécuté avant DOMContentLoaded, si un import s'est résolu et si le Worker a reçu terminate(). Un écart qui n'apparaît qu'après plusieurs minutes relève des ressources ou du cycle de vie, et l'article sur les contextes longs décrit ce qui change à ce moment.

Un écart réseau qui n'apparaît que derrière un proxy ou un conteneur appartient au responsable du transport avant celui du navigateur. Comparez séparément les en-têtes de requête, la politique de réponse et l'adresse de sortie (https://example.com/echo). La vue d'ensemble de la configuration proxy fournit cette carte de décision et évite d'attribuer un écart du navigateur à une route qui n'a jamais transporté la requête.

Un écart de capacité qui se manifeste par un échec silencieux vient en général d'une politique de permissions ou d'un contexte sécurisé, pas d'une API absente. Vérifiez si la fonction est autorisée sur la page (window.isSecureContext, un en-tête Permissions-Policy vide ou un navigator.permissions.query() déjà en denied), puis si l'utilisateur ou le profil l'a refusée auparavant. Ce n'est qu'après ces trois vérifications que l'écart appartient au responsable plateforme.

Chaque vérification répond à une question et produit une ligne de l'enregistrement. L'intérêt de l'ordre est que les vérifications suivantes deviennent plus simples : une fois le rendu et l'exécution stabilisés, l'écart réseau est la seule explication restante et la revue ne revient pas sur des surfaces déjà concordantes.

Conclusion pratique

La cohérence de la plateforme web vient d'un ordre de surfaces fixe, d'une entrée déclarée et d'un enregistrement court. Utilisez ce hub pour ordonner la revue et le groupe pour le détail, et limitez chaque conclusion à la version, au profil et à la page qui l'ont produite.

Sources publiques

• W3C : HTML Standard, définition de l'origine
• MDN : Content Security Policy
• MDN : Cross-Origin Embedder Policy
• WHATWG : Workers
• W3C : Règles pour l'accessibilité des contenus web
• MDN : fonctionnalités des requêtes média
• Documentation BotBrowser : vue d'ensemble de l'empreinte