Pour les opérateurs télécoms, les NaaS sont considérés comme une "seconde chance" de récupérer la valeur qu'ils ont perdue au profit de "l'acteur dominant". Mais la disruption n'est pas simple, et elle doit surmonter plusieurs défis pour être monétisée.
Pendant longtemps, les architectures réseau sont restées spécifiques, séparées des systèmes issus de l’informatique. En particulier, les logiciels télécoms étaient traditionnellement propriétaires et fonctionnaient exclusivement sur des machines fournies par les équipementiers (Nokia, Ericsson, Alcatel, Cisco...). La virtualisation, qui permet aux logiciels de fonctionner sur des serveurs banalisés a réuni les deux mondes. La 5G en particulier est nativement virtualisée. Il est (presque !) alors envisageable d’interagir avec les services réseaux comme avec n’importe quel logiciel informatique.
Architecture 5G et Function d'ExpositionRéseau
Dans l'architecture 5G, la fonction d'exposition au réseau (NEF) est la couche qui expose les fonctions 5G à des tierces parties via des Application Programing Interfaces (API).
En aval, la NEF interagit en temps réel avec de nombreuses fonctions centrales de la 5G, par exemple la PCF (Policy Control Function) qui entre autres contrôle les flux et la qualité de service, NWDAF (Network Data Analytics Function) qui peut fournir des données réseau en temps réeel et la SMF (Session Management Function) qui peut influencer le routage du trafic vers des destinations privilégiées comme des serveurs en périphérie de réseau (edge).
En termes plus concrets, la 5G peut être connectée à une application externe, en vue :
- D’adapter la qualité de service à la demande. On peut donner la priorité à certains appareils/applications : robots en temps réel, diffusion de médias/événements, services d'urgence, XR spécifique, ….
- De fournir des informations en temps réel qui peuvent être utilisées pour des analyses pointues, ou bien à des fins de sécurité. Le réseau peut ainsi garantir l’intégrité des objets connectés.
- D’appliquer un routage réseau spécifique en donnant un accès privilégié à certaines ressources. On peut optimiser le routage d'une certaine application afin de réduire les temps de réponse.
Cette capacité est appelée "Network as a Service" (NaaS). Les NaaS sont parfois considérés comme une "seconde chance" pour les opérateurs télécoms de récupérer la valeur qu'ils ont perdue au profit des géants du web « over the top ». Mais Cette opportunité doit surmonter plusieurs défis pour être monétisée. Différents facteurs peuvent perturber cette innovation comme une mauvaise politique de prix, l’absence de compatibilité entre les acteurs ou un Go-to-Market inadapté.
Passons en revue ces défis.
#Défi n°1 : Les clients des NaaS ne sont pas les clients habituels des opérateurs télécoms
Le client des NaaS (la tierce partie qui interagit avec l’API) n'est pas l'utilisateur final avec sa carte SIM, mais un fournisseur d’applications qui offre à cet utilisateur final un service intégrant une fonction NaaS. Pour illustrer ceci, on peut penser à la façon dont l’API Google Map peut être intégrée dans toutes sortes d’applications intégrant de la géolocalisation (par exemple Uber). Dans ce cas c’est Uber qui paye à Google l’utilisation de l’API.
Pour revenir aux NaaS, l’application peut être un logiciel e-d'agriculture souhaitant renforcer les capacités de ses capteurs connectés, un OTT1 de vidéo d'entreprise (tel que Zoom) cherchant à améliorer l'efficacité des communications, etc..... Ainsi l’opérateur n’est pas nécessairement bien placé pour comprendre comment le service NaaS est utilisé, et comment il est intégré dans la chaîne de valeur. C'est un véritable défi pour en faire la promotion et en fixer le prix. Selon les cas, un même NaaS peut s’avérer indispensable pour une application et accessoire pour un autre cas d’usage.
#Défi n°2 : La base de clients est fragmentée entre les opérateurs télécoms
En supposant qu'une application cible une zone géographique donnée (par exemple un pays), un fournisseur de services applicatifs cherchera à servir tous les utilisateurs des 3 ou 4 réseaux mobiles.
Une solution spécifique à un opérateur qui ne serait pas compatible avec un autre opérateur sera considérée comme une cible réduite pour un fournisseur de services applicatifs (le client du NaaS). Ainsi les opérateurs doivent oublier d'utiliser ces NaaS pour se différencier sur leur propre base de clients et chercher au contraire à élargir son champ d’application.
Pour séduire leurs clients ils se doivent de développer conjointement des outils qui éliminent les complexités et favorisent l’interopérabilité.
Cela devrait conduire à l'adoption de standards inter-opérateurs, initiatives qui ont eu parfois un mauvais bilan en termes de rapidité de mise sur le marché.
#Défi n°3 : Qui contrôle l'écosystème ?
Pour des raisons de sécurité, les opérateurs ne peuvent pas offrir la NEF (Network Exposure Function) directement à des tiers, et devront créer une sur- couche API pour définir des services spécifiques à leur intention.
Il y a donc une problématique autour de cette couche supérieure et de sa normalisation : quelle instance pour fédérer ?
Il pourrait être plus efficace de confier la tâche de concevoir ladite couche à un acteur indépendant des opérateurs de télécommunications. Elle serait davantage axée sur le client et, surtout, neutre. Paradoxalement, les fournisseurs de service (AWS, Microsoft Azure, Google Cloud), qui étaient supposés perdre de la valeur au profit des opérateurs, sont aujourd’hui bien positionnés comme intermédiaires.
#Défi n°4 : Les opérateurs doivent adopter une approche par cas d’usage plutôt qu'une approche axée sur les fonctionnalités
Les développeurs des applications autour de NaaS sont concentrés sur les enjeux techniques de leurs clients et de leurs verticales : objets connectés, agriculture, transports, etc… Beaucoup de magasins d’applications (« marketplaces ») sont organisés autour des cas d’usages, dans une logique d’écosystème. Or ces marketplaces sont clés pour la distribution des APIs.
Par exemple, le succès d'entreprises comme Twilio sur le marché CPaaS (Communications Platform as a Service) peut être attribuée à leur capacité à offrir en un seul endroit tout le panel des applicatifs de la gestion de la relation client.
Ici le facteur déterminant n’est pas la technologie mais l’écosystème d’un cas d’usage. Ceci est assez peu familier pour les opérateurs, qui de plus ne peuvent espérer embrasser tous les écosystèmes.
#Défi n°5 : Ce sont des solutions assez « satisfaisantes »
La plupart des services à valeur ajoutée réseaux ont un équivalent en mode OTT. Les applications qui utilisent les réseaux ont paré à leurs points faibles en développant une série de stratégies, sans attendre que les opérateurs proposent des solutions. L'écosystème s'est adapté, même si c'est parfois au compromis de la performance. Et quand le réseau apporte des solutions, il est trop tard.
Pour donner un équivalent historique, rappelons qu'au cours des années 2000, de nombreux débats ont eu lieu pour savoir si l'ATM était meilleur ou non que l'IP en matière de transport du flux audio/vidéo. Bien que l’ATM/Telco soit susceptible d’être d’optimal, les réseaux Internet/OTT ont démontré depuis lors leurs capacités à transporter des communications professionnelles. Etant simple, solide, bon marché et universel, l’internet s'est avéré "Suffisant", bien que loin d’être le meilleur.
Un exemple plus récent est le SD-WAN (Software Defined Wide Area network), qui est une solution pour construire des réseaux d’entreprises, quelque soit le réseau sous-jacent. Les réseaux d’entreprises basés sur des solutions opérateurs MPLS ont un meilleur contrôle de la qualité de service mais sont moins universels.
La concurrence dans le monde des API NaaS ne se fait pas contre d'autres API NaaS, mais plutôt contre les solutions alternatives OTT (over-the-top). Les hyperscalers (pourtant fournisseurs de services OTT) peuvent servir de facilitateurs pour le développement des NaaS en les intégrants dans leurs magasins d’applications, ou en développant la couche au dessus des APIs NEF.
Si les telcos veulent bénéficier de l’opportunité NaaS, ils doivent renoncer à certains privilèges tels que l'accès direct à leurs clients, l'exclusivité des services ou le contrôle de l'usage final. Il leur faut aussi réévaluer le NaaS dans l'ensemble de la chaîne de valeur et probablement au cas par cas.
La demande client en fonctionnalités spécifiques 5G, telles que la faible latence, les réseaux mobiles hybrides, les analyses de données en temps réel, décidera une fois pour toutes du décollage des NaaS et de la révolution copernicienne des opérateurs qui pourrait s’en suivre.
1OTT: Over The Top désigne les solutions qui permettent de transférer des données et/ou des applications cloud sans dépendre d'une infrastructure de réseau particulier, et vers tout terminal que ce soit.
