• 

ServiceGraph IA

ServiceGraph IA transforme des signalements dispersés et des anomalies techniques en un incident explicable, une décision humaine contrôlée et un rétablissement vérifiable.

Inspiration

Lorsqu’un réseau ou un service public se dégrade, les citoyens et les équipes techniques ne voient pas la même chose.

Les citoyens décrivent des symptômes : connexion lente, interruption de service, faible pression d’eau, panne électrique ou transport perturbé. De leur côté, les opérateurs observent des métriques, des alertes et des dépendances d’infrastructure.

Ces informations sont souvent traitées séparément, alors qu’elles peuvent provenir d’une seule défaillance.

Notre projet est né d’une question :

Comment transformer des dizaines de symptômes dispersés en une cause racine compréhensible, une action gouvernée et une récupération réellement vérifiée ?

ServiceGraph IA réunit la voix du citoyen, la télémétrie, la topologie technique et la mémoire opérationnelle dans une même chaîne de gestion d’incident.

Ce que fait ServiceGraph IA

ServiceGraph IA couvre le parcours complet :

Signalements citoyens + télémétrie → corrélation → incident → preuves → cause probable → remédiation proposée → approbation humaine → exécution contrôlée → vérification → communication.

Le système aide à répondre à cinq questions essentielles :

1. Ces signalements sont-ils liés ?
2. Quelles preuves techniques soutiennent cette corrélation ?
3. Quelle est la cause racine la plus probable ?
4. Quels citoyens, services et secteurs sont touchés ?
5. Quelle action est recommandée, qui peut l’autoriser et le service s’est-il réellement rétabli ?

Notre objectif n’est pas simplement de détecter une anomalie. Nous voulons fermer la boucle jusqu’à la récupération vérifiée.

Deux expériences complémentaires

Portail citoyen

Le portail citoyen est une application web progressive, bilingue et adaptée aux téléphones comme aux ordinateurs.

Il permet de :

• consulter l’état des services ;
• visualiser les problèmes signalés dans son secteur ;
• déclarer différents types de problèmes municipaux ou techniques ;
• transmettre un signalement écrit ou vocal ;
• utiliser sa position avec son autorisation ;
• suivre l’évolution de ses demandes ;
• consulter les incidents qui touchent son secteur ;
• être informé du rétablissement du service.

L’objectif est de donner au citoyen un moyen simple d’agir, sans lui exposer la complexité technique du système.

Centre d’opérations

Le centre d’opérations permet aux équipes autorisées de :

• surveiller les services et les incidents ;
• consulter les signalements et la télémétrie ;
• visualiser les relations entre citoyens, services, anomalies et infrastructures ;
• explorer le graphe causal d’un incident ;
• consulter les preuves utilisées par l’intelligence artificielle ;
• examiner une cause racine probable et son niveau de confiance ;
• mesurer le rayon d’impact ;
• consulter une proposition de remédiation ;
• approuver ou refuser une action sensible ;
• exécuter une action contrôlée dans le simulateur ;
• vérifier les métriques après l’intervention ;
• conserver une trace des décisions importantes.

Notre différence

Beaucoup de solutions s’arrêtent à la collecte des signalements, à une carte ou à une recommandation produite par l’intelligence artificielle.

ServiceGraph IA relie ces éléments dans une seule boucle opérationnelle :

la voix du citoyen devient une preuve, les preuves deviennent une hypothèse explicable, l’hypothèse devient une proposition gouvernée, et la proposition n’est considérée réussie qu’après vérification dans les données.

Notre innovation ne consiste donc pas seulement à utiliser l’intelligence artificielle. Elle consiste à relier données humaines, données techniques, sécurité et responsabilité opérationnelle.

Intelligence artificielle explicable avec Gemini

Gemini agit comme moteur d’analyse assistée.

Le modèle ne reçoit pas un accès libre à la base de données. Le backend lui transmet un paquet de preuves structuré et limité pouvant contenir :

• des signalements ;
• des anomalies de télémétrie ;
• des services affectés ;
• des relations de topologie ;
• des nœuds candidats ;
• du contexte historique pertinent.

Gemini doit produire une réponse structurée contenant notamment :

• une cause probable ;
• un niveau de confiance ;
• une justification ;
• les preuves utilisées ;
• les hypothèses alternatives ;
• les suppositions éventuelles.

Les identifiants de preuve sont validés par le backend. Une réponse invalide est rejetée et affichée comme une intégration dégradée.

Gemini ne peut ni approuver ni exécuter une remédiation.

Corrélation déterministe avant l’IA

ServiceGraph IA ne repose pas uniquement sur un modèle génératif.

Avant l’analyse Gemini, le système examine des signaux explicables :

• proximité temporelle ;
• service concerné ;
• zone géographique ;
• similarité des symptômes ;
• dépendances de topologie ;
• anomalies de télémétrie.

Gemini intervient ensuite pour classer et expliquer les hypothèses à partir de ces faits.

Cette combinaison permet de bénéficier de l’intelligence artificielle sans lui confier seule la vérité opérationnelle.

Contrôle humain et sécurité avec Auth0

ServiceGraph IA sépare strictement la recommandation, l’autorisation et l’exécution.

Par exemple :

• un citoyen peut consulter et suivre ses propres demandes ;
• un opérateur peut analyser un incident ;
• un gestionnaire d’incident peut approuver certaines remédiations ;
• un administrateur peut gérer les accès ;
• une tentative non autorisée doit être refusée côté serveur.

Auth0 fournit l’authentification, les jetons, les rôles et les permissions.

Chaque décision sensible est associée à :

