Votre page facebook manque d'animation?

Suite à quelques interrogations, et contrairement à ce que nous avions prévu coté articles de blogs, j’aimerais revenir et préciser la détermination des besoins du client, probablement vous, lecteur. Cerner les besoins, c’est bien, les formaliser pour pouvoir faire un cahier des charges précis et solide, c’est mieux. C’est l’assurance d’éviter de mauvaises surprises.

Il faut savoir que 25% des applications mobiles installées ne sont pas utilisées et 26% sont désinstallées après une première utilisation.

Google, 2015

Ces chiffres restent plus faibles lorsqu’il s’agit d’une application mobile métier, vu que les salariés peuvent être contraints d’utiliser l’outil malgré tout, cependant, cela aura un impact mesurable sur leur productivité et leur engagement. Un salarié mécontent, ralenti par un outil mal conçu, travaillera mal et cela ne sera pas de sa faute.
Voyons ensemble 10 règles à respecter pour éviter de se fourvoyer et perdre temps et argent.
Ces règles vous guident pour rédiger l’expression de vos besoins.

L’expression des besoins doit être concise

Le document est destiné à toutes les personnes impliquées dans votre projet d’application mobile et permettra de rédiger un cahier des charges pertinent. Il doit être précis, concis et synthétique.

Il faut que cela soit factuel, avec des phrases courtes et décrire le fait et non la solution envisagée.Vous avez besoin de saisir, par exemple, la commande du client, pas d’un formulaire pour choisir dans une liste le produit commandé par le client, un champ de saisie pour le nombre d’article et un bouton pour valider qui envoie une requête au serveur Web.
Le document ne doit pas dépasser dans la majorité des cas cinq pages. Vous pouvez aussi ajouter des maquettes des écrans pour clarifier votre demande. Pas besoin d’une illustration précise, juste éclaircir le besoin.

Vous pouvez désigner une personne, un « chef de projet » qui rédigera ce document, sur base des remontées des besoins (vues dans l’article précédent) ou demander à un prestataire externe de le faire.
Cette solution, qui a un coût ( Takotek peut vous accompagner dans ce processus, n’hésitez-pas à nous contacter), a comme avantage de permettre une prise de recul par rapport au métier: cela évite de garder « le nez dans le guidon » durant une phase critique du projet.
La qualité de l’expression des besoins est la différence entre une application métier utilisée et productive et une application métier qui a été un gaspillage de temps et d’argent.

Les erreurs courantes

• Se concentrer sur le « comment faire? »
• Anticiper la conception technique et la solution au besoin
• Se contredire ou être trop vague
• Laisser de la place à l’interprétation par chaque lecteur du document
• Abandonner la rédaction du document en se disant qu’il n’y a pas de solution
• Considérer tout comme prioritaire et donc n’avoir rien de plus prioritaire que le reste

Ne pas confondre « expression des besoins » et « cahier des charges »

Comme déjà évoquer et pourtant probablement nécessaire de le rappeler, ces deux documents sont différents et l’un permet de créer l’autre sur des bases solides.

Quelles sont les différences entre les deux documents ?

• L’expression des besoins est non–contractuelle, c’est une base pour la suite, rien de plus.
• Elle doit être concise contrairement au cahier des charges qui doit être le plus précis et détaillé possible, notamment parce que ce dernier est contractuel et est un document à valeur juridique.
• L’expression des besoins est un document vivant, ouvert à l’ajout de fonctionnalités. Il faut laisser à tout le monde la possibilité de proposer des choses. Une sélection des besoins prioritaires pourra être faite et le tri fait avant la rédaction du cahier des charges.
• L’expression des besoins recense les besoins, elle ne formalise pas les solutions contrairement au cahier des charges.

Délimiter le contexte de votre projet

Ne perdez pas de vue et exprimez votre positionnement stratégique et vos objectifs.

Pendant ce processus, vous devez également vous poser quelques questions.

• Qui peut vous aider ? Quels partenaires peuvent y participer ? Qu’est ce qu’il est possible de faire ?
• Avez-vous les ressources humains, financières et matérielles pour mener à bien ce projet ?
• Avez-vous le temps pour ce projet ?
• N’y a-t-il pas déjà une solution existante qui réponde à vos besoins ?
• Est-ce qu’une application mobile est acceptable parmi les utilisateurs prévus de votre logiciel ?
• Quels sont les bénéfices que vous avez envisagé d’en tirer ?
• Quels sont les conséquences sur votre organisation d’un échec de ce projet ?

Il faut également vérifier le cadre réglementaire et la légalité de ce que vous envisagez.

• L’outil respecte-t-il les lois en vigueur ? (RGPD, Droit Commercial, Droit du Travail…)
• Possédez-vous les autorisations nécessaires? Par exemple, il faut pour certaines choses faire des déclarations à la CNIL.

Les échéances du projet

Tout projet a un début et une fin, par définition. Il faut donc penser la temporalité du projet, cela sera d’ailleurs un élément critique du cahier des charges et de l’acceptabilité, ou non, de la proposition commerciale d’un prestataire chargé de réaliser l’application.
Voici les questions se poser.

• Quand est-ce que le projet peut commencer ?
• Avez-vous une date limite pour la livraison du produit fini ?
• Quelles sont les disponibilités des personnes impliquées dans le projet ?

Qui va utiliser votre application mobile ?

Il est fondamental de déterminer et connaître les utilisateurs futur de l’application. C’est cela qui va déterminer beaucoup de choses, notamment en terme d’ergonomie.

Qui sont les utilisateurs de mon service ?

