Comment rédiger un cahier des charges logiciel [Modèle + Guide]

Parmi tous les facteurs déterminant la réussite d'un projet logiciel — la pile technologique, l'agence que vous choisissez, le budget que vous allouez — celui qui importe le plus intervient avant même que ces décisions ne soient prises. Il s'agit de la qualité de votre cahier des charges.

Nous avons examiné des centaines de demandes de projets chez Cyberbeak. Le seul indicateur véritablement fiable permettant de prévoir si un projet sera livré dans les délais, dans le respect du budget et avec le résultat que le client souhaitait vraiment n'est pas la taille de l'entreprise, la sophistication technique des parties prenantes, ni même leur disposition à investir. C'est la clarté et l'honnêteté avec lesquelles ils ont consigné ce dont ils ont besoin et pourquoi.

Un cahier des charges solide ne garantit pas le succès d'un projet. Mais un cahier des charges médiocre produit presque toujours un projet qui échoue — ou, au minimum, un projet coûteux, interminable et frustrant. Il crée dès le premier jour des attentes mal alignées, génère des devis très approximatifs, attire les mauvaises agences en compétition et met l'équipe dans la position de construire efficacement la mauvaise chose.

Ce guide vous explique précisément comment rédiger un cahier des charges qui vous permettra d'obtenir des tarifs précis, d'attirer des partenaires sérieux et de donner à votre projet les fondations dont il a besoin. Nous avons inclus un modèle pratique à compléter que vous pouvez utiliser dès aujourd'hui, ainsi que les erreurs les plus fréquentes que nous observons et comment les éviter.

---

Pourquoi un bon cahier des charges est important

Lorsqu'une agence reçoit un cahier des charges vague, elle a deux options : vous poser de nombreuses questions de clarification avant de pouvoir définir la portée des travaux, ou intégrer des hypothèses dans sa proposition et tarifer l'incertitude. La plupart des agences choisissent la seconde option — en partie parce que c'est plus rapide, en partie parce qu'elles ne souhaitent pas paraître exigeantes avant d'avoir remporté le contrat.

Tarifer l'incertitude signifie gonfler les prix. Une agence qui ne connaît pas vos besoins en intégration supposera de la complexité. Une agence qui ne connaît pas vos contraintes de délai ajoutera des marges de sécurité. Une agence qui ne sait pas si vous disposez d'éléments de design ou si ceux-ci doivent être créés de toutes pièces proposera un tarif pour les deux possibilités et facturera en conséquence. Le résultat est une proposition soit gonflée pour couvrir les inconnues, soit définie si sommairement que le budget s'élargit dès le début des travaux.

L'inverse est tout aussi vrai. Un cahier des charges clair et détaillé produit des tarifs précis, car l'agence peut définir la portée avec précision plutôt que par prudence défensive. Il génère de meilleures propositions, car les équipes expérimentées peuvent s'attaquer à votre problème réel plutôt que de faire des suppositions éclairées. Et il produit de meilleures listes restreintes, car les agences qui ne conviennent pas se désélectionnent elles-mêmes plutôt que de remporter des marchés qu'elles ne peuvent pas bien exécuter.

Au-delà du pricing, un cahier des charges bien rédigé accomplit quelque chose de plus important : il vous oblige à clarifier votre propre réflexion. Le fait de consigner par écrit le problème que vous résolvez, les utilisateurs pour lesquels vous le résolvez et les résultats commerciaux par rapport auxquels vous vous mesurez fera remonter les lacunes, les contradictions et les hypothèses dans votre réflexion avant qu'elles ne deviennent des demandes de modification coûteuses en cours de projet. Certains de nos projets les mieux gérés ont commencé avec un client qui nous a dit avoir rédigé et réécrit son cahier des charges trois fois avant de l'envoyer — et chaque version lui avait appris quelque chose sur son propre produit.

---

Ce qu'un cahier des charges N'EST PAS

Avant d'aborder la structure, il est utile de clarifier ce qu'un cahier des charges n'est pas — car la confusion avec d'autres documents est l'une des erreurs les plus courantes que nous observons.

Un cahier des charges n'est pas une spécification technique. Une spécification technique décrit précisément comment un système sera construit — les modèles de données, les contrats d'API, les choix technologiques, les décisions d'architecture. Ce document vient plus tard, généralement comme une production conjointe entre vous et l'agence que vous engagez, après une phase de découverte. Rédiger une spécification technique avant d'avoir engagé un partenaire de développement, c'est mettre la charrue avant les bœufs. Cela vous enferme dans des décisions qui devraient être prises de manière collaborative.

Un cahier des charges n'est pas un wireframe ni un ensemble de maquettes. Les wireframes sont des artefacts de design qui décrivent la mise en page des interfaces. Les partager peut constituer un contexte utile, mais un cahier des charges n'est pas un recueil d'écrans. Décrire ce que le logiciel doit faire au niveau des flux utilisateurs et des résultats est bien plus utile que de décrire ce à quoi vous pensez que l'interface devrait ressembler. Cette dernière approche contraint l'agence sans résoudre le problème sous-jacent.

Un cahier des charges n'est pas un contrat. Rien dans un cahier des charges n'est juridiquement contraignant. C'est une invitation à s'engager — une description structurée de votre projet conçue pour attirer les bons partenaires et leur permettre de répondre avec précision. Les contrats viennent après la sélection, lors de la phase commerciale. Traitez le cahier des charges comme un document de communication, non comme un document juridique.

