Je mise mon entreprise sur les agents proactifs

Les agents peuvent faire presque tout ce que tu leur demandes, et c’est le problème : tu dois encore demander.

J’entends sans cesse des gens appeler les agents des « collègues numériques ». Ce cadrage est faux. Un collègue qui reste assis en silence jusqu’à ce que tu lui tendes une tâche parfaitement délimitée, l’accomplit, puis se remet à attendre, n’est pas un collègue. Chaque agent que tu as utilisé fonctionne exactement comme ça. Les modèles sont devenus plus intelligents, les harnais meilleurs, les runs plus longs, mais l’interface n’a jamais changé : tu apportes le travail, l’agent apporte la main-d’œuvre.

Et la plupart des gens ne l’ont pas remarqué, parce que la boîte de prompt est discrètement devenue, dans nos têtes, ce que l’IA est.

Ask anything about your stack...

Chaque interface est encore une boîte de prompt

Le champ de saisie est ce par quoi toute cette ère a commencé. ChatGPT en a posé un sur un modèle et est devenu le produit à la croissance la plus rapide de l’histoire, et nous l’avons tous copié. Chaque produit d’IA depuis est une variation de la même interaction : l’humain tape, la machine répond, la machine attend.

Claude Code a été l’évolution suivante. L’agent s’est installé dans ton terminal, a pris tes fichiers, ton shell et ton historique git, et a commencé à faire du vrai travail au lieu d’en parler. Ça a changé ce que les agents pouvaient faire, mais pas la façon dont ils démarrent : tu tapes, il travaille, il s’arrête, et il attend que tu tapes à nouveau.

~/app

$ claude

✳ 12 files · main · last session 2h ago

> fix the failing checkout tests

? for shortcuts

Puis les agents sont partis dans le cloud. Codex, Devin, Claude Code sur le web. Ils tournent pendant des heures au lieu de minutes, lancent des sous-agents pour paralléliser le travail, et ne meurent pas quand tu fermes ton ordinateur. Tu confies une tâche à l’un d’eux avant le déjeuner et tu reviens à une pull request.

Le prompt a même cessé d’être une affaire de clavier. Les agents en arrière-plan peuvent être lancés par une alerte ou un webhook, et la plupart des plateformes d’agents proposent désormais des automatisations : quand cet événement se déclenche, ou que ce cron sonne, lance un agent avec ces instructions.

Triage Sentry alerts Enabled

When

a Sentry alert fires

Do

investigate, open an incident if it's real

Then

post the findings to #incidents

Mais qu’est-ce qu’une automatisation ? C’est un prompt que tu as écrit à l’avance. Tu as prédit le mode de défaillance, choisi l’événement et noté ce qu’il fallait faire. Le déclencheur lance l’agent, mais le jugement à l’intérieur est le tien, figé au moment de la configuration. Une automatisation attrape exactement ce que tu avais anticipé, et rien d’autre.

Tu es l’ordonnanceur

Retire l’outillage et la division du travail n’a pas bougé en trois ans. L’agent fait le travail. Décider quel est le travail reste ton boulot.

Tu lis les dashboards, tu écoutes les utilisateurs, tu détermines ce qui compte, et tu compresses tout ce que tu as appris dans un prompt, soit en direct au clavier, soit à l’avance dans un déclencheur. L’agent exécute brillamment, mais chaque parcelle de jugement du système vient de toi.

La prochaine évolution : des agents qui trouvent le travail

Je parie que la prochaine évolution, ce sont des agents qui trouvent eux-mêmes le travail à faire. Pas de prompt, pas de déclencheur à configurer, pas d’instructions écrites à l’avance. Tu connectes ta stack, et l’agent trouve le travail tout seul : il surveille les mêmes signaux que toi, remarque ce qui ne va pas, décide si ça compte, et se met au travail de façon autonome.

C’est facile à dire, et brutalement difficile à construire, parce que la proactivité, ce sont trois problèmes empilés les uns sur les autres, et en sauter un seul donne quelque chose de pire que l’agent derrière un champ de saisie.

Le contexte. Évidemment, l’agent a besoin d’un modèle vivant du monde dans lequel il opère, pas d’un instantané que tu as collé dans la fenêtre de contexte au moment du prompt. Un agent réactif avec un mauvais contexte te donne une mauvaise réponse. Un agent proactif avec un mauvais contexte supprime ta base de données de prod parce qu’il la prenait pour le staging.

Le jugement. C’est ce qui m’a donné le plus de mal. À tout instant, des milliers de choses dans un système de production sont légèrement de travers. Un agent qui les signale toutes est une machine à bruit, les machines à bruit finissent en sourdine, et un agent en sourdine est un agent mort. Toute la valeur de la proactivité vit dans l’écart entre « quelque chose a changé » et « quelque chose compte » :

[
  {
    "signal": "memory up 3% on checkout-edge",
    "verdict": "no anomaly",
    "reasoning": "within the seasonal range for this hour on this worker"
  },
  {
    "signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
    "verdict": "incident",
    "reasoning": "error class never seen on this worker, tightly correlated with a deploy"
  }
]

L’action. Remarquer sans agir n’est qu’une alerte plus intelligente, et les alertes sont précisément ce que j’essaie de tuer. L’agent doit finir le travail, à l’intérieur de limites qui rendent l’autonomie sûre : des actions réversibles, des preuves pour tout, et une barrière ferme avant quoi que ce soit d’irréversible.

Aucun de ces trois problèmes n’implique que l’agent décide de ce à quoi ressemble le bien. Il décide de ce qui ne va pas, si ça compte, et quoi faire, et c’est toute la liste, parce qu’en production personne n’a à définir le bien : des erreurs à zéro, une latence à la baseline, des files vidées, des certificats valides. L’état souhaité vient avec le territoire.

