La qualification des incidents informatiques

Transformation numérique ou pas, n'oublions pas que la validation (l'homologation) des applications est un des principaux aspects des projets informatiques alors que beaucoup ne considère pas cela comme une tâche noble. Les développeurs et les architectes techniques ou ingénieurs systèmes sont égocentriques et dénigrent les autres, notamment les lascars comme moi qui font du transverses et de l'avant projet, et les homologateurs. 

Pourtant, l'homologation est essentielle. Outre le fait que c'est elle qui permet de donner le top à la diffusion d'un logiciel sans dommage pour les utilisateurs donc l'entreprise (elle intéresse beaucoup les dirigeants que le reste...), c'est avec elle qu'on mettra en confrontation les différentes applications du Système d'Information. 

Cela étant, les homogateurs ne sont pas parfaits. Ils appliquent des "procédures systématiques" sans trop comprendre ce qu'ils font. 

Prenons un exemple : les homologateurs de l'Apple Store doivent s'assurer que les applications ne font pas de mal aux gens qui vont la télécharger, donc aux smartphones et à l'image du produit et de la marque. Si vous faites une application pour noter les brasseries parisienne, l'homologation ne saura pas ce qu'est une brasserie et ne connaîtra pas les serveurs informatiques (pas des brasseries...) concernées par votre appli. Il applique son protocole de tests. 

Dans la vraie vie, c'est pareil. Du moins dans l'informatique en entreprise.  Récemment, j'ai eu des problèmes en traitant un incident signalé par un homologateur qui est arrivé dans ma boîte mail par erreur (en principe, j'interviens uniquement dans les cas désespérés). Alors j'ai fait un sondage sur une cinquantaine d'incidents : la plupart sont très mal rédigés et très mal qualifiés. 

Outre son titre, l'incident a trois "atteints essentiels" : 

- sa description,

- sa gravité,

- son urgence. 

Prenons un exemple dans la vraie vraie vie : un type qui doit vérifier si les ascenseur d'un immeuble fonctionne. 

Première bug détecté : l'ascenseur ne s'arrête pas toujours au bon étage. L'incident est gênant mais rigolo. Sa résolution est urgente parce que les utilisateurs vont gueuler. L'homologateur va qualifier l'incident de bloquant (parce que l'ascenseur ne répond pas à ce pour ce qu'il est conçu) mais pas urgent (l'utilisateur peut toujours changer d'étage). Il a tout faux : l'incident n'est pas bloquant (l'utilisateur peut toujours changer d'usage) mais urgent (la société l'ayant installé va se retrouver avec des indemnités à payer). 

La différence entre la gravité (peut-on continuer avec le produit ?) et l'urgence (faut-il une réparation immédiate ?) est très difficile à faire. 

Deuxième exemple : l'homologateur assiste à cent utilisations de l'ascenseur. Au centième, le hasard, l'ascenseur se bloque avec un type dedans. Je vous laisse définir la gravité et l'urgence et vous présente ma réponse : bah ! Ça arrive à tout ascenseur de se bloquer et c'est l'occasion de vérifier que les procédures de sécurité fonctionnent... Donc l'incident n'est pas grave (tout asceur peut tomber en panne) et la résolution n'est pas urgente (pour la même raison). Mais...

Outre le fait qu'un type soit coincé dans le machin et qu'il fait le libérer en urgence (mais nous sommes hors "problématique" de l'homologation), l'homologateur ne peut plus poursuivre ses tests. Pour lui, c'est bloquant. Il ne peut plus faire son boulot. L'homologation est bloquée. 

Troisième urgence : l'ascenseur d'une maison de retraite tombe en panne deux fois par semaine sans que personne ne soit coincé. L'incident est bloquant : l'ascenseur ne remplit pas ses fonctions et les petits vieux ne peuvent pas descendre au réfectoire. Et l'urgence ? Cela dépend si l'établissement a un deuxième ascenseur. Dans ce cas, il n'y pas d'urgence (à part le fait que les réparations coûtent de l'oseille). Par contre, si c'est l'unique ascenseur d'un lycée qui a ce problème. Ce n'est pas bloquant. Les gamins peuvent aller en cours. Par contre, c'est urgent : les PMR (traduire par "handicapés") ne peuvent pas y aller facilement. Ainsi la qualification d'un incident dépend des circonstances. 

C'est un peu ce qui motive mon billet. Un homologateur a signalé un incident comme étant gênant, aujourd'hui, presque fier de lui pour nous mettre en défaut, en ne tenant pas compte des circonstances. Il n'est même pas urgent. Par contre, si on l'avait constaté en septembre, il serait devenu à la fois bloquant (on ne peut pas déployer l'application) et urgent (le blocage nous empêche de passer à la phase suivante du projet). Ainsi, un incident qui peut être qualifié de mineur aujourd'hui (sa correction est simple) et "pas urgent" (on peut attendre septembre) peut changer de statuts au cours du cycle de vie d'une application. 

Mais c'est surtout la façon dont l'homologateur va rédiger son incident qui motive ce billet. 

Changeons de vraie vie. Notre homologateur change de métier et doit vérifier que la température de la bière dans les bistros aux lumières d'un brasseur (mettons Kronembourg). Dans un, il constate que la bière est trop chaude. Notons que l'incident est mineur : il suffit de régler le thermostat (mais pourrait devenir grave si le système de réfrigération est HS). Il est urgent : les clients ne sont pas satisfaits. 

L'homologateur va donc rédiger une fiche d'incident. Vous et moi écriverions : "la bière est trop chaude, ça fait chier". 

L'homologateur écrira :

"Thermomètre introduit dans le verre.

Résultat attendu : entre 4 et 8 degrés.

Résultat obtenu : 9 degrés". 

Le lecteur doit donc relire deux fois pour comprendre que la bière est trop chaude. 

Ne rigolez pas, c'est ainsi. J'ai étudié des dizaines de fiches aujourd'hui pour tester. 

Et en plus, l'homologateur a besoin d'un thermomètre pour savoir si une bière est à la bonne température et n'a pas le droit de consommer le produit.