Cahier des charges fonctionnel ou technique : quelle différence ?

Fonctionnel ou technique : la réponse courte

Le cahier des charges fonctionnel décrit le QUOI, c'est-à-dire le besoin et le résultat attendu (objectifs, cibles, fonctions). Le cahier des charges technique décrit le COMMENT, c'est-à-dire la solution retenue pour y répondre (architecture, technologies, hébergement, performance). L'un exprime le problème, l'autre la façon d'y répondre.

Tout le reste découle de cette distinction. Un cahier des charges fonctionnel dit « les visiteurs doivent pouvoir prendre rendez-vous en ligne et payer un acompte ». Le cahier des charges technique répond « on utilisera tel CMS, tel module de réservation, telle passerelle de paiement, hébergés sur tel serveur ». Le premier appartient à celui qui a le besoin, le second à celui qui construit la solution.

Confondre les deux est l'erreur de cadrage la plus fréquente. Quand un porteur de projet écrit du technique dès le départ (« il me faut du WordPress avec tel plugin »), il fige des choix qu'il n'est pas en position d'arbitrer et prive le prestataire de la marge nécessaire pour proposer mieux. Séparer clairement le besoin de la solution, c'est laisser à chacun son rôle et son moment.

Le cahier des charges fonctionnel : ce qu'il contient

Un cahier des charges fonctionnel décrit ce que le projet doit accomplir, sans imposer la technique. Il contient le contexte et les objectifs, les cibles et leurs usages, les fonctions attendues, l'arborescence et le contenu, ainsi que les contraintes de budget, de délai et d'existant. C'est le document qui exprime le besoin.

Le cahier des charges fonctionnel est le point de départ de tout projet web. Il se lit sans compétence technique, parce qu'il parle de finalité, pas d'implémentation. Ses rubriques forment ce qu'on appelle les spécifications fonctionnelles : la description, fonction par fonction, de ce que l'utilisateur doit pouvoir accomplir. Il rassemble :

• Le contexte et les objectifs. Pourquoi ce projet, quel problème il résout, à quoi on saura qu'il a réussi. Des objectifs mesurables (générer des demandes de devis, vendre en ligne, réduire les appels au support) plutôt qu'un vague « moderniser le site ».
• Les cibles et leurs usages. À qui s'adresse le site, ce que chaque profil vient y faire, sur quels appareils.
• Les fonctions attendues. Ce que l'utilisateur doit pouvoir accomplir : formulaire, prise de rendez-vous, panier, espace client, moteur de recherche. Décrites en termes de résultat, pas de composant.
• L'arborescence et le contenu. Les grandes rubriques, les types de pages, ce qui existe déjà et ce qu'il faut produire.
• Les contraintes. Budget disponible, échéance, existant à conserver, obligations réglementaires ou d'accessibilité (RGAA), identité de marque. On y signale aussi les exigences non fonctionnelles, c'est-à-dire les qualités attendues du site (performance, sécurité, accessibilité) plutôt que ses fonctions.

C'est ce document que vous envoyez aux prestataires pour obtenir des propositions comparables. Il fonde le devis et sert de référence en cas de désaccord. Pour la trame détaillée et une méthode pas à pas, voyez comment rédiger un cahier des charges.

Le cahier des charges technique : ce qu'il contient

Un cahier des charges technique décrit la solution retenue pour répondre au besoin : architecture, technologies, hébergement, sécurité, performance et intégrations. Il traduit chaque fonction attendue en choix concrets d'implémentation. C'est le document qui décrit le COMMENT, produit une fois la solution arbitrée.

Le cahier des charges technique se lit avec un profil technique, parce qu'il descend au niveau des moyens. Il précise notamment :

• L'architecture et les technologies. CMS ou développement sur mesure, langages, base de données, briques logicielles retenues.
• L'hébergement et l'infrastructure. Type de serveur, environnements (préproduction, production), sauvegardes, nom de domaine, certificat HTTPS.
• Les intégrations. Passerelle de paiement, CRM, outil d'emailing, API tierces, connexions à des systèmes existants.
• Les exigences non fonctionnelles, détaillées. Temps de chargement visés, Core Web Vitals, sécurité, protection des données, conformité RGPD, gestion des accès.
• Les livrables techniques. Documentation, procédures de déploiement, plan de reprise, tests.

