MODÈLE DE CAHIER DES CHARGES D'APPLICATION Maestro · Version du modèle : 15 septembre 2026 Guide : https://www.bemaestro.fr/journal/cahier-des-charges-non-technique UTILISATION Commencez par la fiche courte ci-dessous. Quelques phrases suffisent pour une première discussion. Le modèle complet vient ensuite : complétez les rubriques utiles au fil des décisions, sans chercher à tout remplir d'un coup. Copiez ce document dans l'éditeur de votre choix. Remplacez les champs entre crochets. Écrivez « à décider » lorsque la réponse manque. Dans le modèle complet, ajoutez qui cherchera la réponse et quand. Retirez les exemples fictifs avant de partager votre version. Ce modèle décrit un besoin produit ; il ne remplace pas un contrat de prestation. FICHE COURTE : SIX QUESTIONS POUR COMMENCER 1. Quel problème voulez-vous résoudre ? Aujourd'hui, [personne] doit [tâche], mais [difficulté]. 2. Qui utilisera l'application ? [Personnes concernées et ce que chacune doit pouvoir faire.] 3. Quelle est la première action à rendre possible ? [Racontez un seul parcours, du départ au résultat attendu.] 4. Quelles informations faut-il retrouver ? [Informations utiles, où elles sont aujourd'hui et qui peut les consulter.] 5. Que doit-il se passer en cas de problème ? [Une erreur, une annulation ou deux demandes en même temps.] 6. Comment saurez-vous que cela fonctionne ? [Un essai concret, le résultat attendu et la personne qui le vérifiera.] Exemple fictif : une cliente choisit un créneau libre et réserve. La réservation apparaît dans le planning. Si quelqu'un prend le même créneau avant elle, l'application l'explique et lui propose de choisir une autre heure. POUR CONTINUER Les rubriques 2 à 6 du modèle complet développent le besoin et les règles. Les rubriques 7 à 10 précisent les données, la reprise et les vérifications. Les deux dernières préparent le travail avec la personne qui construit. Gardez les questions ouvertes et faites relire cette fiche aux futurs utilisateurs. MODÈLE COMPLET À COMPLÉTER AU FIL DU PROJET 1. IDENTITÉ ET DÉCISIONS Nom du projet : [nom] Responsable du projet : [nom et rôle] Version du document et date : [version / date] Personne qui valide le périmètre : [nom] Personnes consultées : [utilisateurs, exploitation, prestataire] Statut : [brouillon / à relire / validé] Journal des décisions : - [date] [décision] [motif] [personne ayant validé] [conséquences] 2. PROBLÈME ET OBJECTIF Aujourd'hui, [personne] doit [tâche], mais [obstacle observable]. Conséquence : [erreur, ressaisie, attente, coût observé]. Comment le problème est-il traité aujourd'hui ? [outil et étapes] Quelles preuves avons-nous ? [exemples, observations datées, mesures disponibles] Résultat attendu : [ce qui doit devenir possible] Indicateur de réussite : [mesure, situation actuelle, cible à justifier] Quand et comment sera-t-il mesuré ? [méthode et responsable] Alternatives examinées : [améliorer l'existant / logiciel du marché / construction] Pourquoi ce projet ? [raisons et limites des alternatives] 3. UTILISATEURS ET DROITS Pour chaque rôle, compléter : - Rôle : [nom compréhensible] - Tâches réalisées : [liste] - Informations consultables : [liste] - Actions autorisées : [créer / modifier / valider / supprimer / exporter] - Actions interdites : [liste] - Périmètre des données : [les siennes / son équipe / toute l'organisation] - Accès : [sans compte / compte personnel / invitation / autre] - Retrait ou récupération d'accès : [procédure attendue] Ne pas supposer qu'un écran masqué suffit à interdire une action : préciser les essais à effectuer avec chaque rôle. 4. PÉRIMÈTRE DE LA PREMIÈRE VERSION Indispensable pour le premier usage : - [fonction] : [besoin couvert et personne concernée] Utile ensuite : - [fonction] : [raison de la différer] Explicitement exclu : - [fonction, support ou connexion non prévu] Dépendances avant de commencer : [accès, contenus, données, décisions] Critère pour reporter ou abandonner le projet : [condition concrète] 5. PARCOURS À CONSTRUIRE Identifiant : [P-01] Nom : [action réalisée par une personne] Utilisateur : [rôle] Situation de départ : [informations et état déjà disponibles] Étapes : 1. [action de l'utilisateur] 2. [réponse attendue de l'application] 3. [action suivante] Résultat final : [ce que la personne obtient] Cas à traiter : - Saisie manquante ou invalide : [comportement] - Action simultanée d'une autre personne : [comportement] - Connexion interrompue ou service indisponible : [comportement] - Annulation ou correction : [comportement] - Droit insuffisant : [comportement] Dupliquer cette rubrique pour chaque parcours indispensable. 6. RÈGLES DU MÉTIER Identifiant : [R-01] Règle en une phrase : [quand..., alors...] Exemple autorisé : [valeurs et résultat] Exemple refusé : [valeurs et explication attendue] Exceptions : [lesquelles, qui peut les autoriser] Qui confirme cette règle ? [nom] Parcours concernés : [identifiants] Décrire aussi les règles présentes dans les formules, couleurs, commentaires et habitudes de travail de l'ancien outil. 7. DONNÉES ET DOCUMENTS Pour chaque information : - Nom et sens : [ex. identifiant de commande] - Obligatoire ? [oui / non / selon quelle condition] - Format et valeurs autorisées : [texte, date, liste, montant et devise] - Origine : [saisie, import, service externe] - Qui peut la voir ou la modifier ? [rôles] - Durée de conservation et suppression : [règle à valider] - Export nécessaire : [format, contenu, droits] Données confidentielles à protéger : [catégories, sans exemples réels sensibles] Données fictives utilisables pour les essais : [jeu d'essai] Responsable des questions de confidentialité : [nom ou rôle] Services qui recevront les données : [à confirmer avec le réalisateur] 8. REPRISE DE L'EXISTANT Sources à reprendre : [fichiers, bases, documents] Volume connu et date du relevé : [nombre d'éléments et taille] Identifiants stables : [comment retrouver un élément sans ambiguïté] Doublons et champs manquants : [règles de traitement] Échantillon de premier import : [cas ordinaires et exceptions] Vérifications : [nombre d'éléments, totaux, liens, dates, exceptions] Responsable de validation : [nom] Sauvegarde initiale conservée : [emplacement et responsable] Date de bascule envisagée : [date et conditions préalables] Source faisant foi pendant la transition : [outil et règles de modification] Condition de retour à l'ancien outil : [anomalie et décisionnaire] Reprise des changements depuis la sauvegarde : [procédure] Ancien outil après bascule : [lecture seule / archivage / autre] 9. CONNEXIONS, APPAREILS ET QUALITÉ D'USAGE Connexions externes : [service, opération, données échangées, responsable du compte] Comportement si une connexion échoue : [message, reprise, alerte] Appareils et navigateurs à prendre en charge : [liste priorisée] Usage au clavier, lisibilité et besoins d'accessibilité : [situations à vérifier] Performance attendue : [action, seuil convenu, appareil, connexion et conditions] Disponibilité nécessaire : [horaires et conséquence d'une interruption] Langues et formats : [langues, dates, nombres, fuseaux horaires] 10. CRITÈRES D'ACCEPTATION Identifiant : [CA-01] Parcours et règle concernés : [P-01 / R-01] Étant donné : [situation de départ et données d'essai] Lorsque : [action] Alors : [résultat observable et absence d'effet indésirable] Vérifié par : [personne] Preuve : [scénario exécuté, capture, résultat de test] Statut : [à essayer / réussi / à corriger] Date et version essayée : [date / version] Inclure des critères pour les erreurs, les droits et les actions simultanées, pas seulement pour le parcours où tout se passe bien. 11. LIVRAISON, EXPLOITATION ET SORTIE Livrables attendus : [application, code, documentation, exports, formation] Propriétaire des comptes : [domaine, hébergement, dépôt de code, services] Accès à remettre au responsable : [liste, sans mot de passe dans ce document] Sauvegardes : [contenu, fréquence convenue, responsable, essai de restauration] Incidents : [canal de contact, responsable, délai convenu] Maintenance : [correctifs, mises à jour, périmètre, coût à préciser] Sortie ou changement de prestataire : [code, données, documents et accès à récupérer] Limites connues à la livraison : [liste et décision d'acceptation] 12. BUDGET, CALENDRIER ET VALIDATION Budget de construction : [plafond ou fourchette à confirmer] Coûts récurrents à chiffrer séparément : [hébergement, services, maintenance, usage IA] Premier parcours à livrer : [identifiant] Étapes et personnes qui valident : [étape / date cible / responsable] Disponibilité des utilisateurs pour les essais : [créneaux] Procédure en cas de nouvelle demande : [description, impact, accord avant réalisation] Questions ouvertes : [question / responsable / date attendue] Validation du document : [nom / date / version / réserves éventuelles] EXEMPLE FICTIF À REMPLACER : RÉSERVATION DE CRÉNEAUX Problème : les clients appellent pour réserver et le responsable recopie les rendez-vous dans un agenda. Il souhaite publier ses disponibilités et recevoir les réservations au même endroit. Première version : consultation des créneaux, réservation, confirmation, annulation et planning du responsable. Pas de paiement en ligne ni de SMS. Rôles : le client réserve ; le responsable ouvre les créneaux ; un collègue consulte le planning sans modifier les disponibilités. R-01 : un créneau de trente minutes accueille une seule réservation. R-02 : le client annule jusqu'à vingt-quatre heures avant le rendez-vous. Au-delà, l'application l'invite à contacter le responsable. Ces durées illustrent un choix de métier, pas une règle universelle. P-01 : la cliente consulte les créneaux libres, en choisit un, saisit ses coordonnées et confirme. La réservation apparaît dans le planning. Le créneau n'est plus proposé. Une confirmation est préparée pour la cliente ; un échec d'envoi doit être visible au responsable sans supprimer la réservation. CA-01 : étant donné un créneau libre, lorsqu'une cliente confirme avec des coordonnées valides, alors une réservation unique apparaît dans le planning et le créneau n'est plus proposé. CA-02 : lorsque deux clients confirment simultanément le même créneau, alors une seule réservation est acceptée. L'autre personne reçoit une explication et peut choisir un autre créneau. CA-03 : lorsqu'un collègue en lecture seule tente de modifier un créneau, alors l'action est refusée et les disponibilités restent inchangées, y compris lorsqu'il essaie d'accéder directement à l'action sans passer par son écran. Questions encore ouvertes : quelles coordonnées sont nécessaires ? Combien de temps les conserver ? Qui reçoit l'alerte si une confirmation n'est pas envoyée ? Comment corriger une erreur de réservation après le délai d'annulation ?