Le cahier des charges, ce document qui fait échouer les projets

Le raisonnement paraît imparable : pour comparer des devis, il faut un référentiel commun. On rédige donc un document décrivant les fonctionnalités attendues, on l'envoie à trois prestataires, on compare les prix.

Le problème est que ce document ne décrit pas un problème. Il décrit une solution — et cette solution a été choisie par la personne la moins bien placée pour la concevoir.

Un cahier des charges décrit une solution déjà choisie

Quand vous écrivez « il faut un tableau de bord avec des filtres par région et un export Excel », vous avez déjà décidé de la forme. Le besoin réel était peut-être « le directeur commercial doit savoir chaque lundi matin quelles agences décrochent » — ce qui aurait pu se régler par un email automatique de dix lignes.

En figeant la forme, vous supprimez la seule chose qu'un bon prestataire pouvait vous apporter : un regard neuf sur le problème.

Les trois effets pervers

1. Il rend les mauvaises décisions contractuelles

Une fois le document annexé au contrat, toute correction devient un avenant. Vous vous retrouvez à payer pour modifier une décision que vous avez prise avant de comprendre le sujet.

2. Il déresponsabilise le prestataire

Un prestataire qui livre exactement ce qui était écrit a rempli son contrat, même si l'outil ne sert à rien. Vous avez acheté de la conformité, pas un résultat.

3. Il fait comparer les devis sur le mauvais critère

À périmètre figé, seul le prix distingue les offres. Vous choisissez donc le moins cher, c'est-à-dire souvent celui qui a le moins compris — les autres ayant chiffré les difficultés qu'ils avaient anticipées.

Ce qu'il faut préparer à la place

Remplacez le cahier des charges par un dossier de problème. Il est plus court à écrire et infiniment plus utile.

• La liste des irritants, classés par ce qu'ils coûtent. « On ressaisit 40 commandes par jour », « on découvre les retards quand le client appelle ». Des faits, pas des fonctionnalités.
• Qui fait quoi aujourd'hui. Les rôles réels, y compris les contournements officieux — ce sont eux qui révèlent les vrais besoins.
• Vos fichiers actuels. Un tableur existant vaut cinquante pages de spécifications : il contient vos champs, vos statuts, votre vocabulaire.
• Vos règles de gestion, avec leurs exceptions. C'est là que se cache la complexité, et donc le coût.
• Ce qui doit rester possible. Les contraintes réglementaires, les outils avec lesquels il faut cohabiter.
• Comment vous saurez que ça a marché. Un critère mesurable. Sans lui, personne ne pourra jamais dire si le projet a réussi.

Le cas des appels d'offres

Dans un cadre public ou très formalisé, le cahier des charges est obligatoire. Dans ce cas, décrivez des objectifs et des contraintes plutôt que des écrans. « Réduire de moitié le temps de traitement d'une commande » laisse aux candidats la possibilité de proposer mieux que ce que vous aviez imaginé.

Le prototype, meilleure spécification qui soit

La façon la plus fiable de savoir si un outil convient est de le manipuler. Un prototype cliquable, produit en quelques jours avec vos mots et vos données d'exemple, vous apprend en une heure ce qu'aucun document ne vous dira.

C'est aussi la seule manière d'impliquer les utilisateurs finaux. Personne ne relit sérieusement quarante pages de spécifications. Tout le monde a un avis sur un écran qu'il peut cliquer.

Voir aussi : combien de temps faut-il pour développer une application métier ?