Pourquoi vos cahiers des charges finissent tous dans ma🗑️?

Après plus de 10 ans à analyser des demandes de clients pour la conception de projets web et autant d’années à jeter leur cahier des charges avant de tout reprendre depuis le début, j’ai envie de vous partager ma réflexion personnelle sur le sujet.

Que vous ayez un projet web à conduire en interne avec votre équipe ou besoin de confier la réalisation de votre projet à une agence de développement, vous allez devoir spécifier vos attentes, ce qui se traduira probablement par la rédaction d’un cahier des charges.

C’est souvent à ce niveau-là que les problèmes commencent. En effet, le cahier des charges (CDC) est vu comme la Bible de votre projet. Beaucoup en font une spécification initiale qui explique ce qu’il faut faire, voir comment le faire. D’autres y exposent les conditions d’un contrat qui fixera le cadre d’une collaboration entre le porteur de projet (MOA) et l’équipe technique (MOE). Dans tous les cas, ce cahier des charges sera ressorti en fin de projet pour distribuer les bons points et les punitions. Mon point de vue est que, malheureusement, les conditions de réussite du projet n’y sont pas réunies :

• QUI ? Le cahier des charges est réalisé par le client. Est-ce que cette personne seule à toutes les informations et toutes les compétences pour définir ce que l’on doit réaliser ?
  
• QUAND ? Le cahier des charges est réalisé avant le début du projet. Est-ce le bon moment pour savoir ce qui répondra vraiment aux besoins des utilisateurs finaux ?
• POURQUOI ? Le cahier des charges définit ce qui doit ou ne doit pas être fait. En d’autres termes, il peut être vu comme une checklist des conditions à suivre pour finir avec succès le projet. Cependant, cette démarche tournée « exécution » ne serait-elle pas le meilleur moyen de se priver des conseils d’un professionnel ?
  
• COMMENT ? Le cahier des charges est souvent le fruit d’une recherche Google « Modèle de cahier des charges », complété scolairement, saupoudré de quelques buzzwords et rempli d’évidence (Ex : « Le site web doit être simple et ergonomique. » 🙄). Si le cahier des charges est vu comme une spécification, alors il devrait être la suite d’un processus d’analyse et d’étude des besoins.
  

La confiance règne !

Disons les choses, j’ai rarement vu un cahier des charges de client indiquant clairement que nous aurions carte blanche pour concevoir l’application de ses rêves, ou qu’il nous fera confiance.

Parfois, certains clients précisent qu’un conseil ne serait pas de refus mais la plupart nous expliquent surtout que l’on doit être parfait, ne pas faire d’erreur, prévoir l’imprévisible mais surtout suivre les consignes du cahier des charges à la lettre.

Un client qui n’a pas confiance fera un cahier des charges pour se protéger.

Le Prestataire devra obligatoirement respecter les dates proposées dans le planning de réalisation. Tout retard, entraînera l’application de pénalités financières.

Et sinon, on disrupte le monde maintenant ou on continue les politesses ? 😏

Toutefois, si les clients n’ont pas confiance lorsqu’ils recherchent un prestataire de développement, n’est-ce pas justement à cause des nombreux prestataires peu fiables qui abusent de leur position d’experts ?

Cependant, pouvons-nous travailler correctement avec un porteur de projet si nous ne nous faisons pas confiance ? Si notre document de travail est un contrat que l’on ressortira à chaque erreur pour désigner un coupable ?

C’est pas ma faute à moi !

Changeons de point de vue. Un prestataire qui n’a pas confiance demandera aussi un cahier des charges pour se protéger. Et oui, tout comme le porteur de projet, certains prestataires chercheront aussi à se protéger d’un éventuel conflit plutôt que d’assumer une responsabilité sur le projet.

Soyez donc très vigilent à ce que vous mettez dans vos cahiers des charges car ils pourront se retourner contre vous si votre prestataire est peu scrupuleux.

En effet, si vous définissez des choses dans votre cahier des charges, vous allez attendre de votre prestataire (ou de votre équipe) qu’il les réalise en suivant vos conditions. Par contre, si ces demandes sont techniquement aberrantes, c’est bien vous qui devrez en assumer l’échec.

Par exemple, faisons le parallèle avec la construction d’une maison. En tant que client (MOA), si vous faites appel à un architecte, vous pouvez lui donner un cahier des charges précisant que vous souhaitez cinq chambres, deux salles de bain et un style plutôt contemporain. Toutefois, prendriez-vous le risque de préciser quel mur doit être porteur ou à quel endroit placer une poutre ?

Vous commencez à comprendre l’idée ? 😉

Finalement, certains prestataires voient un cahier des charges comme une garantie de ne pas être responsable du résultat. Comme toute checklist, l’objectif est de valider chaque demande sans forcément réfléchir à la finalité.

Et si vous passiez à côté des conseils d’un professionnel ?

Les cahiers des charges nous disent trop souvent ce que l’on doit faire, sauf qu’en tant que professionnel, nous avons énormément de conseils à vous donner. Malheureusement, que ce soit en interne ou en externe, si vous présentez votre projet de manière directive, vous risquez de mettre toute l’équipe dans une position d’exécutant.

Vous risquez fortement d’obtenir ce que vous avez demandé, mais est-ce vraiment dont vous avez besoin ? Est-ce vraiment ce dont vos utilisateurs auront besoin ? Je ne pense pas…

