Cahier des charges d’application mobile : exemple testable

Un cahier des charges d’application mobile décrit le problème à résoudre, les utilisateurs, le périmètre, les contraintes et les critères qui permettront d’accepter la livraison. Commencez par un brief court pour décider, puis détaillez les parcours qui exigent un engagement précis.

Le modèle court à remplir avant le premier échange

Rubrique	Votre réponse
Utilisateur et problème	Qui rencontre quelle difficulté, dans quel contexte ?
Résultat attendu	Quelle tâche la personne doit-elle pouvoir terminer ?
Périmètre	Qu’incluez-vous dans cette version et qu’excluez-vous ?
Contraintes	Quels appareils, accès, données et systèmes faut-il prendre en compte ?
Acceptation	Quel scénario permettra de vérifier le résultat ?
Livraison	Qui recevra le code, les comptes et les instructions d’exploitation ?

Utilisez le générateur de cahier des charges pour organiser vos réponses. Le brief court convient lorsque vous explorez encore les options. Une spécification détaillée devient utile lorsque vous devez valider des parcours, des intégrations et des conditions de recette. La longueur du document ne remplace pas la clarté d’une décision.

Si vous reprenez un produit existant, commencez par l’audit d’application mobile : un constat reproductible évite de transformer une hypothèse en exigence de refonte.

Comment utiliser l’exemple ci-dessous

L’exemple Climato décrit ensuite le problème métier, le périmètre choisi, dix critères de recette, la distinction entre conformité et produit, puis un modèle détaillé à réutiliser. Choisissez d’abord les critères de votre parcours prioritaire ; vous n’avez pas besoin de reprendre toutes les fonctions de cet exemple fictif.

Un cahier des charges ne sert pas à deviner toutes les réponses avant le premier atelier. Il sert à poser les bonnes questions, à rendre les décisions visibles et à transformer « l’application doit marcher » en critères que vous pourrez tester vous-même.

Je vais vous montrer un exemple fictif de cadrage pour une application de service terrain, puis les tests de recette correspondants. L’exemple est volontairement concret : il illustre comment lier chaque exigence produit à une vérification observable, sans transformer le document en simple liste d’écrans.

Le problème avant la solution

Imaginons une entreprise de maintenance d’équipements industriels, appelons-la « Climato ». Aujourd’hui, un technicien part avec une fiche papier, prend des photos, puis ressaisit tout au bureau. Résultat : des erreurs de saisie, des retards de facturation et aucune visibilité en temps réel pour le responsable.

Le cahier des charges commence par ce problème, pas par « une application avec un bouton photo ». Vous écrivez :

Les techniciens doivent pouvoir créer, modifier et clôturer un rapport d’intervention sur site, même sans réseau, puis synchroniser les données au retour sans créer de doublons.

Ce résultat observable devient le filtre de toutes les fonctionnalités. On ne coche pas des cases ; on relie chaque exigence à un comportement métier.

Le périmètre choisi pour cet exemple

Le technicien consulte ses interventions, rédige un rapport et ajoute une photo si elle est utile. Le responsable attribue les interventions et vérifie les rapports. Le MVP ne comprend ni paiement, ni messagerie interne, ni géolocalisation continue. Cette exclusion compte autant que la liste des fonctions retenues.

Avant de développer, l’équipe doit choisir quels rapports peuvent rester sur un appareil, pendant combien de temps et dans quelles conditions elle autorise leur consultation hors ligne. Elle doit également décider qui résout un conflit et qui peut supprimer un rapport. Les tests ci-dessous supposent que ces décisions figurent dans le document.

Si vous hésitez encore entre une démonstration technique et un premier produit utilisable, comparez le prototype et le MVP. Le scanner de risques MVP peut ensuite vous aider à rendre les inconnues visibles.

Les 10 critères d’acceptation à tester

Voici comment transformer les fonctions critiques en tests de recette. Chaque critère est une phrase que votre équipe peut cocher pendant une session de validation, avec un scénario de test associé.

1. Capture hors ligne sans perte

