Rien de tel qu’un mauvais processus de gestion des faits techniques pour ruiner un projet. Or, le monde est scindé en deux catégories étanches : ceux qui ont vu la Vierge (ou Ganesha, ou Raël), et ceux qui se sentent concernés par leur emploi. Généralement, ce sont les premiers qui ont pour charge de poser les fondations qui permettront à l’immense majorité que consitituent les seconds de travailler. Le processus de gestion des faits techniques en fait partie. Ce sont également les premiers qui ne comprennent pas que le doute soit permis quand une correction est proposée.
Petite expérience récente : prenez un processus de gestion des faits techniques qui ne permette pas de se tromper. Exemple : s’il existe une production officielle intégrant une proposition de correction pour un fait technique donné, alors ce fait technique doit être dans un état dont le nom peut varier mais souvent évocateur : clos, fermé, réglé, terminé, effacé ou encore abattu. Notez bien l’inversion de la relation de causalité : « j’ai une tentative de correction, c’est donc que le problème est réglé ». Si, par un étrange coup du sort, votre équipe ne contenait pas que des développeurs capables de produire 100.000 lignes d’assembleur sans bogue (ce qui serait très étonnant dans notre monde de l’ultra-performance), vous voilà bien.
Perrin vient vers vous avec son correctif pour le fait technique 12327, il a remplacé le signe ‘-’ par le signe ‘^’ dans la fonction qui doit couvrir l’exigence PQ-3265.b : « Étant donné les constantes K_TRUC et K_MACHIN dont les valeurs sont précisées en annexe B.3, le système doit fournir le résultat de leur multiplication à l’utilisateur, conformément à la norme IEEE-754 par temps de pluie ». Perrin est vaseux. Il s’est couché tard pour avoir voulu assister à la finale de « La maison des secrets ». C’est bien Léo, Académicien de 23 ans, qui a gagné le concours d’ingestion de gaspacho. Perrin est soulagé, mais fatigué. Malgré tout, c’est jour de livraison. Et oui, on livre tous les jours désormais. Quand ce n’est pas au client, c’est à la qualité, ou à l’équipe système, ou au restaurateur du site. Alors vous imaginez bien : la production sort, elle est fournie avec force bolduc à son destinataire, le FT 12327 est mort et enterré, on passe tous à autre chose.
Sauf que… le problème initial n’est pas si bien corrigé que ça. Que faire ? Le processus ne permet pas de rouvrir le FT 12327, d’autant plus qu’il a été livré au client. Et puis on ne va pas avoir tort quand même, surtout si c’est patent, vu que c’est le client lui-même qui s’est rendu compte que le dit problème n’était pas franchement corrigé. Alors on va ouvrir un autre fait technique, le 24055 (oui, en deux jours, on peut en trouver des problèmes vous savez). S’enclenchent alors la double-comptabilité et le dialogue de sourds. « Le FT12327 a été corrigé, le problème dont vous me parlez c’est le FT24055″. Et puis, songez que si vous êtes payé au fait technique corrigé, c’est extrêmement juteux, puisque le FT12327 est effectivement clos, tout le monde pourra le vérifier. Les indicateurs sont impitoyables.
Il ne faut jamais confondre intégration de correctif et validation fonctionnelle associée.
Ce n’est pas parce qu’une tentative de correction existe que le problème est dissout. Tout le monde peut se tromper, y compris en corrigeant un problème. Il faut donc se méfier d’une correction non testée. Les effets de bord, ça existe. Mais c’est là que le bât blesse : à vouloir parler vite, on utilise des formules courtes qui occultent la réalité des choses. Ce que l’on appelle au quotidien « une correction » n’est jamais qu’une proposition. Ce simple oubli a de vastes conséquences et est source de problèmes multiples : incompréhension, excès de confiance, puis atteinte de la fierté de celui qui propose une correction incomplète ou ratée, bref, de l’effet Joule à tire-l’arigot.
Je ne crois pas non plus qu’on puisse toujours éviter les doublons dans une base de fait technique. « Oui, je connais ce problème, on l’a vu il y a trois mois, c’est amusant qu’il ressurgisse. Si je me souviens bien, c’est le FT 504″. Un bon processus de gestion des faits techniques doit pouvoir permettre d’en rouvrir, ne serait-ce parce que c’est admettre qu’on peut se tromper. Ça évitera quelques doublons et facilitera bon nombre de communications. À l’inverse, interdire la réouverture force à dupliquer les problèmes et pousse inexorablement à une confiance excessive et aux conversations de type bingo « Le 17542 ? Non, tu dois vouloir parler du 18309. Ou le 18776 peut-être ? »
Mais ça se saurait aussi si les fidèles de Marie lisaient ces lignes.