Un cahier des charges n'est pas une demande pour le prix le plus bas. Si votre cahier des charges se lit principalement comme un document de négociation conçu pour solliciter un devis bas, les agences expérimentées le remarqueront et soit déclineront, soit intégreront des hypothèses défensives dans leur tarification. L'objectif d'un cahier des charges est une compréhension partagée, non une course vers le bas.

Ces distinctions étant claires, voici ce qu'est réellement un cahier des charges : un compte rendu structuré et honnête du problème que vous essayez de résoudre, du contexte dans lequel vous le résolvez, de ce à quoi ressemble le succès et des contraintes dans lesquelles vous travaillez. C'est tout. Il n'a pas besoin d'être long. Il n'a pas besoin d'utiliser un langage technique. Il doit être clair, précis et honnête.

---

Les 8 sections que tout cahier des charges logiciel devrait inclure

1. Présentation du projet

Commencez par le problème, non par la solution. C'est la section que la plupart des cahiers des charges ratent — ils s'ouvrent sur une description de ce que le client souhaite construire plutôt que sur les raisons pour lesquelles il souhaite le construire. La distinction est d'une importance capitale.

« Nous souhaitons développer une application mobile avec un tableau de bord, un module de réservation et un panneau d'administration » est une description de solution. « Notre équipe de services terrain gère actuellement plus de 200 rendez-vous hebdomadaires dans trois bureaux régionaux à l'aide de tableurs et d'appels téléphoniques, et nous perdons environ 15 % des réservations en raison d'erreurs de planification et de mauvaise communication » est une description de problème. La seconde est nettement plus utile, car elle indique à une équipe de développement expérimentée ce qui doit réellement être résolu — ce qui peut nécessiter ou non exactement la solution que vous avez imaginée.

Votre présentation du projet devrait couvrir :

• Le problème central ou l'opportunité que vous adressez
• Qui subit actuellement ce problème et comment il le gère aujourd'hui
• Pourquoi maintenant — ce qui a changé, ou ce qui motive cette initiative à ce moment précis
• Une brève description de la solution que vous envisagez (en gardant à l'esprit qu'il s'agit d'un point de départ, non d'une exigence fixe)
• Le type de produit que vous construisez — application web, application mobile, outil interne, plateforme API, système e-commerce, ou une combinaison

Limitez cette section à un ou deux paragraphes. Son rôle est d'orienter rapidement l'agence, pas de raconter l'histoire complète.

2. Contexte métier et objectifs

Un logiciel existe pour servir des résultats commerciaux ou organisationnels. Une agence qui comprend vos objectifs métier peut prendre de meilleures décisions techniques, signaler des risques que vous n'avez pas anticipés et hiérarchiser les fonctionnalités en fonction de ce qui importe vraiment pour votre résultat net.

Cette section devrait couvrir :

• Votre modèle économique — construisez-vous pour des clients, des utilisateurs internes, ou les deux ? S'agit-il d'un produit générateur de revenus ou d'une initiative de réduction des coûts ?
• Objectifs commerciaux — à quoi ressemble le succès en termes métier ? Plus de transactions, un coût opérationnel réduit, un temps de traitement plus rapide, l'entrée sur un nouveau marché ?
• Indicateurs de succès mesurables — comment saurez-vous dans 12 mois si le projet a réussi ? Soyez précis. « Efficacité améliorée » n'est pas un indicateur. « Réduire le temps de saisie manuelle de données de 60 % » en est un.
• Importance stratégique — s'agit-il d'un produit central ou d'un outil de support ? Est-ce un MVP conçu pour tester la demande, ou un système de production remplaçant quelque chose qui existe déjà ?
• Paysage des parties prenantes — qui en interne s'intéresse à ce projet et comment ? Un cahier des charges qui mentionne « le PDG parraine personnellement cette initiative » ou « le directeur financier a approuvé le budget à condition que nous atteignions un lancement en décembre » dit beaucoup à une agence sur la dynamique dans laquelle elle travaillera.

3. Utilisateurs

Les meilleurs logiciels sont construits autour d'une compréhension précise de qui les utilisera et de ce qu'ils doivent accomplir. Les descriptions génériques d'utilisateurs (« propriétaires de petites entreprises », « clients enterprise ») sont quasi inutiles. Les descriptions précises sont extrêmement précieuses.

Pour chaque type d'utilisateur, décrivez :

• Qui ils sont — leur rôle, leur contexte, l'environnement dans lequel ils utiliseront le produit (bureau, mobile, terrain, environnement d'opérations sous pression)
• Leur niveau de sophistication technique — sont-ils à l'aise avec des interfaces logicielles complexes, ou ont-ils besoin d'une expérience très simplifiée ? Utilisent-ils déjà des outils similaires ?
• Ce qu'ils doivent accomplir — les deux ou trois tâches qu'ils doivent pouvoir effectuer efficacement avec ce produit
• Volume — pour combien d'utilisateurs de ce type concevez-vous ? Dix utilisateurs internes ont des exigences très différentes de dix mille consommateurs
• Toute exigence d'accessibilité — obligations légales ou considérations pour les utilisateurs en situation de handicap

Si vous avez effectué des recherches utilisateurs, des entretiens clients, ou si vous disposez de données sur le comportement actuel des utilisateurs, partagez-les. Même des notes brutes sont précieuses. Si vous n'avez effectué aucune recherche utilisateur, dites-le — une bonne agence vous aidera à comprendre comment l'intégrer dans la phase de découverte.

