L'audit est un « détecteur de problèmes »

L'objectif de l'audit (c'est-à-dire : la vérification du travail effectué par une IA distincte) n'est pas d'obtenir une approbation finale.

Voilà le point central que nous avons voulu transmettre tout au long de cette deuxième partie. L'audit n'est pas conçu comme un « rite de passage ». Il est conçu comme un « dispositif qui fait remonter les problèmes à la surface ». Ce chapitre vise à clarifier cette distinction.

Faire un audit « pour obtenir le GO » dévie de l'essentiel

Quand on entend le mot « audit », beaucoup imaginent : « Si le GO final est donné, c'est un succès. » Cette impression vient d'expériences familières — un examen réussi, une évaluation passée.

Pourtant, dans l'organisation conçue dans cette série, l'audit occupe une position légèrement différente.

Lorsque le GO devient l'objectif, la façon de mener l'audit change. Dès que l'on se demande « est-ce que ça va passer ? », l'attention se déplace : plutôt que de chercher des problèmes, on commence à négocier le seuil de tolérance (c'est-à-dire : la ligne à partir de laquelle quelque chose est considéré comme un problème). Si ce seuil est fixé trop bas, les problèmes semblent disparaître. Le GO est accordé plus facilement, mais les problèmes réels, eux, demeurent.

Un audit mené dans le bon sens fonctionne à l'inverse. La démarche n'est pas « vérifier qu'il n'y a pas de problème », mais « faire remonter tout problème existant ». Si la conception ne permet pas d'accepter qu'aucun GO ne soit donné, l'audit devient une coquille vide (c'est-à-dire : la structure formelle subsiste, mais la fonction disparaît).

Quelle différence avec la « chasse aux défauts » ?

Il convient de clarifier un point souvent confondu.

Entendre « faire remonter les problèmes » peut évoquer la chasse aux défauts — chercher les failles de quelqu'un pour le critiquer. Mais ce que vise l'audit est différent.

La chasse aux défauts met l'accent sur le fait de trouver des problèmes afin de critiquer quelqu'un ou de prouver un échec. Les problèmes trouvés servent à établir des responsabilités ou à alimenter des évaluations.

La raison pour laquelle l'audit fait remonter les problèmes est autre. Si des problèmes subsistent dans les étapes suivantes, ils génèrent des coûts plus élevés et des retours arrière plus coûteux. L'objectif est de faire remonter les problèmes tôt pour les corriger à temps. Qu'un problème remonte n'est pas la preuve d'un échec — c'est la confirmation qu'il est encore possible de le corriger maintenant.

Cette différence a un effet sur la psychologie des personnes qui font fonctionner le système. Dans une culture où « signaler un problème, c'est s'exposer aux critiques », le responsable de l'audit hésite à remonter les problèmes. Dans une conception où « remonter les problèmes, c'est le travail », le responsable de l'audit peut le faire sans hésitation. Le choix entre les deux conceptions change concrètement la qualité des informations qui remontent.

Que des remarques arrivent est le signe que l'audit fonctionne

En faisant tourner le système concrètement, nous avons vécu ceci.

Sur le livrable d'une session, l'IA chargée de l'audit a renvoyé plusieurs remarques. Au premier coup d'œil sur leur nombre, nous avons pensé : « il y a beaucoup de problèmes. » Mais en lisant chaque remarque, aucune ne pouvait être ignorée. Des écarts par rapport aux orientations définies, un manque de clarté dans l'explication de termes spécialisés, des incohérences de continuité entre chapitres précédents et suivants.

Quand nous avons comparé les livrables avant et après correction, la version corrigée était manifestement de meilleure qualité. Non pas que de nombreuses remarques signifient de nombreux problèmes : c'est parce qu'il y avait de nombreux problèmes que les remarques ont émergé.

L'audit ne crée pas les problèmes. Il fait simplement remonter ceux qui existent déjà. Zéro remarque dans un audit ne signifie pas l'absence de problèmes. Cela peut signifier que les problèmes n'ont pas été détectés.

« Que des remarques remontent » est le signe que le dispositif fonctionne normalement.

Concevoir un système qui peut avancer même quand des problèmes existent

L'inquiétude de « voir des problèmes remonter » se transforme facilement en résistance à l'idée de faire tourner l'audit. Pourtant, les problèmes existent déjà avant même qu'on les fasse remonter. Ils sont simplement invisibles.

Si l'on compare une situation où les problèmes remontent tôt à une situation où ils se manifestent tard, le coût de traitement est plus faible dans le premier cas. Plus un problème est découvert tardivement, plus l'étendue des corrections à apporter est large.

Dans la conception que nous utilisons dans ce projet, lorsque l'audit fait remonter des problèmes, ceux-ci sont présentés tels quels au responsable de l'approbation finale. Non pas « il y avait des problèmes, le GO est suspendu », mais « ces problèmes précis ont été identifiés, veuillez en juger ».

L'existence d'un problème et la décision d'avancer ou non sont traitées comme deux questions séparées. En tenant compte de l'ampleur du problème, de son urgence et de son étendue, le responsable de l'approbation finale décide : « corriger d'abord, puis avancer », « avancer tel quel » ou « suspendre pour l'instant ». Ce qui incombe à l'audit, c'est de détecter et d'enregistrer les problèmes — pas de prendre les décisions qui suivent.

Cette conception a permis au responsable de l'audit de disposer d'une structure qui le rend « à l'aise pour faire remonter » les problèmes. Il n'y a aucune raison de les dissimuler, et les faire remonter constitue à lui seul l'accomplissement du rôle.

Ce que ce chapitre retient

L'objectif de l'audit n'est pas d'obtenir une approbation finale, mais de faire remonter les problèmes à la surface.

Que des problèmes remontent n'est pas le signe d'un échec — c'est le signe que le dispositif fonctionne. À l'inverse, si zéro remarque se prolonge, c'est une raison de vérifier le paramétrage de la granularité et la façon dont l'audit opère.

L'audit n'est pas une chasse aux défauts. C'est une conception destinée à détecter les problèmes tôt et à réduire les retours arrière dans les étapes ultérieures. Le fait que remonter les problèmes constitue à lui seul l'accomplissement du rôle est la base qui empêche l'audit de devenir une coquille vide.