Il y a quelques semaines, j’observais un ingénieur NOC de niveau 2, au centre d’opérations réseau d’un énergéticien européen, trier une alarme WAN critique. La chorégraphie était toujours la même :

  • Ouvrir le système de supervision réseau, trouver l’équipement, copier les détails de l’alarme.
  • Basculer sur la CMDB, retrouver le CI, le groupe de support, la localisation.
  • Ouvrir ServiceNow, chercher le hostname de l’équipement, parcourir une douzaine d’incidents passés pour trouver quelque chose de similaire.
  • Ouvrir le calendrier des changements, vérifier si un changement planifié pourrait l’expliquer.
  • Ouvrir l’outil de topologie, vérifier l’impact sur le reste du réseau.
  • Rédiger un ticket : description courte, cause probable, actions recommandées, liens vers les incidents passés qu’on vient de lire.
  • Envoyer.

Onze minutes, à peu de chose près, pour une alarme qui se déclenche plusieurs fois par nuit. Multipliez par 500 alarmes par jour sur un NOC 24×7 et vous commencez à comprendre pourquoi les opérateurs rapportent de la fatigue, et pourquoi les mêmes diagnostics sont reconstruits de zéro à chaque vacation.

Cet article raconte comment nous avons remplacé cette chorégraphie par un agent propulsé par Claude qui mène la même investigation en moins de deux minutes, ancre chaque recommandation dans des incidents passés résolus (avec des citations littérales des notes de clôture), et gagne en pertinence à chaque alarme triée.

L’architecture en un schéma

┌──────────────────────────────────────────────────────────────────────┐
│ Trigger: alarm → API Gateway PRIVATE → Lambda → SQS FIFO              │
└─────────────────────────────┬────────────────────────────────────────┘
                              ▼
┌──────────────────────────────────────────────────────────────────────┐
│  Bedrock AgentCore Runtime  ────  Claude Opus 4.8 (EU inference)     │
│  Strands SDK agent loop                                              │
│  STM during the run · LTM across runs (AgentCore Memory)             │
└─┬──────────────────────┬──────────────────────────────┬──────────────┘
  │ MCP Gateway          │                              │
  ▼                      ▼                              ▼
Spectrum MCP        ServiceNow Redshift MCP        Sendmail MCP
(live alarms,       (2 years of incident         (renders the ticket
 topology)           history with close_notes)    as HTML email)

Trois choses comptent, et la plupart des projets d’agent NOC en ratent au moins une :

  1. L’agent ne se contente pas de répondre à des prompts. Il exécute un workflow reproductible et obligatoire. Collecter les faits en direct, s’ancrer sur les incidents historiques, évaluer l’impact topologique, synthétiser, rédiger, livrer. On grave cette boucle dans le system prompt comme des étapes non négociables.

  2. Le plan d’action est ancré sur de vraies résolutions passées. Quand l’agent recommande « essayez shut/no shut sur l’interface », il cite le numéro de l’incident passé où ça a fonctionné et reprend littéralement la phrase pertinente de sa note de clôture. Pas d’hallucination, pas de conseil générique.

  3. L’agent se souvient. Chaque triage écrit un événement structuré dans la Memory AgentCore. Chaque triage futur interroge cette mémoire. L’agent construit un corpus interne de « ce que nous, les agents, avons vu et décidé », qui complète le corpus ServiceNow rédigé par des humains.

Ce que l’opérateur voit réellement

Nous avons remplacé le ticket JSON déversé dans le terminal (retour des opérateurs : « trop verbeux, trop technique ») par un résumé Markdown compact, ordonné par ce qui compte d’abord :

### 🟥 CRITICAL — BAD LINK DETECTED on edge-rtr-12345

`edge-rtr-12345` · DC-Backbone-East · alarm open 1158 min
Confidence: **82 %** · ETA: **60 min**

#### Probable cause
Interface TenGigE0/0/0/26 went down coinciding with change CHG1234567
(Internet Access Carve-out, Step 3). Validate in <5 min: SSH and run
`show interface TenGigE0/0/0/26`, then check CHG1234567 status in the
service management portal.

#### Action plan
1. Consult CHG1234567 in the change portal NOW (grounded on `INC4561323`)
2. SSH to the device and run `show interface TenGigE0/0/0/26`
3. Try `shut/no shut` on the interface (grounded on `INC4560130`)
4. If interface refuses to come up: open Spectrum model correction
   ticket (precedent in `INC4339193`)
5. Escalate to vendor TAC under 24×7 GOLD support if hardware fault

#### What worked on similar past incidents
- `INC4561323` — Bouncing the interface (shut/no shut) cleared the
  BAD LINK in under 2h
- `INC4560130` — Spectrum model misidentification, fixed by Spectrum
  correction request
- `INC4339193` — Cable test on the port found a fault; reseating the
  cable restored the link

---
**Sources checked:** Redshift 6 INC on this device (5 read in detail) ·
8 BAD LINK INC corpus-wide (5 read) · CHG1234567 stamped in the
Spectrum alarm · Site: 79 devices, 0 alarmed elsewhere · Topology: 0
peer impact detected
**Email sent to:** on-call.noc@example.com

