Cette étape paraît simple, mais c'est souvent la plus délicate. Les équipes produit, techniques ou marketing ont parfois tendance à projeter leurs propres hypothèses sur les besoins des utilisateurs.
Sans remettre en cause leur expertise, il est essentiel de prendre du recul et de confronter ces hypothèses à la réalité.
Pour cela, il faut écouter les utilisateurs sans chercher à confirmer une vision préétablie.

Voici cinq méthodes pour identifier leurs besoins :

• Organiser des entretiens individuels afin de recueillir leurs besoins, attentes et retours d'expérience.
• Mettre en place des ateliers de co-construction avant et pendant le projet afin d'impliquer les utilisateurs.
• Observer les utilisateurs dans leur environnement réel pour comprendre leurs usages.
• Réaliser des enquêtes et questionnaires afin de recueillir des données quantitatives.
• Concevoir des prototypes ou MVP (Minimum Viable Product) puis réaliser des tests utilisateurs.

Une fois les besoins identifiés : 

• Prioriser les besoins selon leur importance, leur urgence et leur valeur.
• Définir des objectifs SMART (Spécifiques, Mesurables, Atteignables, Réalistes et Temporellement définis).
• Vérifier leur cohérence avec la stratégie globale de l'organisation.
• Associer les parties prenantes afin d'enrichir et valider les objectifs.
• Identifier les priorités et les dépendances du projet.

Une fois les besoins clarifiés et les parties prenantes alignées, le reste du projet peut se dérouler de manière plus fluide.
Les fonctionnalités peuvent concerner des aspects techniques, des processus, des services ou des composants du produit.

Il est important de distinguer :

• les fonctionnalités indispensables (« must-have ») ;
• les fonctionnalités de confort (« nice-to-have »).

Il convient notamment de préciser :

• l'architecture du système (technologies, structures de données, workflows, intégrations, interfaces) ;
• l'interface utilisateur (UI) et l'expérience utilisateur (UX) ;
• les plateformes et environnements cibles (web, mobile, systèmes d'exploitation...) ;
• les intégrations et API nécessaires ;
• les normes et protocoles garantissant l'interopérabilité, la compatibilité et la conformité.

L'estimation du budget est une étape sensible.
Un budget sous-estimé met rapidement les équipes en difficulté. À l'inverse, un planning trop confortable peut ralentir le projet.

Évaluer les coûts - Plusieurs méthodes existent :

• Estimation ascendante (Bottom-up) : estimation détaillée de chaque tâche.
• Estimation descendante (Top-down) : estimation basée sur des projets similaires.
• Estimation paramétrique : calcul à partir de ratios ou de données historiques.

Construire un planning réaliste - Pour cela, il faut :

• Estimer la durée de chaque tâche ;
• Identifier les dépendances entre les tâches ;
• Affecter les ressources humaines, matérielles et financières ;
• Construire un diagramme de Gantt ;
• Définir les jalons principaux ;
• Faire valider le planning par les parties prenantes ;
• Prévoir des ajustements en fonction des retours d'expérience ;
• Mettre en place des outils de suivi afin de mesurer l'avancement.

Quelques bonnes pratiques :

• Utiliser un langage clair et précis ;
• Eviter les ambiguïtés et le jargon technique inutile ;
• Structurer le document avec des titres, sous-titres et listes ;
• Rendre le document compréhensible pour les profils non techniques ;
• Expliquer les acronymes et illustrer les notions complexes lorsque cela est nécessaire.

Une fois le document rédigé, il est temps de le présenter au client ou au commanditaire.
L'un des facteurs clés de réussite est de ne pas être trop attaché à sa propre solution.
Le cahier des charges n'est pas une vérité absolue : il doit pouvoir évoluer grâce aux retours du client.

Il est recommandé de :

• Organiser une présentation du document ;
• Recueillir les remarques du client ;
• Intégrer les ajustements nécessaires ;
• Planifier des points d'échange réguliers pour le rassurer sur l'avancement ;
• Obtenir une validation finale du cahier des charges.

En cas de projet innovant ou particulièrement complexe, il peut être pertinent de solliciter un expert externe. Le temps et le budget investis dans cette phase sont généralement largement compensés par une meilleure maîtrise du projet par la suite.

Le cahier des charges fonctionnel décrit ce que le produit doit faire, du point de vue des utilisateurs et du métier. Le cahier des charges technique précise comment le réaliser : architecture, technologies, infrastructure. Le premier est écrit par le client ou avec son aide ; le second relève plutôt de l'agence. Sur nos projets Drupal, nous produisons le volet technique à partir du fonctionnel, une fois le cadrage validé.

Oui, il gagne à être plus structuré : critères de sélection, modalités de réponse, éléments attendus des candidats. Un cahier des charges d'appel d'offres clair vous fait gagner du temps au dépouillement et attire des réponses comparables. Nous aidons régulièrement nos clients à le structurer, y compris quand nous n'y répondons pas nous-mêmes.

Comme point de départ, oui ; comme copier-coller, non. Chaque projet a son contexte, son existant et ses contraintes d'intégration. Repartir d'un ancien document sans le questionner reproduit souvent des choix qui n'ont plus lieu d'être.

Le plus tôt possible, idéalement dès le cadrage. Nous animons des ateliers pour formaliser objectifs, périmètre et contraintes techniques avant que le document ne soit figé. Impliquée en amont, l'agence anticipe les points de friction ; sollicitée trop tard, elle hérite d'arbitrages déjà verrouillés.