Cahier des charges fonctionnel : décrire un besoin, pas une solution 2026

Commander une prestation à l’extérieur sans avoir posé par écrit ce que vous attendez vraiment, c’est offrir au prestataire le droit de décider à votre place. Le cahier des charges fonctionnel est le document qui reprend ce droit.

Ce qu’est un cahier des charges fonctionnel, et ce qu’il n’est pas

Un cahier des charges fonctionnel est un document écrit qui décrit ce que le résultat d’un projet doit permettre de faire, du point de vue des personnes qui l’utiliseront. Il ne dit pas comment le résultat sera construit, par quelles technologies, ni selon quels matériaux. Il formule uniquement ce que les utilisateurs doivent pouvoir accomplir une fois la prestation livrée, et dans quelles conditions précises.

Ce document se place en amont de toute décision technique. Il est rédigé avant que quiconque ait choisi une solution. Son rôle est de poser ce qui doit être vrai à la réception du projet, indépendamment du chemin emprunté pour y arriver. C’est ce positionnement qui lui donne sa valeur : il sert de référence commune entre le commanditaire et le prestataire, sans favoriser l’un ni l’autre.

Un point mérite d’être précisé immédiatement. Le cahier des charges fonctionnel ne liste pas des écrans, des boutons, des menus ou des champs de formulaire. Ces éléments relèvent d’un autre niveau de détail, qui appartient aux spécifications techniques rédigées après le choix du prestataire et de la solution. Si votre document mentionne ces éléments, il n’est pas encore un cahier des charges fonctionnel : c’est déjà une spécification technique déguisée, et il faut le réécrire.

Ce document n’est pas non plus une présentation de votre entreprise, un document d’inspiration visuelle ou un récapitulatif de réunion informel. Ce n’est pas une liste de souhaits envoyée par email. C’est un document structuré, destiné à être lu par des personnes qui ne vous connaissent pas, qui doivent comprendre ce que vous attendez sans qu’il soit nécessaire de leur fournir la moindre explication orale complémentaire.

Enfin, le cahier des charges fonctionnel ne décrit pas ce que le système sera, mais ce que les utilisateurs pourront faire. Cette distinction entre l’être et le faire est au cœur du document. Un système peut embarquer des dizaines de fonctionnalités et rester inutilisable si les utilisateurs ne peuvent pas accomplir les actions qui correspondent à leurs besoins réels. Le cahier des charges fonctionnel part toujours de l’action attendue, jamais de la liste des composants qui la rendront possible.

Le distinguer du cahier des charges d’achat et du cahier des charges technique

Trois documents portent souvent le nom générique de cahier des charges, mais ils ne servent pas le même objectif et ne s’adressent pas aux mêmes personnes. Les confondre est une source d’erreurs aux conséquences coûteuses.

Le cahier des charges d’achat, parfois appelé cahier des charges de consultation fournisseur, sert à comparer des offres commerciales sur un produit ou une prestation déjà définie. Il répond à la question : quelle offre du marché correspond le mieux à ce que nous voulons acheter ? Il suppose que le besoin est connu et que les critères de comparaison sont posés. Il s’adresse à des fournisseurs en concurrence sur un périmètre identique. Il vient donc après le cahier des charges fonctionnel, jamais à sa place.

Le cahier des charges technique décrit comment le système sera construit. Il précise les technologies retenues, les architectures choisies, les contraintes d’intégration avec l’existant, les standards à respecter. Il répond à la question : comment va-t-on réaliser ce qui a été décidé ? Il s’adresse aux équipes de réalisation, développeurs, ingénieurs ou architectes, qui ont besoin de savoir exactement par quels moyens produire le résultat.

Le cahier des charges fonctionnel, lui, précède les deux autres. Il répond à la question : qu’est-ce que le résultat doit permettre de faire ? Il s’adresse à quiconque doit proposer une solution, sans lui en imposer une. Il est rédigé par le commanditaire, avant de savoir qui va réaliser le projet et comment.

