Découvrir des résultats que personne ne lit : un audit des consommateurs pour les systèmes automatisés

Tout système automatisé accumule des tâches qui s’exécutent correctement mais ne concernent personne : un rapport régénéré chaque nuit que personne n’ouvre, une étape de validation qui peut échouer mais n’est jamais sollicitée, une règle ajoutée à une liste de contrôle que aucun processus ne lit réellement. Aucune de ces éléments ne provoque de problème, et c’est précisément pour cela qu’ils survivent. Cet article décrit comment auditer un système dont les sorties n’ont pas de destinataire, ce que révèle généralement une telle auditation, les trois erreurs qui font que l’audit détruit des composants fonctionnels, ainsi que le seul métadonnée qui rend toute cette démarche presque gratuite.

Le principe de l’audit : chaque étape a un expéditeur et un destinataire

Une discipline utile pour les pipelines, qu’ils soient constitués de tâches cron, d’étapes CI ou de sessions d’agents IA enchaînées, consiste à exiger que chaque unité de travail soit connectée des deux côtés. Quelque chose en amont lui fournit du contexte et des entrées ; quelque chose en aval reçoit ce qu’elle produit. Une étape qui reçoit correctement mais ne transmet rien n’accomplit pas de travail utile, même si tout ce qu’elle fait est correct.

Définir la règle est facile. La vérifier est plus difficile, car sa violation ne laisse aucune trace. L’audit a pour but de repérer les étapes qui effectuent des actions sensées dont le résultat n’est jamais pris en compte. Il est particulièrement efficace lorsqu’il est effectué régulièrement, par exemple dans le cadre de chaque rétrospective, plutôt qu’une seule fois après une crise de nettoyage.

Ce que trouve généralement un audit honnête

Imaginons une équipe qui utilise un flux de travail fortement automatisé géré par des agents pour effectuer cette auditation sur elle-même. Les résultats étaient peu flatteurs, ce qui en faisait justement leur utilité.

• Contrôles qui ne sont jamais déclenchés. Ils ont découvert 95 vérifications susceptibles de se mettre en rouge, mais qui n’étaient jamais activées. Chacune d’elles avait été correctement mise en œuvre et testée, et semblait essentielle au moment de sa création, pourtant aucune n’était intégrée dans aucun parcours.
• Règles sans appelant. Sur les 25 règles récemment adoptées, 19, soit 76 %, ne figuraient dans aucune référence de parcours de code, de liste de contrôle ou de routine. Le problème n’était pas un manque d’obéissance ; rien ne les mentionnait du tout. Une procédure de débogage est restée dans les directives officielles de l’équipe pendant 42 jours sans jamais être appliquée. Personne ne l’avait oubliée. Le fait de l’avoir notée avait simplement été confondu avec son adoption.

Un registre de tâches rempli d’éléments inactifs. Un comptage en temps réel indiquait 417 tâches ouvertes, dont 146 sans aucune activité et 104 pour lesquelles il n’existait pas de définition de finition. Le plus ancien élément inchangé datait de 37 jours.

Un tableau de bord que personne ne pouvait voir. Un tableau de bord relatif au pipeline de publication était mis à jour à chaque version et stocké dans l’emplacement partagé qui lui était destiné. Cependant, le partage sur la machine de production était configuré en mode lecture seule, si bien que rien de ce qui y était écrit n’était jamais transmis ailleurs. Pendant des semaines, il est resté exact et à jour, sans que personne d’autre ne le voie.

Le dernier cas résume la leçon en une phrase : mettre quelque chose au bon endroit n’est pas synonyme de le livrer.

Pourquoi l’échec survient toujours aux points de jonction

Les pertes ont tendance à survenir aux frontières entre les systèmes, et ce n’est pas propre à l’IA. Quelque chose est transmis mais non accepté, ou accepté sans être remarqué à temps. Dans tous les cas mentionnés ci-dessus, la partie productrice a fonctionné parfaitement : l’auteur a écrit, le compteur a enregistré, la porte a pu s’ouvrir. Ce qui manquait, c’était un consommateur identifié.

La difficulté majeure réside dans le fait que rien ne tombe en panne lorsque le consommateur est absent. Une consommation absente ne génère ni erreur, ni alerte, ni entrée dans le journal. Les producteurs sont surveillés car leurs pannes sont audibles ; les consommateurs le sont rarement, car leur absence reste silencieuse.

Deux autres cas illustrent les conséquences de ce silence persistant :

Ces problèmes auraient pu être détectés par une vérification du côté récepteur : l’opérateur a-t-il bien reçu quelque chose ? La source indiquée par le tableau de bord existe-t-elle vraiment ?

