Systèmes bancaires
De l’expression de besoin au go-live : où se créent les principaux risques fonctionnels
On impute souvent les incidents de production au code. Pourtant, en remontant la chaîne, la cause se situe fréquemment en amont : une exigence ambiguë, une règle implicite, un cas limite jamais formulé. Le risque fonctionnel se crée tôt et se paie tard.
L’ambiguïté de l’expression de besoin
Une exigence formulée en langage métier laisse souvent place à plusieurs interprétations techniques. Chaque interprétation non levée devient une hypothèse silencieuse — et une anomalie potentielle. Nommer explicitement ces zones grises au moment du cadrage coûte quelques heures ; les découvrir en recette coûte des semaines.
Les règles implicites
Dans la banque, beaucoup de règles « vont de soi » pour les experts métier et restent invisibles dans les spécifications. Ce sont elles qui ressurgissent au pire moment. Le travail de l’analyste consiste précisément à rendre explicite ce qui est tenu pour évident.
Les cas limites oubliés
Devises exotiques, arrêtés comptables, opérations annulées puis rejouées : les cas limites sont rarement décrits, souvent mal testés, et presque toujours à l’origine des incidents les plus visibles. Les anticiper dès la conception fonctionnelle est plus efficace que de les corriger après coup.
La continuité comme garde-fou
Le meilleur antidote au risque fonctionnel est la continuité : la même exigence cadrée, spécifiée, testée et validée par une chaîne de responsabilité ininterrompue. C’est précisément ce que perd une organisation qui multiplie les intermédiaires entre le métier et la livraison.