Rédaction de cahiers des charges fonctionnels et techniques

1. Du besoin au document : Le rôle du Cahier des Charges

Après votre réunion de découverte, vous avez des notes, des idées, et une compréhension des objectifs du client. Le cahier des charges est le processus qui transforme cette compréhension en un document structuré et exploitable.

Il est essentiel de distinguer deux facettes de ce document :

• Le Cahier des Charges Fonctionnel (CdCF) : Il décrit ce que le système doit faire, du point de vue de l'utilisateur. Il traduit les besoins du client en fonctionnalités. C'est le "Quoi ?".
• Le Cahier des Charges Technique (CdCT) : Il décrit comment le système va être construit pour répondre aux besoins fonctionnels. C'est votre réponse d'expert technique. C'est le "Comment ?".

Ne pas formaliser ces aspects est la recette pour l'échec d'un projet. Pour bien comprendre les risques, je vous invite à regarder un court extrait vidéo.

Comme vous l'avez vu, le cahier des charges n'est pas une contrainte bureaucratique. C'est un outil de communication et de protection qui aligne la vision du client avec la réalité technique, tout en fournissant un cadre clair pour le développement.

2. La Structure d'un Cahier des Charges Efficace

Un bon cahier des charges doit être complet, clair et sans ambiguïté. Bien qu'il n'existe pas un modèle unique parfait, une structure éprouvée permet de s'assurer que tous les aspects importants sont couverts.

La vidéo suivante propose une excellente structure que nous allons adopter comme fil rouge.

En nous basant sur ce plan et en l'enrichissant avec d'autres bonnes pratiques, voici une structure solide que vous pouvez utiliser pour vos projets :

Structure Type d'un Cahier des Charges

1. Contexte et Objectifs du Projet

• Présentation de l'entreprise/client : Son activité, son marché, ses valeurs.
• Contexte du projet : Est-ce une création, une refonte ? Pourquoi ce projet est-il lancé maintenant ? Quel problème cherche-t-on à résoudre ?
• Objectifs : Que cherche-t-on à accomplir ? Utilisez la méthode SMART (Spécifique, Mesurable, Atteignable, Réaliste, Temporellement défini). Exemple : "Augmenter les ventes en ligne de 20% en 6 mois."
• Cible : Qui sont les utilisateurs finaux ? (Ex: clients du restaurant, administrateurs, etc.)

2. Périmètre et Définitions (Le Glossaire)

• Périmètre fonctionnel (MVP) : Quelles sont les fonctionnalités indispensables pour la première version (Minimum Viable Product) ?
• Hors-périmètre : Qu'est-ce qui est explicitement exclu de cette version ? (Ex: "Le système de réservation de tables sera développé dans un second temps.") C'est crucial pour éviter les malentendus.
• Glossaire métier : Définissez tous les termes spécifiques au projet ou au métier du client. Ne supposez jamais que tout le monde partage le même vocabulaire.

Pour approfondir ce point essentiel des définitions, la section suivante de la vidéo est très instructive.

3. Spécifications Fonctionnelles (Le "Quoi")
C'est le cœur du CdCF.

• Rôles utilisateurs : Listez les différents types d'utilisateurs (ex: Visiteur, Client authentifié, Administrateur).
• Liste des fonctionnalités par rôle : Pour chaque rôle, décrivez ce qu'il peut faire. Une bonne méthode pour cela est d'utiliser des User Stories, que nous verrons en détail dans la prochaine leçon. Pour l'instant, une liste d'actions suffit. Exemple pour le rôle "Client" : "Peut créer un compte", "Peut se connecter", "Peut consulter son historique de commandes".
• Modèle économique : Si applicable, comment l'application génère-t-elle de l'argent ? (Abonnements, publicité, etc.).

4. Spécifications Techniques et Contraintes (Le "Comment")
C'est votre domaine d'expertise, le cœur du CdCT.

• Contraintes techniques imposées : Langages, frameworks, SGBD, hébergement si le client a des exigences particulières.
• Interfaces externes : Le logiciel doit-il communiquer avec d'autres systèmes ? (API de paiement, CRM, services tiers...).
• Exigences non-fonctionnelles :
  • Performance : Temps de chargement des pages, nombre d'utilisateurs simultanés.
  • Compatibilité : Navigateurs et appareils cibles (desktop, mobile).
  • Sécurité : Security by Design. Ex: authentification, gestion des droits, protection contre les injections SQL.
  • Confidentialité : Privacy by Design. Conformité RGPD, gestion des données personnelles.
  • Accessibilité : Normes à respecter (WCAG).
  • Internationalisation : Le site doit-il être multilingue ?

L'article de la société Anakeen, bien que destiné aux logiciels d'entreprise, insiste sur des concepts que vous devez intégrer dans votre pratique pour un travail professionnel.

5. Aspects Graphiques et Ergonomiques

• Charte graphique : Logo, couleurs, typographies à utiliser.
• Arborescence du site : Un plan schématique des différentes pages et de leur hiérarchie.
• Wireframes ou maquettes : Si disponibles, des schémas basse-fidélité des écrans principaux pour définir la structure et l'emplacement des éléments.

6. Budget, Délais et Livrables

