Cahier des charges

Cahier des charges et approche agile

Dans une approche agile comme Scrum, on ne travaille généralement pas avec un cahier des charges figé et complet au début du projet. Les besoins évoluent, et le backlog est ajusté au fur et à mesure.

Dans le cadre du projet intégrateur, on utilise tout de même un cahier des charges comme outil pédagogique. Il te permet d’avoir une vision globale de ton projet (contexte, objectifs, exigences, technologies, livrables), avant de découper tout ça en user stories et en tâches dans ton backlog.

Le cahier des charges que tu vas préparer n’est donc pas un document « gravé dans le marbre » : il pourra être ajusté au besoin, mais il sert de base de référence pour ton équipe et pour le client.

Structure proposée pour ton cahier des charges

Le modèle ci-dessous te propose une structure pour ton cahier des charges. Selon ton projet, certaines sections seront plus développées que d’autres, et tu pourras adapter le contenu au contexte.

1. Présentation du projet

1.1 Contexte

Décris l’environnement du projet : domaine, enjeux, problématique, utilisateurs ciblés, contexte académique ou organisationnel. L’objectif est de situer clairement « d’où vient » le besoin.

1.2 Objectifs

Indique les résultats que le projet doit atteindre. Tu peux formuler des objectifs spécifiques, par exemple :

• Permettre à un utilisateur de faire une action précise.
• Réduire ou optimiser un processus.
• Assurer la sécurité ou la fiabilité d’un aspect du système.

Tu peux aussi préciser des critères de performance qui seront importants (rapidité, fiabilité, qualité du code, qualité de l’interface, impact social, etc.).

1.3 Périmètre du projet

Définis clairement ce qui fait partie du projet et ce qui n’en fait pas partie.

• Ce qui est inclus : par exemple, développement de l’interface utilisateur, création d’un backend, tests de performance.
• Ce qui est exclu : par exemple, intégration avec certains systèmes externes, fonctionnalités avancées qui ne seront pas traitées dans ce cours.

2. Description fonctionnelle

2.1 Besoins et exigences métiers

Décris les besoins du client ou les exigences métiers auxquelles la solution doit répondre.

• Problématique à résoudre : quel problème ou besoin le projet cherche-t-il à adresser ?
• Utilisateurs cibles : qui utilisera la solution (utilisateurs finaux, administrateurs, clients…) ?
• Scénarios d’utilisation : exemples concrets de ce que les utilisateurs doivent pouvoir faire.

2.1.1 Diagramme de cas d’utilisation

Pour compléter la description des besoins, tu peux ajouter un diagramme de cas d’utilisation. Ce diagramme montre visuellement quels types d’utilisateurs interagissent avec le système et quelles fonctionnalités principales sont offertes.

Il permet de :

• donner une vue d’ensemble des fonctionnalités à implémenter ;
• clarifier qui fait quoi dans le système (acteurs et cas d’utilisation) ;
• faciliter la transition vers les user stories et le Product Backlog.

Ce diagramme peut être inclus dans le cahier des charges, même si tu travailles en agile, car il représente bien l’ensemble des fonctionnalités ciblées au début du projet.

2.2 Fonctionnalités principales

Liste les fonctionnalités que la solution doit absolument contenir. Chaque fonctionnalité importante doit être décrite clairement (par exemple : gestion des utilisateurs, enregistrement des transactions, génération de rapports, etc.).

2.3 Interface utilisateur

Donne les grandes lignes de l’interface graphique :

• Attentes en termes d’ergonomie (simplicité, intuitivité, adaptation mobile, etc.).
• Technologies recommandées pour l’interface (HTML/CSS, React, etc.).
• Éventuels wireframes ou esquisses d’écran pour illustrer l’organisation de l’interface.

2.4 Conditions d’utilisation

Précise dans quels environnements la solution sera utilisée (PC, mobile, navigateur, serveur spécifique, etc.) et les contraintes associées (connexion Internet, permissions, matériel, etc.).

3. Description technique

3.1 Technologies à utiliser

Indique les technologies principales qui seront utilisées :

• Langages de programmation pour le frontend, le backend, etc.
• Frameworks, plateformes ou bibliothèques recommandées ou imposées.
• Type de base de données envisagé.

3.2 Architecture du système

Décris l’organisation générale du système et de ses composants. Tu peux inclure :

• Un diagramme d’architecture ou une description textuelle claire.
• Le type d’architecture choisi (client-serveur, microservices, etc.).
• Un schéma d’intégration si l’application interagit avec d’autres systèmes.

3.3 Sécurité

Précise les exigences de sécurité importantes : protection des données, gestion des identifiants, communications sécurisées, rôles et permissions, etc.

3.4 Performance et scalabilité

Indique les attentes de performance et de capacité, par exemple :

• Temps de réponse attendu (ex. : le système doit répondre en moins de 2 secondes).
• Nombre d’utilisateurs ou de requêtes que le système doit supporter.

4. Planification et livrables

4.1 Phases du projet

Décris les grandes phases du projet (analyse, conception, développement, tests, déploiement, etc.) et les principales dates associées. Tu peux t’appuyer sur ton outil de planification (Gantt, calendrier, etc.).

4.2 Livrables attendus

Liste ce qui sera remis au client à la fin (ou à des jalons intermédiaires) :

• Code source, base de données, documentation technique ou utilisateur.
• Services opérationnels (ex. serveur web fonctionnel, déploiement accessible, etc.).
• Tout autre livrable spécifique demandé par le mandat.

5. Modalités de validation

Explique comment vous allez vérifier que la solution répond bien aux attentes, besoins et exigences du client.

• Tests d’acceptation utilisateur.
• Vérification de certaines fonctionnalités clés.
• Tests de performance ou de charge si c’est pertinent.

6. Conclusion

Termine le cahier des charges par un court mot de conclusion. Tu peux y rappeler les points importants, préciser certaines limites, ou ajouter des informations qui ne rentraient pas dans les sections précédentes.

Ce document servira ensuite de base pour définir vos user stories et construire progressivement votre backlog Scrum.

Télécharger le gabarit d'un cahier de charges générique

Tu peux accéder au gabarit du cahier des charges en cliquant ici :