Cahier des charges d'une application : ce qui compte

Le cahier des charges a mauvaise réputation, et souvent à raison : un long document rédigé une fois, que personne ne relit, et qui décrit des fonctions plutôt que des besoins. Pourtant, c’est le document qui décide si trois devis se comparent, si le projet tient son budget, et si l’on sait dire, à la livraison, que c’est fini. Ce qui compte n’est pas sa longueur, mais ce qu’il permet de trancher.

À quoi sert un cahier des charges

Un cahier des charges n’est pas une formalité avant le vrai travail. Il rend trois services, qu’on mesure tout au long du projet.

• Comparer des devis. Trois prestataires qui lisent le même document chiffrent la même chose. Sans lui, chacun chiffre sa propre idée du projet, et l’écart de prix ne dit rien.
• Fixer le premier jour. Les dépassements viennent souvent de fonctions ajoutées en route. Un périmètre écrit permet de dire « oui, dans la version suivante », sans conflit.
• Savoir quand c’est fini. Des critères d’acceptation écrits (« un technicien enregistre une intervention avec trois photos en moins d’une minute ») transforment la livraison en vérification, plutôt qu’en débat.

Les sept éléments qui comptent

1. Qui s’en sert, et pour quoi faire

Les utilisateurs, nommés par rôle (le technicien, le client, la comptable), et pour chacun les deux ou trois gestes qu’il doit pouvoir faire. Un parcours décrit en une phrase (« le client dépose une pièce manquante depuis son téléphone et reçoit une confirmation ») vaut mieux qu’une liste de quarante fonctions.

2. Le premier jour, et ce qui attendra

La liste courte de ce que l’application fait au lancement, et la liste, plus longue, de ce qui viendra après. C’est la décision qui pèse le plus sur le prix d’une application.

3. Les données, et qui voit quoi

Quelles informations l’application garde, d’où elles viennent, et pour chaque rôle ce qu’il peut lire et modifier. C’est le socle de la sécurité d’une application, et c’est ce qui rend possible un portail client où chacun ne voit que ses dossiers.

4. Les logiciels à brancher

Le CRM, l’ERP, l’outil de facturation : pour chacun, ce qui circule dans quel sens, et s’il dispose d’une interface de programmation documentée. C’est souvent la ligne la plus incertaine d’un devis ; un bon cahier des charges permet au prestataire de le dire.

5. Les contraintes d’usage

Les conditions réelles : téléphones de l’entreprise ou personnels, réseau absent sur certains sites (voir l’application hors connexion), langues, notifications attendues (voir les notifications push), paiements (voir l’abonnement), fonctions d’IA (voir l’IA dans une application). Et le canal de diffusion : navigateur, stores, ou distribution privée, que compare PWA ou application native.

6. La propriété

Le code, la base de données, les comptes développeur, l’hébergement et le domaine à votre nom, et une cession des droits écrite. C’est ce qui évite d’avoir un jour à reprendre une application abandonnée par son prestataire, et ce qu’explique publier sous son propre compte développeur.

7. L’exploitation après le lancement

Qui surveille, qui corrige, sous quel délai, et le coût mensuel ligne par ligne : hébergement, base de données, e-mails, comptes des stores, mises à jour imposées. Le détail est dans le budget de maintenance d’une application.

Les obligations à écrire dès le début

Certaines exigences coûtent peu au départ et cher en rattrapage. Elles ont leur place dans le cahier des charges.

• La protection des données dès la conception. L’article 25 du RGPD demande de mettre en œuvre la protection des données au moment de concevoir le traitement, et de ne traiter par défaut que les données nécessaires à chaque finalité, selon le texte publié par la CNIL. Une donnée qu’on ne collecte pas n’a pas à être protégée.
• La suppression de compte. Les consignes de revue d’Apple sont claires : une application qui permet de créer un compte doit aussi permettre de le supprimer depuis l’application, selon la règle 5.1.1.
• L’accessibilité. Depuis le 28 juin 2025, la directive européenne sur l’accessibilité s’applique à certains services fournis aux particuliers, dont le commerce en ligne et la banque. Même quand elle ne vous vise pas, une application lisible par tous sert aussi vos utilisateurs pressés, en plein soleil ou d’une seule main.

Ce qui n’a pas sa place dans un cahier des charges

Imposer une technologie n’est pas interdit, quand une raison existe : vos équipes maintiennent déjà ce langage, votre service informatique impose un hébergement. Sans raison, mieux vaut décrire le résultat attendu et laisser le prestataire proposer, puis comparer les propositions. Si un outil sans développeur peut suffire, le cahier des charges le révélera aussi : c’est le sujet de low-code ou code.

Par où commencer

Écrivez d’abord, en une page, les utilisateurs et leurs gestes, puis le premier jour. Faites tester ces gestes sur une maquette cliquable avant de compléter le reste : la maquette fera tomber des fonctions inutiles et en révélera d’autres. Si vous hésitez encore entre développer et acheter, la grille de sur mesure ou outil du marché se remplit avec les mêmes informations. Pour une application de terrain, partez de ce qu’elle change pour vos équipes ; pour le back-end, de Supabase, Firebase ou serveur à soi. Et si l’idée est de tout générer avec une IA, le vibe coding dit ce qui reste à décider par des humains.

Notre développement d’applications commence par ce document : un cadrage écrit de ce que l’application fait le premier jour, et ce qui attendra.

Questions fréquentes

Sources

1. CNIL, RGPD, chapitre 4 (nouvel onglet)cnil.fr
2. Consignes de revue de l’App Store, Apple (nouvel onglet)developer.apple.com
3. Directive (UE) 2019/882, EUR-Lex (nouvel onglet)eur-lex.europa.eu