Cahier Des Charge Site Web

Enseignant - formateur Denis Christine
WEB / PAO formation@inaden.org
Cahier des charges d’un site Web

Tous droits d'utilisation de ce cours est soumis à demande p. 1 / 47

d'autorisation

Table des matières
Partie 1 : Descriptif du projet................................................................................................................................................................................4

Définition et structure d’un cahier des charges........................................................................................................................................... 5
Introduction........................................................................................................................................................................................................................ 5
Méthodologie..................................................................................................................................................................................................................... 7
Définition du projet........................................................................................................................................................................................................... 8
La définition générale du projet............................................................................................................................................................................. 8
Planning prévisionnel................................................................................................................................................................................................... 9
Le benchmark, c’est-à-dire l’étude de la concurrence................................................................................................................................ 9
Le plan de communication.................................................................................................................................................................................... 10
Le positionnement du projet dans l’entreprise et son fonctionnement technique, humain et financier............. 10
La définition de la cible............................................................................................................................................................................................ 12
La définition des fonctionnalités côté internaute et côté du commanditaire....................................................................... 12
Les chemins utilisateurs......................................................................................................................................................................................... 24
La projection de son évolution............................................................................................................................................................................ 25
Méthodologie générale............................................................................................................................................................................................. 26
Partie 2 : Graphisme et ergonomie................................................................................................................................................................27

La navigation..................................................................................................................................................................................................................... 28
Parcours utilisateur.................................................................................................................................................................................................... 28
Les différents éléments de navigation........................................................................................................................................................... 28
Conclusion........................................................................................................................................................................................................................ 32
Zoning, wireframe, ergonomie et interactivité............................................................................................................................................ 33

Les types de pages..................................................................................................................................................................................................... 33
Le zoning........................................................................................................................................................................................................................... 34
Le responsive design................................................................................................................................................................................................. 34
Le wireframe......................................................................................................................................................................................................................36
L’interactivité................................................................................................................................................................................................................... 38
Le graphisme..................................................................................................................................................................................................................... 42
La charte graphique................................................................................................................................................................................................... 42
La maquette..................................................................................................................................................................................................................... 43
d'autorisation

Partie 3 : Les aspects techniques..................................................................................................................................................................44

L’hébergement................................................................................................................................................................................................................... 45
Le serveur.......................................................................................................................................................................................................................... 45
Le nom de domaine.................................................................................................................................................................................................... 46
Les autres services....................................................................................................................................................................................................... 47

Services connexes...................................................................................................................................................................................................... 47
Algorithmes..................................................................................................................................................................................................................... 47
Base de données.......................................................................................................................................................................................................... 47

d'autorisation

Partie 1 : Descriptif du projet ::
Partie 1 : Descriptif du projet

d'autorisation

Partie 1 : Descriptif du projet :: Définition et structure d’un cahier des charges :: Introduction
Définition et structure d’un cahier des

charges
Introduction
Un cahier des charges est un document permettant de construire un projet.
Dans le cas d’un site Web, ce cahier des charges comporte trois parties distinctes :
• Une partie liée à la définition du projet

• Une partie liée à l’ergonomie et au Design
• Une partie liée à la technique
Vous devez pouvoir construire intégralement la première partie, au minimum participer à la deuxième et
plutôt pouvoir la concevoir intégralement, et analyser la troisième.
La première partie du cahier comporte :

• La définition générale du projet
• Planning prévisionnel
• Le benchmark, c’est-à-dire l’étude de la concurrence
• Le plan de communication
• Le positionnement du projet dans l’entreprise et son fonctionnement technique, humain et finan-
cier
• La définition de la cible
• La définition des fonctionnalités côté internaute et côté du commanditaire
• La définition des données présentées et acquises ainsi que leur organisation (arborescence et
passerelle entre les données).
• Les chemins utilisateurs
• La projection de son évolution
La deuxième partie comporte :

• Le zoning et l’ergonomie
• Le design et la charte graphique
• La visualisation des chemins utilisateurs

d'autorisation

Partie 1 : Descriptif du projet :: Définition et structure d’un cahier des charges :: Introduction
Le zoning est le découpage des grands blocs (zones) du site, c’est une première approche de l’ergono-
mie. Une fois cette approche effectuée chaque partie est remplie des éléments qui la composent : c’est
la mise en place des wireframes, seconde partie de l’ergonomie. Un wireframe est donc la mise en place
des éléments dans chaque bloc du zoning, et de ces transformations ou réactions selon le comporte-
ment de l’internaute — qu’est-ce qu’il se passe quand je passe ma souris sur un élément réactif, quand
j’entre dans un formulaire… Le wireframe détermine donc les éléments statiques et les éléments inte-
ractifs et dépend de différents états tant côté internaute que côté administrateur (identifié/non identifié,
période promotion/période normale…).
Cette deuxième partie doit comporter une double étude :
• Celle pour ordinateur

• Celle pour smartphone et tablette
On appelle responsive design, l’adaptation de l’interface au type de machine et de navigateur qui per-
mettent la fréquentation du site. On parle aussi de media query. Dans le premier cas, on se place plutôt
exclusivement sur la partie-écran de la machine. Dans le second on pousse aux différents éléments
connexes comme l’imprimante.
Enfin, les chemins utilisateurs représentent le parcours qu’un internaute doit faire pour accéder à une
action et la mener à son terme. Cela représente souvent les actes d’achat, d’inscription, d’identification,
d’abonnement ou d’accès à certaines fonctionnalités selon le type d’application que propose le site.
Chaque fonctionnalité doit avoir un chemin et sa définition, ou bien dans le wireframe si cette fonction-
nalité ne nécessite pas de changement de page, ou de connexion, ou bien dans les chemins interpage si
cette fonctionnalité nécessite un changement de page.
La troisième partie doit comporter :

• Le type d’hébergement de votre site
• La façon d’utiliser un ou plusieurs noms de domaine
• La mise en place du protocole HTTPS
• L’arborescence des dossiers sur le serveur
• La liste des langages de programmation utilisés et leur fonction (qu’est-ce qui est utilisé pour quoi)
• La liste des API, open data et services externes utilisés ainsi que leur coût et leur protocole d’utili-
sation
• La description informatique des parcours utilisateurs, c’est-à-dire une partie de « l’algorithme ».
• Les frameworks et/ou CMS utilisés et leurs éventuelles modifications
• Les phases et le temps de développement, c’est-à-dire le planning final
• Des gabarits HTML de chaque type de page
d'autorisation

Partie 1 : Descriptif du projet :: Définition et structure d’un cahier des charges :: Méthodologie
Méthodologie
Il existe plusieurs approches pour la mise en place d’un cahier des charges. Elles dépendent du type
de projet, de la façon de travailler de chacun, de la chaîne d’intervenant… Néanmoins, il est possible de
donner quelques règles de bases.
La première est qu’il est pour ainsi dire impossible de travailler de façon continue en suivant les points
de présentation dans l’ordre présenté dans l’introduction. Par exemple, certains projets vont nécessiter
de commencer par le modèle de données quand d’autres vont plutôt nécessiter de commencer par la
description des fonctionnalités. Et là, parfois ce sera par celle du front-office, et pour d’autres parts celle
du back-office.
Il est, en règle générale, avantageux de prendre des notes sur chacun des points et de les compiler
quand on commence à être suffisamment avancé, car il est nécessaire de faire tout au long de la mise
en place du cahier des charges un rapprochement entre le modèle de données et les fonctionnalités,
qu’elles soit back-office ou front-office.
D’autre part, il faut garder à l’esprit que si vous êtes spécialiste dans votre domaine, votre commandi-
taire l’est dans le sien. Il est donc important de savoir l’écouter pour parvenir à faire la synthèse de votre
expertise et de la sienne. Même s’il arrive que le commanditaire ait apparemment de mauvaises idées,
soient parce qu’elles sont inutiles, soit parce qu’elles ne sont pas adaptées au Web, il est important de
les prendre en compte et de les reconsidérer à l’aune de son expertise.
À noter que la partie Wireframing est, en règle générale, une bonne façon de vérifier le cahier des charges
en visualisant l’emplacement et le comportement des fonctionnalités et des données, néanmoins, il
arrive que pour penser le projet, certaines personnes commencent par poser des esquisses de l’inter-
face. Ce préwireframe peut en effet permettre de fixer les idées. Dans ce cas, il sera quand même néces-
saire de reconsidérer cette étape une fois le cahier des charges rédigé.

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: La définition générale du projet
Définition du projet
La définition générale du projet

La définition du projet doit être claire et concise. En quelques phrases (voire une phrase) elle doit donner
le thème de l’activité et le rapport à l’entreprise, c’est-à-dire : comment le site Web se positionne dans la
politique générale de la société.
• Exemple 1 : site de vente de vêtement présentant les nouvelles collections et les avis client. Le site
est une vitrine de la société et mettra en avant l’aspect créatif de notre démarche.
• Exemple 2 : site d’accès à un coaching pour un maintien ou une remise en forme. Le site permettra
aux internautes de suivre un programme de gymnastique ne nécessitant aucun accessoire autre
que ceux que l’on peut trouver chez soi. Le site est basé sur une série de vidéo qui sera enrichi au
fur et à mesure du temps.
Vous pouvez définir ce projet dans l’historique de l’entreprise, cela permet d’ailleurs souvent de le pré-
ciser. La création d’une application Web provient souvent ou bien de l’évolution de l’entreprise, ou bien
d’une nécessité commerciale ou bien d’une démarche de prestige. Il est important de comprendre la
démarche initiale. Il est souvent plus simple d’aborder la création d’un site Web d’une entreprise jeune,
voire en création, que celle d’une entreprise possédant déjà une histoire.
En effet, il est nécessaire de positionner l’application Web dans le contexte technique et humain de
l’entreprise. Qui va gérer le contenu du site ? Qui va prendre en charge la maintenance ? Quel rapport
le site entretient-il avec l’environnement informatique de la structure… ? Ce ne sont pas des questions
subsidiaires, mais des questions importantes. Dans le cas des activités commerciales, il est important
d’établir le rapport existant entre le CRM de l’entreprise et la boutique en ligne. En effet, une boutique
Web est une boutique à activité continue et il est difficile, surtout si celle-ci « marche bien » de pouvoir
la surveiller 24/24 ; or le CRM existant gère les stocks, la clientèle, la facturation et la boutique en ligne
a besoin des mêmes paramètres. Il est donc important de penser le rapport existant entre l’ancien et le
nouveau système, soit par remplacement, soit par synchronisation synchrone ou asynchrone.
Si le chargé de projet Web connait bien son domaine d’activité, il ne connait pas nécessairement le
métier et l’activité de son commanditaire. En cela, il est nécessaire de mener une « enquête » pour bien
comprendre en quoi consiste le produit, quelle est la clientèle et quelles sont les modalités d’achats ou
de pratique, quel est le mode de fonctionnement du commanditaire et quelles sont ses différences avec
ses concurrents ?

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: Planning prévisionnel
Planning prévisionnel
En début de projet, le planning ne peut être que prévisionnel. En effet, si vous posez un diagramme de
Gant sans avoir une connaissance réelle de tout ce qu’il y a à faire et des difficultés de développement
que vous allez rencontrer, il va être difficile d’évaluer avec justesse les temps de développements réels
que vous allez rencontrer.
Aussi, soyez large et informez bien vos commanditaires que ce planning est prévisionnel et sera rendu
définitif en fin de cahier de charges.
Idem pour le devis. S’il est des postes comme la charte graphique (si elle n’existe pas) qui peuvent être
estimées de façon précise, le développement, l’intégration sont plus difficiles à évaluer sans avoir une
vision claire du projet. Vous pouvez donc agir en deux temps pour le devis ou établir une clause de
reprise de devis une fois le cahier des charges fini.
Le benchmark, c’est-à-dire l’étude de la concurrence

