Setics

Setics est une PME toulousaine qui édite des logiciels de dimensionnement de réseaux fibre. Arrivée en octobre 2023, après six mois de stage de fin d’études en Allemagne. Depuis, développement du portefeuille au quotidien et responsabilité technique de fait : revue de code quotidienne, y compris celle des prestataires, décisions d’architecture, coordination d’un prestataire externe sur l’intégration d’un plugin cartographique, démonstrations client en anglais.

Sttar

Le produit principal s’appelle Sttar : une application C#, .NET et WPF de conception automatique de réseaux FTTH, plus de cinq cent mille lignes à l’échelle de la solution, code d’interface généré compris, déployée par des opérateurs télécoms en Europe, aux États-Unis et en Asie. C’est là que passe la majeure partie du temps.

Algorithme principal rendu modulaire. Il tournait comme un bloc unique ; il est désormais découpé en étapes activables séparément : cheminement, câblage, placement des nœuds, zones de service, conception de l’infrastructure, connectivité fibre. L’utilisateur choisit ce qu’il relance au lieu de tout rejouer.

Performance, pour l’essentiel hors feuille de route. La sélection sur la carte est passée de plusieurs minutes à quelques secondes sur les jeux de données mesurés, relevés conservés ; le pipeline d’optimisation qui la porte repose sur un raisonnement à partir de cas et une triangulation de Delaunay. Le chargement des zones de service est passé de DotSpatial à GDAL. Le moteur de cheminement a été réécrit d’environ deux mille lignes à mille trois cents, et les cas particuliers codés à la main dans la fusion des fourreaux ont été remplacés par un modèle de coût.

Interface refaite pour la version 2.5, avec l’objectif de rendre le produit utilisable sans documentation ouverte à côté : icônes redessinées, langage visuel harmonisé en une passe. La documentation utilisateur a quitté Manula, la documentation interne du code se met à jour automatiquement, et un outil compare deux versions pour en tirer les notes de version.

Chaîne de construction et de test. Maintenance des pipelines Azure derrière Sttar et résorption d’une longue traîne d’échecs de compilation et de tests. Les produits SaaS démarrés depuis suivent le même régime : tests à chaque modification, intégration continue, déploiement semi-automatique.

Plugin cartographique, suivi de bout en bout : implémentation ArcGIS Pro ramenée en interne, fusion de deux autres plugins internes, portage vers QGIS en cours ; détails plus bas, sous Outils SIG.

À cela s’ajoutent les corrections de bugs, facilement la moitié de ce qui est livré.

Produits SaaS

Trois produits vendus, dont l’entreprise décide la feuille de route et dont les choix techniques relèvent du poste : une frontière nette avec les outils internes ci-dessous.

FiberState (TypeScript, React, .NET, Azure) suit le déploiement de la fibre sur le terrain. Travail en cours sur la couche au-dessus : un inventaire physique du réseau, natif, avec la conduite de chantier pilotée depuis la carte. Trois problèmes y sont intéressants : l’ordonnancement par dépendances, où une tâche qui glisse propage son retard dans tout le plan ; une application terrain conçue hors ligne d’abord, parce qu’un chantier n’a pas de réseau au moment précis où il en faudrait un ; et la réconciliation des données de récolement dans l’inventaire de référence, c’est-à-dire l’écart entre ce qui était prévu et ce qui a réellement été posé.

STEM (NestJS, Next.js, Cosmos DB) est une plateforme multi-locataire, dont l’API et le frontend sont déployés en services séparés sur Azure App Service. Travail le plus récent réalisé dessus, avec les contributions occasionnelles d’un collègue.

Supervision réseau, sur la même pile, vendue en service : elle observe les réseaux que les deux précédents ont planifiés puis bâtis. Développement porté après une première version livrée avec un prestataire.

Les trois s’enchaînent, et c’est ce qui rend le travail intéressant : planifier le réseau, suivre sa construction, puis le surveiller une fois qu’il fonctionne. Les mêmes objets métier traversent les trois produits, et l’essentiel du travail consiste à ce qu’ils y survivent sans être redéfinis à chaque frontière.

Applications métier

Reprendre un flux interne éparpillé entre un tableur, une file de tickets et une boucle de courriels, puis le remplacer par une application. Aucun de ces trois outils n’était au planning : proposés, pile technique choisie, écrits à côté du reste de Sttar.

Chaîne de licences (.NET, Blazor Server, EF Core, Azure SQL), reconstruite de zéro pour automatiser le parcours : demande déposée par le client sur le portail, devis pré-rempli à partir de templates et d’offres, validation commerciale (qu’un humain approuve toujours), puis génération et livraison automatiques de la licence. Elle remplace une base tenue dans un tableur, une file de tickets et des échanges par courriel par une seule source de vérité. L’exploitation des licences de Sttar fait partie du périmètre.

Portail unifié : accès aux logiciels, documentation et gestion des licences côté client, ainsi que le back-office interne, au même endroit. En Blazor Server, avec une authentification unique ; cette chaîne d’authentification est le chantier en cours.

Assistants internes : un prototype pour Microsoft Teams, en TypeScript, multi-agents sur Claude, avec de la recherche documentaire augmentée et l’API Graph. L’idée : un collègue demande comment le produit fait telle chose, et la réponse sort de la documentation interne plutôt que d’un modèle qui invente. La suite prévue est le même assistant pour les clients, à l’intérieur du produit, puis capable d’y agir pour eux.

Outils SIG

Deux logiciels de cartographie, deux langages d’extension imposés, et le même métier à faire tourner dans les deux, le plugin mentionné plus haut sous Sttar. La solution paresseuse consiste à écrire deux fois la logique et à la voir diverger au premier correctif.

Ici la frontière d’échange est du WKB, et le cœur de calcul ne dépend que de shapely et de networkx, ni geopandas, ni qgis, ni arcpy. Il ne sait pas dans quel hôte il tourne, ce qui est le but : un correctif de logique métier atterrit partout au lieu d’être écrit deux fois.

Le plugin QGIS couvre QGIS 3 et QGIS 4 depuis une seule livraison ; c’est là, et seulement là, qu’un livrable unique sert deux versions. L’add-in ArcGIS unifié est spécifié, pas construit.

L’implémentation ArcGIS Pro a d’abord été ramenée en interne, puis deux autres plugins internes y ont été fusionnés, et c’est ce résultat qui est porté vers QGIS. Le métier vient avec : bilans de liaison, rapports de chemin optique, gestion des épissures, sérialisation des lignes de fibre, correspondance d’attributs, systèmes de référence spatiale.

Cette page ne dit pas ce que ces produits et outils font pour qui : les clients ne sont pas un argument de portfolio.

C’est dans ce poste que se sont apprises l’architecture, la revue de code et la relation client.