Avant de demander un devis pour une application, préparez le problème à résoudre, les utilisateurs concernés, deux ou trois parcours prioritaires, les règles métier, les données, les outils à connecter et les contraintes de lancement. Indiquez aussi ce qui reste inconnu. Vous n’avez pas besoin de choisir seul la technologie ni de dessiner chaque écran : le prestataire doit pouvoir proposer la solution et expliciter ses hypothèses.
Méthode préparée en septembre 2026. Les contraintes réglementaires et les choix techniques devront être vérifiés avant une éventuelle publication et tout lancement.
À quoi sert vraiment un cahier des charges d’application ?
Un cahier des charges d’application rend une demande chiffrable sans donner l’illusion que tout est déjà décidé. Il aligne le porteur de projet et le prestataire sur le résultat recherché, le périmètre et les questions encore ouvertes.
Si « gérer les réservations » peut désigner la simple création d’un créneau ou inclure le paiement, les annulations, les remboursements, les listes d’attente et un outil pour l’équipe, deux prestataires peuvent estimer des projets très différents.
Le cahier des charges doit réduire les interprétations sur les usages, pas imposer une réponse technique. Dans ses trames pour projets web, France Num recommande de préciser le contexte, les objectifs prioritaires, les fonctionnalités, les outils tiers, les livrables, le calendrier et une estimation du budget. Le même principe s’applique ici : le commanditaire n’a pas à choisir la technologie, mais doit signaler les outils à connecter (France Num).
Que faut-il décider avant de consulter un prestataire ?
Le porteur de projet doit maîtriser le « pourquoi » et le « pour qui ». Le prestataire peut ensuite conseiller le « comment ». Pour éviter de mélanger les deux, classez chaque information dans l’une de ces trois colonnes.
| Statut | Ce que cela signifie | Exemple dans une application de réservation |
|---|---|---|
| Décidé | Une contrainte ou une règle est déjà validée. | Le paiement est encaissé au moment de la réservation. |
| À proposer | Le résultat est clair, mais plusieurs solutions sont acceptables. | Le prestataire propose la meilleure façon d’informer le client d’un changement. |
| À vérifier | L’information manque et peut modifier le périmètre. | L’équipe doit confirmer si elle peut rembourser une réservation sans validation du dirigeant. |
Cette grille évite de garder une contrainte structurante dans la tête du dirigeant ou de transformer une préférence provisoire en exigence. « Il faut une application native » ne doit pas fermer une option web tant que l’usage ne l’impose pas.
Une inconnue n’empêche pas toujours de consulter. Si son impact peut être isolé, demandez une hypothèse ou des variantes. Si elle touche l’utilisateur principal, la règle métier centrale ou les données, travaillez-la avant un devis ferme.
Le modèle de brief à remplir avant un devis
Un brief utile peut tenir dans neuf blocs. La qualité des réponses compte davantage que le nombre de pages.
1. Le problème en une phrase
Décrivez la situation actuelle, la personne concernée et l’amélioration attendue. « Créer une application de réservation » est une solution. « Permettre aux adhérents de réserver sans appeler l’accueil et donner à l’équipe une vue fiable des places » décrit le problème et le résultat.
2. Les utilisateurs et leur contexte
Nommez les groupes qui utiliseront le produit : client, salarié, administrateur ou personne sans compte. Précisez le lieu, l’équipement et la fréquence. Un usage quotidien sur le terrain n’impose pas les mêmes choix qu’une opération mensuelle au bureau.
3. Le résultat attendu
Choisissez un résultat observable : diminuer les ressaisies, permettre une action ou fiabiliser une information. Notez comment vous constaterez l’usage : réservation terminée, dossier transmis, demande traitée ou temps passé relevé avant et après le lancement.
4. Les parcours prioritaires
Racontez deux ou trois scénarios de bout en bout : déclencheur, étapes, résultat et cas d’échec. Écrivez qui agit et ce qui doit être vrai à la fin. Une liste d’écrans ne dit pas comment les informations circulent ni qui décide.
5. Les règles métier et les exceptions
Documentez droits, délais, limites, validations et traitements particuliers. Les exceptions influencent souvent le chiffrage : que se passe-t-il si un paiement échoue, si deux personnes prennent la dernière place ou si un responsable modifie une opération confirmée ?
6. Les données et les intégrations
Listez les données saisies, importées, calculées et supprimées. Nommez les outils à connecter : gestion, paiement, messagerie, calendrier ou identité. Indiquez qui possède les accès et si une documentation existe.
La CNIL demande d’intégrer sécurité et protection des données dès la conception, puis de prévoir les tests adaptés avant mise à disposition (CNIL). Le brief doit signaler les catégories de données, les rôles qui y accèdent et les contraintes connues. Il ne remplace pas une analyse juridique si l’activité l’exige.
7. Le travail de l’équipe après le lancement
Décrivez ce que vos collaborateurs devront consulter, corriger, valider ou exporter. Un back-office peut nécessiter plusieurs rôles, des permissions et un historique des actions. Il appartient au périmètre au même titre que l’interface visible.
8. Les contraintes du projet
Donnez la date cible et sa raison, l’enveloppe ou le plafond, les appareils, les langues, l’accessibilité et les exigences de sécurité. Séparez une date souhaitée d’une échéance non négociable liée, par exemple, à la fin d’un outil existant.
9. La réponse attendue du prestataire
Demandez au prestataire de présenter périmètre, exclusions, hypothèses, variantes, livrables, validations et responsabilités après le lancement. Si l’estimation reste incertaine, demandez ce qui permettrait de la resserrer.
Exemple commenté : modifier une réservation déjà payée
Prenons un exemple fictif. Une entreprise veut lancer une application de réservation de cours. Un client choisit un créneau, paie en ligne et reçoit une confirmation. L’équipe doit ensuite pouvoir déplacer la réservation si l’intervenant est absent.
La phrase « l’administrateur peut modifier une réservation » ne suffit pas. Un brief exploitable préciserait :
| Question | Réponse du porteur de projet | Statut | Conséquence pour le devis |
|---|---|---|---|
| Qui peut déplacer la réservation ? | Le responsable de site, pas tous les intervenants. | Décidé | Prévoir des rôles et des droits distincts. |
| Le client doit-il accepter le nouveau créneau ? | Oui, dans un délai à définir. | À vérifier | Le prestataire chiffre une validation et demande la règle d’expiration. |
| Que devient le paiement si le prix change ? | Aucun changement de prix n’est autorisé lors d’un déplacement. | Décidé | Écarte un scénario de paiement plus complexe. |
| Comment prévenir le client ? | Une notification rapide est requise ; le canal peut être proposé. | À proposer | Le prestataire compare e-mail, SMS ou notification mobile et leurs coûts d’exploitation. |
| Que se passe-t-il sans réponse ? | La réservation reste sur le créneau initial pour le premier lancement. | Décidé | Évite d’ajouter tout de suite une logique de remboursement automatique. |
La décision importante n’est pas le dessin du bouton « déplacer ». Elle porte sur l’autorité de l’équipe, le consentement du client, l’effet sur le paiement et la trace conservée. Le prestataire peut alors concevoir les écrans sans inventer les règles de l’entreprise.
Reporter le remboursement automatique est acceptable si une procédure manuelle existe et si le volume reste gérable. Avec des centaines de modifications quotidiennes, cette décision créerait une charge et un risque d’erreur trop élevés.
Faut-il demander un devis ou cadrer d’abord le projet ?
Demandez un devis lorsque les utilisateurs, le parcours principal, les règles critiques et les intégrations sont identifiés. Les détails d’interface et le choix technique peuvent rester à proposer.
Demandez des variantes quand une décision reste ouverte : authentification simple ou connexion interne, e-mail ou SMS, reprise manuelle ou import automatisé. Chaque variante doit montrer son effet sur le périmètre et les coûts récurrents.
Cadrez d’abord si l’utilisateur prioritaire est inconnu, si les équipes décrivent des règles contradictoires ou si les données restent inaccessibles. Un prix ferme obligerait alors à majorer le risque ou à multiplier les réserves. Le cadrage doit produire des décisions, des parcours, des hypothèses et un périmètre consultable.
Quelles erreurs rendent un cahier des charges difficile à chiffrer ?
Empiler des fonctionnalités sans raconter les parcours
« Compte, paiement, notifications, espace administrateur » ne dit pas qui agit ni dans quel ordre. Ajoutez un scénario principal et un cas d’échec pour chaque opération sensible.
Tout présenter comme indispensable
Sans priorité, impossible de protéger l’objectif quand le budget ou le délai impose un arbitrage. Indiquez ce qui rend la première version utilisable et ce qui peut être manuel ou reporté.
Cacher le budget pour “voir les vrais prix”
Une enveloppe n’impose pas de la consommer. Elle permet de signaler un périmètre incompatible, de proposer des étapes ou d’écarter une approche trop coûteuse. Demandez en retour les hypothèses et exclusions.
Choisir une technologie pour rassurer le devis
Une technologie est une contrainte réelle si votre équipe maintient le produit ou si un système l’impose. Sinon, formulez vos besoins de distribution, de hors-ligne, de performance et d’intégration. Le prestataire doit justifier sa recommandation.
Une checklist avant d’envoyer votre demande
Votre document est prêt à être discuté si vous pouvez répondre « oui » aux questions suivantes :
- Le problème, l’utilisateur principal et le résultat attendu tiennent-ils dans trois phrases ?
- Deux ou trois parcours décrivent-ils une action complète, y compris un cas d’échec ?
- Les rôles internes et les opérations du back-office sont-ils visibles ?
- Les données personnelles, paiements et outils à connecter sont-ils signalés ?
- Les contraintes de date et de budget sont-elles distinguées des préférences ?
- Chaque inconnue importante est-elle classée « à proposer » ou « à vérifier » ?
- La réponse attendue du prestataire mentionne-t-elle hypothèses, exclusions et variantes ?
Si plusieurs réponses manquent, vous pouvez tout de même contacter un prestataire, mais demandez-lui explicitement une phase de clarification avant un engagement de réalisation. Klaapp accompagne ce travail dans ses missions de création de logiciels, d’applications mobiles et de sites web. Un premier échange peut servir à identifier les zones qui empêchent encore un chiffrage utile, y compris si la bonne prochaine étape consiste à simplifier le projet ou à choisir un outil existant.
Questions fréquentes
Combien de pages doit faire un cahier des charges d’application ?
Il n’existe pas de longueur universelle. Un document court suffit si parcours, règles, données, contraintes et inconnues sont explicites. Placez en annexe les maquettes, modèles de données ou documentations techniques.
Faut-il fournir des maquettes avant le devis ?
Des croquis peuvent rendre un parcours concret, mais une maquette ne remplace pas la règle métier et peut figer l’interface trop tôt. Si le prestataire doit concevoir l’UX et les interfaces, sa proposition doit l’inclure.
Peut-on protéger l’idée avant de transmettre le document ?
Vous pouvez limiter le premier brief aux informations nécessaires pour qualifier le projet, puis encadrer les détails sensibles. Pour un enjeu juridique ou de propriété intellectuelle, faites valider le dispositif par un professionnel compétent.
Le cahier des charges devient-il le contrat ?
Le rôle contractuel du cahier des charges dépend des documents signés. Vérifiez que le devis ou le contrat précise la hiérarchie des documents, le périmètre, les livrables, les changements et les responsabilités. Demandez un avis juridique si nécessaire.
Sources
- France Num — Modèles de cahiers des charges pour un site internet d’entreprise
- France Num — Bâtir le cahier des charges du site internet de son entreprise
- CNIL — Sécurité : encadrer les développements informatiques
Valentin Merault est cofondateur de Klaapp. Il intervient sur le cadrage, le produit, l’IHM et l’expérience utilisateur. Découvrir le studio Klaapp.