Trois systèmes, un écran et un tracé autrefois dessiné à la main

Un commercial ne pouvait répondre à la première question d’un client sans ouvrir trois systèmes et une carte.

Pour un fournisseur de connectivité aux entreprises, toute demande commence ainsi : pouvez-vous desservir cette adresse, et combien faut-il facturer ? Répondre honnêtement exigeait de réunir à la main quatre éléments distincts.

Qu’achète déjà ce client, et à quel prix ? Cela se trouve dans l’ERP, Microsoft Dynamics NAV, sous forme de dix ans de lignes de factures, avec le lieu de service saisi dans un champ de texte libre.

Avons-nous déjà établi un devis à cette adresse ? Cela se trouve dans le CRM, Intrix. Et souvent, il était tout simplement impossible de répondre : moins des deux tiers des devis portent une adresse de service précise. La réponse était donc fréquemment introuvable, même lorsqu’elle existait.

Quelle infrastructure se trouve réellement dans cette rue ? Cela se trouve dans iObčina, le portail SIG public municipal, une application web distincte consultée adresse par adresse.

Et si le client veut une liaison privée entre deux de ses bâtiments, quelqu’un devait déterminer un trajet physique pour la fibre. Le câble ne suit pas des lignes droites. Il emprunte des fourreaux, poteaux et tranchées appartenant à différentes entreprises : le gestionnaire du réseau de transport, les distributeurs régionaux d’électricité, l’opérateur télécom lui-même. Planifier un tracé signifie chaîner ces réseaux, décider où passer d’un propriétaire à l’autre et produire un document à envoyer à chacun pour demander autorisation et prix.

Ce tracé était dessiné à la main, sur des cartes.

Cette préparation manuelle prenait jusqu’à un mois. Un mois entre la demande de prix d’un raccordement et la réception d’une offre, consacré non à la négociation ou à l’ingénierie, mais à chercher dans trois systèmes et à tracer une ligne sur une carte.

Une étape aussi lente finit par être sautée. Un devis établi sans vérifier ce que le client paie déjà, ou ce qui se trouve déjà dans le sol, est une supposition.

Un écran. Saisissez une adresse.

Tout ce qui était réuni à la main revient : les clients existants à proximité avec leurs services et tarifs mensuels, les anciens devis à cet endroit, une comparaison des prix selon le débit et les réseaux publics à ces coordonnées. Le tout est dessiné sur une carte interactive sur fond d’images aériennes, avec un PDF à l’identité de l’entreprise pour le client, en un clic.

Et un second mode qui planifie le tracé.

Donnez-lui deux adresses : il propose jusqu’à trois tracés physiques de fibre entre elles, à travers les réseaux cartographiés de huit propriétaires d’infrastructure : le gestionnaire national du réseau de transport ELES (1 454 km cartographiés), les distributeurs régionaux Elektro Ljubljana (1 066 km), Elektro Maribor (847 km), Elektro Celje (267 km), Elektro Gorenjska (98 km) et Elektro Primorska (95 km), le producteur DEM (135 km), et la fibre propre au client (587 km). Il propose le tracé le plus court, celui qui traverse le moins de propriétaires et celui qui comporte le moins de points uniques de défaillance. Chaque passage entre les réseaux de deux propriétaires est signalé, car chacun correspond en réalité à une épissure : un coût, une autorisation et un endroit où la liaison peut rompre.

Le tracé s’exporte en fichier Google Earth avec un dossier par propriétaire d’infrastructure. Le client envoie ainsi à chacun exactement le tronçon qui traverse son réseau, et rien d’autre.

Dix ans d’historique de facturation, interrogeables par lieu pour la première fois. 138 019 lignes sur 51 503 factures, remontant à 2016. L’adresse de service n’avait jamais été un champ structuré : 165 853 points de terminaison de service ont donc été extraits du texte libre, auparavant impossible à interroger géographiquement, et les débits ont été reconstitués à partir de 77 454 lignes saisies à la main.

L’infrastructure de huit propriétaires, rendue exploitable pour le calcul de tracés. 20 721 objets de réseau, dont 5 644 lignes totalisant environ 4 549 km, réunis en un seul graphe que le moteur de routage peut parcourir.

D’un mois au maximum à quelques minutes.

Les données nécessaires au commercial lui parviennent désormais en quelques minutes au lieu d’être réunies sur plusieurs semaines. L’offre part elle aussi en quelques minutes. Le mois n’est pas devenu une semaine. Il est devenu le temps de saisir une adresse.

C’est tout le retour du projet, et il faut préciser d’où il vient : non pas faire le même travail plus vite, mais ne plus le faire du tout. Plus personne ne cherche dans trois systèmes. Plus personne ne dessine un tracé à la main. Les recherches se déclenchent parce qu’une adresse a été saisie.

À l’exécution, il n’y en a pas, et c’est la bonne réponse.

Trouver un tracé sur 4 549 km d’infrastructure appartenant à d’autres est un problème de plus court chemin dans un graphe, pas une affaire de jugement. Déterminer quels clients sont proches d’une adresse relève d’un index spatial. Les deux doivent être exacts, rapides et explicables, et un modèle dégraderait ces trois qualités.

L’IA a été le moteur de construction ; sans elle, ce système n’existerait pas.

Deux des trois systèmes n’offraient aucune voie d’accès.

Extraire des données de Dynamics NAV suppose normalement de faire appel à un partenaire de développement NAV. C’est la voie prise en charge, et quiconque l’a chiffrée en connaît le coût et le délai. Aucun partenaire n’a été engagé ici : une passerelle en lecture seule a été construite à la place, sur le propre serveur Windows du client, protégée par une clé API et une liste d’adresses IP autorisées.

iObčina n’a aucune API publique. C’est une application de navigateur qui communique avec des points de terminaison non documentés, et les données importantes, le rapport de réseaux pour un jeu de coordonnées, nécessitent une connexion.

Les deux ont été ouverts de la même manière : observer le trafic réel, reconstituer les contrats d’interface et les reconstruire sous forme de clients documentés. Ces documents contractuels font désormais référence pour les deux intégrations : c’est la différence entre un script qui fonctionne par chance et une intégration qu’une autre personne peut maintenir.

Le troisième système n’en avait pas besoin. Intrix fournit une interface d’export documentée, simplement utilisée comme prévu. Deux sur trois, pas trois sur trois. Il importe de le dire, car la rétro-ingénierie était un dernier recours, pas le premier réflexe.

Toute la thèse tient dans ce projet. La difficulté n’a jamais été l’algorithme. C’était de sortir les données de systèmes qui n’avaient jamais été conçus pour les livrer.

Les livrables les plus précieux étaient des rapports sur ses propres données.

Rendre dix ans d’enregistrements exploitables pour le calcul de tracés impliquait de tous les lire, et cette lecture a révélé des choses que personne ne savait :

• 233 comptes Intrix portaient le numéro client NAV d’une autre entreprise, ce qui

ouvrait discrètement la mauvaise fiche client.

• 3 001 discontinuités dans leur propre carte d’infrastructure : 264 endroits où un câble s’arrête sans

rien à portée d’épissure, la plus grande coupure mesurant 903 mètres, et 2 737 endroits où deux lignes du même propriétaire passent à moins de 60 mètres sans jamais se rejoindre.

Les deux ont été remis sous forme de fichiers de travail : un tableur et une couche Google Earth. Aucun n’était dans le périmètre. Les deux pourraient valoir autant que l’application.