Le 16 août, mon agent d'exploitation, celui qui surveille les serveurs et déploie les mises à jour, a gelé six fois dans la journée. À chaque fois, il rapportait la même chose : ses outils ne répondaient plus, même une commande triviale.

Ce n'étaient pas ses outils. Il n'atteignait jamais le moment de les appeler.

Un échec qui se répète à l'identique

Un message ancien de sa conversation portait un bloc corrompu, rejeté par l'API du modèle. Chaque requête rejouant tout l'historique, l'échec était déterministe : trois reprises automatiques, trois refus, puis un tour terminé sans sortie visible. Vu depuis le téléphone, cela ressemblait à un gel ; techniquement, c'était un refus reproductible.

Un échec qui se répète à l'identique ressemble à une instabilité quand on ne voit que ses effets. La différence tient à une seule question : est-ce que ça échoue toujours au même endroit ?

L'ampleur, invisible

  • 80 appels en échec dans la journée, sur 20 exécutions distinctes ;
  • une cadence régulière, toutes les trente minutes ;
  • un déclencheur interne : un contrôle de routine de l'agent.

Et ce contrôle de routine vérifiait… des chemins de fichiers d'un ancien serveur, retiré onze jours plus tôt lors d'une migration. Le fichier d'instructions portait lui-même, en première ligne, un avertissement : « écrit sur l'ancien serveur, à revérifier avant usage ». Personne ne l'a lu, parce qu'il n'apparaissait dans aucun rapport.

Pendant onze jours, toutes les trente minutes, l'agent a donc consciencieusement vérifié une machine morte. Et chaque vérification était facturée, car elle rejouait toute la conversation : près de 2 Mo de contexte à chaque tir.

Le correctif, sur les trois causes

  1. Le travail inutile : les instructions périmées ont été retirées.
  2. Le coût : les contrôles de routine tournent désormais dans une session isolée, sans l'historique.
  3. La corruption : la conversation abîmée a été archivée.

Vérifié, pas supposé : après correction, zéro erreur et zéro appel inutile. De quatre-vingts appels facturés à aucun.

Ce que j'ai failli conclure de travers

Notre propre documentation attribuait ce type de corruption aux redémarrages de l'agent, et il y en avait eu huit ce jour-là. La chronologie l'interdisait : la corruption était antérieure de six heures au premier redémarrage. Une cause plausible, déjà écrite, compatible avec les faits du jour. Il a suffi d'aligner les horodatages pour qu'elle tombe.

Ce qu'un dirigeant doit en retenir

Le coût n'était pas le sujet : quelques dizaines d'euros. Le sujet, c'est que dix heures de silence et quatre-vingts appels facturés n'ont produit aucune alerte. L'objectif « le coût reste marginal » était écrit dans le cahier des charges. Il n'était mesuré nulle part. Tant qu'un objectif n'est pas instrumenté, il n'est pas tenu : il est espéré.

Avant de confier une tâche à un agent, demandez à votre prestataire : combien d'exécutions ont échoué hier, et combien ont-elles coûté ? S'il ne peut pas répondre en une minute, le système n'est pas en production. Il est en sursis.