• une identité authentifiée ;
• une permission vérifiée ;
• une version précise de la proposition ;
• une approbation ou un refus ;
• un résultat d’exécution ;
• une vérification ;
• une trace d’audit.

Nous ne demandons pas aux organisations de faire confiance aveuglément à l’IA. Nous leur proposons une IA dont les conclusions sont liées à des preuves et dont les actions restent sous contrôle humain.

Télémétrie et scénario de démonstration

Pour le hackathon, nous utilisons un réseau simulé reproductible.

Le scénario principal provoque une dégradation de NODE-17 :

• augmentation de la latence ;
• augmentation de la perte de paquets ;
• anomalies sur les services dépendants ;
• arrivée de plusieurs signalements décrivant des symptômes différents.

Le système doit alors corréler les événements, ouvrir ou mettre à jour un incident, construire un graphe de preuves et analyser la cause probable.

Le contrôle réseau est simulé et présenté comme tel. En revanche, les contrats de données et les frontières d’intégration sont conçus pour pouvoir recevoir ultérieurement des données issues de technologies comme SNMP, les journaux système, la télémétrie continue, des sondes réseau ou des API de constructeurs.

Données temporelles avec TigerData

TigerData/PostgreSQL constitue la source de vérité persistante du projet.

La base conserve notamment :

• les services et les nœuds d’infrastructure ;
• les signalements ;
• les événements de télémétrie ;
• les incidents et leurs preuves ;
• les hypothèses de cause racine ;
• les propositions et décisions de remédiation ;
• les vérifications ;
• les communications ;
• les événements d’audit.

Les séries temporelles permettent de comparer les indicateurs :

avant la remédiation → pendant l’intervention → après la récupération.

Le système ne doit pas déclarer un incident résolu uniquement parce qu’une action a été exécutée. Il doit vérifier que les métriques se sont réellement améliorées.

Signalement vocal avec ElevenLabs

ElevenLabs est intégré au parcours de signalement vocal.

Un citoyen peut enregistrer une courte description du problème. L’audio est transmis au service de transcription, puis le texte obtenu entre dans le même processus que les signalements écrits.

Si la transcription échoue, l’interface doit le signaler clairement et permettre de continuer avec un signalement écrit. Aucun faux texte n’est généré pour masquer une panne du fournisseur.

Mémoire opérationnelle avec Backboard

Backboard fournit une mémoire opérationnelle permettant de rechercher :

• des incidents antérieurs ;
• des procédures d’intervention ;
• des configurations similaires ;
• des enseignements déjà documentés.

Cette mémoire reste consultative. Les preuves actuelles et la télémétrie récente ont toujours priorité sur l’historique.

Infrastructure

ServiceGraph IA est construit avec une architecture conteneurisée comprenant :

• une application Next.js ;
• une API Fastify ;
• une base TigerData/PostgreSQL externe ;
• un service de préparation des migrations ;
• des adaptateurs Gemini, ElevenLabs, Backboard et Auth0 ;
• un simulateur réseau ;
• un reverse proxy HTTPS.

Notre première version est validée sur un VPS de staging. L’architecture Docker reste portable vers Vultr sans créer une seconde version du produit : le même code et les mêmes images peuvent être redéployés avec des variables d’environnement et une configuration réseau propres à l’environnement cible.

Difficultés rencontrées

La principale difficulté n’a pas été de créer plusieurs écrans, mais de faire communiquer des composants très différents sans transformer le projet en démonstration visuelle déconnectée.

Nous avons notamment travaillé sur :

• la cohérence des contrats entre frontend, API et base de données ;
• la corrélation entre données humaines et données techniques ;
• la validation stricte des réponses de l’intelligence artificielle ;
• la distinction entre données réelles, données simulées et états dégradés ;
• la gestion sécurisée des rôles et permissions ;
• la prévention des actions autonomes sensibles ;
• les flux de données en temps réel ;
• la reproductibilité du scénario de démonstration ;
• les comportements de repli lorsque les services externes sont indisponibles ;
• la représentation visuelle d’une cause complexe de manière compréhensible.

Ce que nous avons appris

Ce projet nous a permis d’explorer :

• l’intelligence artificielle explicable ;
• les séries temporelles ;
• les graphes de causalité ;
• la sécurité fondée sur les rôles ;
• les architectures distribuées ;
• les applications web progressives ;
• les communications en temps réel ;
• la conception bilingue et accessible ;
• la gouvernance des systèmes assistés par intelligence artificielle.

Nous avons surtout appris qu’une recommandation intelligente n’a de valeur opérationnelle que si elle est reliée à des preuves, soumise à une responsabilité humaine et suivie d’une vérification mesurable.

Impact potentiel

ServiceGraph IA peut aider un opérateur ou une institution à :

• réduire le traitement répétitif des signalements dupliqués ;
• diminuer le temps de triage ;
• accélérer l’identification d’une cause commune ;
• mieux prioriser les interventions ;
• améliorer la communication avec les citoyens ;
• capitaliser sur les incidents précédents ;
• conserver une trace claire des décisions sensibles.

La même architecture peut être adaptée aux télécommunications, à l’eau, à l’électricité, au transport et à d’autres infrastructures critiques.

Notre objectif

Nous voulons résumer une situation complexe dans une chaîne compréhensible :

37 signalements → 1 incident → NODE-17 → cause expliquée → action approuvée → récupération vérifiée → citoyens informés.

ServiceGraph IA vise à rendre les services publics et les réseaux plus compréhensibles, plus réactifs, plus responsables et plus sûrs.

Built With

• auth0
• backboard
• caddy
• docker
• elevenlabs
• fastify
• gemini
• next.js
• node.js
• postgresql
• pwa
• react
• sse
• tigerdata
• typescript
• vultr
• zod