L’idéal serait donc de travailler main dans la main avec l’équipe de développement, en toute confiance, pour co-spécifier et co-concevoir un produit qui répondra aux attentes des utilisateurs. Vous êtes convaincu, mettez vos cahiers des charges à la 🗑️!

L’expression de besoins (et de contraintes)

Vous venez de jeter votre cahier des charges à la poubelle, vous êtes heureux et libéré de ce poids, de ce document dans lequel vous aviez mis des mots que vous ne compreniez pas forcément. Vous êtes donc prêt à partir sur une nouvelle base sur laquelle vous serez beaucoup plus à l’aise et qui ne vous enfermera pas dans des choix techniques.

Au lieu du cahier des charges qui contenait tout et surtout n’importe quoi, contentez-vous déjà de réfléchir aux éléments suivants :

• Le pourquoi du projet
  Le contexte et la problématique qui ont déclenché le projet
  
• Les objectifs du projet
  La situation dans laquelle on devrait idéalement se retrouver en fin de projet
  
• Les critères de réussite du projet
  Qu’est-ce qui fait que le projet sera une réussite et créera de la valeur pour votre entreprise (par pitié, penser à des critères de satisfaction utilisateur plutôt que de pilotage de projet, de délai, etc)
  
• Expression de besoins / cas d’utilisation
  Cette partie est la plus dense. Vous devez expliquer avec vos mots chacun de vos besoins. Pensez d’un point de vue utilisateur, ne soyez pas faussement technique et essayez d’être exhaustif.
  
• Contraintes du projet
  Listez les vraies contraintes de votre projet. Les contraintes sont toutes les conditions qui font que le projet « idéal » ne pourra pas avoir lieu. Par exemple, le budget n’est ni plus ni moins qu’une contrainte qui doit être réaliste. La date de livraison attendue peut aussi être une contrainte mais attention à ne pas en fixer une arbitrairement. Chacune des contraintes forcera l’équipe à faire des compromis donc ne vous inventez pas des contraintes qui n’existent pas.
• Documentation technique
  Si le projet à un volet technique, par exemple une intégration à un système existant, n’hésitez pas à fournir la documentation du logiciel, de l’API, etc.

👍 À retenir : prenez soin de ne pas écrire de solution mais bien des problématiques ou des besoins. C’est à la portée de tout le monde et vous ne prenez pas de risques.

Organisez vos besoins et idées

Maintenant que vous n’avez plus de cahier des charges, vous n’avez plus besoin d’arbitrer sur les fonctionnalités qui doivent rentrer dans le cahier des charges initial de celles qui devront attendre la prochaine version.

Vous pouvez donc classer vos attentes parmi 3 listes (illustré par des exemples d’une application todolist) :

• Les besoins : les besoins correspondent à des demandes qui répondent à une problématique concrète.
  Par exemple, une tâche peut être associée à un tag pour être filtrée
  
• Les nécessités : les nécessités sont des besoins qui doivent obligatoirement être développés pour que le projet ait une raison d’exister. Sans eux, votre projet perd tout son sens.
  Par exemple, une tâche peut être marquée comme terminée.
• Les idées : les idées correspondent à des choses qui seront à discuter plus tard. En listant vos idées, vous pouvez donner à l’équipe une vision des évolutions possibles sans perdre du temps à discuter de sujet qui ne sont pas d’actualité au démarrage. Cette liste pourra être complétée au fur et à mesure de l’avancement du projet.
  Par exemple, une tâche peut être créée automatiquement par l’envoi d’un mail sur une adresse spécifique.
  

Les designers, développeurs sont vos amis, il faut les aimer aussi

Je ne peux pas terminer cet article sur le tableau pessimiste que j’ai dressé au départ. Tous les prestataires, développeurs ou designers ne vont pas chercher à vous jeter la faute. Toutefois, je voulais vous alerter sur ce risque qui est bien réel et que je constate régulièrement à travers les témoignages de nos clients.

Les équipes de designers et développeurs sont majoritairement des gens passionnés qui veulent être fiers de leur travail et qui ne demandent qu’à vous conseiller, échanger des idées et à réaliser un projet de qualité.

Que ça soit en interne ou par le biais d’un prestataire, il est important d’établir rapidement une relation de confiance et d’écoute mutuelle. La communication avec une équipe projet est une condition importante dans la réussite de votre projet.

👍 À retenir / En bref

• Ne faites plus de cahier des charges (au sens spécification), contentez-vous d’une expression de besoin,
• Ne formulez plus de solutions mais des besoins, des contraintes et des objectifs,
• Ne soyez pas faussement technique. Si vous ne connaissez pas un terme, ne l’employez pas et demandez à ce qu’on vous l’explique,
• Ne mettez pas votre équipe de développement dans un rôle purement exécutif, vous vous priverez de leur précieux conseils,
• Misez sur la confiance et la collaboration au sein de l’équipe plutôt que sur des clauses contractuelles,
• Méfiez-vous des prestataires qui ne vous conseillent pas et attendent que vous spécifiez tous les aspects du projet. L’assistance à maitrise d’ouvrage (AMOA) est une nécessité dans la réussite d’un projet web,
• Organisez vos besoins en 3 listes : nécessités (impossible à retirer), besoins (utile pour le projet), et idées (à discuter plus tard)
• Définissez des objectifs et des critères de réussite pour votre projet. Ils doivent être créateur de valeur et non être basés sur des conditions contractuelles.

J’espère que cet article vous a intéressé. N’hésitez pas à réagir et à le partager, j’essaierais de le faire évoluer en fonction de vos questions et vos remarques. 😉