Livre Blanc
Modèle de cahier des charges pour une Plateformes Web

Comment rédiger un cahier des charges pour réussir votre plateforme Web ? Guide Gratuit

La rédaction d’un cahier des charges est toujours laborieuse mais fondamentale à la réussite de votre projet !

Dans ce guide, découvrez :

  • Les éléments de réflexions préalables
  • Comment présenter votre projet ?
  • Comment décrire les étapes fonctionnelles de votre plateforme Web ?
  • Comment réussir votre migration et votre intégration ?
Ce livre blanc propose un modèle de cahier des charges que vous pourrez suivre.

Introduction

Ce livre blanc a pour objectif de préciser quels éléments doivent être détaillés dans le cahier des charges de votre plateforme web. Il propose un modèle que vous pouvez suivre, que vous ayez envie de lancer un appel d’offres auprès de prestataires, ou que vous vous en serviez en interne pour le diffuser auprès de votre DSI. Il détaille un plan type et les questions que vous devez vous poser lorsque vous rédigez votre cahier des charges. Ce livre blanc est utile pour de nombreux projets du site web vitrine (dans ce cas-là, il suffira de retirer certains éléments), jusqu’à une plateforme web complète.

Ce livre blanc est composé de deux documents : un modèle de cahier des charges qui propose un document vierge, ainsi qu’un guide qui pourra vous accompagner dans votre réflexion puis votre rédaction.

Éléments de réflexions préalable

D’abord, qu’est-ce qu’une plateforme web ?

Pour schématiser, une plateforme web est une application constituée de plusieurs briques dont la complexité peut varier, mais qui peuvent être catégorisées de la manière suivante :

  • un site public qui présente des contenus permettant de vous faire connaître du public ;
  • un tunnel de transformation qui peut prendre des formes assez diverses : depuis la simple page d’offres (pensez aux pages d’abonnement par exemple) jusqu’à de nombreuses étapes qui comprennent, par exemple, des pages de collecte de données, un simulateur ou encore un tarificateur (des domaines tels que l’assurance ou l’énergie) ;
  • un espace connecté où votre client peut retrouver les interactions qu’il a eues avec vous : consommation, commandes, documents contractuels etc ;
  • un espace administrateur ou back-office qui permet de gérer les différents contenus, paramétrer les éléments associés à vos offres, faire le lien avec les données de votre SI et enfin proposer différents tableaux de bord pour piloter votre activité.

Ce schéma doit être adapté en fonction de votre activité. En particulier si vous avez un business B2B2C (ce qui est relativement fréquent dans le web), vous devrez doubler la partie supérieure du schéma pour prendre en compte les deux cibles auxquelles vous vous adressez.

Vous avez une bonne idée de ce que vous voulez faire ? Vous avez listé vos fonctionnalités ? Vous avez fait un schéma de ce que vous voulez voir dans votre plateforme ? Il est temps de les confronter à vos objectifs.

Puis, bien définir vos objectifs !

Bien souvent, le projet de développement d’une plateforme naît d’une intuition : “Avec un nouveau site web, nos clients trouverons plus facilement des réponses à leurs questions et nous pourrions également en conquérir de nouveaux prospects plus facilement !” et c’est souvent vrai !

Alors, on commence à travailler et on imagine beaucoup de fonctionnalités que l’on trouve géniales et absolument indispensables. C’est le moment de se méfier ! Il s’agit du syndrome “le plus est le mieux” : lorsque l’on raisonne avec un budget contraint, il y a une tendance naturelle à souhaiter le maximum de fonctionnalités, offrir la plateforme la plus complète possible. L’expérience de The Coding Machine montre souvent que l’approche “mettre en œuvre le nécessaire” est préférable. Il est souvent plus intéressant de privilégier quelques fonctions clés et les approfondir pour faire en sorte que vos prospects/clients les adoptent et les comprennent facilement. C’est toute la philosophie d’un lancement MVP – Minimum Viable Product -.

En effet, le risque est de développer pour le plaisir beaucoup de choses inutiles. Non seulement vous allez payer ces développements mais vos équipes vont passer également beaucoup de temps à les concevoir et les tester ! Alors pour ne pas avoir les yeux plus gros que le ventre, il faut chercher à articuler vos objectifs avec les fonctionnalités de votre plateforme. Pour répondre à la phrase d’introduction, nous pourrions imaginer :

  • telles fonctions doivent permettre de réorienter mes clients vers le selfcare, donc de diminuer les appels vers ma plateforme de 5% et ainsi économiser un coût annuel de X milliers d’euros;
  • la mise en place d’un tunnel de conversion optimisé doit me permettre de transformer Y% de mes visiteurs sur cette nouvelle offre donc générer un chiffre d’affaires de Z milliers d’euros.

