Projet digital : rédiger son cahier des charges

05/10/2018

Aucun commentaire

Nous avons déjà abordé dans un précédent article les premiers fondements d’un projet digital : définition des objectifs, des cibles et analyse de l’existant. La base étant solide, il est maintenant temps de rentrer dans le vif du sujet : la phase de spécifications.
On nous demande souvent de fournir un cahier des charges « type » pour que le porteur de projet puisse s’en inspirer et le « remplir ». C’est possible en partie, et un jour prochain nous le ferons certainement (quand nous aurons le temps ahaha !) mais il faut garder en tête que chaque projet est unique et son cahier des charges l’est tout autant.
Le but du jeu (et du post) sera donc de déterminer les points essentiels et les pistes pour rédiger des spécifications aussi utiles que possible. J’utilise à dessein le mot « utile » plutôt que « complète » car un document trop verbeux peut nuire paradoxalement à la bonne compréhension du projet. Parlons peu, mais parlons bien.

Le bûcheron et l’entonnoir

 OK, c’est bien joli tout ça, mais devant une feuille blanche on se sent parfois désarmé. Les idées se bousculent – par quoi commencer ?
Il existe plein de techniques pour rendre ça ludique… post-it battle, brainstorming, idéation et plein de mots marketing qui sonnent bien.
Chez TPZ on a rien contre les jolis mots mais on a une approche un peu plus « bûcheron ». Généralement on utilise la technique de l’entonnoir : partir du plus évident, du plus macro pour se rapprocher du plus fin, du micro. On peut aussi visualiser ça sous forme d’arborescence. On part du tronc de l’arbre et on remonte petit à petit ses multiples ramifications.
Le premier niveau permettra de faire le squelette du cahier des charges, ou son sommaire. Chaque niveau supplémentaire permet de dérouler les fonctionnalités en rentrant dans le détail.
Exemple :
Niveau 1 : mon site web est composé d’une home page, d’une page services, d’une page équipe et d’une page de contact. (C’est la base de mon sommaire).
Niveau 2 : la home page comprend 3 sections : une zone d’introduction, une zone services et un bloc contactez-moi. (Refaire l’exercice pour chaque page).
Niveau 3 : la zone d’introduction est composée d’un titre H1, d’un texte et d’une image full screen. La zone services remonte 3 blocs qui pointeront vers des ancres dans la page Services. Le bloc contactez-moi est composé d’une photo de fond et d’un bouton qui renvoie vers la page de contact. (Propager sur les autres pages).
Niveau 4 : les blocs de la zone services sont composés d’une icône et d’un texte, le tout cliquable.
Ce petit exercice nous permet de rédiger assez simplement une ébauche de cahier des charges. Ici on est sur un exemple de site vitrine relativement restreint… mais en travaillant sur des applications métier complexes le nombre de niveaux va vite monter assez haut. On peut alors explorer une branche jusqu’à son niveau le plus fin avant de passer à une autre.

Le diable se cache dans les détails

Notre cahier des charges commence à se construire, c’est une bonne chose. Mais revenons un instant au fondamental : quelle est la finalité du document ?
1/ détailler les spécifications : c’est à dire fixer – et figer – les fonctionnalités du projet.
2/ identifier les zones d’ombre : en rentrant dans le détail c’est le moment d’identifier ce qui est bancal ou incomplet.
3/ anticiper les choix technologiques : la vision fine du cahier des charges permettra de valider (ou infirmer) les technologies pressenties.
4/ chiffrer in fine le projet (coût / délais) pour valider un budget ou réduire le périmètre projet
5/ préparer le boulot de l’équipe technique.  Le but est que le tout soit digeste et compréhensible pour les développeurs dès qu’ils attaquent le codage.
L’exercice va donc consister à imaginer les différents aspects d’une fonctionnalité et les différents cas d’utilisation de celle-ci – y compris si l’utilisateur se trompe (contrôles de formulaire par exemple). C’est là où les persona définis précédemment vont rentrer en jeu : on se projète en tant que tel ou tel persona pour imaginer son parcours et ses attentes.
Malgré tout, il reste difficile d’anticiper tous les comportements et tous les éléments lié à une fonctionnalité. C’est là qu’interviennent la wireframe, le meilleur ami du développeur, du chef de projet, de l’UX/UI* designer, du stagiaire et du livreur de pizza.

Mon empire pour une wireframe

Disons-le tout net, derrière ce nom barbare se cache un élément si déterminant que nous allons y consacrer un article entier. Mais en trois mot, les wireframes sont des schémas fonctionnels des écrans. Ils permettent de placer les différents blocs, call-to-action, zones de texte, menus etc sur un écran, sans aller jusqu’à la maquette au design leché qui prend beaucoup plus de temps.
Chez TPZ (et j’imagine un peu partout à travers le monde), on considère que les wireframes sont désormais incontournables pour la bonne compréhension d’un projet.
Les phases de wireframing et de rédaction du CDC peuvent être menées en parallèle. Elle viennent s’auto-alimenter l’une / l’autre. Cela demande un vrai travail d’équipe !  Les développeurs sont également mis à contribution pour identifier les contraintes techniques ou les points particulièrement ardus.
Le cahier des charges permettra aussi le chiffrage du projet, dans le détail. Attention, il n’est pas rare qu’une fois le CDC complet, le budget se révèle plus lourd qu’un chiffrage « macro » initial. Les vision micro permettent surtout un découpage précis des fonctionnalités.

Gestion de projet et agilité

La vision de rédaction du CDC décrite ici peut sembler se projeter sur une gestion de projet en V (traditionnelle). En réalité, il peut tout à fait permettre une gestion de projet agile scrum, kanban ou scrumban**. Le découpage en fonctionnalités se fait naturellement et permet d’alimenter un backlog agile. Du reste, chez TPZ nous travaillons à partir d’un backlog synthétique. Nous détaillons ensuite verbalement pour construire le cahier des charges.
En conclusion, la rédaction du CDC est une étape à la fois cruciale et incontournable pour un projet réussi. Un cahier des charges trop vague entraînera à coup sûr des problèmes en phase de développement et des répercussions négatives sur l’équipe technique et le porteur de projet : mauvais choix technologiques, contraintes non anticipées, chiffrage trop bas, délais mal maîtrisés, consommation excessive de café, insomnies chroniques engendrant une dégradation d’humeur notable et dans le pire des cas une inscription à Koh-Lanta pour fuir une réalité distordue.
Pour éviter d’en arriver là, nous pouvons vous accompagner avec plaisir sur votre phase d’AMOA – même si on a rien contre Kho-Lanta !
Réactions épidermiques et conseils avisés sont les bienvenus en commentaire : promis j’y répondrai dès que j’ai terminé mon café 🙂
*Vous confondez UX et UI ? Vous ne savez pas du tout de quoi on parle ? Un super article là dessus : UX et UI, ce n’est pas pareil
** Scrum, Kanban et leur fusion Scrumban sont des méthodologies de gestion de projet modernes. Il faudrait qu’on fasse un article dessus d’ailleurs, en attendant celui-ci est pas mal du tout : Du Scrum au Scrumban