Selon les cas, il est intéressant de faire une étude de la concurrence. Dans le cas de la création d’un site
Web, cette étude est relative aux sites des concurrents sur les points suivants :
• Environnement graphique
• Structuration de la navigation et de l’arborescence
• Placement SEO et relevé des expressions dans les pages sortant sur les moteurs de recherches
• Fonctionnalité particulière
• CGU/CGV
• Politique éditoriale
• Newsletter et réseaux sociaux
L’intérêt du benchmark est aussi d’avoir une première approche du SEO. En effet, le fait de faire la
recherche de la concurrence permet d’identifier les occurrences d’expression et de mots-clés, le type et
l’utilisation des métadonnées, la structure HTML.

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: Le plan de communication
Le plan de communication
Le plan de communication ne fait pas à proprement parler du cahier des charges. Il peut être annexe ou
traité de façon entièrement autonome, néanmoins, le plan de communication est très lié au planning
de mise en place du site, aussi, il est important de le prendre en compte s’il existe. En effet, la commu-
nication liée à la mise en place d’un site Web se prépare. Elle doit se faire avant, pendant et après. Il
faut relier la création du site à une communication efficace afin de pallier à la difficulté que représente
la découvrabilité d’un site Web, dont le référencement n’est qu’un des aspects. Un projet Web doit donc
s’accompagner d’un projet de communication couvrant les trois périodes.
Le positionnement du projet dans l’entreprise et son

fonctionnement technique, humain et financier
Lorsque vous concevez un site Web, il est important de le replacer dans le contexte technique, humain
et financier de l’entreprise.
Le contexte humain
Une fois le site livré, il est important que quelqu’un puisse le faire vivre. Le référencement nécessite un
flux de contenu régulier qu’il sera nécessaire de produire. Il faut donc expliquer aux commanditaires
les besoins techniques de la ou des personnes qui vont s’occuper du site. Ces personnes devront com-
prendre l’interface d’administration, savoir rédiger pour le Web et comprendre l’optimisation SEO à
travers l’utilisation des balises sémantiques lors de la mise en page, savoir retoucher images et éven-
tuellement vidéos…
Selon la volonté du commanditaire, elles devront aussi savoir faire les mises à jour du CMS, de ses plug-
ins et éventuellement du serveur, ainsi que les différentes sauvegardes (fichiers et BDD) du site.
Il est nécessaire d’aborder cette problématique pour, si personne n’est capable d’effectuer ces opéra-
tions, intégrer dans l’aspect financier le coût des interventions.

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: Le positionnement du projet dans l’entreprise et son fonctionnement technique, humain et financier
L’aspect technique : infrastructure informatique
Le site Web est un outil informatique qui possède ses langages et un certain formatage des données.
Or, et principalement dans le cas des boutiques en ligne, si le commanditaire possède déjà une boutique
physique, il est important que celle-ci et son pendant virtuel soient en communication notamment pour :
• L’intégration des anciens et nouveaux clients de l’une à l’autre

• La gestion des stocks
• Les problématiques de facturation, de devis et de paiement
Or, selon les outils existants, il peut être difficile de mettre en communication la boutique en ligne avec le
CRM utilisé pour des raisons de structure réseau, d’incompatibilité des formats de fichiers ou d’incom-
patibilités applicatives.
Ce dialogue entre les outils peut s’effectuer :
• Manuellement, avec le risque que cela pose en termes de gestion de stock et l’ensemble de ressai-
sies nécessaire à l’intégration de la clientèle et des aspects comptable.
• Automatiquement ou bien de façon asynchrone avec les mêmes risques en termes de gestion des
stocks. Le plus souvent, les techniques asynchrones sont mises en place en raison de nécessité
de « moulinnettes » permettant de rendre compatible le système de fichiers entre les deux outils.
• Automatiquement de façon synchrone, avec ou sans moulinettes pour la compatibilité des fichiers.
Il est important de poser cette problématique dès le début de la réflexion sur les fonctionnalités, notam-
ment back-office du site. Cette problématique est à la base du bon fonctionnement commercial et comp-
table de l’entreprise. Dans le cas d’une société nouvelle, il est souvent préférable d’incorporer les CRM au
site afin d’éviter toute incompatibilité entre les deux fonctions.
Le contexte financier
Même s’il est parfois difficile de définir un devis précis lors de la mise en place d’une étude de création
de sites Web, il est souvent facile d’avoir une idée estimative globale du coût final. Il est important de
comparer ce coût aux possibilités financières de l’entreprise. Cela permet d déterminer rapidement si
l’idée initiale du projet est compatible avec le potentiel financier, et éventuellement de définir la mise en
place du site en plusieurs temps, avec, par exemple, la mise en place d’une partie des fonctionnalités
dans un premier temps, et dans un second temps, la mise en place de fonctionnalités complémentaires,
non nécessaire pour une première exploitation.

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: La définition de la cible
La définition de la cible
La définition de la cible présente le type de client que le site cherche à attirer. La cible est définie par :
• Le sexe (homme, femme, indifférent, autre)

• La tranche d’âge
• La catégorie socioprofessionnelle
• Le niveau culturel
• Et toutes autres caractéristiques nécessaires s’il y a lieu d’être comme les goûts, l’orientation poli-
tique ou religieuse, un domaine particulier culturel, artistique, sociologique…
La cible peut évoluer selon les modes et le mouvement des tranches d’âge. Une cible jeune peut rester
une cible, même une fois qu’elle a vieilli. Selon l’activité et l’orientation du site, il est parfois nécessaire de
concevoir une cible étendue ou très précise. Ce n’est donc pas toujours une évidence et la réflexion sur
la cible est un réel travail de réflexion sur l’activité.
Il faut aussi avoir à l’esprit que la cible peut être indirecte. Le produit ou le service s’adresse à des enfants
ou à des personnes âgées, mais ce n’est pas forcément eux qui vont être les clients, mais les parents
des premiers ou les enfants des seconds. Ou encore, vous décidez de faire un site qui propose à des
hommes sans imagination de les aider à faire des cadeaux à leur compagne, le produit s’adresse aux
femmes, mais la cible est les hommes…
La définition des fonctionnalités côté internaute et

côté du commanditaire
Il est souvent nécessaire de définir les fonctionnalités avant de définir les données dans la mesure où,
ce que le site propose, c’est un ensemble de fonctionnalités. Mais il faudra revenir sur les fonctionnalités
une fois les données définies, car selon leurs définitions, certaines fonctionnalités devront être corri-
gées ou adaptées, naîtront des données (émergence), voire devront être abandonnées. Ainsi la définition
des données et des fonctionnalités relève d’un aller-retour jusqu’à ce que leur rapport soit cohérent.
Néanmoins, pour certains projets, il est parfois préférable de définir le modèle de données pour envisa-
ger les fonctionnalités que l’on va mettre en place.
Comme déjà signaler dans ce cours, outre les fonctionnalités définies par les services proposés, il est
nécessaire de repositionner le site Web dans l’ensemble de systèmes informatiques (systèmes d’infor-
mation) de la société. Le système informatique possède des données (identification de client, facturation,

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: La définition des fonctionnalités côté internaute et côté du commanditaire
stock…), or, ces données peuvent et parfois doivent être utilisées par le site, surtout dans le cadre d’une
boutique en ligne. Il est donc important de savoir comment relier les données du site avec celles du SI à
travers des fonctionnalités de mise à jour et de consultation dans les deux sens.
Pour toutes les fonctionnalités de services du site, il est important d’en établir le profil à travers les
questions :
• Nécessité ou non d’identification

• Quelles données sont relatives à cette fonctionnalité
• Quels chemins utilisateur et accès
• Quel suivi possible de la fonctionnalité
• Quel résultat y compris en cas d’échec
• Gratuité ou non
Et bien sûr un descriptif précis de la fonctionnalité elle-même, tant dans son processus que dans son
interface, même si le wireframe sera là pour en poser l’ergonomie. Ce descriptif précis des fonctionna-
lités doit donc comporter un descriptif détaillé du fonctionnement de l’interface, des notifications ou
emails automatiques qui sont envoyés, des nécessités de validation des actions… On peut aussi y ratta-
cher les données nécessaires et leurs différents traitements.
Enfin, il est bien sûr nécessaire de distinguer les fonctionnalités côté internaute des fonctionnalités
côté administration. Vous pouvez être devant un projet avec peu de fonctionnalité côté internaute, mais
beaucoup côté administration. Par exemple, je veux faire un site d’information sur un secteur d’activité
et j’aurais côté internaute un bon moteur de recherche, quelques fonctionnalités de tri et la possibilité de
contacter les administrateurs du site… mais de leur côté on peut vouloir avoir une grande modularité de
la home page, une possibilité d’automatisation du traitement des images, l’intégration dans les pages
de fichiers PDF, WORD ou autre possédant un lecteur interne au site… Une tendance est de croire que le
back-office relève d’une évidence : je veux gérer mon site ! Si cette évidence est triviale, il n’en reste pas
moins que cette gestion peut impliquer des choses très différentes.
Vous devez aussi établir les fonctionnalités automatiques de votre site, notamment toutes les vérifica-
tions qui peuvent être demandées et les notifications qui les suivent. Dès lors que vous définissez des
abonnements, des fonctionnalités de promotions ou toutes autres fonctionnalités liées à des dates, il
est nécessaire de présenter ces automatisations et leur mode de fonctionnement.

d'autorisation

