Méthodologie de projet numérique

Cette fiche présente trois façons de démarrer et d’organiser un projet numérique : une commande, un projet perso utilitaire, ou un projet expressif qui part d’une envie.

Au démarrage, les mêmes questions reviennent : par où commencer ? quand fait-on les maquettes ? à quel moment parle-t-on aux utilisateurs ? a-t-on besoin d’un cahier des charges ? La réponse dépend du projet. Les trois approches plus bas correspondent à trois situations.

Objectifs

1. Commencer son dossier pro dans un document (Markdown, page HTML, .odt)
2. Y mettre le contexte du projet
3. Commencer à faire des personae
4. Faire émerger des fonctionnalités

Questionnaire

1. Contexte et objectifs

1. Quelle est la mission principale de votre activité ?
2. Quels indicateurs utiliserez-vous pour mesurer la réussite du projet ? (trafic, adhésions, consultations…)
3. Quelle situation ou quel problème vous pousse à refondre ce produit ?
4. Qu’aimeriez-vous que ce projet change pour vous ou vos utilisateurs ?
5. Quels sont vos trois objectifs prioritaires (expérience utilisateur, adhérents, etc.) ?
6. À quoi ressemblerait, pour vous, un projet « réussi » dans six mois ?

2. Public et parcours utilisatrices

1. Qui sont vos utilisatrices principales (âge, profil, besoins) ?
2. Sur quels appareils utiliseront-elles surtout votre produit ? (mobile, desktop, tablette, plusieurs à la fois)
3. Dans quel contexte utiliseront-elles votre produit ? (en déplacement, au bureau, à domicile, hors ligne…)
4. Que cherchent-elles à accomplir en priorité avec votre plateforme ?
5. Quels freins ou frustrations rencontrent-elles aujourd’hui avec les solutions existantes ?
6. À quelle fréquence imaginez-vous qu’elles utilisent la plateforme ? (quotidien, hebdomadaire, ponctuel)

3. Conformité

RGPD et protection des données

1. Quelles données personnelles allez-vous collecter ? (nom, email, téléphone, localisation, etc.)
2. À quelles fins utiliserez-vous ces données ? (personnalisation, newsletter, analyses, etc.)
3. Avec quels outils ou services tiers ces données seront-elles partagées ?
4. Combien de temps conserverez-vous ces données ?
5. Avez-vous déjà une politique de confidentialité et des mentions légales à jour ?
6. Comment gérerez-vous les demandes d’accès, de modification ou de suppression des données ?

4. Besoins fonctionnels

1. Quelles actions vos utilisateurs doivent-ils pouvoir réaliser ?
   1. Quels sont leurs cas d’usage critiques ?
   2. Quels sont leurs besoins, frustrations, habitudes numériques ?
   3. Quel est leur niveau technique ?
2. Y a-t-il des fonctionnalités que vous voudriez offrir dans les versions futures ?
3. Avez-vous déjà imaginé le parcours type d’un utilisateur ? (première visite → usage → habitude)
4. Quels contenus existants pouvez-vous réutiliser ?

5. Planning et étapes clés

1. Avez-vous une date de lancement souhaitée ou un jalon (événement, salon, levée de fonds, lancement commercial) ?
2. Préférez-vous un produit minimum viable (MVP), lancé vite avec peu de fonctionnalités, ou un lancement complet ?
3. Quand êtes-vous disponible pour les validations et les tests utilisateurs ?
4. Combien de temps pouvez-vous consacrer à la conception avant le lancement ?
5. À quelle fréquence souhaitez-vous valider les avancées ? (hebdomadaire, bimensuelle, mensuelle)
6. Prévoyez-vous une phase de test avec des utilisateurs réels ?
7. Que se passerait-il si la mise en ligne était décalée ?

6. Ressources nécessaires

1. Qui seront les interlocutrices principales pour les validations ?
2. Quelles compétences ou ressources internes pouvez-vous mobiliser ?
3. Avez-vous besoin d’aide pour produire les contenus (textes, visuels, vidéos, animations) ?

7. Design et expérience utilisateur

1. Quelle ambiance visuelle correspond le mieux au projet ? (minimaliste, ludique, professionnelle, accessible…)
2. Quelles couleurs, typographies ou éléments graphiques vous représentent déjà ?
3. Quels éléments de votre identité visuelle actuelle sont non négociables ?
4. Citez 3 produits numériques (apps ou sites) qui vous inspirent, et dites précisément pourquoi.
5. Quand quelqu’un arrive sur le site pour la première fois, que doit-il ressentir et faire dans les 10 premières secondes ?
6. Qu’est-ce qu’il ne faut surtout pas faire ?
7. Si votre produit était une personne, quel serait son ton de voix ?

Quelques questions pour se situer

• Ce projet part-il d’un problème observé, ou d’une envie, d’une expérience à créer ?
• Pour qui ? Peut-on parler à ces personnes ?
• Quelle est la contrainte principale : le temps, l’argent, les compétences ?
• En combien de temps veut-on avoir quelque chose de testable ?

