Cahier des charges d’un logiciel métier : que faut-il préparer ?

Un client arrive avec un logiciel à remplacer. Un autre avec des fichiers Excel qui font tourner son activité. Un troisième a un petit prototype et une idée de ce qu'il voudrait construire. Tous peuvent se poser la même question : avons-nous assez de matière pour faire appel à un prestataire, ou faut-il d'abord rédiger un cahier des charges ?

Faut-il un cahier des charges exhaustif pour lancer un logiciel métier ? Dans les projets que nous accompagnons, nous pouvons construire une partie de ce cadrage avec le client. Un outil existant, une documentation métier ou un prototype donnent des prises pour comprendre. Mais aucun ne dit, à lui seul, ce que l'organisation cherche à changer.

Pour commencer le cadrage d'un logiciel métier, nous avons surtout besoin d'un cap, d'une enveloppe budgétaire et d'un cadre permettant d'engager le travail. Puis il faut pouvoir parler aux personnes qui portent la stratégie et à celles qui connaissent l'activité. Les fonctionnalités détaillées se construisent à partir de là.

Un ancien logiciel décrit le présent, pas forcément le besoin

L'existence d'un ancien outil rassure. Il y a déjà des écrans, des données, des règles. Le client peut nous montrer ce qu'il utilise et nous expliquer ce qui lui pose problème. Sur Dosima, notre projet de lecture et de validation de dosimètres, l'existant et sa documentation faisaient partie de ce point de départ.

Cette base est précieuse. Elle porte aussi une manière de travailler à laquelle les équipes se sont habituées. Les étapes du logiciel deviennent les étapes du métier. Ce qui a été séparé dans deux écrans semble devoir rester séparé ; ce qui nécessite plusieurs manipulations finit par paraître normal.

Or, derrière une modernisation, il y a souvent une volonté de transformer le travail lui-même. Aller plus vite, réduire les erreurs, soulager une tâche pénible. Si nous recopions les habitudes sans les examiner, nous pouvons livrer une interface plus récente qui conserve les mêmes difficultés.

En conception, nous cherchons donc à comprendre deux choses ensemble : ce que l'ancien outil fait, et ce que le client veut améliorer dans son organisation. Cette volonté donne un critère pour discuter les habitudes. Elle permet de se demander si une étape est nécessaire au métier, ou si elle était surtout nécessaire au logiciel précédent.

Chez Ecolhuma, un objectif de transition devient un choix fonctionnel

Sur un projet avec l'association Ecolhuma, l'objectif stratégique était de permettre aux utilisateurs de passer dans de bonnes conditions à la deuxième version d'une application. L'évolution était importante et concernait plusieurs catégories d'utilisateurs, dont des personnes qui créaient des ressources ensuite mises à disposition.

Une autre décision avait été prise : ces ressources ne devaient pas être migrées. Le dialogue a fait apparaître une contradiction dans le parcours de ces contributeurs. Comment leur permettre de faire la transition tout en conservant leur activité de création de ressources ?

Les deux décisions avaient chacune leurs raisons. Nous avons donc cherché une organisation fonctionnelle capable de les faire tenir ensemble. Le choix retenu a été de conserver une partie bien identifiée et isolée de la version 1, consacrée à l'édition des ressources, dans le cadre de la transition vers la version 2.

L'objectif général de passage à la nouvelle version et la décision de ne pas migrer ces ressources pouvaient ainsi coexister. Le périmètre conservé de l'ancien outil avait un rôle précis dans le fonctionnement du projet.

C'est un exemple de ce que produit le cadrage : partir d'une intention stratégique, examiner ses conséquences pour les différents utilisateurs, puis déterminer ce que l'application doit permettre. Une phrase comme « passer à la version 2 dans de bonnes conditions » devient une décision fonctionnelle dès que l'on regarde le travail réel des personnes concernées.

Des fichiers Excel et des documents peuvent suffire pour commencer

D'autres clients n'ont pas d'application unique à nous montrer. Leur activité repose sur plusieurs fichiers, des échanges entre collègues et des outils activés de manière plus ou moins artisanale. Dans ces cas, les documents qui expliquent les processus existants nous aident beaucoup.

Un tableau raconte la façon dont l'équipe organise ses informations. Les documents métier expliquent une partie des règles. Les échanges permettent de retrouver les décisions et les exceptions que les fichiers ne montrent pas.

Il n'est pas nécessaire de transformer tout cela en spécifications avant de nous le transmettre. Nous pouvons étudier cette matière en amont des réunions, puis revenir avec des questions et des propositions. Les personnes métier gagnent du temps lorsqu'elles n'ont pas à reprendre toute l'explication depuis le début.

