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 :
| Famille | Ce qu'elle modélise |
|---|---|
| features, shapes, layers | Les points, les tracés et les calques : la carte elle-même, avec sa géométrie |
| cables, fibers, splices, ports | Le 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-relations | La continuité logique : ce brin relie ce boîtier à cet abonné |
| ground-plans, documents | Les plans de récolement et les pièces jointes, rattachés à l'objet qu'ils documentent |
| work-orders, projects | Le travail : interventions, chantiers, ce qui reste à faire et par qui |
| qrcodes | Le lien entre le terrain et la base : une étiquette scannée ouvre la fiche du point |
| snmp | L'état des équipements actifs, un OLT qui ne répond plus est une coupure, pas une ligne de tableau |
| import-export | L'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.
| Risque | Ce qu'il donne en vrai | Ce qu'on fait |
|---|---|---|
| Le code qu'on ne comprend plus | Un 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épendances | Une bibliothèque abandonnée, et la mise à jour du serveur casse l'application | Versions figées, montée de version testée, pas de dépendance qui ne se justifie pas |
| Les réglages par défaut | Une documentation d'API publique, un mode debug oublié, un compte de démonstration actif | Une revue de configuration avant chaque mise en ligne, c'est le premier endroit où l'on regarde, pas le dernier |
| La dépendance à une personne | Un seul être humain sait comment redémarrer la bête | Procédure écrite, sauvegardes testées, dépôt de code versionné, accès documenté |
| L'abandon | Le vrai risque, et de loin. Un logiciel sur mesure que personne ne maintient devient une charge, pas un actif | Un 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
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.
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.