L’ordre logique est immuable : d’abord le fonctionnel, qui exprime le besoin ; ensuite le technique, qui décrit la solution retenue ; enfin, si nécessaire, le document d’achat, qui compare les offres commerciales sur cette solution. Inverser cet ordre revient à choisir une réponse avant d’avoir posé la question.

Une confusion fréquente consiste à envoyer à un prestataire un document qui mélange les trois niveaux simultanément : on y décrit ce que les utilisateurs veulent faire, comment on imagine que ce sera construit, et les critères sur lesquels on va comparer les offres. Ce mélange prive chaque partie de la clarté dont elle a besoin. Le prestataire ne sait pas ce qui est négociable et ce qui ne l’est pas. Le commanditaire ne peut pas comparer les réponses sur une base commune.

Pourquoi décrire un besoin plutôt qu’une solution change tout

L’erreur la plus fréquente lors de la rédaction d’un cahier des charges fonctionnel n’est pas d’oublier un besoin. C’est d’écrire une solution à la place d’un besoin. Cette confusion, extrêmement répandue, change radicalement la nature du document et ses conséquences pratiques sur le projet.

Prenons un exemple concret. Un dirigeant veut que ses clients puissent accéder à leurs factures sans appeler le service administratif. S’il écrit « il faut un bouton qui exporte les factures en PDF depuis un espace client », il décrit une solution : un bouton, un export, un format PDF. S’il écrit « le client doit pouvoir retrouver et télécharger toute facture émise à son nom sans intervention de notre équipe », il décrit un besoin.

La différence n’est pas cosmétique. La première formulation ferme la porte à toute approche alternative : pas de notification automatique par email, pas d’accès depuis une application mobile, pas d’envoi mensuel groupé. Le prestataire est contraint de livrer exactement ce qui est décrit, même si une autre approche aurait été moins coûteuse, plus simple à maintenir ou mieux adaptée aux usages réels de vos clients. Et si le résultat livré satisfait la description mais ne résout pas le problème de fond, vous n’avez aucun recours : vous avez obtenu ce que vous aviez demandé.

La seconde formulation laisse ouvertes toutes les façons d’atteindre le même résultat. Deux prestataires peuvent y répondre différemment, et vous pouvez comparer leurs propositions sur la base du même besoin. L’un proposera un espace client avec téléchargement direct, l’autre un envoi automatique par email à chaque émission de facture. Les deux réponses sont valides si elles satisfont le besoin tel qu’il est exprimé. Vous choisissez la meilleure, pas la plus fidèle à ce que vous aviez initialement imaginé.

Tant que le document contient des boutons, des onglets, des champs de formulaire ou des noms de technologies, ce n’est pas encore un cahier des charges fonctionnel. C’est déjà une spécification technique déguisée. La règle pratique est directe : si la phrase que vous venez d’écrire décrit un mécanisme plutôt qu’une action attendue par un utilisateur identifiable, remontez d’un niveau et reformulez.

Pour identifier un vrai besoin, deux questions suffisent. Première question : qui doit pouvoir accomplir cette action ? Deuxième question : que doit pouvoir faire cette personne qu’elle ne peut pas faire aujourd’hui ? Les réponses donnent une exigence fonctionnelle correcte. Le mécanisme qui permettra de la satisfaire n’entre pas dans ce document.

Cette discipline de formulation peut sembler contraignante lors de la rédaction. Elle devient un avantage décisif au moment de comparer les offres. Sans un cahier des charges fonctionnel bien rédigé, vous ne pouvez pas évaluer deux prestataires qui proposent des approches très différentes pour répondre au même problème. Avec lui, vous évaluez chaque offre en vous posant une seule question : est-ce que ça satisfait ce besoin, au niveau que j’ai précisé ?

Rendre chaque exigence vérifiable à la livraison

Une exigence qui ne peut pas être vérifiée à la livraison ne sert à rien. Si vous ne pouvez pas répondre par oui ou par non à la question « cette exigence est-elle remplie ? », le document ne vous protège pas au moment de la réception.