Trois manières dont un audit d’utilisation peut échouer

La version naïve de cet audit, consistant à « compter la fréquence d’utilisation de chaque composant et à supprimer ceux qui obtiennent zéro », endommage activement le système. Ces trois corrections visent les causes les plus fréquentes de ses erreurs.

1. Mesurer l’utilisation, et non la mise en œuvre

Il est tentant d’associer un compteur au point d’entrée évident, comme l’appel à l’outil qui charge une compétence ou exécute un script. Mais les composants sont souvent consommés de manière indirecte. Si des routines automatisées se contentent de lire le fichier d’une compétence sans appeler l’outil qui le gère, un compteur de mises en œuvre indiquera zéro pour un composant qui est utilisé constamment, et l’audit le déclarera inactif.

Comptez plutôt l’effet que produit un composant en aval, et non le point d’entrée qui le déclenche. Si un rapport est utilisé, une décision, un ticket ou un fichier en aval devrait changer en conséquence ; c’est ce changement qui constitue la preuve à prendre en compte.

2. Afficher l’âge des données et respecter la fenêtre de temps

Un composant créé il y a neuf jours ne peut pas rivaliser dans une comparaison d’utilisation sur trente jours. Un audit doit indiquer jusqu’où remontent ses données et ne doit jamais porter de jugement sur quoi que ce soit antérieur à sa fenêtre d’observation. Un verdict qui ne précise pas la période couverte n’a aucune autorité réelle, et il pénalise systématiquement ce qui a été créé le plus récemment.

3. Exempter ceux dont la valeur est l’disponibilité

Certains artefacts existent pour être prêts, non pas pour être utilisés. Un guide de gestion d’incident qui n’a jamais eu lieu ne devrait pas faire l’objet d’aucune invocation. Pour ce type de document, la bonne question est de savoir s’il fonctionne encore, et non à quelle fréquence il a été consulté. En appliquant une métrique d’utilisation, on supprime précisément les éléments dont on aura besoin le jour le plus difficile. Les procédures de reprise après sinistre, les configurations de secours et les outils administratifs peu utilisés appartiennent à la même catégorie ; il convient de les tester périodiquement plutôt que de compter leurs invocations.

Le piège plus profond : des métriques qui ne peuvent que confirmer

En dehors des compteurs, il existe un problème plus fondamental. Une métrique qui ne peut évoluer que dans le sens de ce que vous avez créé n’est pas une preuve. Un audit qui ne peut jamais recommander de désactiver un processus n’est en réalité qu’un rapport d’état sous un autre nom. Avant de faire confiance aux résultats, demandez quel résultat vous amènerait à supprimer quelque chose, et vérifiez que ce résultat est réellement atteignable.

La solution : déclarer le consommateur au moment de la création de l’artefact

Le changement le plus efficace est petit. Pour chaque artefact, qu’il s’agisse d’une étape, d’une règle, d’un rapport, d’un tableau de bord ou d’une tâche, enregistrez une ligne au moment de sa création et non lors d’un audit : qui le consomme, et quel changement d’état prouve qu’il a été consommé.

Toute défaillance mentionnée ci-dessus trouve son origine dans le fait que cette question n’a pas été répondue dès le premier jour, et chaque correction a posteriori coûte plus cher que de la répondre dès le départ. Voici quelques moyens pratiques pour l’imposer :

• ajouter un champ obligatoire « consommateur » aux modèles pour de nouvelles tâches, règles et jobs planifiés
• rejeter les définitions de terminé qui ne décrivent que l’action du producteur (« tableau de bord mis à jour ») sans mentionner le destinataire (« tableau de bord visible pour l’examinateur en service »)
• pour tout élément transmis via un mécanisme de partage, de file d’attente ou de relais, ajouter une vérification du côté récepteur, et non seulement du côté émetteur

Lorsque ce champ existe, l’audit ne nécessite plus d’enquête approfondie. Il suffit de rechercher les éléments ayant une entrée « consommateur » vide ; cette liste constitue le résultat, et elle aurait pu être consultée à tout moment.

Points clés

• Les résultats sans consommateur sont invisibles par défaut, car rien ne se passe d’anormal lorsque personne ne les lit.
• Les pannes se concentrent aux points de transfert, il faut donc vérifier la livraison du côté récepteur.

Décompter les changements d’état causés par la consommation, et non par les appels à un point d’entrée.

Rapporter la fenêtre de données, sans juger les composants plus anciens qu’elle, et tester uniquement les artefacts liés à la disponibilité plutôt que de décompter leur utilisation.

Enregistrer « qui consomme ceci et comment nous le savons » lors de la création d’un artefact ; l’audit coûte alors presque rien.