Trois types de projet, trois approches

Cas 1. Projet pour une structure, un client

Vous réalisez un site, une appli, un outil ou une refonte pour une asso, une entreprise, une collectivité.

Le projet a des parties prenantes et des utilisateurs que vous ne connaissez pas encore. L’approche conseillée s’appelle discovery-first. Elle s’inspire du Lean UX et du framework Jobs-to-Be-Done (JTBD).

Le principe

Avant de concevoir quoi que ce soit, vous observez et vous écoutez. Le but de cette phase est de formuler le problème avec précision. Les solutions viennent après.

Étapes

Étape 1. Interviews courtes (2 à 5 personnes)

Rencontrez des personnes concernées par le projet et faites-les parler de leur quotidien. Posez des questions ouvertes :

• Raconte-moi comment tu fais aujourd’hui pour [tâche visée].
• Qu’est-ce qui est le plus pénible dans ce processus ?
• Qu’est-ce que tu utilises en ce moment ? Pourquoi ça ne suffit pas ?

Vous cherchez ce que vous ignorez encore, pas une confirmation de ce que vous pensez savoir.

Étape 2. Reformuler le besoin avec la structure JTBD

Après les interviews, reformulez le besoin réel sous cette forme :

Quand [situation déclenchante], je veux pouvoir [action], pour [résultat attendu].

Exemple : Quand je dois rendre compte à mes financeurs, je veux générer un rapport structuré en quelques clics, pour ne pas y passer trois heures chaque trimestre.

Cette phrase sert de filtre. Une fonctionnalité qui n’y répond pas part dans une liste « plus tard » (le cimetière 🦴).

Étape 3. Prototype basse fidélité, testé sur 2 ou 3 personnes

Construisez quelque chose de simple : écrans papier, maquette Figma, ou même une présentation. Montrez-le à 3 personnes du terrain. Notez ce qui coince, ce qui est compris, ce qui est raté.

Étape 4. Lister les fonctionnalités

À partir des étapes 1 à 3, listez les fonctionnalités. Pour chacune, posez la question : cette fonctionnalité résout-elle le problème formulé à l’étape 2 ?

Quand rédiger un cahier des charges ?

Si le contrat l’exige, rédigez-le après les étapes 1 à 3. Il sera plus précis, et le devis aussi 💸.

Ce que cette approche évite

• Développer des fonctionnalités que personne n’utilisera
• Prendre des décisions de conception sur des hypothèses
• Être bloqué·e par un périmètre figé trop tôt

Cas 2. Projet personnel ou en solo

Une petite appli, un outil, un micro-SaaS, une plateforme, de votre propre initiative.

Sans client, vous êtes à la fois commanditaire, designer et développeur·euse. Personne ne vous impose de date. Il devient alors facile de trop planifier, de ne jamais livrer, ou de changer de cap sans rien terminer.

Cette approche s’inspire de Shape Up (Basecamp) : on fixe d’abord le temps disponible, puis on adapte le périmètre.

Le principe

Deux questions, dans l’ordre :

1. Quel problème ce projet résout-il, pour vous ou pour quelqu’un d’autre ?
2. Combien de temps êtes-vous prêt·e à y consacrer avant d’avoir quelque chose de testable ?

Étapes

Étape 1. Le problème en une phrase

[Qui] n’arrive pas à [faire quelque chose] parce que [obstacle]. Ce projet résout ça en [approche large].

Étape 2. Fixer un budget temps

Shape Up appelle ce budget l’« appétit ».

• 1 à 3 jours → prototype jetable, preuve de concept
• 1 à 2 semaines → version bêta minimale utilisable
• 4 à 6 semaines → première version publique

Étape 3. Le pitch

Un document d’une page :

• Le problème
• La solution envisagée (fonctionnelle, pas technique)
• Ce qui est dans le périmètre
• Ce qui est explicitement hors périmètre
• Les risques identifiés

Étape 4. Des cycles courts : construire, tester, choisir

À la fin de chaque cycle :

• Quelqu’un peut-il utiliser ce que vous avez construit ?
• Qu’avez-vous appris que vous ne saviez pas ?
• Le projet mérite-t-il un deuxième cycle ?

Ce que cette approche évite

• Planifier pendant des semaines sans rien livrer
• Un périmètre qui gonfle sans fin (feature creep)
• Attendre que le projet soit « assez prêt » pour commencer

Cas 3. Projet expressif, desire-led

Vous construisez quelque chose qui part d’une envie, d’une vision, d’une expérience à faire vivre : une appli musicale, un outil créatif, une plateforme de communauté, un projet artistique numérique.

Au départ, il y a une intuition plutôt qu’un problème déclaré. Ce type de projet inverse la logique des deux premiers : on part de l’expérience voulue et on en déduit les fonctions nécessaires.

L’approche s’appelle desire-led design. Elle emprunte au design d’expérience, au branding et au design critique.

Le principe