Écrire « le système doit être rapide » n’engage personne. Au moment de la réception, si vous estimez que le résultat est lent et que le prestataire estime qu’il est rapide, vous n’avez aucun point de référence commun dans le document pour trancher. La phrase était une intention, pas une exigence.

Écrire « le système doit permettre à un utilisateur de retrouver un dossier client en moins de trois actions depuis la page d’accueil » est une exigence vérifiable. Le jour de la réception, vous ouvrez le résultat, vous cherchez un dossier client, vous comptez les actions. La réponse est soit conforme, soit non conforme. Il n’existe aucune zone d’interprétation.

Ce principe s’applique à chaque ligne du document. Pour chaque exigence, posez-vous cette question : quel test précis confirme qu’elle est remplie ? Si vous ne trouvez pas de réponse concrète à cette question, reformulez l’exigence jusqu’à ce qu’un test soit possible.

Les formulations les plus dangereuses utilisent des adjectifs qualitatifs : intuitif, ergonomique, simple, rapide, robuste, moderne, professionnel. Ces mots n’ont aucune valeur dans un document contractuel. Ils ont une signification pour vous et une signification différente pour le prestataire. Remplacez-les systématiquement par des critères mesurables : une durée, un nombre d’actions, un taux de disponibilité, un seuil quantifiable.

Chaque exigence du cahier des charges fonctionnel devrait pouvoir être cochée ou rejetée sans discussion le jour du contrôle. C’est à ce critère qu’on reconnaît un document sérieux, qui protège à la fois le commanditaire et le prestataire contre les désaccords subjectifs à la réception.

Ce que doit contenir le document, section par section

Un cahier des charges fonctionnel n’a pas de format imposé. Il suit cependant une logique que tout lecteur doit pouvoir suivre sans votre aide. Les sections présentées ici répondent chacune à une question précise. Une section absente laisse un angle mort que le prestataire remplira lui-même au moment de rédiger son offre, selon ses propres hypothèses.

La section contexte et enjeux est souvent rédigée trop rapidement. Un prestataire qui comprend le problème de fond proposera une solution mieux adaptée que celui qui travaille uniquement à partir d’une liste d’exigences isolée de toute explication. Prenez le temps d’expliquer pourquoi ce projet se lance maintenant et quel problème précis il doit résoudre.

La section périmètre est aussi importante que la liste des exigences elle-même. Tout ce qui n’est pas explicitement exclu est potentiellement inclus, ce qui ouvre la porte à des demandes supplémentaires en cours de projet. Lister les exclusions protège les deux parties et évite les désaccords sur l’étendue réelle du travail attendu.

La section critères de réception est souvent absente des documents transmis aux prestataires. Son absence est la principale raison pour laquelle les litiges à la livraison se règlent à l’appréciation de chacun plutôt qu’à partir d’un référentiel commun préétabli. Sans elle, « livrable accepté » reste une notion subjective. Avec elle, c’est un critère opposable.

Qui l’écrit, et avec qui

Le cahier des charges fonctionnel est rédigé par le commanditaire : celui qui exprime le besoin et qui va payer pour qu’il soit satisfait. Ce n’est pas le prestataire qui le rédige, même s’il dispose d’une expertise reconnue sur le sujet. Si le prestataire écrit lui-même ce document, il définit ce qu’il va vous livrer, ce qui retire tout intérêt à l’exercice.

Le rédacteur porte le rôle de maîtrise d’ouvrage. Il représente les besoins du commanditaire, pas les solutions du réalisateur. Ce rôle peut être tenu par le dirigeant lui-même dans une TPE ou une PME, ou par un responsable de projet côté client dans une organisation plus structurée. Il exige, dans tous les cas, d’interroger les futurs utilisateurs du résultat plutôt que de transcrire uniquement ce que le dirigeant imagine depuis son bureau.

Les futurs utilisateurs expriment naturellement leurs besoins sous forme de solutions : ils demandent un bouton, un onglet, un fichier à exporter. Le rôle du rédacteur est de reformuler ces demandes en besoins fonctionnels, en remontant d’un niveau pour retrouver l’action réellement attendue derrière chaque demande exprimée. C’est ce travail de traduction qui donne sa valeur au document.