Sur un projet de refonte, le cahier des charges technique intègre un volet souvent oublié : la migration et le plan de redirections 301, pour ne pas perdre le référencement acquis quand les URL changent. C'est un point que le fonctionnel signale comme contrainte, mais que le technique traite en détail.

Lequel rédiger pour votre projet

Dans la quasi-totalité des cas, vous rédigez un cahier des charges fonctionnel. C'est lui qui exprime votre besoin, sert à consulter les prestataires et fonde le devis. Le cahier des charges technique vient ensuite, écrit par le prestataire ou votre équipe technique, une fois la solution choisie. Le fonctionnel d'abord, le technique après.

La logique est chronologique. On ne peut pas décrire une solution avant d'avoir défini le problème. Le fonctionnel se rédige au tout début, quand vous êtes seul maître de votre besoin. Il vous permet de mettre plusieurs prestataires en concurrence sur une même base, de comparer des offres qui répondent à la même demande, et d'obtenir des devis qui se tiennent. Le technique, lui, n'a de sens qu'une fois le prestataire choisi et l'approche arbitrée : c'est sa réponse à votre besoin, formalisée.

D'après mon expérience, les clients qui arrivent avec un cahier des charges déjà technique se sont souvent laissé influencer par un premier interlocuteur, et ils s'enferment dans une solution avant d'avoir consulté. Le réflexe sain est l'inverse : exprimez le besoin le plus précisément possible, laissez la technique ouverte, et jugez les prestataires sur la qualité de la solution qu'ils proposent. Ce raisonnement rejoint celui de l'appel d'offres, où le fonctionnel sert de socle commun à tous les candidats.

Qui rédige quoi : MOA et MOE

Le cahier des charges fonctionnel relève de la maîtrise d'ouvrage (MOA), le porteur du projet qui exprime le besoin. Le cahier des charges technique relève de la maîtrise d'oeuvre (MOE), le prestataire ou l'équipe qui réalise la solution. La MOA dit ce qu'elle veut, la MOE dit comment elle le fera.

Cette répartition des rôles est le coeur de tout projet piloté. La maîtrise d'ouvrage (MOA) est le commanditaire : elle porte le besoin, valide les orientations et paie. La maîtrise d'oeuvre (MOE) est le réalisateur : elle conçoit et construit la solution qui répond au besoin. Le fonctionnel est donc l'expression écrite de la MOA, le technique celle de la MOE. Quand une organisation manque de compétence pour formaliser son besoin, un assistant à maîtrise d'ouvrage (AMOA) l'accompagne pour rédiger un fonctionnel solide sans se laisser happer par la technique.

Cette frontière protège le projet. Si la MOA se met à écrire du technique, elle empiète sur la MOE et s'expose à des choix qu'elle ne saura pas défendre. Si la MOE écrit le fonctionnel à la place du client, elle risque de décrire la solution qui l'arrange plutôt que le besoin réel. Pour le détail de ces rôles et de leurs responsabilités, voyez la fiche MOA, MOE et AMOA.

Fonctionnel et technique dans un seul document : quand c'est possible

Oui, sur un projet modeste, le fonctionnel et le technique tiennent souvent dans un seul document à deux parties. Sur un projet plus lourd, mieux vaut les séparer : le fonctionnel pour consulter et comparer, le technique après le choix du prestataire. La taille du projet décide.

Pour un site vitrine ou une petite refonte, un document unique suffit largement : une première partie rassemble les spécifications fonctionnelles, une seconde liste les quelques contraintes techniques imposées (hébergeur, CMS existant à conserver, compatibilité avec un outil interne). Alourdir un petit projet de deux documents formels ferait perdre du temps sans rien sécuriser. C'est d'ailleurs l'approche que je recommande pour un cahier des charges de site vitrine.

Sur un projet e-commerce, applicatif ou multilingue, la séparation redevient utile. Le fonctionnel circule tôt, vers plusieurs prestataires, et doit rester lisible par des non-techniciens. Le technique se rédige plus tard, engage des choix lourds et s'adresse à des développeurs. Les mélanger reviendrait à demander à un décideur de valider des choix d'architecture, et à un développeur de deviner des objectifs métier. Dans tous les cas, la règle tient en une phrase : le fonctionnel décrit le besoin, le technique décrit la solution, pas l'inverse.