Guide pour cahier des charges d’une application

C’est une étape souvent négligée mais qui est indispensable au succès d’un développement application web ou mobile : l’expression de besoin et / ou sa version plus précise : le cahier des charges !

Pourquoi faire un cahier des charges ?

Cela vous permet :

• de mettre à plat vos besoins,
• d’envisager un maximum de cas de figure et mieux définir les contours de votre projet,
• d’avoir des chiffrages plus précis auprès des prestataires que vous consulterez,
• d’avoir des offres / devis comparables puisque basés sur le même référentiel,
• d’éviter la plupart des allers-retours, incompréhensions et oublis !
• de mesurer l’écart entre ce qui était attendu et ce qui sera effectivement réalisé !

Pour votre partenaire / prestataire cela permet :

• de mieux appréhender votre activité, votre projet et vos objectifs,
• de sélectionner des socles techniques les plus pertinents possibles,
• éventuellement de trouver des solutions existantes du marché qui répondent aux besoins avec un minimum de développement spécifique (afin de ne pas réinventer la roue !),
• d’anticiper des évolutions à venir.

Liste des tâches pour vous :

Définir le contexte

C’est le contexte dans lequel s’inscrit votre démarche :

• Votre activité et ses spécificités,
• Vos objectifs (et vos objectifs de date de mise en ligne / échéances),
• Vos contraintes (géographiques, budgétaires, organisationnelles, juridiques…) s’il y en a.

Notre métier à nous, c’est le développement d’applis, logiciels et solutions web professionnelles sur mesure !

Nous avons besoin de bien comprendre votre métier ou votre projet, alors n’hésitez pas à bien expliciter ce que vous attendez.

Il y a de grandes chances pour que l’on ait déjà, chez Solstys, réalisé un projet dans votre secteur ou un secteur adjacent à votre activité ou que l’on ait mis en œuvre des mécanismes similaires dans des projets antérieurs.

Définir les conditions, situations et contraintes d’usage

En mobilité ? à partir d’une tablette Android, d’un smartphone Apple, d’un PC, d’un Mac ? De tous ces terminaux à la fois ? En zone de couverture réseau, wifi, satellite pour gps ? Si un terminal précis est à utiliser, en préciser les caractéristiques (taille et orientation écran, éventuellement processeur et RAM), etc…

L’application doit-elle être disponible dans les stores d’applications publics (Google Play et Apple Store) ? Souhaitez-vous en maitriser la diffusion via l’envoi de lien privés à des utilisateurs identifiés ?

Définir les utilisateurs / les cibles de l’application

Ce sont les personnes utilisatrices de la solution, les différents groupes avec des droits homogènes

• collaborateurs ?
• partenaires ?
• administrateurs ?
• utilisateurs de type particulier ? L’application est-elle destinée à un public enfants, ado, adulte etc…?
• quels pays ? quelles langues ? L’application sera-t-elle multilingue tout de suite ? dans un second temps mais c’est à prévoir tout de même dans l’architecture de l’application ?

Définir les fonctionnalités attendues

1) Front-office web ou application mobile

C’est la partie visible par les utilisateurs cibles de l’application. Il faut ici décrire l’ensemble des fonctionnalités, leur séquençage, les conditions pour débloquer les fonctionnalités / options, les interactions possibles entre les utilisateurs etc.

Il faut décrire avec le plus de précisions possibles le scénario complet pour chaque type d’utilisateur et les cas d’usages.

Authentification / connexion

Comment vont s’authentifier les utilisateurs ? Email + mot de passe ? Via la validation de leur numéro de téléphone par un code envoyé par SMS ? Connexion comptes existants et réseaux sociaux et si oui lesquels (Facebook, Google, Apple, LinkedIn, instagram etc..) ?

Tutoriel / Onboarding

Faut-il prévoir pour les nouveaux utilisateurs, après création de leur compte et première connexion, un tutoriel avec les instructions pour bien commencer l’utilisation de l’application ? Écrans fixes qui s’enchaînent ? Vidéo tuto ?

Gestion de profil

Qu’est ce que les utilisateurs vont devoir paramétrer dans leur profil (photo de profil, description, gestion des notifications on/off, géolocalisation on/off etc.)

Mode connecté / non-connecté / avec ou sans GPS etc..

Comment l’application doit se comporter dans ces différents modes ? Doit-on synchroniser des informations, inviter l’utilisateur à se connecter (en wifi et ou en data), à activer son GPS pour continuer ? L’utilisateur doit-il confirmer sa position à un instant t ou à des étapes précises ?

Notifications

Dans quels cas de figures les utilisateurs et l’administrateur doivent-ils être notifiés ? Quel type de notifications et dans quel cas ? Email ? Notifications push système sur le smartphone avec pastilles +1 +2 etc. sur l’icône de l’appli ? Notifications à l’intérieur de l’appli sur certains onglets ? Envoi de SMS ?

Exemple d’autres fonctionnalités :

• géolocalisation automatique, en appuyant sur un bouton ? affichage d’une carte (google, mapbox…) avec points d’intérêts ? quelles actions et affichages selon différents niveaux de zoom…?
• recherche par mot clé, recherche géographique ? calcul d’un itinéraire ?
• tchat, tchat vidéo / audio ?
• chargement photo à partir de la galerie, à partir de la prise directe de photo avec la caméra du smartphone ?
• algorithme de matching ? de scoring ?
• saisie d’informations, de commentaires, chargement de documents, génération pdf, etc…?
• enregistrement audio / vidéo, etc.