Pour structurer les rôles de chacun dans ce processus, une matrice RACI précise qui est responsable de la rédaction, qui doit être consulté pour alimenter le document, qui valide le contenu avant transmission, et qui doit simplement être tenu informé de l’avancement. Cet outil évite les zones d’ombre sur les responsabilités et les surprises en cours de rédaction.

Prioriser les exigences sans en perdre le fil

Toutes les exigences ne sont pas égales. Certaines sont indispensables : si elles ne sont pas satisfaites, le résultat est inutilisable. D’autres sont importantes mais n’empêchent pas de travailler si elles manquent lors d’une première livraison. D’autres encore sont souhaitables et peuvent attendre une version ultérieure du projet, sans remettre en question la réception initiale.

Cette hiérarchie doit apparaître clairement dans le document. Sans elle, le prestataire ne sait pas où concentrer ses efforts si une contrainte budgétaire ou de délai l’oblige à faire des choix. Il arbitrera à votre place, ce qui n’est pas ce que vous souhaitez.

Trois niveaux suffisent dans un projet courant : indispensable, important, souhaitable. Il est inutile d’en créer cinq ou six. Une granularité excessive devient contre-productive : les discussions sur la priorité d’une exigence peuvent alors durer plus longtemps que sa réalisation elle-même.

La priorisation doit être faite avant la transmission du document, pas pendant les négociations avec le prestataire. Attendre que le prestataire demande ce qui peut être retiré revient à négocier sous contrainte, dans l’urgence, avec une partie qui a intérêt à réduire son propre périmètre de travail. La priorisation est un acte de clarté que le commanditaire accomplit pour lui-même, avant d’engager quiconque d’autre.

Une vérification utile une fois la priorisation terminée : estimez si le budget prévisionnel est cohérent avec les seules exigences « indispensables ». Si ces dernières dépassent déjà l’enveloppe disponible, le document présente un problème à résoudre avant d’être transmis à un prestataire.

Le budget et les délais, jusqu’où aller dans le cahier des charges fonctionnel

Le budget et les délais ont leur place dans le cahier des charges fonctionnel, sous une forme précise : une enveloppe globale et une date cible. Pas de décomposition ligne par ligne par exigence, pas de planning détaillé semaine par semaine à ce stade.

Indiquer un budget plafond permet aux prestataires de calibrer leur réponse. Ils savent qu’une proposition qui dépasse significativement cette enveloppe ne sera pas retenue, et ils arbitrent en conséquence entre les exigences importantes et les souhaitables. Ne pas indiquer de budget est une erreur fréquente : elle oblige à comparer des offres aux périmètres incomparables et crée une asymétrie d’information au détriment du commanditaire.

Pour les délais, indiquer une date cible de mise en service et les contraintes calendaires incontournables suffit au stade du cahier des charges fonctionnel. La définition précise des jalons de projet relève ensuite de la discussion avec le prestataire retenu, une fois la solution choisie et la méthode de travail arrêtée entre les parties.

Si vous devez construire un calendrier global avant même de sélectionner le prestataire, bâtir un rétro-planning à partir de la date cible vous aidera à identifier les contraintes calendaires irréductibles à mentionner dans le document, sans entrer dans le détail d’un planning d’exécution qui n’appartient pas encore à cette étape du projet.

Le faire relire et valider avant de le transmettre

Un cahier des charges fonctionnel ne se transmet pas sans avoir été relu par au moins deux personnes qui n’ont pas participé à sa rédaction. Cette relecture extérieure détecte ce que l’auteur ne voit plus : les ambiguïtés, les présupposés implicites, les passages compréhensibles uniquement parce qu’il connaît déjà le contexte.

La première relecture devrait être conduite par un futur utilisateur du résultat. Il vérifie que les exigences correspondent à ce qu’il vivra réellement au quotidien et signale ce que le document a oublié ou mal exprimé. Cette relecture terrain est souvent la plus révélatrice des angles morts de la rédaction initiale.