La question stratégique reste la même que pour un ancien logiciel : quel changement justifie le projet ? Un ensemble de fichiers décrit une situation. L'objectif permet de décider ce que nous voulons conserver, simplifier ou réorganiser.

Avec un prototype, le périmètre peut encore se répartir autrement

Sur Lidarvisor, le client disposait d'un petit prototype et d'un objectif : afficher des données lidar en 3D et les traiter. Le produit s'est construit à partir d'échanges autour de cette direction, sans application métier complète à reprendre.

Assez rapidement, le client a choisi d'internaliser la classification des données. Cette partie représentait un enjeu de maîtrise et de cœur de métier important pour lui. La répartition s'est précisée au fil du travail : le client prenait cette responsabilité, tandis que nous nous occupions davantage de la partie applicative et de l'interface.

Le besoin ne portait donc pas seulement sur une liste de fonctions. Il fallait aussi comprendre ce que le client voulait maîtriser lui-même. Le dialogue a permis de répartir le travail en fonction de cette intention.

Pour préparer un projet de logiciel sur mesure, cette information compte : quels savoir-faire doivent rester dans votre équipe ? Quelles parties souhaitez-vous nous confier ? Vous pouvez exprimer ces enjeux avant de savoir décrire tous les écrans.

Une idée peut précéder le projet de plusieurs mois

Il arrive aussi qu'un client nous parle d'une idée alors qu'aucun projet n'est encore lancé. La discussion reste informelle. Six mois ou un an plus tard, l'idée peut se concrétiser.

Ces premières conversations ne sont pas perdues. Elles nous permettent d'assimiler la direction recherchée. Quand le travail commence, nous avons déjà une bonne compréhension du cap. Ce qui manque encore, c'est la connaissance détaillée de l'activité, que nous construisons avec les équipes métier.

La stratégie donne le cap. La connaissance du terrain donne le chemin.

Un cahier des charges logiciel gagne à tenir ensemble ces deux dimensions. L'objectif stratégique permet d'arbitrer. La connaissance du terrain permet de construire un outil qui sera utilisable. Il faut des interlocuteurs pour éclairer chacune.

Ce qu'il faut préparer avant de contacter un prestataire

Nous demandons au client de nous apporter ce qu'il sait déjà et de rendre possibles les échanges qui permettront d'aller plus loin. Voici les éléments qui nous aident à démarrer un cadrage fonctionnel.

Pour décrire le changement recherché, une formulation simple aide déjà beaucoup : quelle équipe rencontre quelle difficulté aujourd'hui, et qu'aimeriez-vous lui permettre de faire demain ? C'est une base pour discuter, même si vous ne savez pas encore quelles fonctionnalités y répondront.

Les grandes échéances nous aident aussi à poser une première trajectoire. Que voudriez-vous avoir changé dans trois mois, dans six mois, dans un an ? Cette discussion produit une roadmap encore large. Nous la précisons ensuite, avec des fonctionnalités et des essais.

À ce stade, vous pouvez laisser ouvertes des questions comme la disposition exacte d'un écran ou le détail d'un export. Elles pourront être examinées pendant le travail. Une dépendance à un service inaccessible demande, elle, une discussion dès que nous la repérons.

Ce qui bloque vraiment le démarrage

Une absence de cadre budgétaire nous empêche de discuter sérieusement les choix. Si nous ne savons pas dans quelles conditions engager le travail, le démarrage reste également en suspens.

Le troisième obstacle est plus discret : ne pas avoir accès à la dimension stratégique ou aux équipes métier. Sans la première, nous pouvons construire un outil sans comprendre le changement recherché. Sans les secondes, il devient très difficile d'être pertinent sur les usages.

Cette disponibilité mérite donc d'être organisée. Dans notre retour sur le temps à prévoir côté métier, nous détaillons le rythme des échanges, les essais guidés et l'appropriation. Le prestataire prend en charge une partie importante de la formalisation, mais il a besoin de personnes qui peuvent lui répondre et le corriger.

Le cahier des charges peut se construire avec le prestataire

Rédiger un cahier des charges exhaustif avant de commencer est un travail important. Lorsque l'équipe manque de temps, nous pouvons en porter une partie avec elle : étudier les documents, restituer ce que nous comprenons, proposer des maquettes et discuter les choix.

C'est le rôle d'un lot de cadrage avec des livrables identifiables. Il permet de rendre la compréhension visible, puis d'organiser la suite du projet. Nous racontons cette manière de travailler dans notre article sur les projets numériques avec des équipes métier qui manquent de temps.

Avant de nous contacter, rassemblez donc ce que vous avez. Un outil, quelques documents et un objectif clair peuvent être un bon point de départ. Si certaines réponses manquent encore, elles feront partie du travail de conception.

Vous avez une direction, un existant et des questions sur ce qu'il faut formaliser ? Parlons de ce premier cadrage.