Le cahier des charges parfait n'existe pas

c'est à peu près aussi rare qu'une licorne !

Un dénominateur commun à tous nos projets

On aimerait tous, en démarrant un projet, disposer d'un cahier des charges parfait, un document qui prévoit tout : chaque page, chaque contenu, chaque cas particulier, sans surprise possible en cours de route. C'est ce que nous demandons à la moindre demande de devis, nous et nos confrères.

Dans les faits, ce document n'existe quasiment jamais et ce n'est pas parce que les clients manquent de rigueur, ni parce que nous manquons de méthode. C'est que personne, au premier jour d'un projet, ne détient toutes les réponses. Le client connaît ses enjeux (il pense qu'ils sont évidents et oublie de les préciser)  mais rarement la façon dont ils vont se traduire concrètement en pages, en mots ou en parcours. Ca c'est plutôt normal, c'est notre job de traduire un besoin en réponse. Et nous, même avec la meilleure expertise du monde, nous ne pouvons pas deviner ce qui n'a pas été partagé.

Ce constat vaut aussi bien pour une brochure de 4 pages (qui est considéré comme un projet "simple") que pour le développement d'une application complexe.

Dans tous ces cas, l'absence de cahier des charges complet n'est pas un problème en soi. On peut même vous accompagner pour le rédiger.

Le vrai sujet, c'est de savoir comment on s'organise pour avancer quand même et c'est justement là que les deux types de projets se distinguent, parce que les solutions ne sont pas les mêmes.

Le projet (faussement) simple

Il y a une phrase qu'on entend souvent, formulée de mille façons : "c'est un site assez simple", "c'est juste un catalogue de 8 pages", "rien de très compliqué", "un petit logo".

Elle cache toujours la même idée : puisque le projet paraît simple, il serait presque standard, et nous saurions par avance ce qu'il faut y mettre.

Le malentendu

C'est un malentendu compréhensible, mais un malentendu quand même. Un client n'a en général aucune raison de savoir ce que représente la conception d'un site ou d'un document, aussi modeste soit-il : le choix des mots, l'ordre dans lequel on présente les choses, ce qu'on met en avant ou ce qu'on tait, les enjeux techniques, de SEO, ... Ce n'est pas son métier, c'est le nôtre.

Mais cette différence de métier crée un piège bien réel : le client pense que la simplicité apparente du résultat final dispense de réfléchir en amont, et espère que nous saurons deviner à sa place, à moindre coût. Sauf qu'un site à 5 ou 10 pages ne s'imagine pas tout seul, pas plus qu'un catalogue de 20 à 50 produits ou un kit de communication. Sans un minimum d'information sur ce que le client veut dire, à qui, et pourquoi, nous ne pouvons littéralement rien inventer de pertinent. Il y a des choses qui paraissent évidentes mais qui si elles ne sont pas dites, ne le sont pas.

La déconvenue

Le moment de vérité arrive presque toujours après coup : une fois la maquette validée, une fois le texte intégré, une fois le tunnel de vente configuré. C'est là que ce qui semblait clair dans la tête du client se heurte au réel, et qu'il découvre que ce n'est finalement pas ce qu'il voulait ou ce qu'il pensait vouloir. C'est légitime : on se projette rarement bien sur un objet qu'on n'a pas encore vu exister. Le problème n'est pas que le client change d'avis, c'est ce que ce changement d'avis déclenche derrière.

Concrètement, face à un revirement de ce type, nous avons 3 options :

1. Absorber le changement. Ponctuellement, ce n'est pas dramatique. Nous l'avons fait. Mais répété ou trop tardif, ça devient vite intenable pour nous et honnêtement, personne n'en ressort vraiment satisfait : le client sent bien qu'il nous demande un effort supplémentaire, et nous, on finit par travailler à perte sur un projet qu'on avait pourtant bien cadré au départ.
2. Dire non. Rarement la meilleure façon de démarrer ou d'entretenir une relation de confiance. Mais parfois nécessaire.
3. Faire un avenant au devis. On documente le changement, on chiffre le temps supplémentaire, et on avance sur une base claire pour tout le monde.

Les solutions

L'idéal reste bien entendu la rédaction d'un cahier des charges, ne nous y trompons pas. Cet article n'a pas pour vocation à dire le contraire.

Cependant quand la rédaction d'un cahier des charges est trop problématique, la solution que nous préférons, quand elle est possible, c'est de poser dès le départ l'idée qu'un projet se construit en plusieurs temps : une première version qui permet de voir concrètement ce que ça donne, suivie d'une phase de retravail une fois que le client a pu se confronter au résultat réel, la prochaine édition, s'il s'agit d'un support papier.

Ou, plus simplement, nous proposons un fonctionnement au temps passé, qui a le mérite de rendre les choses honnêtes des 2 côtés : de la souplesse pour ajuster en cours de route, une rentabilité préservée pour nous, et une forme de responsabilisation pour le client, qui sait que chaque changement a un coût et un temps associés.

Le projet de développement : itérer, oui, mais pas sans direction

Sur les projets numériques plus complexes que nous développons, comme les applications, la logique est différente et paradoxalement plus simple à assumer.

Attention, là aussi, nous ne disons pas qu'un bon cahier des charges est inutile. Nous pouvons d'ailleurs vous accompagner à sa rédaction.

Ces outils sont, par nature, pensés pour continuer à évoluer après leur mise en ligne. Avancer par itérations successives, observer les usages réels, ajuster, recommencer : cette méthode tient parfaitement la route, et elle est même la meilleure option, parce qu'aucune équipe, aussi expérimentée soit-elle, ne peut anticiper avec certitude comment les utilisateurs vont réellement se servir d'un outil avant de le leur mettre entre les mains.

Mais il y a un piège inverse à celui du projet « simple » : penser que, puisque le projet va évoluer, on peut se dispenser de cadrage au départ.

C'est faux.

Itérer ne veut pas dire avancer sans direction : ça veut dire avancer avec une direction claire, mais en acceptant de l'ajuster à mesure que le réel nous informe.

Le problème du cahier des charges reste donc entier, même ici : il faut toujours savoir, avant de commencer, ce qu'on cherche à faire et pour qui.

La différence, c'est que sur ces projets, cette question se repose à chaque nouvelle version plutôt qu'une seule fois au départ, ce qui, en réalité, rend les choses plus confortables pour tout le monde : personne n'a besoin de prétendre tout savoir dès le premier jour.

C'est ce que nous avons fait sur plusieurs projets dont le projet PROSCeSS.

Ce qui ne change jamais

Que le projet soit un site vitrine, une affiche, une charte graphique ou une application, le cahier des charges parfait n'existe pas, et ce n'est pas la question.

La vraie question, c'est de savoir dès le départ comment on va s'organiser quand la réalité contredira, en partie, ce qu'on avait imaginé ensemble.

Et ça, contrairement aux licornes, ça se prévoit !