Projet digital : site web, app mobile, refonte, par où commencer ?

31/08/2018

Aucun commentaire

Un projet de refonte web, le lancement d’une application mobile, une startup qui naît sur une nouvelle création de valeur : lorsque l’on échange avec les porteurs de projet digital les questions sont toujours les mêmes. Par où commencer ? Comment rédiger son cahier des charges ? Comment ne rien oublier ?

Chez TroisPointZéro, on accompagne des Startups autant que des PME ou des Grands Groupes et la recette reprend toujours les même ingrédients. Rien de mieux qu’une petite suite d’articles de blogs bien digestes pour récapituler tout ça 🙂

Bien sûr, on a pas la prétention de faire la bible du digital ou de pondre un livre blanc bullshit pour récupérer du prospect : chaque projet est unique et les problématiques dépendent autant du contexte que de la personnalité des porteurs de projet. Mais on se dit qu’un porteur de projet averti en vaut deux, alors voyez ça comme un pense-bête synthétique.

Premier volet –  les bases : objectifs, analyse, ciblage.
Second volet – la rédaction du cahier des charges.
Troisième volet – les wireframes.
Quatrième volet – le choix des technologies.

Avant toute chose : définir ses objectifs

On ne lance pas un projet digital pour se faire plaisir, ou alors il ne faut pas espérer en tirer un quelconque bénéfice. Un projet répond à un besoin plus ou moins latent, plus ou moins précis, plus ou moins conscient.
Le plus souvent, le besoin de créer un site web ou une application mobile est primaire : lancement d’un produit, d’un service, création de la société etc. Il n’en est pas moins primordial de définir les attentes vis à vis de ce projet :

  • créer de la notoriété,
  • vendre un produit / un service,
  • toucher des prospect,
  • communiquer / expliquer / délester le support client,
  • recruter…

Parfois, le besoin est plus mécanique : refonte d’un « vieux » site, concurrence accrue sur un secteur… Là encore, il convient de creuser pour identifier ce que l’on souhaite réellement :

  • moderniser l’image digitale,
  • renforcer une expertise en particulier,
  • repositionner l’activité…

Dans tous les cas, il faut identifier et formaliser les objectifs : ce sera l’une des bases de la stratégie digitale au lancement du projet.

Les objectifs peuvent être formulés simplement (de manière verbale) ou définis de manière plus précise et mesurable par des indicateurs clés (les KPI dans le jargon digital) : traffic, transformation, génération de lead, chiffre d’affaire.

Quoiqu’il en soit, les objectifs dépendent étroitement du contexte… Ça tombe bien, c’est le point suivant 😀

Indispensable : analyse de l’existant

 
L’analyse de l’existant permet de formaliser le contexte du projet.

L’existant se décline à plusieurs niveaux :

  • Historique du projet (qui peut apporter un éclairage intéressant sur les objectifs ou les freins rencontrés)
  • Contraintes techniques (environnement existant, niveau de sécurité, services tiers)
  • Concurrence (positionnement digital, niveau de service, positionnement tarifaire)

Là encore, le degré de détail dépend du temps passé sur le projet, le minimum est de préciser le contexte historique et de regarder ce qui existe sur le segment de marché concerné.

En cas de création d’un nouveau produit / service, le parallèle avec d’autres marchés reposant sur une problématique ou une complexité comparable est souvent bénéfique et très enrichissant.

Si l’on parle d’une refonte ou d’une évolution, un audit de l’existant versus la concurrence permet de conforter le positionnement du projet et ses objectifs. Ce type d’étude se base sur un comparatif des forces / faiblesses par catégorie, par exemple :

  • contenu éditorial,
  • SEO
  • conversion,
  • ergonomie…

Une fois les objectifs fixés et le contexte étudié, on peut s’intéresser maintenant à notre cible : l’internaute. Après tout, c’est lui qui fera le succès final du projet (ou pas) !

La cible : à qui parle-t-on ?

La définition des personas est une étape primordiale mais qui est souvent négligée voire inexistante sur bon nombre de projet. Pour savoir si l’on va dans la bonne direction, il faut déjà savoir à qui on parle et ce qu’on veut lui raconter. A quoi il sera plutôt sensible ou au contraire réfractaire.

Par persona, on entend typologie des utilisateurs finaux du service, que l’on classe généralement en cible principale et cible secondaire. La cible principale représente les utilisateurs dont les attentes sont prioritaires tandis que celles des cibles secondaires seront prises en compte de manière plus marginale.

En définissant les différents personas, on va essayer d’identifier à la fois leurs aptitudes et leurs attentes. Quels sont leur comportement vis à vis des supports digitaux ? Quelle sera la fréquence d’utilisation du service ? Dans quel contexte (personnel / professionnel, sédentaire / mobile…) ? Quels seront les leviers de conversion ou réassurance à employer ?

On peut aller jusqu’à incarner les personas en les dotant d’une identité, d’une histoire, d’un métier afin de mieux donner du contexte à la cible et de rendre son comportement plus concret. On va surtout définir ses attentes par rapport aux éléments clés du projet.

Je vois d’ici une sorte de scepticisme s’emparer d’une partie de l’auditoire : OK, super mais à quoi ça sert de savoir que Jaqueline qui habite Palavas-les-flots et a 47 ans aime bien consulter ses mails depuis sa terrasse pendant le petit-déjeuner en été ?

Alors d’abord, fondamentalement, on découvre que rien n’empêche de savourer un croissant tout en checkant ses emails et en regardant la mer (en ayant pris soin d’apposer un écran plus ou moins total sur sa peau et une paire de lunette de soleil devant ses yeux*).
Plus sérieusement, seul le comportement en relation avec le projet / le produit / le service est retenu, bien entendu. Les personas resteront au coeur du processus pendant toute la durée du projet :

  • Ils serviront de « phare » lors de la rédaction du cahier des charges : on vérifiera soigneusement si le parcours utilisateur ou les différentes fonctionnalités sont compatibles avec l’utilisation anticipée du ou des persona principaux
  • Ils serviront à définir les cas de tests qui seront passés en phase de recette (test) de telle ou telle fonctionnalité – d’ailleurs en mode agile type scrum, un élément de backlog** est défini en commençant par la phrase « en tant que » qui fait référence au persona concerné

Une fois qu’on dispose de nos utilisateurs-type, que l’on sait où on met les pieds (le contexte) et où on veut aller (l’objectif)… On peut rentrer dans le vif du sujet et attaquer notre cahier des charges. On verra que sa rédaction dépend étroitement de la typologie de gestion de projet souhaitée (classique ou agile) et que l’on peut l’attaquer dans un sens ou dans l’autre…

Et vous, comment fonctionnez-vous sur cette base avant-projet ? Vous pensez qu’on raconte n’importe quoi ? Vous trouvez qu’on devrait écrire un livre blanc ? Vous ne savez pas où se situe Palavas-les-Flots ?
Alors à vos claviers : un petit commentaire et promis, on vous répond rapidement 🙂

*Si vous êtes arrivé jusque là dans l’article, je me devais de récompenser votre lecture assidue par une petite récréation intellectuelle. 
**Si vous ne savez pas ce qu’est un backlog, nous détaillerons cela dans le second volet sur la rédaction du cahier des charges : patience !