Modèle de cahier des charges pour une application mobile

En résumé : le cahier des charges d'une application mobile tient en neuf rubriques : le problème, les utilisateurs et les rôles, les exigences classées, le modèle de données, les critères d'acceptation, le fonctionnement hors ligne, les notifications, les contraintes des boutiques d'applications, et ce qui est hors périmètre de la première version. Ci-dessous, le modèle que j'utilise, avec un exemple de critères testables.

Pourquoi une application mobile demande des rubriques en plus

Une application mobile ajoute des questions qu'un site ne pose pas : que se passe-t-il sans réseau, quand l'utilisateur reçoit-il une notification, quelles versions de téléphone sont prises en charge, et comment l'application passe-t-elle la validation des boutiques ? Quand ces points ne sont pas écrits, chaque prestataire chiffre ce qu'il imagine. Dans un cas réel, deux devis pour la même application, 18 000 $ et 47 000 $, s'expliquaient par l'absence, dans le moins cher, de mode hors ligne, de gestion des rôles et de back-office d'administration : environ 60 % du produit en charge.

Le modèle en neuf rubriques

1. Problème et contexte : ce qui ne fonctionne pas aujourd'hui, avec un chiffre si possible.
2. Utilisateurs et rôles : qui utilise l'application, et ce que chaque rôle peut faire. Les rôles cachent beaucoup de périmètre : un back-office, une vue gestionnaire et une vue client font trois produits.
3. Exigences classées : chacune en une phrase, marquée indispensable, souhaitable ou plus tard.
4. Modèle de données : entités, relations et champs qui comptent.
5. Critères d'acceptation : pour chaque indispensable, les contrôles qu'une personne non technique peut exécuter.
6. Hors ligne et synchronisation : ce qui doit fonctionner sans réseau, comment les données se synchronisent à la reconnexion, comment les doublons sont évités.
7. Notifications : déclencheurs, délais, fréquence, désactivation.
8. Appareils et boutiques : systèmes et versions pris en charge, comptes développeur créés au nom de votre organisation, règles de validation des boutiques.
9. Hors périmètre de la version 1 : une liste explicite.

Exemple : des critères testables pour un enregistrement à distance

Exemple illustratif, dans l'esprit d'une plateforme que j'ai livrée (voir l'étude de cas Doctifile).

Flou : « Le patient peut s'enregistrer à distance. »

Testable :

• Un patient ayant un rendez-vous peut s'enregistrer depuis son téléphone jusqu'à 30 minutes avant le créneau, sans créer de compte.
• Après l'enregistrement, il voit sa position dans la file, mise à jour sans rechargement de la page.
• Si le cabinet signale un retard, chaque patient enregistré reçoit une notification en moins d'une minute.
• Hors réseau, une action saisie est conservée sur l'appareil et synchronisée à la reconnexion, sans doublon.

Les cinq erreurs qui rendent un cahier des charges inutilisable

• décrire la solution au lieu du besoin ;
• omettre les critères d'acceptation ;
• tout classer en priorité ;
• ne rien écrire sur les données (qui migre, qui nettoie) ;
• ne pas lister ce qui est hors périmètre.

Le test avant l'envoi

Donnez le document à quelqu'un d'extérieur à votre métier et posez deux questions : qu'est-ce qui doit être construit ? et comment saura-t-on que cela fonctionne ? Si la seconde reste sans réponse, le document n'est pas prêt. Pour la structure générale, voir comment rédiger un cahier des charges.

Le faire rédiger

Mon offre cahier des charges et spécifications livre en dix jours ouvrés les exigences classées, le modèle de données, les critères d'acceptation et une estimation de charge. Je rédige sans répondre à l'appel d'offres : le document reste neutre.