LE CAHIER DES CHARGES. La référence du projet

LE CAHIER DES CHARGES

La référence du projet

Nos objectifs pour la journée

● Comprendre ce qu’est un Cahier Des Charges

● Connaître les différentes étapes d’un projet

● Apprendre les éléments clefs qui constituent le CDC

● Pouvoir faire un travail d’analyse d’un site web

Le CDC est un document structuré

Le CDC est avant tout un document bien organisé, ses objectifs :

● Présenter le projet

● Clarifier les besoins (objet, cible, environnement, charte graphique)

● Définir les fonctions (les détailler)

● Déployer une maquette fonctionnelle visuelle

● Définir les contraintes techniques

● Proposer une feuille de route (un planning de livrables)

● Éventuellement chiffrer le travail (en temps en charges etc…)

Attention ! le CDC est un document contractuel à respecter lors d’un projet, il est

également un outil de communication entre le prestataire et l’équipe interne.

Les étapes d’un projet Web

1. Idée (client)

2. Etude de faisabilité

3. Recherche et choix d’un prestataire

4. Expression des besoins (interview prestataire->client) 5. Rédaction d’un CDC

6. Production du site

7. Livraison en test (parfois en plusieurs étapes)

8. Mise en production

Qualité, Coût, Délai

Tout projet doit équilibrer ces 3 notions 1. Rapide et pas cher (qualité dégradée) 2. Rapide et de bonne qualité (coût élevé)

3. Qualité élevé et pas cher (délais importants) La méthode agile :

‘Le bazar et la cathédrale’

Le CDC doit convaincre

Plusieurs types de lecteurs vont utiliser le CDC

Le CDC doit prendre en compte les rôles des interlocuteurs concernés.

● Le client (il faut qu’il le comprenne et qu’il puisse le valider)

● Les opérationnels (toute personne impliquée côté client sur le projet, commerciaux, comptables etc...)

● Les développeurs (le CDC sera la référence pour leur travail)

Un conseil, utiliser le temps ‘présent de l’indicatif’ dans le document, il implique mieux le lecteur et donne un mode affirmatif.

Se poser les questions : Qui va lire le CDC ?, qui va le valider ? qui va l’utiliser ?

Exemple : Le site est disponible en 3 langues à la place de ‘Le site sera en trois langues’

Par où commencer ?

1. Faire un plan : (comme à l’école) Exemple de plan :

A. Présentation du projet :

Il ne faut pas s’étendre à expliquer l’entreprise, le marché etc..ce n’est pas le but du CDC, la plupart des lecteurs connaissent l’entreprise, il faut le rappeler

brièvement mais très vite donner la fonction principale du projet (exemple: Site ecommerce, Extranet à usage des commerciaux etc..)

B. Description graphique et ergonomique :

C’est là que l’on va définir le style du projet en termes graphiques, les visuels : logo, images, les styles : couleurs, typos, inspirations, le découpage : types de zoning. Une rubrique qui est parfois déléguée à un graphiste qui présente des maquettes graphiques souvent très précises des pages au pixel près. Il doit alors fournir tous les éléments, calques et images nécessaires dans les bonnes résolutions.

○ Ergonomie, éléments cliquables, fonctionnalités interactives (ex: chat)

Exemple de plan

Exemple de plan de site :

Suite du plan

C. Description fonctionnelle et technique :

a. C’est la partie importante qui doit être bien comprise par le client, un peu comme la maquette et le plan de l’architecte, chaque fonction doit être décrite et détaillée pour qu’il n’y ait pas d'ambiguïté (exemple pour l’architecte : Toutes les portes s’ouvrent de la gauche vers la droite, exemple pour le chef de projet, tous les boutons de validation demandent une confirmation à l’utilisateur). On parle d’architecture du site.

b. Une maquette cliquable fonctionnelle appuyée sur un descriptif détaillé complète la maquette des templates, le lecteur comprend visuellement ce qui se passe et peut le vérifier écrit noir sur blanc. Exemple : le taux de TVA est modifiable par le back-office par le rôle admin, toutes les factures sont historisée avec leur taux de TVA au moment de la génération dans le dossier du client.