2) Back-office

Dans la plupart des projets d’applications mobiles et web, il est nécessaire d’avoir une application web back office réservée à l’administrateur. Cette application peut lui permettre de gérer :

• ses utilisateurs si c’est lui qui doit les créer et ouvrir des accès (tri, recherche, création, suppression, modification…) ?
• la modération (des photos, des messages, des commentaires…) en cas de signalement par exemple ?
• ses tableaux de bord et statistiques (indicateurs clés qui sont importants pour lui)?
• ses paramètres (par exemple un taux TVA, un paramètre variable ou un pourcentage quelconque qui sert à calculer un tarif) ?
• ses exports de fichiers ?

Parfois, selon la fréquence et la criticité des paramétrages, il est plus raisonnable de nous faire changer des paramètres ponctuellement dans le cadre de la maintenance plutôt que de nous faire développer une fonction back-office qui vous rendrait autonome mais qui aurait un coût au niveau mise en œuvre / développement. Tout est question de dosage par rapport aux bénéfices attendus.

Si vous avez un existant avec lequel la nouvelle application doit interagir ou échanger des données, une maquette graphique, des schémas, des captures d’écran, des fichiers excel, des bases de données ou n’importe quel document qui peut nous aider à comprendre plus vite votre besoin, tous ces éléments sont les bienvenus !

Un bon schéma c’est souvent parlant et ça fait gagner du temps ! De la même manière, l’analyse d’un fichier excel que vous utilisez actuellement pour gérer un processus par exemple, peut nous aider à visualiser, anticiper, extrapoler les flux de données et actions utilisateurs à mettre en œuvre dans la future solution logicielle ou applicative.

Monétisation application / business model

Cette question concerne surtout les applications mobiles mais également certaines applications web. Vos choix relatifs au business model et business plan de l’application, même s’ils ne nous regardent pas à priori en tant que développeurs, ont tout de même un impact certain sur le développement puisqu’il faut prévoir tous les mécanismes associés. L’application sera-t-elle payante ? Au moment du téléchargement dans les stores ? Par abonnement mensuel / hebdomadaire ? A l’acte à la souscription d’options payantes ? Y a t’il un système d’achat de pack de crédits ? Après une période d’essai de 3 jours, 1 semaine, 1 mois etc.. ?

Y a t’il plusieurs acteurs / intermédiaires à rémunérer en cas d’achat (système de marketplace par exemple). Y a t’il un système de facturation à mettre en place ? Souhaitez-vous des publicités (quel format, quelle régie etc..)

Les stores ont des règles et il faut prévoir dans certains cas la commission non négligeable due à Google et/ou Apple quand leur système de paiement est utilisé. Les opérateurs carte bleue et autres Stripe ou Paypal prennent également des commissions.

Vous avez besoin d’accompagnement ?

Ecrire un cahier des charges, ce n’est pas quelque chose que vous avez à faire tous les jours et nous le comprenons très bien.

Tous les éléments énumérés ci-dessus ne sont pas obligatoires dans votre cahier des charges et certains points seront définis au fil de l’eau. Certaines fonctionnalités seront peut-être à réserver pour une v2 mais les avoir en tête est toujours utile afin de prévoir l’architecture qui permette plus facilement des les intégrer par la suite.

On peut tout à fait vous accompagner et vous aider à définir vos besoins, de la manière la plus pertinente possible, de manière à ce que vous puissiez avancer dans votre projet, et que de notre côté, nous puissions vous établir une offre la plus adaptée et la plus réaliste possible en termes de budget et de planning. Avant de prendre votre décision, vous avez en effet besoin de savoir où vous allez, quel sera votre retour sur investissement et si les éventuelles échéances que vous vous êtes fixées sont atteignables.

Il est à noter que certains projets, relativement simples, sont tout à fait chiffrables avec un document d’expression de besoin succinct, complété de quelques réunions ou coups de fil pour affiner ensemble.

De manière générale, plus vous êtes précis, plus nous pouvons l’être, en réduisant les fourchettes de budget et de délais !

Maquette animée : La réalisation d’une maquette animée avec l’enchaînement des écrans et la représentation graphique des actions, fonctionnalités et concepts anticipés à ce stade peut être une étape supplémentaire avant le développement en tant que tel. Cela peut être utile pour tester le concept de l’application et son attractivité auprès d’utilisateurs ou de financeurs potentiels sur quelques écrans clés, pour ajuster ou prioriser certaines fonctionnalités plutôt que d’autres et revoir le chiffrage avant le début des développements. Cela permet également d’éviter de devoir refaire des choses dans la phase développement, ce qui va s’avérer bien plus coûteux et long qu’une modification de maquette graphique.

Prototype : C’est une application avec les fonctionnalités essentielles (version 0 aussi appelée MVP minimum viable product), afin de tester en conditions réelles avec des utilisateurs pilotes une faisabilité technique par exemple et qui pourra servir de socle de développement pour la première version de l’application à publier.

N’hésitez pas à nous solliciter ! Selon votre existant, votre niveau d’avancement sur vos spécifications et votre projet, nous affinerons ensemble votre besoin via l’analyse de vos éléments et un jeu de questions / réponses.