Les agents de code IA ont besoin d’un contrat de logs, pas d’un meilleur prompt.

La production juge le changement en dernier#

Un agent de code IA peut livrer un changement qui compile et passe les tests, tout en rendant le système plus difficile à exploiter. À l’incident suivant, le seul nouveau log dit qu’une erreur s’est produite.

Je ne considère pas ce changement comme terminé.

Comme je l’expliquais dans Coder plus vite n’est pas livrer plus vite, accélérer l’implémentation n’accélère pas tout le cycle de livraison. Les logs en sont un bon exemple : le code arrive plus vite, mais quelqu’un doit encore le rendre compréhensible en production.

Cette exigence opérationnelle ne peut rester une préférence informelle. Il lui faut un contrat.

Les humains réparent discrètement les logs générés par les agents#

Une prépublication empirique de 2026 a étudié 4 550 pull requests agentiques dans 81 dépôts open source. Parmi les 77 dépôts comparables, les agents modifiaient moins souvent les logs que les humains dans 58,4 % des cas.

Parmi les 1 308 pull requests où un canal de consignes était observable, seules 61, soit 4,7 %, parlaient explicitement des logs. Les auteurs rapportent 67 % de non-respect des demandes constructives analysées. Les humains ont réalisé 72,5 % des modifications de logs après génération.

Il s’agit d’une prépublication, pas d’un référentiel universel. Elle couvre des dépôts, agents et workflows précis. Elle ne prouve pas que tous les agents gèrent mal les logs.

Les longueurs de messages sont aussi similaires, et l’écart apparent de densité se réduit largement lorsque la taille des pull requests est prise en compte. L’étude ne dit pas que les agents produisent toujours trop peu de logs. Elle révèle un risque plus précis : terminer la tâche visible tout en oubliant l’exigence opérationnelle.

Utilisez un code d’événement et un message clair#

Chaque log important doit contenir quatre éléments : un nom d’événement stable, un message technique court, des champs structurés et un contexte de trace relié à l’opération complète.

{
  "event.name": "document.delivery.accepted",
  "severity_text": "INFO",
  "body": "Document delivery was accepted",
  "trace_id": "4bf92f3577b34da6",
  "channel": "api",
  "outcome": "accepted"
}

Le code fournit un identifiant stable aux tableaux de bord, alertes et requêtes. Le message permet à un humain de comprendre les faits sans consulter un catalogue. Le texte seul rend l’automatisation dépendante de la formulation. Le code seul ralentit l’analyse. Il faut les deux.

Les champs doivent ajouter du contexte sans exposer identifiants, jetons, adresses e-mail ou données personnelles inutiles. Le modèle de logs OpenTelemetry définit déjà événement, sévérité, trace, corps et attributs. Le guide OWASP fixe la limite de sécurité. Je préfère ces modèles à une nouvelle convention par projet.

Donnez un seul sens à chaque niveau de log#

Le contrat doit aussi définir une sémantique stable pour les niveaux.

Une exception interceptée n’est pas automatiquement une erreur. Si l’application la traite et termine normalement l’opération demandée, ERROR peut créer un faux signal d’incident. L’inverse est aussi vrai. Un échec métier ne doit pas disparaître dans DEBUG simplement parce que l’application continue de fonctionner.

AGENTS.md guide, mais ne contrôle pas#

Un fichier AGENTS.md reste utile. OpenAI le présente comme un emplacement pour les commandes, conventions, attentes de revue et contraintes du dépôt. Chaque session reçoit ainsi le même point de départ.

Je garderais la section sur les logs courte : structure attendue, niveaux, données interdites, exemples approuvés et commande de vérification. Pas un manuel de vingt pages.

Mais ces consignes ne prouvent pas que le code respecte la règle. L’étude avertit que le langage naturel seul reste peu fiable pour cette exigence non fonctionnelle.

Déplacez les règles vérifiables dans la CI#

Tout ce qui peut être vérifié de façon déterministe doit quitter le prompt et entrer dans la chaîne d’outils.

Une API commune peut exiger événement et champs structurés. Un catalogue peut empêcher les codes invalides ou dupliqués. L’analyse statique peut refuser System.out, printStackTrace et les champs interdits. Les tests peuvent vérifier code et résultat sans figer tout le message.

La CI doit contrôler les changements humains comme ceux des agents. Le standard ne dépend pas de l’auteur de la pull request.

L’automatisation ne peut pas décider si un événement mérite un log ni si son contexte aidera pendant un incident. Cela reste une décision d’ingénierie. Elle retire les défauts mécaniques pour concentrer la revue sur ces choix.

Produisez des preuves, pas du volume#

De bons logs ne produisent pas plus de lignes. Ils laissent assez de preuves stables pour reconstruire les faits.

Ce principe soutient aussi le workflow décrit dans Claude en entreprise. Un agent ne peut analyser un incident qu’avec des faits fiables à corréler. Du bruit non structuré ne devient pas utile parce qu’un modèle peut le lire.

Le modèle rédige l’appel. Le contrat en définit la forme. La CI vérifie la mécanique. Un humain reste responsable de l’utilité de l’événement lorsque le système échoue.

Cette organisation survivra au prochain modèle, au prochain incident et au prochain ingénieur.