Le cahier des charges qui ne sert à rien, et celui qui sert

« Envoyez-nous votre cahier des charges. » La phrase paraît professionnelle, et elle décourage la moitié des projets avant qu’ils ne commencent. Beaucoup d’entreprises renoncent simplement parce qu’elles ne savent pas par quel bout écrire ce document.

Bonne nouvelle : dans la plupart des cas, il n’est pas nécessaire. Et quand il l’est, il est bien plus court qu’on ne l’imagine.

Pourquoi les gros cahiers des charges produisent de mauvais logiciels

Un document de quarante pages donne une impression de maîtrise. En pratique, il souffre de trois maux.

Il décrit une solution, pas un problème. « Il faut un bouton qui exporte en PDF » est une solution ; « le comptable a besoin des factures du mois dans un format qu’il puisse archiver » est un problème. Le second laisse une chance de trouver mieux que le bouton.

Il oublie ce que personne ne pense à dire. Les règles non écrites, celles que tout le monde applique et que personne ne formule, ne figurent jamais dans un document rédigé en salle de réunion. Elles se voient en regardant travailler, et elles représentent la moitié des spécifications réelles.

Il fige au pire moment. Un cahier des charges est signé quand la compréhension du besoin est à son minimum : avant d’avoir rien vu. Tout ce qu’on apprend ensuite devient un « avenant », c’est-à-dire un conflit.

Ce qu’il faut écrire à la place

Trois pages suffisent, et elles répondent à sept questions. Si vous ne deviez faire qu’une chose avant de nous appeler, c’est celle-ci.

• Qu’est-ce qui ne va pas aujourd’hui ? Décrivez la situation actuelle, pas l’outil rêvé. « Trois personnes ressaisissent les commandes reçues par courriel dans le logiciel de gestion. »
• Combien ça coûte ? En heures, en erreurs, en clients perdus. Même approximatif, ce chiffre oriente tout le reste.
• Qui s’en sert, et dans quelles conditions ? Cinq personnes au bureau, ou quinze sur le terrain avec un téléphone et un réseau incertain ? Ce n’est pas le même logiciel.
• Avec quoi ça doit parler ? Logiciel de comptabilité, ERP, site web, messagerie. Nommez-les, même si vous n’êtes pas sûr que ce soit possible.
• Qu’est-ce qui est vital, et qu’est-ce qui serait agréable ? Deux colonnes. C’est le tri le plus utile du document, et celui que personne ne fait spontanément.
• Comment saurez-vous que c’est réussi ? Un critère mesurable. « Plus aucune ressaisie » vaut mieux que « un outil moderne ».
• Quel budget, quelle échéance ? Même une fourchette large. Un projet sans budget annoncé fait perdre du temps à tout le monde, et le prestataire qui ne le demande pas vous chiffrera au hasard.

Ce qui remplace les trente-sept autres pages

Une demi-journée sur place. Regarder les gens travailler, voir la feuille scotchée sur l’écran, le raccourci que tout le monde connaît sauf le nouveau, le fichier qu’on ouvre « juste pour vérifier ». Cette demi-journée apprend plus que six semaines d’allers-retours par courriel, et nous la facturons au prix d’une demi-journée.

Vient ensuite une maquette cliquable — pas du code, des écrans qu’on peut parcourir. C’est là que les vraies remarques arrivent, parce qu’il est infiniment plus facile de réagir à quelque chose qu’on voit que d’imaginer à partir d’un texte. Corriger une maquette coûte une heure ; corriger un développement, plusieurs jours.

Les trois questions qui font gagner le plus de temps

Si la liste de sept questions vous paraît encore trop longue, en voici trois qui, à elles seules, cadrent l’essentiel d’un projet.

« Montrez-moi comment vous faites aujourd’hui. » Pas comment vous voudriez faire : comment vous faites. C’est la question qui révèle les contournements, les fichiers parallèles et les règles implicites.

« Que se passe-t-il quand ça se passe mal ? » Une commande annulée, un client qui change d’avis, une erreur de saisie découverte trois jours plus tard. Les cas d’exception représentent souvent la moitié du développement, et ils ne figurent presque jamais dans un cahier des charges.

« Qui décide, et qui utilise ? » Ce n’est pas toujours la même personne, et c’est la source d’échec la plus fréquente : un outil conçu pour satisfaire celui qui signe, abandonné par ceux qui devaient s’en servir.

Et si vous êtes une administration

Le formalisme s’impose parfois, et c’est légitime : un marché public a des règles. Dans ce cas, nous aidons à rédiger la partie technique du document plutôt que de vous laisser deviner un vocabulaire qui n’est pas le vôtre. Cela fait partie du travail, et cela ne devrait pas être un service payant caché.

En résumé

N’attendez pas d’avoir un cahier des charges pour appeler. Apportez le problème, nous nous occupons de la traduction. C’est même précisément ce que fait Leslie chez nous : transformer « on perd du temps sur les commandes » en quelque chose qu’un développeur peut construire.