Peut-être est-ce du à notre enfance bercée par les histoires racontées avant de s’endormir, toujours est-il que nous appréhendons la réalité à l’aide d’histoires, de scénarii.
Quand on spécifie un système informatique, il s’agit des “use cases“, histoires racontant ce qui se passe concrètement quand l’utilisateur fait telle ou telle action. La liste des uses cases permet d’avoir une vision d’ensemble, macro, des fonctionnalités que doit remplir le système. C’est là que ça se gâte. D’abord parce qu’on est réduit à avoir recours à un formalisme abscons (extension, héritage, inclusion,…) parce que l’utilisateur peut vouloir parcourir le système en suivant des voies diverses. Les décrire toutes est impossible. S’en tenir aux use cases identifiés est réducteur. Ensuite, on se rend bien compte que cette description, bien pratique sous l’angle contractuel ou de la rédaction des tests, pêche dès qu’il s’agit de rendre la complexité du métier. On ajoute alors des “business rules”, des renvois sans fin et le document devient illisible.
Quand on gère un projet, on cherche à gérer les risques. Les identifier, les anticiper, prendre des actions préventives. Pour gérer les risques, il faut les identifier. On se fait donc une image mentale du système, on essaie de dérouler tout ce qui peut se passer (utilisation normale, intrusion, crash système, incident d’exploitation, …). On affecte ensuite une probabilité à l’incident (celle que la salle machine soit détruite par une explosion nucléaire est faible par exemple). Si l’incident est jugé probable, on construit un nouveau scénario incluant le fruit d’actions préventives. La difficulté de cet exercice, c’est de savoir jusqu’où allé, ce que l’on gère et ce sur quoi on fait l’impasse. L’autre difficulté c’est l’exhaustivité. Penser à tout. C’est un réel travail de créativité, qui gagnera beaucoup à être réalisé en groupe. Malheureusement, la mise en situation étant relative, nous avons tendance à “découvrir” des problèmes au dernier moment, alors qu’il est trop tard…