4. Fonctionnalités et fonctions principales

C'est souvent la section la plus longue d'un cahier des charges, et il vaut la peine d'y investir du temps pour bien la rédiger. L'objectif n'est pas de rédiger une liste exhaustive de fonctionnalités, mais de communiquer la portée de ce dont vous avez besoin de manière suffisamment claire pour qu'une agence puisse estimer le travail avec une confiance raisonnable.

Structurez cette section autour de deux catégories :

Les indispensables sont les fonctionnalités sans lesquelles le produit ne peut pas être lancé et délivrer sa valeur centrale. Si la suppression d'une fonctionnalité signifie que le produit échoue à résoudre le problème pour lequel il existe, c'est un indispensable.

Les souhaitables sont les fonctionnalités qui ajouteraient de la valeur mais ne sont pas requises pour le lancement. Être explicite sur cette distinction est l'une des choses les plus utiles que vous puissiez faire dans un cahier des charges. Cela indique à l'agence ce qui est dans le périmètre de l'engagement initial et signale que vous comprenez la gestion du périmètre.

Pour chaque fonctionnalité significative, rédigez une courte user story au format : « En tant que [type d'utilisateur], je veux [faire quelque chose], afin de [résultat]. » Les user stories maintiennent les descriptions centrées sur le besoin utilisateur plutôt que sur les hypothèses d'interface.

Par exemple :

• En tant que technicien terrain, je veux recevoir mes missions sur mon téléphone avec toutes les informations client pertinentes jointes, afin de ne pas avoir à appeler le bureau pour obtenir des détails avant d'arriver sur site.
• En tant que responsable financier, je veux exporter des rapports de transactions mensuels au format CSV et PDF, afin de pouvoir les partager avec nos comptables externes sans reformatage manuel.

Vous n'avez pas besoin d'une user story pour chaque micro-interaction. Concentrez-vous sur les flux qui définissent le produit.

Notez également les fonctionnalités que vous avez explicitement décidé de mettre hors périmètre pour cet engagement. Indiquer ce que vous ne construisez pas est parfois aussi utile que d'indiquer ce que vous construisez.

5. Exigences et contraintes techniques

C'est la section où de nombreux clients non techniques se sentent incertains. Ne laissez pas cela vous empêcher d'inclure ce que vous savez — et soyez honnête sur ce que vous ne savez pas, car une bonne agence vous aidera à combler les lacunes pendant la découverte.

Couvrez les éléments suivants, selon les cas :

• Systèmes existants et intégrations — ce produit doit-il se connecter à d'autres logiciels ? Listez chaque système par nom. CRM (Salesforce, HubSpot), ERP (SAP, NetSuite), passerelles de paiement (Stripe, PayPal), plateformes de communication (Twilio), logiciels de comptabilité (Xero, QuickBooks), APIs logistiques. Le travail d'intégration est fréquemment la source la plus importante de complexité et de coûts inattendus, donc plus vous êtes précis ici, mieux c'est.
• Migration des données — déplacez-vous des données depuis un système existant ? Quelle quantité de données, dans quel format, et quelle est leur complexité ?
• Préférences d'hébergement et d'infrastructure — avez-vous une préférence pour une plateforme cloud (AWS, Azure, Google Cloud) ? Une infrastructure existante dans laquelle vous devez déployer ? Des exigences spécifiques de résidence des données géographiques ?
• Contraintes technologiques — votre équipe interne a-t-elle une préférence ou une exigence technologique ? Avez-vous des développeurs qui maintiendront le produit après le lancement, et si oui, quelle est leur pile technologique ?
• Exigences de conformité et réglementaires — RGPD, PCI-DSS pour le traitement des paiements, HIPAA pour les données de santé, ISO 27001, réglementations FCA, normes d'accessibilité (WCAG). Listez toutes les obligations de conformité dont vous avez connaissance.
• Exigences de performance — le système doit-il gérer de grands volumes d'utilisateurs simultanés ? Le traitement de données en temps réel ? Des temps de réponse inférieurs à la seconde sous charge ?
• Exigences navigateurs et appareils — quels navigateurs et appareils le produit doit-il prendre en charge ? Doit-il fonctionner hors ligne ?

6. Design et identité de marque

Soyez clair sur votre point de départ afin que l'agence puisse estimer avec précision le travail de design.

• Éléments de marque existants — disposez-vous d'un guide de style, d'une bibliothèque de composants ou d'un système de design existant ? Si oui, le cahier des charges concerne-t-il un nouveau logiciel qui devrait les suivre, ou un produit autonome avec sa propre identité visuelle ?
• Travail de design existant — avez-vous commandé des wireframes, des maquettes ou un design d'interface utilisateur ? Attendez-vous de l'agence qu'elle implémente un design existant, ou qu'elle conçoive à partir de zéro ?
• Apparence, atmosphère et ton — décrivez l'expérience que vous souhaitez offrir aux utilisateurs. Référencez des exemples de produits que vous admirez sur le plan esthétique ou en termes d'UX. Si vous avez des opinions fortes sur ce que vous ne voulez pas, dites-le.
• Livrables de design attendus — attendez-vous de l'agence qu'elle produise des artefacts de design (guide de style, bibliothèque de composants, prototypes) dans le cadre de l'engagement, ou qu'elle implémente simplement le produit fini ?

7. Budget et calendrier

C'est la section que les clients laissent le plus souvent vide, et c'est l'omission la plus coûteuse. Abordons directement la question du budget : refuser de partager un budget ne vous protège pas. C'est le contraire.

Lorsqu'une agence ne connaît pas votre budget, elle ne peut pas adapter sa proposition. Elle soit sur-ingéniera (produisant une proposition que vous ne pouvez pas vous permettre) soit sous-dimensionnera (produisant une proposition qui manque ce dont vous avez réellement besoin). Dans les deux cas, vous perdez du temps — le vôtre et le leur — et obtenez des propositions qui ne peuvent pas être comparées de manière significative.

Vous n'avez pas besoin de vous engager sur un chiffre précis. Une fourchette (« nous disposons d'un budget dans la région de 60 000–80 000 £ pour la phase initiale ») est tout à fait suffisante et donne à une agence tout ce dont elle a besoin pour définir la portée de manière appropriée.