Critère : Si le technicien n’a pas de réseau, il peut créer un rapport, joindre des photos et enregistrer le tout. Au retour de la connexion, le rapport est synchronisé automatiquement.

Test : Activez le mode avion. Créez un rapport, ajoutez trois photos. Vérifiez que le rapport reste modifiable et qu’aucune donnée n’est perdue.

2. Reprise sans doublon

Critère : Après une coupure de réseau en cours de synchronisation, l’application reprend le transfert sans dupliquer le rapport, les photos ou les signatures.

Test : Lancez la synchronisation, coupez le réseau à mi-parcours, rétablissez-le. Vérifiez qu’il n’existe qu’un seul rapport et que toutes les photos sont bien associées.

3. Gestion des modifications conflictuelles

Critère : Si deux utilisateurs modifient le même rapport en même temps, l’utilisateur autorisé compare les versions et choisit la résolution ; aucun changement n’est silencieusement écrasé.

Test : Ouvrez le même rapport sur deux appareils en mode hors ligne. Modifiez le champ « observation » différemment, synchronisez les deux. Vérifiez qu’un écran de résolution apparaît et que l’utilisateur choisit la version finale.

4. Permission photo refusée

Critère : Si l’utilisateur refuse l’accès à la caméra ou à la galerie, l’application lui explique pourquoi la permission est nécessaire, propose une alternative et continue de fonctionner pour les autres fonctions.

Test : Refusez la permission. Vérifiez le message explicatif, testez la saisie de texte sans photo. La permission ne doit pas être redemandée à chaque action.

5. Principe de minimisation des permissions

Critère : L’application ne demande que les permissions strictement nécessaires, au moment où la fonction est utilisée pour la première fois, plutôt que de demander des accès sans rapport avec le parcours en cours.

Test : Installez l’application sur un appareil vierge. Vérifiez qu’aucune permission n’est demandée avant qu’une action la justifie. Exemple : la localisation n’est demandée que pour l’itinéraire, pas pour ouvrir le rapport.

6. Suppression des données locales

Critère : Quand un technicien supprime un rapport localement avant synchronisation, aucune trace résiduelle (photo, fichier temporaire) n’est retrouvée dans le stockage de l’application.

Test : Créez un rapport avec photos, supprimez-le en mode hors ligne. Demandez à l’équipe technique de vérifier le stockage de test et les fichiers associés avec les outils adaptés à la plateforme. Un simple contrôle de la liste visible ne suffit pas.

7. Suppression des données côté serveur

Critère : Quand un responsable supprime un rapport dans le back-office, l’application mobile est informée et le rapport disparaît de la liste locale après synchronisation.

Test : Supprimez un rapport dans l’interface d’administration. Synchronisez l’appareil. Vérifiez que le rapport n’apparaît plus et qu’une règle de conservation est notée dans la documentation.

8. Départ d’un technicien et attribution des accès

Critère : Quand un technicien quitte l’entreprise, son compte peut être désactivé sans supprimer l’historique des rapports déjà synchronisés. Créez un compte nominatif distinct pour son remplaçant, avec les droits nécessaires.

Test : Désactivez un utilisateur dans le back-office. Vérifiez que ses rapports restent accessibles au responsable et que la connexion mobile est refusée. Créez un nouvel utilisateur avec le même rôle et vérifiez qu’il accède aux interventions en cours.

9. Écran de permission sans confusion

Critère : L’application distingue clairement la demande de permission technique du système et le recueil du consentement RGPD, le cas échéant. Le parcours explique leur différence et recueille un consentement distinct lorsque ce fondement est nécessaire.

Test : Lancez une action qui nécessite la caméra et un consentement de traitement. Vérifiez que le parcours distingue les deux décisions, respecte le refus et ne présente pas une autorisation système comme un consentement à tous les traitements.

10. Journal de synchronisation vérifiable

Critère : Chaque rapport affiche la date et le statut de sa dernière synchronisation. Le technicien peut voir si le rapport est à jour sans se reconnecter au serveur.

Test : Créez un rapport hors ligne, puis synchronisez. Vérifiez que le statut passe de « en attente » à « synchronisé » et que l’horodatage est correct.