Avant de concevoir quoi que ce soit, formulez l’expérience que vous voulez créer. Laissez de côté les fonctionnalités et les écrans. Une seule question : que doit-on ressentir en l’utilisant ?

Une note sur la légitimité

Partir d’un désir demande autant de rigueur qu’un autre projet. Le critère change : on se demande si le projet « résonne », pas s’il résout quelque chose. Une sensibilité forte et une vision esthétique claire sont des compétences de design.

Étapes

Étape 1. Raconter l’expérience idéale

Écrivez une courte histoire (10 à 20 lignes) qui décrit un moment d’usage idéal. Écrivez une scène, pas une spécification. Qui est là ? Que fait cette personne ? Que ressent-elle ?

Exemple pour une application de sons d’ambiance :

Clara ouvre l’appli sans savoir exactement ce dont elle a besoin. Elle fait défiler les textures sonores lentement, comme on feuillette un livre sans but. Elle tombe sur quelque chose qui ressemble à de la pluie sur un toit en tôle. Elle s’arrête. Quelque chose se détend en elle. Elle ne saura pas dire pourquoi ce son-là plutôt qu’un autre.

Ce récit est votre référence. Chaque choix de conception se juge avec une question : est-ce que ça rend cette scène possible ?

Étape 2. Explorer l’existant par sensation, pas par catégorie

Ne faites pas d’étude de marché sur « les applis de sons d’ambiance ». Rassemblez des objets, des interfaces, des lieux, des morceaux qui produisent la même sensation, même dans des domaines très différents.

Pour chaque référence, notez :

• ce qu’elle fait ressentir
• par quels moyens (couleur, rythme, texture, silence, densité visuelle…)
• ce qu’elle ne fait pas, et si c’est une force ou une limite.

Cette collection remplace l’analyse concurrentielle. Elle vous donne un vocabulaire sensoriel pour votre projet.

Étape 3. Personae lifestyle

Les personae classiques décrivent qui a un problème. Les personae lifestyle décrivent comment quelqu’un veut vivre, se voir, et être vu·e.

Évitez les listes de goûts (« aime le yoga, valeurs écolos, Spotify Premium »). Partez de comportements réels :

• Comment cette personne passe-t-elle son temps libre ?
• Pour quoi paie-t-elle volontiers, et pour quoi refuse-t-elle de payer ?
• Qu’est-ce qu’elle montre aux autres, et qu’est-ce qu’elle garde pour elle ?

Deux ou trois personae suffisent, à condition qu’ils soient tirés de personnes observées.

Étape 4. Prototype d’ambiance avant prototype fonctionnel

Avant les écrans, construisez une ambiance. Un moodboard sert à prendre des décisions, pas à décorer le dossier.

Il peut contenir :

• une palette de couleurs, avec pour chaque couleur l’effet recherché (« c’est joli » ne suffit pas)
• des typographies et leur rapport à la sensation cible
• des interactions de référence (un geste dans une autre appli, une transition dans un film)
• un mot interdit : ce à quoi votre projet ne doit pas ressembler.

Ensuite seulement, construisez un premier prototype interactif. Vous le jugez sur sa ressemblance avec le récit de départ, pas sur son fonctionnement.

Étape 5. Tester la résonance

Montrez votre prototype à 3 à 5 personnes. Ne leur demandez pas si c’est utile. Demandez :

• Qu’est-ce que tu as ressenti ?
• À quoi ça t’a fait penser ?
• Y a-t-il eu un moment où tu t’es senti·e à l’aise, ou au contraire décalé·e ?

Ces réponses sont votre critère de validation, à la place du taux de complétion d’un formulaire.

Ce que cette approche évite

• Construire quelque chose de fonctionnel mais sans âme
• Devoir justifier l’absence d’un « problème à résoudre »
• Traiter l’esthétique comme une couche de finition

Sur l’esthétique

En 1995, Masaaki Kurosu et Kaori Kashimura ont montré que des interfaces jugées plus belles étaient aussi jugées plus faciles à utiliser, à fonctionnalités égales. Don Norman a popularisé ce résultat dans Emotional Design. L’esthétique est donc une décision de design qui change la perception de l’usage.

Les trois approches côte à côte

Dans les trois cas, les fonctionnalités se déduisent d’un problème, d’une contrainte de temps ou d’une expérience voulue. Elles ne se décident pas au départ.

Pour aller plus loin

Cas 1. Discovery-first

• Lean UX, Jeff Gothelf et Josh Seiden
• Competing Against Luck (Jobs to Be Done), Clayton Christensen, et When Coffee and Kale Compete, Alan Klement
• Continuous Discovery Habits, Teresa Torres

Cas 2. Shape Up

• Shape Up, Ryan Singer (Basecamp), gratuit en ligne : basecamp.com/shapeup

Cas 3. Desire-led design

• Emotional Design, Don Norman
• The Shape of Design, Frank Chimero
• How to See, George Nelson
• Ways of Seeing, John Berger