Quand un agent IA diagnostique votre Kafka en 2 minutes — ce qui prendrait 90 minutes à la main

Le premier article montrait trois agents IA pilotant une supply chain de 200 magasins sur Kafka — ils agissaient dans le flux métier : détecter les ruptures, décider les réapprovisionnements, exécuter les transferts. Avec MCP Confluent pour appeler les tools Kafka en langage naturel, le pipeline tournait en 30 secondes ce qui prenait 4 heures à la main.

Pour le détail : Kafka remplace vos middlewares — une supply chain de 200 magasins pilotée par 3 agents IA.

Ici, changement de terrain. Les agents ne sont plus dans le flux métier, ils sont autour — côté ops. Un cluster qui va mal, un incident à diagnostiquer. La question n’est plus « que faire ? » mais « que se passe-t-il ? »

Nous prenons dans cet article un cas concret :

Au sommaire

Quand un agent IA diagnostique votre Kafka en 2 minutes — ce qui prendrait 90 minutes à la main

1. Le scénario — un poison message bloque la facturation

Côté métier, le symptôme est simple : les factures ne partent plus. Le système en amont continue d’en produire, mais plus aucune n’atteint la facturation. Pas d’erreur explicite nulle part — juste une alerte technique qui signale un retard de traitement.

Pour l’équipe qui reçoit l’alerte, la seule information disponible est : “facturation est bloqué”, sans savoir où ni pourquoi.

C’est un scénario que je croise régulièrement sur les clusters Kafka que j’opère en mission — plateforme data d’un grand acteur du retail français, des dizaines de consumer groups en production. Le poison message qui bloque un flux critique sans erreur explicite est l’un des incidents les plus chronophages à ce niveau d’échelle, précisément parce que rien dans l’alerte ne dit où chercher.

Sur Kafka, chaque facture est un message : un producteur les émet sur le topic factures, et le consumer group facturation les lit une par une pour alimenter le système de facturation.

La cause du blocage, une fois trouvée, est presque toujours la même :

L’application replante en boucle sur ce message sans jamais réussir à passer au suivant. Chaque facture arrivée après s’empile sans être traitée, et ce retard qui s’accumule est ce que les techniciens appellent le lag. Pour l’équipe ops, l’alerte dit juste “lag en hausse sur facturation”, c’est tout.

flowchart TD
    PROD[Producteur émet factures normales] -->|topic factures| PART[Partition 0]
    PROD_BUG[Producteur bug: siret absent sur 1 message] -->|offset 1452| PART
    PART -->|fetch| CG[Consumer group facturation]
    CG -->|crash parsing siret| CRASH[Consumer crash]
    CRASH -->|reconnect| CG
    CG -.->|offset stuck à 1452| STUCK[Lag monte en continu]
    STUCK --> ALERT[Alerte: lag facturation en hausse]

2. Ce qui se passe vraiment en ops sans agent

L’alerte tombe dans le canal ops : lag en hausse sur facturation, rien d’autre. Rien n’indique où chercher. Voici le déroulé réel — celui que n’importe quel SRE Kafka a vécu :

  1. L’ops ouvre AKHQ (l’interface web de Kafka) ou la CLI. Il consomme les derniers messages du topic, décode à la main, cherche celui qui casse. S’il a de la chance, le poison message est dans les derniers 100 — il le trouve en 30 min. S’il est plus loin, il doit itérer. 30 à 90 minutes perdues.
  2. L’ops identifie l’offset exact du poison message — disons 1452 sur la partition 0.
  3. L’ops lance le fix. Une commande CLI : kafka-consumer-groups.sh --reset-offsets --to-offset 1453 --execute. 30 secondes.
  4. Le consumer reprend. Le poison message est sauté.

La partie pénible, c’est le diagnostic, pas le fix. Le fix est trivial — une commande de 30 secondes — mais pour l’exécuter, il faut savoir quoi skip, quel offset, quelle partition, pourquoi le message casse. C’est l’investigation qui prend du temps. Et c’est exactement ce que l’agent fait en 2-3 minutes.

