accueil / guides / cahier des charges

~/guides/cadrage mis à jour le 22 octobre 2026

Cahier des charges d'un logiciel sur mesure

Vous voulez faire développer un outil métier et obtenir des devis comparables. Le cahier des charges est le document qui le permet. Voici ce qu'il doit contenir, ce qu'on y oublie et ce qu'il vaut mieux laisser au prestataire.

par Andrei Chirtes, dev2cafes

Un cahier des charges de logiciel sur mesure décrit ce que l'outil doit permettre de faire, pour qui, avec quelles données et quelles contraintes, assez précisément pour que deux prestataires chiffrent le même travail. Pour une PME, il n'a pas besoin d'être long. Il doit être complet sur les points qui coûtent cher, et discret sur les choix techniques que le prestataire fera mieux que vous.

Cette page explique à quoi il sert, ce qu'il doit contenir, ce qu'on oublie presque toujours et qui peut l'écrire. Pour partir d'une trame à remplir, le modèle de cahier des charges pour une application web reprend ces rubriques sous forme de questions.

À quoi sert un cahier des charges

Il sert d'abord à obtenir des devis comparables. Sans document commun, chaque prestataire imagine son propre projet : l'un chiffre un outil simple, l'autre un outil complet avec reprise de données et accès mobile. Les montants diffèrent alors pour de bonnes raisons, et vous ne pouvez pas le voir.

