Rédiger le cahier des charges d'une application métier : le strict nécessaire

Beaucoup d'entreprises repoussent leur projet d'application métier parce qu'elles pensent devoir écrire un document exhaustif avant de consulter un prestataire. C'est l'inverse : un cahier des charges trop long fige des décisions prises trop tôt, et les meilleures idées arrivent quand on voit les premiers écrans. Voici ce dont nous avons réellement besoin pour commencer.

Décrire le processus, pas les écrans

La partie la plus utile d'un cahier des charges raconte une journée de travail. Qui reçoit quoi, dans quel ordre, avec quelle information manquante, et ce qui se passe quand ça se passe mal. Un développeur expérimenté déduit les écrans d'un processus bien raconté ; l'inverse n'est pas vrai.

• Le déclencheur : un appel, un mail, un scan, une commande, un patient qui arrive.
• Les étapes réelles, y compris celles faites dans un tableur ou sur papier.
• Les validations et qui les donne.
• Le résultat attendu : un document, une facture, une décision, une notification.

Nommer les rôles et ce que chacun peut voir

Les questions de permissions sont la première source de mauvaise surprise. Listez les rôles, et pour chacun ce qu'il peut consulter, créer, modifier et supprimer. Une seule ligne compte plus que tout le reste : qui n'a pas le droit de voir quoi.

Lister les données et leur provenance

Une application métier vaut par les données qu'elle manipule. Précisez lesquelles existent déjà, où elles vivent, dans quel état, et qui en est responsable. Une reprise de données mal anticipée décale un projet plus sûrement qu'une fonctionnalité oubliée.

• Les fichiers ou logiciels existants à reprendre, avec un exemple réel anonymisé.
• Les systèmes avec lesquels l'application doit échanger.
• Les données sensibles et leur cadre réglementaire.
• Les volumes : quelques centaines de lignes ou plusieurs millions ne se traitent pas pareil.

Écrire les cas limites

Le sur-mesure existe précisément pour les exceptions. Le client qui paie en trois fois, la commande annulée après préparation, le dossier incomplet qu'il faut tout de même traiter. Ces cas sont votre métier, et ce sont eux qui font la différence entre un outil adopté et un outil contourné.

Ce qu'il vaut mieux ne pas écrire

• Le choix des technologies, sauf contrainte réelle de votre système d'information.
• Le détail des écrans et la position des boutons : c'est le travail des graphistes et des ergonomes.
• Une liste de fonctionnalités sans ordre de priorité : tout est important, donc rien ne l'est.
• Un planning au jour près avant d'avoir cadré le périmètre.

Ajouter la seule chose qui aide à chiffrer

Terminez par vos priorités : ce qui doit absolument fonctionner dans la première version, et ce qui peut attendre. C'est cette hiérarchie qui permet de proposer un périmètre réaliste, un délai tenable et un budget honnête. Si vous n'avez que trois pages mais qu'elles contiennent cela, envoyez-les-nous : nous saurons quoi en faire.