Blog · Développement

FIBERGIS
un SIG fibre à moindre coût, et le risque du sur-mesure

Un SIG fibre coûte cher par la saisie, pas par la licence. Ce que l'IA fait réellement baisser dans FIBERGIS, et les cinq risques du sur-mesure.

Pourquoi un SIG fibre coûte cher, et ce n'est pas la licence

Un système d'information géographique pour réseau fibre, c'est une carte où chaque point porte une réalité physique : ce boîtier, cette chambre, ce câble de 72 fibres, cette cassette d'épissure, ce port du splitter. Le logiciel doit répondre à une question que le tableur ne sait pas poser : où est la fibre numéro 37 du câble 12, et sur quel port arrive-t-elle ?

Les devis de ce marché dépassent souvent le budget d'une année d'exploitation, et la raison n'est jamais celle qu'on croit. Le logiciel libre existe, les fonds de carte sont gratuits ou peu chers, les serveurs ne coûtent presque rien. Ce qui coûte, c'est la saisie : relever un réseau existant, câble par câble, chambre par chambre, avec quelqu'un qui marche sur le terrain et quelqu'un qui encode le soir.

Vouloir un SIG « à moindre coût » suppose donc de s'attaquer à ces trois postes, saisie, modèle de données, développement, et pas seulement au dernier.

FIBERGIS, et ce qu'il contient réellement

FIBERGIS est notre application de gestion de réseau fibre, en service sur fibergis.islandcloudsolution.net. Derrière l'interface cartographique, l'API expose 72 points d'entrée et une trentaine d'objets métier. Ce sont eux qui disent si l'outil est sérieux ou décoratif :

FamilleCe qu'elle modélise
features, shapes, layersLes points, les tracés et les calques : la carte elle-même, avec sa géométrie
cables, fibers, splices, portsLe cœur du métier : un câble contient des fibres, une fibre s'épissure dans une cassette, une extrémité arrive sur un port
connections, feature-relationsLa continuité logique : ce brin relie ce boîtier à cet abonné
ground-plans, documentsLes plans de récolement et les pièces jointes, rattachés à l'objet qu'ils documentent
work-orders, projectsLe travail : interventions, chantiers, ce qui reste à faire et par qui
qrcodesLe lien entre le terrain et la base : une étiquette scannée ouvre la fiche du point
snmpL'état des équipements actifs, un OLT qui ne répond plus est une coupure, pas une ligne de tableau
import-exportL'entrée et la sortie des données : sans cela, un SIG est une prison

La technique, elle, est volontairement banale : un backend FastAPI en Python, une base SQLite, une interface React servie en statique, derrière un frontal qui gère le chiffrement. Pas de licence par siège, pas de serveur d'application propriétaire. La banalité est une qualité : elle rend le remplacement possible.

Où l'IA fait vraiment baisser la facture

Il faut être précis, parce que « l'IA divise le coût par dix » est faux dans l'ensemble et vrai dans certaines parties très identifiables.

  • Le code répétitif soixante points d'entrée d'API, ce sont soixante fois le même schéma de validation, de requête et de test. C'est exactement ce qu'un modèle produit correctement, et exactement ce qu'un développeur trouve ennuyeux.
  • Les analyseurs de fichiers un plan de récolement arrive en PDF, en DXF ou en CSV mal formé, avec un format différent par bureau d'études. Écrire un analyseur par fournisseur prend des jours ; le faire écrire, quelques heures, avec une relecture.
  • Le style cartographique règles de rendu, palettes, étiquettes, seuils de zoom. Purement mécanique, très visuel, et donc facile à vérifier à l'œil.
  • La documentation un modèle de données qui n'est pas documenté est un modèle qui meurt avec celui qui l'a conçu.

Et là où l'IA ne fait rien gagner, il faut le dire aussi : le modèle de données (combien de fibres par câble, comment représenter une cassette, que faire d'une fibre coupée), la saisie terrain, et la recette c'est-à-dire la vérification que ce qui est en base correspond à ce qui est dans la chambre.

Des outils sur mesure : la vraie économie

Le gain décisif n'est pas dans le prix du logiciel, il est dans le périmètre. Un produit du marché impose ses écrans, ses objets et ses habitudes ; il faut adapter l'entreprise au logiciel. Un outil sur mesure fait l'inverse : il porte le vocabulaire du client, ses exceptions, ses manies.

Concrètement, cela veut dire qu'une fonctionnalité se décide en une réunion et se livre en quelques jours, l'étiquette QR sur les boîtiers, la vue « ce brin est-il libre jusqu'au point de mutualisation », l'export que l'exploitant doit remettre à l'opérateur. Ce sont ces détails qui déterminent si l'outil est utilisé ou abandonné au bout de six mois.

Mais alors, un risque pour le logiciel ?

Oui. Et il vaut mieux le dire ici que le découvrir en réunion. Cinq risques réels, tous maîtrisables, aucun magique.

RisqueCe qu'il donne en vraiCe qu'on fait
Le code qu'on ne comprend plusUn modèle produit quinze fichiers en une heure ; personne ne sait pourquoi la ligne 340 est là. Le jour de l'incident, c'est un mur.Tout ce qui entre en production est lu, et ce qui n'est pas compris est réécrit, pas fusionné
La dette de dépendancesUne bibliothèque abandonnée, et la mise à jour du serveur casse l'applicationVersions figées, montée de version testée, pas de dépendance qui ne se justifie pas
Les réglages par défautUne documentation d'API publique, un mode debug oublié, un compte de démonstration actifUne revue de configuration avant chaque mise en ligne, c'est le premier endroit où l'on regarde, pas le dernier
La dépendance à une personneUn seul être humain sait comment redémarrer la bêteProcédure écrite, sauvegardes testées, dépôt de code versionné, accès documenté
L'abandonLe vrai risque, et de loin. Un logiciel sur mesure que personne ne maintient devient une charge, pas un actifUn budget de maintien annuel assumé, ou pas de logiciel sur mesure du tout

À quoi s'ajoute une question de fond, propre à notre époque : ce qui est produit vite est produit en quantité. Un outil sur mesure qui grossit de vingt fonctionnalités par mois finit par peser plus lourd que le besoin. La discipline n'est donc pas dans la génération, elle est dans le refus : non, on n'ajoute pas cet écran.

La règle que nous appliquons sur ce type de socle

Trois principes, non négociables

1. Aucune bascule de version sans sauvegarde vérifiée et retour arrière possible.
2. Aucune reconstruction depuis des sources dont on n'a pas prouvé qu'elles compilent, le binaire en production est la référence, pas le dépôt.
3. Aucun accès par défaut : documentation d'API fermée en production, comptes nominatifs, journalisation.

Un SIG fibre à moindre coût, c'est possible, à condition d'accepter que l'économie vienne du périmètre et de l'outillage, jamais du contrôle. Le jour où l'on économise sur la vérification, on ne fait pas des économies : on emprunte.

Get in touch

Un projet comparable ? Nous répondons aux questions techniques en rendez-vous, avec les mêmes chiffres que dans ces articles.

The matching service: l'hébergement, la sauvegarde et le data center local.

Call now Contact us