Pourquoi l’expression des besoins est-elle un des métiers les plus difficiles au monde ? Pourquoi est-ce un métier créatif ? Et pourquoi est-ce un métier de bâtisseurs alors qu’on exprime les besoins et non la solution ? Démonstration par l’exemple …

Rappelons très brièvement les quatre activités utiles à l’expression des besoins et à l’élaboration d’un cahier des charges :

1.  Recueillir les besoins (activité appelée « recueil » ou « élicitation »),

2.  Traduire les besoins en exigences (l’analyse),

3.  Spécifier les exigences dans un cahier des charges (la spécification),

4.  Mettre tout le monde d’accord sur les exigences (la validation).

Pour mener à bien ces activités, nous disposons d’une large gamme d’outils, de techniques et de méthodes. Mais l’outil absolument indispensable est une tête bien faite avec une forte capacité d’analyse. Ce n’est sans doute pas pour rien que les personnes chargées de ces activités s’appellent en anglais business analysts, et en français analystes métier ou analystes d’affaires.

Ceux qui continuent à nous appeler « assistants à la maîtrise d’ouvrage » n’ont pas compris que la business analysis est un métier qui exige de conseiller son client (et pas simplement de l’assister). Et aussi d’apporter du neuf. Car si la capacité d’analyse est nécessaire, la créativité l’est presque autant.

Mais, me direz-vous, la créativité pour créer quoi ? J’écoute les besoins, ou je les recherche parmi des centaines de pages de documentation, je les traduis dans un langage plus formel, et je les rédige sous forme d’exigences. Le texte ainsi constitué s’appelle un cahier des charges. A-t-on besoin de tant de créativité que ça alors qu’il ne s’agit que de traduire et rédiger ?

En plus de ça, me direz-vous, nous ne sommes pas encore au stade de la conception. Nous n’avons pas à construire une solution, juste à exprimer des besoins.

Il s’agit bien, pourtant, d’une activité de création. Et même d’un métier de bâtisseurs.

En effet, une combinaison d’exigences (règles métier, exigences métier, contraintes techniques) peut donner naissance à de nouvelles exigences, jamais formulées comme telles, et jamais imaginées auparavant. C’est là qu’intervient la créativité. Je précise que je parle ici de créativité opérationnelle, et non de créativité artistique. De plus, cette créativité est collective, car elle fait intervenir toutes les parties prenantes, et une des tâches de l’analyste est de gérer cette créativité de groupe quand elle s’assoupit, ou au contraire quand elle devient foisonnante.

Prenons un exemple qui illustre les joies et les difficultés de l’analyse …

Supposons que vous soyez un constructeur automobile. Vous me demandez d’élaborer un cahier des charges pour un logiciel « pilote automatique » qui sera embarqué dans le prochain modèle d’automobile. Quelle est ma mission ? Je dois expliciter les besoins utilisateur. Je dois également mettre au jour des contraintes qui découlent des règles métier. Dans notre cas, le référentiel incontournable de règles métier est le code de la route. Chaque article de loi constitue potentiellement une règle métier, qu’il suffira de traduire en exigence.

Alors prenons un article de loi et voyons ce que nous pourrons faire avec …

Article R412-31 du code de la route

Tout conducteur doit marquer l’arrêt devant un feu de signalisation jaune fixe, sauf dans le cas où, lors de l’allumage dudit feu, le conducteur ne peut plus arrêter son véhicule dans des conditions de sécurité suffisantes.

C’est clair, n’est-ce pas ? Relisez lentement l’article en vous mettant à la place du conducteur, comme si vous n’aviez jamais conduit un véhicule.

Il s’agit dans un premier temps de comprendre et de mettre en cohérence le vocabulaire. Le « feu de signalisation jaune » est ce que vous et moi appelons vulgairement un feu orange. Il est « fixe » par opposition à l’orange clignotant qui, lui, ne vous oblige pas à marquer l’arrêt. Le législateur voit jaune ce que l’automobiliste voit orange. Ça commence bien ! Bienvenue dans le monde coloré de la « business analysis » !

Continuons l’analyse …

La loi stipule que « tout conducteur doit marquer l’arrêt ». Est-ce le conducteur qui marque l’arrêt, ou bien le véhicule ? Après analyse on comprend que le texte sous-entend le couple conducteur-véhicule, représenté par « le conducteur », responsable, devant la loi, du comportement de son véhicule (en cas de défaillance de celui-ci, il pourra se retourner contre le constructeur automobile, mais ceci est une autre histoire).

Après cela, la loi nous donne une condition de déclenchement de l’action : « lors de l’allumage dudit feu ». C’est magnifique ! Pile lorsque le feu s’allume, le conducteur (ou le système embarqué qui le remplace) devra décider s’il « ne peut plus », selon des critères à déterminer, arrêter son véhicule. Il faudra traduire tout ça en exigences fonctionnelles et non-fonctionnelles. Rappelons que tout cela n’est (en principe) pas le travail du concepteur, mais d’un groupe de travail animé par l’analyste métier.

Last but not least, l’article de loi fait référence à des conditions de sécurité « suffisantes ». Qu’est-ce qu’une condition de sécurité suffisante ? Suffisante pour qui ? Suffisante à quoi ? L’interprétation de ce seul adjectif fera émerger des exigences qui n’avaient jamais existé auparavant. Des dizaines, des centaines, voire milliers d’exigences logicielles, qui tiendront compte de contraintes aussi diverses que le code de la route, la psychologie du comportement des piétons, l’adhérence du caoutchouc sur le goudron humide, ou la mécanique des freins à disque.

Et ce n’était là qu’un échantillon de trois lignes de code de la route. Alors imaginez la suite …

Certes, nous sommes là pour exprimer des besoins et des contraintes, et non pour concevoir une solution. Mais je persiste. Il s’agit bien d’un métier de bâtisseurs.

 © Yves Constantinidis, 2022