Conformité vs produit : ne mélangez pas les deux

Les critères 4, 5, 8 et 9 touchent à la protection des données et à la gestion des permissions. Ce ne sont pas de simples choix techniques. La CNIL rappelle que les permissions du système ne recueillent pas le consentement RGPD : elles donnent uniquement un accès technique. Selon le traitement, vous devez déterminer le fondement juridique approprié et, lorsque le consentement est nécessaire, le recueillir correctement. La CNIL explique cette différence entre permission technique et consentement.

Dans votre cahier des charges, séparez les exigences produit des exigences de conformité. Un test de recette vérifie le comportement ; il ne valide pas la conformité juridique. Pour cela, référez-vous aux recommandations de la CNIL et à votre délégué à la protection des données. L’exemple ci-dessus montre comment des règles comme la minimisation des permissions se traduisent en critères testables, sans prétendre couvrir l’ensemble des obligations.

Le modèle de cahier des charges à réutiliser

Vous pouvez repartir de la structure suivante, que vous remplirez avec votre contexte :

1. Contexte : activité, problème actuel, personnes concernées et conséquence.
2. Résultat attendu : ce que l’utilisateur pourra accomplir et comment vous validerez l’utilité.
3. Utilisateurs : profils, droits, appareils, contexte et contraintes d’usage.
4. Parcours prioritaires : trois à cinq scénarios complets, du déclencheur au résultat.
5. Périmètre : fonctions du MVP, phase suivante et éléments hors périmètre.
6. Plateformes : iOS, Android, tablette, web, versions minimales et capacités du téléphone.
7. Données : données collectées, finalité, durée, suppression, permissions et acteurs qui y accèdent.
8. Intégrations : systèmes, API, propriétaires, documentation et sens de synchronisation.
9. Qualité : critères d’acceptation, appareils de test, accessibilité, langues et volumes.
10. Livraison : code, comptes, maquettes, documentation, déploiement, garantie et maintenance.
11. Organisation : décideur, interlocuteurs, disponibilité pour tester et circuit de validation.
12. Contraintes : échéance, dépendances, enveloppe ou scénarios de périmètre.

Pour chaque critère d’acceptation, écrivez le comportement observable et le test à exécuter, comme dans l’exemple Climato. Vous disposerez ainsi d’une base précise pour discuter du périmètre et préparer la recette.

Ce que Doved Studio fait avec votre cahier des charges

Je ne transforme pas votre première liste en devis automatique. Je vérifie le parcours principal, je relève les décisions qui changent l’architecture et je distingue le nécessaire de ce qui peut attendre. Les critères d’acceptation deviennent notre outil commun : vous savez exactement quoi tester, et je sais ce qu’il faut livrer.

Vous pouvez réunir ces décisions dans le générateur de cahier des charges. Puis apportez votre parcours principal et un critère encore ambigu à Doved Studio : nous réunissons cadrage produit, conception et développement pour préciser ce qu’il faut livrer. Faites aussi figurer la remise du code, la propriété des comptes et la documentation dans les livrables attendus.

Questions fréquentes

Faut-il écrire tous les tests de recette avant le développement ?

Non. Vous pouvez commencer par les critères qui correspondent aux parcours critiques. Le studio complétera les cas limites pendant le cadrage. L’important est d’avoir une base vérifiable avant la recette.

Quelle est la différence entre un test de recette et un test de conformité ?

Un test de recette vérifie que l’application se comporte comme prévu (ex. : pas de doublon après synchronisation). Un test de conformité vérifie le respect d’une obligation légale (ex. : consentement RGPD). Le premier relève du produit, le second du juridique.

Cet exemple décrit-il un vrai client ?

Non. Climato est un exemple fictif créé pour illustrer comment structurer un cahier des charges. Il ne décrit pas une mission client.

Puis-je utiliser ce modèle pour d’autres secteurs ?

Oui. La structure reste valable pour une application de logistique, de santé à domicile ou de maintenance. Adaptez les permissions et les données à vos obligations sectorielles.