Services externes
La définition des fonctionnalités passe aussi par les liens du site Web et de services ou prestataires
externes comme les inscriptions et envois de mailing, par les services de tracking et leur rapport avec
les CRM (selon les actions de l’internaute quelle action commerciale je dois faire ou automatiser), par les
services d’identification (SSO, identification par service tiers — Facebook, Google, LinkedIn…).
Fonctionnalités communes à l’ensemble des projets
Pour les boutiques en ligne, mais aussi pour les sites présentant un grand nombre d’informations, il est
nécessaire de penser les fonctionnalités de tri et de recherche avancée. Le moteur de recherche est une
fonctionnalité commune à l’ensemble des sites, ce qui diffère c’est la présence ou non d’un système de
tri et/ou de classement des résultats, système que l’on peut retrouver, ou non, dans d’autres types de
pages du site.
Bien entendu, la navigation est une fonctionnalité primordiale du site et présente dans l’ensemble des
projets. Elle sera détaillée dans la partie wireframe de ce cours.
L’identification pour l’administration du site est aussi une fonctionnalité incontournable. Elle repose prin-
cipalement sur différents niveaux de pouvoir d’administration qui seront décrits dans la partie modèle
de données de ce cours.
Autre fonctionnalité inhérente à tout projet : le formulaire de contact. Plutôt que de mettre une adresse
mail qui risque d’être découverte par les robots spammers, mettez un formulaire de contact, mais faites
en sorte que l’internaute reçoive une copie de son message afin de garder une trace de son contact.
Indiquez-lui clairement que le message est envoyé. Le formulaire de contact est important aussi dans la
mesure où une partie des internautes utilisent des interfaces mail en ligne (et non des logiciels de mail
sur leur ordinateur) et que si vous mettez simplement une adresse mail, cela les oblige à aller sur cette
interface pour vous contacter, ce qui peut réduire le nombre de contacts que vous aurez.

d'autorisation

La définition des données présentées et acquises ain-

si que leur organisation (arborescence et passerelle entre les données)
On distingue deux branches pour les données :
• Les données que l’on présente (propose) à l’internaute

• Les données que l’on récolte de l’internaute ou de sa navigation
Les données sont le cœur de votre site. Sans données, pas, ou presque pas de fonctionnalités pos-
sibles. En effet, une fonctionnalité repose sur l’émission, la réception, le transfert ou la transformation
de données. Il est donc important de bien préparer cette partie du cahier des charges, car les fonction-
nalités, la navigation, et une partie de la monétisation vont dépendre d’elles.
D’un point de vue général l’ensemble des données et de leur relation va être à la base d’un système d’in-
formation, c’est-à-dire d’un système permettant d’établir les relations que les données ont entre elles,
et c’est un problème complexe. Dans les deux branches de données, certaines vont avoir des relations,
d’autres n’en auront pas. Il va donc falloir établir non seulement chaque champ de données, mais les
passerelles entre elles afin de pouvoir les recouper, les analyser ou les distribuer selon des choix stra-
tégiques. Néanmoins, lorsque l’on pose le modèle de données, on ne distingue pas spécialement les
données récoltées des données proposées sinon à travers les outils qui vont permettre leur manipu-
lation. En effet, on va souvent faire appel à des outils externes notamment pour le tracking, mais aussi
éventuellement pour l’identification si vous utilisez un système externe type SSO1, ce qui induit au niveau
de l’interface une différence fondamentale : l’externalisation de l’outil.
Toutes ces données vont devoir être enregistrées dans une ou plusieurs bases… de données, et la défi-
nition de ces données, les relations qu’elles ont entre elles vont déterminer la façon dont ces bases vont
être construites. Une base de données est ainsi un ensemble de tables possédant des lignes et des
colonnes, ces tables ayant entre elles des relations. Une ligne est un élément, une colonne une pro-
priété de cet élément.
Pour une propriété donnée, il est important de se poser la question suivante : mon élément ne pos-
sède-t-il qu’une propriété de ce type ou peut-il en posséder plusieurs ?
1 L’authentification unique (en anglais Single Sign-On : SSO) est une méthode permettant à un utilisateur d’accéder à plusieurs applications
informatiques (ou sites Web sécurisés) en ne procédant qu’à une seule authentification. https://fr.wikipedia.org/wiki/Authentification_unique

d'autorisation

Dans le premier cas, si cette propriété est unique, elle va pouvoir figurer dans la même table et avoir sa
colonne. Dans le second cas, il va falloir utiliser une autre table pour définir les propriétés de ce type et
une troisième pour mettre en relation l’élément et ses propriétés.
Une autre question à se poser sur un élément est : est-ce que cet élément est une propriété commune
à plusieurs autres éléments. Par exemple dans le cas d’une boutique de vêtement qui possède plu-
sieurs marques, une marque est un élément, et cet élément va être la propriété de différents vêtements
de nature différente (pantalon, pull, chemise…). Toutes ces propriétés qui peuvent prendre des valeurs
multiples et qui sont attribuées à plusieurs éléments nécessitent en règle générale leur propre table.
Mais surtout, elles nécessitent en règle générale de disposer dans l’interface d’administration d’un outil
de gestion (ajout, modification et éventuellement suppression).
Enfin, pour pouvoir identifier correctement chaque élément, celui-ci doit avoir un identifiant unique que
l’on appelle une clé dans la BDD.
Pour exemple, vous voulez associer à un vêtement sa marque et sa couleur. Or un vêtement peut avoir
plusieurs couleurs et votre magasin peut avoir plusieurs marques. Vous allez donc avoir une table avec
vos vêtements, une table avec vos marques, une table avec les couleurs et une table de relation entre
les marques et les couleurs.
Table vêtement
Identifiant Nom Marque (le chiffre correspond à l'identi-

fiant de la marque)
1 Chemise truc 1
2 Chemise machin 2
3 Pantalon Bidule 1
Table marque
Identifiant Nom
1 La marque chose
2 Une autre marque
Table couleur
Identifiant Couleur Descriptif

1 Taupe Entre le gris et le beige
2 Rouge sang Rouge écarlate

d'autorisation

Table de relation vêtement/couleur
Identifiant Vêtement (le chiffre correspond à l'iden- Couleur (le chiffre correspond à l'identi-
tifiant du vêtement) fiant de la couleur)
1 1 1
2 1 2
3 2 1
4 3 2
Cet exemple nous montre que la chemise truc est de la marque chose et est rouge et taupe. Que les
deux autres vêtements n’ont qu’une couleur.
Le fait de mettre ainsi dans des tables séparées les propriétés que l’on va attribuer de façon multiple
et/ou à plusieurs éléments, va permettre, non seulement au niveau de l’administration de votre site
Internet, d’ajouter ou de modifier facilement ces propriétés, mais aussi de créer des filtres de recherches
pour l’internaute, lui facilitant sa recherche.
Le modèle de données
Le but n’est pas pour vous d’établir le plan de la base de données, et l’explication précédente n’a pour but
que de vous donner un aperçu de la façon dont cela fonctionne. Bien entendu, si vous êtes accoutumé
aux BDD, rien ne vous empêche d’en faire le plan, néanmoins, avant de faire ce plan et c’est que vous
devez pouvoir faire dans tous les cas, vous devez établir le modèle de données.
On peut établir trois types de données :
• Les éléments : ce sont les éléments de base de la raison d’être d’une BDD comme des objets pour
une boutique, des personnes pour une identification…
• Les propriétés : si les propriétés peuvent être des éléments (par exemple des marques dans
l’exemple précédent) ce sont des éléments servant à qualifier (donner une propriété) à d’autres
éléments.
• Les relationnelles : elles permettent de mettre en place les relations entre éléments et propriétés
ou éléments et autres éléments.
Les deux premiers types font partie intégrante du modèle de données de données. Le troisième type lui,
va être déterminé par la façon dont on va établir les deux premiers.
Il faut donc définir les propriétés de vos objets par listes ou tableaux en notifiant si une propriété est
unique ou multiple, son mode de saisie ou d’accès (champ texte, menu déroulant, case à cocher… et
d'autorisation

pour certaines données l’automatisation de sa valeur [par exemple date d’inscription]), son obligation ou
non, et éventuellement son genre (texte, texte formatable, nombre, valeur booléenne…).
Cette réflexion va permettre de déterminer si une propriété d’objet va faire l’objet d’une utilisation parti-
culière et surtout, s’il est nécessaire de prévoir dans les fonctionnalités back-office si elles doivent être
administrables ou non.
Pour exemple, vous voulez utiliser des vidéos issues de YouTube dans votre contenu. Deux choix se pré-
sentent à vous, soit vous voulez intégrer ces vidéos dans votre contenu principal, auquel cas vous allez
les intégrer dans le corps de celui-ci à l’aide des outils d’intégration de média de votre interface d’admi-
nistration. Néanmoins, dans ce cas, vous ne pouvez pas les extraire pour en disposer dans une utilisation
particulière (par exemple, les regrouper thématiquement dans une page spécifique). Soit au contraire
vous voulez les taguer à l’aide de mots-clés pour pouvoir les regrouper dans une page indépendante,
auquel cas il faut que chaque vidéo soit notifié dans un champ spécifique de la table ad hoc de votre BDD
afin de pouvoir y attribuer des mots-clés et de pouvoir les ressortir pour des utilisations spécifiques.
Il est donc important lors de cette réflexion sur les propriétés d’un élément (ces propriétés pouvant
elles-mêmes être un élément) de faire le rapprochement entre celles-ci et les fonctionnalités qui vont les
utiliser, tant du côté front-office que back-office.
Exemple de modèle de données
Prenons le cas d’une personne s’incrivant sur votre site. Sous forme de liste, vous pouvez présenter le
modèle de données de la façon suivante :
• Identifiant : unique, obligatoire, autoincrémentable (clé de la table)

• Nom : unique, obligatoire, saisie par champ textuel simple
• Prénom : unique, obligatoire, saisie par champ textuel simple
• Email : servira de login, unique, obligatoire, champ de texte email. L’email sera vérifié par l’envoi
d’un mail comportant un lien cliquable pour validation de l’adresse. ATTENTION : il sera possible
pour l’internaute de renseigner un autre email s’il veut recevoir sa newletter sur une autre adresse
mail.
• Password : unique, obligatoire, champ de texte password pouvant être rendu visible pour vérifi-
cation, doit comporter 12 caractères dont lettre majuscule et minuscule, chiffre et au moins un
caractère spécial. Doit donc comporter une vérification.
• Téléphone : multiple, non obligatoire et pouvant être qualifiée par un type de téléphone (mobile
perso, mobile fixe…) cette qualification sera accessible depuis un menu déroulant2.
2 Noter que cela entraine qu’il faudra dans le modèle de données avoir « une table » type de téléphone et que son contenu devra être ad-

d'autorisation

• Avatar : non obligatoire et unique. Si l’avatar n’est pas défini par l’internaute, un avatar par défaut
lui sera attribué. Image à télécharger de type, JPG, PNG ou GIF de 300px de côté maximum. En
cas de téléchargement d’une image plus grande, un traitement automatique ramènera l’image à
la bonne taille.
• Texte de présentation : facultatif, unique, texte formatable permettant de mettre du gras, de l’ita-
lique et des listes
• Date d’inscription : automatique, unique, sous forme aaaa/mm/jj hh/mm/ss
• Date de validation du compte : automatique, unique, sous forme aaaa/mm/jj hh/mm/ss
Bien évidemment, il est possible de donner d’autres propriétés comme la date de fermeture de compte,
une ou plusieurs adresses…
Sous forme de tableau, cela peut se présenter sous la forme :
Nom Descriptif Type d'accès Caractéristique

