Rédiger un cahier des charges application mobile n'est pas réservé aux chefs de projet techniques. Pour une TPE, une PME ou un entrepreneur, c'est surtout un exercice de clarté : mettre noir sur blanc votre besoin pour que plusieurs prestataires puissent le comprendre de la même façon et le chiffrer sur la même base. Cet article donne un modèle prêt à coller dans votre éditeur de texte, avec des champs entre crochets à adapter. Il n'y a rien à télécharger : vous copiez le bloc ci-dessous et vous le complétez.
Modèle de cahier des charges application mobile à copier
Copiez le bloc suivant dans un document texte. Remplacez chaque élément entre crochets par vos informations. Si une rubrique ne s'applique pas, écrivez « non défini à ce stade » plutôt que de la supprimer : cela montre au prestataire où se situent les zones d'incertitude.
CAHIER DES CHARGES : [Nom du projet]
Version : [numéro] | Date : [jj/mm/aaaa] | Rédacteur : [nom et fonction]
1. Contexte et objectifs
- Présentation de l'activité : [décrire en 3 à 5 lignes votre entreprise ou projet]
- Problème à résoudre : [décrire la difficulté rencontrée par vos utilisateurs ou votre équipe]
- Objectif principal de l'application : [un seul objectif, formulé simplement]
- Objectifs secondaires : [maximum 2]
2. Utilisateurs cibles
- Profil principal : [qui, âge ou métier, niveau d'aisance avec le mobile]
- Profil secondaire (administrateur, livreur, employé, etc.) : [préciser]
- Contexte d'usage : [en déplacement, au bureau, en magasin, avec ou sans connexion]
3. Plateformes et appareils
- Systèmes visés : [iOS / Android / les deux]
- Versions minimales souhaitées : [si connues, sinon « à définir avec le prestataire »]
- Autres supports éventuels : [tablette, site web, back-office]
4. Fonctionnalités
- Indispensables au lancement : [liste]
- Utiles mais reportables : [liste]
- Souhaitées plus tard : [liste]
- Pour chaque fonctionnalité : [en tant que [profil], je veux [action] afin de [bénéfice]]
5. Parcours utilisateur et écrans
- Parcours principal : [étape 1 > étape 2 > étape 3]
- Liste des écrans attendus : [inscription, accueil, fiche, panier, profil, etc.]
- Références visuelles : [applications dont vous aimez l'ergonomie, sans copier]
- Charte graphique disponible : [oui / non, fournir logo et couleurs]
6. Contraintes techniques et réglementaires
- Connexions à des outils existants : [CRM, caisse, paiement, calendrier, ERP]
- Données personnelles collectées : [lesquelles, pourquoi]
- Authentification : [email, téléphone, compte tiers]
- Fonctionnement hors ligne : [oui / non / partiel]
- Notifications : [type et fréquence]
- Langues : [français, autres]
7. Budget, délais et organisation
- Enveloppe budgétaire : [montant ou fourchette, à indiquer honnêtement]
- Date souhaitée de mise en ligne : [date ou événement qui la justifie]
- Interlocuteur côté client : [nom, disponibilité]
- Modalités de validation : [qui valide quoi, sous quel délai]
8. Critères de réussite
- Indicateurs à suivre : [téléchargements, utilisateurs actifs, commandes, rendez-vous]
- Seuil considéré comme un succès à [durée] : [valeur]
9. Après la livraison
- Publication sur les stores : [qui crée les comptes développeur]
- Maintenance et évolutions : [souhaitées ou non]
- Propriété du code et des maquettes : [à préciser dans le contrat]
Comment utiliser et remplir chaque partie du modèle ?
Quand utiliser ce modèle
Ce modèle convient à un premier cadrage, avant de demander des devis à une agence ou à un développeur indépendant. Il est adapté à une application métier, une app de réservation, de fidélité, de catalogue ou de suivi, et à un MVP comme à une première version plus complète. Il est volontairement court : l'objectif est d'obtenir un document que vous et votre prestataire lirez réellement, pas un volume de spécifications techniques. Les détails fins (maquettes, règles de gestion précises) se construiront ensuite lors d'un atelier de cadrage.
Ce qu'il faut écrire dans chaque rubrique
Le tableau ci-dessous résume le niveau de détail attendu et l'erreur la plus courante pour chaque partie.
| Partie | À écrire | Erreur fréquente |
|---|---|---|
| Contexte et objectifs | Le problème réel et un objectif unique et mesurable | Décrire la solution au lieu du problème |
| Utilisateurs cibles | Qui utilise l'app, où et quand | Écrire « tout le monde » |
| Plateformes | iOS, Android ou les deux, avec la raison du choix | Exiger les deux sans en avoir besoin au départ |
| Fonctionnalités | Une liste hiérarchisée, formulée en actions | Tout classer comme indispensable |
| Parcours et écrans | Le chemin principal de l'utilisateur, étape par étape | Lister des écrans sans enchaînement |
| Contraintes | Intégrations, données personnelles, hors ligne | Découvrir une intégration en cours de projet |
| Budget et délais | Une enveloppe réaliste et une date justifiée | Cacher le budget pour « voir les prix » |
| Critères de réussite | Un indicateur et un seuil | Ne rien mesurer |
Trois conseils pour rédiger sans jargon
- Décrivez le besoin, pas la technique. Écrivez « le client peut réserver un créneau en moins d'une minute », pas « API REST avec base relationnelle ». Le choix des technologies revient au prestataire, sauf contrainte réelle de votre côté.
- Hiérarchisez toujours. Une méthode simple consiste à classer chaque fonctionnalité en « indispensable », « utile » ou « plus tard ». Ce classement est ce qui permet de construire un MVP sans exploser le budget.
- Faites relire par un utilisateur final. Un client ou un collaborateur concerné repère en dix minutes les étapes oubliées du parcours.
Une fois votre document rédigé, vous pouvez le soumettre à un service de développement d’application mobile pour obtenir un avis sur la faisabilité et un chiffrage fondé sur des éléments précis. Plus le document est net, plus les devis reçus seront comparables entre eux.
Exemple fictif de cahier des charges pour une application mobile
Voici une version complétée du modèle, à titre d'illustration. L'entreprise, les chiffres et les choix sont inventés pour l'exemple : adaptez-les à votre situation, ne les reprenez pas tels quels.
CAHIER DES CHARGES : Application de commande en click and collect, « Boulangerie Exemple » (cas fictif)
1. Contexte et objectifs
- Activité : boulangerie artisanale de quartier avec deux points de vente.
- Problème : files d'attente le matin et commandes spéciales prises par téléphone, avec des oublis.
- Objectif principal : permettre aux clients de commander et de choisir un créneau de retrait depuis leur téléphone.
- Objectif secondaire : fidéliser avec un suivi simple des commandes passées.
2. Utilisateurs cibles
- Clients réguliers, de 25 à 60 ans, utilisant leur téléphone en mobilité.
- Équipe en boutique, qui consulte les commandes du jour sur une tablette.
3. Plateformes
- iOS et Android, car la clientèle est mixte.
- Une interface simple de gestion des commandes pour la boutique.
4. Fonctionnalités
- Indispensables : création de compte, catalogue des produits, panier, choix du créneau de retrait, paiement en ligne, notification « commande prête ».
- Utiles : historique et recommande en un geste.
- Plus tard : programme de fidélité, précommandes pour les fêtes.
5. Parcours principal
- Ouverture de l'app > choix du magasin > sélection des produits > choix du créneau > paiement > confirmation.
6. Contraintes
- Connexion au logiciel de caisse existant : à étudier avec le prestataire.
- Données collectées : nom, email, historique de commandes, avec recueil du consentement.
- Pas de fonctionnement hors ligne nécessaire.
7. Budget et délais
- Enveloppe fixe validée en interne avant les demandes de devis.
- Mise en ligne visée avant une période de forte activité, date confirmée après chiffrage.
- Un seul interlocuteur côté boulangerie, qui valide sous quelques jours ouvrés.
8. Critères de réussite
- Part des commandes passées via l'app : 20 % des ventes du matin après trois mois.
9. Après la livraison
- Comptes développeur créés au nom de la boulangerie.
- Propriété du code et des maquettes cédée au client dans le contrat.
Ce que cet exemple illustre
Remarquez que l'objectif tient en une phrase, que la liste des fonctionnalités est hiérarchisée et que le seul indicateur de réussite est mesurable. L'intégration à la caisse est signalée comme inconnue plutôt que passée sous silence : c'est précisément le genre de point qu'un prestataire sérieux voudra creuser avant de s'engager sur un prix.
Les points à préciser pour cadrer un MVP iOS et Android
Un MVP (version minimale viable) vise à tester une hypothèse auprès de vrais utilisateurs avec le moins de fonctionnalités possible. Son cahier des charges doit donc être plus restrictif que celui d'une application complète. Voici les points qui font le plus souvent la différence.
Définir le cœur de valeur et couper le reste
Posez-vous une question : quelle est l'unique action qui prouve que l'application sert à quelque chose ? Dans l'exemple de la boulangerie, c'est passer commande et retirer sans attendre. Tout ce qui ne contribue pas directement à cette action (fidélité, avis, partage social) peut attendre la deuxième version. Un MVP réussi se reconnaît à ce qu'il laisse volontairement de côté.
Choisir iOS, Android ou les deux dès le départ
Le choix des plateformes dépend de votre public, pas de vos préférences personnelles. Observez les appareils de vos clients actuels (statistiques de votre site, de votre newsletter, enquête rapide). Une approche multiplateforme permet souvent de couvrir iOS et Android avec une base de code commune, tandis qu'une approche native offre un accès plus fin aux fonctions de l'appareil. Indiquez dans votre document ce qui compte pour vous (rapidité de mise en ligne, budget, performances, usage de l'appareil photo ou de la géolocalisation) et laissez le prestataire justifier sa recommandation.
| Critère à préciser | Question à vous poser | Impact sur le projet |
|---|---|---|
| Plateformes | Mes utilisateurs sont-ils plutôt sur iOS, Android ou répartis ? | Périmètre de développement et de tests |
| Fonctions de l'appareil | Ai-je besoin de la caméra, de la localisation, du Bluetooth ? | Choix de la technologie |
| Données et comptes | Les utilisateurs doivent-ils se connecter ? | Sécurité, RGPD, hébergement |
| Paiement | Vends-je un produit physique, un service ou un contenu numérique ? | Règles des stores et solution de paiement |
| Back-office | Qui gère les contenus et les commandes au quotidien ? | Interface d'administration à prévoir |
Anticiper la publication sur les stores
Publier sur l'App Store et Google Play suppose des comptes développeur, des fiches de présentation, des visuels et le respect des règles de chaque magasin, notamment sur les paiements et la protection des données. Ces étapes demandent du temps et leur validation n'est pas entièrement maîtrisable. Mentionnez dans votre cahier des charges qui crée les comptes (idéalement vous, afin que l'application reste votre propriété), qui rédige les textes et qui gère les mises à jour.
Prévoir la mesure, la maintenance et la suite
- Mesure : décidez dès le départ de ce que vous suivrez (inscriptions, commandes, rétention) afin que l'outil d'analyse soit intégré dès la première version.
- Retours utilisateurs : prévoyez un moyen simple de les recueillir, par exemple un formulaire dans l'app ou un entretien avec vos dix premiers utilisateurs.
- Maintenance : les systèmes iOS et Android évoluent régulièrement. Précisez si vous souhaitez un suivi après la livraison et sous quelle forme.
- Propriété et documentation : demandez la remise du code source, des maquettes et d'une documentation de base pour ne pas dépendre d'un seul prestataire.
Les erreurs à éviter avant d'envoyer le document
- Lister trop de fonctionnalités « indispensables » et vider le mot de son sens.
- Oublier les profils secondaires, comme l'administrateur ou le livreur, qui génèrent souvent des écrans entiers.
- Ne pas indiquer de budget, ce qui conduit à des devis très éloignés et difficiles à comparer.
- Confondre cahier des charges et maquette : le premier explique le besoin, la seconde le met en forme.
- Ne pas relire le document avec une personne extérieure au projet.
Un bon cahier des charges application mobile n'a pas besoin d'être exhaustif. Il doit être honnête sur ce que vous savez et sur ce que vous ignorez, hiérarchisé et assez précis pour permettre un chiffrage sérieux. Utilisez le modèle, complétez-le en une session de travail, faites-le relire, puis affinez-le avec le prestataire lors de l'atelier de cadrage.
FAQ
Un cahier des charges est-il indispensable pour demander un devis d’application mobile ?
Non, il n’est pas toujours obligatoire, mais il aide les prestataires à comprendre le périmètre du projet et à chiffrer une réponse comparable. Sans besoins décrits, les devis risquent de reposer sur des hypothèses différentes. Vous pouvez commencer par un document synthétique présentant les utilisateurs, les objectifs, les fonctionnalités attendues et les contraintes connues, puis le compléter avec le prestataire.
Comment décrire les fonctionnalités pour obtenir une estimation plus fiable ?
Décrivez chaque fonctionnalité du point de vue de l’utilisateur, en précisant son objectif, les étapes principales et le résultat attendu. Ajoutez des critères qui permettent de vérifier son bon fonctionnement, par exemple les informations à afficher ou les règles à appliquer. Distinguez les besoins essentiels des options souhaitables. Cette précision réduit les interprétations différentes sans vous obliger à définir à l’avance la solution technique.
Faut-il choisir les technologies avant de demander un devis ?
Pas nécessairement. Si vous n’avez pas de contrainte technique établie, décrivez plutôt les usages, les appareils visés, les services à connecter et les exigences de sécurité ou de performance. Le prestataire pourra proposer une approche adaptée et en expliquer les conséquences. En revanche, indiquez toute technologie déjà imposée par votre organisation ou par un système existant, car elle peut influencer la conception et l’estimation.
Peut-on réunir les besoins web et mobile dans un même cahier des charges ?
Oui, un document commun peut présenter la vision d’ensemble du produit et les parcours partagés. Séparez toutefois les exigences propres à chaque support, comme les fonctionnalités réservées à l’application, les usages sur navigateur ou les besoins d’administration. Précisez aussi quelles données et quels comptes doivent être communs. Cette organisation aide à repérer les dépendances sans confondre le périmètre web et celui de l’application mobile.
Quelles informations prévoir sur les données personnelles et la sécurité ?
Indiquez quelles données l’application collecte, pourquoi elles sont nécessaires, qui peut les consulter et avec quels services elles sont partagées. Signalez les exigences internes ou réglementaires que votre organisation doit respecter, ainsi que les besoins de connexion, de gestion des accès et de suppression des comptes ou données. Le cahier des charges sert à rendre ces sujets visibles, mais ne remplace pas une analyse juridique ou de sécurité adaptée au projet.
À qui appartiennent le code source et les éléments créés pour l’application ?
La propriété et les conditions de remise du code source, des maquettes, de la documentation et des autres livrables doivent être clarifiées dans le contrat avec le prestataire. Le cahier des charges peut signaler ces attentes et préciser les éléments nécessaires à la reprise ou à la maintenance du projet. Vérifiez également les conditions applicables aux composants tiers, qui peuvent relever de licences distinctes.
Conseils en développement d'application mobile | Ship Studio
Obtenez une recommandation adaptee a votre contexte autour de ce sujet.
Demander un avis expert