Le régulateur des télécoms veut que les box des FAI de plus d'un million d'abonnés disposent d'une API permettant de caractériser « l’environnement de l’utilisateur lors du test de mesure de la qualité de service internet ». Le projet est en phase finale et une consultation publique est organisée avant la publication de la décision au JO.
La semaine dernière, l'Arcep a lancé une consultation publique sur un nouveau projet : ajouter une API dans les box des principaux fournisseurs d'accès. Son but ? Retourner l'ensemble des informations sur la technologie d'accès utilisée qui manque cruellement lors des tests de débits et « rend les données difficilement exploitables, voire, dans certains cas, induit en erreur le consommateur ».
En effet, « Sur les réseaux fixes, la mesure de la qualité de service est particulièrement complexe : il est à ce jour quasi-impossible techniquement pour un outil de mesure (souvent appelé "speed test") de connaître avec certitude la technologie d’accès (cuivre, câble, fibre, etc.) sur laquelle a été réalisé un test », explique le régulateur.
Ce chantier a été lancé l'année dernière, en collaboration avec une vingtaine d'acteurs, dont des éditeurs d'outils de mesure et des opérateurs. En fin d'année dernière, le projet a migré vers « la mise en place d'une interface de programmation applicative (API) implémentée directement dans la box des opérateurs ».
La consultation publique du jour concerne les conditions d’implémentation et d'utilisation de cette API, ainsi que son périmètre d'action. Sauf changement de dernière minute, c'est la dernière ligne droite avant sa publication. Les FAI auront ensuite entre 12 et 28 mois pour s'adapter.
Les informations retournées par l'API
Le principe est le même que pour n'importe quelle API : un outil de mesure envoie une demande à l'interface de programmation, qui lui répond avec « les spécifications techniques qui caractérisent l’environnement de l’utilisateur lors du test de mesure de la qualité de service Internet ».
Généralement, elles sont directement disponibles dans la box. C'est notamment le cas du type de connexion (xDSL, FTTH, câble, etc.), des « informations sur la connexion LAN et WAN et [du] compteur d’octets permettant de détecter le cross-traffic ». D'autres données doivent par contre être envoyées par le système d'information (SI) des FAI à la box, qui sert de relai, notamment pour « le débit souscrit par l’utilisateur » dans le cas de la fibre par exemple.
Dans tous les cas, cette API n'a pas pour but de mesurer le débit effectivement disponible pour le client : elle « se limite à caractériser l’environnement utilisateur afin de fiabiliser les données remontées par des outils de mesure tiers qui font appel à l’API ».
Bien évidemment, « aucune donnée liée à l’identification de l’utilisateur (identifiant, nom, localisation etc.) ne sera en revanche transmise, dans un objectif de protection de la vie privée des utilisateurs ». Tout dépendra ensuite de l'implémentation de chaque FAI et des contrôles qui seront éventuellement menés par le gendarme des télécoms.
Les informations sont retournées au format JSON (JavaScript Object Notation) avec des champs obligatoires comme les débits contractuels minimum et maximum dans le sens montant et descendant, la présence d'une agrégation de liens (4G et xDSL par exemple), la technologie LAN utilisée (Wi-Fi, Ethernet, CPL...) et son débit de synchronisation, etc.
D'autres paramètres en revanche dépendent du type de connexion. En xDSL, les débits de synchronisation montant et descendant doivent être renvoyés par l'API. Si la machine est connectée à la box en Wi-Fi, la norme IEEE (802.11a/b/g/n/ac/ax), la bande radio (2,4 ou 5 GHz) et la mesure de la puissance du signal (dBm) doivent aussi être présentes dans le JSON.
Estimer le « cross-traffic »
Une autre information importante dans le cadre d'un test de débit concerne le « cross-traffic ». Il s'agit de vérifier que d'autres services/utilisateurs ne sont pas en train de consommer une partie non négligeable de la bande passante disponible, avec comme effet immédiat de fausser complètement les résultats.
Dans cette optique, deux requêtes peuvent être effectuées par l'outil de mesure. La première, dès que le client lance le test, la seconde dès qu'il est terminé. « L’outil détermine la présence de cross-traffic si le nombre d’octets sur l’interface WAN est significativement supérieur au nombre d’octets générés par le test de mesure de la qualité de service en lui-même ».
L'ensemble des paramètres est décrit dans l'annexe 1 (page 12), ainsi que dans les tableaux ci-dessous. Dans sa consultation, l'Arcep veut savoir s'ils « vous paraissent pertinents pour la mise en place de l’API ? » et, le cas échéant, « Quel(s) autre(s) paramètre(s) trouvez-vous utile d’ajouter ou de supprimer ? ».
Du côté des détails techniques, « l’API écoute uniquement en HTTPS, sur le port TCP 443 ou sur le port spécifié par l’opérateur dans l’URL », explique le régulateur dans son annexe 2 (page 15). TLS 1.2 minimum doit être utilisé, avec un certificat valide évidemment. « L’API écoute uniquement sur le LAN. L’API ne répond pas aux requêtes qui pourraient provenir d’Internet », elle est « activée par défaut sans intervention de l’utilisateur » et « est joignable par un (ou deux) nom(s) de domaine(s) par opérateur (un opérateur correspond à un AS ou "système autonome") », détaille le régulateur.
Une des questions de la consultation concerne cette partie : « L’implémentation de l’API et les restrictions d’accès retenues par l’Arcep (détaillées à l’annexe 2) vous paraissent-elles les plus appropriées ? Sinon, quelles modifications proposez-vous ? ».
Objectifs de l’API
Pour le régulateur, la caractérisation de l’environnement utilisateur via cette API représente un double enjeu. « D’une part, elle est indispensable à la réalisation d’observatoires plus pertinents pour le consommateur, et d’autre part, elle représente un intérêt significatif dans l’établissement d’un diagnostic précis d’un problème de qualité de service ».
Un mauvais débit peut en effet venir de plusieurs sources différentes, pas toujours faciles à identifier : qualité de la ligne et du signal Wi-Fi, utilisation simultanée de plusieurs appareils sur la même box, etc. Les informations renvoyées par l'API permettent de faire du tri dans les hypothèses.
Dans son projet de décision, l'Arcep se demande : « l’objectif retenu vous parait-il pertinent ? ».
Périmètre d'action et modalités d'application de la décision
Le gendarme veut contraindre les fournisseurs d'accès disposant d'au moins d'un million de clients sur le marché de détail grand public. Pour les autres, l'API pourra être mise en place, mais de manière facultative. Seront concernées les box supportant les technologies xDSL, câble et FTTH, ainsi que les prochaines pour la 5G fixe.
Les box 4G fixe et satellite sont donc exclues du périmètre obligatoire, mais peuvent tout de même intégrer cette API si les FAI le décident.
Le régulateur précise que « les modèles de box qui n’ont pas vocation à dépasser 10 000 unités ne sont pas soumis à l’obligation d’implémenter l’API. Cette limite a pour vocation de ne pas faire peser de contraintes sur des box de tests ». De même, les box ne sont plus concernées « après expiration d’un délai de 5 ans à compter du jour de l’arrêt de la mise à disposition sur le marché de détail grand public fixe » ou lorsque moins de 10 000 unités sont exploitées sur le parc grand public.
Une des questions de la consultation porte sur les points précédents : « Le périmètre opérateurs et box concernés par le projet de décision vous parait-il pertinent ? ».
Le calendrier de mise en place, entre 12 et 28 mois
Pour que cette solution soit déployée dans un délai raisonnable, l'Arcep prévoit un calendrier en plusieurs étapes.
- 12 mois après la publication de la décision : « les opérateurs effectuent la démonstration auprès de L'Arcep d’une box de développement avec l’API implémentée conformément aux dispositions de la présente décision ».
- 20 mois après la publication de la décision : « les opérateurs implémentent et activent par défaut l’API sur 5 % des box du parc concerné par la mise en place de l’API ».
- 24 mois après la publication de la décision : « les opérateurs implémentent et activent par défaut l’API sur 40 % des box du parc concerné par la mise en place de l’API ».
- 28 mois après la publication de la décision : « les opérateurs implémentent et activent par défaut l’API sur 95 % des box du parc concerné par la mise en place de l’API [et] sur 100 % des box mises à disposition auprès des nouveaux clients sur le marché de détail grand public fixe ».
« Le calendrier retenu vous parait-il réaliste et adapté aux contraintes de développement ? Pour quelles raisons ? Sinon, quelles modifications proposez-vous ? », demande le régulateur.
Dans tous les cas, ce calendrier parait déjà bien trop long pour Alexandre Archambault, ex-directeur des relations institutionnelles d'Iliad jusqu'en novembre 2014 et désormais avocat. En juin 2018, alors que l'Arcep remettait au Parlement son bilan de santé de l'internet en France, il en profitait pour déterrer un document de 2011 dans lequel Free suggérait d'intégrer des outils de mesure directement dans la box. Une possibilité écartée par le régulateur pour finalement y revenir huit ans plus tard ?
Pour Pierre Dubreuil, chargé de mission à l'Arcep, il n'était pas question de la même chose : « la proposition de Free en 2011 était l'intégration d'une sonde dans la box des FAI. Ici, nous proposons une API qui vient seulement caractériser l'environnement utilisateur, le test restant réalisé par les outils tiers eux-mêmes ». « L'idée d'une sonde dans la box a été réétudiée, mais l'API a été préférée », ajoute-t-il.
2011 : coucou @ARCEP, dis, rapport à ton usine à gaz de monitoring de l’accès Internet, pourquoi pas via une API dans les box ?
— Alec ن Archambault (@AlexArchambault) 5 juin 2018
2012 : non, c’est pas nécessaire
2018 : oué, finalement, on va regarder.#InternetCheckUp #7ansDeReflexion pic.twitter.com/5Rj6SXyN9Q
Consultation ouverte jusqu'au 27 mai
Enfin, dernière demande : « Les acteurs sont invités à formuler, le cas échéant, d’autres observations ou propositions sur le projet de décision en consultation ». Cette consultation publique est ouverte jusqu'au 27 mai 2019. Vous pouvez y répondre par email, ou bien par courrier.
Comme toujours, « l'Arcep, dans un souci de transparence, publiera l’intégralité des commentaires qui lui auront été transmis, à l’exclusion des parties couvertes par le secret des affaires ».
