Comment cadrer un logiciel métier avant d’écrire la première ligne de code

On demande souvent quelle stack choisir. Next.js, .NET, une base relationnelle, un outil low-code. La question arrive trop tôt. Tant que l’on ne sait pas qui utilise le système, ce qu’une personne essaie d’achever, et ce qui se passe quand le cas habituel ne tient pas, la technologie n’a rien à trancher.

Le cadrage sert à ça. Pas à produire un document que personne ne relira. À obtenir une compréhension assez précise pour que le premier incrément soit utile, et pour que les choix d’architecture découlent de contraintes réelles.

Commencer par le processus réel

La procédure écrite et le travail réel divergent presque toujours. Le manuel dit qu’une demande est validée dans l’outil. En pratique, la validation part par e-mail, un tableur suit les exceptions, et une personne « sait » quels dossiers peuvent passer sans la pièce manquante.

Parler aux utilisateurs ne suffit pas s’ils racontent le processus idéal. Il faut observer une opération complète : une commande, un dossier, une intervention, une clôture. Qui ouvre, qui complète, qui bloque, qui relance, et où l’information est recopiée.

Les écarts intéressants sont concrets. Un champ obligatoire que tout le monde contourne. Un statut qui ne correspond à aucune décision. Une liste exportée chaque matin parce que l’écran ne permet pas de filtrer. Ces contournements ne sont pas de la mauvaise volonté. Ce sont les spécifications que le système actuel n’a pas su porter.

Définir le problème avant la solution

Une demande arrive souvent déjà traduite en fonctionnalités. « Il nous faut un portail », « un workflow », « une application mobile ». Si l’on accepte cette traduction trop vite, on construit l’écran qu’on a décrit, pas le problème qu’on avait.

Le problème se formule mieux en décisions et en résultats. Quelle information manque au moment où quelqu’un doit dire oui ou non ? Qu’est-ce qui est ressaisi, et avec quel délai ? Quelle erreur coûte cher, et à quelle fréquence ? Qu’est-ce qui doit rester possible même si le nouvel outil est en panne ?

Cette formulation change le périmètre. On peut livrer le suivi de dossier sans le dépôt de pièces, ou l’inverse, selon ce qui retire le plus de friction. Une liste de fonctionnalités ne donne pas cet ordre.

Cartographier l’existant

Le futur logiciel n’arrive pas dans un vide. Il y a déjà des applications, des fichiers, des boîtes mail, des API, des exports nocturnes, parfois un accès direct à une base que « personne ne touche ».

La carte utile n’est pas un schéma d’architecture d’entreprise. C’est la liste de ce qui porte une donnée dont le nouveau système aura besoin, ou qu’il risque d’écraser :

• l’application qui fait foi aujourd’hui, même si elle est ancienne ;
• les tableurs qui corrigent cette application ;
• les messages qui transportent une décision ;
• les API ou fichiers échangés avec un partenaire, un ERP, un outil métier ;
• les dépendances horaires : clôture, facturation, astreinte, synchro.

Pour chaque élément, trois questions suffisent. Qui en est responsable ? Que se passe-t-il s’il est faux ? Peut-on s’en passer le temps d’une transition ?

Cette carte évite deux erreurs symétriques. Tout reconnecter « plus tard », et découvrir en recette qu’un statut vient d’un système qu’on n’a pas prévu. Ou tout intégrer dès le premier jour, et ne jamais livrer le parcours qui justifiait le projet. Quand le sujet est surtout de faire circuler une information déjà saisie ailleurs, le cas d’usage connecter des systèmes est souvent plus juste qu’un nouveau logiciel complet.

Identifier les utilisateurs et leurs décisions

« Les utilisateurs » est une catégorie trop large. Un gestionnaire, un opérateur terrain, un client externe et un responsable qui consulte un tableau n’ont ni le même moment, ni la même information, ni le même droit à l’erreur.

Pour chaque rôle, on gagne à écrire une phrase de ce genre : au moment X, cette personne décide Y, avec l’information Z, et la conséquence est W. Si la phrase ne tient pas, le rôle est flou ou la décision n’existe pas vraiment.

Les droits d’accès se déduisent de ces phrases, pas d’un organigramme. Qui peut corriger une donnée déjà transmise ? Qui peut voir un dossier qui n’est pas le sien ? Qui doit être empêché de valider ce qu’il a lui-même saisi ? Ces questions ont plus d’effet sur le modèle que le choix du framework.

