Pour aller à la rencontre des prestataires et discuter de votre projet d’application, il est préférable d’avoir un cahier des charges. Plus celui-ci sera précis, plus le prestataire pourra vous fournir une estimation précise de la faisabilité, du temps et du coût de réalisation de votre application mobile ou web.

Sur le principe, tout le monde est d’accord sur l’intérêt d’un cahier des charges, mais dans les faits, la question est souvent : « oui, mais qu’est-ce que je mets dans ce cahier des charges ? »

Pour vous aider, voici une liste non exhaustive de ce que vous pouvez indiquer dans votre cahier des charges. Cela pourra vous inspirer, mais c’est à vous de vous l’approprier et de le compléter selon vos besoins. Pas d’inquiétude, il s’agira simplement d’une première version que nous travaillerons ensemble.

 

Quelques détails essentiels

  • Les versions

Il est conseillé de tenir un tableau récapitulatif, des différentes versions et de leurs dates, pour suivre plus facilement les évolutions du projet.

  • Le sommaire

Il permet au lecteur d’avoir une première vue d’ensemble du projet. Même s’il peut sembler être un simple outil de navigation, il est en fait une première lecture du cahier des charges.

  • Lexique

Votre métier nécessite peut-être d’utiliser des mots techniques que nous sommes susceptibles de ne pas comprendre. Pas de soucis, il suffit simplement de prévoir un rapide lexique.

 

Contexte du projet

  • Présentation de l’entreprise

Cette partie est parfois négligée, parfois très fournie. À vous de trouver le bon ratio. N’en faites pas trop, mais n’oubliez pas de dire l’essentiel pour que les acteurs du projet comprennent bien tous les enjeux.

  • Les objectifs du projet
    • Qualitatifs : le rôle de l’application, les solutions que l’application apporte, l’innovation d’usage pour l’utilisateur…
    • Quantitatifs : nombre de téléchargements, volume d’achats in-app, fréquence d’utilisation…
  • Les cibles du projets
    • Les cibles marketing
    • Les cibles d’usage : les Personas (Personnages imaginaires auxquels l’on attribue un nom, un âge, une profession, des habitudes d’achats…)
  • Les interfaces existantes
    • Site responsive, Web app, POC, refonte d’une application existante…

De quels interfaces disposez-vous ? Vont-elles être remplacées par l’application ? Devront-elles interagir avec l’application ? L’idéal est de décrire l’éco-système actuel et la façon dont l’application pourra s’y intégrer. Pour cette partie, un schéma est souvent bien plus clair que de longues phrases.

    • La concurrence

Si concurrence, il est intéressant d’exposer vos différenciations par rapport aux usages et fonctionnalités apportés par vos concurrents.

  • La présentation du projet
    • La ou les plateforme(s) : iOS, Android, web…
    • L’équipement : mobile, tablette (format portrait, paysage ou les 2). S’il s’agit d’un équipement unique parce que l’ensemble de la société sera équipée avec le même smartphone ou la même tablette, il faut le préciser.
    • Modèle économique : application gratuite ou payante, abonnement, vente de produits, publicité…
    • Le résultat attendu : souhaitez-vous un POC à présenter aux investisseurs ou un produit fini à mettre sur le marché ?

 

la description du projet

Description fonctionnelle

Il s’agit de décrire toutes les fonctionnalités que vous allez apporter à l’utilisateur

  • Le parcours utilisateur

Il peut se décrire via un schéma, une liste d’écrans auxquels il va accéder, ou encore des users stories (Phrases décrivant simplement une fonctionnalité à développer). À vous d’utiliser la méthode qui vous convient, mais un schéma ou de simples croquis sont parfois beaucoup plus complets que de longs discours.

  • Les fonctionnalités
    La liste peut-être très longue, et peut vous paraître redondante avec l’étape précédente, mais mieux vaut ne rien oublier. Voici quelques idées :

    • compte utilisateur, connexion avec Facebook ou Google,
    • accès sans connexion au contenu, consultation hors ligne, restriction de contenu,
    • commenter un contenu, le mettre en favori,
    • invitation d’amis, messagerie,
    • localisation, cartographie,
    • microphone,
    • appareil photo, scan de QRcode,
    • bluetooth,
    • système de paiement, code promo,
    • moteur de recherche, filtre,
    • agenda, rappel,
    • notifications push,

Pour ne rien oublier, la liste des fonctionnalités peut-être faite à côté de chaque écran lors de la description du parcours utilisateur.

 

Back office

Dans une première version de l’application, il est parfois préférable de ne rien administrer ou très peu de choses. Il peut s’avérer coûteux de réaliser un back office, il est parfois conseillé de tester son application et de réaliser les changements directement dans l’application avant d’investir dans un back office d’administration.

