Expertise
Ce que nous construisons.
Le logiciel d’exploitation d’un opérateur tient rarement dans un seul outil. Il tient dans ce qui les relie : un modèle de données, des intégrations, des circuits tracés, des interfaces que les équipes utilisent, et l’automatisation de ce qui se répète. C’est notre métier. Chacun de ces cas d’usage peut faire l’objet d’un pilote.
- 01
Un modèle de données qui fait foi
- Le problème
- Le même équipement existe dans plusieurs outils, avec des identifiants et des états différents. Personne ne sait lequel croire.
- Le livrable
- Un modèle de données partagé, l’outil qui fait foi pour chaque attribut, des identifiants stables et l’historique des changements.
- Nos règles
- Un attribut, une source. Pas de synchronisation dans les deux sens. Un écart est visible et daté, jamais écrasé en silence.
- 02
Des outils qui se parlent sans double saisie
- Le problème
- Les équipes recopient d’un outil à l’autre. Les scripts d’appoint cassent à chaque mise à jour, et personne ne sait qui les maintient.
- Le livrable
- Des connecteurs entre vos outils existants, versionnés, testés et documentés, avec un journal de chaque échange et une reprise sur erreur.
- Nos règles
- On garde vos outils. Chaque échange peut être rejoué sans créer de doublon. Une intégration sans propriétaire ni surveillance n’est pas livrée.
- 03
Des circuits d’exploitation tracés de bout en bout
- Le problème
- Un incident ou un changement traverse plusieurs outils et plusieurs équipes. La chronologie se reconstitue à la main, après coup.
- Le livrable
- Les circuits d’incident, de changement et de demande inscrits dans vos outils : qui est prévenu, quand, avec quelles données, et une trace horodatée à chaque étape.
- Nos règles
- Les heures viennent des outils, pas des personnes. Chaque étape a un responsable. Le rapport se produit à partir des traces.
- 04
Des interfaces que les équipes utilisent
- Le problème
- Les outils du marché sont conçus pour tous les métiers à la fois. Les équipes les contournent, les clients appellent pour savoir où en est leur demande.
- Le livrable
- Des écrans conçus avec les utilisateurs pour les tâches qui comptent, et un portail client qui montre l’état réel des demandes et des interventions.
- Nos règles
- On observe le travail avant de dessiner. Une interface se juge au temps qu’elle fait gagner, pas au nombre de ses fonctions.
- 05
Automatiser, puis confier le reste à des agents
- Le problème
- Une part du travail récurrent reste manuelle parce qu’elle demande de lire du texte libre ou de recouper plusieurs sources.
- Le livrable
- Des règles pour tout ce qui est déterministe, et un agent seulement sur les cas ambigus, qui propose une modification avec ce qui la justifie.
- Nos règles
- Un script d’abord. Un agent coûte plus cher qu’un script et se trompe autrement.
Ce que nous ne faisons pas
Les limites sont écrites avant le premier accès.
- Modifier vos outils sans votre accord.
- Accéder à un outil ou à une installation hors du périmètre convenu.
- Livrer un logiciel que votre équipe ne pourrait ni comprendre ni reprendre.