La plupart des fonctionnalités doivent servir un ou plusieurs objectifs. Grâce à ces objectifs, vous allez pouvoir déterminer ce qui est indispensable de ce qui ne l’est pas. Vous pourrez aussi les hiérarchiser pour définir votre roadmap.

En plus, une fois mis en place, ces objectifs vous permettront de mieux gérer votre activité. Vous saurez quels sont les efforts à faire pour les améliorer s’ils ne sont pas atteints parce qu’un projet de plateforme web n’est jamais vraiment terminée.

Si vos objectifs ne sont pas encore clairs, pour vous aider à y réfléchir, il y a deux familles de gains possibles :

  • Les objectifs associés au développement de l’activité : lancer un nouveau business, étendre le business actuel… Ils sont en général en lien avec la partie site public ou tunnel de transformation ;
  • Les objectifs associés aux économies : réduire le temps de traitement, faciliter le travail des collaborateurs, réduire les sollicitations… ils se reflètent dans la plupart des cas dans la partie connectée de votre plateforme ;

Il y aussi dernier type d’objectifs qui est souvent plus dur à quantifier mais qui n’est pas négligeable : les gains associés à la qualité de l’information ou la structuration des processus.

Vos  objectifs  sont  clairs,  bien  définis  ?  Passons  à  un  autre  sujet  ardu  :   la technique !

Comprendre et effectuer les choix techniques

Penser que la technique ne vous concerne pas serait une grossière erreur même si vous n’y connaissez rien ! Évidemment, le sujet peut faire peur à certains mais ne pas prendre le temps d’y réfléchir peut poser deux problèmes : être limité par la technique : à un moment, plus tard, vous souhaiterez développer une nouvelle fonctionnalité et, si vous avez fait un mauvais choix, ce développement pourra vous coûter extrêmement cher !

Il y a aussi une forte tentation à l’universalisme : une solution a déjà été développée dans un autre service, pourquoi ne pas continuer sur la même plateforme ? Une solution open source ou du marché propose une très large palette fonctionnelle, pourquoi ne pas partir avec ? Bref, beaucoup de raccourcis qui sont dangereux parce que si la solution n’est pas parfaitement adaptée à la plateforme web que vous souhaitez, il y a de fortes chances de rencontrer de grosses difficultés (nous intervenons sur beaucoup de projets à cause de mauvais choix).

Notre conviction est qu’il faut choisir la solution technique en fonction des fonctionnalités que vous souhaitez et surtout pas l’inverse. Ne laissez pasla technique aux experts. Lors de votre appel d’offres ou de vos réunions internes faites-vous expliquer tous les points qui vous semblent obscurs, demandez des choix argumentés et n’acceptez aucune solution a priori !

Il est difficile de donner un panorama complet de toutes les technologies possibles. Pour tenter malgré tout de vous donner une quelques idées générales : il y a les CMS (Content Management System) qui conviennent généralement assez bien aux sites de contenus et où le besoin d’un espace connecté est faible ou inexistant. Il peut s’agir de Drupal ou WordPress par exemple.

Il y a ensuite les solutions qui offrent plus de souplesse pour gérer le design, l’expérience offerte aux utilisateurs de votre plateforme. Elles présentent des APIs qui peuvent être consommées par différents devices (web ou mobile). Ces solutions sont appelées headless CMS. Il peut s’agir par exemple de Strapi ou Prismic.io pour les contenus ou Sylius pour le e-Commerce.

Pour les solutions plus complexes ou plus spécifiques, la plupart du temps, une solution sur-mesure est conseillée. La solution technique est donc de développer la solution grâce à une stack (ensemble de composants techniques) complète : framework back (Symfony ou Laravel par exemple), framework front (Vue, React ou Angular par exemple), base de données (MySQL, Mongo).

La technique est devenue votre alliée ? Regardons le sujet d’un peu plus haut. Il est temps de voir le système dans son ensemble.

Pour lire la suite,
télécharger le livre blanc

La rédaction d'un cahier des charges est toujours laborieuse mais fondamentale à la réussite de votre projet !