Agents IA en production: quatre formes vraiment réelles

Exemples d'agents IA en production : voilà la vraie réalité opérationnelle. Pas le chatbot RH ou l'assistant commercial des listes marketing. La question que se posent les platform engineers, c'est : à quoi ressemble un agent quand on le laisse près d'un pipeline de déploiement ? La réponse est plus étroite et moins glamour que les decks marketing. Les exemples d'agents IA qui tournent en production infra se divisent en quatre formes : agents de rollback, agents de triage, agents diagnostiques Kubernetes, et exécuteurs de runbook. Aucun n'est pleinement autonome. Tous sont auditables et limités à un seul job. Tout le reste est un chatbot avec un meilleur prompt.

Nous avons tiré ces catégories de cas d'étude publics, de postmortems de vendeurs, et de notre propre travail sur les rollouts avec SLO gate. Aucun n'est pleinement autonome d'un bout à l'autre. Tous sont étroits, auditables, et limités à un seul job.

Ce qui compte vraiment : définir un agent IA opérationnel

Un dashboard qui signale une anomalie n'est pas un agent. Un bot Slack qui te ping quand le p99 franchit un seuil n'est pas un agent non plus, c'est une cron job avec un meilleur texte. La distinction qui compte pour les équipes plateforme : un agent planifie une séquence d'actions sur plus d'un système, adapte ce plan selon ce qu'il découvre, et exécute sans qu'un humain valide chaque étape.

Critère appliqué honnêtement, la plupart de l'outillage « IA DevOps » reste assistif, pas agentic. Il sort les infos plus vite. Les quatre catégories ci-dessous franchissent la ligne de l'action réelle, au moins dans un blast radius défini.

L'agent de rollback : revenir en arrière avant qu'un humain ne le remarque

C'est la forme la plus proche de ce qu'on construit. Un agent regarde le burn rate d'un SLO pendant un rollout et revient en arrière quand le budget franchit un seuil, avant qu'un humain n'ouvre un dashboard. Pas d'appel de jugement, pas de fil Slack à 3h du matin qui demande « c'est assez grave pour revenir ? ». Le seuil est décidé en lumière du jour, quand personne ne fait les maths en mode adrénaline.

Une version minimale du gate ressemble à ça :

type RolloutState = {
  errorBudgetBurn: number; // fraction du SLO budget de mois consommée cette fenêtre
  windowMinutes: number;
  canaryPercent: number;
};

function shouldAutoRollback(state: RolloutState): boolean {
  const burnRateThreshold = 0.14; // 14% du budget mensuel en une fenêtre = page
  const fastBurn = state.errorBudgetBurn / state.windowMinutes > burnRateThreshold / 60;
  return fastBurn && state.canaryPercent > 0;
}

C'est toute la décision. La partie agent, c'est tout le reste : tirer le taux d'erreur live et la latence de la pile observabilité, comparer au SLO pré-déclaré, exécuter le rollback via l'API de déploiement, et écrire une note structurée au canal incident expliquant ce qui l'a déclenché et ce qu'il a vu. On a vu ce pattern tourner en prod chez une fintech en Série C faisant à peu près 40 déploies par jour. Temps médian de la détection du burn au rollback : sous 90 secondes. Le temps médian de l'équipe elle-même, mesuré sur les six mois précédents de postmortems, était 11 minutes.

Oublie ce pattern si ta fréquence de déploiement est assez basse pour qu'un humain regarde déjà chaque rollout en direct. L'agent gagne ses galons au volume, pas à 2 déploies par semaine.

L'agent de triage : de l'alerte au fil Slack en minutes

C'est la catégorie avec le plus de données publiques derrière en ce moment, parce que c'est la plus facile à vendre et la plus facile à mesurer. L'AWS DevOps Agent, par exemple, est déclenché par une alerte CloudWatch ou une page PagerDuty, forme une hypothèse sur la cause, interroge les logs et traces pour la tester, corelle l'anomalie aux timestamps de déploie récents, et poste les découvertes sur Slack avec une mitigation recommandée. AWS rapporte jusqu'à 75% de MTTR plus bas dans ses déploiements documentés, et l'étude de cas de l'Université Western Governors spécifiquement cite un temps de résolution tombant d'à peu près deux heures à 28 minutes (source).

