Qualité de service : l’Arcep entérine « la mise en place d’une API dans les box » des FAI

C'est fait, les box auront leur API pour améliorer la mesure de la qualité de service. Le régulateur a revu sa copie entre la consultation publique d'avril et la décision finale qui vient de tomber ; notamment suite aux retours des opérateurs. La CNIL a été consultée au passage.

En avril, l'Arcep lançait une consultation publique sur un projet surprenant au premier abord : ajouter une API dans les box des fournisseurs d'accès. Objectif, envoyer des informations précises sur la technologie d'accès utilisée avec le type de connexion chez le FAI (xDSL, FTTH, câble, etc.) et au réseau local (Wi-Fi, filaire), la mise en place d'un compteur d'octets pour détecter le cross-traffic, etc. 

« Une carte d’identité de l’accès » pour renforcer les tests de débits

Cette API « permet ainsi de caractériser l’environnement utilisateur, sans dégrader l’expérience utilisateur du client du test de mesure quel qu’il soit (testeur web, sonde matérielle, agent dans la box, logiciel installable sur le terminal, etc.) », explique le régulateur.

•  « Carte d’identité de l’accès » : les plans de l'Arcep pour ajouter une API dans les box des FAI

Dans les grandes lignes, la décision finale reprend la trame présentée dans la consultation d'avril, avec quelques ajustements. Les opérateurs avec plus d'un million de clients ont l'obligation d'ajouter cette API, mais le régulateur encourage également les autres FAI à l'implémenter, ce qui ne sera pas toujours facile selon l'AOTA. 

On trouve d'ailleurs un détail « amusant » dans le retour de la Fédération FDN pour qui  « le seuil d’un million de clients semble élevé et sorti au doigt mouillé ». Ce n'est pas – loin de là – le seul reproche des opérateurs au projet de l'Arcep, comme nous allons le voir. 

L'API dans les box commercialisées depuis juillet 2008

Tout d'abord, « les modèles de box concernés par la mise en place de l’API sont ceux mis à disposition sur le marché de détail grand public fixe haut débit et très haut débit à l’issue d’un délai de 18 mois à compter de la publication de la présente décision au Journal officiel » et qui réunissent les trois conditions suivantes :

• les modèles de box pour les technologies xDSL, câble, FTTH ainsi que les modèles de box d’accès fixe supportant la technologie 5G
• les modèles de box ont une date de première commercialisation postérieure au 1er juillet 2008
• le nombre de box mises à disposition sur le marché de détail grand public fixe haut débit et très haut débit dépasse, pour le modèle de box concerné, les 30 000 unités

Le régulateur est donc moins ambitieux puisqu'il était auparavant question d'un délai de 12 mois après la publication au J.O. et d'un seuil de 10 000 box pour déclencher l'obligation d'installer l'API, au lieu de 30 000 aujourd'hui. Une fois les 18 mois écoulés,  les modèles de box soumis à l'obligation auront trois mois une fois le seuil des 30 000 unités dépassé.

Surtout, l'Arcep limite désormais l'obligation aux box dont la première commercialisation est « postérieure au 1er juillet 2008 ». Chez Free, cela ne devrait donc pas remonter avant la Freebox Révolution, contre la Livebox 2 pour Orange par exemple. 

Comme précédemment, les « box ne sont plus concernées par la mise en place de l’API 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 », ou bien « lorsque les modèles de box sont respectivement présents en moins de 30 000 exemplaires dans le parc de clients de l’opérateur », contre 10 000 auparavant.

Une API activée par défaut, avec TLS et OAuth

Comme demandé durant la consultation, et « afin que les acteurs puissent réaliser des publications sur un nombre suffisant de mesures caractérisées pour être représentatif, l’API est activée par défaut, pour toutes les box compatibles, sans intervention de l’utilisateur. Une uniformisation du format de sortie est nécessaire et le format JSON (JavaScript Object Notation) a été plébiscité par l’écosystème ». 

Pour des raisons de sécurité et de confidentialité, « l’API ne répond pas sur une connexion HTTP sans couche de chiffrement TLS. L’API n’est accessible que depuis le réseau local (LAN) de l’utilisateur final et ne répond pas aux requêtes qui pourraient provenir d’Internet ». TLS 1.2 est recommandé (on peut supposer que la 1.3 aussi), mais TLS 1.0 et 1.1 restent « tolérés » si besoin, alors que les navigateurs les abandonneront dans les mois qui viennent.

