Je suis profondément convaincu que les êtres humains font tous des erreurs.
Certains disent que « l’erreur » est universelle et que cela s’appliquent aussi aux autres êtres vivants, à l’inanimée voire aux lois
de la nature ( ?). Ce me semble hors sujet : faire une erreur ne se comprend que par rapport à un but poursuivi : et jusqu’à présent
il semble que seuls les êtres humains ont des buts.
Dans ce qui suit il s’agit surtout d’erreurs individuelles. La questions des erreurs des « systèmes » créés par les humains
(organisations ou informatique) nécessiterait une approche différente.
Nous avons des milliards d’êtres humains qui tous les jours font chacun des centaines ou des milliers d’actions. Une proportion significative de
ces actions ont des buts (plus ou moins conscient au moment de l’action) voir plusieurs buts.
Je suis sûr que des milliards d’erreurs sont commises tous les jours.
Une question est intéressante : quel est le taux d’erreur (le nombre d’action qui ratent leur but par rapport au nombre d’action à
but) ?
Je l’estime aux alentours de 5%. Mais c’est un problème largement à préciser.
Il y a les erreurs qui n’ont un impact que temporaire. On peut imaginer que celui qui « pâtit » de l’erreur « rouspètent »
auprès de celui qui la commise (cela peut être le même) et que ce dernier « apprenne » (il ne
reproduire plus ce type d’erreur). C’est là un feed back élémentaire. Malheureusement, il n’est pas toujours opérationnel.
Il y a les cas où l’erreur « reste ». L’explication principale provient du fait que l’erreur n’est pas identifiée comme telle. Par
exemple personne n’en pâtit. Le fait que ce soit une erreur est masqué dans le flot d’activité. L’auteur de l’erreur peut en avoir conscience mais se
débrouille pour le camoufler (malfaçon). Les productions de « connaissance » (les sciences par exemple) sont sujettes à ce genre de situation.
Si l’on admet ces généralités, l’erreur est fortement répandue. Il faut en effet considérer que dans un processus classique qui enchaine
plusieurs activités, une seule erreur entraine l’erreur sur le processus.
Parfois cela a peu de conséquence : par exemple les fautes d’orthographe qui restent dans mes textes ne nuisent pas complètement à leur
intérêt.
Ce qui m’intéresse ce sont les mécanismes de correction d’erreur. On retrouve cette question dans les problèmes de transmission de données
informatiques : mais c’est un cas très spécialisé.
La première idée qui vient pour la correction d’erreur c’est la redondance. Plus précisément, c’est faire au moins 3 fois l’activité (en effet,
si l’on ne fait que 2 fois, il peut être délicat d’identifier l’activité sans erreur de l’autre). Si 2 activités donnent le même résultat (il faut
donc une activité de comparaison), il est en effet hautement improbable que ce soit celles-ci qui sont en erreur.
Cette « triplication » est lourde à gérer et très couteuse.
Une deuxième idée est l’indicateur de contrôle. C’est la clé du RIB, le bit de contrôle, c’est l’équilibre d’un bilan comptable, ce sont tous
les voyants des « tableaux de bord ».... Il s’agit de donner un moyen de contrôle rapide de l’activité : ce moyen est lui aussi le produit de l’activité. Il n’empêche que lui aussi
nécessite une activité de contrôle. Si l’indicateur de contrôle est une production complexe, sa génération peut être source d’erreur indépendamment de l’activité à laquelle elle sert d’indicateur
(le voyant ne marche plus).
Le troisième cas consiste en l’isolement d’une ou plusieurs activités de contrôle par rapport à l’activité à vérifier. On voit poindre un
phénomène exponentiel. En effet, ces activités de contrôle méritent aussi d’être contrôler et ainsi de suite…
Si on a qu’un seul contrôle, là aussi on risque le conflit entre l’activité de départ et l’activité de contrôle : laquelle
est juste ?
Strictement, une activité de contrôle ne fait que produit une alerte (« OK » ou « Pas OK »). Cette alerte doit être
« lue ».
Par rapport à un « duplication », l’activité de contrôle est plus réduite. Il ne s’agit pas de refaire l’activité mais de faire un
test (la preuve par 9 par exemple) moins couteux. Il s’ensuit que ce contrôle ne garantira pas exactement à 100%. On se débrouillera pour construire un test qui donne un bon rapport
fiabilité/cout. Il n’empêche que l’indicateur de fiabilité du test est une donnée à publier.
Dans un processus complexe qui se traduit nativement par un nombre important d’activité et une arborescence complexe de ces activités,
l’introduction de ces contrôles peut compliquer singulièrement l’affaire ! Un axe de simplification est de considérer que l’on n’a pas nécessairement à contrôler chaque activité
individuellement : un contrôle global sur tout le processus peut suffire. Cette simplification se paie par la difficulté d’analyser la source de l’erreur éventuelle.
On a vu qu’outre les activités de contrôle, il est nécessaire d’avoir au moins une activité de « prise en compte des alertes ».
La multiplication des activités de contrôle risque de noyer cette activité de prise en compte des alertes.
Cette prise en compte aboutit à 2 type de « processeur » : une machine automatique ou un être humain. Il est largement plus
économique que ce soit un être humain. En effet, c’est dans ce genre de situation qu’il a l’avantage sur la machine. Il s’agit en effet de lire l’alerte, de la comprendre, d’estimer sa gravité
vis-à-vis du processus (fout-elle tout en l’air ?), d’estimer son importance (« coût » si non correction), d’estimer le cout de la résolution (+ délai) et de décider d’une
action (corriger ou continuer).
L’être humain fait cela (avec plus ou moins de bonheur) « naturellement ». Alors que l’écriture d’algorithme pour traiter ces
situations relèvent du casse tête. On peut au mieux fournir des filtres qui traitent automatiquement les « cas fréquents ».
En effet, dans le cas où l’on veut faire quelque chose, il va falloir distinguer la correction (de l’incident) de la résolution (du problème).
La notion de fréquence intervient
On corrige un incident (un après l’autre) : une faute d’orthographe après une autre. Cela passe par une activité de correction. Elle aussi
est difficilement automatisable (le moyen pratique c’est de « refaire » après résolution du problème). En effet, si l’incident est le
produit d’un processus automatique, il est fortement probable que le même processus automatique reproduira l’incident. De plus, il vaut mieux investir sur la résolution du problème que sur une
activité automatique de correction d’incident.
La correction du problème est une approche plus globale. Il s’agit de régler « une fois pour toute » les incidents de même nature de
celui (ou du flot) qui a été détecté. C’est le genre de chose que l’on effectue au cours des recettes des systèmes.
Je crois que la correction des problèmes est impossible à automatiser. C’est une activité extrêmement complexe. Elle consiste en une analyse qui
nécessite le rapprochement entre l’incident identifier et la description du processus qui a produit l’incident. C’est un travail de manageur (pour une organisation) ou d’informaticien (pour un
système informatique).
2 métiers qui ne seront pas automatisés ?
Commentaires