Cahier des charges: le Kamoulox de la gestion de projet web
Publié le 18 May 2009, par Babozor dans la catégorie Gestion de projetAller petit rappel des faits pour ceux qui ne connaissent ce merveilleux jeu qu’est le Kamoulox, avant de s’attaquer au sujet du jour: le cahier des charges (fonctionnel principalement)
Attention article pouvant heurter la sensibilité des Chefs de projets…
Remettre le cahier des charges dans son contexte
La première chose à faire avant de pouvoir traiter le contenu à proprement parlé du Cahier des charges est de le remettre dans son contexte.
Pour un cahier des charges produit par une agence pour un client, ce document poursuit un double but: sceller dans la pierre (ou dans le document word pour être plus précis) un accord entre un client et un prestataire, mais surtout continuer l’action des commerciaux… essayer de vendre du rêve, ou l’impossible (au choix, voir les deux).
Pour un cahier des charges produit par le client final, il répond à certaines contraintes (marketing, vente, design) qui sont souvent très éloignés de la réalité du web, plus proche d’un doux rêve que d’une réelle plateforme web ou d’un site d’e-commerce.
Rédigé par un chef de projet fonctionnel
La deuxième chose qui fait que je ne considère pas le cahier des charges comme un document sérieux, provient des personnes qui le rédigent. Sans être supra langue de pute, disons que beaucoup de Chefs de projets d’agence y sont parachutés sans expérience et avec peu voir pas de culture web. Si par chance votre chef de projet à de la culture web et de l’expérience (et on s’en réjouit), il lui manquera la compétence technique pour pouvoir valider la faisabilité dans le temps imparti… vous pouvez faire appel à un profil technique pour le valider, peu le font… et encore le profil technique n’aura pas le temps et/ou l’envie de se pencher à fond sur le travail du CdP.
Enfin je crois que j’ai été suffisamment méchant sur ce point (je le rappelles, je n’ai rien contre les Chefs de projets, juste contre le cahier des charges)
Un fantasme du site/application plus qu’une réalité
Car voilà ce qu’est réellement le cahier des charges, un fantasme à un temps T par rapport à un besoin ou un projet, ni plus ni moins… un projet web est une entité vivante (en fonction des contraintes, des gens qui y participent, tout cela bougeant dans le temps) et se dire qu’on peut bloquer les fonctionnalités à une liste réductible et parfaitement définissable est une utopie. Simplement le fait de monter certaines pages nous montre les incohérences du cahier des charges, certains points oubliés, des passages ergonomiquement discutable, rien de bien dramatique à cela, si ce n’est que ce n’est qu’en le réalisant qu’on s’en rend compte (et donc adieu aux 87 pages de votre joli cahier des charges)
Un bon moyen de fixer certaines idées… guère plus
Alors, un cahier des charges ça sert à quoi? (puisque je viens de le détruire de façon plus ou moins méthodique)
Non, ça ne sert pas à rien… cela sert surtout comme base de travail et de réflexion pour votre futur site ou application web, puisque juste après avoir eut votre idée lumineuse ou vendu telle ou telle presta, il faut surtout mettre les choses noir sur blanc pour tester votre concept, tenter de passer de l’idée à la conceptualisation.
Penser que le cahier des charges est la réponse à tous vos problèmes est illusoire, penser que cela sera la bible de votre projet aussi… votre projet durant sa phase de conception et réalisation va beaucoup bouger, donc plutôt que de passer du temps à rédiger et peaufiner un document qui au final ira en grande majorité à la poubelle, consacrez du temps à gérer votre projet (réflexion, gestion de l’équipe, suivi du client, etc.)
Et vous, vous en pensez quoi du cahier des charges… quelle utilité? (et j’aimerais bien entendre l’avis des chefs de projets sur le coup)
le 18 May 2009 à 21h58
Un cahier des charges c’est bien, mais les méthodes agiles c’est pas mal aussi.
le 18 May 2009 à 23h00
Pas vraiment de CDC pour nous mais plutôt des storyboard qui synthétisent l’application.
Par contre, pour rebondir à ce que tu dis sur les CDP Fonctionnels et la partie technique, c’est là qu’intervient le CDP Technique (quand il y en a un) qui étudie et valide la faisabilité avec le CDP Fonctionnel. Enfin dans l’idéal
Pas compris le rapport avec le Kamoulox, mais ça fait toujours plaisir de le voir
le 19 May 2009 à 06h51
Je trouve que ça a au moins le mérite de fixer les limites de la prestation à réaliser de manière à ce que le client ne change pas tout en cours de route.
le 19 May 2009 à 08h38
voici mes (déjà ancienne) réflexions sur le sujet
http://www.glagla.org/weblog/2008/01/28/acheter-des-prestations-informatiques-2-le-cahier-des-charges/
le 19 May 2009 à 09h00
D’accord avec Rémi, les storyboards sont souvent le parent pauvre de la conception.
On peut avoir des beaux cahiers des charges, mais si à la fin le formulaire d’inscription au service truc a été mal pensé et que le cheminement entre le point de départ et la validation finale est développé au fur et à mesure par des informaticiens pas payés pour réfléchir à la conception utilisateur, alors c’est la catastrophe.
Des storyboards bien pensés, une arborescence réfléchie, une terminologie claire et voilà déjà un bon morceau de fait.
Sinon, ce qui me gave le plus dans les CDC, ce sont ces grandes introductions inutiles qui rappellent le contexte, la vie de la société, les contraintes… Enfin bref, surtout en interne, aucun intérêt.
le 19 May 2009 à 12h58
Je ne suis pas trop d’accord avec toi.
Le CDC permet de poser les limites du projet.
Je le vois comme la réécriture de la proposition commerciale, par une personne ayant un profil “web”.
Une proposition commerciale est souvent un document qui vend du rêve. On idéalise toutes les parties, un peu comme une publicité.
Le CDC, lui, va lister ce que le projet comprend, en étant un peu plus précis sur la manière de faire les choses, et surtout en étant plus réaliste.
Il va aussi ajouter la dimension technique, car il sera validé par un Responsable technique.
En paralèlle au CDC, il convient de livrer rapidement un wireframe, qui va encore une fois préciser les fonctionnalités du cahier des charges, en posant les briques de l’ergonomie.
@nathalie :
C’est clair que les intros de CDC sont souvent bien inutiles ^^
Tous ces points ayant été abordés en propositions commerciales.
Je précise que je ne suis pas du tout chef de projet.
Je fais part de mon expérience en tant que Responsable technique.
Sinon, je suis d’accord qu’il faut parfois se battre, pour qu’on écoute la technique lors de la réalisation du CDC.
Mais ma position était claire la dessus :
- Soit je valide et donc je m’engage à ce que le CDC soit réalisable.
- Soit on ne me demande rien, et dans ce cas, je ne prend pas la responsabilité d’un éventuel échec. Pareil si mon avis est écarté.
PS : merci pour Kamoulox
le 19 May 2009 à 14h35
D’accord sur un seul point celles et ceux qui écrivent le CDC sont souvent incompétents techniquement (voir fonctionnellement). C’est même une idée de site Web : toutes les conneries pondus dans les sites Web.
Mais j’ai encore une bonne estime du CDC, sans doute par mon expérience en SSII. Et merci de ne pas réduire le document à un Power Point (on devrait même interdire cette application) où ne figure uniquement les créas (souvent tout autant stupides), les storys ou même juste des zonings.
Qui n’a jamais été obligé d’inventer une fonction pour un bouton qui avait été placé par un DA qui trouvait l’interface vide ? Qui n’a jamais été obliger d’expliquer à un client que “non, la typo CowBoy Sans-serif Bord n’est pas une typo utilisable sur son navigateur ?” Qui ne s’est jamais retrouvé à chambouler (et donc perdre du temps) sur son dev parce que le Workflow de création de compte n’avait pas été spécifié par un CDC ?
le 19 May 2009 à 22h57
Je ne crois pas que le CDC soit inutile que cela. Il a pour fonction et seulement celle là de présenter un besoin en mettant le contexte dans lequel il a été pensé. Il permet à l’agence (maître d’oeuvre) de savoir ce qu’elle va développer mais aussi de définir comment elle doit développer. Il servira aux chef de projet de base de travail pour un plan projet. C’est ce plan projet dont les équipes de développement peuvent avoir besoin, et encore je ne suis pas sûr, disons qu’il leur parlera plus car là ont été ajouté la faisabilité, les solutions adoptées…
Et d’ailleurs il n’est pas destiné à tout le monde ce cahier des charges…
le 20 May 2009 à 05h00
Avec le temps je m’aperçois que le célèbre cahier des charges (certains lui donnent valeur de saint graal donc on pourrais l’écrire avec des guillemets ad vitam : “le cahier des charges”), ne m’a jamais servi qu’à chopper le contenu de la page pour le coller dans le template … sic.
le 20 May 2009 à 11h09
Ma vision SSII…
Concernant le CDC, je n’en produit que rarement en tant que “fonctionnelle” (sauf en AMOA pour les appel d’offre). Le CDC est comme évoqué plus haut “la liste au Père Noël… d’où justement les incohérences techniques.
Le client à envie de rêver son appli, et ne valide souvent le CDC produit par ses presta que s’il y a la ligne soulignant la présence de telle abbération fonctionnelle au sein du documents.
Et puisqu’en général on n’est pas juge est parti (rare en AMOA que la boite qui rédige le CDC soit retenue pour la conception), on a tendance à éluder les point qui seront bloquants dans la rédaction des SFD.
C’est plutôt lors des phases de rédaction des specifications fonctionnelles générales et détaillées qu’on met les mains dans la technique et la faisabilité.
Le storyboard est un peu le “Oui-Oui” pour le client : c’est écrit gros, illustré, il comprend mieux a quoi servent telle ou telle fonctionnalités… et de quelle manière un enchainement peut être possible et cohérent (ou pas).
De plus c’est bien pratique pour les intégrateurs, plutôt que de se farcir 80 pages de SFD (souvent mal écrites et paraphrasées…. à croire que le client achète souvent les spec au kilo :p)
Je d’ailleurs suis surprise que certaines équipes de dev travaillent sans spécifications fonctionnelles front et back office (au mieux validée par un CDP tech… ce qui est vraiment rare…). Ca doit juste être l’enfer pour arbitrer certain points…
Quant aux méthodes agiles, pour la tester actuellement en prod, je trouve que c’est une vraie perte de temps et d’énergie… Est elle vraiment adaptée aux phases de développement ?
le 20 May 2009 à 13h51
Je suis sans doute devenu le roi des casses couilles, mais je veux trouver dans le document (et y appuyer mon dev) :
- tous les champs des formulaires, les contraintes qui s’y appliquent, les messages d’erreurs qui s’affichent (où et pourquoi)
- les différents workflow (pas une succession de screencap où l’on ne sait pas ce qui doit être persisté, les contrôles, les webservices appelés)
- la fiabilité
- etc.
Appelez le comme vous voulez, mais je n’en peux plus de passer des jours à modifier, supprimer ou ajouter des fonctions sans qu’elles aient été précédemment spécifiées.
note : je viens de voir un projet être annulé par le client parce qu’il ne lui convenait pas (et pourtant il avait validé les créas).
le 24 May 2009 à 16h39
J’ai l’impression que
1 – On confond cahier des charges et spécifications fonctionnelles
et
2 – Il est toujours utile de préciser si on se situe côté agence (maitrise d’œuvre) ou côté client (maitrise d’ouvrage).
Et pour remettre ma réponse dans le contexte, je parle de mon expérience en tant que chargée de projets avant-vente (réponse aux appels d’offre) et chef de projets fonctionnel en agence.
Je n’ai jamais rédigé de cahier des charges : j’ai lu ceux soumis par le client, j’en ai longuement discuté avec eux pendant des réunions pour rédiger des spécifications fonctionnelles détaillés -j’insiste sur le mot détaillées- validées à la fois par le client et par l’équipe technique de l’agence.
Donc tout ce que tu dis sur le cahier des charges est vrai : c’est une liste au père Noël, pleine d’incohérences, rédigée par quelqu’un qui n’a souvent que de très vagues connaissances techniques et ça sert essentiellement à fixer les grandes lignes du projet.
Les développeurs ne voient jamais le cahier des charges, leur travail est basé sur les spécifications fonctionnelles qui en sont issues. Et dans le meilleur des cas, sur les spécifications techniques elles-mêmes issues des specs fonctionnelles.
En plus d’être la référence pour les développements, les specs ont une valeur juridique. Quant à la livraison du projet le client hurle parce qu’une fonctionnalité ne fait pas ce qu’il voulait, c’est toujours agréable de lui répondre “Si, regardez, c’est écrit là et il y a votre signature en bas de la page”.
le 25 October 2010 à 22h17
Bonjour,
Consultant IT mais aussi webmaster du site http://www.codeurmania.com, j’ai l’occasion de voir passer beaucoup de cahiers des charges, devis, analyses fonctionnelles ou techniques durant la journée (et mes soirées).
Sujet très intéressant que le “cahier des charges” ou plus “le fantasme d’un cahier des charges”. Il est vrai que beaucoup de porteurs de projets voient en ce document la bible de leur projet alors que ce n’est qu’une première ébauche.
Je dirais que le cahier des charges peut être réellement utile si d’une part il décrit fonctionnellement les besoins du site web (ou de l’application) mais si d’autre part il est couplé à une analyse technique précise.
Trop souvent des budgets sont rapidement estimés sur base d’un document imprécis et/ou incomplet d’où des surprises très désagréables lors de la réalisation (extension de la durée de réalisation, explosion du budget, mésentente sur certains points).
L’idéal serait donc que le porteur de projet réalise un cahier des charges très fonctionnel puis qu’il fasse appel à un webmaster qui, avant de lui remettre un devis, puisse fixer précisément les besoins en développement et en temps.
Cela permet de fixer les besoins fonctionnels par le client, le faire comprendre au webmaster qui lui fixera sur papier sa charge de travail. Chacun se voit donc responsabilisé!