L’agent IA SRE de Cloud Inspire prend en charge la partie répétitive du traitement des incidents : recevoir l’alerte, ouvrir le ticket, le classer, l’envoyer à la bonne équipe, préparer la procédure et rédiger le compte rendu. L’ingénieur garde la décision. L’action sur vos serveurs passe par vos propres pipelines.
Cet article suit un incident du début à la fin. Il explique ensuite où la plateforme se place dans votre organisation IT, comment elle se met en place, quels outils s’y connectent, et comment la veille et la traçabilité s’y ajoutent.
Où se place la plateforme dans votre chaîne IT
La plateforme ne remplace pas vos outils. Elle se place après votre supervision et à côté de votre outil de ticketing. Elle reçoit les alertes, organise le traitement, et confie l’action à vos pipelines.
| Étape | Outil | Qui agit |
|---|---|---|
| Détection | Votre supervision (Prometheus, Alertmanager ou tout outil capable d’envoyer une alerte HTTP signée) | La supervision |
| Ticket | Outil de ticketing Chatwoot | La plateforme ouvre et met à jour le ticket |
| Classement, routage, délais | Plateforme Cloud Inspire | L’agent IA SRE |
| Décision | Console de la plateforme | L’ingénieur |
| Action sur les serveurs | Votre pipeline GitLab CI (Ansible, Terraform…) ou un webhook signé | Votre pipeline |
| Compte rendu et documentation | Base de connaissances de la plateforme | L’agent rédige, une personne valide |
Ce principe a une conséquence importante : la plateforme n’agit jamais directement sur un serveur. Elle n’a pas d’accès SSH à vos machines. Elle lance un pipeline que vous avez déclaré, et c’est ce pipeline qui agit, avec les droits que vous lui avez donnés.
Le cas d’usage : un disque presque plein sur un serveur de base de données
Le scénario suivant est un exemple. Il montre ce que fait chaque acteur, étape par étape.
1. L’alerte arrive
À 2 h 40, la supervision détecte qu’un disque d’un serveur de base de données est rempli à 92 %. Elle envoie une alerte à la plateforme par une requête HTTP signée. Une alerte non signée est refusée.
Dans les minutes qui suivent, la supervision renvoie la même alerte plusieurs fois. La plateforme les regroupe par empreinte : un seul incident, un seul ticket. Par défaut, la fenêtre de regroupement est d’une heure, réglable par source.
2. Le ticket est ouvert et classé
La plateforme ouvre un ticket dans Chatwoot. La gravité annoncée par la supervision devient la priorité du ticket, selon une correspondance réglée pour chaque source.
L’agent de classification lit ensuite l’alerte. Il propose une catégorie (par exemple « stockage »), une priorité parmi quatre niveaux (urgente, haute, moyenne, basse) et des étiquettes. Deux règles encadrent ce classement :
- l’agent ne pose que des étiquettes qui existent déjà dans votre compte ;
- il ne change la priorité que s’il est suffisamment sûr de lui. Sinon, le ticket garde la priorité donnée par la supervision.
3. Le ticket va à la bonne équipe, avec un délai
L’agent de routage lit le ticket et la description de vos équipes. Il affecte le ticket à l’équipe « Systèmes ». S’il ne trouve pas d’équipe adaptée, le ticket va à l’équipe par défaut.
Une politique de délai (SLA) est rattachée au ticket. Toutes les 5 minutes, la plateforme compare le ticket à ses échéances. Si le délai approche, les paliers d’escalade s’appliquent : note, courriel, notification vers votre messagerie d’équipe par webhook, hausse de priorité ou passage à l’équipe d’astreinte.
4. La procédure démarre
L’étiquette « stockage » déclenche le runbook « Disque plein ». Ses étapes sont écrites par vos équipes. Dans notre exemple :
- une note privée rappelle les vérifications à faire ;
- une lecture d’une source déclarée (par exemple votre inventaire) indique le service et le responsable de la machine ;
- une étape pipeline prépare le lancement du job « Purge des journaux applicatifs » dans votre GitLab CI.
5. L’ingénieur valide et lance
Pour une action sensible, l’étape pipeline est réglée en lancement manuel. L’ingénieur d’astreinte ouvre le ticket. Il voit la note, le contexte, la machine ciblée et chaque paramètre qui sera envoyé au pipeline. Il clique sur « Lancer le pipeline ».
Le pipeline GitLab exécute la purge avec Ansible. Le résultat et les journaux du job reviennent dans l’étape du runbook, visibles depuis le ticket.
6. L’incident se ferme
Le disque redescend sous le seuil. La supervision envoie « résolu ». La plateforme ferme l’incident et, par défaut, le ticket.
7. Le compte rendu est rédigé
La dernière étape du runbook rédige un post-mortem. Il est posé en note privée sur le ticket, enregistré en brouillon dans la base de connaissances et envoyé par courriel à l’équipe responsable. Rien n’est publié sans relecture humaine.
8. Les incidents qui reviennent deviennent des procédures
Toutes les heures, la plateforme regroupe les incidents résolus qui se ressemblent en « motifs récurrents ». Si ce disque se remplit chaque semaine, le motif apparaît. Un manager peut en tirer un brouillon de runbook, ou décider de traiter la cause : rotation des journaux, taille du disque.
Ce que l’agent fait, et ce qu’il ne fait pas
| L’agent IA SRE fait | L’agent IA SRE ne fait pas |
|---|---|
| Regroupe les alertes répétées | Se connecter à vos serveurs |
| Classe le ticket et propose une priorité | Lancer une action sensible sans validation, si l’étape est en lancement manuel |
| Oriente le ticket vers une équipe | Publier une procédure ou un article sans relecture |
| Surveille les délais et escalade | Lire l’état de vos machines en dehors des sources que vous déclarez |
| Prépare et déroule le runbook | Remplacer votre supervision ou votre outil de ticketing |
| Rédige le post-mortem et les brouillons de procédures |
La mise en place
La plateforme s’installe sur des machines que vous fournissez, sur votre site ou dans un environnement privé opéré par Cloud Inspire.
Les prérequis.
- Des machines Ubuntu 24.04 LTS de 8 vCPU, 16 Go de mémoire et 100 Go de disque.
- Deux noms DNS internes (console et API), plus un par composant hébergé chez vous.
- Des certificats émis par votre autorité interne.
- Des flux sortants en HTTPS. Aucun accès entrant n’est demandé : ni SSH, ni VPN, ni port ouvert depuis Internet.
L’installation. Vous vérifiez l’empreinte du script d’amorçage, puis vous le lancez une fois sur chaque machine. Ensuite, l’installation, les mises à jour et les sauvegardes passent par un agent de déploiement qui se connecte en sortie.
Le paramétrage. Il se fait par étapes, dans cet ordre :
- Les sources d’alertes. Une source par outil de supervision, avec sa clé de signature et sa correspondance gravité → priorité. Un bouton « Essayer un envoi » montre ce qui se passerait, sans rien écrire.
- Les équipes et l’astreinte. Chaque équipe a une description : c’est elle que lit l’agent de routage.
- Les politiques SLA et leurs paliers d’escalade.
- Les cibles d’automatisation : les pipelines GitLab et les webhooks signés que les runbooks ont le droit de lancer.
- Les runbooks, en commençant par les incidents les plus fréquents.
- La base de connaissances : vos procédures et votre documentation interne.
- Le bot, s’il y en a un, démarre en mode Observation : il écrit seulement des notes privées. Vous lisez ce qu’il aurait fait avant de lui donner plus de rôle.
Les outils connectés
| Fonction | Outils |
|---|---|
| Supervision | Prometheus et Alertmanager, ou tout outil capable d’envoyer une alerte HTTP signée |
| Sécurité | Wazuh (script d’intégration prêt) |
| Ticketing | Chatwoot |
| Action | Pipelines GitLab CI (Ansible, Terraform…) et webhooks signés |
| Notification | Courriel, webhooks vers votre messagerie d’équipe |
| Inventaire et documentation | Sources déclarées en lecture seule, base de connaissances |
| Modèle d’IA | Le modèle de votre choix : fournisseur appelé en direct, relais Cloud Inspire, ou modèle open source hébergé chez vous (Ollama) |
Sans modèle d’IA, la plateforme fonctionne encore : le regroupement des alertes, les délais, les escalades et les runbooks restent actifs. Seules les fonctions d’assistance (classement, routage, notes, rédaction) s’arrêtent.
La veille : les avis de sécurité appliqués à votre inventaire
Une partie des incidents ne vient pas de la supervision. Elle vient d’un avis de sécurité : une faille critique publiée par un éditeur ou par un CERT.
Cette veille est assurée par l’équipe Cloud Inspire. Nous suivons les avis du CERT-EU et des éditeurs des logiciels que vous utilisez. Pour chaque avis, nous vérifions dans votre inventaire quels services utilisent la version concernée. Chaque service touché devient un ticket, traité avec le même circuit : priorité, équipe, délai, correction par pipeline, compte rendu.
L’article Failles critiques PHP (CERT-EU 2026-018) décrit ce circuit sur un cas réel : détecter, qualifier, corriger, isoler si besoin, informer.
La traçabilité : des preuves pour vos audits
La plateforme ne garantit pas, à elle seule, le respect d’une réglementation. Elle conserve en revanche les éléments qu’un audit demande sur la gestion des incidents :
- l’historique complet de chaque ticket : alerte reçue, classement, équipe, échéances, escalades ;
- pour chaque runbook : qui a lancé quelle étape, avec quels paramètres, et le résultat du pipeline ;
- les demandes de changement, avec leurs approbateurs ;
- les post-mortems relus et validés.
Ces éléments aident à préparer les contrôles liés à NIS2 ou à DORA, qui demandent de documenter la détection, le traitement et le suivi des incidents. Pour le détail de ces obligations, voir notre guide NIS2 pour DSI et RSSI.
Pour aller plus loin
- La page Agent IA SRE présente l’offre complète.
- Le cas de la sécurité est traité dans l’article L’agent cybersécurité.
- Vous voulez voir le parcours sur vos propres alertes ? Réservez 30 minutes avec un ingénieur.