Vous avez une idée d'application pour votre entreprise et vous voulez demander des devis. Le premier réflexe est souvent de chercher un modèle de cahier des charges de quarante pages. Pour une petite entreprise, c'est rarement utile : personne ne le lira en entier, et il fige des choix qu'on ferait mieux de tester sur une maquette.
Ce qu'il vous faut, c'est un document court qui répond aux bonnes questions. Voici le modèle que je recommande, en dix rubriques, puis un exemple rempli pour une application de suivi d'interventions. Si votre projet consiste surtout à remplacer un tableur, lisez aussi remplacer Excel par une application sur mesure : le fichier existant fait souvent la moitié du travail.
À quoi sert un cahier des charges d'application mobile ?
Il a trois usages, et seulement trois :
- Obtenir des devis comparables. Sans document commun, chaque prestataire imagine une application différente, et les prix ne veulent plus rien dire.
- Se mettre d'accord en interne. Le gérant, le responsable terrain et la personne qui fait l'administratif n'ont pas la même idée de l'application. Les écrire côte à côte révèle les désaccords avant le développement.
- Fixer la première version. Le document sépare ce qui est indispensable au lancement de ce qui peut attendre. C'est la décision qui pèse le plus sur le coût et le délai.
Cinq à dix pages suffisent. Des phrases simples, des listes, un ou deux schémas d'écrans à main levée valent mieux qu'un vocabulaire technique.
Que doit contenir un cahier des charges d'application mobile ?
Voici les dix rubriques à remplir. Copiez-les dans un document et répondez à chaque question en quelques lignes.
- 01
Le contexte
Votre entreprise en trois lignes, le problème actuel, comment il est géré aujourd'hui (papier, tableur, logiciel) et ce que cela coûte en temps ou en erreurs.
- 02
L'objectif
Une phrase vérifiable : « supprimer la ressaisie des fiches d'intervention » plutôt que « moderniser notre gestion ».
- 03
Les utilisateurs et leurs rôles
Qui utilise l'application, combien de personnes, à quelle fréquence, et ce que chacun doit pouvoir voir ou modifier.
- 04
Les parcours principaux
Deux ou trois scénarios racontés étape par étape : « le technicien ouvre l'app, voit sa journée, arrive chez le client… ».
- 05
Les fonctionnalités, classées
Une liste avec trois niveaux : indispensable à la première version, utile, plus tard.
- 06
Les écrans
La liste des écrans principaux, idéalement avec un croquis. Pas besoin de design : un rectangle et des mots suffisent.
- 07
Les données
Ce que l'application enregistre (clients, interventions, photos, signatures), qui en est responsable, et les données existantes à reprendre.
- 08
Les connexions
Les outils avec lesquels l'application doit échanger : logiciel de facturation, agenda, CRM. Notez le nom exact de chaque outil, pour vérifier qu'il propose une API.
- 09
Les contraintes
iPhone, Android ou les deux, usage sans réseau, appareil photo, notifications, données personnelles, et publication sur les stores avec des comptes développeur au nom de votre entreprise.
- 10
Le cadre
Le budget ou la fourchette envisagée, la date souhaitée et pourquoi, qui teste les versions de votre côté, et ce que vous attendez après la livraison (maintenance, évolutions).
La rubrique 09 est souvent oubliée, et c'est elle qui crée les mauvaises surprises. Publier sur l'App Store et Google Play demande des comptes développeur payants et, pour une entreprise, un numéro D-U-N-S : je détaille ces frais dans combien coûte une application mobile en 2026.
À quoi ressemble un cahier des charges rempli ?
Exemple fictif. L'entreprise ci-dessous n'existe pas. Elle sert à montrer le niveau de détail attendu, rubrique par rubrique. Remplacez chaque réponse par la vôtre.
Contexte et objectif
Entreprise de maintenance de chaudières, huit techniciens, environ quarante interventions par semaine chez des particuliers et des syndics. Aujourd'hui : planning dans un tableur, fiches d'intervention sur papier, ressaisies le soir par l'assistante, rapports envoyés au client sous plusieurs jours. Objectif : que le rapport d'intervention parte au client le jour même, sans ressaisie.
Utilisateurs et rôles
- Techniciens (8) : voient leurs interventions du jour, remplissent la fiche, prennent des photos, font signer le client. Ne voient pas les tarifs.
- Assistante (1) : crée et répartit les interventions, suit les statuts, envoie les rapports, prépare la facturation.
- Gérant (1) : voit tout, y compris l'activité par technicien.
Parcours principal
Le technicien ouvre l'application le matin et voit ses interventions dans l'ordre. Sur place, il ouvre la fiche, coche les contrôles effectués, ajoute deux ou trois photos, note les pièces remplacées et fait signer le client sur l'écran. Il valide : le rapport PDF part au client par e-mail, et l'intervention passe en « à facturer » côté bureau. Sans réseau dans une cave, la fiche s'enregistre et part dès le retour du réseau.
Fonctionnalités classées
| Fonctionnalité | Priorité | Pourquoi |
|---|---|---|
| Liste des interventions du jour | Indispensable | Point d'entrée du technicien |
| Fiche d'intervention, photos, signature | Indispensable | C'est l'objectif de l'application |
| Rapport PDF envoyé au client | Indispensable | Supprime l'envoi manuel |
| Fonctionnement sans réseau | Indispensable | Caves et chaufferies sans signal |
| Écran bureau : création et répartition | Indispensable | Remplace le tableur de planning |
| Export vers le logiciel de facturation | Utile | Un export simple suffit au départ |
| Rappel au client la veille | Utile | Moins de rendez-vous manqués |
| Statistiques par technicien | Plus tard | Utile au gérant, pas au quotidien |
| Espace client pour les syndics | Plus tard | À décider après six mois d'usage |
Données, connexions et contraintes
- Données : clients et adresses, équipements (marque, modèle, date de pose), interventions, photos, signatures. Reprise de la liste clients depuis le tableur actuel.
- Connexions : export des interventions « à facturer » vers le logiciel de facturation (nom exact à préciser, API à vérifier).
- Contraintes : téléphones Android et iPhone (les techniciens utilisent leur propre téléphone), mode hors ligne, appareil photo, données personnelles des clients accessibles aux seuls techniciens concernés, comptes développeur au nom de l'entreprise.
Cadre
Première version souhaitée avant la saison de chauffe. Testeur désigné : le technicien le plus ancien, avec l'assistante. Après la livraison : maintenance mensuelle et une évolution par trimestre.
Comment prioriser les fonctionnalités de la première version ?
Pour chaque fonctionnalité, posez une seule question : si on l'enlève, l'application atteint-elle encore son objectif ? Si oui, elle n'est pas indispensable. Dans l'exemple, les statistiques sont intéressantes, mais sans elles le rapport part quand même le jour même.
Deux autres repères aident à trancher :
- La fréquence d'usage. Une fonction utilisée quarante fois par semaine passe avant une fonction utilisée une fois par mois.
- Le coût d'attendre. Si une fonction peut être faite à la main pendant quelques mois sans gêne réelle, elle peut attendre la version suivante.
Une première version réduite, utilisée tous les jours, vous apprendra plus que n'importe quel cahier des charges. C'est pour cela que je construis les applications en sprints de 2 semaines, avec une version à tester sur votre téléphone à la fin de chacun : c'est la méthode que je décris sur ma page création d'application mobile.
Quelles erreurs éviter dans un cahier des charges ?
- Décrire des solutions au lieu de besoins. « Un menu déroulant à gauche » ferme des options. « Le technicien doit retrouver un client en moins de trois gestes » en ouvre.
- Copier l'application d'un grand groupe. Ses fonctions ont été construites par des équipes entières, sur des années. Gardez l'idée, pas la liste.
- Oublier le côté bureau. Une application terrain a presque toujours besoin d'un écran pour celui qui organise. Il compte autant dans le devis.
- Ne pas nommer de testeur. Sans personne pour essayer chaque version avec de vrais cas, les problèmes arrivent après la mise en ligne.
- Taire le budget. Une fourchette, même large, permet au prestataire de proposer la meilleure première version possible dans ce cadre.
Quand peut-on se passer d'un cahier des charges ?
Le document écrit n'est pas toujours la meilleure porte d'entrée. Pour une petite application, une conversation et une maquette font souvent mieux : on voit les écrans, on les corrige, et le périmètre se fixe sur quelque chose de concret. C'est ainsi que je travaille : un échange gratuit de 30 min, puis une maquette offerte construite sur votre cas, présentée lors d'un deuxième rendez-vous, et un devis au forfait à la fin de cette démo.
Le cahier des charges reste utile si vous consultez plusieurs prestataires, si plusieurs personnes doivent valider le projet, ou si un financement demande un document écrit. Et dans tous les cas, se poser les dix questions du modèle avant le premier rendez-vous vous fera gagner du temps.
Vous avez une idée d'application et quelques notes ? Réservez un échange de 30 min, on regarde ensemble ce qui doit entrer dans la première version.
Sources consultées le 17 octobre 2026
- Apple Developer, inscription au programme (numéro D-U-N-S pour les organisations)
- Aide Google Play Console, numéro D-U-N-S pour les comptes d'organisation
Questions fréquentes
Comment rédiger le cahier des charges d'une application mobile ?
Répondez en quelques lignes à dix rubriques : contexte, objectif, utilisateurs, parcours, fonctionnalités classées, écrans, données, connexions, contraintes et cadre (budget, délai, testeur). Cinq à dix pages suffisent pour une petite entreprise.
Quelle est la différence entre un cahier des charges d'application mobile et d'application web ?
La structure est la même. L'application mobile ajoute des contraintes propres : iPhone et Android, fonctionnement sans réseau, notifications, appareil photo et publication sur l'App Store et Google Play avec des comptes développeur.
Faut-il un cahier des charges pour demander un devis d'application ?
Pas obligatoirement. Il est utile pour comparer plusieurs prestataires. Pour une petite application, un échange et une maquette des écrans peuvent remplacer un long document et fixer le périmètre sur du concret.
Combien de pages doit faire un cahier des charges d'application ?
Pour une petite entreprise, cinq à dix pages. L'important est que chaque fonctionnalité soit classée par priorité et que la première version soit clairement délimitée.
Qui doit rédiger le cahier des charges ?
L'entreprise qui commande l'application, avec les personnes qui l'utiliseront. Le prestataire peut ensuite le compléter, notamment sur les connexions techniques et les contraintes de publication.