La seconde relecture devrait être conduite par une personne extérieure au projet, sans connaissance préalable du sujet. Elle vérifie que le document est compréhensible sans explication orale. Si elle doit poser des questions pour comprendre ce qui est attendu, le document n’est pas encore prêt pour la transmission.

Une fois les corrections intégrées, le document doit être formellement validé avant transmission. Cette validation peut prendre la forme d’une signature, d’un email de confirmation, ou d’une décision actée lors d’une réunion dont le compte rendu de réunion constituera la trace officielle et opposable. Sans cette validation, le document reste un brouillon, même si vous l’avez déjà transmis.

Pour les projets impliquant plusieurs décideurs, la validation mérite d’être organisée lors d’un comité de pilotage dédié à cet objet. Cette instance réunit les personnes qui ont autorité pour engager le projet et garantit que chacune a effectivement lu et approuvé le document avant sa diffusion externe vers les prestataires.

Ce qui se passe quand un prestataire propose autre chose que ce qui est demandé

Un prestataire peut répondre à votre cahier des charges fonctionnel en proposant une approche différente de celle que vous aviez imaginée. C’est non seulement possible, c’est parfois souhaitable. C’est précisément pourquoi un cahier des charges fonctionnel décrit des besoins et non des solutions : pour laisser de la place à une réponse meilleure que celle que vous auriez conçue vous-même.

La question à poser face à une proposition alternative n’est pas « est-ce ce que j’avais demandé ? » mais « est-ce que ça satisfait les exigences que j’ai posées ? ». Si la réponse est oui, la proposition est valide, même si elle est différente de votre vision initiale. Si la réponse est non, le prestataire doit préciser comment il compte couvrir les exigences qui restent insatisfaites dans sa proposition.

Il faut cependant distinguer deux situations. Première situation : le prestataire propose une approche différente qui satisfait toutes vos exigences. C’est exactement le scénario que le cahier des charges fonctionnel est censé rendre possible. Évaluez l’offre sur la base des exigences, pas sur la base du mécanisme choisi. Deuxième situation : le prestataire propose une approche différente qui ne couvre pas certaines exigences indispensables, en arguant que c’est meilleur pour vous. Demandez-lui de démontrer que vos besoins seront couverts, ou d’adapter sa proposition en conséquence.

Ce raisonnement est particulièrement structurant lorsque vous lancez un appel d’offres fournisseur auprès de plusieurs prestataires. Sans cahier des charges fonctionnel clair, les réponses ne reposent pas sur le même référentiel et ne peuvent pas être comparées objectivement. Avec lui, vous évaluez chaque réponse exigence par exigence, quel que soit le chemin technique choisi par chaque candidat.

Faire évoluer le document en cours de projet sans le dénaturer

Un cahier des charges fonctionnel peut évoluer. Les projets durent des semaines ou des mois, et le contexte change. Un besoin non identifié au départ peut apparaître. Une exigence peut s’avérer inutile ou irréaliste une fois les premières livraisons intermédiaires en main. L’évolution du document n’est pas un problème en soi.

Le problème, c’est une évolution non tracée et non validée. Si une exigence change verbalement, sans que le document soit mis à jour et que les deux parties valident cette modification, deux versions du projet coexistent : celle que le prestataire a en tête et celle que vous avez en tête. C’est la source la plus fréquente des incompréhensions à la livraison, et l’une des plus coûteuses à corriger.

Chaque modification du document doit respecter ce protocole :

• Identifier explicitement ce qui change : quelle exigence, dans quel sens, et pour quelle raison
• Évaluer l’impact de cette modification sur le budget et le délai convenus
• Obtenir la validation formelle des deux parties avant de considérer le changement comme acté
• Dater la modification et numéroter la nouvelle version du document

Un tableau de versionnement en première page du document, listant chaque version avec sa date et son objet, permet de retracer l’historique des décisions. Ce n’est pas de la formalité superflue : c’est ce qui vous permettra, en cas de désaccord, de démontrer ce qui avait été convenu et à quel moment précis.