3. Diagnostic agentique — quatre appels MCP, un diagnostic exact

Ce que fait l’agent, en clair :

  1. Il regarde le retard (le lag)
  2. Il lit les messages autour du point de blocage
  3. Il repère lequel est fautif

La même démarche qu’un ops suivrait à la main, mais enchaînée en quelques secondes plutôt qu’en dizaines de minutes.

Techniquement, l’agent ops est un google.adk.Agent connecté au MCP Confluent (@confluentinc/mcp-confluent) via HTTP SSE — une passerelle qui lui permet d’interroger Kafka avec des appels de haut niveau plutôt que d’écrire du code Kafka.

Le diagnostic enchaîne quatre appels de tool MCP — deux tools, appelés deux fois chacun, contre le cluster Kafka local :

sequenceDiagram
    actor U as Operateur
    participant A as Agent ops (ADK)
    participant M as MCP Confluent
    participant K as Kafka (factures)

    U->>A: facturation est bloqué, pourquoi ?

    A->>M: get-consumer-group-lag group=facturation
    M->>K: AdminClient.listConsumerGroupOffsets
    K-->>M: committed offset P0=1451, lag=478
    M-->>A: lag par partition, P0 stagnant

    Note over A: 2e appel quelques secondes plus tard
    A->>M: get-consumer-group-lag group=facturation
    M-->>A: P0 lag identique → stagnant, pas juste un pic

    A->>M: consume-messages topic=factures partition=0 offset=1451
    M->>K: fetch depuis l'offset 1451
    K-->>M: message 1451 valide, message 1452 = siret absent
    M-->>A: poison message identifié à l'offset 1452

    A->>M: consume-messages topic=factures partition=0 offset=1453 max=5
    M->>K: fetch 5 messages après le poison
    K-->>M: tous valides
    M-->>A: pas de rafale, 1 message isolé

    A-->>U: Poison message offset 1452 P0. Cause: siret absent. 1 message isolé.

Les deux tools qui font tout le travail :

get-consumer-group-lag — le MCP Confluent retourne le **lag par

partition** (log-end offset vs committed offset), pas juste des métadonnées de groupe. L’agent l’appelle deux fois, à quelques secondes d’intervalle, pour confirmer que le lag est stagnant — c’est-à-dire que le consumer ne progresse pas du tout, pas qu’il est simplement lent. C’est le signal qui distingue “poison message” d’“overload temporaire”.

consume-messages avec seek par offset précis — l’agent lit les messages

à partir de l’offset committed du groupe (1451), trouve le message fautif à 1452, puis scanne quelques messages après (1453+) pour distinguer un message isolé d’une rafale. C’est un détail qu’un ops fait mentalement mais ne formalise jamais — l’agent le fait explicitement et le dit.

4. La commande exacte — et sa précondition critique

L’agent ne s’arrête pas au diagnostic. Il formule la commande exacte que l’ops doit exécuter pour sauter le poison message :

kafka-consumer-groups.sh \
  --bootstrap-server broker1:9092 \
  --group facturation \
  --topic factures:0 \
  --reset-offsets \
  --to-offset 1453 \
  --execute

Mais il y a un piège. Et l’agent le connaît.

--reset-offsets échoue si le groupe a un membre actif — autrement dit, si l’application en crash-loop tourne encore, la commande de reset n’a aucun effet. Si le consumer est en boucle crash/retry sans quitter le groupe, la commande plante avec :

Error: Assignments can only be reset if the group is inactive,
but the current state is Stable.

L’agent inclut donc une précondition dans son diagnostic :

Étape 0 — arrêter le process consumer avant le reset.

La commande --reset-offsets échoue si le groupe facturation a un membre actif. Le consumer doit être :

  1. arrêté manuellement d’abord,
  2. puis le reset appliqué,
  3. puis le consumer redémarré.