Ce qu'il faut remarquer n'est pas le pourcentage. C'est l'exigence de la piste d'audit : chaque étape de raisonnement que l'agent prend est loggée dans un dossier immuable qu'il ne peut pas modifier lui-même. Ce n'est pas un nice-to-have. Si un agent va coreller ta historique de déploiement avec ton spike d'erreur et dire à un ingénieur on-call « c'est probablement le changement du service checkout », tu dois pouvoir reconstruire exactement comment il est arrivé là quand il se trompe, et il se trompera occasionnellement.

On a vu le même pattern sous des noms différents : Wild Moose promet la surfacing de cause racine en moins d'une minute, HolmesGPT diagnostique les alertes cloud via la même boucle de détection-correlation-explication. Les mécaniques convergent parce que le problème a la même forme partout : alerte déclenche, l'agent lit la télémétrie, l'agent propose une cause, un humain confirme ou surcharge.

Ça vaut la setup si ton équipe page plus de quelques fois par semaine et tes postmortems gardent de citer « trop de temps pour trouver la vraie cause » comme facteur contributif. Oublie si tes incidents sont assez rares pour que le temps de tuning ne se rembourse pas avant que ta prochaine architecture change ne rend stale la data d'entraînement du modèle de toute façon.

L'agent diagnostique Kubernetes : une tranche plus étroite et plus sûre

Le debugging Kubernetes est où un lot de ces outils ont commencé, probablement parce que la sortie kubectl est exactement le type de texte dense et structuré qu'un LLM est bon pour résumer. k8s-GPT scanne un cluster et explique les défaillances en langage clair : pourquoi un pod est coincé en CrashLoopBackOff, pourquoi un PVC ne se lie pas, pourquoi un service n'a pas d'endpoints. Il n'agit pas, il explique. C'est une portée délibérée, et c'est le bon choix pour un outil qu'un jeune ingénieur pourrait exécuter contre un cluster qu'il ne comprend pas complètement encore.

Le niveau suivant agit, prudemment. Les agents style Guardian détectent un problème, trouvent la cause racine, et ouvrent une PR de fix plutôt que de pousser directement au cluster. Ce seul pas supplémentaire, une PR au lieu d'un changement live, est la différence entière entre « une automatisation utile » et « la chose qui a causé la panne de mardi dernier ». Une PR se revue. Un kubectl apply direct depuis un agent ne le fait pas, à moins que tu aies construit une étape de review toi-même, et la plupart des équipes ne l'ont pas.

La couche docs compte plus que les gens l'attendent ici. Quand un agent explique une défaillance Kubernetes ou ouvre une PR de fix, le runbook qu'il suit implicitement soit vit dans la tête de ton équipe, soit vit quelque part que l'agent (et l'ingénieur suivant) peut vraiment lire. Les équipes qui gardent les runbooks dans un outil docs-as-code avec une couche IA interrogable voient moins de fils « attends, pourquoi on l'a fait de cette façon » six mois plus tard. Ce n'est pas un conseil spécifique aux agents, c'est juste que la sortie des agents rend la documentation stale évidente plus vite qu'un humain la lisant jamais ne l'aurait fait.

L'agent exécuteur de runbook : ce qui se passe quand tu laisses un agent toucher la prod

C'est la catégorie que les gens veulent dire quand ils disent « agent SRE totalement autonome », et c'est aussi celle avec la base de preuves la plus mince. Le pitch : un agent détecte une fuite mémoire, déclenche un restart roulant pendant une fenêtre de trafic bas, confirme que le service est revenu sain, et ferme la boucle sans pager quelqu'un. Des playbooks de remédiation multi-step, exécutés sans le risque d'une typo ou d'une étape sautée dans un runbook à 2h du matin qui n'a pas été testé depuis mars.

Ça marche, quand le playbook est étroit et le blast radius petit. Un restart roulant d'un service sans état pendant une fenêtre de trafic bas définie est une chose raisonnable à automatiser. Un failover de base de données pendant les heures de bureau ne l'est pas, peu importe à quel point le dossier de track de l'agent ressemble bien dans une démo. Les équipes qui se font griller ici ne sont pas celles qui automatisent les restarts, elles sont celles qui laissent une belle victoire initiale les convaincre d'automatiser quelque chose avec un vrai risque de perte de data avant que l'agent ait eu assez de reps en prod pour mériter cette confiance.

Notre propre lecture, en regardant les clients câbler l'AI Pilot dans des rollouts progressifs : commence par l'action la plus facile à revenir et la plus dure à rater. Restart avant failover. Rollback de pourcentage canary avant les changements de schéma de base. Laisse le taux d'erreur de l'agent sur des actions à enjeu bas construire le cas pour les plus hauts enjeux, sur une timeline mesurée en mois, pas la première belle semaine.