Les signaux qu’un cahier des charges est mal écrit

Certains signaux permettent de détecter rapidement qu’un cahier des charges fonctionnel n’est pas utilisable tel quel. Repérer ces signaux avant d’envoyer le document évite de mettre un prestataire en situation de travailler sur une base incorrecte dès le départ.

Premier signal : le document décrit des composants d’interface. Si vous lisez des mentions de boutons, d’onglets, de menus déroulants ou de champs de formulaire, vous n’êtes pas dans un cahier des charges fonctionnel. Ces éléments appartiennent aux spécifications techniques, pas à ce document.

Deuxième signal : aucune exigence ne mentionne de critère mesurable. Si toutes les phrases contiennent des mots comme « facilement », « rapidement », « intuitivement » ou « simplement », le document ne permettra de vérifier quoi que ce soit à la livraison.

Troisième signal : le document ne distingue pas ce qui est indispensable de ce qui est souhaitable. Si toutes les exigences semblent avoir le même poids, le prestataire ne peut pas arbitrer en cas de contrainte budgétaire ou calendaire.

Quatrième signal : il est impossible de comprendre à quoi sert le projet sans explications orales supplémentaires. Un bon document est autosuffisant. Un lecteur qui ne vous connaît pas doit comprendre le besoin en lisant le document seul.

Cinquième signal : le document a été rédigé par une seule personne, sans consultation des futurs utilisateurs du résultat. Les angles morts dans ce cas sont nombreux et systématiques, et ils apparaissent toujours au pire moment, à la livraison.

Lorsque vous repérez l’un de ces signaux, reprenez la section concernée avant transmission. Un document rédigé trop rapidement pour gagner du temps en coûte souvent beaucoup plus à corriger une fois la réalisation engagée sur de mauvaises bases.

Un cahier des charges fonctionnel complet déroulé de bout en bout, pour un projet concret

Voici un exemple complet pour ancrer tout ce qui précède. Une PME de services à domicile, quinze salariés, deux cents clients actifs, souhaite permettre à ses clients de réserver des interventions, de consulter l’historique de leurs prestations et de régler en ligne, sans passer par téléphone ou email.

Section contexte et enjeux : la société traite aujourd’hui toutes ses réservations par téléphone et par email. Cette gestion mobilise une personne à mi-temps pour la coordination des appels entrants. L’objectif est de permettre aux clients de gérer leurs réservations de manière autonome, de réduire le volume de contacts entrants et d’accélérer les encaissements.

Section périmètre : sont inclus dans ce projet la prise de réservation par le client en ligne, la consultation de l’historique des interventions et le paiement en ligne. Sont explicitement exclus la gestion des plannings des intervenants, la facturation interne, la gestion des ressources humaines et la comptabilité.

Section parties prenantes : trois profils utilisent le résultat. Le client final réserve, consulte et paie. L’administrateur de la société valide les réservations hors créneaux automatiques et consulte les paiements. Le gérant accède aux données globales sans pouvoir les modifier directement.

Section contraintes : le résultat doit fonctionner sur les principaux navigateurs et sur les terminaux mobiles. Il doit respecter la réglementation en vigueur sur la protection des données personnelles. Il doit pouvoir être administré par une personne sans compétence technique.

Section budget et délais : l’enveloppe globale est de douze mille euros pour la réalisation initiale. La date cible de mise en service est fixée à six mois après le démarrage effectif du projet.

Le tableau de suivi des exigences de ce projet montre comment chaque besoin est formulé, priorisé, vérifié et renseigné à la réception :

Une fois le document relu par deux membres de l’équipe et par un client test, il est transmis à trois prestataires en concurrence. Chacun répond en indiquant, exigence par exigence, si elle est couverte, à quel niveau et avec quelle approche. Les exigences « indispensables » non couvertes dans une offre éliminent cette offre de la comparaison, sans négociation.

Pour que la collaboration tienne dans la durée et que les engagements de chaque partie soient posés dès le départ, définir les termes généraux du projet au sein d’une charte de projet formalise le cadre de gouvernance et les responsabilités de chacun dès le démarrage effectif.