• Enveloppe budgétaire : Le budget alloué par le client.
• Calendrier : Date de livraison souhaitée et grandes étapes (jalons).
• Livrables attendus : Que devez-vous fournir à la fin ? (Code source, documentation, base de données, etc.).

Pour une vue très concrète de ce à quoi peut ressembler un CdC, l'article de Manager GO! propose un excellent modèle sous forme de tableau.

3. Mise en Pratique : Le Cahier des Charges de "Chez Antoine"

Reprenons notre cas pratique de la leçon précédente : le restaurant "Chez Antoine" qui souhaite un système de commande en ligne. Vous avez mené votre réunion de découverte et collecté les informations suivantes :

• Objectif : Réduire les erreurs et le temps passé au téléphone en permettant aux clients de commander et payer en ligne.
• Processus actuel : Commandes par téléphone, paiement sur place lors du retrait.
• Besoins fonctionnels : Menu en ligne, gestion d'un panier, paiement par carte bancaire, choix de l'heure de retrait, notification de la commande en cuisine, e-mail de confirmation pour le client.
• Contraintes techniques : Le système doit s'intégrer au site vitrine existant. Le budget est limité. Le gérant veut pouvoir mettre à jour le menu lui-même facilement.

Votre mission : À partir de ces notes, rédigez une ébauche des sections Spécifications Fonctionnelles et Spécifications Techniques du cahier des charges. Prenez 10 minutes pour structurer vos idées avant de consulter ma proposition ci-dessous.

Ma proposition de rédaction

3. Spécifications Fonctionnelles

• Rôles utilisateurs :

  • Visiteur/Client : Tout utilisateur accédant au site.
  • Gérant : Le propriétaire du restaurant.

• Fonctionnalités pour le rôle "Visiteur/Client" :

  • Consulter la carte des plats organisée par catégories (entrées, plats, desserts).
  • Voir le détail d'un plat (description, prix, photo, allergènes).
  • Ajouter/modifier/supprimer des plats de son panier.
  • Valider sa commande en fournissant son nom, email et numéro de téléphone.
  • Choisir une heure de retrait de la commande (parmi des créneaux proposés).
  • Payer la commande en ligne via carte bancaire.
  • Recevoir un email de confirmation de commande avec le récapitulatif et l'heure de retrait.

• Fonctionnalités pour le rôle "Gérant" (via une interface d'administration) :

  • Se connecter à un espace d'administration sécurisé.
  • Gérer la carte : ajouter, modifier, supprimer des plats et des catégories.
  • Marquer un plat comme "temporairement indisponible".
  • Consulter la liste des nouvelles commandes en temps réel.
  • Visualiser le détail de chaque commande (client, contenu, heure de retrait).
  • Marquer une commande comme "Prête pour le retrait".

4. Spécifications Techniques et Contraintes

• Architecture : Le système de commande sera un module intégré au site web statique existant. Il nécessitera une base de données pour gérer les plats, les commandes et les clients.
• Technologie (Proposition) : Backend en Java/Spring Boot exposant une API REST, base de données MySQL. Le frontend sera une petite application React (ou vanilla JS) s'intégrant dans la page existante.
• Hébergement : À définir avec le client. Nécessite un hébergement supportant Java et une base de données MySQL.
• Interfaces externes :
  • Paiement : Intégration de l'API Stripe pour le traitement sécurisé des paiements par carte bancaire.
  • Emailing : Utilisation d'un service d'email transactionnel (ex: SendGrid) pour garantir la délivrabilité des confirmations de commande.
• Exigences non-fonctionnelles :
  • Performance : Le chargement du menu doit être quasi-instantané (< 1s). Le processus de paiement ne doit pas excéder 3 secondes.
  • Sécurité : L'interface d'administration doit être protégée par mot de passe (haché avec BCrypt). Toutes les communications doivent se faire en HTTPS. Aucune information bancaire ne doit être stockée sur nos serveurs.
  • Confidentialité : Le traitement des données client (nom, email, téléphone) doit être conforme au RGPD. Une politique de confidentialité simple sera rédigée.
  • Ergonomie : L'interface de gestion de la carte doit être extrêmement simple pour être utilisable par le gérant sans formation technique.

Conclusion

Félicitations pour avoir franchi cette étape ! La rédaction d'un cahier des charges peut sembler fastidieuse, mais c'est l'un des investissements les plus rentables que vous puissiez faire en début de projet.

Les points clés à retenir :

• Le cahier des charges est un document de communication qui transforme les besoins du client en un plan d'action technique.
• Il doit clairement séparer le fonctionnel (le quoi) du technique (le comment).
• Une structure claire (Contexte, Périmètre, Specs Fonctionnelles, Specs Techniques...) est indispensable pour n'oublier aucun aspect crucial du projet.
• La précision est votre meilleure alliée : définissez les termes, listez ce qui est hors-périmètre et soyez explicite sur les contraintes.

Dans notre cahier des charges, nous avons mentionné les User Stories comme un moyen de décrire les fonctionnalités. C'est une technique puissante issue des méthodes Agiles. Dans la prochaine leçon, nous allons nous concentrer entièrement sur ce sujet : vous apprendrez à créer des user stories avec des critères d'acceptation clairs, ce qui vous permettra de décomposer le travail de manière efficace et de vous assurer que ce que vous développez correspond exactement aux attentes.