Cadrer un projet web : identifier les vrais besoins avant de développer

Avant d'ouvrir un éditeur de code, la première étape d'un projet web consiste à comprendre ce que l'on cherche réellement à construire.

Un besoin mal compris peut entraîner des fonctionnalités inutiles, des choix techniques difficiles à remettre en question ou, plus simplement, un projet qui répond à la demande initiale sans vraiment répondre au problème de l'entreprise.

Le cadrage permet justement de prendre un peu de recul : distinguer ce que le client demande, ce dont il a réellement besoin et ce que le contexte du projet permet de faire.

La bonne question n'est pas seulement « qu'allons-nous construire ? », mais « quel problème cherchons-nous à résoudre, pour qui et dans quelles conditions ? ».

Distinguer la demande du besoin

Un client formule souvent une solution plutôt que son besoin.

Par exemple :

« Je voudrais un slider avec cinq offres sur la page d'accueil. »

Ce n'est pas nécessairement le besoin. Le véritable objectif peut être :

« Je veux que les visiteurs comprennent rapidement les services que je propose et sachent lequel choisir. »

Dans ce cas, un slider est une possibilité parmi d'autres. Une présentation statique, une hiérarchisation différente des contenus ou une page dédiée pourraient être plus efficaces.

Le rôle du concepteur ou du développeur n'est donc pas simplement d'exécuter une liste de fonctionnalités. Il consiste aussi à comprendre pourquoi ces fonctionnalités sont demandées.

Quelques questions utiles

Avant de parler de technologie ou d'interface, il est intéressant de clarifier :

• Quel est l'objectif principal du site ?
• Quel problème cherche-t-on à résoudre ?
• Qui sont les utilisateurs concernés ?
• Que doivent-ils pouvoir faire ou comprendre facilement ?
• Dans quel contexte vont-ils utiliser le site ?
• Qu'est-ce qui existe déjà ?
• Qu'est-ce qui ne fonctionne pas aujourd'hui ?
• Comment saura-t-on que le projet est une réussite ?

Cette dernière question est particulièrement importante.

Un site peut être techniquement réussi tout en étant un échec pour l'entreprise s'il ne génère pas davantage de demandes de contact, s'il ne permet pas aux utilisateurs de trouver l'information recherchée ou s'il est impossible à maintenir au quotidien.

Faire apparaître les contraintes dès le départ

Un projet web n'existe jamais dans le vide.

Il doit composer avec un budget, un calendrier, des outils existants, des personnes disponibles et parfois des obligations réglementaires. Ces contraintes ne sont pas forcément des problèmes : elles définissent simplement le cadre dans lequel le projet doit fonctionner.

Les découvrir tardivement peut en revanche obliger à revoir des décisions déjà prises.

Contraintes techniques

Il peut être nécessaire de prendre en compte :

• un hébergement ou une infrastructure existante ;
• un CMS déjà utilisé ;
• une API ou un logiciel métier à intégrer ;
• des contraintes de performances ;
• les navigateurs et appareils à prendre en charge ;
• les besoins d'accessibilité ;
• la sécurité et la gestion des données.

Le choix d'une technologie ne devrait donc pas être fait uniquement parce qu'elle est moderne ou appréciée par l'équipe de développement. Il doit aussi être cohérent avec le projet et son contexte.

Contraintes humaines et organisationnelles

Une contrainte est parfois beaucoup plus simple : qui va faire quoi après la mise en ligne ?

Qui rédige les articles ? Qui ajoute les produits ? Qui répond aux demandes de contact ? Qui valide les contenus ? Qui pourra modifier le site dans six mois ?

Un outil parfaitement conçu sur le papier peut devenir difficile à utiliser si personne n'a le temps ou les compétences nécessaires pour l'administrer.

Contraintes budgétaires et temporelles

Tout ne peut pas toujours être fait en même temps.

Un budget limité ou une date de mise en ligne imposée oblige à faire des choix. L'objectif du cadrage n'est pas de faire entrer toutes les idées dans le projet, mais de déterminer ce qui apporte le plus de valeur dans le cadre disponible.

Contraintes légales et métier

Selon le projet, il faudra également anticiper :

• le RGPD et la gestion des données personnelles ;
• les mentions et obligations légales ;
• les règles propres au secteur d'activité ;
• les processus de validation internes ;
• les contraintes liées à la saisonnalité ;
• les obligations d'accessibilité applicables au projet.

Certaines contraintes peuvent avoir un impact important sur la conception. Elles doivent donc être identifiées suffisamment tôt.

Transformer les échanges en périmètre concret

Une fois les besoins et les contraintes identifiés, il faut les formaliser.

Le but n'est pas nécessairement de produire un document de plusieurs dizaines de pages. Il s'agit surtout de disposer d'une référence commune permettant au client et au prestataire de savoir ce qui a été décidé.

Une méthode simple consiste à :

1. Lister les fonctionnalités et contenus nécessaires.
2. Les classer par priorité : must have, should have, could have.
3. Identifier les dépendances entre les différentes fonctionnalités.
4. Définir explicitement ce qui n'est pas prévu dans cette phase.
5. Déterminer comment chaque élément sera validé.
6. Faire valider le périmètre avant de commencer le développement.

Cette dernière étape évite une situation fréquente : découvrir en cours de développement que deux personnes n'avaient pas la même définition de ce qui devait être réalisé.

Documenter les décisions, pas seulement les fonctionnalités

Le cadrage ne devrait pas uniquement répondre à la question « quelles fonctionnalités allons-nous développer ? ».

Il peut aussi être utile de noter certaines décisions importantes et leur raison.

Par exemple :

Pas de CMS pour la première version Le site comporte peu de contenus et les modifications seront rares. Ajouter un CMS augmenterait la complexité et le coût du projet sans bénéfice immédiat.

Ou, à l'inverse :

Utilisation d'un CMS Le client doit pouvoir publier régulièrement des articles sans intervention du développeur.

Ces décisions sont précieuses quelques mois plus tard. Elles permettent de comprendre pourquoi une solution a été choisie et de savoir dans quelles conditions elle pourrait être remise en question.

Le cadrage est aussi un outil de priorisation

Le cadrage permet enfin de distinguer ce qui est indispensable de ce qui est simplement intéressant.

Une idée peut être pertinente sans être nécessaire pour la première version.

Prenons un exemple : un site vitrine pourrait prévoir dès le départ un espace client, un système de prise de rendez-vous, une newsletter, un blog, plusieurs langues et différentes automatisations.

Toutes ces fonctionnalités peuvent avoir du sens. Mais si l'objectif immédiat est simplement de présenter l'activité et de générer des demandes de contact, les développer toutes en même temps risque surtout d'augmenter le coût, les délais et la complexité du projet.

Une première version plus simple peut parfois permettre de mettre le site en ligne, observer son utilisation et faire évoluer le projet à partir de besoins réels.

En résumé

Un bon cadrage doit permettre de répondre clairement à quelques questions essentielles :

• Pourquoi ce projet existe-t-il ?
• Pour qui est-il conçu ?
• Quel problème doit-il résoudre ?
• Quelles contraintes faut-il respecter ?
• Qu'est-ce qui est prioritaire ?
• Comment saura-t-on que le résultat est satisfaisant ?
• Qu'est-ce qui est volontairement laissé de côté ?

Le développement vient ensuite.

Prendre le temps de comprendre le projet avant de construire permet de faire de meilleurs choix techniques, de mieux maîtriser le périmètre et surtout d'éviter de développer des choses dont personne n'a réellement besoin.

Commencer par comprendre, puis construire : c'est souvent le moyen le plus simple de construire juste.