Pour le calendrier :

• Date de lancement cible — si vous en avez une, partagez-la. Si elle est flexible, dites-le
• Échéances fermes — dates réglementaires, événements de lancement de produit, engagements du conseil d'administration, obligations contractuelles
• Approche par phases — êtes-vous ouvert à une approche par phases de la construction ? Si oui, à quoi ressemble un MVP par rapport à une version complète ?
• Disponibilité côté client — qui de votre équipe sera impliqué, et quelle part de son temps est disponible ? Les contraintes de ressources côté client constituent un paramètre légitime pour la planification du calendrier

8. Critères de sélection

Terminez votre cahier des charges en indiquant aux agences sur quels critères vous les évaluez. C'est une bonne pratique pour deux raisons : elle attire les agences qui correspondent vraiment à vos critères et décourage celles qui ne correspondent pas, et elle signale que vous êtes un acheteur structuré et professionnel — ce que les agences expérimentées souhaitent activement.

Les critères de sélection courants incluent : l'expérience sectorielle ou technologique pertinente, la séniorité de l'équipe, l'approche de communication, le modèle de support post-lancement, la tarification, l'adéquation culturelle et l'approche ou la méthodologie proposée. Pondérez-les si vous le pouvez — « la capacité technique est notre critère principal ; le prix est secondaire » est une information utile.

---

Modèle de cahier des charges

Utilisez cette structure comme point de départ. L'exemple ci-dessous montre un cahier des charges complété pour une place de marché B2B — remplacez chaque champ par les détails de votre propre projet. Signalez les sections sur lesquelles vous êtes incertain afin que l'agence puisse vous aider à les développer lors de la découverte.

---

TradeHub — Plateforme de place de marché B2B — Cahier des charges logiciel

Soumis par : Acme Distribution Ltd — Sarah Chen, Responsable Produit Date : 15 janvier 2025 Date limite de réponse : 31 janvier 2025

---

Section 1 : Présentation du projet

Quel est le problème central que ce logiciel résoudra ? Qui le rencontre ? Pourquoi y répond-on maintenant ? Quel type de produit construisez-vous ?

