# Comment rédiger le cahier des charges d’un projet logiciel Un cahier des charges clair est le moyen le moins coûteux d’obtenir un devis utile. Voici les sept rubriques qui couvrent la plupart des projets logiciels, et ce qu’il vaut mieux laisser de côté. - Page: https://www.cognivise.co.uk/fr/blog/comment-rediger-cahier-charges-projet-logiciel - Original (anglais): https://www.cognivise.co.uk/blog/how-to-write-a-software-project-brief - Sujet: Créer des logiciels - Publié: 2026-10-09 - Mis à jour: 2026-10-09 - Auteur: Cognivise ## À retenir - Un cahier des charges décrit le problème, les personnes concernées et ce à quoi ressemble la réussite. Ce n’est pas une liste de fonctionnalités. - Une page qu’un inconnu peut comprendre vaut mieux que vingt pages que personne ne lit jusqu’au bout. - Dites ce qui est figé et ce qui reste ouvert. Les prestataires ne peuvent être honnêtes sur les coûts et les délais que s’ils savent faire la différence. - Écrivez ce qui est hors périmètre. Aucune autre partie du document n’évite autant de désaccords. ## Pourquoi le cahier des charges compte-t-il ? Tout devis logiciel est une réponse à ce que le prestataire pense que vous avez demandé. Un cahier des charges vague donne un devis vague, et deux prestataires peuvent lire la même phrase et chiffrer deux projets différents. C’est pourquoi les devis pour un même travail sont souvent si éloignés les uns des autres. Un bon cahier des charges n’a pas besoin de jargon technique. Il demande une réflexion claire sur le problème, mise par écrit. Notre guide sur [ce qui détermine le coût d’un logiciel sur mesure](https://www.cognivise.co.uk/blog/how-much-does-custom-software-cost) explique pourquoi le périmètre est le principal levier sur le prix. C’est dans le cahier des charges que vous le fixez. ## Que doit contenir le cahier des charges d’un projet logiciel ? Avec ces sept rubriques, vous pouvez presque tout couvrir en une ou deux pages. ### 1. Le problème Décrivez ce qui est lent, risqué, coûteux ou impossible aujourd’hui. Parlez de la situation, pas de la solution. « Notre équipe ressaisit les commandes reçues par e-mail dans trois systèmes, et des erreurs atteignent les clients » est un problème. « Il nous faut un portail de commande » est une solution qui convient peut-être, peut-être pas. ### 2. À qui il s’adresse Listez les groupes de personnes qui l’utiliseront ou seront concernées : salariés, clients, fournisseurs, managers. Pour chacun, indiquez à peu près leur nombre et ce qu’ils doivent faire. Des utilisateurs externes impliquent en général plus de travail de conception, de sécurité et de support que des utilisateurs internes. ### 3. À quoi ressemble la réussite Dites comment vous saurez que cela a fonctionné. Choisissez un critère observable : moins d’étapes manuelles, des délais de traitement plus courts ou moins d’erreurs. Évitez les objectifs que vous ne pouvez pas mesurer ou que vous n’avez jamais mesurés. ### 4. Ce qu’il doit faire en premier Listez les quelques fonctions que la première version doit assurer pour que le projet en vaille la peine. Tout le reste va dans une liste « plus tard ». C’est l’étape la plus utile pour maîtriser les coûts, et c’est ainsi que l’on définit le périmètre d’un bon [MVP](https://www.cognivise.co.uk/blog/mvp-development-for-startups). ### 5. Ce à quoi il se connecte Nommez les systèmes avec lesquels le logiciel doit fonctionner : comptabilité, boutique en ligne, CRM, tableur, prestataire de paiement. Indiquez ce que vous savez de chacun, y compris qui s’en occupe. C’est souvent sur les intégrations que les estimations dérapent, car elles dépendent de systèmes que vous ne maîtrisez pas. ### 6. Les contraintes Indiquez tout ce qui limite la solution : - une fourchette de budget, ou au moins un plafond à ne pas dépasser - une date qui ne peut pas bouger, et pourquoi - les obligations légales ou réglementaires, comme le traitement des données personnelles au titre du UK GDPR - les technologies à utiliser ou à proscrire - les personnes qui doivent valider les décisions Si vous ne connaissez pas le budget, dites-le. Une fourchette aide le prestataire à proposer une solution adaptée plutôt qu’à deviner. ### 7. Ce qui est hors périmètre Précisez ce que vous ne demandez pas. Cela paraît superflu jusqu’au premier désaccord. Une courte liste d’exclusions, comme « pas d’application mobile dans la première version » ou « pas de migration des données de l’ancien système », évite bien des discussions par la suite. ## Que faut-il laisser de côté ? - **Des maquettes d’écrans détaillées, sauf si vous les avez déjà.** Les prestataires doivent les élaborer avec vous. - **Une technologie précise, sauf s’il existe une vraie raison.** Demandez une recommandation et ses justifications. - **Toutes les fonctionnalités imaginables.** Une longue liste rend les éléments importants plus difficiles à repérer. - **Des informations confidentielles que vous ne partageriez pas avec un candidat non retenu.** Donnez plus de détails une fois le prestataire choisi et un accord signé. ## Comment savoir si le cahier des charges est prêt ? Donnez-le à quelqu’un qui n’a pas participé au projet et demandez-lui de vous l’expliquer. S’il ne peut pas dire quel problème est résolu et pour qui, réécrivez-le. Vérifiez ensuite ces points : - Dit-il ce que vous voulez voir changer, et pas seulement ce que vous voulez faire construire ? - Deux prestataires chiffreraient-ils à peu près le même projet à partir de ce document ? - Indique-t-il ce qui est figé et ce qui reste ouvert à la discussion ? - Précise-t-il qui prend les décisions de votre côté ? ## Et si vous n’êtes pas prêt à rédiger un cahier des charges ? Parfois, la réponse honnête est que vous ne pouvez pas encore remplir toutes les rubriques. Vous connaissez peut-être le problème mais pas la solution, ou l’inverse. C’est normal, et c’est précisément le rôle d’une courte phase de cadrage. Consultez [la phase de cadrage technique expliquée](https://www.cognivise.co.uk/blog/technical-discovery-explained) pour voir comment elle transforme une idée approximative en périmètre écrit. Une fois votre cahier des charges rédigé, servez-vous-en pour comparer les prestataires sur un pied d’égalité. Notre guide [pour choisir une entreprise de développement logiciel](https://www.cognivise.co.uk/blog/how-to-choose-a-software-development-company) liste les questions à poser à chacun. ## Questions fréquentes **Quelle longueur doit faire un cahier des charges ?** Une à deux pages suffisent pour la plupart des projets. Ajoutez des détails là où la complexité est réelle, par exemple pour des intégrations inhabituelles ou une réglementation spécifique. **Faut-il indiquer un budget ?** Une fourchette ou un plafond est utile. Les prestataires qui le connaissent peuvent proposer des options adaptées, et vous pouvez comparer ce que chacun livrerait pour un même montant. **Puis-je envoyer le même cahier des charges à plusieurs prestataires ?** Oui, et c’est la façon la plus équitable de les comparer. Donnez à tous les mêmes informations et partagez vos réponses à leurs questions avec chacun. **Et si le cahier des charges évolue une fois le travail commencé ?** Il évoluera, et c’est acceptable. Convenez avant de démarrer de la manière dont les changements sont décidés et chiffrés, pour qu’un changement donne lieu à une discussion plutôt qu’à un litige. Si vous souhaitez de l’aide pour transformer une idée approximative en périmètre clair, notre service de [développement de logiciels sur mesure](https://www.cognivise.co.uk/fr/services/developpement-logiciel-sur-mesure) commence par là, et vous pouvez [nous contacter](https://www.cognivise.co.uk/fr/contact) pour démarrer. ## À lire aussi - [Développement de logiciels sur mesure](https://www.cognivise.co.uk/services/custom-software-development) - [Combien coûte un logiciel sur mesure ?](https://www.cognivise.co.uk/blog/how-much-does-custom-software-cost) - [Cadrage technique : ce qui se passe avant un projet logiciel](https://www.cognivise.co.uk/blog/technical-discovery-explained) - [Équipes dédiées](https://www.cognivise.co.uk/fr/services/equipe-de-developpement-dediee)