- L’idée selon laquelle la plateforme web fonctionne partout de la même manière grâce à des API standardisées est largement répandue, mais en réalité de nombreuses API dépendent d’une infrastructure propre à chaque éditeur de navigateur
- Geolocation, Speech, Push, Payments, Passkeys, etc. sont en apparence des standards du web, mais appellent en interne des services de Google, Apple ou Microsoft
- Même pour un appel d’API identique, la précision, la disponibilité, les incompatibilités selon les régions et les politiques de confidentialité varient fortement d’un navigateur à l’autre, et les développeurs finissent par en dépendre sans en avoir conscience
- Une standardisation structurée autour des grands éditeurs relève la barrière à l’entrée pour les petits navigateurs et l’écosystème open source, et renforce de fait un effet de verrouillage (lock-in)
- Les développeurs doivent considérer ces API non comme de purs « standards web », mais comme une couche d’abstraction de services d’éditeurs, et prévoir en parallèle information sur la confidentialité, conceptions alternatives et tests par navigateur
Perception générale de la plateforme web et structure réelle
- La plateforme web est perçue comme un système unifié fondé sur des spécifications standard, et l’on s’attend au même comportement dans des navigateurs basés sur le même moteur
- En pratique, de nombreuses API dépendent d’implémentations propres à chaque navigateur ainsi que de services tiers, d’infrastructures propriétaires et de systèmes internes aux éditeurs
- Contrairement à l’interface standardisée, les détails d’implémentation varient fortement selon les choix de l’éditeur du navigateur
Geolocation API et source réelle des données de position
- Geolocation API fournit une interface standardisée, mais les données de localisation réelles sont collectées par différents moyens
- Utilisation du service de localisation de l’OS et du GPS
- Estimation de position à partir des informations des points d’accès Wi‑Fi
- Consultation d’une base de données de géolocalisation par adresse IP
- Chrome utilise Google Location Services, Safari des serveurs Apple, et Firefox utilise depuis 2024 des services Google
- Lors de l’utilisation de la localisation, des données utilisateur peuvent être envoyées vers les serveurs d’un éditeur précis, sans que cela soit explicitement visible dans l’interface du navigateur
- Si l’accès au service d’un éditeur est bloqué dans certaines régions, la fonctionnalité peut ne pas fonctionner correctement
Speech Synthesis et infrastructure de traitement vocal
- La synthèse vocale de la Web Speech API utilise des moteurs différents selon le navigateur, l’OS et l’appareil
- Speech Synthesis API est une interface standardisée, mais les données vocales sont traitées par le moteur TTS du système d’exploitation ou par des serveurs cloud
- Chrome combine traitement local et cloud, tandis que Safari utilise le moteur vocal de l’OS
- Certaines voix de haute qualité nécessitent un traitement cloud, donc un envoi en ligne, ce qui implique que des données utilisateur sont envoyées vers un serveur
- Il existe donc un risque d’envoi involontaire de messages personnels ou d’informations sensibles à des serveurs externes
- De plus, une voix choisie dans l’environnement de test peut ne pas exister dans l’environnement de l’utilisateur
Speech Recognition et transmission vocale en temps réel
- Speech Recognition API dépend dans la plupart des cas de services de reconnaissance cloud
- Chrome utilise Google, Safari Apple, et Edge des services de la famille Azure
- Depuis Chrome 139, l’option
processLocally permet un traitement local, mais ce n’est pas la valeur par défaut, et cette fonction reste limitée à Chrome
- La précision et la prise en charge des langues varient selon la qualité des modèles de chaque éditeur
Passkeys et base réelle de WebAuthn : dépendance à l’écosystème du navigateur
- WebAuthn API se présente comme une authentification sans mot de passe, mais dépend en pratique de l’infrastructure de gestionnaire de mots de passe du navigateur
- Chrome utilise Google Password Manager, Safari iCloud Keychain, et Edge le compte Microsoft
- Des navigateurs comme Polypane ne prennent pas en charge les Passkeys à cause des limites d’Electron, et nécessitent une extension comme 1Password
- La manière de stocker, synchroniser et récupérer les identifiants dépend entièrement de l’implémentation de chaque éditeur
Payment Request API et dépendance aux éditeurs de paiement
- Payment Request API ressemble à un standard, mais en pratique le paiement fonctionne ou non selon les partenaires de l’éditeur
- Chrome utilise Google Pay, Safari Apple Pay, Edge une intégration Microsoft, et Firefox ne le prend pas en charge
- La prise en charge régionale, l’UX et les réglages supplémentaires requis varient selon les navigateurs
- En conséquence, il faut prévoir des contrats distincts et une logique spécifique pour chaque moyen de paiement
Push API et réseaux de notification selon les éditeurs
- Push API est un standard, mais l’infrastructure serveur réellement utilisée pour la livraison des notifications diffère selon le navigateur
- Chrome et Edge utilisent FCM, Safari APNs, et Firefox Mozilla Push Service
- Limites d’envoi, taille des messages, traitement hors ligne et politiques de confidentialité diffèrent d’un service à l’autre
- Une panne de l’infrastructure d’un éditeur peut affecter l’ensemble des fonctions push de ce navigateur
API média, codecs et DRM
- Media Source Extensions (MSE) et Encrypted Media Extensions (EME) sont des standards, mais leur prise en charge varie selon les codecs et licences DRM
- Chrome, Edge et Firefox dépendent de Widevine, tandis que Safari utilise FairPlay, donc de technologies entièrement propriétaires
- Chaque éditeur de navigateur a ses codecs et sa stratégie de prédilection
- À cause du coût des licences DRM et des contraintes techniques, les petits navigateurs ont du mal à les prendre en charge
Arrivée des API d’IA dans le navigateur : une nouvelle structure propriétaire
- Chrome expérimente des API d’IA basées sur Gemini Nano (résumé, traduction, correction, etc.)
- L’exécution est locale, donc sans transfert de données, mais le modèle est volumineux (environ 4 Go), exige un GPU, et reste un modèle propriétaire de Google
- Les autres navigateurs doivent développer leurs propres modèles, et les petits navigateurs ou projets open source ne peuvent ni obtenir ni maintenir un modèle équivalent, ce qui les empêche de rivaliser
- Cela crée une nouvelle forme de dépendance aux éditeurs fondée sur l’IA
Pourquoi c’est important
- Problème de portabilité : un même code peut produire une qualité de fonctionnement différente selon le navigateur, la région ou l’environnement
- Risque pour la confidentialité : des données vocales, de localisation ou de push peuvent être envoyées involontairement aux serveurs d’un éditeur
- Déséquilibre de la standardisation : les grandes entreprises pilotent la rédaction des spécifications et leur implémentation, et font de leurs propres infrastructures une condition de fait, ce qui écarte les petits navigateurs
- Impact pour les développeurs : ces fonctions sont utiles, mais il faut reconnaître qu’il s’agit de dépendances à des services plutôt qu’à de simples standards
Approche à adopter pour les développeurs
- Considérer les API comme une couche d’abstraction de services d’éditeurs et prévoir tests, documentation et solutions de repli
- Concevoir avec une dégradation progressive (graceful degradation) pour anticiper les écarts de comportement
- Assurer la transparence sur la confidentialité : indiquer clairement que des données peuvent être envoyées à des serveurs tiers
- Gérer la dépendance aux éditeurs : prévoir une réponse en cas d’arrêt de service ou de changement de politique
- Vérifier les écarts de qualité avec des tests par navigateur et par région
- Réduire autant que possible la dépendance aux éditeurs par des choix stratégiques
Le web tel qu’on l’imagine vs le web réel
- Les appels d’API standardisés sont identiques, mais les flux de données, la précision, la couverture régionale, la confidentialité et la structure des coûts diffèrent selon les navigateurs
- Un appel à
navigator.geolocation.getCurrentPosition() revient en pratique à appeler un service de localisation Google ou Apple
- La spécification standard ne définit que l’interface ; le fonctionnement réel dépend de l’infrastructure et des politiques de l’éditeur
- Appeler une API revient donc à utiliser les serveurs, les politiques et le modèle économique d’un éditeur précis
- La plateforme web reste puissante, mais sa structure réelle est plus fragmentée et plus centrée sur les éditeurs
- Les développeurs doivent concevoir en comprenant clairement la frontière entre standard et implémentation
Aucun commentaire pour le moment.