Les agents généralistes montrent aussi le bout de leur nez, et ils ont la mauvaise forme pour ça

Cherche « exemples d'agents IA » n'importe où en dehors d'un contexte ops et tu vas atterrir sur une catégorie entièrement différente : des agents généralistes construits pour planifier et exécuter des tâches en open-ended sur un navigateur virtuel, terminal, et système de fichiers.

Manus opère à l'intérieur d'un ordinateur virtuel complet et rapporte les livrables terminés plutôt qu'une réponse chat. C'est vraiment capable sur la recherche et les tâches multi-step web. C'est aussi le mauvais outil pour une décision de rollout en prod, parce que sa proposition de valeur est la largeur : il peut faire à peu près n'importe quoi, étant donné assez d'étapes et assez de temps. Une décision de rollback a besoin de la propriété opposée. Elle a besoin d'être vite, étroite, et assez ennuyeuse pour que tu puisses prédire exactement ce qu'elle va faire avant qu'elle le fasse.

Lindy s'assoit plus près du milieu ops-adjacent : des workflows no-code qui gèrent le triage d'inbox, la programmation de réunions, et les follow-ups récurrents. Utile pour le côté humain d'une rotation on-call (personne ne veut reprogrammer une passation manuellement à 6h du matin), inutile pour la vraie réponse aux incidents. Même histoire avec le Super Agent no-code de Genspark, qui navigue, appelle, et génère à la demande mais n'a aucun concept d'un budget SLO ou d'un pourcentage canary.

Aucun de ça n'est un knock sur ces produits. Ils sont construits pour un job différent. L'erreur qu'on voit constamment est les équipes évaluant un agent généraliste contre un problème ops étroit, se sentant peu impressionnées, et conclure « les agents IA ne sont pas prêts pour l'infra ». Mauvaise catégorie, mauvaise conclusion.

Où ces agents échouent encore, et pourquoi c'est la partie intéressante

Le mode d'échec que personne ne met dans l'étude de cas : les agents qui sont 94% précis sur l'identification de cause racine se trompent encore une fois sur dix-sept, et la mauvaise réponse est habituellement confiante-sounding et assez spécifique pour envoyer un ingénieur on-call chasser le mauvais service pendant vingt minutes avant que quelqu'un remarque que la corrélation que l'agent a trouvée était coïncidentale, pas causale. La corrélation de timestamp de déploiement est un vrai signal. Ce n'est pas une preuve. Un agent entraîné à sonner sûr va sonner sûr sur une coïncidence tout aussi facilement que sur une vraie cause.

Le deuxième mode d'échec est plus silencieux : la prolifération d'agents. Une fois que les agents de triage, diagnostic, et rollback tournent tous, quelqu'un doit monitorer les agents. Les déploiements début 2026 montrent déjà que le plus gros gain opérationnel n'est pas le chiffre MTTR, c'est de construire l'observabilité pour la couche agent elle-même, parce qu'un agent qui arrête silencieusement de se déclencher est pire qu'aucun agent du tout. Personne ne remarque l'absence d'une alerte.

Oublie l'autonomie complète sur n'importe quoi avec un blast radius irréversible, peu importe à quel point les vingt dernières exécutions ressemblaient bien. Vingt bonnes exécutions n'est pas une distribution, c'est un échantillon.

Quand câbler un agent à ton rollout, ou attendre le cycle suivant ?

Si ton équipe page plus de quelques fois par mois et tes postmortems gardent de répéter la même cause racine avec des noms de service différents, un agent de triage se rembourse lui-même plus vite que tu l'attends, surtout en rétrécissant la phase « qu'est-ce qui a changé » de chaque incident. Si ton volume de déploiement est assez haut pour qu'un humain ne puisse pas regarder chaque rollout en direct, un agent de rollback SLO-gated enlève l'appel de jugement à 3h du matin complètement, ce qui est le point réel : tu ne veux pas que l'ingénieur on-call réfléchisse à 3h du matin, tu veux qu'il appuie sur un bouton qui a été configuré en lumière du jour.

Si ni l'un ni l'autre n'est vrai encore, le move honnête est d'instrumenter tes SLOs correctement d'abord. Un agent s'asseyant sur des budgets d'erreur bruyants et indéfinis va juste automatiser les mauvaises décisions plus vite qu'un humain les aurait prises. L'agent n'est pas la partie dure. Savoir exactement ce que « assez mauvais pour agir » veut dire, en chiffres, avant de remettre la décision à quelque chose qui ne se fatigue pas à 3h du matin, c'est ça.