Identifiant Identifiant dans la BDD Automatique Entier naturel autoincrémentable et unique, clé
de la table
Nom Nom de la personne Champ texte simple Unique et obligatoire
Email email servant de login Champ email Unique, obligatoire, champ de texte email.
L'email sera vérifié par l'envoi d'un mail com-
portant un lien cliquable pour validation de
l'adresse. ATTENTION : il sera possible pour
l'internaute de renseigner un autre email s'il
veut recevoir sa newsletter sur une autre
adresse mail.
Vous avez compris le principe.
Spécificités des champs et des tables pour les contenus textuels
Les données relatives à un « article », c’est-à-dire à un contenu rédactionnel, doivent comporter des pro-
priétés différentes pour différentes parties de l’article dans le cadre de l’optimisation du SEO.
Le minimum est d’avoir :
• Un titre (utiliser dans la balise title et dans les balises titre des Métas de partage de la page sur les
réseaux sociaux)
• Une accroche (permettant aussi de remplir automatique la balise description)
ministrable depuis le back-office afin de pouvoir ajouter des types de téléphones en cas d’oubli ou d’évolution de ce moyen de communication.

d'autorisation

• Le contenu de l’article (formatble et dans lequel on peut insérer des médias)

• Une image (servant d’icône pour éventuellement identifier l’article sur le site et d’image pour les
balises mata de partage sur les réseaux sociaux)
• Une date de création
• Une (ou plusieurs) date de modification
• Un (ou plusieurs) auteur(s)
• Une (ou plusieurs) URL pour l’URL rewriting
On peut aussi trouver des champs : surtitre, sous-titre, note, et tout autre champ que l’on jugera
nécessaire.
Les images relatives à un article sont référencées dans une table séparée (plusieurs images pour un
article). Cette table devra comprendre outre l’identifiant de l’image, des champs : URL, nom, description,
extension. Le champ extension est nécessaire pour le traitement des images surtout dans le cadre d’une
table média qui reliera les articles à tous les médias (PDF, vidéo, son, SWF…) et surtout pour remplir la
l’attribut ALT de la balise image. Dans le cas ou on utilise la balise figure et sa sous-balise figcaption, un
second champ de description permet de différencier les textes de l’attribut ALT de la légende de l’image.
Pour les vidéos et le son, il est nécessaire de prévoir un lien entre les vidéos ou les bandes sonores du
fait de l’obligation d’associer plusieurs formats de ces médias au lecteur ad hoc.
Enfin, si on veut pouvoir associer des articles entre eux, il est nécessaire de mettre en place une table
d’association de ces articles les uns avec les autres.
Dans le cas où on veut différencier les champs titre et descriptions des balises méta de partage de page
sur les réseaux sociaux, il est nécessaire d’avoir autant de champs que d’utilisation prévue à cet effet.
Il est alors possible de prévoir au niveau du traitement de la page une fonctionnalité automatique per-
mettant d’attribuer le contenu du titre et de l’accroche si les champs complémentaires pour les balises
méta OG et Twitter sont vides.

d'autorisation

Spécificités des données administrateurs
À noter, évidemment, qu’il est nécessaire de prévoir dans le cadre de rédaction d’article, une table pour
les auteurs et plus globalement des comptes permettant l’administration du site. Outre les données sur
l’auteur (nom, prénom, pseudo…) on trouve souvent les droits suivants :
• Webmaster : tous les droits

• Administrateur : tous les droits sauf certains liés à la structure même du site. Les droits des admi-
nistrateurs sont donc : la possibilité d’ajouter, de supprimer ou de modifier les droits des auteurs,
créer, modifier, déplacer et publier des articles, et éventuellement changer l’arborescence, d’ajouter
ou modifier des menus dans le cadre d’une insertion automatique de menu…
• Rédacteur : création ou modification d’article, mais pas de publication. La publication pouvant être
réservée aux administrateurs.
• Visiteur : plus rarement, on peut introduire la notion de visiteur pour les personnes ayant accès à
une partie restreinte à une identification de l’espace public du site. Néanmoins, cette partie est le
plus souvent traitée en externe de la table des auteurs. Un visiteur n’a pas accès à l’espace d’ad-
ministration.
Les rédacteurs et administrateurs peuvent aussi être restreints à une partie seulement de l’arbores-
cence du contenu et n’être administrateurs ou rédacteurs que d’une ou plusieurs rubriques, mais pas de
la totalité.
Bien entendu, selon les nécessités d’administration du site, on peut trouver une « table des droits » bien
plus complexe comportant des droits de gestion sur les produits ou sur la facturation pour les boutiques
en ligne, des droits de gestion spécifique à certaines fonctionnalités…
Arborescence des contenus
Qu’on les appelle rubriques, taxonomie, famille de tags ou d’une autre façon, l’idée de l’organisation du
contenu textuel se fait en divisant les différents sujets du contenu en « thématiques »… que j’appellerais
ici rubriques. Ces rubriques peuvent elles-mêmes contenir des sous-rubriques et la différence entre les
premières et les autres n’est qu’une question de niveau dans l’arborescence générale. On retrouve d’ail-
leurs dans certains CMS cette notion sous l’appellation taxonomie et sur le lien entre les « mots-clés »
de la forme parent-enfant. Il est important de prévoir aussi la possibilité de classer des articles dans une
catégorie hors « rubriquage ».
Les contenus des pages sont des articles, mais on peut distinguer des articles de nature restreinte qu’on
appelle brèves. Selon les CMS, cette différence de nature est parfois prise en compte, parfois non.

d'autorisation

Pour résumé, votre site est composé d’articles (et éventuellement de brèves) qui sont classés dans des
rubriques pouvant être subdivisées en sous-rubriques et comptant une possibilité de classement hors
rubrique.
Enfin, vous pouvez mettre en place un système de navigation transversale aux rubriques par le biais de
mots-clés qui permettent de taguer les articles, les rubriques et les brèves, et éventuellement les diffé-
rents médias, pour les regrouper dans des thématiques transverses ou parallèles à l’organisation en
rubrique. Ainsi, si votre système est à base de mot clés, une première famille de mot clés sera dédiée à
l’arborescence générale (rubriquage) et d’autres familles à la navigation transverse (tags).
L’arborescence peut se définir de deux façons, parfois, ces deux arborescences sont identiques, parfois,
elle présente des différences. Ces deux façons sont :
• Au niveau de l’organisation des données dans le back-office

