« Je dirige une entreprise de location de matériel pour les événements, avec 12 salariés. On veut une application pour que nos clients réservent en ligne et que nos livreurs voient leurs tournées sur leur téléphone. Les prestataires nous demandent un cahier des charges, mais on n'en a jamais écrit : qu'est-ce qu'on met dedans ? »
La situation, telle qu'on la raconte à une IA
Un cahier des charges décrit votre besoin, pas la solution technique : le contexte et l'objectif, les utilisateurs, ce que chacun doit pouvoir faire, ce qui n'est pas prévu, les données et les outils à connecter, les contraintes (données personnelles, règles des stores, accessibilité), le budget, le calendrier et la façon dont vous vérifierez le résultat. Aucune loi n'impose de modèle pour un projet privé. Un document clair, avec des priorités, suffit pour recevoir des devis comparables.
À quoi sert un cahier des charges ?
Il sert à trois choses : obtenir des devis qui chiffrent la même chose, éviter les malentendus pendant le développement, et vérifier à la livraison que ce qui était prévu a été fait. C'est aussi la référence quand une demande nouvelle apparaît en cours de route.
Pour un projet privé, la forme est libre. Il existe toutefois une norme, NF EN 16271, publiée par AFNOR en février 2013, qui décrit l'expression fonctionnelle du besoin et le cahier des charges fonctionnel ; elle a remplacé l'ancienne norme NF X50-151¹. Son principe reste utile même sans la suivre à la lettre : décrire ce que le produit doit permettre, pas comment le construire.
Les rubriques d'un cahier des charges d'application
| Rubrique | Ce que vous y écrivez | Exemple |
|---|---|---|
| 1. Le contexte | Votre activité, la situation actuelle, ce qui ne va pas | « Les réservations arrivent par téléphone et sont recopiées dans un tableur. » |
| 2. L'objectif | Ce qui doit changer, si possible de façon mesurable | « Que les clients réservent sans appeler. » |
| 3. Les utilisateurs | Qui utilisera l'application, et sur quel appareil | Clients sur téléphone et ordinateur, livreurs sur téléphone, équipe au bureau |
| 4. Les fonctions | Ce que chaque utilisateur doit pouvoir faire, par ordre de priorité | « Le livreur voit ses livraisons du jour dans l'ordre de la tournée. » |
| 5. Le hors périmètre | Ce que l'application ne fera pas, au moins au début | « Pas de paiement en ligne dans la première version. » |
| 6. Les données | Ce que l'application enregistre, et ce qu'il faut reprendre de l'existant | Fichier clients, catalogue du matériel, historique des locations |
| 7. Les connexions | Les outils déjà en place à relier | Logiciel de facturation, agenda, site internet |
| 8. Les contraintes | Données personnelles, stores, accessibilité, hébergement, volumes | Voir la partie suivante |
| 9. Le budget et le calendrier | Une fourchette, une date souhaitée, et pourquoi | « En service avant la saison des mariages. » |
| 10. La réception et la suite | Comment vous vérifierez le travail, et ce que vous attendez après | Tests sur vos cas réels, maintenance, propriété du code |
Comment décrire les fonctions sans être technicien ?
Décrivez des situations, pas des écrans. Une formule simple : « En tant que [utilisateur], je veux [action] pour [raison]. » Par exemple : « En tant que livreur, je veux voir le téléphone du client pour le prévenir de mon arrivée. » Les équipes de développement appellent cela des « récits utilisateur » (user stories).
Classez ensuite chaque fonction : indispensable pour la première version, utile, ou pour plus tard. Ce classement permet au prestataire de proposer une première version à un prix raisonnable, puis d'ajouter le reste selon l'usage réel.
Joignez ce que vous avez déjà : tableurs, formulaires papier, bons de livraison, captures d'outils que vous aimez. Ces exemples en disent souvent plus qu'une longue description.
Les contraintes qu'on oublie souvent
- Les données personnelles : la CNIL recommande d'intégrer la protection des données dès la conception de l'application, et une analyse d'impact est obligatoire pour certains traitements². Indiquez quelles données seront collectées, qui y aura accès et combien de temps elles seront gardées.
- Les données de santé : si l'application conserve des données de santé recueillies lors de soins, de prévention ou d'un suivi social et médico-social, pour le compte d'autres personnes, leur hébergeur doit être certifié³. C'est ce qu'on appelle la certification HDS.
- Les règles des stores : si l'on peut créer un compte dans l'application, Apple exige qu'on puisse aussi le supprimer depuis l'application, et chaque application doit donner accès à sa politique de confidentialité⁴. Google Play demande lui aussi un moyen de supprimer son compte dans l'application, et un lien web pour en faire la demande⁵.
- L'accessibilité : depuis le 28 juin 2025, certains services numériques, dont le commerce en ligne, doivent être accessibles aux personnes handicapées. Une entreprise de moins de 10 salariés dont le chiffre d'affaires annuel ou le total de bilan est inférieur à 2 millions d'euros peut invoquer une exemption⁶. Même sans obligation, il est plus simple de le prévoir dès le départ que de corriger après coup.
- L'hébergement : où les données seront stockées (en Europe, par exemple) et au nom de qui le compte sera ouvert.
- Les volumes : nombre d'utilisateurs, de réservations par jour, de photos ou de documents. Ce sont eux qui dimensionnent le serveur.
Ce qu'il vaut mieux ne pas y mettre
- Une technologie imposée sans raison : laissez le prestataire proposer, et demandez-lui de justifier son choix, notamment pour la maintenance.
- Une liste de souhaits sans priorités : tout devient indispensable, et le devis s'envole.
- Des maquettes présentées comme définitives : des croquis aident, mais la conception des écrans est un travail à part entière.
- Des mots vagues sans exemple, comme « simple », « intuitif » ou « rapide » : personne ne peut les chiffrer ni les vérifier.
Budget, calendrier, réception : la partie qu'on saute
Donner une fourchette de budget n'est pas se dévoiler : cela permet au prestataire de proposer ce qui tient dans votre enveloppe, plutôt qu'un projet idéal hors de portée. Pour un premier repère, voyez notre article sur le coût d'une application sur mesure.
Prévoyez aussi la réception, qu'on appelle « recette » : quels cas réels vous testerez avant d'accepter la livraison, combien de temps vous aurez pour signaler les défauts, et qui les corrige. Ajoutez ce que vous attendez ensuite : maintenance, cession écrite des droits sur le code, comptes des stores et hébergement à votre nom.
Qui écrit le cahier des charges ?
Vous, d'abord : personne ne connaît mieux votre activité. Si personne dans l'équipe n'a l'habitude des projets informatiques, un consultant indépendant ou un directeur technique à temps partagé peut transformer vos besoins en document chiffrable. Certains prestataires proposent aussi une phase de cadrage payante avant le développement : vérifiez alors que le document produit vous appartient et peut être envoyé à d'autres prestataires.
Ce qui dépend de votre cas
Plus le projet est grand ou sensible (données de santé, paiement, nombreux utilisateurs), plus le cahier des charges doit être précis. Pour le contrat qui l'accompagne, en particulier la responsabilité et la propriété du code, un avocat reste le bon interlocuteur.
Et chez Prestalgo ?
Pas besoin d'un cahier des charges pour nous contacter : décrivez vos utilisateurs et ce qu'ils doivent pouvoir faire. Le prix est fixé dans une proposition écrite, après un échange sur votre besoin et avant le début du travail ; une application se chiffre à partir de 2 999 € HT. Si vous voulez un cahier des charges à soumettre à plusieurs prestataires, notre direction technique à temps partagé le rédige avec vous, à 100 € HT de l'heure. Voir aussi développement d'application et Tarifs.
Questions fréquentes
Existe-t-il un modèle de cahier des charges gratuit ?
Oui, de nombreux modèles circulent en ligne. Servez-vous-en comme d'une liste de rubriques, pas comme d'un formulaire à remplir mot à mot : une rubrique recopiée d'un autre projet crée plus de confusion qu'elle n'en évite.
Quelle différence entre cahier des charges fonctionnel et technique ?
Le cahier des charges fonctionnel décrit ce que l'application doit permettre : c'est celui que vous écrivez. Le cahier des charges technique, ou spécifications techniques, décrit comment la construire : technologies, architecture, hébergement. Il est en général rédigé par le prestataire, à partir du vôtre.
Combien de pages doit faire un cahier des charges ?
Il n'y a pas de bonne longueur. Pour une première application, un document court et précis vaut mieux qu'un long texte vague : l'essentiel est que chaque fonction soit décrite, classée par priorité et vérifiable à la livraison.
Faut-il un accord de confidentialité avant d'envoyer le cahier des charges ?
C'est utile si le projet contient une idée nouvelle ou des informations sensibles sur votre entreprise. Dans tous les cas, n'y mettez pas de données réelles de clients : des exemples fictifs suffisent pour décrire le besoin.
Le prestataire peut-il facturer ce qui n'était pas prévu ?
Oui, une demande nouvelle peut faire l'objet d'un devis complémentaire. C'est justement pour cela que le cahier des charges doit être précis : il permet de distinguer ce qui était prévu au départ de ce qui ne l'était pas.
Sources
- AFNOR, norme NF EN 16271, « Management par la valeur - Expression fonctionnelle du besoin et cahier des charges fonctionnel », février 2013, fiche de la boutique AFNOR consultée le 8 novembre 2026 : boutique.afnor.org
- CNIL, « Préparer son développement », guide RGPD de l'équipe de développement, 27 janvier 2020, consulté le 8 novembre 2026 : cnil.fr
- Code de la santé publique, article L1111-8, Légifrance, consulté le 8 novembre 2026 : legifrance.gouv.fr
- Apple, « App Review Guidelines », règle 5.1.1, consulté le 8 novembre 2026 : developer.apple.com
- Google, « Comprendre les exigences de Google Play concernant la suppression de comptes d'application », aide Play Console, consulté le 8 novembre 2026 : support.google.com
- Entreprendre.Service-Public.fr (Direction de l'information légale et administrative), « Directive “Accessibilité” : possibilité de demander une exemption en ligne », 27 novembre 2025, consulté le 8 novembre 2026 : entreprendre.service-public.gouv.fr
Alexandre Gougeon, fondateur de Prestalgo, développeur full stack depuis 2015. Prestalgo fait tourner et maintient les applications de SAUVLife, Youngs Job et Groume.