Deux documents, deux publics, deux objectifs
Confondre cahier des charges fonctionnel et cahier des charges technique est l'une des sources de malentendus les plus fréquentes entre un porteur de projet et un prestataire. Le premier décrit ce que le produit doit faire pour l'utilisateur, le second décrit comment le produit va le faire techniquement. Envoyer un document technique à un client qui n'a pas de compétences en développement, ou un document purement fonctionnel à une équipe qui a besoin de spécifications précises pour chiffrer, produit le même résultat : de l'incompréhension et des devis mal calibrés.
Le cahier des charges fonctionnel : ce qu'il doit contenir
Le fonctionnel se lit sans connaissance technique. Il décrit les utilisateurs, leurs parcours, les règles métier et les résultats attendus, sans jamais mentionner un langage de programmation, une base de données ou une architecture. Il répond à des questions comme : qui utilise le produit, que peut-il faire, dans quel ordre, avec quelles règles, un client peut-il annuler une réservation moins de 24h avant, un prestataire peut-il refuser une commande. C'est le document de référence pour le porteur de projet, et c'est aussi celui qui sert de base à la négociation commerciale et à la comparaison des devis entre prestataires.
Le cahier des charges technique : ce qu'il doit contenir
Le technique traduit le fonctionnel en décisions d'implémentation : architecture, choix de framework, modèle de données, intégrations API, contraintes d'hébergement, mesures de sécurité. Il répond à des questions comme : comment les disponibilités sont-elles stockées et vérifiées pour éviter un double booking, quel service de paiement est intégré et selon quel protocole. Ce document s'adresse au développeur, rarement au client final, et il est généralement rédigé par le prestataire lui-même à partir du fonctionnel, pas l'inverse.
Exemple côte à côte : la fonctionnalité de réservation
Prenons la même fonctionnalité vue des deux côtés.
- Fonctionnel : un client sélectionne un créneau disponible, le réserve, reçoit une confirmation par email, peut annuler jusqu'à 24h avant sans frais
- Technique : table reservations avec contrainte d'unicité sur le créneau et le statut confirmé, verrou transactionnel à l'écriture pour éviter les doubles réservations concurrentes, envoi asynchrone via file de messages vers le service email, annulation gérée par un job planifié vérifiant le délai de 24h
Le premier document permet à un porteur de projet non technique de valider que le comportement correspond à son besoin métier. Le second permet à un développeur de l'implémenter sans ambiguïté et à un autre développeur de la maintenir plus tard, y compris s'il rejoint le projet après le prestataire initial.
Qui rédige quoi, et dans quel ordre
Le cahier des charges fonctionnel se rédige en premier, généralement par le porteur de projet, seul ou accompagné d'un assistant de cadrage. Le cahier des charges technique se rédige ensuite, par le prestataire retenu, en réponse au fonctionnel. Inverser l'ordre, un client qui impose une stack technique avant même d'avoir clarifié le besoin fonctionnel, prive souvent le projet des meilleures options techniques, choisies non pas pour le besoin réel mais par habitude ou par mode passagère.
L'erreur la plus commune : mélanger les deux niveaux
Beaucoup de cahiers des charges envoyés en consultation mélangent les deux : une phrase fonctionnelle suivie d'une exigence technique précise, sans cohérence d'ensemble. Ce mélange complique le chiffrage, car chaque prestataire doit d'abord démêler ce qui est une contrainte réelle et imposée de ce qui est une suggestion négociable. La règle simple à retenir : le fonctionnel décrit le quoi et reste stable quel que soit le prestataire choisi, le technique décrit le comment et peut varier d'un prestataire à l'autre pour un même besoin fonctionnel.
Les signes que votre document mélange les deux niveaux
Certains signaux trahissent un cahier des charges mal séparé, avant même de le faire relire par un prestataire.
- Le document mentionne un framework ou un langage de programmation dès la première page
- Une même section contient à la fois une règle métier et une contrainte de base de données
- Le porteur de projet ne comprend plus son propre document une fois relu deux semaines plus tard
- Deux prestataires consultés posent des questions radicalement différentes sur ce qui semblait être la même demande
Pourquoi cette distinction compte au moment de comparer des prestataires
Quand le document envoyé reste rigoureusement fonctionnel, chaque prestataire propose sa propre traduction technique du même besoin, et ces traductions deviennent elles-mêmes un critère de choix : l'une mise sur une architecture simple et rapide à livrer, l'autre sur une base plus robuste pensée pour absorber une forte croissance. Cette diversité de réponses techniques n'est visible que si le document de départ ne l'a pas déjà imposée à tort. C'est cette lecture comparative, rendue possible par la séparation stricte des deux niveaux, qui permet ensuite d'évaluer objectivement le score de correspondance entre chaque prestataire et le besoin exprimé.
Comment Devizy relie les deux niveaux sans les confondre
L'assistant de cadrage de Devizy travaille exclusivement au niveau fonctionnel : à partir d'une description en langage naturel, il génère un cahier des charges organisé en modules et sous-tâches qui reste dans le registre du quoi, découpé en environ 5 modules pour rester lisible, avec alerte automatique si un module dépasse dix sous-tâches. Ce document fonctionnel structuré est ensuite envoyé à plusieurs prestataires, qui y répondent chacun avec leur propre traduction technique et leur devis ligne par ligne sur les mêmes sous-tâches. Le porteur de projet compare ainsi des réponses techniques différentes à un besoin fonctionnel identique, exactement l'objectif recherché pour choisir en connaissance de cause plutôt que sur la seule confiance.