• Au niveau de la navigation (et donc de l’organisation côté front-office)
On peut en effet concevoir que ces deux arborescences ne soient pas totalement identiques, ou tout
du moins que la seconde n’inclut pas forcément la totalité de la première. De plus, comme je l’ai dit
précédemment, la navigation peut donner accès à des fonctionnalités qui ne sont pas présentes dans
l’arborescence du contenu, ce qui implique que la navigation peut aller au-delà de l’arborescence du
contenu. Globalement on essaie de construire l’arborescence du contenu sur trois niveaux maximum,
même si dans certains cas de contenu très fournis, il arrive que l’on dépasse ces trois niveaux. Dans ce
cas, en règle générale, le menu principal qui permet une représentation de la(arborescence s’arrête au
plus, au troisième niveau, voire au deuxième, et ce sont les éléments de navigation secondaires qui vont
permettre de s’enfoncer dans l’arborescence.
Si l’on prend un site comme developpez.net3 (voir capture d’écran page suivante) vous remarquerez que
malgré la quantité importante de contenu du site, la navigation principale n’est jamais sur plus de deux
niveaux, quitte à avoir deux menus l’un en dessous de l’autre et que selon la section dans laquelle on
entre, l’URL de la page change de sous-domaine (pour les tutos on a general.developpez.com/cours/,
pour java on a java.developpez.com, pour le développement Web on a web.developpez.com…).
3 https://www.developpez.net

d'autorisation

1
2
3
4
5
1 Menu de fonctionnalités principales

2 Menu de contenu principal
3 Menu contextuel à la section de contenu ou de fonctionnalités
4 Menu contextuel de fonctionnalité ou de contenu
5 Menu contextuel de fonctionnalité
Remarquez aussi que le nom de domaine change et que des sous-domaines sont appliqués aux diffé-
rentes parties du site.
La navigation
Même si cette règle est aujourd’hui parfois remise en question, la navigation est régie par la règle des
trois clics : c’est-à-dire qu’il faut depuis n’importe quelle page d’un site pouvoir accéder à n’importe
quelle autre en trois clics maximum. Elle repose le plus souvent sur un menu principal en haut et sur des
menus secondaires en colonne de droite et/ou de gauche. La navigation est la première fonctionnalité
d’un site.
L’ensemble de cette fonctionnalité sera abordé dans la deuxième partie de ce cours sur les wireframes.

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: Les chemins utilisateurs
À propos des mots-clés
Comme évoqué précédemment, le système de tag peut être utilisé non seulement en tant qu’outil de
navigation, mais aussi en tant qu’outil de fonctionnalité. Vous trouverez par exemple une utilisation de
mots-clés pour :
• Afficher un article dans une zone donnée de votre site

• Regrouper l’affichage d’article à la suite d’un contenu de base
• Attribuer une valeur élevée à un contenu dans le moteur de recherche
• Filtrer une catégorie d’article
• Gérer l’affichage de contenu dans vos pages
• …
Les chemins utilisateurs

Lorsque l’on établit le cahier des charges, en plus de l’arborescence, il vous faudra aborder la notion de
chemin utilisateur. Outre l’idée que le chemin utilisateur peut prendre en compte la navigation, on parle
de chemin utilisateur plutôt pour des successions de pages relatives aux étapes d’une action ou d’une
fonctionnalité comme une inscription, un acte d’achat, l’accès à un contenu sous condition d’identifica-
tion ou d’inscription… La question à vous poser est donc la suivante : quelles sont les actions ou fonc-
tionnalités qui nécessitent des étapes ?
Il est important de garder à l’esprit qu’un chemin utilisateur n’est pas qu’une succession de page Web,
mais un ensemble d’action qui peut aussi faire intervenir des outils tiers, et principalement l’email. Par
exemple, une validation d’inscription passe par l’envoi d’un email (pour vérifier l’adresse mail de l’inter-
naute et si c’est bien lui qui fait l’action) possédant un lien cliquable permettant d’accéder à la suite du
processus. Vous pouvez aussi devoir passer par des actes de validation sous forme de boites de dialo-
gues ou de notification.
Vous devez donc définir tous les processus qui nécessitent cette succession d’action. L’idée est de
réduire le plus possible les « effets tunnel », c’est-à-dire un « emprisonnement » long dont l’internaute ne
peut sortir facilement. Dans le cas d’un long processus, il faut essayer de donner la possibilité à l’inter-
naute d’enregistrer l’état de son parcours afin de lui permettre de le reprendre plus tard, et dans tous les
cas, que ce parcours soit composé de peu d’étapes ou d’un nombre important d’étapes, il est nécessaire
de lui indiquer sa position dans le processus par le biais d’une barre de procession (breadcrumb) lui per-
mettant alors de visualiser le chemin et sa position dans celui-ci (voir exemple ci-dessous).

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: La projection de son évolution
Cette méthode peut aussi convenir à de longs formulaires, car si l’effet tunnel est à éviter, un très long
formulaire peut aussi rebuter l’internaute, alors que ce type d’accompagnement et de prévisualisation
facilite la prise en main du processus.
Ainsi, les systèmes de messagerie interne, les inscriptions, les actes d’achats sont des chemins utilisa-
teurs particuliers qu’il convient de bien étudier.
La projection de son évolution

Soit pour des raisons budgétaires, soit pour des raisons de stratégie, il est possible que le site ne soit
pas développé intégralement dès sa première version. Il est néanmoins nécessaire de prévoir, dans la
mesure du possible, son évolution. En effet, tant pour le modèle de données que pour les fonctionnalités
back et front-office, l’évolution d’un site se prépare au niveau de sa programmation et de son interface.
Vous devez donc dans ce cas construire votre cahier des charges en incluant les évolutions futures du
site et en indiquant ce qui sera fait dans un second temps. Cela permettra au développeur de prévoir les
« portes » à préparer pour la version suivante.
D’autre part, outre ces raisons budgétaires ou stratégiques, essayer de projeter votre site dans l’avenir et
de voir si la cible, le service, voire la technologie va évoluer pour concevoir les modifications à apporter
aux fonctionnalités ou aux données de votre site.
Si on prend en compte l’évolution des smartphones, on s’aperçoit que la taille des écrans évolue, que
les capacités de calcul augmentent… Graphiquement, les tendances évoluent aussi, votre cible peut
évoluer, et vos besoins en termes d’administration peuvent aussi évoluer. Aussi essayer de penser votre
projet dans le futur afin de vous éviter des phases de développement trop complexe nécessitant une
reprise globale de la programmation.
Comme nous le verrons dans la troisième partie, le site Web n’est plus conçu comme une application
monolithique, c’est-à-dire où tous les services sont inclus dans la structure du site, mais comme une

d'autorisation

Partie 1 : Descriptif du projet :: Définition du projet :: Méthodologie générale
base de développement sur laquelle on attache des services externes. Plus la conception de votre site
est basée sur cette toile de services, plus vous pourrez faire évoluer chacun d’eux sans avoir à repenser
l’ensemble de votre projet. Cette conception en service permet ainsi une grande modularité et une faci-
lité à la prospective de votre application Web.
Méthodologie générale
Il n’est pas possible de penser un projet Web de façon linéaire. Une fois poser les grandes idées (défini-
tion du projet) établit la cible et benchmark, les aller-retour entre les fonctionnalités et le modèle de don-
nées entraine une réflexion quantifiée (et non continue) de votre projet. N’essayez donc pas de rédiger
votre cahier des charges de façon linéaire, mais prenez des notes sur les différents sujets, éventuelle-
ment (cela me parait plus simple, mais à chacun sa façon de travailler) sur des fichiers distincts vous
permettant d’avoir des fichiers assez courts pour isoler les idées, ce qui vous permettra de les recouper
plus facilement.
Selon les projets, il est parfois préférable (ou naturel) de commencer par le modèle de données, parfois
par la description des fonctionnalités. De même pour celles-ci, si, le plus souvent on commence par
la description du front-office, il arrive qu’il soit plus judicieux de commencer par celle du back-office. La
façon de travailler est la vôtre et vous devez adapter les préconisations de ce cours à votre façon de
penser et de travailler.
Ainsi, si globalement on commence à travailler les wireframes après cette première partie du cahier des
charges, rien ne vous empêche de poser des schémas d’ergonomie avant ou durant la rédaction de vos
fonctionnalités et de votre modèle de données afin de clarifier vos idées.
Une étape importante de votre travail consiste à recenser les besoins de votre client. Aussi les premiers
entretiens sont primordiaux et vous devez faire preuve d’une grande capacité d’écoute et d’interrogation
sur son métier, son service, son besoin et son histoire. Votre expertise ne couvre pas tout, la sienne non
plus, c’est donc une synthèse qu’il vous faudra construire en prenant en compte ce qu’il peut (humaine-
ment, techniquement et financièrement), ce qu’il sait (des technologies Web, de sa cible, de son service
ou de son produit), ce qu’il veut (et oui, c’est lui le client), et ce qu’il doit (et oui, c’est vous l’expert·e Web).
Il arrive que ces caractéristiques entrent en conflit et il est donc nécessaire d’avoir discernement et
diplomatie pour construire un projet efficient, et cela fait aussi partie de votre métier.

d'autorisation

Partie 2 : Graphisme et ergonomie :: Définition du projet :: Méthodologie générale
Partie 2 : Graphisme et ergonomie

d'autorisation

Partie 2 : Graphisme et ergonomie :: La navigation :: Parcours utilisateur
La navigation
Parcours utilisateur
La navigation est la première fonctionnalité d’un site Web : pouvoir aller de page en page. C’est le prin-
cipe même des origines du Web : l’hyperlien, c’est-à-dire une zone cliquable permettant de naviguer au
sein d’une page ou d’aller d’une page à l’autre. En cela, la navigation fait partie du « parcours utilisateur ».
Mais c’est aussi un élément primordial de l’ergonomie puisque tant pour le référencement naturel que
pour maintenir l’internaute sur le site, les éléments de navigations doivent être visibles, inviter au clic
(call to action) et permettre une parfaite compréhension non seulement de l’arborescence du contenu,
mais aussi des passerelles entre les différents éléments de son contenu (navigation transverse), de
l’accès aux fonctionnalités et de l’utilisation de celles-ci.
La navigation est donc la première préoccupation de l’ergonomie et doit être abordée avec une attention
toute particulière.
Les différents éléments de navigation

La navigation est régie par la règle des trois clics : c’est-à-dire qu’il faut depuis n’importe quelle page
d’un site pouvoir accéder à n’importe quelle autre en trois clics maximas. Cette règle est aujourd’hui par-
fois remise en question du fait du développement important de contenu que présentent certains sites,
néanmoins, et dans la mesure du possible, il importe d’essayer de rendre l’accès entre les pages d’un
site Web le plus court possible.
La navigation repose le plus souvent sur un menu principal en entête de page (header) et sur des menus
secondaires en colonne de droite (et/ou de gauche). Avec le temps, les éléments de navigation des pieds
de page (footer) se sont développés, et on peut aujourd’hui considérer que cette zone du site fait partie
des principaux éléments de navigation.

d'autorisation

Partie 2 : Graphisme et ergonomie :: La navigation :: Les différents éléments de navigation
Le menu principal
Le menu principal, est situé au-dessus du contenu principal le plus souvent dans le header, mais on peut
trouver aujourd’hui ce menu sur le côté et de plus en plus souvent dans sa forme responsive dites menu
hamburger en raison de l’icône qui en permet l’ouverture et représenter par trois traits l’un au-dessus de
l’autre .
Il comporte le plus souvent les grandes parties de l’arborescence du contenu. Ce menu se présente
traditionnellement en tant que menu déroulant qui permet d’accéder par survol d’une partie (rubrique)
à ses sous-parties (sous-rubriques). Parfois même, le survol de ces sous-parties donne accès à un troi-
sième niveau de l’arborescence du contenu. Si, dans le passé, on trouvait des menus allant dans des
sous-niveaux plus profonds de l’arborescence du contenu, ce n’est plus, ou que très rarement, le cas
aujourd’hui.
On trouve aussi parfois tout en haut de la page, au-dessus de ce menu de navigation, un second menu
principal présentant l’accès au panier, l’accès à l’identification ou à l’espace client, l’accès à des sites
connexes, le changement de langue, le support client… Ce menu présente donc plutôt des accès directs
à des services ou à des fonctionnalités qu’à des accès aux descriptifs de ces services et est donc plus
un menu de fonctionnalité qu’un menu de contenu. Pour illustration le site OVH (https://www.ovh.com/
fr/) présente un premier menu tout en haut de la page donnant accès à l’espace client, au webmail, à
la communauté au support et au changement de langue. Le deuxième menu en dessous possède une
arborescence à trois niveaux qui donnent accès à tous les descriptifs de tous les services que la société
propose. Ce type de menu est appelé mégamenu.
Ces menus principaux sont à la base de la navigation en ce qu’ils représentent l’arborescence du contenu
et les principaux services proposés par le site.

d'autorisation

Menus secondaires
Les menus secondaires sont importants en ce qu’ils sont le plus souvent contextualisés par le contenu
de la page et l’emplacement dans l’arborescence des données. Pour un site organisé en rubriques, on
peut trouver en menu secondaire « l’ensemble des articles de la rubrique », mais aussi des articles liés
au sujet qui ne sont pas forcément dans la même rubrique. Par exemple dans une rubrique technique de
peinture, dans un article « les glacis » on pourra aussi trouver un lien « lire aussi » vers un article « huile
de noix » que l’on trouve dans la rubrique « fiche technique ».
La navigation secondaire est donc un complément important à la navigation principale non seulement
comme une navigation transverse au site, mais aussi comme une incitation à le parcourir. C’est ce
principe que l’on trouve dans les boutiques sous l’appellation « les clients qui ont acheté ce produit ont
aussi acheté… ». Mais cette navigation secondaire ne s’arrête pas à des liens en fin d’article, on peut en
effet trouver des blocs de navigation contextuelle présents en colonne de droite ou sous les articles
présentant des articles de sujets connexes ou des compléments d’articles (pour aller plus loin, pour en
savoir plus, voir aussi…), les articles appartenant à la même rubrique en cas de classement par rubrique
du contenu, des fichiers joints (PDF, modèles de document…), des filtres (en cas de boutique en ligne), le
report du résultat d’une recherche effectuée sur le moteur interne du site…
Un autre élément de navigation jugé important par une grande partie des internautes est le fil d’Ariane.
Le fil d’Ariane est souvent présent en une ligne textuelle au-dessus du contenu principal de la page
et sous le (ou les) menu(s) principal(aux). Il représente la position dans l’arborescence du contenu et
permet de remonter au sein de celui-ci. Pour exemple il est de la forme :
Accueil >> Technique de peinture >> Peinture à l’huile >> Glacis
Pour rester dans l’exemple, si vous cliquez sur Technique de peinture vous aurez accès aux liens pein-
ture à l’huile, acrylique, gouache, aquarelle… Outre son rôle de navigation, le fil d’Ariane permet de se
repérer facilement.
Outre des liens directs vers des articles d’autres rubriques, cette navigation transverse peut aussi être
définie à partir de mots-clés (ou tags) qui permettent de relier des articles (pages Web) qui ne sont pas
dans le même niveau de l’arborescence du contenu et qui pourtant traitent en partie quelque chose de
commun. Ces tags ne définissent pas des éléments de l’arborescence du contenu, mais des sujets, des
notions qui sont présentes dans plusieurs catégories du contenu. Un tag peut d’ailleurs posséder sa
propre page et ne pas être simplement un lien ou une indication de concept traité dans la page, et qui
réunit ces différents articles qu’ils proviennent ou non de rubriques différentes.

d'autorisation

À propos des mots-clés
Comme évoqué précédemment, le système de tag peut être utilisé non seulement en tant qu’outil de
navigation, mais aussi en tant qu’outil de fonctionnalité. Vous trouverez par exemple une utilisation de
mots-clés pour :
• Afficher un article dans une zone donnée de votre site
• Regrouper l’affichage d’article à la suite d’un contenu de base
• Attribuer une valeur élevée à un contenu dans le moteur de recherche
• Filtrer une catégorie d’article
• …
Le footer
Dernier menu présent dans une page Web, le pied de page. Le pied de page a beaucoup évolué depuis
ces dix dernières années. Avant, il présentait quelques liens hors arborescence du type mentions légales,
contact et des éléments de copyright, l’adresse physique de l’entreprise… Actuellement, le pied de page
est construit comme un véritable menu complémentaire permettant de naviguer dans le site sans avoir
à remonter en haut de page, même si on a maintenant la possibilité de faire en sorte que le header de la
page Web apparaisse lorsque l’on descend dans celle-ci. Le pied de page contient donc souvent tout ou
partie des menus principaux, des liens complémentaires (comme à son origine), des accès aux réseaux
sociaux, un lien vers le plan du site… et est donc devenu un élément de navigation à part entière.
Le moteur de recherche interne
Dernière forme de navigation dans un site et non des moindres : le moteur de recherche. Le moteur de
recherche permet une navigation transverse au site en ce qu’il donne un accès direct à un ensemble
de liens selon des expressions contenues dans les articles, brèves ou descriptifs de mots-clés ou de
rubrique. Il prend la forme d’un champ de recherche souvent situé en haut de page ou en haut de la
colonne secondaire de la page.
Le moteur de recherche est indispensable à un site Web et peut aussi être accompagné de fonctionna-
lités de recherche avancée dont les filtres sont un exemple.

d'autorisation

Partie 2 : Graphisme et ergonomie :: La navigation :: Conclusion
Autres navigations
Enfin, on trouve aussi à divers endroits des pages, parfois au-dessus du contenu, sur le côté, ou en bas
de page, de petits blocs comprenant les boutons de partage des pages Web vers les réseaux sociaux.
Ces « menus » ne sont pas des menus de navigation, mais des menus d’interactivité donnant accès à
des fonctionnalités contenant aussi les liens vers les flux RSS, le bouton d’impression de la page ou
l’accès à la version PDF, l’envoi par mail de l’adresse de la page…
Conclusion
Il n’y a pas de règle absolue dans l’utilisation des différents menus. Néanmoins, pour des arborescences
fournies, je préconise l’utilisation de fil d’Ariane, et en général, la présence des boutons de partage sur
toutes les pages et un menu principal clair. Je crois aussi qu’il est nécessaire de bien développer son
menu de bas de page afin de donner à l’internaute la possibilité de naviguer dans le reste du site sans
avoir à remonter en haut de page et en disposant d’informations et d’orientations secondaires qui pren-
draient trop de place dans le menu principal. Tous les autres moyens de navigations vont dépendre du
contenu, de l’ergonomie et des fonctionnalités proposées.

d'autorisation

Partie 2 : Graphisme et ergonomie :: Zoning, wireframe, ergonomie et interactivité :: Les types de pages
Zoning, wireframe, ergonomie et interactivité
Les types de pages

Lorsque votre cahier des charges a défini toutes les fonctionnalités, toutes les données et donc, l’ar-
borescence de votre site, la première étape dans la mise ne place de l’ergonomie est de déterminer les
différents types de pages. En effet, toutes les pages de votre site n’ont pas le même rôle et ne vont donc
pas avoir la même structure.
Il existe néanmoins des zones communes à l’ensemble des pages : ce sont les invariants, même si sur
une page Web, ces invariants peuvent avoir des variations en fonction des situations (connecté/non
connecté, niveau de droit…). Ces invariants sont le header et le footer qui forme à eux deux les bases de
la navigation.
Parmi les types de pages les plus fréquentes :
• La page d’accueil : qui possède (presque) toujours une structure différente des autres pages. La
page d’accueil doit ouvrir sur l’ensemble des thématiques et des fonctionnalités.
• Les pages de gestion de compte : quand elles existent ses pages sont différentes dans autres
dans la mesure ou elle présente un accès aux données personnelles et à certaines fonctionnalités.
• Les pages de présentations d’ensemble d’articles : ce sont des pages qui regroupent des « collec-
tions d’articles » comme les articles d’une rubrique, reliés par un mot-clé, résultat d’une recherche
sur le moteur de recherche interne… Si ces pages ont toutes en commun de présenter une série
d’articles (voire de « sous-rubrique »), selon les besoins elles peuvent néanmoins présenter des
configurations différentes.
• Les pages d’articles : c’est-à-dire les pages de contenu informationnelles
• Les pages produits : dans le cas de boutique en ligne
• Les pages génériques : telle que les mentions légales, les CGU, la page contact… même si ces
pages sont parfois construites sur le modèle des pages d’article
On peut bien évidemment au sein de ces types de pages avoir des variations et bien entendu trouver
d’autres types de pages selon les sites.
Il est donc important de commencer à déterminer les différents types de pages afin de construire le
nombre de wireframes nécessaire à poser l’ergonomie de l’ensemble des pages du site.

d'autorisation

Partie 2 : Graphisme et ergonomie :: Zoning, wireframe, ergonomie et interactivité :: Le zoning
Le zoning
Une fois déterminés les différents types de pages,
il faut établir le zoning de chacun de ces types.
Le zoning est le schéma des grands blocs compo-

sant la page, c’est comme un plan (voir schéma
ci-contre).
Il est nécessaire de faire au moins deux zonings

par type de page : la version desktop (ordinateur)
et smartphone. En effet, ces deux versions sont à
la base du responsive design, c’est-à-dire de l’adap-
tation de la mise en page d’une page Web selon le
type de terminal sur lequel elle est consultée.
Le responsive design
Le resposnsive design est donc l’ensemble des propriétés permettant à une page Web de s’adapter à
deux choses :
• Le type de machine sur laquelle la page est consultée

• La taille de la fenêtre du navigateur sur un ordinateur
Ainsi, il y a deux types de réactions au responsive design, une réaction « statique » au moment du char-
gement de la page qui correspond à l’appareil qui lit celle-ci et une réaction « dynamique » qui corres-
pond pour les ordinateurs, à la nécessité de s’adapter quand on change la dimension de la fenêtre du
navigateur.
Il est nécessaire de prendre en compte 3 types de machines : ordinateur, tablette et smartphone, néan-
moins, il faut prendre en compte que les smartphones et tablettes présentent une grande variété de
modèles et que les résolutions et taille d’écran d’ordinateur aussi. Il est donc nécessaire de simplifier sa
réflexion et son modèle.

d'autorisation

Partie 2 : Graphisme et ergonomie :: Zoning, wireframe, ergonomie et interactivité :: Le responsive design
Les dimensions types
Si on se réfère à Bootstrap, les dimensions utilisées dans les médias query sont pour les tailles maxi-
males : 575px, 767px, 991px, 1199px
Attention, il est néanmoins important de prendre en compte que certains smartphones en mode portrait
(vertical) ont une taille de 320px.
On voit aussi parfois une autre façon d’aborder le problème et reposant sur la définition des trois princi-
paux types de terminaux :
• Desktop : au-delà de 1024 pixels

• Tablette : entre 600 et 1024 pixels (en mode portrait)
• Mobile : entre 320 et 600 pixels (en mode portrait)
Pour ce second cas, l’approche est réductrice en ce que certains vieux écrans d’ordinateur ont une réso-
lution inférieure à 1024 pixels et certains mobiles ont une résolution supérieure à 600px. De plus, mobile
et tablette peuvent basculer de portrait à paysage.
L’approche globale
On peut donc, afin de sortir de ces problématiques, adopter une approche globale et définir deux modèles
de zoning :
• Un modèle desktop : qui sera utilisé aussi, dans une certaine mesure pour les modes paysage des
tablettes.
• Un modèle smartphone : qui sera utilisé dans une certaine mesure pour le mode portrait des ta-
blettes.
Cela ne veut pas dire qu’il n’y a pas des adaptations intermédiaires et que dès 991px, l’interface même
sur ordinateur ne passe pas en mode smartphone.
Cela ne veut pas dire non plus qu’il n’y a pas parfois besoin d’adaptation sur des dimensions intermé-
diaires, par exemple pour le menu qui comporte trop d’entrées de premier niveau et qui dès 1024 px
devient trop grand pour tenir sur une seule ligne. Néanmoins, ces adaptations ne sont pas nécessaire-
ment des adaptations dans la structure de la page, mais peuvent être liées à une réduction de la taille de
la police, des marges intérieures ou extérieures, de l’interlignage…
Il est donc possible de partir sur une idée simple de deux modèles possédant des adaptations transitoires

d'autorisation

Partie 2 : Graphisme et ergonomie :: Zoning, wireframe, ergonomie et interactivité :: Le wireframe
ou sur des éléments ponctuels. À noter néanmoins que dans certains designs applicatifs, des change-
ments de structures peuvent intervenir de façon spécifique sur plusieurs tailles et avoir pour une taille
donnée une adaptation partielle de la structure (seul le menu change), pour une autre, une adaptation
de la structure, et pour une dernière la disparition de certains éléments.
Pour résumer, il n’y a pas véritablement de règle générale, même si les frameworks en établissent, c’est
à vous de garder à l’esprit que vous avez la liberté de décider de la façon dont votre interface s’adapte.
Le wireframe
Vous savez donc que vous avez
un certain nombre de types
de page, dont vous avez fait le
zoning et que chaque zoning va
devoir avoir au minimum deux
interprétations selon le principe
du responsive design.
Le wireframe est la description

du contenu de ces zones. Il a plu-
sieurs rôles :
• Établir les modes de fonc-

tionnalités des éléments
• Visualiser l’ensemble des
fonctionnalités définies
dans la première partie du
cahier des charges
• Préparer le graphisme final
Selon le zoning présenté précé-

demment, le wireframe corres-
pondant pourrait être le suivant (figure ci-dessus) :
Comme vous pouvez le constater, on présente dans chaque zone, l’ensemble des éléments qui s’y
trouvent. On présentera les variations de ces éléments. Par exemple, on a en haut le formulaire de
connexion, mais une fois connecté, on ne trouvera à la place de ce formulaire que l’accès à la page de
gestion de compte et le lien de déconnexion.

d'autorisation

Partie 2 : Graphisme et ergonomie :: Zoning, wireframe, ergonomie et interactivité :: Le wireframe
Il est nécessaire d’annoter le wireframe pour :
• Nommer et décrire l’élément

• Expliquer ses éventuelles variations (lorsque l’internaute est connecté ou pas, selon la date, se-
lon une commande depuis l’interface d’administration comme la mise en place d’une période de
solde…)
• Déterminer le mode d’appel de l’élément dans la page (automatique par date, par un mot-clé depuis
l’interface d’administration…).
Pour exemple voir l’image ci-dessous.
À noter que les éléments déjà décrits

comme l’entête et le pied de page ne
sont pas décrits de nouveau.
On notera aussi la différence de style

dans les commentaires : certains
commentaires permettent de définir
l’objet, d’autres (en rouge) sont liés à
des problématiques de programma-
tions comme le type d’appel dans la
page, des conditions de connexion…
Le wireframe est un élément extrême-

ment important de la conception d’un
site Web puisqu’il permet de visualiser
l’interface en dehors de sa charte gra-
phique. De plus, lorsque l’on parcourt
les wireframes, on peut vérifier que
l’ensemble des fonctionnalités défi-
nies dans le cahier des charges sont
bien présentes et les annotations per-
mettent de vérifier les conditions de
leur présence ainsi que les processus
d’appel dans la page.
On pense souvent que le wireframe n’est là que pour la partie front-office, néanmoins, selon les besoins et
la complexité des interfaces d’administration, il peut aussi être nécessaire de mettre en place la même
procédure pour le back-office. Le protocole est alors le même : définition des types de pages, définition
de leur zoning, mise en place des wireframes selon le cahier des charges.

d'autorisation

Partie 2 : Graphisme et ergonomie :: Zoning, wireframe, ergonomie et interactivité :: L’interactivité
Les invariants
Les invariants sont les éléments d’une page qui sont communs à toutes les autres. Contrairement au
Print, les invariants du Web ont… des variantes. La principale variante est la présence d’éléments diffé-
rents selon que l’internaute est connecté ou non, et selon ses droits une fois connecté. Globalement
les invariants sont l’entête et le pied de page. Bien entendu, front et back-office doivent être considérés
comme des interfaces différentes et ne vont donc pas avoir les mêmes invariants.
Le design system
La notion de design system définit les éléments d’interfaçage d’un iste Web. Il peut ainsi être utile de
recenser les différents types d’éléments composant les pages. Par exemple :
• Tous les blocs textes sont-ils les mêmes, et sinon, combien de types de blocs sont présents dans le site ?
• Tous les boutons sont-ils les mêmes ?
• Les blocs de mise en avant sont-ils tous les mêmes ?
Le fait de recenser ces éléments permet d’une part de vérifier l’homogénéité du site, mais aussi de sim-
plifier l’intégration et le design. En effet, si une page contient des blocs qui sont tous déjà désignés dans
d’autres pages, le wireframe suffit à les décrire et la référence aux maquettes qui les contiennent suffit à
l’intégrateur pour construire les pages par simple copier-coller du code.
D’autre part, le design system permet aussi d’homogénéiser l’interface des différents sites composant
un parc applicatif. Si une société possède plusieurs sites, on retrouvera entre eux le même type de fonc-
tionnalité ce qui permettra aux utilisateurs de faciliter leur utilisation.
L’interactivité
L’interactivité d’un site Web n’est pas que la façon de naviguer. Nous l’avons vu, c’est aussi le parcours
utilisateur, mais c’est surtout la façon dont le site communique avec l’internaute. Un site communique
avec un internaute de trois façons :
• Une façon externe qui est l’envoi d’email

• Une première façon interne qui est la notification par boite de dialogue et le tooltip (infobulle)
• Une seconde façon interne qui est la signalétique fixe ou animée, la signalétique animée étant la
micro-interaction.
d'autorisation

Je ne reviendrais donc pas sur la navigation, et je ne parlerais pas des fonctionnalités qui font l’objet
d’une partie précédente de ce cours pour m’intéresser aux deux aspects spécifiques à l’interface d’un
site Web.
Outre le wireframe vous devez donc mettre en place les dispositifs de communication entre l’interface et
l’internaute. Vous devez donc établir le graphisme des boites de dialogue et des infos bulles, et surtout
définir les moments de l’action qui nécessitent leur apparition. Si l’info bulle est purement informative, la
boite de dialogue (ou la notification) est en règle générale fonctionnelle et mets en place soit une infor-
mation de type fonctionnel (vous allez lancer telle opération, vous avez X messages dans la messagerie
interne, votre commande est validée…), soit la demande de validation d’une action.
Le rôle de designer Web ne s’arrête donc pas à l’ergonomie, mais prend aussi en compte l’interactivité.
Parmi les éléments d’interactivité, on trouve :
• Tous les éléments de formulaires et leurs différentes compositions

• Les accordions (accordéons) qui sont des « sections » dépliables
• L’autocomplétion (proposition de valeur lorsque l’on remplit un champ texte
• Les boutons (qui peuvent présenter plusieurs états)
• Les datapicker (calendrier permettant de saisir une date)
• Les boites de dialogues
• Les barres de progression
• Les tooltip (infobulle)
Il est donc nécessaire que vous établissiez les différents états de ces éléments et leurs procédures
d’apparition/disparition. En effet, rien de plus agaçant qu’un élément qui apparait pour aider, mais qu’il
est difficile de faire disparaître.
Les icônes
L’interactivité est souvent signalée par des icônes. Si les icônes sont normalement définies dans la
charte graphique, il vous appartient d’en définir les différents états selon la façon dont ils sont utilisés.
On peut définir trois utilisations pour les icônes :
• Une information
• Un accès à une information
• Un accès à une action

d'autorisation

Icône d’information
Ci-contre, des exemples d’icônes indiquant une information,

parfois sous forme textuelle à sa suite (par exemple la dernière
icône avec le numéro de tel qui suit) ou en infobulle lors du
survol ou du clic, parfois sans. De gauche à droite présence du WiFi, on parle anglais, venir en train,
contact par téléphone portable. Cette dernière icône peut aussi, dans le cas d’un affichage sur smart-
phone, permettre de lancer la communication.
Icône d’accès à l’information
Ci-contre, des icônes permettant l’accès à une information (et parfois à

une action. Ainsi, de gauche à droite : adresse mail (permet aussi d’envoyer
un mail en cliquant dessus), annonce d’un évènement ou accès à un calen-
drier, information — souvent ouverture d’une infobulle (tooltip) par clic ou par roll-over.
Icône d’action
Ci-contre des icônes permettant une action. De gauche à droite : modifier

une information (ouvre un pop in permettant le changement d’une donnée
ou transforme une ligne de texte en champ de formulaire lorsque l’on clique
dessus), accès à la page de gestion des données personnelles, partage d’un article sur Twitter ou accès
à la page Twitter de la marque.
Icône d’état et micro-interaction
Ces deux représentations marquent des étapes d’une

animation lors d’une action.
Pour le premier, lorsqu’on « like » un article, le cœur gris lance des petits rayons et reste en rouge une
fois l’action effectuée. Pour la seconde, lorsqu’on se connecte sur l’interface d’un site, si celui-ci contient
une fonctionnalité de messagerie, une fois la page affichée, la petite icône de cloche s’agite puis affiche
le nombre de messages reçus. Ces types de comportements font partie de ce que l’on appelle les
micro-interactions.
Ces micro-interactions deviennent de plus en plus fréquentes sur un site Web. Elles permettent

d'autorisation

d’agrémenter l’interface entre la page Web et l’internaute de telle sorte que ce dernier ait l’impression de
communiquer avec l’application. C’est d’ailleurs ce concept qui est mis en avant : le site Web devient une
application et non plus simplement un contenu statique. Ce passage du statique à l’applicatif humanise
la fonction informatique : la consultation devient un dialogue.
Les micro-interactions utilisent quatre procédés :
• Le déclencheur : il peut être une action de l’internaute ou une règle système ;

• La rétroaction : c’est le suivi de la micro interaction (le petit cœur qui devient rouge) et l’affichage
de la fin du processus (le cœur reste rouge) ;
• La boucle : la boucle est la répétition d’une animation lors de la micro-interaction comme une pe-
tite icône qui tourne durant le chargement d’une page ;
• Les modes : les modes sont des actions complémentaires demandées à l’internaute comme la
saisie d’une adresse pour avoir la météo locale.
Pour qu’une micro-interaction soit efficace, il est nécessaire de bien identifier le public qui utilise le site
Web, tant pour son iconographie que dans sa façon de manifester sa présence ou son résultat. De plus,
la micro-interaction peut aussi appeler l’action, et ne pas simplement l’annoncer ou y répondre. Pour une
application Web, on peut imaginer certaines icônes avoir une courte animation pour attirer l’attention de
l’internaute sur une fonctionnalité utile à ce moment.
Outre les services qu’elles rendent et l’humanisation de l’interface qu’elles induisent, les micro-interac-
tions participent à un mouvement dit « smooth » qui amène le plus possible de microanimations (par
exemple lorsque l’on passe sur un lien le fond du lien se colorie progressivement) et de transition (par
exemple le passage d’une page à une autre se fait par disparition progressive de la page que l’on quitte
et mouvement d’entrée de la nouvelle).
Ces effets de transition permettent non seulement un confort de navigation, mais aussi une impression
que le site n’a pas (ou peu) de latence.
Parmi toutes les micro-interactions possibles, pensez au loader qui permet de montrer qu’une action
de chargement se passe, soit entre vos pages si celles-ci sont lourdes, soit lors du chargement d’une
image lourde (agrandissement de photo par exemple), soit même lors d’un chargement d’un script ou
dans l’attente de son exécution.
C’est donc un ensemble de facteurs à mi-chemin entre la signalétique et l’interaction personne-machine

qu’il est nécessaire de prendre en compte, mais cette prise en compte ne peut et ne doit pas être un
effet de mode, mais une réelle réflexion sur le rapport entre la cible et le produit pour répondre à un réel
besoin dans l’utilisation.

d'autorisation

Partie 2 : Graphisme et ergonomie :: Le graphisme :: La charte graphique
Le graphisme
La charte graphique
Une fois mis en place les wireframes, vous devez leur appliquer la charte graphique. Le graphisme d’un
site Web n’est pas une recherche indépendante de l’ensemble des graphismes nécessaire à une entre-
prise pour tous les éléments de sa communication comme les cartes de visite, la plaquette, les cour-
riers, les rapports d’activités, les images sur les réseaux sociaux…
Pour homogénéiser sa communication on met en place une charte graphique (voir cours sur le sujet)
qui établit entre autres les utilisations du logo, les polices utilisées et la feuille de styles relative aux dif-
férents types de paragraphes et de mise en avant, les couleurs et leur gamme et alliance, le traitement
des images, l’utilisation de forme géométrique dans des cas particuliers ou général…
Le graphisme de votre site Web est l’application de ce document générique à vos wireframes. En cela,
on distingue la conception de l’ergonomie de son habillage. Dans votre cahier des charges, vous devez
joindre en document annexe la charte graphique et, si besoin est, déterminer d’éventuels compléments,
ou quelques variantes.
Par exemple, les fontes de votre charte graphique sont définies en point (pt), mais vos pages Web vont
utiliser une autre unité pour celles-ci (pixel ou em). Vous devez donc indiquer la correspondance entre ces
unités de mesure4. Vous pouvez avoir aussi un traitement d’image particulier pour le Web, ne serait-ce
qu’une définition des tailles maximales des images intégrées et de leur éventuel agrandissement. Peut-
être aussi ajouterez-vous une couleur si votre charte graphique en est dépourvue (par exemple une
charte graphique se basant que sur du noir et blanc).
Vous avez à prendre en compte la spécificité de certains éléments comme les liens qui changent de
couleur et dont il faut alors définir la fonte par défaut et la fonte en état hover.
Une fois définie la façon dont vous utilisez la charte graphique sur votre Web, vous pouvez passer au
maquettage.
4 Voir la page https://syndicode.com/2017/07/19/points-to-pixels-converter/ pour ces correspondances

d'autorisation

Partie 2 : Graphisme et ergonomie :: Le graphisme :: La maquette
La maquette
La maquette est donc la mise en application de votre charte graphique sur vos wireframes. C’est le plus
souvent un document Photoshop qui va présenter l’aspect définitif de vos pages. Vous avez normale-
ment autant de maquettes que de wireframes, sauf si vous avez défini le graphisme de l’ensemble des
blocs comme nous l’avons vu plus haut. La maquette est présentée sous version desktop et smart-
phone et tablette si besoin.
Et c’est à partir de ces maquettes que l’intégrateur va pouvoir construire ou finaliser le code HTML/CSS/
JavaScript permettant aux pages de fonctionner. Je dis finaliser parce qu’il est possible de commencer
l’intégration à partir des wireframes dans la mesure ou l’ensemble des éléments sont déjà présents et
selon la complexité du projet et l’équipe, cette étape peut être commencée avant la mise ne place de la
maquette définitive.

d'autorisation

Partie 3 : Les aspects techniques :: Le graphisme :: La maquette
Partie 3 : Les aspects techniques

d'autorisation

Partie 3 : Les aspects techniques :: L’hébergement :: Le serveur
L’hébergement
Le serveur
La première particularité technique à aborder est celle du serveur. Selon les médias que vous allez
inclure et leur mode de diffusion, selon les nécessités calculatoires de votre site… vous allez devoir défi-
nir les nécessités en CPU, RAM, bandes passantes, capacité de stockage…
La structure de votre serveur va aussi dépendre du langage de programmation que vous allez utiliser.
PHP, Python, Perl, Ruby… nécessitent des configurations différentes du serveur. Allez-vous installer Git
sur votre serveur, allez-vous utiliser Sass et donc devoir installer un préprocesseur CSS sur votre ser-
veur, allez-vous utiliser un développement par version de votre projet… ? Tous ces paramètres doivent
être pris en compte pour la définition du serveur.
Vous pouvez aussi définir votre structure d’hébergement en cluster, c’est-à-dire utiliser plusieurs ser-
veurs relier les uns aux autres dans un réseau privé. Ainsi, vous pouvez définir que le serveur de base de
données est indépendant de votre serveur Web, voir que selon l’importance de votre projet, vous allez
utiliser plusieurs serveurs Web (un pour l’identification, un pour la boutique, un pour le site vitrine…).
Enfin, vous devez mettre en place la politique de maintenance et de sauvegarde. Vous pouvez définir
de mettre en place un IP-failover permettant de basculer l’IP auquel est lié votre nom de domaine d’un
serveur à l’autre en cas de panne du premier… ce qui implique une sauvegarde quasi temps réel de l’en-
semble des fichiers du premier sur le second.
CMS, Framework et langage de programmation
Il est donc aussi nécessaire de définir l’utilisation de framework, CMS et langage de programmation, tant
dans leur « nature » que dans leur version. En effet certains CMS peuvent plus ou moins bien supporter
telle ou telle version d’un langage de programmation.
La définition d’un framework est tout autant valable côté back que côté front, et côté front, l’utilisation
d’un framework peut avoir une incidence sur la gestion du SEO dans la façon que ce framework entraine
sur la structure HTML des pages.

d'autorisation

Partie 3 : Les aspects techniques :: L’hébergement :: Le nom de domaine
Le nom de domaine
Bien entendu, il est nécessaire que vous ayez un nom de domaine. Le paramétrage d’un nom de domaine
peut s’avérer plus complexe que le lien avec votre serveur. Lorsque vous prenez un nom de domaine, il
arrive qu’il faille en prendre plusieurs. Pour exemple, vous avez le nom de domaine monbeausite.fr, mais
vous avez peur qu’un concurrent prenne le nom de domaine monbeausite.com. Aussi, il arrive que l’on
prenne un même nom de domaine sous plusieurs extensions, voire plusieurs noms de domaines, eux-
mêmes, sous plusieurs extensions.
Ne laissez jamais vos autres noms de domaines sans paramétrages
Vous devez définir les reroutages de tous vos noms de domaines afin qu’ils pointent vers votre domaine
fonctionnel. Cela permet à des personnes se trompant d’extension d’arriver quand même sur votre site.
D’autre part vous pouvez créer des sous-domaines relatifs à la diversité de vos activités comme c’est le
cas pour le site developper.net que nous avons vu dans la première partie de ce cours. Ainsi, si vous pro-
posez en parallèle de vos activités une activité de formation, rien ne vous empêche de créer un sous-do-
maine formation.monbeausite.fr qui conduira à la partie formation de votre site : ce reroutage simple
est un alias, c’est-à-dire l’attribution d’un sous-domaine au reroutage vers une page de votre site. À noter
que ce n’est pas le cas du site developez.net qui attribue un sous-domaine à un ensemble de pages, ce
qui nécessite une programmation du site plus complexe, ou l’utilisation de zones différentes du serveur
pour l’hébergement des pages.
Enfin, autour du nom de domaine, vous pouvez (devez) créer les adresses mail qui vous serviront. C’est
d’ailleurs dans le paramétrage du nom de domaine que vous pourrez incorporer les certificats SPF/
DKIM pour les envois de mail.
Certificat SSL pour le HTTPS
Le certificat SSL pour pouvoir bénéficier d’une connexion HTTPS sur votre site est mélange de paramé-
trage sur le nom de domaine et sur le serveur à partir d’une clé générée par un organisme certifié.

d'autorisation

Partie 3 : Les aspects techniques :: Les autres services :: Services connexes
Les autres services
Services connexes
Enfin, il est important de concevoir votre structure Web comme l’interconnexion de services, que ceux-ci
soient issus de prestation externe ou non. Allez-vous utiliser des API, de l’open data ? Comment allez-
vous gérer votre tracking, l’envoi d’email ? Allez-vous utiliser une régie publicitaire ?
Toutes ses données structurelles doivent être réfléchies en tant que bloc tant l’interconnexion entre
elles est sensible. En effet certains prestataires proposent des services qui ne sont valables que dans
certains langages de développement. L’utilisation de données récupérées en OpenData l’est sous cer-
tains formats qui ont des implications techniques…
Algorithmes
Enfin, le parcours utilisateur dépend le plus souvent du statut de celui-ci. Il est important de mettre en
place ces chemins sous forme d’algorithmes et afin de disposer d’une idée claire des différentes possi-
bilités et donc de la programmation nécessaire pour les traiter.
La base nécessaire que vous définir pour ces algorithmes est l’imbrication conditionnelle des états,
actions et statuts que vous attribuez aux différents constitutifs de votre site (internautes, données,
fonctionnalités…).
Base de données
À partir de votre modèle de données, si vous n’avez pu le faire vous-même, le développeur doit vous
proposer un plan de la base de données, c’est-à-dire le descriptif des tables, leur encodage, la définition
des utilisateurs possibles et de leurs droits…

d'autorisation

Cahier Des Charge Site Web

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Cahier Des Charge Site Web

Titre original :

Transféré par

Droits d'auteur :

Enseignant - formateur Denis Christine

WEB / PAO formation@inaden.org

Cahier des charges d’un site Web

Cahier des charges d’un site Web

Tous droits d'utilisation de ce cours est soumis à demande p. 1 / 47

Cahier des charges d’un site Web

Table des matières

Partie 1 : Descriptif du projet................................................................................................................................................................................4

Partie 2 : Graphisme et ergonomie................................................................................................................................................................27

Zoning, wireframe, ergonomie et interactivité............................................................................................................................................ 33

Cahier des charges d’un site Web

Partie 3 : Les aspects techniques..................................................................................................................................................................44

Les autres services....................................................................................................................................................................................................... 47

Tous droits d'utilisation de ce cours est soumis à demande p. 3 / 47

Cahier des charges d’un site Web

Partie 1 : Descriptif du projet

Tous droits d'utilisation de ce cours est soumis à demande p. 4 / 47

Cahier des charges d’un site Web

Définition et structure d’un cahier des

• Une partie liée à la définition du projet

La première partie du cahier comporte :

La deuxième partie comporte :

Tous droits d'utilisation de ce cours est soumis à demande p. 5 / 47

Cahier des charges d’un site Web

Cette deuxième partie doit comporter une double étude :

• Celle pour ordinateur

La troisième partie doit comporter :

Cahier des charges d’un site Web

Tous droits d'utilisation de ce cours est soumis à demande p. 7 / 47

Cahier des charges d’un site Web

La définition générale du projet

Tous droits d'utilisation de ce cours est soumis à demande p. 8 / 47

Cahier des charges d’un site Web

Le benchmark, c’est-à-dire l’étude de la concurrence

Tous droits d'utilisation de ce cours est soumis à demande p. 9 / 47

Cahier des charges d’un site Web

Le positionnement du projet dans l’entreprise et son

Tous droits d'utilisation de ce cours est soumis à demande p. 10 / 47

Cahier des charges d’un site Web

L’aspect technique : infrastructure informatique

• L’intégration des anciens et nouveaux clients de l’une à l’autre

Ce dialogue entre les outils peut s’effectuer :

Tous droits d'utilisation de ce cours est soumis à demande p. 11 / 47

Cahier des charges d’un site Web

• Le sexe (homme, femme, indifférent, autre)

La définition des fonctionnalités côté internaute et

Tous droits d'utilisation de ce cours est soumis à demande p. 12 / 47

Cahier des charges d’un site Web

• Nécessité ou non d’identification

Tous droits d'utilisation de ce cours est soumis à demande p. 13 / 47

Cahier des charges d’un site Web

Fonctionnalités communes à l’ensemble des projets

Tous droits d'utilisation de ce cours est soumis à demande p. 14 / 47

Cahier des charges d’un site Web

La définition des données présentées et acquises ain-

• Les données que l’on présente (propose) à l’internaute

Tous droits d'utilisation de ce cours est soumis à demande p. 15 / 47

Cahier des charges d’un site Web

Identifiant Nom Marque (le chiffre correspond à l'identi-

2 Une autre marque

Identifiant Couleur Descriptif

2 Rouge sang Rouge écarlate

Tous droits d'utilisation de ce cours est soumis à demande p. 16 / 47

Cahier des charges d’un site Web

Table de relation vêtement/couleur