Date de publication : 7 novembre 2025
Gérer la compatibilité des navigateurs pour plus de 38 000 clients professionnels au Japon n'est pas une tâche facile. Lorsque Kintone alimente des opérations commerciales critiques pour plus de 1,5 million d'applications chaque jour, chaque décision concernant la compatibilité des navigateurs est importante.
Cybozu, l'une des principales entreprises de groupware au Japon, était confrontée à un défi fondamental : comment maintenir des normes Web cohérentes dans tous ses produits tout en évitant la charge de maintenance des matrices de compatibilité des navigateurs personnalisées.
La solution ? L'adoption de Baseline comme norme de développement, qui a transformé leur approche de l'adoption des fonctionnalités de la plate-forme Web.
Le défi : la prise en charge des navigateurs sans devinettes
Avant Baseline, Cybozu gérait ses propres critères de compatibilité des navigateurs en fonction des journaux d'accès et du suivi manuel des versions. Leur norme consistait à prendre en charge les navigateurs qui couvraient les 98 % supérieurs des journaux d'accès. Les utilisateurs qui utilisaient des navigateurs en dehors de ce seuil voyaient une invite à mettre à jour leur navigateur.
Chaque trimestre, les équipes d'ingénierie de Cybozu consacrent environ une heure au total à la mise à jour des critères. Toutefois, l'intégration des critères à l'équipe de développement n'a pas été fluide et il était assez courant d'avoir des questions : quand de nouvelles fonctionnalités CSS pourraient-elles être utilisées ? Quand les polyfills pour les nouvelles API JavaScript pourront-ils être supprimés ? Et quelles fonctionnalités peuvent être utilisées dès maintenant ?
Non seulement les critères personnalisés de Cybozu manquaient de facilité de maintenance et d'utilisabilité pour les développeurs, mais l'entreprise s'est également rendu compte que s'appuyer sur la détection de l'agent utilisateur et le suivi manuel des versions ne permettait pas de suivre le rythme de l'évolution du Web moderne.
Peut-on se fier à la chaîne User-Agent ?
L'approche précédente de Cybozu consistait à extraire les noms et les versions des navigateurs à partir de chaînes User-Agent, puis à agréger ces résultats en tant que données "utilisateur". Mais cela reflète-t-il vraiment la réalité des utilisateurs ?
User-Agent est un en-tête de requête HTTP, c'est-à-dire une information que n'importe quel client peut prétendre être. Les journaux d'accès aux produits contiennent un volume considérable de requêtes provenant de robots, de robots d'exploration, de pirates informatiques et d'autres sources. Certains clients envoient intentionnellement d'anciennes chaînes User-Agent à diverses fins, comme l'analyse des failles. Par conséquent, les journaux d'accès ne peuvent pas représenter les utilisateurs qui doivent être pris en charge.
L'User-Agent ne peut pas refléter les fonctionnalités disponibles
Les versions de navigateur ne sont pas associées aux fonctionnalités. Une même version peut avoir des fonctionnalités différentes selon le canal (Stable/Bêta/Dev/Canary), les indicateurs de fonctionnalité, les tests Finch ou les règles pour les entreprises, par exemple. De plus, les différents navigateurs implémentent les fonctionnalités à des moments différents. Par exemple, l'imbrication CSS a été déployée dans Safari 16.5 (mai 2023) et dans Chrome 112 (avril 2023). La chaîne User-Agent n'indique pas la disponibilité de la fonctionnalité.
Responsabilité de la prise en charge des versions de navigateur
Les mises à jour du navigateur ne concernent pas uniquement les nouvelles fonctionnalités. Les versions régulières du navigateur incluent des correctifs de sécurité critiques et des corrections de bugs, en plus de nouvelles fonctionnalités. Lorsque des versions obsolètes sont prises en charge, le problème ne se limite pas à l'évitement des nouvelles fonctionnalités. Il s'agit d'une décision qui a un impact direct sur la sécurité des utilisateurs. Dans les environnements d'entreprise, certains utilisateurs peuvent être soumis à des contraintes légitimes. Exemple :
- Il est possible que les règles strictes de votre organisation concernant les navigateurs empêchent les mises à jour.
- Le matériel ancien n'est pas compatible avec la mise à jour des navigateurs modernes.
- Utilisateurs dans des secteurs réglementés avec des processus d'approbation des modifications lents.
Cependant, aider ces utilisateurs signifie également les laisser vulnérables.
Si un incident de sécurité s'est produit en exploitant une faille connue dans une ancienne version du navigateur, il ne serait pas raisonnable de dire "ce navigateur était pris en charge parce que les utilisateurs l'ont demandé". Si l'attaque se propage à d'autres utilisateurs qui maintiennent correctement leurs navigateurs à jour, les développeurs et autres parties prenantes du projet sont responsables de ne pas avoir interrompu la prise en charge des navigateurs non sécurisés.
Cybozu a réalisé que cette approche crée des risques pour la majorité des utilisateurs qui maintiennent leur navigateur à jour. La prise en charge des navigateurs basée uniquement sur le nombre de journaux ne permet pas de valider correctement la sécurité. Il ne s'agit pas seulement de passer à côté de nouvelles fonctionnalités, mais de ne pas assumer la responsabilité de protéger les utilisateurs.
La question n'est plus "Combien d'utilisateurs utilisent cette version ?", mais "Devons-nous prendre en charge les utilisateurs en fonction des versions de navigateur ?".
Pourquoi Baseline est la bonne réponse pour Cybozu
Cybozu avait besoin d'une nouvelle approche qui ne se contente pas de résoudre les problèmes opérationnels liés au maintien des critères de compatibilité des navigateurs, mais qui s'attaque également aux failles fondamentales de l'ancienne méthodologie. Baseline a permis à Cybozu de faire exactement cela.
Critères évolutifs gérés en externe
Au lieu de réévaluer manuellement les versions de navigateur chaque trimestre, Baseline fournit une cible mouvante gérée par le WebDX Community Group du W3C, et non par des entreprises individuelles prenant des décisions arbitraires. Cela signifie que les critères évoluent automatiquement en fonction des informations fournies par les fournisseurs de navigateurs et les organismes de normalisation.
Les utilisateurs de Kintone n'ont plus besoin de gérer eux-mêmes les seuils de version. Baseline évolue sans aucune action de leur part. L'état de référence des fonctionnalités répond définitivement aux questions sur la disponibilité. La réponse se met à jour automatiquement à mesure que la plate-forme évolue.
Précision au niveau des caractéristiques
Au lieu d'essayer de suivre la situation d'un navigateur individuel, Baseline adopte une approche fondamentalement différente.
"Baseline largement disponible" désigne les fonctionnalités Web disponibles depuis 30 mois ou plus dans les principaux navigateurs. Cette période a été déterminée pour "approximer les signaux des développeurs, l'adoption des versions de navigateur au fil du temps, une estimation de la prise en charge d'une part de marché totale élevée et le meilleur jugement du groupe communautaire WebDX". En définissant ce seuil, Baseline élimine la tâche de suivi des situations de navigateur individuelles non observables.
Avec Baseline, les développeurs obtiennent une réponse directe sur la disponibilité de cette fonctionnalité spécifique dans les navigateurs. Il est désormais possible de répondre à la question "Pouvons-nous utiliser des requêtes de conteneur CSS ?". Les développeurs peuvent vérifier l'état de référence sur MDN ou d'autres documents instantanément, sans avoir à consulter les matrices de compatibilité.
Une conception axée sur la sécurité
En adoptant la version de référence largement disponible comme norme, Cybozu a aligné sa politique d'assistance sur un calendrier qui correspond naturellement aux cycles de vie de l'assistance des fournisseurs de navigateurs. Les navigateurs qui sont encore activement mis à jour seront compatibles avec toutes les fonctionnalités largement disponibles et recevront également les mises à jour de sécurité critiques.
Les critères basés sur les journaux d'accès pouvaient ancrer l'assistance à des navigateurs obsolètes, ce qui dissuadait les utilisateurs de les mettre à jour. En adoptant Baseline, nous pouvons non seulement utiliser des fonctionnalités modernes en toute confiance, mais les utilisateurs de navigateurs obsolètes sont naturellement amenés à mettre à jour leur navigateur à mesure que la plate-forme Web évolue.
Baseline n'exclut pas explicitement les navigateurs vulnérables. Il incite naturellement les utilisateurs à maintenir leurs navigateurs à jour.
Adopter Baseline
L'adoption de Baseline a nécessité un changement dans la gestion des anciennes versions de Cybozu. Cybozu devait donc être sûr que Baseline fonctionnerait sans inconvénients majeurs. Il était essentiel de connaître le pourcentage d'utilisateurs concernés pour l'adoption au niveau de l'entreprise.
Google Analytics Baseline Checker est un outil qui analyse les données exportées depuis Google Analytics pour indiquer le pourcentage de vos utilisateurs qui sont compatibles avec les fonctionnalités de chaque année de référence. Cet outil a aidé Cybozu à vérifier l'impact réel du choix d'une cible de référence sur ses utilisateurs. Après avoir exécuté Baseline Checker, Cybozu a fait une découverte remarquable :
Baseline Checker a révélé que 98,8 % des utilisateurs de Cybozu utilisaient des navigateurs compatibles avec la cible "Baseline largement disponible". Cette couverture est plus large que la norme interne précédente de Cybozu, qui était d'au moins 98 % des utilisateurs. Trois points clés peuvent être analysés à partir des données fournies :
- Les navigateurs précédemment compatibles ne sont pas concernés.
- Navigateurs précédemment non compatibles : ils représentent environ 0,8 % des navigateurs qui répondent aux critères de référence largement disponibles, mais qui n'affichent plus l'invite de mise à jour du navigateur.
- Les autres navigateurs continueront de recevoir l'invite de mise à jour du navigateur comme avant.
Cela signifiait notamment que les faux positifs pouvaient être éliminés, c'est-à-dire les ~0,8 % d'utilisateurs qui avaient reçu des avertissements inutiles alors qu'ils utilisaient des navigateurs compatibles. Parallèlement, les faux négatifs ne doivent pas être introduits en avertissant les utilisateurs qui étaient auparavant acceptés.
Grâce à ces données, Cybozu a pu adopter en toute confiance Baseline Widely available comme cible.
L'impact de Baseline en pratique
Adopter Baseline comme règle était une chose, mais la rendre opérationnelle nécessitait de créer des outils et des processus. Il était nécessaire de s'assurer que les développeurs ne pouvaient pas utiliser accidentellement des fonctionnalités non compatibles sans vérifier manuellement l'état de référence.
Analyse statique basée sur la configuration ESLint
@cybozu/eslint-config est une configuration basée sur OSS utilisée dans les produits Cybozu. Il était compatible à partir du préréglage css-baseline qui vérifie les fonctionnalités CSS par rapport à la ligne de base au moment de la compilation :
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
Lorsque les développeurs utilisent des fonctionnalités qui ne sont pas encore largement disponibles dans Baseline, ils reçoivent un retour immédiat d'ESLint :
Cela permet d'éviter que des problèmes de compatibilité n'atteignent la production. Les développeurs peuvent prendre des décisions éclairées dès le début du processus de développement : soit attendre que la fonctionnalité soit largement disponible, soit implémenter l'amélioration progressive en sachant exactement quels utilisateurs seront concernés. (En savoir plus sur la compatibilité d'ESLint avec CSS et Baseline)
Configurer les transpilers pour cibler la fonctionnalité de référence largement disponible
Les outils de compilation modernes ont commencé à prendre en charge Baseline comme cible. Par exemple, Vite cible automatiquement la fonctionnalité de base largement disponible en production sans configuration supplémentaire. Browserslist est désormais compatible avec Baseline.
L'utilisation de différents paramètres de compilation garantit que notre JavaScript et notre CSS ne sont transpilés que lorsque cela est nécessaire, ce qui évite les transformations et les polyfills inutiles pour les fonctionnalités déjà largement prises en charge.
Éliminer la maintenance manuelle des critères et le système de détection du navigateur pour les commentaires des utilisateurs
Le plus grand avantage en termes de maintenance a été l'élimination du suivi manuel des versions de navigateur. Au lieu d'organiser des réunions trimestrielles pour déterminer les versions de navigateur à prendre en charge, Cybozu s'appuie désormais sur le package @web-platform-dx/baseline-browser-mapping, dont la maintenance est ouverte, pour répondre à ces questions.
Cybozu a également créé une détection automatique du navigateur pour afficher des invites de mise à niveau aux utilisateurs qui utilisent des navigateurs obsolètes.
La détection de navigateur récupère les versions de navigateur compatibles directement à partir du package @web-platform-dx/baseline-browser-mapping.
Il s'exécute pendant notre processus de compilation et génère des bannières d'avertissement qui sont partagées entre toutes les équipes produit. À mesure que la période de disponibilité générale de référence s'étend pour inclure les navigateurs plus récents, notre système détecte automatiquement les modifications sans aucune intervention manuelle.
Communication simplifiée
L'un des avantages les plus importants, mais aussi les plus inattendus, a été la façon dont Baseline a simplifié la communication entre les équipes. Auparavant, les discussions sur la compatibilité des navigateurs nécessitaient des connaissances spécifiques à l'entreprise (quels navigateurs nous prenons en charge, quelles versions et quelles fonctionnalités sont disponibles actuellement). Les nouveaux employés avaient besoin de temps pour apprendre nos normes internes. Avec Baseline, nous nous référons désormais aux mêmes critères de compatibilité largement reconnus par la communauté Web.
Cela permet également de créer un vocabulaire commun au sein de nos équipes d'ingénierie et de la communauté Web au sens large. Lorsque vous discutez de l'adoption des fonctionnalités, tout le monde fait référence aux mêmes données provenant de la même source. Il n'est donc pas nécessaire d'expliquer les règles internes ni de traduire entre différents frameworks de compatibilité.
Les outils de développement ont également rattrapé leur retard : Visual Studio Code et le panneau Style des outils pour les développeurs Chrome affichent désormais directement les informations sur la compatibilité avec la référence. Les développeurs n'ont plus besoin de consulter constamment MDN ou Can I use pour vérifier si une fonctionnalité peut être utilisée sans risque. L'outil les en informe immédiatement.
Faites fonctionner le produit pour tous en toute confiance
Avec Baseline, nous avons pu changer radicalement notre façon de penser la compatibilité des navigateurs, en passant d'un fardeau à gérer à une base de confiance. Notre stratégie d'implémentation est axée sur l'automatisation à chaque étape :
- Commentaires au moment du développement : analyse statique et fiche "État de référence".
- Validation au moment de la compilation : les transpilers ciblent automatiquement la fonctionnalité Baseline Widely Available.
- Détection de l'environnement d'exécution : avertissements destinés aux utilisateurs pour les navigateurs non compatibles utilisant
baseline-browser-mapping. - Mises à jour continues : la synchronisation automatique avec les données de référence élimine la maintenance manuelle.
Les résultats parlent d'eux-mêmes.
- Zéro heure consacrée à la maintenance des versions de navigateur.
- Nous maintenons une couverture des utilisateurs de plus de 98,8 % avec un niveau de certitude au niveau des fonctionnalités.
- Réponses instantanées et spontanées aux questions fréquentes, qui répondent à la question "Pouvons-nous utiliser cette fonctionnalité sur cette version du navigateur ?"
- Vocabulaire commun pour les équipes d'ingénieurs.
- Un chemin plus clair vers l'adoption des fonctionnalités invite les équipes à discuter de l'intégration de nouvelles fonctionnalités et du calendrier de suppression des polyfills, si nécessaire.
Pour les organisations qui envisagent d'adopter le niveau de référence, il est essentiel de savoir comment ce changement affectera vos utilisateurs. Des outils comme Google Analytics Baseline Checker rendent cette mesure plus simple et plus explicite. Une fois que vous êtes sûr des données et que vous décidez d'adopter Baseline, vous pouvez utiliser l'écosystème en pleine croissance de Baseline pour organiser votre workflow de développement.
La plate-forme Web est plus puissante, plus cohérente, plus fiable et évolue plus rapidement que par le passé. Avec Baseline, nous pouvons exploiter cette puissance en production en toute confiance.
Ressources
- Article d'origine en japonais : プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
- Configuration ESLint de Cybozu :
@cybozu/eslint-configsur GitHub - Vérificateur de référence Google Analytics : Vérificateur de référence Google Analytics
- Mappage du navigateur de référence :
@web-platform-dx/baseline-browser-mapping - En savoir plus sur Baseline : Baseline sur MDN