Le terrain ajoute une contrainte que les ateliers en salle oublient. Réseau intermittent, gants, soleil sur l’écran, une seule main libre, un délai de quelques secondes. Si le logiciel doit vivre hors du bureau, ces conditions font partie du cadrage, au même titre que les règles de gestion.

Clarifier les règles métier

Le cas nominal

Le cas nominal est le chemin que l’on sait raconter. Une demande complète, un stock disponible, un client identifiable, une validation dans les délais. Il faut le décrire jusqu’au bout, y compris ce qui est enregistré et ce qui est notifié. Mais il ne représente pas le système.

Les exceptions

Les exceptions sont le logiciel. Un avoir partiel. Une pièce illisible. Un tiers qui n’existe pas encore dans le référentiel. Une règle locale que seule une équipe applique. Un cas qui doit sortir du flux et revenir plus tard sans perdre son historique.

Chaque exception se traite de la même façon. Quelle est la condition ? Qui tranche ? Quelle trace reste ? Est-ce que le dossier peut continuer, ou doit-il s’arrêter ? Si personne ne sait répondre, ce n’est pas un détail à voir en développement. C’est un trou dans la règle, et le code ne le comblera pas proprement.

Définir un premier périmètre utile

Un premier périmètre n’est pas un produit coupé au hasard pour tenir un budget. C’est un parcours complet pour un cas réel, utilisé par de vraies personnes, avec un critère pour dire s’il a servi.

Le critère n’a pas besoin d’être un indicateur sophistiqué. Moins de ressaisie sur ce type de dossier. Un délai de traitement observable. La disparition d’un tableur donné. L’important est que l’équipe puisse constater l’effet, et décider de la suite à partir de ça plutôt qu’à partir du plan initial.

Tout ce qui est hors de ce parcours reste visible : on le note, on ne le construit pas. Les fonctions « pendant qu’on y est » sont le principal moyen de rater un cadrage qui était pourtant clair.

Ce travail rejoint souvent l’automatisation d’un processus, quand le gain tient à la suppression de copies manuelles, ou la modernisation d’un logiciel déjà en place, quand il s’agit de remplacer une partie d’un existant sans tout éteindre.

Choisir l’architecture ensuite

Les contraintes précèdent la technologie. Volume, pics, données personnelles, temps de réponse, mode déconnecté, systèmes à ne pas casser, équipe qui reprendra le code, horizon à deux ans ou à dix ans. Deux contextes qui « veulent une application web » n’appellent pas la même architecture.

On peut alors choisir un cadre technique sans le faire passer pour une préférence. Monolithe modulaire ou services séparés, selon le nombre d’équipes et le rythme de déploiement. Base relationnelle quand les règles et l’historique comptent. Fichiers et files quand le métier est un échange, pas un formulaire. Authentification reprise de l’annuaire existant plutôt qu’un deuxième compte à gérer.

Le développement vient après ce choix, pas à la place. Développer le logiciel sans cette étape, c’est coder des hypothèses. Les hypothèses se corrigent, mais elles coûtent moins cher écrites dans un cadrage que dispersées dans le code.

Ce qu’un bon cadrage doit produire

À la fin, les personnes qui décident et les personnes qui construiront devraient pouvoir relire la même chose et y reconnaître le travail réel. Concrètement, le livrable tient en quelques pièces, pas en une liasse :

• une compréhension partagée du processus, y compris les contournements ;
• le problème formulé en décisions, pas en écrans ;
• la carte de l’existant et des données qui font foi ;
• les rôles et ce qu’ils ont le droit de trancher ;
• les règles du cas nominal et les exceptions retenues ;
• un premier périmètre, avec ce qui est explicitement dehors ;
• les risques déjà visibles : donnée sale, dépendance, adoption, calendrier ;
• une architecture initiale suffisante pour démarrer, pas un schéma définitif ;
• les hypothèses encore ouvertes, et comment on les vérifiera ;
• un backlog ordonné par le parcours utile, pas par la facilité technique.

L’analyse et l’architecture servent à produire ces pièces avant d’engager le développement. Le volume varie. Un parcours déjà bien connu peut tenir en quelques ateliers. Un métier éclaté entre trois outils et deux sites demande plus de temps sur le terrain. Dans les deux cas, le critère de fin est le même : on sait ce qu’on construit en premier, et pourquoi le reste attend.

Cadrer ne veut pas dire figer le projet pendant trois mois. Un cadrage qui interdit d’apprendre en cours de route est trop long. Un développement qui démarre sans réponse sur les exceptions est trop tôt. Entre les deux, il y a assez de matière pour écrire la première ligne sans improviser le métier.