Vous avez donc une idée et une certaine direction (ou vous avez été chargé) de lancer une nouvelle application Web ou mobile, mais vous ne savez pas trop comment procéder. Bien que vous puissiez penser qu’un cahier des charges n’est pas nécessaire, il fait généralement partie intégrante de la définition des objectifs et des contraintes de votre projet.
Les cahiers des charges de projets numériques sont de formes et de tailles diverses, et il y a plus d’une bonne façon de les aborder. Certains sont énormes et d’autres sont minuscules. Certains exigent tous les détails, tandis que d’autres ne demandent qu’une vue d’ensemble. Un fait indiscutable, cependant, est que les cahiers des charges d’applications font partie intégrante de la réussite du projet. Qu’il soit destiné à votre équipe de projet interne ou que vous fassiez appel à une agence externe, un briefing vous obligera, en tant que maître d’œuvre et votre équipe, à être vraiment intentionnel quant à la raison et au but de votre projet.
Les cahiers des charges d’applications Web et mobiles ne sont pas la seule étape, mais ils sont la première phase de définition du projet. Si vous souhaitez lancer un projet, qu’il s’agisse d’une application Web, d’une application mobile ou même de fonctionnalités supplémentaires pour des propriétés existantes, vous êtes au bon endroit. En gardant cela à l’esprit, voyons d’abord pourquoi nous avons besoin d’un cahier des charges avant de voir à quoi il ressemble.
Pourquoi mon cahier des charges doit-il être détaillé ?
Vous n’achèteriez pas une maison sans définir ce dont vous avez besoin, n’est-ce pas ? Je veux dire, si vous appelez un agent immobilier et dites » Yo, donne-moi une maison » et que vous raccrochez, Dieu sait ce que vous obtiendrez. Vous pourriez obtenir une boîte en carton, un manoir avec deux majordomes, ou n’importe quoi d’autre, car l’achat n’a pas été réfléchi et aucun paramètre n’a été donné à l’agent immobilier. Le même raisonnement s’applique aux applications web et mobiles (dont certaines coûtent aussi cher, voire beaucoup plus, que votre maison).
C’est pourquoi nous avons besoin de cahiers des charges. Ils nous obligent, en tant que maîtres d’ouvrage, à réfléchir et à valider les éléments d’information clés d’un projet. Ils nous obligent à réfléchir au pourquoi, au quoi, au comment et au quand d’un projet qui pourrait comporter un grand nombre de risques (et, espérons-le, de récompenses). Il permet d’accéder aux informations nécessaires à la validation et à la discussion du projet – que ce soit avec votre patron, votre équipe interne ou une agence – et, idéalement, il donne une orientation à toutes les parties prenantes tout au long de la vie du projet. Cela peut sembler idiot, mais il est facile de s’écarter de quelques degrés de la route lorsque vous êtes au fond de la forêt ; puis, des kilomètres plus tard, vous vous retrouvez au mauvais endroit. Oups.
Un cahier des charges correctement exécuté et mis à jour permet d’éviter cela.
Comment et quand utiliser un cahier des charges pour le Web ou les applications mobiles ?
Il existe trois situations clés dans lesquelles les exposés de projet sont extrêmement utiles :
1/ Présenter un projet à vos supérieurs ou à vos collègues. Passez un peu de temps à créer un briefing réfléchi, informé et concis, et vous serez en mesure de défendre efficacement votre projet auprès de votre patron (occupé) ou de vos coéquipiers.
2/ Approvisionnement. Si vous avez le feu vert pour le projet mais que vous devez embaucher des experts pour le mener à bien, un dossier de projet donnera aux agences ou aux équipes internes un bon point de départ pour la phase de découverte. À partir de là, les deux parties peuvent poser des questions éclairées et la découverte du projet peut commencer.
3/ Tout au long de la vie du projet. L’énoncé de projet n’est pas un document à rédiger au début du projet, puis à laisser pourrir dans votre dossier Dropbox ou Drive. Au contraire, il faut s’y référer en permanence pendant toute la durée du projet. Ils servent de guide pour la réussite du projet, la prise de décision historique (oui, ils devraient être mis à jour avec des notes), et des informations supplémentaires au fur et à mesure que la phase de découverte du projet avance.
Quel contenu doit figurer dans votre cahier des charges ?
Il n’y a pas d’exigences strictes quant au contenu d’un dossier de projet, mais il contient habituellement des informations telles que :
I/ Présentation
1) Aperçu de l’entreprise
2) Objectifs de l’application ou du site web
3) Cible adressée par l’application ou le site web
4) Objectifs quantitatifs
5) Type d’application et de supports
6) Périmètre du projet
II/ Graphisme et ergonomie
1) Charte graphique
2) Wireframe / maquette
III/ Spécificités et livrables attendus
1) Parcours utilisateurs et contenus de l’application
2) Contraintes techniques
3) Livrables attendus
4) Planning
5) Budget
6) Décisionnaires sur le projet
7) Autres informations et documents utiles
I/ Présentation
1. Aperçu de l’entreprise
Cette section est simplement un descriptif de votre entreprise ou organisation, bien que si votre organisation est assez grande, elle pourrait également être utilisée pour décrire la branche de l’entreprise à laquelle l’application web ou mobile est spécifique. Voici un exemple :
[L’entreprise] est une société de technologie pharmaceutique située à Paris, qui se spécialise dans la recherche et le développement de produits pharmaceutiques de pointe. Avec plus de 500 employés, [Entreprise] est bien établie dans son domaine, puisqu’elle existe depuis 2001. Vous trouverez de plus amples informations sur son site Web à l’adresse www.url.com.
2. Objectifs de l’application ou du site web
Cette section est un résumé du projet/type de travail requis, et pourquoi. Quel est le problème ? Quel est l’objectif global de l’outil ? Voici un exemple :
[L’entreprise] a besoin d’une nouvelle application mobile : planification, stratégie, prototypage, conception, développement, contenu, tests d’assurance qualité et d’analyse, etc. De nombreux utilisateurs de [l’entreprise] sont sur le terrain, ce qui rend difficile l’accès aux ressources et à la gestion de la facturation dont ils ont besoin via un ordinateur de bureau ou le site web existant qui ne répond pas. L'[Entreprise] est passée à un nouveau CRM en 2016, qui devra être intégré à la nouvelle application mobile.
3. Cible adressée par l’application ou le site web
Cette section doit présenter les parties prenantes de l’outil. Qui seront les utilisateurs ? Quelles seront les fonctionnalités principales de chaque parcours ?
[L’entreprise] cherche à intégrer tous les collaborateurs sur ce nouvel outil. L’idée est d’ouvrir la gestion de projet au plus grand nombre. Cela se fera notamment par l’ajout de certaines fonctionnalités rendant la planification plus « ludique”. Les chercheurs pourront ainsi suivre en direct les résultats des campagnes de crowdfunding pour chaque produits pharmaceutiques. L’approvisionnement en matériel au siège de [l’entreprise] se fera en direct d’après les montants alloués à chaque projet.
4. Objectifs quantitatifs
Les objectifs quantitatifs représentent les chiffres espérés à une date fixée. Combien d’utilisateurs espérés ? A quelle échéance ?
[L’entreprise] souhaite que tous les collaborateurs utilisent l’application, soit 450 chercheurs, 40 employés de logistique, 10 RH, dans les 12 mois suivants la sortie de l’application.
5. Type d’application et de supports
Il s’agit ici de lister les différents types d’applications (mobile, web, site internet web et/ou mobile…) et les différents types de devices (smartphone, tablette, ordinateur…). Les systèmes d’exploitation (iOS, Android…) ou les langages de programmation (PHP, .NET, …) souhaités devront être ici mentionnés au besoin
[L’entreprise] a besoin d’une application mobile pour les chercheurs et les employés de logistique. Un format desktop pour vue sur ordinateur sera nécessaire pour les RH.
6. Périmètre du projet
Cette section permet de présenter les fonctionnalités principales par utilisateur.
[L’entreprise] souhaite actuellement une application en français uniquement. Les chercheurs devront pouvoir consulter leur soldes de financement de recherche et faire appel à des dons supplémentaires. Ils auront également la possibilité de télécharger des comptes rendus de leurs campagnes de recherche. Les employés de logistique pourront suivre les livraisons en direct et émettre des bons de commandes. Ils auront accès à un historique des livraisons et à l’édition de bons de commandes. Les RH auront davantage un rôle d’administrateur avec la possibilité d’ajouter/retirer de nouveaux utilisateurs. En ce qui concerne les comptes, il faudra permettre aux utilisateurs de se connecter à leur session directement à l’ouverture de l’application.
II/ Graphisme et ergonomie
1. Charte graphique
Listing des couleurs souhaitées et de la police de caractère. Présentation d’un moodboard des styles d’applications inspirantes. Description de l’ambiance à donner à l’application.
Le logo de [L’entreprise] a les couleurs suivantes : Jaune : #ffde59 ; Or : #c8a929 ; Blanc #fffff ; et nous souhaitons donc reprendre ces couleurs pour le design de l’outil.
La police de caractère actuellement utilisée est «roboto (light/regular/bold).ttf »
Nous voulons une application qui reprenne le style de Hubspot, avec un style épuré et des couleurs chaudes. Notre but est d’utiliser une interface reprenant des codes connus et associés à une expérience utilisateur fluide et sans fioritures.
2. Wireframe / maquette
Vous pouvez insérer ici des wireframes, des schémas ou des pages de maquettes expliquant les principales fonctionnalités souhaitées.
III/ Spécificités et livrables attendus
1. Parcours utilisateurs et contenus de l’application
Description des parcours et des principales fonctionnalités par parcours/
L’application de [L’entreprise] comprendra 3 parcours (chercheurs, employé logistique, RH).
Le parcours chercheur comprendra un tableau de suivi des études, un formulaire de demande d’approvisionnement en matériel, un espace de gestion de profil.
Le parcours employé logistique comprendra un espace de gestion de stocks, un tableau de suivi de commandes, un espace de gestion de profil.
Le parcours RH comprendra un espace de gestion des comptes, de suivi des médicaments, de gestion des congés, et un tableau récapitulatif des données statistiques globales.
2. Contraintes techniques
Détaillez ici les prérequis techniques, de maintenance, de technologie…
[L’entreprise] souhaite bénéficier d’une maintenance de l’application après le déploiement. L’application devra être évolutive avec des capacités d’intégration rapide de nouvelles fonctionnalités. Un développement mobile de la partie RH pourra être envisagé dans un second temps. Un développement en Node JS serait préférable pour relier l’outil à notre CRM.
3. Livrables attendus
Décrivez ici les livrables souhaités afin d’aider l’agence de développement à réaliser un devis détaillé et ajusté.
[L’entreprise] souhaite voir apparaître dans votre devis, la présentation de votre société, le calendrier de réalisation, le coût de la maintenance, les garanties, le détail du prix de maquette, le détail du prix de développement.
4. Planning
Cette partie du briefing peut être un simple résumé de haut niveau du calendrier du projet. Si vous voulez entrer dans les détails des délais pour des livrables et des phases spécifiques, n’hésitez pas, mais il y a généralement trop d’hypothèses à ce stade précoce du jeu. C’est pourquoi nous suggérons un calendrier de haut niveau à ce stade. Il peut se lire comme suit :
L’application mobile doit être testée, stable et lancée sur le serveur de production avant le [date] afin de s’inscrire dans le cadre de l’exercice fiscal en cours et de s’aligner sur les dates clés du plan marketing de [entreprise].
5. Budget
Cette section est ce qu’elle semble être – il s’agit simplement d’une description du budget du projet, que vous avez, je l’espère, mis en place.
[L’entreprise] a alloué un budget de XXX,XXX $ pour ce projet (toutes taxes, services, licences, etc. compris) et un budget de XX,XXX $ pour un an d’hébergement, d’assistance et de maintenance après le lancement.
6. Décisionnaires sur le projet
Nommez ici les décisionnaires sur le projet, en renseignant leurs coordonnées et fonctions.
[L’entreprise] a nommé comme responsable du projet:
Jean Bartos – Directeur général – jean.bartos@laboris.com – 06XXXXXXXX
Sophie Van Risel – Directrice achats – sophie.vr@laboris.com – 06XXXXXXXX
7. Autres informations et documents utiles
Décrivez ici toute autre information complémentaire pouvant aider à la bonne compréhension de votre projet. Vous pouvez également ajouter des documents expliquant votre besoin, vos enjeux…