• Énoncé du problème : Notre réseau de plus de 400 fournisseurs professionnels gère actuellement les relations avec les acheteurs via un mix de commandes téléphoniques, de PDFs par e-mail et d'un système de gestion des commandes datant de 2011. Les acheteurs — principalement des responsables des achats dans des entreprises du bâtiment et de la gestion de sites — ne peuvent pas consulter les stocks actuels, vérifier les tarifs en temps réel ou passer des commandes en dehors des heures ouvrées. Les fournisseurs n'ont aucune visibilité sur l'activité des acheteurs ou le statut des commandes sans relances manuelles.
• Pourquoi maintenant : Deux concurrents majeurs ont lancé des portails d'achat numérique au cours des 18 derniers mois. Nous perdons des comptes de taille intermédiaire précisément parce que nous ne pouvons pas proposer une expérience de commande en libre-service. Le conseil d'administration a approuvé le budget pour le T1 2025.
• Solution proposée (vue d'ensemble) : Une place de marché B2B multi-vendeurs où les fournisseurs agréés listent des produits et gèrent leurs stocks, et où les acheteurs professionnels vérifiés parcourent, demandent des devis et passent des commandes avec des conditions de paiement différé. L'opérateur de la plateforme (nous) gère l'intégration des fournisseurs et perçoit une commission sur les transactions.
• Type de produit : Application web (priorité bureau, responsive mobile)

---

Section 2 : Contexte métier et objectifs

Quels sont les résultats commerciaux ou organisationnels que ce projet est conçu à délivrer ?

• Contexte du modèle économique : Commission de plateforme de 4 à 8 % sur chaque transaction, par paliers selon le volume du fournisseur. Les fournisseurs ne paient pas de frais de référencement. Les acheteurs paient à 30 ou 60 jours selon le statut du compte.
• Objectif commercial principal : Retenir le réseau de fournisseurs existant et récupérer 20 % des comptes acheteurs de taille intermédiaire perdus dans les 12 mois suivant le lancement.
• Indicateurs de succès : 2 M£ de GMV via la plateforme dans les 6 mois suivant le lancement ; 80+ fournisseurs actifs référencés dans les 90 jours ; taux moyen de conversion session-commande des acheteurs supérieur à 18 %.
• Importance stratégique : Il s'agit de la principale initiative de croissance numérique de l'entreprise pour 2025–2026. Ce n'est pas un projet secondaire.
• Principales parties prenantes internes : PDG (approbation finale), Responsable Produit (contact au quotidien), Directeur Commercial (relations fournisseurs), Responsable IT (décisions d'infrastructure).

---

Section 3 : Utilisateurs

Qui utilisera ce produit ? Répéter pour chaque type d'utilisateur distinct.

Type d'utilisateur 1 — Acheteur professionnel (Responsable des achats)

• Rôle / description : Responsables des achats et acheteurs dans des entreprises du bâtiment, de la gestion de sites et de la maintenance. Ils passent des commandes récurrentes de consommables, d'outils et d'équipements au nom de leur organisation.
• Sophistication technique : Moyenne — à l'aise avec les outils web, utilisent l'e-mail et les tableurs au quotidien, mais sans profil technique
• Tâches clés : Parcourir et rechercher des produits parmi les fournisseurs, vérifier les prix et la disponibilité, passer des commandes sur les comptes existants, suivre le statut des commandes, générer des rapports d'achats
• Volume approximatif : 2 000 à 3 000 acheteurs enregistrés au déploiement complet
• Exigences d'accessibilité : Conformité WCAG 2.1 AA requise (certains utilisateurs sont des professionnels de la trade plus âgés)

Type d'utilisateur 2 — Fournisseur professionnel (Vendeur)

• Rôle / description : Personnel commercial et opérationnel de notre réseau de fournisseurs. Ils gèrent leurs fiches produits, répondent aux demandes de devis et exécutent les commandes passées via la plateforme.
• Sophistication technique : Faible à moyenne — beaucoup ne sont pas très à l'aise avec le numérique ; l'interface doit être simple
• Tâches clés : Télécharger et gérer les fiches produits et les tarifs, répondre aux demandes des acheteurs, gérer le pipeline de commandes, consulter les analytics de ventes, recevoir les paiements
• Volume approximatif : 400 à 600 fournisseurs enregistrés

Type d'utilisateur 3 — Administrateur de la plateforme (Interne)

• Rôle / description : Notre équipe opérationnelle interne qui approuve l'intégration des fournisseurs, gère les comptes acheteurs, résout les litiges et surveille la santé de la plateforme
• Sophistication technique : Élevée
• Tâches clés : Approuver/rejeter les candidatures des fournisseurs, gérer les structures de commission, consulter les analytics de la plateforme, gérer les litiges

---

Section 4 : Fonctionnalités et fonctions principales

Fonctionnalités indispensables (sans lesquelles le produit ne peut pas être lancé) :

Fonctionnalité	User Story	Notes
Catalogue produits et recherche	En tant qu'acheteur, je veux rechercher et filtrer des produits parmi tous les fournisseurs afin de trouver rapidement ce dont j'ai besoin	Recherche plein texte, filtres par catégorie, fournisseur, prix, disponibilité
RFQ (Demande de devis)	En tant qu'acheteur, je veux demander un devis personnalisé à un fournisseur afin de négocier les prix sur les commandes importantes	Le fournisseur reçoit une notification et répond dans la plateforme
Commande avec paiement différé	En tant qu'acheteur, je veux passer une commande sur mon compte crédit afin de payer à 30 jours sans carte	Plafonds de crédit définis par l'administrateur par acheteur
Gestion des produits vendeur	En tant que fournisseur, je veux ajouter et mettre à jour mes fiches produits et tarifs afin que mon catalogue reste à jour	Import CSV en masse requis pour les fournisseurs avec de grands catalogues
Gestion des commandes (les deux côtés)	En tant que fournisseur, je veux voir les commandes entrantes et les marquer comme expédiées afin que les acheteurs reçoivent des mises à jour de statut	Notifications e-mail à chaque changement de statut
Moteur de commission et de paiement	En tant qu'opérateur de plateforme, je veux calculer automatiquement la commission sur chaque transaction et planifier les paiements aux fournisseurs	Stripe Connect pour les paiements fractionnés et les versements

Fonctionnalités souhaitables (utiles mais non requises pour le lancement) :

Fonctionnalité	User Story	Notes
Listes de commandes enregistrées / favoris	En tant qu'acheteur, je veux enregistrer les produits fréquemment commandés afin de pouvoir les recommander rapidement	Priorité pour la V1.1
Notes de performance des fournisseurs	En tant qu'acheteur, je veux voir les notes d'exécution des fournisseurs afin de prendre des décisions éclairées	Nécessite une politique de modération avant le lancement
Intégration ERP (Sage/Xero)	En tant qu'acheteur, je veux que les commandes se synchronisent automatiquement avec notre système comptable	Dépend des ERP effectivement utilisés par les acheteurs — nécessite une recherche complémentaire

Explicitement hors périmètre pour cet engagement :

• Applications mobiles natives iOS ou Android (le web responsive est suffisant pour le lancement)
• Multi-devises ou livraison internationale (marché britannique uniquement au lancement)
• Pages produits publiques pour le SEO (la plateforme est fermée aux comptes enregistrés uniquement)

---

Section 5 : Exigences et contraintes techniques

• Intégrations requises : Stripe Connect (paiements fractionnés et versements aux fournisseurs), SendGrid (e-mail transactionnel), HubSpot CRM (synchronisation des fiches acheteurs et fournisseurs), Companies House API (vérification KYB lors de l'intégration des fournisseurs)
• Migration des données : Oui — environ 12 000 fiches produits depuis le système historique (base de données SQL Server, export disponible en CSV). Les données de comptes fournisseurs et acheteurs doivent également être migrées (~400 fournisseurs, ~1 800 comptes acheteurs). La qualité des données est connue pour être incohérente et devra être nettoyée.
• Préférences d'hébergement / infrastructure : AWS préféré (compte AWS existant en place). Région britannique requise pour la résidence des données.
• Contraintes technologiques : Aucune contrainte sur le choix de la pile — nous nous en remettons à la recommandation de l'agence. Le système historique est en .NET mais nous ne sommes pas liés à la technologie Microsoft.
• Exigences de conformité : RGPD (Royaume-Uni) — nous traitons des données personnelles pour les acheteurs et les fournisseurs. Pas de périmètre PCI-DSS requis si nous utilisons Stripe pour le traitement des paiements.
• Exigences de performance : La recherche de produits doit retourner des résultats en moins d'une seconde. La plateforme doit supporter 500 utilisateurs simultanés au lancement sans dégradation.
• Support navigateurs / appareils : Chrome, Firefox, Safari, Edge (2 dernières versions). Responsive mobile mais le bureau est le cas d'usage principal.
• Inconnues techniques connues : Nous ne savons pas si la synchronisation des stocks en temps réel depuis les systèmes de stocks des fournisseurs est faisable au lancement — cela dépend de la compatibilité des systèmes fournisseurs. Nous aimerions avoir l'avis de l'agence à ce sujet lors de la découverte.

---

Section 6 : Design et identité de marque

• Éléments de marque existants : Nous disposons d'un guide de style de marque de base (logo, palette de couleurs, typographie) mais pas de bibliothèque de composants ni de système de design d'interface utilisateur
• Travail de design existant : Aucun — nous partons de zéro sur le design produit
• Approche design : L'agence conçoit à partir de zéro, en respectant nos directives de marque
• Références d'apparence et d'atmosphère : Nous admirons la clarté de Faire.com (place de marché de gros) et l'efficacité de l'interface de gestion de projet de Procore. Propre, professionnel, fonctionnel plutôt que décoratif.
• Livrables de design attendus : Wireframes UX pour les flux clés, designs UI haute fidélité pour tous les écrans, une bibliothèque de composants livrée avec la base de code

---

Section 7 : Budget et calendrier

• Fourchette budgétaire : 120 000–180 000 £ pour le MVP (indispensables des Sections 1 et 4 ci-dessus). Nous comprenons que cela devra peut-être être affiné après la découverte.
• Date de lancement cible : Bêta privée avec 20 fournisseurs pilotes et 50 acheteurs en octobre 2025. Lancement public en janvier 2026.
• Échéance ferme : La date de la bêta privée (octobre 2025) est importante mais pas contractuellement fixée. Le lancement public de janvier 2026 est lié à une participation à un salon professionnel et est ferme.
• Ouvert à une approche par phases : Oui — nous sommes ouverts à une approche par phases de la construction si cela réduit les risques. Notre préférence est d'avoir quelque chose d'utilisable par les acheteurs et les fournisseurs le plus tôt possible, même si l'ensemble de fonctionnalités est réduit.
• Disponibilité des ressources côté client : Sarah Chen (Responsable Produit) est disponible 2 à 3 jours par semaine comme contact client principal. Notre Responsable IT peut apporter son soutien sur les décisions d'infrastructure. Pas de ressources de développement internes.

---

Section 8 : Critères de sélection

Nous évaluerons les réponses selon les critères suivants (par ordre approximatif de priorité) :

1. Expérience démontrée avec les plateformes de place de marché multi-vendeurs et les implémentations de paiements fractionnés / Stripe Connect
2. Séniorité de l'équipe proposée pour notre projet — nous souhaitons des ingénieurs seniors, pas une équipe de livraison junior
3. Crédibilité et spécificité de l'approche technique proposée (nous serons rebutés par des propositions génériques)
4. Modèle de support post-lancement et options de contrat de développement continu
5. Adéquation commerciale dans notre fourchette budgétaire indiquée

Format de réponse demandé : Veuillez inclure un résumé de votre approche technique proposée, une estimation approximative des coûts décomposée par phase, la composition de votre équipe proposée avec les niveaux de séniorité, et deux ou trois études de cas de projets de place de marché comparables.

Date limite de réponse : 31 janvier 2025

---

Erreurs courantes dans les cahiers des charges

Se concentrer trop sur la solution

L'erreur la plus courante dans un cahier des charges est de décrire une interface spécifique plutôt qu'un besoin utilisateur. « Nous avons besoin d'un tableau de bord à trois colonnes avec un panneau de filtres à gauche et un tableau de données au centre » indique à une agence ce que vous avez imaginé, pas ce que vos utilisateurs ont besoin d'accomplir. Cela contraint le design sans résoudre le problème sous-jacent, et cela ferme des solutions que l'agence aurait pu proposer et qui sont meilleures que ce que vous avez imaginé.

Décrivez le résultat. Décrivez l'utilisateur. Laissez le processus de design déterminer l'interface.

Le cahier des charges « Airbnb pour X »

« Nous voulons construire un Airbnb pour la garde de chiens » ou « un Spotify pour les livres audio » ou « un Uber pour l'entretien des jardins » n'est pas un cahier des charges. C'est une métaphore. Et c'est presque toujours le signe que l'auteur n'a pas encore fait le travail difficile de comprendre ce que le produit doit réellement faire.

Les produits de référence sont utiles pour transmettre une ambition approximative ou une direction esthétique, mais ils ne peuvent pas remplacer une description réelle de vos utilisateurs, de vos fonctionnalités et de votre modèle économique. Les agences expérimentées ont vu ce schéma si souvent qu'il est devenu un signal d'alarme léger — il suggère que le client n'a peut-être pas encore de clarté sur ce qu'il construit réellement.

Refuser de partager votre budget

Nous avons abordé ce point ci-dessus, mais il mérite d'être souligné. Lorsqu'un client refuse de partager un budget, les agences expérimentées ne supposent pas que cela signifie que le budget est important. Elles supposent soit que le client ne sait pas, soit que le budget est inférieur à ce que le projet exige, soit que le client utilise l'opacité budgétaire comme tactique de négociation. Aucune de ces hypothèses ne produit de meilleurs résultats pour vous. Partagez une fourchette. Vous obtiendrez de meilleures propositions.

Omettre un calendrier

L'absence d'information sur le calendrier signifie qu'une agence ne peut pas planifier l'allocation des ressources, signaler les conflits de planification ou vous dire si vos ambitions sont réalistes. Même « nous n'avons pas d'échéance ferme mais souhaiterions idéalement lancer dans les six mois » est utile. Une absence totale d'information sur le calendrier ne l'est pas.

Omission des exigences d'intégration

Les intégrations sont la source de complexité et de coûts la plus sous-estimée dans les projets logiciels. Une intégration CRM qui semble triviale peut impliquer des flux d'authentification complexes, des limites de débit, une correspondance de données, une gestion des erreurs et une surcharge de maintenance continue. Une agence qui découvre une intégration non divulguée en cours de projet soumettra une demande de modification. Partagez toutes les exigences d'intégration dont vous avez connaissance, même si vous n'êtes pas sûr des détails techniques.

Envoyer le cahier des charges à trop d'agences

Une idée reçue courante est que l'envoi de votre cahier des charges à quinze agences maximise la concurrence et fait baisser les prix. En pratique, c'est l'inverse. Les agences expérimentées savent quand elles participent à un processus compétitif de grande ampleur. Soit elles refusent d'investir dans une réponse approfondie, soit elles produisent une proposition moins élaborée qui couvre les bases sans offrir de véritable analyse. Une liste restreinte de trois à cinq agences réellement adaptées à votre projet produira des réponses plus approfondies et plus engagées qu'une distribution de masse qui signale que vous traitez cela comme un exercice de mise en concurrence.

---

Quelle devrait être la longueur d'un cahier des charges ?

Il n'y a pas de réponse universelle, mais il existe des directives raisonnables par type de projet.

Type de projet	Longueur suggérée du cahier des charges
Outil interne simple ou MVP	2–4 pages
Application web de complexité moyenne	4–8 pages
Produit ou plateforme grand public	6–10 pages
Système enterprise avec plusieurs intégrations	8–15 pages
Secteur réglementé (fintech, santé, juridique)	10–20 pages

La longueur n'est pas un indicateur de qualité. Un cahier des charges de quatre pages précis, honnête et complet produira de meilleures réponses qu'un cahier des charges de quinze pages bourré d'exigences vagues et d'en-têtes de sections répétées. Concentrez-vous sur la substance, pas sur le volume.

Si votre cahier des charges dépasse dix pages pour un projet simple, c'est généralement le signe que les exigences ne sont pas encore suffisamment priorisées, ou que vous incluez des décisions de design et des spécifications techniques qui appartiennent à des documents ultérieurs.

---

Ce qui se passe après l'envoi du cahier des charges

À quoi ressemble une bonne réponse d'agence :

Une réponse solide à votre cahier des charges démontrera que l'agence l'a réellement lu. Elle fera référence à votre problème spécifique, à vos utilisateurs et à vos contraintes — et ne se contentera pas de vous répéter votre cahier des charges avec du jargon marketing autour. Elle posera des questions de clarification lorsque des informations font réellement défaut plutôt que de supposer. Elle vous donnera une estimation crédible avec des hypothèses clairement énoncées, et elle vous indiquera ce qu'elle suppose pour produire cette estimation.

Une bonne réponse remettra également en question de manière constructive, le cas échéant. Si votre calendrier est irréaliste par rapport au périmètre que vous avez décrit, une agence compétente vous le dira, expliquera pourquoi et proposera des options. Si votre budget est mal aligné avec vos ambitions, elle le dira clairement. Les agences qui vous disent que tout est réalisable dans vos contraintes sans aucune réserve ne font pas preuve d'optimisme — elles ne regardent pas assez attentivement, ou elles prévoient de soulever la question plus tard comme une demande de modification.

À quoi ressemble une réponse faible :

Méfiez-vous des propositions qui sont riches en références d'entreprise et pauvres en engagement avec votre cahier des charges réel. Méfiez-vous des devis à prix fixe pour des projets complexes sans hypothèses énoncées — cela signifie soit que le prix inclut une large contingence, soit que le périmètre sera interprété restrictivement et élargi plus tard. Méfiez-vous des agences qui ne peuvent pas vous dire qui travaillera sur votre projet et quel est leur niveau d'expérience.

Gérer le processus après la réception des réponses :

Une fois que vous avez reçu les réponses, évaluez chacune selon le même cadre d'évaluation. Comparez-les selon les critères que vous avez énoncés dans votre cahier des charges. Si une agence a fait des hypothèses que vous n'aviez pas prévues, revenez vers elle avec des questions de clarification avant de l'écarter — parfois les hypothèses révèlent une véritable incompréhension qu'une conversation peut résoudre. Invitez vos deux ou trois agences préférées à un appel. La qualité de la conversation vous en dira presque autant que la proposition écrite.

---

Comment nous utilisons votre cahier des charges chez Cyberbeak

Lorsqu'un cahier des charges arrive dans notre boîte de réception, la première chose que nous faisons est de le lire de bout en bout sans regarder aucun des détails techniques. Nous voulons comprendre le problème métier et le contexte commercial avant de penser à la technologie. Les cahiers des charges qui rendent cela clair sont ceux qui nous enthousiasment le plus — ils nous indiquent que nous avons affaire à un client qui pense en termes de résultats, pas seulement de fonctionnalités.

À partir de là, nous évaluons l'adéquation. Nous sommes honnêtes lorsqu'un projet n'est pas dans notre domaine de compétence, et nous le disons plutôt que de nous proposer pour un rôle que nous ne pouvons pas bien remplir. Si le projet convient, nous entrons dans un processus de réponse structuré — une personne est responsable de la réponse commerciale, une autre de l'approche technique, et nous revoyons les deux ensemble avant que quoi que ce soit ne soit envoyé au client.

Avant de finaliser toute proposition, nous reviendrons généralement vers vous avec une courte liste de questions de clarification. Ce n'est pas le signe que votre cahier des charges était mauvais — presque tous les cahiers des charges ont des lacunes, et les lacunes sont généralement là où se trouvent les décisions les plus importantes. Nous préférons faire remonter une ambiguïté dans une conversation plutôt que de la supposer tout au long du développement et de découvrir le décalage six semaines après le début du développement.

Pour les projets plus importants ou plus complexes, nous recommandons souvent une phase de découverte payante avant de nous engager sur une estimation complète. La découverte permet aux deux parties de comprendre profondément le problème, de valider les hypothèses avec les utilisateurs et de produire un document de périmètre ancré dans les preuves plutôt que dans les conjectures. Le résultat d'une bonne phase de découverte n'est pas seulement un meilleur périmètre — c'est une probabilité significativement plus élevée d'un projet réussi.

---

FAQ

Ai-je besoin d'un cahier des charges si je m'engage sur une base en régie ?

Oui, bien qu'il puisse être plus court et moins prescriptif. Même dans les engagements en régie, une agence a besoin de comprendre votre contexte métier, vos utilisateurs, votre paysage d'intégration et vos critères de succès pour prendre de bonnes décisions pendant le développement. Un cahier des charges pour un engagement en régie n'a pas besoin d'être une liste de fonctionnalités exhaustive, mais il devrait couvrir au minimum les quatre premières sections du modèle ci-dessus. Sans ce contexte, même une excellente équipe de développement construira efficacement la mauvaise chose.

Devrais-je inclure des wireframes ou des maquettes dans mon cahier des charges ?

Inclure des wireframes ou des maquettes existants en tant que matériel complémentaire est acceptable — cela peut aider à transmettre la portée et l'intention, en particulier pour les interfaces utilisateur complexes. Mais ne confondez pas les wireframes avec un cahier des charges, et ne laissez pas l'existence de wireframes remplacer une description appropriée des besoins des utilisateurs et des objectifs métier. Si vos wireframes représentent une réflexion préliminaire plutôt qu'un design validé, signalez-le. Une agence qui interprète des wireframes approximatifs comme des exigences fixes les tarifieras et construira selon ces wireframes, même si elle aurait proposé quelque chose de mieux avec plus de liberté.

Et si je ne connais vraiment pas mon budget ?

Commencez par les principes fondamentaux. Recherchez ce que coûte la construction de produits logiciels comparables — notre guide sur le coût du développement de logiciels sur mesure est un bon point de départ. Parlez à votre équipe financière ou à votre conseil d'administration de l'investissement justifié compte tenu de la valeur commerciale que le projet est censé délivrer. Même une fourchette large — « nous pensons à une fourchette de 40 000–100 000 £ selon le périmètre » — est plus utile que le silence. Si vous n'avez vraiment aucune clarté budgétaire, l'approche la plus honnête est de le dire dans votre cahier des charges et de demander aux agences de répondre avec une gamme d'options de périmètre à différents niveaux d'investissement.

Comment comparer les devis de différentes agences lorsqu'elles ont défini le périmètre différemment ?

C'est l'un des défis les plus courants dans un processus d'appel d'offres compétitif, et la réponse honnête est que vous ne pouvez pas le faire directement sans poser des questions de clarification. Lorsque les devis diffèrent significativement, l'étape la plus utile est d'identifier les hypothèses clés que chaque agence a faites et de leur demander de s'aligner sur un périmètre commun avant de finaliser leurs chiffres. Un devis bon marché qui a exclu la moitié du travail d'intégration n'est pas moins cher — il est incomplet. Un devis plus élevé qui inclut une phase de test complète, la documentation et le support post-lancement peut représenter une meilleure valeur. Demandez à chaque agence de décomposer son devis par phase ou flux de travail, afin de pouvoir comparer des éléments comparables plutôt que de comparer les totaux.

---

Un cahier des charges bien rédigé est un investissement de quelques heures qui se rentabilise plusieurs fois — en devis plus précis, en meilleures propositions, en processus de sélection d'agence plus propre, et en un engagement de développement qui commence à partir d'une compréhension partagée plutôt que d'hypothèses accumulées.

Si vous souhaitez un second avis sur un cahier des charges que vous avez déjà rédigé, ou si vous construisez un projet et souhaitez discuter de la façon de structurer vos exigences, nous serions ravis de vous aider. Contactez notre équipe et nous pouvons généralement vous fournir une réponse initiale dans un délai d'un jour ouvrable.