Que doit contenir un cahier des charges d'application mobile?

L'objectif et la cible de l'app, le périmètre fonctionnel complet avec tous les écrans et leurs états, les exigences non fonctionnelles comme la performance et la protection des données, les contraintes de design, les interfaces avec les services externes, la plateforme visée et des critères de recette clairs. Plus chaque point est concret, plus le devis que vous recevez est précis et moins il y a d'avenants ensuite.

Quelle différence entre cahier des charges et spécifications?

Le cahier des charges décrit de votre point de vue ce dont vous avez besoin, tandis que les spécifications décrivent du point de vue du prestataire comment il va le réaliser. En pratique les termes se mélangent souvent. L'important n'est pas l'appellation, mais qu'un document existe qui fixe les besoins assez clairement pour que les deux parties attendent la même chose.

Ai-je besoin d'un cahier des charges pour mon application?

Pour tout projet sérieux, oui. Sans besoins écrits, vous recevez des devis imprécis qui deviennent plus chers ensuite en avenants, et en cas de litige c'est parole contre parole. Un cahier des charges n'a pas à être parfait, mais il doit fixer les fonctions, écrans et conditions centraux. Il naît souvent avec le prestataire lors d'une phase de cadrage.

Quel niveau de détail pour un cahier des charges?

Assez détaillé pour qu'un prestataire puisse établir un devis solide sans questions, mais pas si rigide qu'il n'y ait plus de place pour de meilleures solutions. Décrivez précisément le quoi et le pourquoi de chaque fonction, laissez de la latitude sur le comment. Un bon cahier des charges pour un MVP tient souvent en quelques pages claires, pas cent.

Puis-je faire rédiger le cahier des charges par le prestataire?

Oui, et c'est souvent la meilleure option. Un prestataire expérimenté rédige avec vous, lors d'une phase de cadrage payée, un cahier des charges qui relie vos objectifs à la réalité technique. Le résultat vous appartient et peut servir à consulter d'autres prestataires. Exigez que ce document et le code soient votre propriété.

Cahier des charges d'application mobile: structure et modèle

Réponse courte

Un cahier des charges d’application décrit ce que l’app doit faire, pour qui et dans quelles conditions. Il contient l’objectif et la cible, le périmètre fonctionnel avec tous les états, les exigences non fonctionnelles, les contraintes de design, les interfaces, la plateforme et les critères de recette. Un cahier des charges clair donne des devis plus précis, moins d’avenants et un contrat plus équitable. Le modèle plus bas fournit la structure; remplissez-le avec vos vrais besoins. Si vous voulez d’abord estimer le budget, notre guide sur les coûts d’une application donne des repères.

Pourquoi un cahier des charges vaut de l’argent

Beaucoup de projets démarrent par un courriel et une idée floue. Le résultat: des devis très éloignés les uns des autres, parce que chaque prestataire y lit autre chose. Le cahier des charges règle exactement cela: il donne à tous la même base, de sorte que vous comparez des devis qui portent sur la même chose.

Le deuxième bénéfice apparaît en cours de projet. La cause la plus fréquente d’avenants et de litiges, c’est qu’un périmètre n’a jamais été mis par écrit. Si une fonction figure au cahier des charges, il est clair qu’elle fait partie du prix. Si elle n’y figure pas, il est clair que c’est un ajout payant. Cette clarté protège les deux parties et rend la collaboration plus sereine.

Un cahier des charges n’est donc pas un rituel administratif, mais le document sur lequel vous vous appuyez quand quelque chose devient flou, et tôt ou tard quelque chose le devient toujours.

Les chapitres d’un bon cahier des charges

Un cahier des charges utile s’organise en sections claires. La structure suivante peut servir directement de modèle:

Chapitre	Ce qu’il contient
Objectif et finalité	Quel problème l’app résout, quel but métier
Cible	Qui utilise l’app, dans quelle situation
Périmètre fonctionnel	Toutes les fonctions et écrans, avec états
Exigences non fonctionnelles	Performance, sécurité, données, montée en charge
Contraintes de design	Style, marque, références, accessibilité
Interfaces	Services externes, API, systèmes existants
Plateforme et technique	iOS, Android, versions, appareils
Critères de recette	Comment on mesure qu’une chose est terminée
Délai et budget	Cadre général, échéances clés

Chaque chapitre n’a pas à être long. Pour un MVP, quelques phrases claires par section suffisent souvent. L’essentiel est qu’aucun ne manque, car tout chapitre omis est une discussion à venir.

Le plus important: le périmètre fonctionnel avec les états

Le chapitre qui décide de la qualité des devis, c’est le périmètre fonctionnel. L’erreur la plus courante est de lister les fonctions par mots-clés: “connexion”, “chat”, “paiements”. Cette forme courte cache le périmètre réel.

“Connexion” signifie en réalité connexion avec Apple, e-mail, réinitialisation du mot de passe, vérification et suppression de compte, cette dernière étant obligatoire selon les directives de l’App Store dès que votre app crée des comptes. Décrivez donc chaque fonction complètement et pensez aux états: qu’affiche un écran quand il est vide, quand il charge, quand une erreur survient et quand il est rempli? Ces quatre états par écran sont le vrai travail et l’angle mort le plus fréquent d’un cahier des charges.

Plus vous êtes précis ici, plus le devis est juste et moins il y a d’avenants. Décrivez précisément le quoi et le pourquoi de chaque fonction, mais laissez de la latitude sur le comment, pour que le prestataire choisisse la meilleure solution technique.

Prioriser les fonctions: indispensable, souhaité, optionnel

