Comment rédiger un cahier des charges pour un logiciel sur mesure

Le test des dix questions

Avant d'envoyer quoi que ce soit, il existe un moyen simple de savoir si votre document est bon : faites-le lire à quelqu'un qui ne connaît pas votre métier, et comptez ses questions.

S'il en a cent, le document est incomplet. Les prestataires vous répondront par des devis prudents, gonflés pour couvrir ce qu'ils n'ont pas compris, et impossibles à comparer entre eux.

S'il n'en a aucune, il ne l'a pas lu, ou le document est si vague qu'il peut y projeter n'importe quoi. C'est le cas le plus dangereux, parce qu'il produit des devis bas suivis d'avenants.

S'il en a une dizaine, et qu'elles portent sur des cas limites plutôt que sur le principe, vous avez un bon cahier des charges. Il est assez précis pour être chiffré, et assez ouvert pour laisser le prestataire proposer une solution.

Ce test vaut mieux qu'une relecture, parce qu'il mesure la seule chose qui compte : ce que le document transmet réellement à quelqu'un qui n'a pas votre contexte en tête.

À quoi sert réellement ce document

Un cahier des charges n'a pas pour fonction de décrire un logiciel. Il sert à ce que plusieurs prestataires comprennent le même besoin, chiffrent la même chose, et puissent être comparés autrement que sur un prix global.

C'est aussi, et souvent surtout, un exercice interne. Écrire ce que l'on attend oblige à trancher des questions restées ouvertes pendant des années : qui valide quoi, quelle règle s'applique dans tel cas, quelle information fait foi.

Beaucoup d'entreprises constatent que la rédaction leur a apporté davantage que le document lui-même. Ce n'est pas un effet secondaire, c'est la moitié de l'intérêt.

Les sept parties, et les deux qui comptent

Dix à vingt pages suffisent largement pour un projet courant. Au-delà, le volume nuit à la lecture et personne ne le relit à mi-projet.

• Le contexte : qui vous êtes, ce que vous vendez, combien vous êtes, comment le travail s'organise aujourd'hui.
• Le problème, avec des chiffres : combien de temps, combien de fois, combien d'erreurs.
• Les utilisateurs : qui va s'en servir, dans quelles conditions, avec quel matériel.
• Les parcours : ce qui doit se passer, pas à pas, dans les cas les plus fréquents.
• Les règles métier : ce qui est autorisé, interdit, conditionnel, avec les exceptions.
• L'existant : les systèmes auxquels l'outil devra parler, et qui les administre.
• Les contraintes : échéance, budget indicatif, obligations réglementaires, matériel imposé.

Les parcours et les règles métier représentent à eux seuls la moitié de la valeur du document, et ce sont les deux parties que personne d'autre que vous ne peut écrire. Les cinq autres peuvent être rédigées par n'importe qui dans l'entreprise.

Écrire un parcours, écrire une exception

Un parcours bien écrit tient en une page et suit toujours la même forme : qui, dans quelle situation, fait quoi, et qu'est-ce qui se passe ensuite.

Un exemple, volontairement générique : « Le technicien termine son intervention. Il ouvre la fiche, saisit les pièces utilisées, prend deux photos, fait signer le client. La fiche part en facturation. Si le client est absent, elle part en attente de validation. »

Quatre phrases, et un prestataire comprend ce qu'il doit construire, ce qu'il doit raccorder, et où se trouvent les cas particuliers. Un seul parcours de ce niveau vaut mieux que vingt lignes de fonctions.

Les cas particuliers méritent une attention particulière, parce que ce sont eux qui font le prix. Une règle générale s'écrit en une ligne ; les situations où elle ne s'applique pas représentent le vrai travail, et elles doivent figurer dans le document plutôt que surgir en cours de projet.

Écrivez les parcours les plus fréquents, puis les deux ou trois exceptions qui reviennent le plus. Les cas rares se traitent en cours de route : chercher l'exhaustivité au départ allonge le document sans améliorer les devis.

Pourquoi les exceptions pèsent autant sur un budget : Combien coûte un logiciel sur mesure

Ce qu'il vaut mieux retirer

Trois contenus très répandus dégradent la qualité des réponses reçues.

• Les choix techniques. Désigner un langage ou une base de données prive les prestataires de leur meilleure contribution et ne vous apporte rien. Décrivez les contraintes réelles, pas les solutions.
• Les maquettes d'écran détaillées. Elles figent une interface avant d'avoir compris les parcours, et déplacent la discussion vers l'apparence.
• Les listes de fonctions sans contexte. « Gestion des utilisateurs » peut désigner deux jours ou deux mois de travail. Sans parcours, ces lignes ne se chiffrent pas.

Une quatrième tentation mérite d'être évitée : décrire ce que fait le logiciel que vous avez vu chez un concurrent. Vous obtiendrez des devis pour ce logiciel, pas pour votre besoin.

Une journée, et une personne qui tranche

Pour un projet courant, un cahier des charges utile se rédige en une journée : une matinée d'observation sur le terrain, puis une séance d'écriture des parcours avec les personnes concernées. Ce n'est pas un document à faire mûrir pendant des semaines.

La personne qui le rédige n'a pas besoin d'être technique. Elle doit en revanche avoir l'autorité pour trancher, parce que l'exercice fera remonter des désaccords internes jusque-là contournés.

Si cette rédaction vous paraît lourde, il existe une alternative : faire réaliser le cadrage par un prestataire, en gardant la liberté de consulter d'autres entreprises ensuite. Une journée menée par quelqu'un qui a déjà cadré cent projets produit souvent un meilleur document que trois semaines de rédaction interne entre deux dossiers.

Enfin, acceptez dès le départ que le document évolue. Les projets qui aboutissent le relisent à mi-parcours et assument les écarts, parce que l'usage réel enseigne des choses que la rédaction ne pouvait pas prévoir. Conservez les parcours et les règles comme référence vivante ; la liste des fonctions, elle, bougera.