Il sert ensuite de référence pendant le projet. Quand une question se pose (« l'export vers la comptabilité était-il prévu ? »), on relit le document au lieu de se fier aux souvenirs d'une réunion. Annexé au contrat, il dit ce que le prix couvre et ce qu'il ne couvre pas.

Il sert enfin à la recette, c'est-à-dire à la vérification de ce qui est livré avant de payer. Chaque fonction décrite devient un point à tester. Un cahier des charges flou donne une recette floue, et des discussions sans fin sur ce qui était « évident ». La page sur la recette d'un logiciel avant paiement détaille cette étape.

Ce qu'il doit contenir

Pour un outil métier de PME, on retrouve presque toujours les mêmes rubriques. Leur ordre compte peu. L'essentiel est que chacune soit remplie, même d'une seule phrase.

  1. Le contexte. Votre activité, la taille de l'entreprise, la façon dont la tâche se fait aujourd'hui (papier, Excel, logiciel en place) et ce qui coince.
  2. L'objectif. Ce qui doit changer une fois l'outil en service, si possible mesurable : moins de ressaisies, un délai de traitement plus court, un document produit sans erreur.
  3. Les utilisateurs. Qui se sert de l'outil, combien de personnes, depuis où (bureau, chantier, téléphone), avec quels droits. Des clients ou des fournisseurs auront-ils un accès ?
  4. Les fonctions. Ce que chaque type d'utilisateur doit pouvoir faire, décrit en actions concrètes : créer une commande, valider un devis au-delà d'un montant fixé par la direction, envoyer un bon de livraison signé.
  5. Les règles de gestion. Les calculs, les validations, les statuts, les exceptions. C'est là que se cache l'essentiel du travail, bien plus que dans le nombre d'écrans.
  6. Les données. Ce qui existe déjà et devra être repris, d'où viennent les informations, combien d'années d'historique garder.
  7. Les liaisons avec d'autres logiciels. Comptabilité, CRM, banque, site internet, paie : lesquels, dans quel sens, à quelle fréquence.
  8. Les contraintes. Délai, budget envisagé, hébergement, sécurité, obligations légales.
  9. L'après-livraison. Qui corrige les anomalies, qui héberge, qui fait évoluer l'outil, et ce qui vous est remis (code source, accès, documentation).

Un budget indicatif a sa place dans le document. Beaucoup d'entreprises le cachent, de peur que le prestataire remplisse l'enveloppe. En pratique, un ordre de grandeur évite de recevoir des propositions sans rapport avec vos moyens, et permet au prestataire de dire ce qui tient dans la somme et ce qui doit attendre.

Ce qu'on oublie le plus souvent

Les rubriques absentes de la plupart des cahiers des charges sont aussi celles qui font déraper les devis et les délais.

La reprise des données

Des années de fichiers Excel, d'exports d'un ancien logiciel ou de tableaux partagés doivent être nettoyées, dédoublonnées et importées. C'est un chantier à part entière. Dites ce qui existe, sous quelle forme, et quelle partie de l'historique doit vraiment être reprise.

Les cas particuliers

Un processus décrit dans son cas normal tient en trois lignes. Les avoirs, les commandes livrées en plusieurs fois, les clients à deux adresses, les remplacements pendant les congés font la différence entre un outil utilisé et un outil contourné au bout d'un mois. Notez-les, même en vrac.

Les données personnelles

Dès que l'outil contient des informations sur des personnes (salariés, clients particuliers, candidats), le prestataire qui les héberge ou les traite pour vous est en général considéré comme sous-traitant au sens du RGPD. La CNIL recommande de ne pas commencer la prestation sans un contrat reprenant les exigences de l'article 28 du RGPD. Ce contrat prévoit notamment les obligations de sécurité, la notification des incidents, et les conditions de restitution et de destruction des données en fin de contrat.

Source : CNIL, Sécurité : gérer la sous-traitance, consulté le 22 octobre 2026.

Le guide sur le RGPD dans un logiciel métier sur mesure détaille ce que cela change pour le projet.

Les obligations qui arrivent

Si l'outil produit ou reçoit des factures, la réforme de la facturation électronique le concerne. L'obligation de recevoir des factures électroniques s'applique à toutes les entreprises depuis le 1er septembre 2026. L'obligation d'en émettre arrive le 1er septembre 2027 pour les PME et les micro-entreprises. Un cahier des charges écrit aujourd'hui doit dire comment l'outil s'articule avec ce nouveau circuit.

Source : Entreprendre.service-public.gouv.fr, Facturation électronique : c'est pour bientôt !, consulté le 22 octobre 2026.

Ce qu'il vaut mieux ne pas y mettre

Un cahier des charges trop directif coûte aussi cher qu'un document vide, parce qu'il empêche le prestataire de proposer plus simple.

  • Les choix techniques imposés sans raison. Exiger un langage ou un framework (l'ossature logicielle sur laquelle on construit) parce qu'on l'a lu quelque part ferme la porte à des solutions moins chères. Gardez les contraintes réelles : un serveur déjà en place, un logiciel avec lequel il faut dialoguer, un informaticien interne qui devra intervenir.
  • Les maquettes dessinées au pixel près. Un croquis à main levée ou la capture d'un écran que vous aimez suffit. Le dessin détaillé des écrans fait partie du travail du prestataire, et il se valide écran par écran.
  • Les fonctions « au cas où ». Ce que personne n'utilisera la première année coûte le même prix que le reste. Rangez ces idées dans une rubrique « plus tard » : elles restent visibles sans entrer dans le chiffrage.
  • Les qualités invérifiables. « Ergonomique », « intuitif », « performant » ne se testent pas. Écrivez à la place ce qui se constate : une commande se saisit en moins de deux minutes, l'écran reste lisible sur un téléphone de chantier.

Qui l'écrit, et avec qui

Vous l'écrivez vous-même. C'est souvent le meilleur choix pour un outil interne : personne ne connaît votre travail mieux que les personnes qui le font. Le document sera imparfait sur la forme, ce qui a peu d'importance. Commencez par l'expression des besoins : décrire les problèmes et les résultats attendus avant de parler de fonctions.

Un consultant l'écrit avec vous. Utile quand plusieurs services doivent se mettre d'accord, ou quand le projet touche à des obligations réglementaires. Vérifiez s'il vend lui-même le développement, et faites-le dire clairement si c'est le cas.

Le prestataire mène une phase de cadrage. Beaucoup de prestataires proposent un cadrage payant avant le devis ferme. Certains affichent un prix : un studio parisien annonce par exemple un cadrage à 995 € sur sa page publique. Le cadrage produit un document plus précis, mais il vous rattache à la vision d'un seul prestataire. Demandez que le livrable vous appartienne et puisse servir à consulter d'autres prestataires.

Source : Zetos, page de présentation de ses offres, prix affiché, consulté le 22 octobre 2026.

Quel que soit le rédacteur, faites relire le document par les personnes qui utiliseront l'outil. Elles repèrent en une lecture les cas particuliers que la direction ne voit plus.

Du cahier des charges au devis

Un bon cahier des charges se reconnaît aux devis qu'il produit : des montants plus proches les uns des autres, des postes qu'on retrouve d'une proposition à l'autre, moins de lignes « à préciser ». Quand les écarts restent grands, comparez ligne par ligne ce qui est compris et ce qui ne l'est pas. La page pour comparer des devis de développement donne la méthode.

C'est aussi le document à partir duquel je travaille. Si vous avez un cahier des charges et un devis d'agence, je repars des deux pour proposer un prix fixe découpé en étapes, chacune payée une fois livrée et validée. Mon objectif se situe entre la moitié et les trois quarts du devis reçu. Certains devis ne peuvent pas être battus, et je le dis. Les repères de prix du marché sont sur la page prix d'un logiciel métier sur mesure.

Avant d'envoyer votre document à un prestataire, vérifiez ces points :

  • Chaque type d'utilisateur et ses droits sont décrits.
  • Les règles de gestion et les cas particuliers sont listés, même sommairement.
  • Les données à reprendre sont identifiées, avec la profondeur d'historique voulue.
  • Les logiciels à relier sont nommés.
  • Les obligations légales (données personnelles, facturation) sont mentionnées.
  • L'après-livraison est prévu : hébergement, corrections, remise du code source et des accès.
  • Les idées « plus tard » sont séparées du périmètre à chiffrer.

? questions fréquentes

Ce qu'on me demande.

Une autre question ? Écrivez-moi à contact@2cafes.fr.

Un cahier des charges est-il obligatoire pour faire développer un logiciel ?

Vous pouvez lancer un développement à partir de quelques pages ou d'échanges par e-mail. Sans document écrit, vous ne pouvez toutefois ni comparer les devis ni vérifier précisément ce qui est livré.

Combien de pages doit faire un cahier des charges ?

Il n'y a pas de longueur idéale. Pour un outil interne de PME, quelques pages précises sur les utilisateurs, les règles de gestion, les données et les liaisons valent mieux qu'un long document générique.

Faut-il indiquer son budget dans le cahier des charges ?

Un ordre de grandeur suffit. Il évite des propositions hors de vos moyens et permet au prestataire de dire ce qui tient dans l'enveloppe et ce qui doit attendre une étape suivante.

Le cahier des charges peut-il changer pendant le projet ?

Oui, c'est fréquent. Chaque changement doit être écrit et chiffré avant d'être réalisé, pour que le prix fixe reste lisible et que la recette porte sur la bonne version.

~/devis vous avez déjà une proposition ?

Envoyez-moi le devis reçu.

Sous 48 heures ouvrées, je vous réponds avec un prix fixe pour le même travail, découpé en étapes que vous réglez une fois livrées et validées. Ou avec les questions qui me manquent. Si le devis est déjà bien placé, je vous le dis.