APHP

Plutôt que d’ajouter une plateforme AIOps de plus à la facture logicielle, nous avons construit un outil qui fait exactement ce dont l’équipe a besoin : trier les alertes, éliminer les doublons et créer les bons tickets, sans saisie manuelle. Pas de licence par utilisateur, pas de données qui sortent du réseau, et une logique métier qui appartient au client.

Situation : des milliers d’alertes par jour, traitées à la main

L’outil de supervision du client (Centreon) surveille plusieurs milliers de serveurs, réseaux, bases de données et applications métier. Il remonte des milliers d’alertes chaque jour.

Derrière l’écran, une équipe de pilotes fait le tri. Pour chaque alerte confirmée, un pilote ouvre la consigne correspondante, crée un ticket dans l’outil d’ITSM (SMAX), puis revient acquitter l’alerte avec le lien du ticket.

• Un travail répétitif et prévisible, qui mobilise une attention permanente sur un tableau de bord.
• Beaucoup de bruit : une large part des alertes sont parasites, redondantes, ou la conséquence d’une panne déjà signalée.
• Des doublons : quand un serveur tombe, tous les services qu’il héberge passent en alerte, et chacun peut générer son propre ticket.
• Deux outils qui ne se parlent pas : la supervision d’un côté, le ticketing de l’autre, et l’humain au milieu pour faire le lien.

Le réflexe habituel : acheter une plateforme de plus

Face à ce type de problème, la réponse classique est d’ajouter une couche logicielle : une plateforme d’AIOps ou un module de gestion d’événements vendu en SaaS. Sur le papier, tout y est. En pratique, le client aurait payé pour beaucoup de choses dont il n’a pas besoin.

• Un abonnement récurrent qui s’ajoute à deux outils déjà sous licence, et qui grossit avec le volume d’alertes ou le nombre d’utilisateurs.
• Des données sensibles qui sortent : l’inventaire des serveurs et l’historique des incidents d’un hôpital partent chez un éditeur tiers.
• Des règles génériques : les consignes que suivent les pilotes, construites au fil des années, doivent être retraduites dans la logique de l’éditeur.
• Un projet d’intégration quand même : il faut de toute façon connecter la supervision et le ticketing.

Notre position : quand on paie déjà l’intégration, autant investir dans un outil qui vous appartient plutôt que de louer celui d’un autre.

Solution Fabric : un orchestrateur sur-mesure, hébergé chez le client

Nous avons construit l’automatisation sur n8n, un moteur de workflows open source, déployé dans un conteneur sur le cluster Kubernetes interne de la DSN. Trois choix ont guidé le projet.

• Aucun nouvel abonnement. L’outil s’appuie sur les licences Centreon et SMAX déjà payées. On ne remplace rien qui fonctionne : on relie ce qui ne se parlait pas.
• Des données qui restent à la maison. Tout tourne sur l’infrastructure du client. Aucune alerte, aucun nom de serveur ne quitte le réseau.
• La logique métier des pilotes, pas celle d’un éditeur. Chaque consigne de supervision (titre du ticket, groupe d’affectation de jour ou de nuit, service et application impactés, criticité, commentaire d’acquittement) a été modélisée dans une base PostgreSQL et rattachée à chaque hôte ou service supervisé.

Résultat : les règles sont lisibles, modifiables par l’équipe, et exportables à tout moment.

Comment ça marche

L’automatisation reproduit, en quelques secondes, ce que faisait un pilote en plusieurs minutes.

1. Récupérer les alertes confirmées (état HARD, après trois vérifications) et non encore acquittées.
2. Filtrer le bruit : les statuts indéterminés sont écartés, chaque alerte est rapprochée de sa consigne.
3. Corréler : si un serveur est en panne, ses services en alerte sont rattachés à un seul ticket au lieu d’en générer un chacun.
4. Créer le ticket dans SMAX via son API, avec les champs dictés par la consigne.
5. Acquitter l’alerte dans Centreon avec la référence du ticket, pour qu’elle ne soit jamais traitée deux fois.

Du prototype à la production. Pour valider la logique en environnement de qualification (environ 1 300 hôtes et services), nous avons commencé par interroger Centreon toutes les cinq minutes. Simple et rapide à mettre en place, mais pas tenable sur les plus de 10 000 éléments supervisés en production. La cible retenue est donc un stream connector : Centreon pousse lui-même chaque alerte pertinente vers n8n, en temps réel, sous forme d’un petit message JSON. Pas de requêtes inutiles, une charge qui ne grossit pas avec le parc.

L’IA là où elle sert, pas partout

Le plan initial prévoyait un modèle d’IA pour remplir les tickets. Après analyse des consignes, nous l’avons écarté de ce périmètre : des règles bien définies suffisaient, avec un résultat plus fiable, plus facile à auditer et beaucoup moins gourmand en ressources.

C’est la même logique que pour les licences : on ne paie que ce qui apporte de la valeur. L’outil reste prêt à accueillir de l’IA pour les cas où elle fera vraiment la différence, comme expliquer une décision de tri ou enrichir un ticket avec l’historique de l’incident.

Résultat

Le projet a été mené en preuve de concept, avec des critères de réussite fixés dès le départ avec l’équipe.

• 0 € de licence supplémentaire : l’outil exploite les logiciels déjà en place.
• Quelques secondes par ticket au lieu de plusieurs minutes à la main.
• Des données hébergées en interne, sur l’infrastructure du client.
• Chaque décision traçable : on sait pourquoi une alerte a donné lieu, ou non, à un ticket.
• Des pilotes libérés d’une tâche répétitive, recentrés sur l’analyse des vrais incidents.

Et ensuite : un socle qui grandit avec le client

Parce que l’outil appartient au client, chaque évolution s’ajoute au même socle au lieu de déclencher un nouvel abonnement.

• Historique et reporting : chaque alerte traitée est enregistrée en base, avec un récapitulatif hebdomadaire envoyé aux pilotes, puis des tableaux de bord pour les pilotes et la direction.
• Amélioration continue : l’historique sert à affiner les règles de tri semaine après semaine.
• Nouvelles sources : la même mécanique peut accueillir d’autres outils de monitoring, sans repartir de zéro.
• Actions correctives : à terme, redémarrer un service ou notifier une équipe dans Teams directement depuis le workflow.

Vos outils ne se parlent pas ? Avant d’en louer un troisième, parlons-en.

Ticketing, supervision, CRM, gestion des opérations : si vos équipes recopient à la main des informations d’un logiciel à l’autre, ou si vous envisagez un nouvel abonnement pour combler le trou, un outil sur-mesure est souvent plus rentable. Vos données restent chez vous, et vous investissez dans votre logiciel au lieu de le louer.