Ce qui veut dire que le vrai basculement n’est pas de « tu promptes » vers « l’agent se prompte lui-même ». C’est de l’exploitation impérative vers l’exploitation déclarative. Une automatisation est impérative : tu énumères les modes de défaillance à l’avance et tu scriptes une réponse pour chacun. Un agent proactif est une boucle de réconciliation : il confronte le système que tu as au système que tu devrais avoir, et travaille à combler l’écart. Kubernetes l’a fait pour l’infrastructure il y a dix ans, tu écris trois réplicas et un contrôleur fait tout ce qu’il faut pour garder trois réplicas en vie. Personne ne l’a fait pour l’exploitation du logiciel lui-même. Et ici, il n’y a même pas de YAML à écrire, parce que l’état souhaité est déjà connu. Ça marche d’office.

J’ai commencé par l’exploitation

Demande à un agent proactif de choisir ta roadmap produit et tu obtiens un stagiaire avec des opinions, parce que la direction produit est une affaire de goût. La production, non. C’est le seul domaine où les trois problèmes sont résolubles aujourd’hui.

Le travail s’annonce de lui-même : les taux d’erreurs grimpent, un deploy part de travers, un certificat expire, une file s’engorge. Le travail est déjà là, dans la télémétrie, en attente que quelqu’un le remarque. Et contrairement aux domaines guidés par le goût, la vérité terrain existe : le taux d’erreurs a grimpé ou pas, le rollback a restauré la baseline ou pas, le jugement de l’agent est donc noté par le système lui-même, en continu, sans place pour les impressions.

Surtout, nous employons déjà des humains pour ce travail. Nous appelons ça l’on-call : une personne qui dort à côté d’un téléphone, en attendant qu’une machine dise qu’une autre machine est mécontente. J’ai passé des années dans l’observabilité, fondé une entreprise d’observabilité que Cloudflare a rachetée, et écrit tout un manifeste sur la structuration de la télémétrie pour que la réponse soit à une requête de distance. Sa thèse est la raison d’être de cette entreprise : personne ne devrait être on-call en 2026.

Parce que la vérité inconfortable sur la dernière décennie d’observabilité, c’est que nous avons rendu les systèmes plus faciles à interroger pour les humains à 3 h du matin, puis déclaré victoire alors que c’étaient toujours les humains qu’on réveillait. Les dashboards sont devenus plus jolis et le pager est resté sur la table de nuit. L’observabilité sans action n’est que du stockage cher.

À quoi ça ressemble

C’est ce que fait Polylane. Voici un mardi concret :

Personne n’a configuré de vérification pour ce mode de défaillance. Il n’y a aucune règle à écrire et aucun seuil à régler : les agents évaluent chaque ressource connectée à un rythme continu, et tes dashboards et requêtes enregistrées existants deviennent leur checklist. Le jugement est là où je suis le plus strict. Le verdict par défaut est no anomaly, parce qu’il vaut bien mieux manquer une issue limite que réveiller quelqu’un pour du bruit. « Un deploy pourrait introduire un bug » est vrai de chaque deploy et ne justifie jamais de réveiller qui que ce soit.

Quand quelque chose est réel, l’enquête fait tourner plusieurs hypothèses concurrentes en parallèle, et le travail de chaque agent est de réfuter son hypothèse plutôt que de la confirmer, pour que la corrélation ne puisse jamais se faire passer pour une cause. Quand la cause racine confirmée est un changement de code, le correctif arrive sous forme de pull request avec l’enquête jointe :

Restore Hyperdrive pool size in checkout-edge

PR open coreplane/checkout-edge

Investigation report attached Checks passing

Opened by Polylane · gated on review and CI

Proactif ne veut pas dire sans supervision

L’autonomie est dans le fait de remarquer, dans le triage, dans l’archéologie de 3 h du matin et dans l’atténuation. Tout ce qui restaure un état connu comme sain, l’agent le fait tout seul : annuler le mauvais deploy, remettre le flag sur off. Ces actions sont réversibles par construction, et ce sont elles qui font vraiment taire le pager. Ce qui reste derrière une barrière, c’est tout ce qui crée un nouvel état : un changement de code passe par ta revue et ta CI, jamais à côté.

La ligne n’est pas humain contre agent. C’est réversible contre irréversible. Et c’est pour ça que tu n’es pas secrètement encore on-call : le rollback a mis fin à l’incident à 02:33, six heures avant que tu fusionnes la pull request. La PR n’a jamais été ce qui a arrêté l’hémorragie. C’est ce qui l’empêche de se reproduire, et ça peut attendre le café.

Et la barrière, tu peux la déléguer. Les agents de revue de code lisent déjà chaque pull request de ton dépôt. Il existe un monde, pas loin de celui-ci, où ton agent de revue lit le correctif à 02:41, le vérifie face à l’enquête, l’approuve, et ta CI déploie en production avant ton réveil. Rien ne change dans la boucle, sauf qui tient le bouton d’approbation. C’est là que tout cela aboutit : un logiciel qui se répare lui-même, avec toi qui écris la politique au lieu de cliquer sur fusionner.

Remarque ce qui manque dans cette boucle :

Ask anything about your stack...

La boîte de prompt a été une excellente façon d’apprendre à faire confiance à ces systèmes, et c’est une très mauvaise façon de faire tourner la production. L’agent a vu chaque deploy, chaque ligne de log et chaque métrique de chaque service, tout à la fois. Le garder derrière un prompt, c’est faire en sorte que le membre le mieux informé de ton équipe ne parle que quand on lui adresse la parole.

Personne ne devrait être on-call en 2026.