Toujours sur la sécurité et afin de « réduire le périmètre d’attaque, un système de restriction d’accès doit être mis en place. La restriction d’accès retenue en concertation avec les différents acteurs impliqués est : CORS + OAuth 2.0 (https://oauth.net/2/) avec un token à validité de 15 minutes ».

L'Arcep veut un état des lieux annuel

Les opérateurs doivent transmettre chaque année à l'Arcep tout un flot d'informations, dont : la liste des différentes box sur le marché grand public prenant en charge l'API, les dates d'activation et désactivation des API sur les box, la liste des outils de mesure autorisés à accéder à l'API et les raisons éventuelles conduisant à un « refus d’accès pour un outil de mesure qui s’est déclaré conforme au "Code de conduite de la qualité de service" en vigueur ».

Pour le moment, cinq outils de test de qualité de service d'Internet se sont déclarés conformes au code : nPerf,  SpeedTest UFC-Que Choisir, DébitTest 60, 4GMark et IPv6-test. Le régulateur précise au passage que « le Code de conduite de la qualité de service internet, version 2018, qui fixe un niveau minimum de transparence et de robustesse, sera amené à évoluer périodiquement ».

Enfin, dans un souci de transparence, l'Arcep pourra rendre publique la liste des box prenant en charge l’API, ainsi que celles des outils autorisés à y accéder. 

Un calendrier plus généreux, deux à six mois de plus pour les FAI

Le calendrier de mise en place glisse de deux à six mois sur l'ensemble des échéances, avec l'ajout d'une mention « au minimum » devant le pourcentage de box concernés :

• 18 mois (au lieu de 12) 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 ».
• 22 mois (au lieu de 20) après la publication de la décision : « les opérateurs implémentent et activent par défaut l’API sur au minimum 5 % des box du parc concerné par la mise en place de l’API ».
• 26 mois (au lieu de 24) après la publication de la décision : « les opérateurs implémentent et activent par défaut l’API sur au minimum 40 % des box du parc concerné par la mise en place de l’API ».
• 30 mois (au lieu de 28) après la publication de la décision : « les opérateurs implémentent et activent par défaut l’API sur au minimum 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 ».

Cette décision de l’Arcep « va être transmise pour homologation au ministre chargé des communications électroniques puis, sous réserve d’homologation, publiée au Journal officiel ». La première échéance de 18 mois débutera alors.

Que pensent les opérateurs des objectifs de l'Arcep ?

Comme à chaque fois, l'Arcep a mis en ligne les réponses obtenues à sa consultation, et elles sont toujours intéressantes pour comprendre certains changements opérés en cours de route.

Les quatre opérateurs nationaux se retrouvent sur plusieurs points. Dans l'ensemble, Bouygues Telecom, Orange et SFR s'accordent pour dire que l'objectif d'améliorer la mesure de la qualité de service est atteint par la proposition de l'Arcep. Mais ils ont également d'accord pour dénoncer en bloc le second objectif sur « l’établissement d’un diagnostic précis d’un problème de qualité de service ». Rien d'étonnant. 

Pour Bouygues Telecom, « une multitude d’éléments externes, non couverts par l’API, pourraient fausser ce diagnostic et ainsi induire le consommateur en erreur sur le problème rencontré ». Orange « est opposée au second enjeu [qui] soulève à la fois des interrogations majeures quant au respect de la vie privée et de la confidentialité des données personnelles. De plus, cela pourrait conduire à ce que ce diagnostic soit contraire aux recommandations du FAI qui porte seul la relation contractuelle avec le consommateur ».

Même son de cloche chez SFR : ce dispositif ne peut « servir à identifier un éventuel problème de qualité de service et permettre d’engager la responsabilité d’un opérateur pour non-respect de ses obligations contractuelles. La qualité de la connexion wifi par exemple n’est mesurée qu’à un instant alors que cette donnée est à la fois sujette à de fortes variations et déterminante dans la pertinence des mesures qui peuvent être effectuées. De la même façon, SFR note que les caractéristiques du terminal sur lequel sera effectuée la mesure ne sont pas du tout prises en considération ». 

Free « fermement opposé » à la communication de certaines données

Et Free alors ? Pour l'opérateur « ce projet de décision [...] parait insuffisant pour satisfaire les objectifs visés ». La société « constate [qu'il] n’adresse pas la plupart des raisons pour lesquelles ces outils de mesure ne répondent pas aux attentes [...] A défaut, ce projet ne convainc pas Free que ces outils de mesure puissent remplir demain les objectifs qu’ils ne remplissent pas aujourd’hui  ». 

Concernant les informations renvoyées par l'API, « Free est fermement opposé à la communication des données relatives au modèle de box [...] La répartition du parc par box est une donnée stratégique et confidentielle. Il n’est pas raisonnable d’imposer aux FAI de rendre cette donnée publique ou de permettre à des concurrents d’y accéder ».

Le FAI a été entendu sur certains points. Alors que le modèle de la box, les versions hardware et software devaient obligatoirement être présents dans le JSON (annexe 1 du projet de décision), ces informations sont désormais facultatives (annexe 1 de la décision finale) et la notion de version hardware a même disparu.

Les anciennes box de la discorde

Les fournisseurs d'accès sont également contre l'intégration de l'API sur des box d'anciennes générations encore utilisées par certains clients. Pour Bouygues Telecom, la mise en œuvre de cette API « ne doit devoir être implémentée, et maintenue, que sur les box sur lesquelles il est techniquement et opérationnellement possible de le faire ».

Free est sur la même longueur d'onde et affirme qu'il « n’implémentera pas cette API sur ses modèles de box les plus anciens (ex : Freebox V5). Les évolutions demandées dans le cadre de cette API nécessiteraient une mise à jour majeure de leur firmware ce qui n’est pas possible […] Il ne nous paraît pas raisonnable, ni proportionné au regard des objectifs visés, de remplacer toutes les box de ce modèle encore en service, y compris à échéance de quelques années ».

