Comment rédiger un cahier des charges pour une plateforme web
Assurez la réussite de la construction de votre plateforme web.
Disclaimer : cet article est destiné aux entreprises (startups, PMEs …) souhaitant développer une plateforme web (ou mobile). L’article vous donne les clés pour construire un cahier des charges de manière efficace, précise et concise. Le but est de pouvoir obtenir un devis réaliste et juste.
Captain Data a une sa phase “agence web & data”, nous avons donc vu passer bon nombre de cahiers des charges. Vous vous en doutez, si nous avons décidé d’écrire un guide, c’est qu’il y a une bonne raison : la plupart des cahier des charges que nous avons reçu étaient médiocres, voire inexistants.
Cet article s’inscrit dans la continuité de notre série “Construire une plateforme web”.
TL;DR
Vous n’avez pas envie de lire ces +1500 mots rédigés avec amour et bienveillance ? Ça tombe bien, j’ai pensé à vous : voir le spécimen du cahier des charges.
⚠️ Avant de rédiger un cahier des charges, assurez-vous de bien comprendre Pourquoi et comment construire une plateforme web.
Pourquoi rédiger correctement un cahier des charges
On en revient toujours à la même question : pourquoi. Pourquoi devrais-je passer du temps à bien rédiger un cahier des charges ?
La liste de réponses est longue :
1. Ne pas vous faire plumer
Rien de plus facile pour une agence / un freelance que d’augmenter ses tarifs si vous ne savez pas exactement où vous allez et le temps que ça va mettre, sauf si vous les prenez en régie. Mais là, vous risquez de ne pas attirer les meilleures agences et d’élargir le projet sans en voir la fin.
2. Améliorer votre taux de succès
À force de reprendre des projets codés avec les pieds, on pourrait croire que le développement web s’apparente parfois à une science inexacte. Un peu comme la médecine, quand le docteur vous dit “prenez ce médicament, ça ira mieux”… et que ça ne va pas mieux. Un cahier des charges bien rédigé maximisera votre taux de réussite et votre satisfaction, tout en réduisant les risques de retards sur le planning. Et le temps, c’est de l’argent :)
3. Piloter le projet
En tant que commanditaire, vous avez pour rôle de piloter le projet. Si, si, je vous assure! Si vous souhaitez que le projet avance à bon rythme, même si l’agence est efficace et bienveillante, vous avez intérêt à y mettre du vôtre. Seulement, si vous ne savez pas exactement où vous allez et que vous êtes (légèrement ?) perdu, impossible de piloter correctement le projet.
Les guidelines suivantes sont relativement simples :
- Définir les archétypes (les personas) d’utilisateurs
- Définir un premier jet de fonctionnalités en “user stories” (traduction littérale : histoire utilisateur)
- Définir le(s) parcours utilisateur(s)
- Wireframe
- Validation et itération sur les fonctionnalités; vous affinez par rapport au premier jet
- Maquette
- Cahier des charges final
Première étape : les archétypes (personas)
Un archétype utilisateur est une grande catégorie d’utilisateurs, dans laquelle vous allez ranger des typologies d’utilisateurs similaires. Exemple :
- Archétype client : les entreprises de moins de 20 personnes dans le bâtiment
- Archétype utilisateur : les analystes financiers de 20 à 45 ans
- etc.
Un archétype est ni plus ni moins qu’un segment utilisateur, au même titre qu’un segment client. Il est essentiel de bien définir vos archétypes et de se mettre à leur place. Certains processus vous semblent totalement acquis et très compréhensibles (et je vous laisse imaginer que pour le développeur, c’est L-I-M-P-I-D-E), cependant il arrive que l’expérience utilisateur que vous avez imaginée n’est pas la bonne.
Vous devez systématiquement vous projeter vis-à-vis de ces archétypes utilisateurs. Sur chaque module “global” de fonctionnalités (ne rentrez pas dans l’excès pour chaque fonctionnalité !), prenez le temps de vous poser la question suivante :
Comment la fonctionnalité permet à [ARCHÉTYPE UTILISATEUR] de résoudre [SON BESOIN]
Vos premières fonctionnalités
Vous mourez d’envie de rentrer dans le dur; ça tombe bien, il va falloir le faire assez rapidement. Mine de rien, vous savez quand même que vous voulez créer le prochain Airbnb des coiffeurs (“what ?”).
Si vous n’avez pas encore travaillé sur vos fonctionnalités, commencez par créer des modules : mettez des labels sur vos fonctionnalités.
Exemple : “Moteur de recherche”, “Réservation” etc. Vous trierez toutes les fonctionnalités dans chaque module par la suite. Pensez à vos personas, et commencez à écrire des fonctionnalités.
Si vous avez déjà travaillé sur vos fonctionnalités ou que vous avez réalisé l’étape précédente, vous devez maintenant réécrire ces fonctionnalités en USER STORIES. J’insiste énormément là dessus :
- C’est un langage que le développeur comprend
- Ça vous permet d’être parfaitement précis dans la description de la fonctionnalité, et donc d’obtenir un devis beaucoup plus réaliste et juste
- Cela vous permet de hiérarchiser les fonctionnalités
- Cela permet, in fine, de structurer le projet. Je ne vais pas rentrer dans la gestion de projet agile, mais sachez que définir des users stories permet de bien cadrer le projet.
Une user story s’écrit de la façon suivante :
“Un utilisateur [doit] pouvoir [ajouter un produit dans son panier]”.
Si ça vous paraît simple, c’est parce que ça l’est. Mais vous ne pouvez pas savoir à quel point c’est précieux : avec ça, je sais que je vais avoir une action à gérer pour l’utilisateur, une fonctionnalité dans mon backend pour manipuler les données et à le prévoir dans ma base de données.
Les users stories s’écrivent toujours de la même façon :
Un utilisateur [DOIT / DEVRAIT / POURRAIT] pouvoir [faire X]
En anglais, MUST / SHOULD et COULD définissent vos ordres de priorité.
Une fois vos user stories écrites, rangez les dans vos modules.
Parcours utilisateur
Vous avez vos premières fonctionnalités, il s’agit désormais d’imaginer le parcours de l’utilisateur. Vous n’avez pas besoin de maquette ni quoi que ce soit d’autre; juste de créer un schéma. Et pour ça, draw.io est votre ami.
Le parcours utilisateur vous permet de :
- Valider l’enchaînement des fonctionnalités
- Anticiper l’enchaînement des boards (des “vues”) dans votre maquette
Pensez à rajouter un minimum “d’onboarding”, c’est-à-dire à expliquer au maximum à l’utilisateur ce qu’il faut faire à un moment T. Cela peut s’apparenter à envoyer un email au moment de la première connexion, ou à mettre en valeur certains boutons en donnant des explications. Ces petits détails permettent à l’utilisateur de bien comprendre l’application et de l’apprécier d’autant plus.
Wireframe
Je ne comprendrai jamais pourquoi personne ne prend le temps de réaliser cette partie : ce n’est ni plus ni moins qu’un schéma, un dessin, de votre application. N’importe qui, je dis bien n’importe qui, est capable de faire un wireframe. Soit vous le faites avec du papier / crayon, soit vous êtes plus à l’aise et vous utilisez un outil comme balsamiq.
L’idée ici est de rapidement conceptualiser et mettre en oeuvre le parcours utilisateur et les fonctionnalités que vous avez imaginés. Ça peut être très moche, concrètement on s’en moque, cela permet encore une fois de bien structurer le tout.
Valider les fonctionnalités
Arrivé à ce stade, vous avez normalement les idées beaucoup plus claires. Si vous avez l’occasion / prévu de faire valider vos mockups et les fonctionnalités à des utilisateurs potentiels, sautez sur l’occasion. Un test physique en direct est l’idéal.
Sinon, prenez le temps de bien analyser ce que vous avez créé et réfléchissez bien, par rapport à votre proposition de valeur : est-ce que ça match, est-ce que je n’en ai pas trop fait (ma préférée) etc.
L’étape de validation se construit tout au long de la vie du produit. C’est un processus continu, qui fait référence au fait de “Test & Learn”. Il est important de comprendre que votre vision du produit n’est pas forcément (jamais ?) adaptée à celle du client. Et c’est malheureusement le client qui prévaut dans la majeure partie des cas; il ne s’agit pas non plus de tomber dans l’excès et de faire tout en fonction du client à chaque fois qu’il vous demande de rajouter quelque chose.
Je parle plus en détails de la validation dans cet article : “Pourquoi et comment construire une plateforme web”.
Construire sa maquette
Si vous ou quelqu’un de votre équipe maîtrise Sketch ou Photoshop, ces logiciels restent un must. Si vous n’y connaissez rien ou que vous êtes comme moi et que vous avez un baobab dans la main, je vous conseille Marvelapp.
En fait, les mockups suffisent et la maquette est vraiment un plus. Cependant, le fait de pouvoir rentrer dans les détails (code couleur etc.) permet au(x) développeur(s) de ne pas se poser de questions et d’intégrer la maquette comme telle tout en développant les fonctionnalités.
Outre le gain de temps précieux, construire une maquette nécessite d’apporter un regard critique sur l’expérience utilisateur et le parcours, et donc de potentiellement réviser ces derniers.
Finaliser le cahier des charges
Faites-Un-Planning.
Si vous ne savez pas comment faire, vous prenez le nombre de fonctionnalités et vous faites x3. De toute façon, le / les développeurs auront leur mot à dire. Je peux vous garantir qu’en arrivant avec un planning, vous allez avoir un pouvoir de négociation plus grand, même si vous ne savez pas de quoi vous parlez. Très peu de clients arrivent avec une roadmap, et je parle bien d’une roadmap et pas d’un “on est pressé on doit avoir ça pour le mois prochain”.
Vous avez un document complet, il s’agit maintenant de bien le structurer. Rien de plus simple :
- Couverture
- Sommaire (important, si vous mettez les user stories en titre, cela permet d’avoir le listing sous les yeux, directement)
- Définition et scope (périmètre) du projet
- Objectif du projet
- Description des archétypes (bon, globalement la plupart des devs ne regarderont pas cette partie, c’est plus pour vous, vous pouvez la mentionner en annexe)
- Spécifications : le listing de vos user stories
- Expérience utilisateur : parcours utilisateur (votre schéma), maquette
- Spécificités et livrables : contenu, code couleur et tout ce qui va bien, contraintes techniques, hébergement, éventuellement des recommandations techniques sur les technologies
- Roadmap, votre planning: prototype, application, mise en production, recettage
- Annexes
En fonction de la complexité du projet, vous avez un document d’une vingtaine de pages.
Voilà, vous savez tout !
Si vous voulez nous envoyer votre cahier des charges, c’est ici que ça se passe https://captaindata.co ou sur hello@captaindata.co :)