Un diagnostic qui dit “sauter à l’offset 1453” sans mentionner cette précondition est incomplet : l’ops va essayer la commande, elle va échouer, et perdre 10 minutes de plus à comprendre pourquoi.

5. Le bouclage — l’agent vérifie que le fix a marché

Le fix est manuel — l’ops arrête le consumer, lance la commande, redémarre le consumer. 30 secondes. Mais comment savoir que ça a marché ?

Sans agent : l’ops retourne sur AKHQ ou Grafana, regarde le lag redescendre, et confirme visuellement. Encore 2-3 minutes.

Avec l’agent : la boucle se ferme toute seule :

sequenceDiagram
    actor U as Operateur
    participant A as Agent ops
    participant M as MCP Confluent
    participant K as Kafka

    U->>A: fix appliqué, vérifie
    A->>M: get-consumer-group-lag group=facturation
    M->>K: AdminClient.listConsumerGroupOffsets
    K-->>M: committed offset avancé, lag draine
    M-->>A: lag P0 = 12, en baisse
    A-->>U: Fix vérifié. Lag en baisse, consumer a repris.

L’agent refait un get-consumer-group-lag et confirme que le lag redescend. En 10 secondes.

La boucle se ferme — diagnostic → action humaine → validation agent — sans que l’ops retourne sur un dashboard.

Ce n’est pas de l’autonomie : l’agent ne fixe rien, il diagnostique puis valide.

6. Le gain chiffré

Pour le métier, la question est simple : pendant combien de temps la facturation reste-t-elle bloquée ? La réponse, avec ou sans agent :

Étape Temps sans agent Temps avec agent Ce qui reste humain
Diagnostic 30-90 min (AKHQ + CLI + décodage manuel) 2-3 min (4 appels MCP) Lire le diagnostic
Fix 30 sec (commande CLI) 30 sec (même commande) Exécuter la commande
Validation 2-3 min (retour dashboard) 10 sec (appel MCP) —
Total 33 min - 1h33 ~3-4 min —

Le blocage passe donc d’une plage moyenne de 30 minutes à plus d’une heure, à une plage de 3 à 4 minutes.

Ce que l’agent ne fait pas, en revanche, est tout aussi important :

La décision et l’action restent entièrement humaines — l’ops reste au centre du fix, mais il arrive avec un diagnostic exact, une cause identifiée et une commande prête à exécuter, au lieu de partir à la pêche.

C’est ce même déplacement — d’un temps passé à chercher vers un temps passé à décider — qui rend Kafka et les agents IA utiles ensemble, que ce soit côté flux métier ou côté ops. Sur le flux métier, l’agent agit ; ici, il observe et propose, sans jamais toucher au cluster.

Cette frontière entre lire et agir n’a rien d’automatique — elle a été tracée à la main, tool par tool, pour ce scénario précis. La question qui vient ensuite est la suivante : selon quelles règles la trace-t-on à l’échelle d’un cluster entier, sans la redessiner à la main pour chaque nouvel agent ? Une tentative de réponse fait l’objet du prochain article — gouverner l’autonomie des agents sur Kafka.

Le PoC kafka-ops-agents implémente cette boucle en local. Le problem-injector crée le scénario poison message (topic factures, consumer group facturation, message avec siret absent). L’agent utilise le MCP Confluent pour get-consumer-group-lag et consume-messages avec offset seek — deux tools contre le Kafka KRaft 4.2.x du stack Docker. Le fix (reset d’offsets) est simulé via AdminClient en Python, avec un log SIMULATED: pour marquer que c’est l’ops qui décide, pas l’agent. La validation finale est un appel MCP.

Références

Article précédent : Kafka remplace vos middlewares — une supply chain de 200 magasins pilotée par 3 agents IA — MCP Confluent et KIP-932 en action sur un cas de supply chain retail.

Commentaires