Notes de version du navigateur pour les équipes web
Transformez les notes de version en vérifications de compatibilité, décisions de déploiement et preuves de repli.
Vous voulez la documentation structurée pour Plateforme ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Les notes de version signalent un changement, mais ne certifient pas la compatibilité. Utilisez-les pour choisir une enquête limitée, puis vérifiez capacité, permissions, repli et résultat visible.
Lire le signal
Consultez les notes Chrome et les notes Firefox. Notez canal, version, date, fonction, drapeau, origine et migration. Distinguez livraison, expérimentation, avertissement et retrait.
Une note décrit l’implémentation, pas la fin de la tâche ni du serveur. Choisissez une page possédée, des données synthétiques, un résultat et un repli avant l’essai.
Choisir la matrice
Incluez la version stable, la candidate et une version supportée antérieure. Indiquez si chaque cellule est une preuve de standard, une capacité d’exécution ou un parcours applicatif.
Notez version, origine, contexte sécurisé, permissions, fixture et résultat attendu. Un échec peut venir du navigateur, de l’application, du test ou d’un service externe.
Tableau de décision
| Observation | Décision | Résultat visible | Limite |
|---|---|---|---|
| Note concordante et candidat réussi | déployer graduellement | garder route et repli | version déclarée |
| Fonction sous drapeau ou expérimentation | garder le repli | expliquer l’indisponibilité | politique |
| Méthode absente ou contexte bloqué | ne pas forcer | proposer le repli | page actuelle |
| Appel refusé | classer une fois | afficher récupération | navigateur |
| Appel terminé | vérifier application | confirmer signal visible | navigateur et application |
Fixture d’échec
Le fixture crée ses contrôles, simule l’API possédée, vérifie la branche visible et supprime les nœuds dans finally. Ne modifiez pas une empreinte ni des identifiants.
async function tester() {
const h = document.createElement('div');
h.innerHTML = '<p id="etat"></p><button id="repli" hidden>Utiliser le repli</button>';
document.body.append(h);
const etat = h.querySelector('#etat');
const repli = h.querySelector('#repli');
try {
const ok = typeof navigator.share === 'function';
const r = ok
? await navigator
.share({ title: 'Test synthétique', url: '/fixture' })
.then(() => 'termine')
.catch(() => 'echec')
: 'absent';
etat.textContent = r === 'termine' ? 'Terminé' : 'Utilisez le repli';
if (r !== 'termine') repli.hidden = false;
console.assert(etat.textContent && (r === 'termine' || !repli.hidden));
return r;
} finally {
h.remove();
}
}
Déploiement et retour
Notez version, fonction, portée, assertions, responsable et seuil de retour. Vérifiez un accusé applicatif plutôt qu’une promesse résolue. Testez libellés, focus, clavier et messages.
Retournez en arrière pour exception élevée, focus bloqué, repli absent ou accusé serveur perdu. Conservez la note, la sortie et le résultat visible.
Entretien et BotBrowser
BotBrowser fournit des contextes contrôlés pour des parcours autorisés de versions candidates et des vérifications répétables. Il ne garantit pas l’interprétation des notes, n’accorde pas de permissions, ne remplace pas la conformité et ne prouve pas le serveur. La documentation d’isolation prouve la répétabilité, pas une garantie universelle.
Tenez un registre de source, version, état, repli, résultat et prochaine revue sans données personnelles. Consultez le guide de compatibilité API et le guide WPT.
Classez chaque changement par impact et reliez-le à un fixture et une assertion visible.
Notez drapeaux, certificats, contexte et état du profil pour comparer les candidats.
Séparez l’appel navigateur de l’accusé applicatif et conservez le premier échec.
Révisez la matrice après chaque mise à jour et retirez un candidat avec une décision explicite.
La fiche doit répondre à ce qui change, aux versions touchées, à la détection, au résultat visible et à l’action suivante.
Testez présence et échec pour une nouvelle API, ainsi que la route bloquée après retrait d’un drapeau.
La date du fournisseur n’est pas celle de préparation de l’application; notez responsable et preuve.
Une fiche utile couvre changement, versions, détection, résultat visible et action suivante.
Comparez le build et le contexte exacts: drapeaux, certificats, politiques et réseau peuvent différer.
Séparez appel navigateur, état visible et accusé serveur avant la décision de déploiement.
Relisez la fiche après les mises à jour et notez responsable et expiration des exceptions.
Reliez chaque retrait, changement par défaut ou politique de sécurité à un test positif et à une route bloquée expliquée.
La clôture doit préciser si le changement est prêt, progressif, différé ou annulé, avec sa preuve et son responsable.
Si une preuve manque, marquez la décision en attente avec responsable, donnée manquante et date suivante.
Le transfert est terminé quand une autre personne peut reproduire la décision, voir le même repli et connaître la preuve qui la changerait.
Gardez la note brève pour la revue, tout en séparant clairement navigateur et application.
Utilisez le même vocabulaire: candidat, détecté, visible, confirmé, en attente et annulé.
Ainsi la revue distingue la limite observée de celle qui reste ouverte.
Cette distinction garde la décision utile sans exagérer la compatibilité.
Gardez la portée explicite.
La décision conserve cette frontière.
Sources
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.