La télémétrie « verte » peut masquer une perte silencieuse de données lors d’un changement d’outils

Un ingénieur logiciel a découvert que son système automatisé de télémétrie signalait une santé normale pendant plusieurs semaines tout en échouant silencieusement à capturer la majorité de l’activité de ses agents IA. L’incident s’est produit en octobre 2026 après que l’utilisateur a déplacé son flux de travail de Claude Code vers Codex, un changement qui a transféré la génération de données hors du périmètre de son pipeline de surveillance existant.

Ce qui s’est passé

L’ingénieur maintient un rapport hebdomadaire de comparaison stratifiée qui analyse les sessions des agents, suivant des métriques telles que les taux d’erreur des outils et les jetons de sortie. Ce rapport est généré par une tâche cron chaque lundi à 09:30, qui traite les transcriptions archivées depuis un répertoire spécifique utilisé par Claude Code. Pendant plusieurs semaines, le rapport a continué à être publié avec un statut « normal », indiquant zéro problème de qualité des données et des distributions statistiques cohérentes.

Cependant, les données sous-jacentes avaient changé de manière spectaculaire. Le 6 septembre 2026, l’utilisateur a configuré son système pour router par défaut les exécutions planifiées sans intervention humaine et les requêtes headless vers Codex, limitant Claude Code à seulement deux sessions par jour. Plus tard, le 5 octobre, il a remis Claude Code dans le rôle principal d’orchestrateur, mais les exécutions sans intervention sont restées sur Codex. Le pipeline d’ingestion n’a jamais été mis à jour pour lire depuis le répertoire de session de Codex, ce qui signifiait qu’il ne capturait qu’une infime fraction du travail réellement effectué.

Malgré cet énorme angle mort, les contrôles de santé ont réussi chaque semaine. Le système vérifiait que la commande de copie se terminait avec le code 0, que le nombre de fichiers archivés ne diminuait pas et que les règles internes de cohérence des données étaient respectées. Parce que la tâche cron elle-même s’exécutait avec succès et traitait sans erreur les quelques fichiers restants de Claude Code, le système de surveillance n’avait aucune raison de signaler un incident. Le rapport décrivait avec précision le petit échantillon de données qu’il recevait, créant un faux sentiment de sécurité.

Détails clés

• Le rapport de télémétrie affichait des médianes et des intervalles interquartiles identiques pendant des semaines, différant uniquement de 12 lignes liées aux métadonnées et aux comptages mineurs.
• Entre le 13 et le 20 septembre, le système a enregistré zéro fichier de transcription Claude Code mais 192 fichiers de déploiement Codex.
• Du 27 septembre au 4 octobre, l’ingestion n’a capturé que 3 fichiers Claude Code tandis que 1 058 fichiers Codex ont été générés.
• La session la plus récente dans la base de données s’est terminée le 11 septembre, pourtant le rapport du 21 septembre marquait toujours le système comme normal.
• Les contrôles de santé validaient l’exécution des processus et la cohérence des données, mais ne vérifiaient pas si le volume de données ingérées correspondait à l’activité réelle.
• Un contrôle distinct de fraîcheur a réussi parce que le fichier de base de données était réécrit chaque semaine par le processus de build, indépendamment de l’ajout ou non de nouvelles données.

Contexte

Les systèmes de télémétrie reposent souvent sur la surveillance des « battements de cœur » (heartbeats) ou des codes de sortie pour déterminer la santé. Si un script s’exécute jusqu’à sa fin sans crasher, il est considéré comme sain. Cette approche fonctionne bien pour détecter les plantages mais échoue à détecter les « défaillances silencieuses » où le script s’exécute mais ne traite aucune donnée significative. Dans ce cas, la surveillance était étroitement couplée à un chemin d’outil spécifique. Lorsque la charge de travail a basculé vers un autre outil avec une structure de fichiers différente, le moniteur a continué à surveiller l’ancien chemin vide.

Cela illustre un piège courant dans l’observabilité auto-hébergée : surveiller le mécanisme plutôt que le résultat. Le système confirmait que le pipeline de données était opérationnel, mais ne confirmait pas que le pipeline recevait l’entrée attendue. Sans dénominateur externe — un comptage du travail total effectué à travers tous les outils — le système ne pouvait pas reconnaître que sa vision du monde s’était réduite.

Pourquoi c’est important

Pour les équipes exécutant leur propre logiciel, ce scénario met en évidence le risque d’une surveillance statique dans des environnements dynamiques. À mesure que l’infrastructure et les flux de travail évoluent, les chemins codés en dur et les hypothèses deviennent des passifs. Si votre script de sauvegarde s’exécute avec succès mais sauvegarde un répertoire vide parce que la source de données a déménagé, votre surveillance restera probablement verte jusqu’à ce que vous tentiez une restauration. L’absence d’erreurs n’est pas une preuve de succès.

Cet incident démontre également le danger de trop compter sur les contrôles de cohérence interne. Des métriques comme « zéro résultat d’outil orphelin » sont précieuses pour l’intégrité des données mais inutiles pour la couverture. Un système peut être parfaitement cohérent tout en étant totalement hors sujet. Les ingénieurs doivent s’assurer que leurs contrôles de santé incluent des contraintes de validité sur le volume et la fraîcheur des données par rapport à la réalité externe, et non seulement sur les états des processus internes.

De plus, le silence de la défaillance l’a rendue plus difficile à détecter qu’un crash. Un script cassé génère des alertes ; un script fonctionnel traitant des données obsolètes génère de la confiance. Les équipes doivent concevoir des moniteurs qui échouent bruyamment lorsque les données cessent d’arriver, plutôt que d’accepter silencieusement ce qui est disponible. Cela nécessite de découpler la définition de « sain » de celle de « exécuté sans erreur ».

Ce que vous pouvez faire

• Implémentez une surveillance par battement de cœur (heartbeat) pour les tâches critiques, exigeant un signal explicite provenant de l’intérieur du processus, et non seulement un code de sortie réussi.
• Ajoutez des vérifications de dénominateur externe qui comparent le volume de données ingérées à des sources de vérité connues, telles que le nombre de fichiers dans tous les répertoires pertinents.
• Configurez des alertes de fraîcheur basées sur l’horodatage de l’enregistrement de données le plus récent, et non sur la date de dernière modification du fichier de base de données.
• Revoyez les politiques de routage et les changements d’outils pour garantir que les périmètres de surveillance sont mis à jour chaque fois que les sources de données changent ou s’élargissent.
• Testez la logique de surveillance en simulant une pénurie de données pour vérifier que les scénarios à faible volume déclenchent des avertissements appropriés.
• Découplez les alertes de l’utilisation principale de l’outil en envoyant des notifications vers des canaux indépendants du flux de travail surveillé, assurant ainsi une visibilité même lorsque l’outil principal est inactif.