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. 😉

Ressources récentes