Un cahier des charges qui traite toutes les fonctions au même niveau oblige le prestataire à tout chiffrer et rend un MVP économique impossible. Priorisez donc chaque fonction pour qu’un premier périmètre raisonnable puisse émerger:

Priorité	Signification	Exemple
Indispensable	Sans elle, l’app ne se lance pas	Inscription, action centrale, paiement
Souhaité	Important, mais reportable au lancement	Notifications, filtres
Optionnel	Souhaitable, version ultérieure	Fidélité, recommandations, thèmes

Ce simple classement a un grand effet: il permet au prestataire de composer un MVP fait seulement des fonctions indispensables, que vous publiez tôt et testez avec de vrais utilisateurs. Les fonctions souhaitées et optionnelles se financent ensuite avec ce que vous avez appris de la première version. Un cahier des charges sans priorisation mène souvent à un premier jet surchargé et coûteux.

Ne pas oublier les exigences non fonctionnelles

Un domaine souvent absent et qui coûte cher, ce sont les exigences non fonctionnelles: tout ce que l’app doit savoir faire sans être une fonction visible. Cela comprend:

Performance. À quelle vitesse l’app doit répondre, combien d’utilisateurs simultanés?
Sécurité et protection des données. Quelles données sont collectées, comment protégées, quelles obligations légales, notamment le RGPD?
Accessibilité. L’app doit-elle suivre les recommandations d’accessibilité d’Apple, par exemple pour VoiceOver et les grandes tailles de texte?
Disponibilité et montée en charge. L’app doit-elle absorber des pics, dans quelles régions fonctionne-t-elle?

Ces points influencent fortement la charge mais n’apparaissent jamais dans une simple liste de fonctions. Les nommer au cahier des charges donne un devis plus honnête et évite qu’ils reviennent plus tard comme une coûteuse surprise.

Design, interfaces et recette

Trois chapitres complètent le document. Pour les contraintes de design, il suffit souvent d’indiquer le style voulu, votre marque et deux ou trois applications de référence dont vous visez la qualité. Un prestataire qui travaille selon les Human Interface Guidelines d’Apple livre une app que les utilisateurs d’iPhone comprennent aussitôt.

Pour les interfaces, listez chaque service externe et chaque système existant que l’app doit relier: prestataire de paiement, cartes, un logiciel de gestion existant. Chaque interface apporte ses propres flux et cas d’erreur et doit donc figurer au document.

Les critères de recette fixent comment on mesure qu’une chose est terminée. Sans eux, “terminé” reste sujet à interprétation. Un bon prestataire teste sur de vrais appareils et fournit une bêta via TestFlight sur laquelle vous effectuez la recette.

Utiliser le modèle correctement

La structure ci-dessus est votre modèle gratuit. Pour la transformer en un cahier des charges utile:

Parcourez chaque chapitre et écrivez avec vos mots ce qui vaut pour votre app. Des phrases courtes et claires valent mieux que de longs paragraphes vagues.
Priorisez les fonctions en indispensable, souhaité et optionnel, pour qu’un MVP puisse être défini.
Signalez explicitement les questions ouvertes au lieu de les taire. Un honnête “encore à décider” vaut mieux qu’une exigence inventée.
Faites relire le document, idéalement par une personne qui utilisera l’app.

Le résultat n’a pas à être parfait. Un cahier des charges de quatre pages clair pour un MVP vaut mieux qu’un document de cent pages que personne ne lit. Son but n’est pas l’exhaustivité pour elle-même, mais une base commune: vous et le prestataire devez avoir la même app en tête après lecture.

Les erreurs les plus fréquentes

De nombreux cahiers des charges répètent les mêmes erreurs, faciles à éviter une fois nommées:

Des fonctions en mots-clés plutôt qu’en flux. “Chat” est un mot; “chat avec historique, notifications, blocage et signalement d’abus” est le vrai besoin.
Seul le cas favorable décrit. Que se passe-t-il sans connexion, avec un formulaire à moitié rempli, un paiement refusé? Les cas d’erreur sont un tiers du travail.
Le comment imposé au lieu du quoi. Si vous dictez la solution technique, vous privez le prestataire de la chance d’en trouver une meilleure.
Aucune priorisation. Sans indispensable, souhaité et optionnel, tout MVP devient trop gros.
Exigences non fonctionnelles omises. Données, performance et accessibilité manquent et reviennent en avenants coûteux.
Pas de critère de recette. Sans définition mesurable de “terminé”, chaque discussion reste ouverte.

Chacune de ces erreurs coûte plus tard de l’argent ou des nerfs. Un rapide contrôle du document au regard de cette liste est l’une des assurances qualité les moins chères du projet, et pourtant l’une des plus rentables.

Rédiger le cahier des charges avec le prestataire

Il existe un cas où vous n’avez pas à écrire seul le cahier des charges: un prestataire expérimenté le rédige avec vous lors d’une phase de cadrage payée. L’avantage est grand, car le document relie alors vos objectifs à la réalité technique, au lieu de contenir des exigences difficiles à réaliser.

Exigez dans ce cas deux choses: le cahier des charges vous appartient et peut servir à consulter d’autres prestataires, et le même principe vaut pour le code, dont le dépôt doit être à votre nom dès le premier jour. Ainsi vous restez indépendant et pouvez changer de prestataire sans repartir de zéro, si la collaboration ne convient plus un jour.

C’est exactement notre façon de travailler: une équipe qui réunit design et développement sous un même toit traduit votre idée en un cahier des charges clair, puis la construit, sans la coûteuse friction entre prestataires séparés. Vous trouverez des exemples dans nos projets, et lors d’un court échange nous établissons avec vous la base de votre projet, de la première idée au cahier des charges prêt pour la recette.