Le fameux « ça dépend », combien de fois ai-je entendu cette réponse en tentant d’obtenir d’un client une règle de gestion !
Ma question était pourtant simple : « Selon les données que vous me fournissez, quelles sont les différentes règles à appliquer pour obtenir le résultat escompté ? ». L’objectif est bien sûr de mettre en œuvre, dans un logiciel, l’application automatisée de ces règles.

Dès lors que le traitement devient un peu complexe, impliquant différents cas de figure et des exceptions, il devient nécessaire d’entamer une réflexion pour décrire l’ensemble des possibilités. Pour atteindre cet objectif, il existe traditionnellement deux approches :

L’approche par l’exemple ou la généralisation des cas particuliers

La plus classique consiste à énumérer des exemples. Vous recevez ainsi un ensemble de cas concrets qui, pris individuellement, font sens. Cependant, la litanie peut devenir longue et être rapidement agrémentée de commentaires tels que « sauf si » ou « ça dépend de ». Non seulement vous risquez d’oublier certains cas, mais ce système est fastidieux à mettre en œuvre. En effet, cela implique d’énumérer tous les ensembles de cas, ce qui devient vite exponentiel dès lors que plusieurs niveaux de conditions sont imbriqués.
Pour certains, c’est le seul mode de raisonnement possible. Dans ce cas, la meilleure solution est de demander : « Pouvez-vous définir le cas le plus fréquent et son contexte d’application ? Nous traiterons ensuite les exceptions. »
L’avantage est de permettre d’avancer rapidement, et surtout d’être évolutif dans la découverte des conditions d’exception, tout en rappelant qu’une exception doit rester minoritaire dans son application ; sinon, elle devient une généralité.

L’approche par modélisation ou du général au particulier

Dans ce cas, on s’appuie sur un modèle théorique défini en amont, qui a vocation à traiter tous les cas. Une fois mis en œuvre, ce modèle révèle les cas particuliers à traiter en proposant une solution en échec qu’il faudra détecter et traiter de manière spécifique.
Cette phase de mise au point est souvent délicate, car elle nécessite la compréhension des conditions menant à l’échec, ainsi qu’une justification et un processus d’intervention bien défini, étant donné que, par définition, l’échec est imprévu. Néanmoins, on dispose rapidement d’une solution opérationnelle qui saura rester adaptative, y compris en cas de changement de contexte.

Concrètement, qu’est-ce que cela donne ?

Prenons un exemple simple : je veux gérer, par la communication entre une DSI et une DRH, un processus fiable des entrées et sorties du personnel dans le SI.
Une première approche consiste à définir les cas d’usage à partir de l’expérience d’un acteur, mais on risque alors d’oublier les cas peu fréquents. C’est ainsi que j’ai vu des pigistes entrer et sortir 20 fois dans l’année ou des élus d’une collectivité locale être expulsés sans ménagement du SI.
À l’inverse, partir des définitions connues de la DRH, y ajouter celles spécifiques à une DSI, puis valider les données nécessaires et leur signification semble plus approprié. Il restera à envisager les changements de catégorie ou l’intégration d’une autre organisation avec un vocabulaire différent, mais c’est une autre histoire.
Vous l’aurez compris, je préfère la seconde approche, car elle permet de poser le sujet et d’éviter de devoir assembler la voiture alors qu’elle roule déjà…

Olivier Piochaud, Président Directeur Général d’Apsynet