Pour une validation authentique

19 mai 2000

Avez-vous vu comment se passe la validation des spécifications générales (ou encore "fonctionnelles") d'un système d'information ?

Les spécifications générales sont un document que le client ("maître d'ouvrage") fournit au maître d'œuvre, et qui indique à celui-ci très exactement ce que doit faire l'outil informatique qu'on lui demande de réaliser. 

Si le maître d'ouvrage utilise les méthodes les plus récentes, il aura modélisé son activité en utilisant le modèle UML ("Unified Modeling Language", voir "Le langage UML"). 

Le modèle UML décrit la façon dont le système d'information va s'articuler avec les processus professionnels qu'il équipe. Si l'on pense, comme la plupart des dirigeants, que le SI est "stratégique", il faut en tirer une conclusion pratique immédiate : l'adéquation du modèle au métier est un enjeu d'importance. Lorsque l'on prépare le modèle, on l'adapte aux besoins des utilisateurs en associant ceux-ci à sa conception (des "experts métiers" venus du terrain participent à l'équipe de modélisation) ; mais il faut vérifier par ailleurs que la représentation du métier fournie par le modèle est conforme à la stratégie de l'entreprise, c'est-à-dire à son positionnement sur le marché, à ses méthodes de gestion, à ses projets, en un mot à sa "personnalité". Cette vérification doit être faite par les stratèges eux-mêmes, par les dirigeants (PDG, DG, DGA, directeurs etc.) C'est cette vérification que l'on appelle "validation".

Cependant les choses se passent souvent de la façon suivante :

- le modèle prend la forme d'un classeur de quelques centaines de pages, hérissé de graphiques et d'acronymes, rédigé dans le français particulier à l'informatique (où tout texte est un "livrable", tout donneur d'ordre un "commanditaire", toute méthode une "méthodologie", tout problème une "problématique" etc., voir "Crise du langage"). Le décideur y trouve divers types de diagrammes : de classes, de cas d'utilisation, de séquences, d'interaction, d'activité, d'état, de composants, de déploiement etc. Ni les cases, ni les flèches de ces diagrammes ne peuvent être compris par quelqu'un qui n'en a pas acquis l'habitude. 

- on donne le modèle au dirigeant le vendredi en lui demandant de l'avoir validé le lundi, parce que l'on a pris du retard et qu'il faut qu'il signe vite. 

- les techniciens se disent in petto avec malice " Perrin Dandin, tu as voulu être dirigeant ; eh bien si tu veux comprendre, tâche moyen d'y passer ton week-end et bonne chance !"

- le dirigeant signe, parce que (1) il ne veut pas être celui qui ralentit la procédure, (2) il ne veut pas avouer qu'il n'y comprend rien. Tout au plus posera-t-il une question de détail pour faire preuve de vigilance. 

- les équipes se mettent au travail en se fondant sur les spécifications ainsi "validées", passent aux spécifications détaillées, puis aux spécifications techniques, à la réalisation, aux tests, à la recette, au site pilote, au déploiement ... et alors le dirigeant constate, quelques mois après la "validation", que le produit n'est pas conforme à la stratégie de l'entreprise. Alors il faudra soit admettre que la stratégie boîte parce qu'elle est mal outillée, soit tout refaire à grands frais. 

Plusieurs choses sont choquantes dans ce scénario. 
- D'abord, le mépris avec lequel les techniciens traitent le dirigeant. Ce mépris ne s'exprime pas par des paroles insultantes et il peut même s'accommoder de l'obséquiosité. Mais l'une des pires insultes que l'on puisse adresser à un être humain, c'est de lui donner un travail que l'on sait impossible en le défiant de révéler son incompétence. 
- Ensuite, la faiblesse du dirigeant qui n'ose pas protester et accepte de galvauder sa signature en l'appliquant à des documents qu'il n'a pas compris. 
- Enfin, la conception de l'entreprise qui sous-tend ce processus : la validation, lorsqu'elle est de pure forme, ne représente rien de sincère et n'engage personne.

Une validation authentique, c'est la validation d'un document que le dirigeant peut lire et comprendre ; il peut en demander la correction s'il lui semble ne pas correspondre à la stratégie de l'entreprise (c'est là que réside la valeur ajoutée de la validation) ; il y apposera une signature par laquelle il se sentira engagé. Alors le risque d'une inadaptation du processus à la stratégie est réduit ainsi que le risque d'un désaveu ultérieur de la validation.

Il faut donc trouver le moyen, lorsque l'on a en mains un modèle UML, de le transcrire en un texte qui le représentera fidèlement tout en étant lisible par le dirigeant. L'exercice n'est pas facile mais il est possible. Je propose que l'on procède de la façon suivante :
- rédiger une synthèse en français, sur quatre ou cinq pages, expliquant (1) ce que l'on a voulu modéliser, (2) la façon dont on s'y est pris, (3) les modifications que l'on a apportées au processus en le modélisant, (4) les choix que l'on a fait, (5) les questions qui ont été laissées pendantes par souci de simplicité ;
- faire valider la fidélité de cette synthèse par une personne qui connaît parfaitement le modèle (le "vérificateur" ; il est préférable que le vérificateur ne soit pas la même personne que le responsable du modèle car il est difficile, pour celui qui a supervisé les détails d'une production technique, d'en vérifier une présentation synthétique) ;
- présenter les cases sur lesquelles doivent figurer les signatures de la façon suivante :

Le "modèle", c'est alors l'ensemble constitué par le modèle formel et la synthèse. Le modèle formel est signé par le responsable du modèle et par le vérificateur ; la synthèse est signée par le vérificateur et par le dirigeant. On communique au dirigeant la synthèse et le modèle formel. Il peut se reporter à ce dernier s'il veut voir un détail, mais il ne signe que la synthèse, seul document qu'il sera censé avoir lu et qui l'engagera.