Automatiser les commandes d'accès fibre entre opérateurs télécoms

Passer une commande d’accès pour un nouvel abonné fibre, entre un opérateur d’infrastructure (OI) et un opérateur commercial (OC), demande de suivre des protocoles d’interconnexion précis (DSL, Interop’Fibre) et implique souvent, en pratique, de remplir des fichiers CSV à la main pour chaque commande. Multiplié par le volume de commandes d’un opérateur qui grandit, ce processus devient vite un goulot d’étranglement administratif plutôt qu’un problème technique.

C’est ce type de processus que Fasfox a automatisé pour des opérateurs télécoms, en développant des solutions sur mesure autour des protocoles d’interconnexion. Cet article détaille ce que ça change, puis prend l’exemple d’un projet mené pour Legos, un opérateur qui s’est développé en Allemagne.

Ce que l’automatisation change dans la relation OI/OC

Le secteur des télécommunications a ses propres protocoles d’échange entre opérateurs d’infrastructure et opérateurs commerciaux : commande d’accès, commande de PM (point de mutualisation), commande de liens PM/PRDM. Historiquement, une partie de ces échanges se fait par des fichiers plats échangés manuellement, avec les délais et les erreurs de saisie que cela implique.

Automatiser ces échanges, en centralisant les données et en connectant les systèmes plutôt qu’en les faisant communiquer par fichier, apporte des bénéfices concrets :

• moins de temps passé à remplir des commandes manuellement pour chaque nouvel abonné,
• un meilleur suivi des commandes en cours et des sites auxquels un opérateur a accès (PM, PRDM, NRO),
• une communication plus directe entre les intervenants côté OI et côté OC,
• la possibilité, pour un opérateur commercial, d’élargir son périmètre plus facilement puisque l’intégration à un nouvel OI devient moins coûteuse.

Ce que Fasfox a développé sur ce terrain

Fasfox développe des solutions sur mesure autour des protocoles d’interconnexion DSL et Interop’Fibre, pour automatiser la prise de commandes d’accès et simplifier les échanges entre opérateurs d’infrastructure (Orange, Free Infra, SFR, notamment) et opérateurs commerciaux.

Concrètement, ces outils permettent de passer des commandes de PM, des commandes de liens PM/PRDM et des commandes d’accès en mode STOC, de vérifier l’éligibilité d’une adresse pour le déploiement de la fibre, de gérer les accès aux sites PM et PRDM, et de suivre le SAV des lignes pour maintenir le parc en conditions opérationnelles.

Le cas Legos : adapter une plateforme pour un nouveau marché

Legos est un opérateur téléphonique qui vend des numéros fixes et mobiles à ses clients, lesquels réservent des plages de numéros puis les attribuent à des utilisateurs finaux. Présent en France, Legos a voulu s’étendre en Allemagne, ce qui supposait d’adapter sa plateforme à un marché aux règles différentes.

Plusieurs contraintes se posaient : faire évoluer la base de données existante sans casser le fonctionnement en France, développer une nouvelle API pour gérer les commandes au format allemand (trunk/SDA, numéros mobiles), et intégrer une contrainte réglementaire propre à l’Allemagne, la collecte des pièces d’identité avant l’activation d’une ligne, absente du processus français.

Fasfox a fait évoluer la base de données de façon non destructive, développé l’API v2 pour les commandes allemandes tout en maintenant la compatibilité avec les commandes françaises, intégré la collecte des pièces d’identité dans le flux existant, et mis à jour l’interface pour les opérateurs qui ne passaient pas par l’API. Résultat : Legos a pu s’implanter en Allemagne sans interrompre son activité en France, avec une conformité réglementaire intégrée directement dans le processus plutôt que traitée à part.

Que retenir ?

Le point commun entre l’automatisation des commandes OI/OC et le projet Legos, c’est qu’aucun des deux ne part de la technologie : les deux partent d’un processus administratif ou réglementaire précis qui coûtait du temps ou représentait un risque, et construisent l’outil qui le résout. Dans un secteur aussi normé que les télécoms, c’est souvent la maîtrise fine des protocoles et des contraintes réglementaires locales, plus que la sophistication technique, qui fait la différence entre un projet qui tient et un projet qui n’aboutit pas.