« Le projet de décision semble faire le pari que ces box anciennes ne seront plus commercialisées dans les douze mois suivant la Décision. Nous ne partageons pas ce point de vue. Ces box jouent encore un rôle essentiel pour Free et pour les consommateurs dont le pouvoir d’achat est faible », ajoute l'opérateur dans sa réponse.  Avec une date fixée au 1er juillet 2008, la Freebox V5 n'est donc pas concernée.

Idem chez SFR qui voulait aller largement plus loin : « toutes les anciennes générations de box, antérieures à 2017, pour lesquelles plus aucune évolution et maintenance n’est mise en œuvre, doivent pouvoir continuer à être proposées à la commercialisation dans le cadre d’offres ou d’opérations limitées, sans que l’API ne soit disponible sur celles-ci ». 

Oui, SFR a réuni dans la même phrase « anciennes générations », « 2017 » et « plus aucune maintenance ».

L'AOTA rappelle la difficulté de certains petits opérateurs volontaires

L'Association des opérateurs télécoms alternatifs (AOTA), résume l'ambiance générale : elle « estime que le critère pertinent n’est pas la date de commercialisation, mais de conception de la box : en effet, dans une logique de développement durable, les opérateurs peuvent être amenés à proposer à leurs clients dont les besoins sont basiques une box reconditionnée dont les développements fonctionnels ont été stoppés il y a plusieurs années, l’équipementier n’assurant que les correctifs de sécurité ».

Pour l'AOTA, la mise en place de l'API ne doit pas entraîner des charges disproportionnées, notamment pour les petits opérateurs qui risquent d'avoir plus de mal à la mettre en place : « En effet, si les principaux opérateurs, par leur pouvoir de marché reposant sur un parc de plusieurs millions de box en circulation, peuvent disposer d’une relation privilégiée, notamment en ce qui concerne l’accès à la couche logicielle des box, avec les équipementiers, voire même pour certains en étant leur propre équipementier pour les box, c’est loin d’être le cas pour les opérateurs de taille plus modeste ».

Concernant la 5G, Bouygues Telecom et la Fédération Française des Télécoms souhaitaient exclure les box du périmètre d'action. Ils n'ont pas été écoutés par le régulateur puisque les box 5G sont incluses d'office, contrairement à celles en 4G qui sont sur la base du volontariat.

La FFDN soulève la question de la vie privée

De manière générale, la Fédération des fournisseurs d'accès à Internet associatifs (FFDN) trouve à redire sur de nombreux points du projet. Tout d'abord sur la question des données personnelles : « l’API est capable d’informer le service de tests de la nature de l’abonnement souscrit : prenons l’offre Orange qui couple fixe et mobile. Son tarif s’élève à 78 puis 113 euros par mois. Très clairement, cette seule information permet d’identifier le niveau de vie de l’utilisateur : il faut un certain niveau de revenus pour pouvoir assumer ce coût mensuel ».

Ensuite, vient la question de la longueur de la ligne : « C’est une information utile pour l’évaluation de l’atténuation du signal. Mais couplée à la zone géographique de l’abonné, on peut en déduire non pas son adresse exacte, mais au moins sa localisation de manière assez précise (vit-il à la campagne, en centre-ville, dans quelle ville... ?) ». 

Qu'en pense la CNIL ?

Bref, pour FFDN « toutes ces données sont des données personnelles, puisqu’elles identifient les personnes de manière au minimum indirecte (par exemple : niveau de vie, localisation) [...] Leur usage dans le cadre de l’évaluation de la qualité de service peut se comprendre, mais cela doit d’une part, se faire en conscience et, d’autre part, s’accompagner de garanties ». La fédération regrette ainsi que « le projet de décision fasse apparaître une trace d’une consultation de la CNIL sur ce point ».

Dans son communiqué d'octobre, l'Arcep a pris note de cette remarque puisqu'elle consacre un passage à la Commission :  « Questionnée dans le cadre de cette démarche, la CNIL a pu s’assurer que le dispositif répondait dans son principe aux exigences en matière de protection des données personnelles tout en insistant sur l’importance du rôle de conseil de l’Arcep, notamment au travers du "Code de conduite de la qualité de service internet" vis-à-vis des outils de mesure exploitant l’API ».

Sur le test de qualité de service en lui-même, FFDN estime qu'il s'agit d'un projet « pertinent et bienvenu », mais la fédération aurait aimé aller plus loin : « Il pourrait être pertinent d’ajouter, de façon optionnelle, un objectif pédagogique : les résultats retournés par l’API pourraient être habillés dans une explication fonctionnelle de la structure technique du FAI. L’ensemble pourrait être géré en natif sur la box ou sur le portail du FAI qui retournerait les résultats de l’API ». Il n'en est pas question dans la version finale de la décision.

Dans tous les cas, la FFDN salue « le fait que l’Autorité ait choisi d’utiliser pour cette API des protocoles standards, rendant aisée l’implémentation de celle-ci dans des logiciels libres comme OpenWRT ».