Le même contenu part en e-mail HTML mis en forme vers l’équipe d’astreinte. Deux minutes après le déclenchement de l’alarme.

Les deux mémoires — et pourquoi on les utilise différemment

La Memory AgentCore a deux couches :

  • La mémoire court terme (STM) est l’état conversationnel propre à une session. Le runtime l’utilise de façon transparente pendant la boucle de l’agent : chaque résultat de Tool #N, chaque réflexion, chaque appel en aval reste dans le contexte de travail. Le SDK Strands s’en occupe pour nous.

  • La mémoire long terme (LTM) est durable entre les sessions, indexée par stratégie. Nous utilisons la stratégie SEMANTIC : la sortie finale de chaque triage est écrite comme un événement, et un pipeline d’embeddings managé par Bedrock extrait des métadonnées structurées (équipement, site, signature d’alarme, cause probable, actions recommandées, confiance de l’agent) dans des memory records interrogeables.

Le choix de conception non évident, c’est la clé de namespace. Par convention, on partitionnerait par équipement (l’équipement dont on trie l’alarme est la clé primaire naturelle). Nous avons choisi de partitionner par signature d’alarme (la combinaison du titre de l’alarme et de la cause) à la place.

Pourquoi : le motif pertinent, c’est « ce qui marche pour ce type de mode de défaillance », pas « ce qui est arrivé sur cette boîte précise ». Un BAD LINK DETECTED se traite de façon similaire sur les 32 000 équipements du parc. En indexant sur la signature, l’agent récupère des triages antérieurs de n’importe quel équipement présentant la même forme de panne — exactement ce qu’un L2 humain expérimenté ferait mentalement. L’équipement et la sévérité entrent quand même dans la requête de recherche, donc les cas spécifiques à un équipement remontent plus haut quand ils existent.

L’historique ServiceNow sur Redshift (curaté par des humains pendant deux ans) reste la source de vérité primaire sur les résolutions passées. La LTM est la source secondaire : le corpus propre de l’agent, qui grandit un triage à la fois. Si les deux divergent, on indique à l’agent dans le system prompt de faire confiance à ServiceNow et de signaler la divergence — jamais l’inverse.

Ce que disent les chiffres

Après trois semaines en préprod sur de vraies alarmes Spectrum :

MétriqueRéférence manuelleAgentRatio
Temps de triage moyen~11 min~2 min×5,5
Incidents passés lus par triage1,54,7×3
Plan d’action ancré sur des citations de notes de clôture12 % des tickets100 %—
Coût par triage~3,5 € (temps opérateur)~0,05 € (tokens Claude)/70

Le coût par triage, c’est le chiffre qui accroche dans les slides. Le nombre d’« incidents passés lus par triage », c’est celui qui accroche dans le NOC : c’est la différence entre une recommandation one-shot et une recommandation qui cite la preuve passée exacte qui la soutient.

Le déroulé — du terminal à la boîte mail

Toute l’expérience, vue depuis le poste de l’opérateur :

  1. Il tape /wan-triage dans son terminal.
  2. La skill appelle l’ARN du runtime déployé via SigV4.
  3. Strands exécute la boucle de l’agent. Une quinzaine d’appels d’outils s’enchaînent sur Spectrum, ServiceNow Redshift, la topologie et l’e-mail.
  4. ~100 secondes plus tard, le résumé Markdown apparaît dans le terminal.
  5. En parallèle, le rapport HTML mis en forme atterrit dans la boîte d’astreinte.

Aucun portail à ouvrir, aucun JSON à copier-coller, aucun SSH vers un rebond. Juste une slash command.

Ce que je ferais différemment en repartant de zéro

  • Commencer par le pipeline d’évaluation. Nous avons ajouté les évaluations sur golden-set après coup, une fois l’agent fonctionnel. Construire le jeu d’éval d’abord, en parallèle du prompt de l’agent, aurait permis d’attraper deux régressions plus tôt.

  • Garder un agent unique tant que l’orchestration n’est pas vraiment nécessaire. La tentation de découper en agents « collecteur de faits » + « diagnostic » + « rédacteur » était réelle. Nous avons testé les deux : la boucle mono-agent est moins chère, plus rapide et plus facile à déboguer pour un cas d’usage où le workflow est linéaire.

  • Brancher l’écriture LTM dès le premier jour, même sans l’utiliser. La mémoire s’accumule sur toute la durée de vie du déploiement. Commencer les écritures LTM une semaine après le lancement, c’est perdre une semaine de corpus que vous ne récupérerez jamais.

La suite

Le prochain jalon, c’est la boucle de feedback : quand un opérateur accepte, modifie ou rejette un plan d’action, nous voulons que ce signal reparte dans la LTM sous forme d’événement labellisé. Avec le temps, l’agent apprend non seulement « ce qui a été fait historiquement » mais « ce que l’équipe NOC actuelle accepte réellement comme recommandation utile aujourd’hui ». C’est là que ça devient un système en amélioration continue, plutôt qu’un outil one-shot intelligent.

Si vous construisez un agent similaire pour n’importe quel rôle d’ops de niveau 2 — réseau, réponse à incident de sécurité, alertes applicatives — je serai ravi d’échanger.