Un cahier des charges d'application mobile permet de faire chiffrer le même périmètre par deux prestataires, avant de choisir l'un d'eux. Il se rédige en vue d'une application mobile sur mesure, pour iOS et Android, ou d'un logiciel sur mesure quand l'outil vit dans un navigateur. Ce modèle dit, section par section, ce que le prestataire doit lire pour chiffrer, et l'erreur qui renvoie le document.
JAIKIN, agence IA, Odoo et logiciels sur mesure pour PME et ETI, reçoit ces documents de l'autre côté de la table. Ceux qui se chiffrent du premier coup décrivent un parcours et ses exceptions ; ceux qui reviennent listent des écrans. Pour un ERP, le même exercice a son propre modèle de cahier des charges ERP.
Que doit contenir le cahier des charges d'une application mobile ?
Neuf sections, dans cet ordre. Le contexte dit pourquoi l'application existe et qui la paie. Les utilisateurs nomment les rôles. Le parcours clé raconte la tâche du début à la fin. Les écrans et fonctions se rangent en deux colonnes : indispensable, puis ensuite. Les données disent où elles vivent. Les intégrations nomment les outils à relier. Les contraintes posent le non négociable. La publication dit à quel nom vivront les comptes des stores. Le budget et la recette rattachent chaque lot à un critère d'acceptation.
Un prestataire lit ces sections pour chiffrer, pas pour découvrir le métier en réunion. Si une section l'oblige à deviner, le devis devient une fourchette large, ou un avenant. Le tableau qui suit est la grille de relecture : relisez votre document avec elle avant de l'envoyer.
| Section | Lisible sans réunion | Erreur qui renvoie le document |
|---|---|---|
| Contexte | Le problème, qui décide, qui paie | « Une application innovante pour nos clients » |
| Utilisateurs | Rôles, appareils réellement en main | « Tout le monde » |
| Parcours clé | La tâche, du déclencheur au résultat | Une liste d'écrans sans ordre |
| Écrans et fonctions | Indispensable, puis ensuite | Une application concurrente « en mieux » |
| Données | Où elles vivent, qui les modifie | « Il faudra une base de données » |
| Intégrations | Outil d'en face, sens, fréquence | « Connectée à tous nos outils » |
| Contraintes | Hors connexion, appareils, données personnelles | Des souhaits écrits comme des contraintes |
| Publication | Comptes des stores, maintenance, propriété | Rien, ou « vous vous en occupez » |
| Budget et recette | Lots, fourchette, critère d'acceptation | Un montant unique, sans lot |
Contexte, utilisateurs et parcours clé : la première page
Le contexte tient en un paragraphe : le problème d'aujourd'hui, et ce qui change le jour où l'application marche. « Les techniciens ressaisissent leurs rapports le soir » se chiffre ; « digitaliser le terrain » ne se chiffre pas. Ajoutez qui décide et qui valide les livrables : un prestataire chiffre aussi le nombre d'allers-retours.
Les utilisateurs se décrivent par rôle : technicien, chef d'équipe, client, administrateur. Pour chacun, le téléphone qu'il a vraiment en main, modèles anciens compris. Le parcours clé raconte ensuite une tâche complète, comme un rapport d'intervention : ouverture, saisie, photo, signature, envoi. C'est lui que JAIKIN met d'abord dans les mains de vrais utilisateurs, et c'est lui qui fixe le premier lot.
Écrans et fonctions : deux colonnes, pas une liste
La liste des fonctions se range en deux colonnes. À gauche, ce sans quoi le parcours clé échoue. À droite, ce qui peut attendre la deuxième version. Notifications, tableau de bord, mode sombre : chaque ligne de droite a un coût, et peu servent le premier jour. Une maquette n'est pas obligatoire à ce stade ; un croquis par écran du parcours clé suffit.
L'erreur fréquente est de décrire une application concurrente « en mieux ». Le prestataire ne sait pas quelles fonctions vous avez vues, ni lesquelles vous servent. La seconde est d'oublier les écrans d'administration : qui crée les comptes, qui corrige une saisie, qui exporte. Ils ne se voient pas en démonstration, mais ils pèsent dans le devis.
Données, back-office et intégrations : la moitié cachée du devis
Une application mobile affiche des données qui vivent ailleurs. La section données dit lesquelles, où elles vivent aujourd'hui, et qui les modifie : fiches clients dans l'ERP, planning dans un tableur, photos sur le téléphone. Elle dit aussi ce qui ne doit jamais quitter l'entreprise. C'est souvent la moitié du travail, et la partie qu'un devis d'écrans oublie.
Une intégration tient en trois informations : l'outil d'en face, le sens et la fréquence. « Le rapport signé part dans l'ERP à la validation » se chiffre. « Connectée à nos outils » ne se chiffre pas. Joignez un exemple réel du document échangé, même anonymisé : sans lui, l'intégration n'est pas mûre, et elle passe au lot suivant.
Une application mobile à chiffrer ?
Application métier iOS et Android : 15 000 à 35 000 €, publication comprise. En 30 minutes, on situe votre projet dans cette fourchette.
Contraintes : hors connexion, appareils et données personnelles
Les contraintes sont ce qui élimine une option, pas ce qu'on aimerait. Un chantier en sous-sol impose le hors connexion et une synchronisation au retour du réseau. Des téléphones anciens imposent une version minimale du système. Des données personnelles imposent un hébergement choisi, des droits par rôle et une durée de conservation. Chacune change le devis ; une couleur d'écran ne le change pas.
Le choix entre Flutter, React Native et le natif découle de ces contraintes, pas l'inverse. Le cahier n'a pas à le trancher : il donne les faits qui le tranchent. Notre comparatif Flutter vs React Native détaille les critères, et notre agence Flutter et React Native dit comment nous choisissons.
Publication, maintenance et propriété : la section qu'on oublie
Une application mobile n'existe qu'une fois publiée. La section publication dit au nom de qui seront les comptes développeur Apple et Google : le vôtre, toujours. Une application publiée depuis le compte du prestataire ne peut plus recevoir de mise à jour le jour où il s'en va. Elle dit aussi qui prépare la fiche, les captures et la politique de confidentialité.
Elle dit enfin qui maintient l'application quand iOS ou Android change. Chez JAIKIN, aucune maintenance obligatoire : le client est propriétaire du système livré, code compris. Le cahier peut exiger la même chose de tout prestataire : code source livré, comptes à votre nom, documentation de reprise.
Budget, lots et critères de recette
Le budget se rattache à des lots, pas à un montant unique. Chez JAIKIN, une première version mobile démarre dès 8 000 € ; une application métier iOS et Android se situe entre 15 000 et 35 000 €, publication comprise. Au-delà, le projet se découpe en lots chiffrés après cadrage. Le prix d'une application mobile est détaillé facteur par facteur.
Chaque lot porte son critère de recette : « un technicien envoie un rapport signé sans réseau, et il arrive dans l'ERP au retour de la connexion ». Ce critère dit quand le lot est livré, et il évite le débat sur ce qui était « prévu ». Un devis qui ne reprend pas vos critères n'a pas lu le cahier.
Cahier des charges logiciel : ce qui change sans application mobile
Pour un logiciel métier, le même modèle tient, avec deux déplacements. La section publication disparaît : pas de store, pas de revue. Les sections droits et intégrations grossissent : un logiciel de gestion sert plusieurs services, et chacun ne voit pas la même chose. On ajoute une ligne sur la reprise des données existantes, souvent un tableur, et sur ce qui reste dans l'outil en place.
L'erreur propre au logiciel est de décrire l'outil qu'on remplace, écran par écran. Le prestataire reproduit alors les contournements de l'ancien. Décrivez le processus, son déclencheur et ses exceptions : le développement logiciel sur mesure part de là, pas d'une copie d'écran.
Cahier des charges d'une application web : les trois différences
Une application web se décrit comme une application mobile, avec trois différences. Les navigateurs remplacent les téléphones dans la section utilisateurs. La publication devient un hébergement et un nom de domaine, à votre nom. Le hors connexion n'est plus la règle : on le demande seulement si l'usage l'exige. Le reste, parcours clé, données, intégrations et recette, ne change pas.
Si l'application ne sert qu'au bureau, une application web sur mesure coûte souvent moins cher qu'une application mobile, et se met à jour sans passer par les stores. Le cahier des charges est le bon moment pour se poser la question : ses sections utilisateurs et contraintes y répondent.
Exemple rempli : une application d'intervention fictive
L'entreprise ci-dessous est inventée pour montrer le niveau de détail attendu : une PME fictive de maintenance d'équipements, des techniciens chez les clients, un ERP au bureau. Aucun volume n'est donné ; chaque ligne montre ce qu'un prestataire peut chiffrer.
| Section | Ce que le cahier écrit |
|---|---|
| Contexte | Les techniciens remplissent un rapport papier, ressaisi le soir au bureau. Objectif : le rapport signé dans l'ERP le jour même. |
| Utilisateurs | Techniciens sur téléphones Android fournis, chef d'équipe sur iPhone, une administratrice au bureau. |
| Parcours clé | Ouvrir l'intervention du jour, saisir les pièces posées, prendre deux photos, faire signer le client, envoyer. |
| Écrans et fonctions | Indispensable : liste des interventions, rapport, signature. Ensuite : historique du client, tableau de bord du chef d'équipe. |
| Données | Interventions et clients lus dans l'ERP ; photos et signature créées sur le téléphone. |
| Intégrations | Rapport envoyé à l'ERP à la validation ; planning du jour lu chaque matin. |
| Contraintes | Caves et sous-sols sans réseau : hors connexion obligatoire. Données des clients hébergées en Europe. |
| Publication | Comptes Apple et Google au nom de l'entreprise ; comptes des techniciens créés par l'administratrice. |
| Budget et recette | Lot 1 = le parcours clé. Critère : un rapport signé sans réseau arrive dans l'ERP au retour de la connexion. |
Ce cahier tient en deux pages, et il suffit à comparer deux devis. Un prestataire qui répond « hors connexion inclus » sans dire comment la synchronisation traite deux saisies concurrentes n'a pas lu la ligne contraintes.
Comparer les réponses : trois questions à poser à chaque devis
Le devis reprend-il vos lots et vos critères de recette, ou impose-t-il son propre découpage ? Chiffre-t-il un périmètre, ou des jours ? Nomme-t-il qui écrit le back-office et qui publie sous vos comptes ? Ces trois questions valent pour un freelance comme pour une agence ; notre page développeur d'application mobile détaille quand l'un ou l'autre convient.
Questions fréquentes
Comment rédiger le cahier des charges d'une application mobile ?
On écrit neuf sections dans l'ordre : contexte, utilisateurs, parcours clé, écrans et fonctions, données, intégrations, contraintes, publication, budget et recette. Le parcours clé raconte une tâche complète, avec ses exceptions. Les fonctions se rangent en deux colonnes, indispensable puis ensuite. Chaque lot porte un critère de recette. JAIKIN renvoie un document qui décrit une application concurrente « en mieux », ou qui pose un montant unique.
Que doit contenir, au minimum, le cahier des charges d'une application ?
Trois sections rendent deux devis comparables : le parcours clé avec ses exceptions, les données et leurs intégrations, le budget découpé en lots avec un critère de recette par lot. Les autres sections évitent les avenants. Sans ces trois-là, deux prestataires ne chiffrent pas la même application, même si leurs totaux se ressemblent.
Le modèle existe-t-il en PDF ou en Word ?
Non, JAIKIN ne publie pas de fichier de ce modèle : cette page est le modèle. Pour l'avoir hors ligne, la commande Imprimer du navigateur, puis Enregistrer au format PDF, suffit. Le plus utile reste de recopier la grille de relecture et l'exemple rempli dans votre propre document, puis de remplacer chaque ligne par votre parcours, vos données et vos lots.
Faut-il un cahier des charges pour une petite application ?
Oui, mais court. Une première version tient souvent en deux pages : un parcours clé, ses données, une contrainte forte et un critère de recette. C'est sur les petits projets qu'un document flou coûte le plus cher, parce que l'écart entre deux devis y pèse vite autant que le budget. Deux pages précises valent mieux que vingt pages de fonctions.
Cahier des charges fonctionnel ou technique : lequel écrire ?
Le fonctionnel, d'abord : parcours, données, contraintes, critères de recette. Le choix technique, Flutter, React Native ou natif, découle de ces faits et revient au prestataire, qui doit le justifier. Écrire la technologie avant le parcours revient à choisir l'outil avant de savoir quelle exception compte. Une contrainte technique réelle, comme un équipement à relier, entre dans la section contraintes.
Combien coûte une application décrite par ce cahier des charges ?
Chez JAIKIN, une première version mobile démarre dès 8 000 € et une application métier iOS et Android se situe entre 15 000 et 35 000 €, publication comprise. Au-delà, le projet se découpe en lots chiffrés après cadrage. Le cahier des charges sert précisément à placer le projet dans l'un de ces paliers, puis à rendre le devis ferme après cadrage.