• Des entreprises ?
• Vos salariés ?
• Des particuliers ?
• Des agriculteurs ?
• Des associations ?
• Combien seront-t-ils ?

Quelle est leur typologie ?

• Particuliers: genre, age, catégorie socio-professionnelle, lieu de résidence, habitudes de consommations, agilité avec l’outil numérique…
• Entreprises: secteur, taille de l’entreprise, stratégie de développement, international, maturité digitale…

Qui décide de l’achat ?

Il est très important de savoir qui décide de l’achat de l’application: ce n’est pas forcément l’utilisateur qui décide. Si vous commandez une application pour votre entreprise qui sera utilisé par les enfants de vos clients, c’est le parent qu’il faut convaincre.
Si c’est une entreprise, cela peut être le service RH ou logistique suivant l’application. Si c’est pour une utilisation en interne, qui signe la commande au prestataire ?

Y a -t-il une saisonnalité dans l’achat ?

Lorsque vous vendez cette application, si ce n’est pas pour un usage interne, est-ce que la période de l’année impacte sur sa commercialisation et / ou son utilisation ?

Description des besoins fonctionnels

Pour préparer le cahier des charges, il faut commencer, succinctement, à récapituler les fonctionnalités demandées à l’application. Il est conseillé de les numéroter et les prioriser, surtout si des contraintes en ressortent.
Si par exemple, vous devez gérer les informations de votre application, il sera nécessaire de développer un back-office – un espace de gestion, qui devra être décrit dans votre cahier des charges. De ce fait, il devra être précisé lors de la rédaction de votre expression de besoins également.
Rappelez également, il ne faut pas le perdre de vue, le but recherché en développant cette application mobile.

Exemple: mon application permet à mes utilisateurs de louer du matériel de bricolage

GESTION DES UTILISATEURS

A01	les utilisateurs s’inscrivent sur la plateforme
A02	Les utilisateurs doivent se connecter pour réserver du matériel
A03	Les utilisateurs peuvent se connecter via les réseaux sociaux

GESTION DU MATÉRIEL

B01	Tout le monde peut voir la liste du matériel qui peut être loué
B02	L’utilisateur connecté peut sélectionner des matériels disponibles pour les louer
B03	L’utilisateur valider sa sélection et paie via CB et Mobile sa location…

Prévoir le futur

On peut déjà penser à ce stade des évolutions futures. L’enjeu est quand même d’avoir une première version viable dans un délai raisonnable. Voyons le type d’évolutions qui peuvent être prévues.

• Évolution fonctionnelles: les fonctions prévues évoluent et se voient enrichies
• Évolution du périmètre: l’utilisation de l’application est étendue à d’autres types d’utilisateurs
• Réplication du modèle: le modèle est appliqué à d’autres filiales ou d’autres cibles similaires.

Spécifier le contexte technique

Au contraire, vous pouvez vouloir que l’application soit utilisable sur tous les supports possibles. Cela a des implications au niveau des choix de solution techniques. N’hésitez pas à lire notre article sur la technologie FLUTTER particulièrement adaptée dans ce dernier cas.

D’autres besoins techniques sont déjà déterminés de votre coté.

• Y-a-t’il besoin d’une connexion internet?
• Doit-t-on utiliser la géolocalisation, les capteurs du smartphone?
• Voulez-vous intégrer une solution de paiement ?
• …

Il faudra également signaler si vous avez une identité visuelle déjà pensée et transmettre au prestataire les éléments nécessaires (codes couleur, logos…).

Contraintes spécifiques du projet

Techniques

Les contraintes techniques ont pour but de vous questionner sur vos besoins en termes d’administration de données, de trafic, d’exploitation, etc.

• Faut-il prévoir des connexions simultanées sur votre application ? Quel volume ?
• Votre application web ou mobile requiert-elle un espace de gestion pour modifier, ajouter ou supprimer des données ?

Humaines

Les ressources humaines nécessaires à votre projet sont-elles suffisantes ? Avez-vous besoin de faire appel à des prestataires ?

Réglementaires

Si vous êtes régi par un cadre réglementaire spécial, il est primordial de lister les normes à respecter.

Financières

Il se peut que vous ayez des contraintes financières, précisez-les dans votre expression de besoins.

Liées au marché

Une solution existe-t-elle déjà sur le marché ? Si c’est le cas, quelle valeur ajoutée apportez-vous avec votre projet ?

Liées à la nature de la prestation

Avez-vous des contraintes spécifiques à votre métier ?

En agro-alimentaire par exemple, un process qualité spécifique est obligatoire. Il devra alors être complètement intégré à l’application sans négliger des étapes.

Réfléchir aux impacts de votre application mobile

Votre application aura certainement des impacts en termes de communication, d’organisation, de gamme ou encore de support.

Pour compléter votre expression de besoins fonctionnel, anticipez les différents impacts collatéraux qui pourraient survenir.

• Devez-vous prévoir des sessions de formations spéciales pour vos équipes ?
• Votre communication web devra-t-elle être adaptée ?
• Cette application aura-t-elle des impacts sur des logiciels existants ?
• Faut-il mettre en place des dispositifs ou des équipes pour une assistance auprès de vos utilisateurs ?

Le mot de la fin

En répondant à ces points dans l’expression de vos besoins, vous aurez tout les éléments pour un cahier des charges complet, rigoureux et bien pensé. Tout ce qu’il faut pour éviter les dépassements de budget, les retards ou pire le gaspillage d’énergie et d’argent à faire développer une application qui ne sera pas utilisée.
A bientôt pour la prochaine étape, le cahier des charges et l’évaluation du coût d’un projet !