Les scénarios qui tuent un projet SI après la mise en prod (et qu'on oublie de cartographier avant)

Le scénario nominal est un mensonge confortable

Quand on rédige des spécifications, on décrit naturellement ce qui se passe quand tout se passe bien. Le client passe commande, la commande est traitée, la facture est émise, le client paie. Ce flux est propre, linéaire, facile à modéliser. Il est aussi rare. Le quotidien opérationnel des équipes ressemble très peu au scénario nominal qu'elles auraient décrit si on les avait interrogées sur leur processus idéal.

Les scénarios non nominaux, c'est tout ce qui s'écarte de ce flux propre : le client modifie sa commande après validation, un produit est en rupture partielle, une règle réglementaire s'applique différemment selon la localisation du client, deux opérations se déclenchent simultanément sur le même contrat, un tiers externe retarde une étape intermédiaire. Ces cas représentent rarement la majorité des transactions en volume. Ils concentrent pourtant la majorité des bugs qui remontent en production, parce que personne n'avait pensé à les mettre dans les specs.

Le problème n'est pas que les équipes métier ignorent ces cas. Elles les vivent tous les jours. Le problème est qu'on ne leur pose pas les bonnes questions pendant le cadrage. On leur demande « comment fonctionne votre processus de facturation ? » et ils décrivent le scénario nominal. On devrait leur demander « quelle est la situation la plus compliquée que vous ayez traitée ce mois-ci ? » et « qu'est-ce qui arrive quand ça ne se passe pas comme prévu ? ». Ce sont des questions très différentes, et elles font remonter une matière complètement différente.

Ce qui se passe quand les cas particuliers arrivent en production

Le premier scénario non nominal qui arrive en production après une mise en service est toujours une surprise. L'équipe technique n'avait pas prévu ce cas. Le modèle de données ne gère pas la situation. L'interface affiche un message d'erreur que l'utilisateur ne comprend pas, ou pire, enregistre silencieusement une donnée incorrecte. L'équipe commence à chercher d'où vient le problème. Elle met en général deux à trois jours pour le reproduire, l'identifier et trouver une correction. Elle déploie un correctif. Deux semaines plus tard, un deuxième scénario non nominal arrive, différent du premier mais du même type. Même diagnostic, même délai.

Ce cycle de bugfixing post-production est extrêmement coûteux. Pas seulement en temps de développement : en confiance des équipes dans le système, en risque d'erreurs de données qui contaminent d'autres processus, et en décisions prises sur des données incorrectes avant que le bug soit détecté. Dans les secteurs où les données alimentent directement la facturation ou le reporting groupe, un scénario non nominal non géré peut avoir des conséquences bien au-delà du bug lui-même.

« Derrière le scénario nominal, du fait d'un métier très technique, il y avait un certain nombre de scénarios qui arrivaient de manière plus aléatoire — et ça, ça a amené pas mal d'allers-retours. »

Dans ce cas, le secteur de l'énergie générait des scénarios non nominaux nombreux : règles spécifiques à l'injection et au soutirage, dépendances aux référentiels Enedis, calculs de TURPE qui s'appliquaient différemment selon la configuration du point de livraison. Ces scénarios étaient connus des équipes métier qui les géraient informellement depuis des années. Ils n'avaient jamais été formalisés, et donc jamais anticipés dans les specs initiales. Les cartographier pendant le cadrage a conduit à des allers-retours avec les équipes, mais ces allers-retours ont eu lieu au bon moment : avant que du code soit écrit sur une hypothèse incorrecte.

Comment cartographier les scénarios non nominaux en amont

La méthode n'est pas de demander aux équipes de lister leurs exceptions.Elles n'en sont pas capables spontanément. Les exceptions font partie de leur quotidien au point qu'elles ne les identifient plus comme des exceptions. Elles les gèrent par réflexe, par habitude, par contournement informel. Ce qui est perçu comme normal en interne est souvent ce qui sera le plus difficile à gérer pour un système informatique.

La méthode efficace est de construire le scénario nominal en détail avec les équipes, puis de le soumettre à des cas limites systématiquement. On commence par le flux standard et on demande, étape par étape : que se passe-t-il si l'étape précédente n'a pas pu se faire ? Que se passe-t-il si deux événements arrivent simultanément sur cet objet ? Que se passe-t-il si une donnée d'entrée est manquante ou erronée ? Que se passe-t-il si une règle réglementaire externe change d'état pendant le traitement ?Chaque réponse est un scénario non nominal à documenter et à modéliser.

L'énergie comme cas d'école

Le secteur de l'énergie illustre bien la densité de scénarios non nominaux que peut générer un métier à forte composante réglementaire. La facturation d'un contrat de fourniture d'énergie suit un processus nominal simple en apparence. Mais dès qu'on s'intéresse aux cas particuliers, la complexité explose : un point de livraison peut basculer entre injection et soutirage selon les conditions météorologiques, une règle de calcul TURPE s'applique différemment selon la puissance souscrite, un client peut avoir plusieurs contrats sur des points de livraison distincts avec des règles différentes pour chacun. Aucune de ces situations n'est rare. Elles représentent une part significative du quotidien opérationnel des équipes.

La même logique s'applique dans des secteurs très différents : dans l'agroalimentaire, les scénarios de non-conformité et de traçabilité génèrent des cas particuliers qui ne figurent jamais dans les specs initiales. Dans les services B2B à contrats récurrents, les avenants, les modifications en cours de contrat, les résiliations partielles créent des situations que le scénario nominal ignore complètement.

Pour comprendre comment la modélisation BPMN et le travail sur le modèle de données permettent de rendre ces scénarios explicites avant le code : note de cadrage pour moderniser son SI en PME.

Ce que ça coûte de ne pas le faire (et pourquoi l'investissement se rentabilise toujours)

Un scénario non nominal traité pendant le cadrage prend quelques heures de modélisation. Le même scénario traité après la mise en production suppose un cycle complet : bug constaté, reproductible, diagnostiqué, corrigé, testé en régression, déployé. On parle de deux à cinq jours de travail par scénario, selon la complexité et les interdépendances avec d'autres modules. Sur un projet de taille modeste avec une dizaine de scénarios non nominaux non anticipés, le surcoût post-production représente entre deux et six semaines de développement supplémentaires qui n'étaient pas budgétées.

La résistance à investir dans la cartographie des scénarios non nominaux vient généralement de deux endroits. Le premier est la pression sur le délai : on veut commencer à coder vite, et le cadrage semble retarder ce moment. Le deuxième est l'illusion de complétude des specs initiales : les équipes métier ont décrit leur processus, les développeurs ont posé des questions, tout semble couvert. Ce sentiment de complétude est trompeur précisément parce que les scénarios non nominaux ne remontent pas spontanément dans ce type d'échange.

La cartographie des scénarios non nominaux n'est pas un luxe de projet bien géré. C'est la condition pour que le scénario nominal, une fois en production, fonctionne dans un environnement réel plutôt que dans les conditions idéales du test. Un système qui gère correctement ses cas particuliers est un système qui gagne la confiance des équipes qui l'utilisent. Un système qui bugue sur les exceptions est un système que les équipes contournent, ce qui reproduit exactement les problèmes d'informel que le projet était censé résoudre. Pour voir comment éviter ce type de régression : ce que les freelances ne livrent pas par défaut (et ce que ça coûte).