Le mot informatique est défini par le dictionnaire Larousse comme « la science du traitement automatique et rationnel de l’information ».
Mon métier consiste donc à réaliser des applications dont l’objectif est de traiter automatiquement et rationnellement des informations… et à les mettre à disposition d’utilisateurs humains.
Vu comme cela, tout ne peut que bien se passer : le logiciel décharge les utilisateurs des tâches répétitives, le fait avec une rigueur exemplaire et reste bien sûr disponible H24, 7 jours sur 7.
Pour cela donc je dois recueillir des modes opératoires et les formaliser dans une application qui a pour vocation de traiter des données en évitant les opérations manuelles.
Seulement voilà, les algorithmes les plus rigoureux se heurtent souvent tant à la réalité du terrain qu’aux raisonnements parfois imprédictibles des utilisateurs.
En voici un exemple totalement imparable pour un logiciel aussi bien pensé soit-il.
Le logiciel ne connait pas les cas particuliers
Un logiciel est chargé de gérer les arrivées de collaborateurs, dès lors qu’ils apparaissent dans le système SIRH :
- Il enregistre l’utilisateur dans sa base,
- Créé un compte dans l’annuaire d’entreprise en attribuant un login unique prédictible,
- Communique au futur manager tous les éléments pour fournir les équipements et les applications nécessaires.
Bien évidemment cela se fait quelques jours en avance pour laisser le temps au manager de fournir les éléments et aux équipes de traiter le sujet et être fin prêt le jour J.
Seulement voilà, l’équipe RH n’effectue pas son travail en temps et en heure, donc pour éviter au collaborateur d’être dans l’incapacité de travailler le jour de son arrivée, l’équipe informatique créé le compte manuellement, tout à l’air de bien se passer…
Mais le logiciel sait attendre et après quelque jours l’équipe RH rattrape son retard et enclenche le process… c’est là que tout se gâte !
Quand on fixe une règle, le logiciel s’y tient
Evidemment, le compte prévu étant déjà pris, le logiciel en créé un différent, après tout le Jean Dupont créé il y a quelques jours n’est pas pour lui la même personne que celle qu’il s’apprête a créer.
Il va donc effectuer sa tâche en avertissant le manager pour un utilisateur qui n’est pas le bon.
Quand l’humain est aléatoire, le programme bug comme ils disent. Le manager va alors, suivant son humeur, perde son temps à décrire un poste pour un compte inutilisé, ou bien détecter le problème et avertir le support, qui effacera le nouveau compte.
Et bien sûr, l’automate qui ne renonce jamais créera à nouveau le compte et on repartira pour un cycle…
Dans un cas comme dans l’autre ce sera bien sûr la faute du logiciel.
Doit-on débrancher les automates ?
En arriver à cette conclusion reviendrait à remettre en cause tout l’intérêt de l’informatique dans sa définition même.
En fait, la vraie solution est d’évaluer tous les cas possibles, même les plus improbables. Il faut les inclure dans l’automatisation ou alors prévoir et documenter la procédure de traitement des exceptions.
Dans les phases de mise en œuvre, le temps nécessaire à ce genre de chose et rarement pris en compte, pour en arriver à la situation décrite ci-dessus, qui est malheureusement un cas réel…
Cet article pourrait vous intéresser :
Olivier Piochaud, PDG d’Apsynet
