Pas besoin d'un cahier des charges de 80 pages pour démarrer un projet

« On reviendra vers vous quand on aura rédigé le cahier des charges. » C'est une phrase que j'entends souvent en fin de premier rendez-vous, et qui annonce généralement un projet qui ne démarrera pas avant un an. Rédiger un long document de spécifications est une tâche intimidante, et ce n'est pas ce qui fait réussir un logiciel. Voici pourquoi, et ce qui suffit vraiment pour démarrer.

Pourquoi le gros cahier des charges déçoit souvent

Il décrit des solutions, pas des problèmes

Un cahier des charges écrit seul, sans aide, décrit souvent la solution imaginée : « un bouton ici, un tableau là, un export Excel ». Or la meilleure solution n'est pas toujours celle qu'on imagine au départ. Ce qui compte, c'est le problème à résoudre, et c'est ce que le document oublie parfois de dire.

Il est écrit avant de savoir

Au moment où l'on rédige, on ne sait pas encore ce qui sera simple ou compliqué, ce que les utilisateurs aimeront ou contourneront. Quatre-vingts pages figées au début d'un projet, ce sont quatre-vingts pages qu'il faudra renégocier en cours de route.

Personne ne le lit vraiment

Ni vos équipes, qui n'ont pas le temps, ni parfois le prestataire, qui le survole. Un document que personne ne lit en entier ne protège personne.

Il retarde tout

Le temps passé à rédiger est du temps où le problème continue de vous coûter. Et la rédaction s'éternise souvent, parce qu'il manque toujours une information.

Ce qui suffit pour démarrer

Pour un premier rendez-vous, et même pour lancer la conception, il suffit de :

• Le problème en une phrase. « Nos devis prennent trop de temps et contiennent des erreurs de prix. » « Personne ne sait en temps réel où en est la production. »
• Deux ou trois exemples concrets. Le tableur actuel, un devis qui a posé problème, un échange de mails qui illustre la difficulté.
• Les personnes concernées. Qui utilisera l'outil, qui lira les résultats, qui décidera.
• Les outils existants avec lesquels il faudra communiquer.
• Les contraintes : délai, budget envisagé, données sensibles, contraintes de terrain.

Une page, souvent moins. Le reste, on le construit ensemble.

Ce qui remplace le cahier des charges chez nous

Des entretiens avec les utilisateurs

Plutôt que de vous demander d'écrire, nous venons écouter, en visio ou sur place : la personne qui saisit, celle qui valide, celle qui lit les chiffres. On comprend en une heure d'observation ce qu'un document mettrait trente pages à décrire.

Des maquettes cliquables

Nous dessinons les écrans du futur logiciel sous forme de maquettes sur lesquelles on peut cliquer, comme si le logiciel existait. Vos équipes les essaient, réagissent, corrigent. C'est la spécification la plus précise qui soit, et la seule que tout le monde comprend. Le prix est fixé à la fin de cette étape, sur la base des maquettes validées, avant d'écrire du code.

Des versions testables toutes les deux semaines

Pendant le développement, vous recevez une version utilisable toutes les deux semaines. Si une idée se révèle mauvaise à l'usage, on la corrige tôt, quand ça ne coûte presque rien.

Une documentation qui décrit ce qui existe

À la livraison, vous recevez le code source et une documentation du logiciel réellement construit, pas d'un logiciel imaginé un an plus tôt.

Quand un cahier des charges est vraiment utile

Soyons honnêtes : il y a des cas où un document écrit précis est indispensable. Un marché public impose un cahier des clauses techniques. Un projet soumis à une norme ou à une certification exige des exigences tracées. Un projet qui met en concurrence plusieurs prestataires a besoin d'une base commune. Dans ces cas, nous travaillons à partir de votre document, et la phase de maquettes sert à le vérifier et à le compléter.

Le vrai risque n'est pas l'absence de document

Les projets qui échouent ne manquent pas de papier. Ils manquent de contact avec les utilisateurs, de versions testées tôt, et de décisions prises au bon moment. Un document de quatre-vingts pages peut même donner une fausse impression de sécurité : tout semble prévu, alors que personne n'a encore essayé quoi que ce soit. À l'inverse, un projet qui démarre avec une page claire et des maquettes testées par vos équipes a déjà levé la plupart des malentendus.

Les questions à vous poser

• Pouvez-vous dire votre problème en une phrase ?
• Qui, dans l'entreprise, le vit au quotidien ?
• Avez-vous un exemple concret à montrer ?
• Que vous coûte chaque mois d'attente ?

Si vous pouvez répondre à ces quatre questions, vous avez de quoi démarrer. Nous expliquions dans notre article sur le rendez-vous de 30 minutes comment se passe le premier échange, et dans celui sur le choix d'un prestataire les questions à nous poser. Nos logiciels sont présentés sur la page Logiciel. Le plus simple reste de prendre rendez-vous, sans document.