Les erreurs qui reviennent et comment chacune se corrige

Les mêmes erreurs se retrouvent dans un grand nombre de cahiers des charges fonctionnels, quel que soit le secteur d’activité ou la taille de l’organisation. Identifier ces erreurs avant transmission permet de les corriger sans reprendre le document entièrement.

Chacune de ces erreurs a une correction directe qui ne nécessite pas de reprendre le document entièrement. Il s’agit de revenir sur les passages concernés avec trois questions simples : est-ce que j’exprime un besoin ou une solution ? Est-ce que cette exigence peut être vérifiée le jour de la réception sans discussion ? Est-ce que n’importe quel lecteur extérieur comprend ce que j’attends en lisant cette ligne ?

Organiser le suivi de projet avec Djaboo après validation du document

Djaboo est un logiciel de gestion tout-en-un conçu pour les TPE et les PME, qui centralise la gestion des projets, des clients, des tâches et de la facturation dans une interface accessible sans compétences techniques.

Lorsque votre cahier des charges fonctionnel est validé et que le prestataire est sélectionné, Djaboo vous permet d’organiser la suite du travail. Un projet créé porte un nom, un client, une description, un statut, une date de début, une échéance, un nombre d’heures estimées et un indicateur d’avancement. Chaque tâche rattachée à ce projet porte un nom, une description, une priorité, un statut, des dates de début et de fin, un rattachement à un jalon, et deux indicateurs précisant si la tâche est facturable et si elle a déjà été facturée. Le projet dispose d’un espace pour déposer des fichiers, avec un réglage indiquant si chaque fichier est visible par le client ou non, ainsi que des notes, des discussions et un journal d’activité horodaté.

Il faut être explicite sur ce que Djaboo ne fait pas, sans contourner ces limites. Il n’existe aucun objet « cahier des charges » dans l’outil : pas de gabarit dédié, pas de champ « exigence », pas de case à cocher à la réception pour confirmer qu’une exigence est satisfaite ou non. Le champ « priorité » d’une tâche est un libellé libre : ce n’est pas une classification formelle des exigences par niveau d’importance. Aucun budget ni aucune durée ne se rattache à une tâche individuelle ; seul le projet entier porte des heures estimées. Il n’existe aucune matrice reliant une exigence à la tâche ou au fichier qui la satisfait, et aucune signature ni validation formelle d’un document n’est possible dans l’outil.

Voici comment travailler proprement malgré ces limites. Le cahier des charges fonctionnel se rédige hors de l’outil, dans un traitement de texte ou un tableur, puis se dépose comme fichier joint au projet avec le réglage de visibilité adapté selon que vous souhaitez le partager avec le client ou non. Chaque exigence retenue devient ensuite une tâche distincte dans le projet, ce qui permet de tracer son exécution et de la facturer si besoin. Le niveau de priorité de l’exigence, tel qu’il figure dans le document, se recopie dans le libellé de priorité de la tâche pour rester visible au quotidien. La vérification à la livraison se fait à la main, en reprenant le document exigence par exigence : l’outil ne le fera jamais automatiquement.

Décrire un besoin plutôt qu’une solution n’est pas une contrainte formelle : c’est ce qui laisse la place à la meilleure réponse. Un prestataire qui comprend ce que vous devez accomplir peut proposer une approche que vous n’aviez pas imaginée et qui se révèle plus pertinente, moins coûteuse ou plus simple à maintenir sur la durée. Un prestataire enfermé dans une liste de composants techniques livre exactement ce qu’on lui a demandé, même si ce n’est pas ce dont vous aviez besoin.

Une exigence qui ne se vérifie pas à la livraison n’a jamais été une exigence : c’était une intention. La différence entre les deux se mesure au moment de la réception, quand il faut décider si le résultat est conforme ou non. Un document construit sur des intentions laisse cette décision à l’appréciation de chacun. Un document construit sur des exigences vérifiables la rend objective, indépendante des humeurs et des interprétations du moment.