Lister dans votre cahier des charges les fonctionnalités que vous souhaitez retrouver dans votre back office, en précisant éventuellement qu’il est envisageable de le réaliser seulement dans une 2ème version de l’application. Il est aussi possible de prioriser vos besoins.

Les éléments à décrire sont par exemple :

  • le nombre et le type d’accès : administrateur, rédacteur, lecteur…
  • les éléments de contenu à pouvoir administrer
  • la gestion des comptes utilisateurs : modifier les identifiants, prolonger un abonnement…
  • les exports nécessaires

Il est souvent tentant de vouloir tout administrer, mais il est important de s’interroger sur son besoin réel : il sera toujours possible de le faire évoluer par la suite.

 

Contraintes techniques ou spécificités non-fonctionnelles

Elles peuvent être aussi diverses que variées, voici quelques éléments que l’on retrouve le plus souvent.

  • Les services tiers

À quoi faudra t-il connecter l’application ?  Un CRM, un ERP, une base de données, un outil de mailing ou de sms, un système d’information…

  • Compatibilité

Avec quelles versions d’OS ou de navigateur l’application doit elle être compatible ? Si vous n’avez pas de contrainte particulière, il est préférable de demander le conseil de votre prestataire plutôt qu’imposer une contrainte potentiellement irréalisable.

  • Sécurité

Tous les prestataires s’engagent désormais sur une conception « RGPD friendly ». Vous restez cependant responsable du traitement des données de vos clients, alors autant demander clairement ce dont vous avez besoin.

  • Hébergement

Vous pouvez gérer votre hébergement en direct ou demander à l’agence qui réalise votre application de le faire, c’est à vous de voir !

Attention, certains types de données demandent un hébergement spécifique comme les données de santé.

 

Eléments graphiques

  • Charte graphique

Elle est bien sûr à transmettre. Si vous n’en n’avez pas, vous pouvez déjà lister l’ensemble des éléments à votre disposition : logo, couleurs, typo…. Si vous n’avez rien, ce n’est pas grave, mais pensez à le signaler.

  • Maquettes

Des premières maquettes (ou croquis) ont pu être réalisées dans le cadre d’un POC ou simplement pour illustrer facilement les éléments attendus.

  • Sources d’inspiration

Il est parfois difficile de décrire ses attentes en terme de design, mais il y a toujours des éléments qui nous plaisent (ou pas) dans d’autres interfaces. C’est le moment de les lister (liens, captures d’écrans…) et d’indiquer ce qui vous plaît dans chacun de ces exemples.

 

Pilotage

  • Prestations attendues

Est-ce qu’il s’agit de conception, graphisme, développement, etc ?  Tout cela à la fois ?

  • Planning

On pense souvent à la date de fin, mais n’oubliez pas de donner une date de début de projet. Il peut parfois se dérouler beaucoup de temps entre une consultation et le lancement effectif d’un projet.

Il y a bien sûr la deadline ; notamment si votre application est associée à un événement. Si ce n’est pas le cas, nous ne conseillons pas d’imposer une deadline pour la deadline. Cela peut être contre productif en terme de résultats attendus ; pour faire un produit qualitatif, il faut prendre le temps qu’il faut.

  • Budget

On pense souvent que donner un budget va fausser la proposition du prestataire. Cela lui permettra surtout de vous faire une proposition cohérente. Imaginez-vous consulter un agent immobilier sans donner de budget pour votre projet ; les chances d’être satisfait par sa proposition sont bien moindres.

  • Contacts

Qui contacter pour quelle question ?

  • Eléments de réponses  attendus

Méthodologie, proposition technique, planning…

 

La rédaction du cahier des charges

Vous disposez désormais d’un première liste d’éléments à indiquer. Bien sûr, il n’est pas nécessaire d’avoir un cahier des charges exhaustif dès le début du projet. Ce document peut doit se construire de façon itérative, pour affiner petit à petit votre besoin, jusqu’à obtenir la description d’une première version du projet d’application. Alors, n’attendez pas d’avoir un cahier des charges parfait pour nous consulter. Une première version simple d’expression des besoins, vous permettra d’obtenir une première approche du coût et du planning de votre projet d’application.

Ne cherchez pas non plus à concevoir votre interface finale pour le cahier des charges. Nous sommes là pour vous apporter notre savoir-faire et nos conseils. Décrivez ce que vous avez en tête en vous aidant de cette liste, et comptez sur nous pour agencer toutes ces idées.

Voilà, à vous de nous décrire votre besoin désormais !

Couverture du livre blanc de Mobizel
Livre blanc : Quel choix technologique pour mon application mobile ?
Télécharger