Document d’exigences logicielles : le guide du fondateur non technique pour en rédiger un qui obtient un devis
Ce qui entre, ce qui reste dehors, et le test qui dit quand le document est prêt à partir vers un studio logiciel.
Un mardi après-midi, une fondatrice d’une fintech parisienne a ouvert ses mails et lu trois devis qu’elle avait demandés à trois studios logiciels différents, tous basés sur le même document de 14 pages qu’elle avait passé un week-end entier à écrire. Le premier devis indiquait 140 000 € en quatre mois. Le deuxième indiquait 320 000 € en sept mois. Le troisième n’arrivait pas sous forme de devis. Il arrivait sous forme d’une liste de 27 questions et d’une phrase : « avant de chiffrer, nous avons besoin de mieux comprendre ».
Les trois studios ont lu le même document et sont arrivés à trois décisions différentes. Pas parce que l’un avait raison et les autres tort. Parce que le document ne décidait rien à leur place.
C’est le problème central qu’un document d’exigences logicielles résout quand il fonctionne, et le problème qu’il crée quand il est écrit comme une rédaction de collège, ou pire, comme la spécification d’un système bancaire de 1998. Pour la fondatrice non technique qui est sur le point de faire produire la première version d’un produit, le document d’exigences n’est pas un exercice académique. C’est la pièce qui décide combien ça coûte, combien de temps ça prend, et ce qui arrive.
Ce guide couvre ce qui entre, ce qui reste dehors, et comment savoir quand le document est prêt à sortir.
Ce qu’est un document d’exigences logicielles, en une phrase
Un document d’exigences logicielles décrit ce qu’un logiciel doit faire (et ce qu’il n’a pas besoin de faire) avec un niveau de détail suffisant pour qu’une équipe de développement puisse l’estimer, le contractualiser et le construire sans tours infinis de clarification.
C’est une définition modeste, intentionnellement. Le document n’est pas la spécification complète du produit. Ce n’est pas le contrat. Ce n’est pas la roadmap. C’est l’instrument qui relie le problème que vous décrivez clairement (parce que c’est votre métier) au système que quelqu’un d’autre va construire (parce que c’est son métier à lui). Tout ce que le document doit faire, c’est rendre cette traversée bon marché.
Quand il fonctionne, trois studios le lisent et reviennent avec des devis proches en délai, en périmètre et en prix, avec des questions ciblées plutôt que des listes de 27 points. Quand il ne fonctionne pas, vous recevez trois plans pour trois produits différents.
Pourquoi le modèle SRS de l’université ne vous sert pas
Le terme technique est SRS : Software Requirements Specification. C’est le document que les écoles d’ingénieurs en informatique enseignent à rédiger depuis les années 80. La plupart des modèles qui apparaissent en première page de Google quand vous cherchez « document d’exigences logicielles » sont des variations de ce schéma : sommaire de 14 sections, exigences fonctionnelles et non fonctionnelles séparées, diagramme de cas d’utilisation, glossaire, matrice de traçabilité.
Ce modèle a été conçu pour une réalité qui n’est pas la vôtre. Il a été fait pour des projets logiciels commandés par de grands groupes, avec des délais de deux à cinq ans, des équipes QA internes qui vont tester contre la spécification, et un audit réglementaire après la livraison. Pour une fintech early-stage, une clinique qui monte son back-office, ou une marketplace de niche qui sort une première version, ce format échoue pour trois raisons.
Il est trop long. Un SRS bien fait fait 40 à 120 pages. Aucun studio logiciel ne va lire 80 pages avant de chiffrer. Ils vont survoler les dix premières, identifier trois points confus, et vous renvoyer la liste de questions. Vous avez passé un week-end et vous êtes au même point.
Il est fait pour valider la livraison, pas pour vendre le projet en interne. Le SRS traditionnel documente « ce que le système va faire » pour que plus tard quelqu’un puisse tester s’il l’a fait. Vous n’avez pas encore besoin de ça. Vous avez besoin que trois studios s’accordent sur combien coûte ce que vous voulez.
Il exige une précision technique que vous n’avez pas. Exigences non fonctionnelles, contraintes d’architecture, modèle de données conceptuel. Si vous saviez écrire ça correctement, vous ne chercheriez pas un studio. Essayer de faire technique produit des documents qui sont soit faux (un studio le verra), soit trop vagues (tous le verront).
L’alternative n’est pas de ne rien écrire. C’est d’écrire un document plus court, plus tranché, adressé à un lecteur précis : la personne qui va chiffrer votre projet.
Les 5 blocs qui tiennent en 8 pages
Le document qui fonctionne pour une fondatrice non technique compte cinq blocs. Il tient en six à huit pages. Il est écrit en prose, avec des listes là où la liste aide. Chaque bloc a un objectif déclaré.
Bloc 1 : Le problème, en une page au plus. Qui est l’utilisateur, quelle est la vraie douleur, et pourquoi la douleur existe maintenant. Ce n’est pas le pitch deck. C’est la description honnête de la situation : l’opération manuelle que vous remplacez, le tableur qui a cassé, le processus qui vit sur WhatsApp et qui doit devenir un produit. La personne qui chiffre utilise cette page pour calibrer tout ce qui suit. Si la douleur paraît petite, le budget paraît grand. Si la douleur est évidente, le reste du document bénéficie du doute.
Bloc 2 : L’utilisateur, en une page ou moins. Un paragraphe par persona, trois personas maximum. Pour chacun : ce qu’il fait aujourd’hui, ce qu’il a besoin que le produit fasse, et où il l’utilise (mobile, desktop, au comptoir, à la maison). C’est ici que des questions comme « est-ce que ça doit marcher sur téléphone ? » et « est-ce qu’il faut un accès hors ligne ? » trouvent leur réponse sans devenir des exigences non fonctionnelles. Elles deviennent des faits d’usage.
Bloc 3 : Le périmètre, sous forme « dedans/dehors », en deux à trois pages. C’est la partie la plus précieuse du document, et celle que les founders sous-estiment le plus. Au lieu de lister tout ce que le système va faire, séparez en deux colonnes : ce qui entre dans la première version, et ce qui reste dehors (mais qui existe). La colonne « dehors » est ce qui donne au studio la sécurité de chiffrer la colonne « dedans ». Sans elle, chaque studio chiffre comme si le périmètre était infini, parce que c’est ce que les founders font normalement avec le périmètre. Exemples typiques dans la colonne « dedans » : création de client, génération de devis, export PDF, intégration Stripe. Exemples typiques dans la colonne « dehors » : app native, dashboard BI, intégration avec l’ERP comptable, plan gratuit.
Bloc 4 : Les critères de fini, en une page. Pour la première version, trois à cinq phrases qui décrivent ce qui doit être vrai le jour du lancement. « Un agent immobilier peut enregistrer un bien, générer une proposition en PDF, et l’envoyer à un client en moins de cinq minutes. » « La direction peut voir, en fin de mois, combien de propositions sont devenues des contrats. » Ces critères fonctionnent comme un contrat silencieux : vous n’acceptez pas le produit si l’un d’eux ne se passe pas encore. Ils aident aussi au chiffrage parce qu’ils disent au studio où est la barre. Un critère comme « le système a besoin de 99,99 % de disponibilité » coûte cher. « Le système ne peut pas tomber pendant les heures ouvrées à Paris » coûte moins cher et dit presque la même chose pour votre métier.
Bloc 5 : Contraintes réelles, en une demi-page. Temps, argent, réglementation. Quand vous avez besoin d’être en ligne (et pourquoi). Quel est le plafond de budget (préparez-vous à répondre honnêtement ; les devis se rapprochent de la réalité quand le plafond est sur la table). Quelle réglementation s’applique (RGPD toujours en Europe ; PCI si vous stockez des cartes ; HIPAA si santé aux US ; ACPR si fintech régulée en France). C’est le bloc le plus court et celui qui économise le plus de retravail. Un studio qui sait que vous avez trois mois jusqu’à la prochaine tranche de financement chiffrera différemment d’un studio qui pense que vous avez un an.
Cinq blocs. Six à huit pages. Écrits un week-end sans stress, ou deux après-midi avec du focus. C’est le document qui obtient un devis.
Comment documenter des exigences de façon simple
La réponse courte : vous décrivez chaque bloc dans une réunion de 15 minutes avec vous-même avant d’écrire. Vous ouvrez un document vide, vous mettez le nom du bloc en haut, et vous répondez à voix haute, en enregistrant ou en écrivant sous la forme qui vient. Le texte propre vient ensuite.
Le piège de l’écriture « technique » est ce qui tue la majorité des documents. Les founders non techniques essaient de sonner comme des ingénieurs parce qu’ils supposent que c’est la langue que le studio attend. Ce n’est pas le cas. Les bons studios logiciels lisent le document à voix haute comme s’il s’agissait d’un rendez-vous commercial. Ils font plus confiance à une description claire du problème qu’à un diagramme UML mal dessiné. Si vous hésitez entre « avoir l’air pro » et « être littéral sur ce qui se passe », choisissez toujours la seconde option.
Le deuxième piège est de vouloir tout couvrir. Vous n’y arriverez pas. C’est impossible. Le document d’exigences de la première version est, par conception, un instrument incomplet. Il décrit la première version, pas le produit final. Chaque décision que vous n’avez pas prise maintenant deviendra plus tard une question du studio, et c’est normal. Ce qu’il faut éviter, c’est le document qui semble complet mais qui est vague, parce que celui-là génère des questions pires : des questions qui ressemblent à du détail et qui sont en fait du périmètre.
Le troisième piège est de laisser le document traîner pendant des semaines parce qu’il est « presque prêt ». La version 0,9 de la personne qui possède le problème bat à chaque fois la version 1,0 imaginaire. Si le document remplit les cinq blocs, il est prêt.
Le test du devis : trois signes que le document est prêt
Il n’existe pas de check-list objective pour « document prêt », mais il y a trois signaux empiriques qui reviennent.
Signe 1 : Vous pouvez lire le document à voix haute sans ouvrir de parenthèses. Si vous devez expliquer une phrase pendant que vous la lisez, la phrase n’est pas prête. Réécrivez. La règle vaut pour chaque paragraphe.
Signe 2 : Un ami de votre secteur, sans connaissance technique, peut lire le document et dire « j’ai compris ce que ce produit va faire ». S’il ne peut pas, le studio non plus. Le test s’applique aux Blocs 1 à 3 (problème, utilisateur, périmètre).
Signe 3 : Vous pouvez citer trois choses qui ont été intentionnellement laissées dehors. Si vous ne pouvez pas, vous n’avez pas assez décidé. Retournez au Bloc 3 et enlevez davantage. « Tout entre dans la première version » est ce qui produit les devis gonflés et les calendriers qui glissent.
Quand les trois signaux sont là, le document est prêt à partir. Envoyez-le à deux à quatre studios en même temps. Vous apprendrez plus de la différence entre les devis que de n’importe quel devis pris isolément.
Où s’arrête le document d’exigences et où commence le contrat
Confondre le document d’exigences avec le contrat est la version la plus chère de cette erreur. Le document d’exigences est un instrument de communication. Il n’engage personne. Il décrit le produit que vous voulez et le problème qu’il résout.
Le contrat de développement logiciel est l’instrument juridique qui gouverne la relation. Il couvre les délais, le prix, les conditions de paiement, la propriété du code, la garantie, et ce qui se passe si l’une des parties rompt sa promesse. En général, le contrat annexe le document d’exigences par référence, mais c’est le contrat qui gouverne, pas l’exigence.
La séparation compte parce que les deux documents ont des lecteurs différents. Le document d’exigences est lu par l’équipe technique qui va construire. Le contrat est lu par le juridique (le vôtre et le leur) et par vous, au moment de signer. Si vous essayez de glisser une clause contractuelle dans le document d’exigences, vous embrouillez le studio. Si vous essayez de décrire des fonctionnalités dans le contrat, vous créez un document juridique qui vieillit en deux semaines.
La règle pratique : le document d’exigences décrit le produit. Le contrat décrit la relation. Le périmètre vit dans l’exigence. Le prix, dans le contrat. Les changements qui surviennent pendant la construction vivent dans un troisième document (en général un compte rendu de réunion ou un ticket dans le système du studio), et déclenchent périodiquement des avenants au contrat.
Ce trio (exigence, contrat, suivi des changements) est ce qui tient un projet sans bruit. C’est aussi là que l’analyse de fit avec le studio se joue vraiment : la façon dont un studio répond à votre document d’exigences vous dit plus sur sa manière de travailler avec vous que n’importe quelle présentation commerciale.
Foire aux questions
Que veut dire « exigences » ?
Dans un contexte logiciel, les exigences sont des descriptions de ce que le système doit faire (exigences fonctionnelles) et des conditions dans lesquelles il doit le faire (exigences non fonctionnelles, comme la performance, la sécurité, la disponibilité). Pour un founder non technique, la traduction pratique est : « ce que le produit livre » et « sous quelles limites il le livre ».
Comment documenter des exigences de façon simple ?
En cinq blocs courts : le problème, l’utilisateur, le périmètre (dedans/dehors), les critères de fini, et les contraintes réelles (temps, argent, réglementation). Six à huit pages au total. En prose, pas en diagrammes. Écrit pour un lecteur précis : le studio qui va chiffrer. Détail dans « Les 5 blocs qui tiennent en 8 pages » plus haut.
Le document d’exigences est-il la même chose qu’un PRD ou qu’une spécification fonctionnelle ?
Ce sont des cousins proches, pas la même chose. Le document d’exigences décrit ce que le système doit faire. Le PRD (Product Requirements Document) est plus courant dans les boîtes avec une équipe produit interne et décrit ce que le produit résout et pour qui, en général sans détail technique. La spécification fonctionnelle plonge dans les écrans, les flux et les règles métier. Pour une première commande à un studio, le document d’exigences court décrit ici suffit en général ; le PRD et la spec fonctionnelle apparaissent plus tard, quand le produit tourne et que vous ou le studio devez coordonner plus de détail.
Quels sont les 4 types de documents qui apparaissent dans un achat de logiciel ?
Dans un achat typique de logiciel sur mesure : le brief (une à deux pages que vous utilisez pour vous présenter aux studios et savoir qui vaut la peine), le document d’exigences (celui-ci, six à huit pages), le contrat (l’instrument juridique entre vous et le studio choisi), et le SOW (Statement of Work, qui dans certains montages contractuels remplace ou complète le document d’exigences en annexe du contrat). Les quatre ont des lecteurs différents et des objectifs différents ; les mélanger est l’erreur la plus chère du processus.
Puis-je demander au studio d’écrire le document d’exigences pour moi ?
Vous pouvez, et parfois c’est ce qu’il faut faire (surtout si vous avez déjà un studio de confiance et que vous lancez un discovery formel). Mais le résultat est généralement meilleur quand le document sort d’abord de votre tête, même en forme brute. Vous êtes la seule personne qui connaît le problème en profondeur. Le studio améliorera la forme. Il ne peut pas inventer le problème.
Quand le document d’exigences doit-il devenir une spécification détaillée ?
Quand le projet passe le cap de la première version. Pour la version un, le document court suffit parce que la majorité du détail se découvre pendant la construction, dans la conversation avec le studio. À partir de la version deux (ou d’un pivot significatif), les blocs du document se séparent en artefacts plus gros : le périmètre devient un backlog, les critères de fini deviennent des tests, les contraintes deviennent une politique technique documentée.