c. La/les sources de données doivent être décrites si possible afin de ne rien oublier (schéma de bases de données ou data-model)

d. A ce stade, on peut définir également, les rôles/permissions, la procédure d’authentification, les aspects de langage et de nomenclatures (listes prédéfinies, meta-données, thésaurus)

Suite du plan

C. Description fonctionnelle et technique (suite)

e. Afin de donner une idée des ressources nécessaires à mettre en oeuvre, il est également bon de parler, hébergement, tests, domaine, emails, backups, performances.

D. La feuille de route

Les lecteurs du CDC veulent avoir une idée du planning, quand est ce que cela commence, et quand cela se termine, montrer les étapes, donner des dates, des intervalles de temps et des

valeurs temps/homme. Ce n’est pas toujours facile d’être précis mais il faut essayer de l’être le plus possible, cela permet de se fixer des objectifs, de faire une évaluation précise, quitte à l’affiner parfois plus tard.

Ne pas négliger la période de tests dans la durée du projet.

exemple de maquette fonctionnelle :

Exemple de planning :

Ce qu’il faut apprécier

On rappelle que le CDC sert de référence avant et tout au long du projet, il est l’élément auquel on se réfère en cas de litige avec les demandeurs (donc contractuel), plus il est précis, moins il y a d’ambiguité entre vous et le client et plus vous savez où vous allez. Un bon CDC se fait à l’aide d’interviews, de

préférence, chez le client, des personnes concernées.

A priori, vous êtes le prestataire qui allez réaliser le projet (attention Je/nous/on/vous/ils il faut bien situer à qui on s’adresse et qu’il soit clairement établi qui est qui)

On rappelle que ce CDC doit être validé par le client avant de commencer le travail.

Mieux vaut mettre trop de détails que pas assez.

● Qui est responsable de la gestion du domaine, des backups, des intégrations ?

● Quel niveau de service ? délai d’intervention (SLA, y a t’il un contrat ?)

● Quel niveau de sécurité, comment sont gérés les mails (spam, blacklistage etc…)

Charge = Travail

Le CDC exprime le travail nécessaire à la réalisation d’un projet technique.

Il défini les objectifs du projet (Institutionnel, site marchand, catalogue, intranet, extranet, WebApp, API, service)

Il doit donc être complet, structuré, clair, précis, n’oublions pas son caractère contractuel. C’est un travail collectif.

Si certains éléments ne sont pas connus au moment de la rédaction, il faut en faire mention et évaluer l’impact sur le projet.

Certains éléments peuvent faire partie du CDC comme le pricing du projet et ce qui concerne le référencement. (dépend de la taille de l’entreprise).

A la fin de la rédaction du CDC il faut se poser la question : Ai-je la majorité des éléments nécessaires pour construire le site ?

Petite liste de questions à se poser pour le CDC

1. Quelles actions doivent être menées pour faire mon CDC (todo list) ? 2. Y a t’il un budget à prendre en compte ?

3. Qui sont les interlocuteurs ?

4. Quelles sont les ressources nécessaires (machines, soft, personnes) ? 5. Quel est le timing ?

6. Quel est le niveau de détail demandé ? 7. Quel est le niveau de sécurité ?

8. Que se passe t’il après ? 9. Qui décide ?

10. Qui organise ? 11. Qui rédige ?

12. Qui va lire le CDC ?

Caricature

Les outils pour le CDC

Dessin de l’arborescence, maquette fonctionnelle

● GlooMaps

● Visual Paradigm

● Balsamiq

● Photoshop

● Figma

Exercices proposés

● Analyser le site pâtisseries : lien

● Faire une fiche projet de vos propres projets (nature, objectifs, description fonctionnelle)

● Décrire les fonctions :

○ d’un backoffice pour un site eCommerce

○ D’un site de rencontre