Intégration web - Les bonnes pratiques

-

Livres
416 pages
Lire un extrait
Obtenez un accès à la bibliothèque pour le consulter en ligne
En savoir plus

Description

Intermédiaire entre le chef de projet, le designer et le développeur, intégrateur web (ou développeur front-end) est un métier à part entière. Maillon indispensable dans la création de sites, il rassemble tous les éléments pour monter les pages et livrer un site performant, accessible et utilisable. Son travail nécessite tout autant de compétences techniques en HTML, CSS et JavaScript qu'une bonne appréhension de la qualité web (ergonomie, accessibilité, performance...).



S'appuyant sur l'expérience de l'auteur, souvent appelée à la rescousse sur des projets mal engagés, ce livre offre aux intégrateurs débutants, comme aux plus expérimentés, un recueil précieux des meilleures pratiques, méthodes et outils pour améliorer et réussir leurs intégrations dans le respect des standards du Web.



Une référence pour tous les créateurs de sites web !



Avec une préface d'Elie Sloïm et Laurent Denis.




"Avec le mouvement d'industrialisation des métiers du Web, chaque métier voit émerger un livre de référence. Pour l'intégrateur web, c'est chose faite grâce à ce livre, qui représente un jalon important dans l'histoire de cette discipline en évolution permanente !"

Elie Sloïm, Président de Temesis et Directeur des projets Opquast et Openweb.





  • Bien préparer son projet


    • Organiser son espace de travail


    • S'équiper des bons outils


    • Mettre en place l'environnement de test




  • Elaborer un socle HTML solide


    • Adopter HTML5


    • Concevoir les fondations


    • Construire la structure


    • Injecter le contenu


    • Incorporer les images




  • Habiller le contenu grâce aux CSS


    • Réviser les bases


    • Définir une convention d'écriture


    • Organiser le code CSS


    • Prendre connaissance des facteurs d'optimisation


    • Contrôler et déboguer


    • Préparer la livraison (ou la mise en ligne)




  • Peaufiner les détails

Sujets

Informations

Publié par
Date de parution 25 octobre 2012
Nombre de visites sur la page 223
EAN13 9782212177220
Langue Français

Informations légales : prix de location à la page 0,0165 €. Cette information est donnée uniquement à titre indicatif conformément à la législation en vigueur.

Signaler un problème

DESIGN

Préface d’ÉlieSloïm& LaurentDenis

CorinneSchillinger

Intégration web
Les bonnes pratiques

L EG U I D ED ES U R V I ED EL’ I N T É G R A T E U R!

Intégration web

« Avec le mouvement
d’industrialisation des métiers
du Web, chaque métier voit
émerger un livre de référence.
Pour l’intégrateur web, c’est
chose faite grâce à ce livre, qui
représente un jalon important
dans l’histoire de cete discipline
en évolution permanente ! »
Élie Sloïm,
Président de Temesis
et Directeur des projets
Opquast et Openweb

DESIGN

Intermédiaire entre le chef de projet, le designer et le
développeur,intégrateur web(ou développeurfront-end) est
un métier à part entière. Maillon indispensable dans la création
de sites, il rassemble tous les éléments pour monter les pages
et livrer un siteperformant, accessible et utilisable. Son travail
nécessite tout autant de compétences techniques en HTML, CSS et
JavaScript qu’une bonne appréhension de la qualité web
(ergonomie, accessibilité, performance…).
S’appuyant sur l’expérience de l’auteur, souvent appelée à
la rescousse sur des projets mal engagés, ce livre offre aux
intégrateurs débutants, comme aux plus expérimentés, un
recueil précieux des meilleures pratiques, méthodes et outils
pour améliorer et réussir leurs intégrations dans le respect des
standards du Web.
Une référence pour tous les créateurs de sites web !

AU SOMMAIRE

Intégratrice senior et Experte AccessiWeb en
Évaluation,Corinne Schillingers’est forgée une solide
expérience dans le domaine du développement
front-endavant de créer son entreprise, Inseo, en
2009. Ayant à cœur de promouvoir les standards
et la qualité web, elle a intégré l’association Paris
Web en 2011, rejoint l’équipe éditoriale du Train de
13h37 et partage son expérience en animant
régulièrement des ateliers à l’occasion d’évènements
dédiés à la conception web.

Bien préparer son projet ໌Espace de travail ໌Outils : éditeurs et inspecteurs
de code, préprocesseurs, systèmes de gestion de versions…໌Environnement
de test : le « cas » Internet Explorer ໌Élaborer un socle HTML solide ໌HTML5
໌Fondations : compatibilité avec IE, styles CSS et interactions JavaScript,
métadonnées ໌Structure : balisage, sémantique et rôles ARIA, liens d’évitement ໌
Contenu : faut-il utiliser un framework ? ໌Images : formats, images
adaptatives, alternatives textuelles ໌Habiller le contenu grâce aux CSS ໌Schémas de
positionnement, cascade, propriétés abrégées ໌Convention d’écriture :
instructions, blocs de déclarations, commentaires… ໌Organiser
les règles CSS ໌Facteurs d’optimisation ໌Concevoir la
feuille de styles ໌Contrôler le rendu et l’accessibilité ໌
Préparer la livraison.

Code G13370
ISBN 978-2-212C-o13n3c7e0p-t7ion Nord Compo

Intégration
web :
les bonnes
pratiques
L EG U I D ED ES U R V I ED EL' I N T É G R A T E U R!

ÄÝ ½ ʽ½ã®ÊÄ Ý®¦Ä t

ÄÝ ½ ʽ½ã®ÊÄ ÊÊ» ÖÙã

«þ ½ Ãà ®ãçÙ

ÄÝ ½ ʽ½ã®ÊÄ Ý®¦Ä t

ÄÝ ½ ʽ½ã®ÊÄ ÊÊ» ÖÙã

«þ ½ Ãà ®ãçÙ

Corinne Schillinger

Intégration
web :
les bonnes
pratiques
L EG U I D ED ES U R V I ED EL' I N T É G R A T E U R!

P r é f a c ed ’ É l i eS l o ï m& La u r e n tD e n i s

ÉDITIONS EYROLLES
61, bld Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com

Remerciements à Virginie Caplet (http://cheekille.com) pour ses illustrations
d’ouverture de parties et à Renaud Scapin pour la réalisation des pictogrammes.

En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou partiellement
le présent ouvrage, sur quelque support que ce soit, sans autorisation de l’éditeur ou du Centre
Français d’Exploitation du Droit de Copie, 20, rue des Grands Augustins, 75006 Paris.

© Groupe Eyrolles, 2012
ISBN : 978-2-212-13370-7

PRÉFACE
Rappelez-vous. Il y a quelques années, la plupart des webmasters (car on les
appelait encore comme cela) utilisaient des logiciels comme Dreamweaver, Frontpage ou
Hotmetal pour créer leur sites Internet. Ces logiciels WYSIWYG(What You See Is What
You Get)permettaient de faire du code plus ou moins propre pour un navigateur
ultramajoritaire, en l’occurrence, Internet Explorer.
À cette époque, l’intégrateur n’existait pas et le webmaster n’avait pratiquement besoin
d’aucune compétence spéciique ni d’aucune formation : il était en pleine invention de
son métier, de ses outils et de ses technologies.
C’est alors que sont arrivées successivement les feuilles de styles et la séparation du
fond et de la forme. Le processus de création de site web s’est alors découplé en deux
phases successives : le design puis l’intégration. Ces deux activités ont longtemps été
assumées par des personnes aux proils similaires, avant que chacun des deux métiers
ne se constitue progressivement.

Intégrateur front-end est aujourd’hui un vrai métier et Corinne Schillinger nous le
prouve à travers l’exposé détaillé de son utilisation des technologies, de ses méthodes,
approches, processus, standards et pratiques. Il s’y dessine inalement un véritable
écosystème, un ensemble de relations entre métiers du Web, où l’intégrateur joue un
rôle clé.

L’intégrateur a une fonction pivot entre plusieurs compétences. On pense
immédiatement au découpage et à l’intégration HTML-CSS, ainsi qu’au développement JavaScript
côté client. En sus, on lui demande de maîtriser d’autres compétences beaucoup plus
variées : la gestion de la compatibilité multinavigateur, la maîtrise des questions de
performances, d’expérience utilisateur, la prise en compte d’ARIA en matière
d’accessibilité, le choix de recourir ou non à HTML5, etc.

L’intégrateur doit jongler avec les exigences du référencement, de la performance, de
l’ergonomie, de l’accessibilité, de la typographie, etc. Il doit en outre gérer la
diversiication des médias et des modes d’interaction : desktop, mobile, tablettes. Bientôt, il devra
certainement assumer la généralisation du tactile.

En tant que « qualiticiens », nous ne pouvons que conirmer cet état de fait : lorsque
nous travaillons sur les bonnes pratiques de la qualité web, bon nombre d’entre elles se
concentrent sur la phase d’intégration.

VI

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S

L’intégrateur front-end doit donc savoir maîtriser un grand nombre de standards, de
bonnes pratiques, de compétences, de méthodes, aussi bien du point de vue technique
que managérial. Il était plus que temps de rassembler tous ces éléments dans un livre.

Jusqu’à présent, les ouvrages existants se concentraient principalement sur des sujets
techniques, comme CSS, HTML, JavaScript. Là est la force de l’auteur : en plus de poser
les bases, de formaliser et de déterminer ce qui est de l’ordre du savoir minimal de
l’intégrateur, elle a su dépasser la technique pour aborder ces sujets sous l’angle métier.

La publication de livres comme celui de Corinne Schillinger est l’un des nombreux
signes que le processus d’industrialisation est en marche. Alors, oui, la connaissance
technique est fondamentale, mais, non, elle ne suit pas. Des experts techniques, il en
existe beaucoup, mais des personnes qui comprennent la philosophie qui sous-tend les
techniques et la façon de les déployer sont beaucoup plus rares. C’est pourquoi il faut
aller beaucoup plus loin.

Aujourd’hui, nous entrevoyons le moment où l’intégrateur va enin devoir aller au-delà
de la technique. Il est désormais celui qui doit accorder des violons souvent discordants,
entre les exigences du design, du référencement, de la DSI... Il commence à en acquérir
les moyens avec l’industrialisation du Web. Il est appelé à devenir de plus en plus un
manager de solutions, appuyé sur une maîtrise rigoureuse des techniques et surtout des
clés de décision.

D’une certaine manière, au même titre que les autres professionnels du projet web,
l’intégrateur devient un véritable gestionnaire de risques. Les risques auxquels il doit
faire face et qu’il sera de plus en plus amené à gérer sont particulièrement critiques pour
les clients et les utilisateurs inaux.

Avec cette évolution, l’intégrateur se servira diféremment de ses références techniques
actuelles. Il aura rarement à produire du code : le cœur de son métier sera de choisir
des solutions. Il n’est déjà plus un simple exécutant opérationnel : il lui revient de plus
en plus souvent d’arbitrer sur le choix des formats, sur celui d’un framework JavaScript,
voire d’un framework CSS, ou même sur la décision quant au CMS à utiliser.

Au terme de cette maturation du métier, sa compétence proprement technique pourra
alors être réservée aux seuls cas où une certaine forme d’expertise sera requise pour des
solutions sur mesure.

P R É F A C E

Gageons que si le mouvement d’industrialisation des métiers du Web se poursuit, il faut
s’attendre à l’émergence de livres de référence sur chacun des principaux métiers du
Web. Pour ce qui est du métier d’intégrateur, l’ouvrage que vous avez entre les mains
sera à l’évidence l’un de ces livres de référence et, au minimum, un jalon important dans
l’histoire de ce métier en évolution permanente.

Élie Sloïm (Président de Temesis, Directeur des projets Opquast et Openweb)
et Laurent Denis (Expert accessibilité)

VII

TABLE DES MATIÈRES





















1
1
1
2
4

7

9
10
10
11
11
13
14
15
15
16
16
20
21


23
24
24
25
25
26
27
28

Avant-Propos
À qui s’adresse ce livre ?
Pourquoi ce livre ?
Comment le livre est-il organisé ?
Remerciements
Partie 1
Bien préparer son projet
Chapitre 1
Organiser son espace de travail
Arborescence : créer un dossier par projet
Avoir tous les éléments à portée de main
Organiser les répertoires en fonction du type de ichiers
Cas particulier : les images
Adopter une convention de nommage
Exemples de règles de nommage
Où placer la convention de nommage ?
Qualité : mettre en place une checklist détaillée
Index des maquettes
Évaluation individuelle des pages
Évaluation transversale de l’intégration
Rédiger la checklist au format Markdown

Chapitre 2
S’équiper des bons outils
Les éditeurs de code
Zen Coding
Produire du HTML
Produire du code CSS
Les préprocesseurs CSS
Les variables
Les déclarations imbriquées

X

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S

































29
31
32
34
35
36
37
37
39
39
40
41
41
41
41
41
41
42
42
42
42
42
43
43
43
43
44
44
44
45
45
45
45


47
48
48
49

L’héritage
Les fonctions mathématiques
Les inspecteurs de code
Édition des éléments HTML et des styles CSS
Débogage du code JavaScript
Validation du code HTML et CSS
Analyse des performances
Visualisation du temps de chargement
Le système de gestion de versions
Organiser logiquement les commits
Outils en ligne
Outils pour le HTML
CopyPasteCharacter
HTML-Ipsum
Outils pour les CSS
CSS3 Generator
ProCSSor
CSS Lint
Outils pour améliorer les performances
WebPagetest
SPOF-o-Matic
Ressources et outils pour la qualité web
Les bonnes pratiques Opquast
Opquast Reporting
Outils de vériication et de validation
Validateurs HTML et CSS
Contrôleur JavaScript : JSLint
Vériicateur de liens
Validateur pour les lux de syndication (Atom, RSS)
Ressources diverses
DocHub
Le wiki du W3C
JsFiddle

Chapitre 3
Mettre en place l’environnement de test

Quelles conigurations tester ?
Le panel de test
Le contexte projet
































50
51
53
53
53
54

55
55
55
55
56
56
57

57
58
58
59
59
60
61

62
62
62
63
63
64
64
64

65
66
66
66

TA B L ED E SM AT I È R E S

Le « cas » Internet Explorer
L’aichage de compatibilité
Les installations multiples
IETester
IE Collection
Google Chrome Frame
Les services en ligne
Les services de captures d’écran
Browsershots
BrowserLab
Les services d’accès à distance
Sauce Labs
CrossBrowserTesting
La virtualisation
Des conditions de test réelles
Une grande lexibilité
Contraintes liées aux systèmes d’exploitation
Windows
Mac OS
Linux
Les terminaux mobiles
WebKit
Android
iPhone/iPad
Windows
Opera
Opera Mobile
Opera Mini
Les technologies d’assistance
JAWS
NVDA
VoiceOver

XI

XII

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S


69

71
72
72
72
77
77
77
78
78
79
80
82
82
83
83
84
85
85
85
86
88
88
89
90
90
92
96
97


99
100
100

Partie 2
Élaborer un socle HTML solide
Chapitre 4
Adopter HTML5
Prendre connaissance des diférentes contraintes
L’instabilité de la spéciication
Les problèmes d’accessibilité
Tirer parti des évolutions apportées
Une charpente HTML simpliiée
Un Doctype raccourci
Un en-tête de document allégé
Un gabarit minimaliste
Les éléments redéinis
<a>
<cite>
<b>
<i>
<small>
Les nouveaux champs de formulaire
<input type="email" />
<input type="tel" />
<input type="url" />
Les problèmes d’implémentation
Exploiter les nouveaux attributs
Lier des valeurs à un élément grâce à data-*
Manipuler les données en JavaScript
Ajouter du sens avec les microdonnées
Un peu d’histoire : RDFa et les microformats
Découvrir les attributs spéciiques
Quelle syntaxe adopter : HTML ou XHTML ?
En résumé

Chapitre 5
Concevoir les fondations

Gérer les diférentes versions d’Internet Explorer
Éviter l’emploi de hacks CSS



















102
102
102
103
105
106
109
109
109
110
111
112
112
114
114
116
116
119
119


121
122
122
123
125
126
126
127
127
129
130
131

TA B L ED E SM AT I È R E S

Éviter d’avoir recours à une feuille de styles dédiée
Les problèmes de performance
Les problèmes de maintenance
S’appuyer sur une classe CSS conditionnelle
Placer la classe à la racine de la page
Se limiter aux cas « utiles »
Préparer les inclusions CSS et JavaScript
Choisir la méthode la plus adaptée
Les instructions inline
Les instructions internes
Les instructions externes
Positionner les appels suivant leur nature
Les styles dans l’en-tête de document head
Les scripts à la in du contenu body
Prévoir le cas où JavaScript est désactivé
Ajouter les métadonnées dans l’en-tête de document
La balise meta viewport
La balise meta description
En résumé

Chapitre 6
Construire la structure
Organiser la page
Identiier les zones principales
Mettre en place le balisage
Faut-il préférer les classes aux identiiants ?
Spéciier le rôle des éléments grâce à ARIA
À quoi sert ARIA ?
Améliorer l’accessibilité des interfaces riches
Doter les éléments de structure d’une valeur sémantique
Ajouter les rôles au balisage en place
Mettre en place les liens d’évitement
Valider la structure

XIII

XIV

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S


133
134
134
138
139
139
140
144
146
148
150
152
155


157
158
159
162
163
166
167
168
169
170
170
174
175
176
177
180
181
182
185
187

Chapitre 7
Injecter le contenu
Faut-il utiliser un framework ?
Les frameworks CSS
Les frameworks HTML
Mettre en place le balisage
Établir une hiérarchie de titres logique
Sélectionner les balises pour leur valeur sémantique
Éviter l’emploi de <a href="#"> comme bouton d’action
Le cas particulier de <br />
Nommer les balises judicieusement
Éviter l’ajout d’éléments superlus
Utiliser des motifs déjà éprouvés
Valider le contenu

Chapitre 8
Incorporer les images
Multiplicité des supports : les images adaptatives
L’emploi de l’élément noscript
Le kit « adaptative image »
L’instruction max-width: 100%;
Choisir le bon format d’image
Le format GIF
Gérer la transparence
Optimiser pour le Web
Le format PNG
PNG 8
PNG 24
Optimiser pour le Web
Le format JPEG
Optimiser pour le Web
Quel format choisir ?
Renseigner correctement l’alternative textuelle
Les liens et boutons images
Les représentations graphiques
Les images d’illustration


191

193
194
194
195
195
195
196
197
197
197
198
198
198
199
200
201
202
203
203
205
207
208
209
211


213
214
214
215
217
217

TA B L ED E SM AT I È R E S

Partie 3
Habiller le contenu grâce aux CSS
Chapitre 9
Réviser les bases
Les schémas de positionnement
La notion de lux
Positionnement lottant : la propriété loat
Positionnement statique
Positionnement relatif
Positionnement absolu
Positionnement ixe
Quel positionnement choisir en priorité ?
Erreur courante à éviter
La cascade CSS
L’origine de la règle
La spéciicité d’une règle
La valeur !important
Les propriétés abrégées
Marges : margin et padding
Contours : outline
Bordures : border
Angles arrondis
Bordures en image
Listes : list-style
Polices de caractères : font
Arrière-plan : background
Arrière-plans multiples

Chapitre 10
Déinir une convention d’écriture
Agencer les instructions
Éviter de regrouper plusieurs instructions sur une seule ligne
Aller à la ligne avant chaque instruction
Hiérarchiser les blocs de déclarations
Par ordre alphabétique

XV

XVI

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S

218
220
220
222
223
224


227
228
228
229

232
233
234
235
236
236
236
238

240
241
241

241


243
244
244
245
247
248
248
249

Par ordre fonctionnel
Préciser le rôle des commentaires
Rédiger les commentaires au format CSSDoc
Les blocs d’identiication
Les blocs de documentation
Faire connaître la convention élaborée

Chapitre 11
Organiser le code CSS
Préciser le contexte projet
Tenir compte de la nature du site
Choisir l’approche « traditionnelle » pour les sites peu
ou pas réactifs
Uniformiser les styles par défaut
Élaborer la charte typographique
Mettre en place la structure générale
Styler les composants internes
Ajouter les styles relatifs aux comportements JavaScript
Corriger l’aichage sur les anciennes versions d’Internet Explorer
Adapter l’aichage grâce aux media queries
Appliquer le principe de l’amélioration progressive pour un site
adaptatif
Utiliser la version mobile comme base commune
Ajouter les styles destinés aux autres terminaux
Servir (si nécessaire) des images adaptées à la densité de pixels du
terminal
Assurer la rétrocompatibilité sur les anciens navigateurs

Chapitre 12
Prendre connaissance des facteurs d’optimisation
Comprendre comment les règles CSS sont appliquées
Les règles CSS sont triées en fonction de leur type
Les sélecteurs sont lus de droite à gauche
Les sélecteurs courts sont les plus performants
Concevoir des règles eicaces
Limiter l’emploi de règles universelles
Utiliser des sélecteurs courts et eicaces

251
252
255
255

256
261


265
266
267
267
271
274
274
275
276
276
276
280
285
285
286
288
294
301
304
306
307
308
308
311
313
313
314

TA B L ED E SM AT I È R E S

Éviter de redéinir inutilement la valeur de certaines propriétés
Factoriser les instructions
Ne pas tomber dans l’excès d’optimisation
Diminuer le nombre de requêtes nécessaires à l’aichage des
images
Utiliser la technique des sprites
Employer les data URI en complément

Chapitre 13
Élaborer les règles CSS
Se renseigner sur les propriétés autorisées
Employer les propriétés CSS3 à bon escient
Penser à spéciier tous les préixes propriétaires
Fournir une alternative aux vieilles versions des navigateurs
Uniformiser les styles navigateurs
Réinitialiser les styles dans leur globalité
Appliquer des correctifs ciblés
Concevoir la charte typographique
Choisir une unité pour déinir la taille de police et son interlignage
Éviter l’utilisation du pixel
Préférer l’emploi d’unités relatives
Procéder avec méthode pour ajouter une police personnalisée
Vériier les droits accordés par la licence
Contrôler le rendu de la fonte sur les diférentes conigurations
Décliner la fonte en plusieurs formats
Élaborer le bloc d’instructions
Rendre visible la prise de focus
Le cas particulier des liens images
Organiser les blocs de structure et styler les composants
Ajouter les règles relatives aux comportements JavaScript
Les subtilités de l’approche « mobile irst »
Utiliser la version mobile comme point de départ
Ajouter les styles destinés aux autres terminaux
Masquer certains éléments de contenu aux terminaux mobiles
Déinir des points d’arrêt pour passer d’une version à l’autre
Servir (si nécessaire) des images adaptées à la densité de pixels du
terminal

XVII

XVIII

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S

318
318
319
320
321
322
323
323


327
328
328
328

329
330
331
332
333
333

335
335
337
337
337
338
338

345

347
348

Assurer la rétrocompatibilité sur les anciens navigateurs
Les solutions JavaScript
La solution CSS pour Internet Explorer
Élaborer la feuille d’impression
Appliquer les styles génériques
Masquer les éléments superlus
Linéariser le contenu
Ajouter quelques règles complémentaires

Chapitre 14
Contrôler et déboguer
Contrôler le rendu
Prendre l’aichage d’un navigateur moderne comme référence
Surveiller le rendu des navigateurs obsolètes
pendant le développement
Résoudre les problèmes détectés
Valider le code
Identiier l’élément incriminé
Isoler la ou les instructions problématiques
Corriger le problème
Vériier le rendu sur Internet Explorer par ordre de version
décroissant
Tester les gabarits
Détecter certaines erreurs HTML grâce une feuille de débogage
Simuler l’indisponibilité des ressources
Les images
JavaScript
Tester la navigation clavier
Agrandir la taille de caractères
Partie 4
Préparer la livraison (ou la mise en ligne)
Chapitre 15
Peauiner les détails

Réaliser les dernières optimisations

348
349
349
350
351
352
353
354
355
356
357
357
358
360
361
361
362
362
363
365
367
368
369
378
380
384
389

TA B L ED E SM AT I È R E S

Les images
Le code CSS et JavaScript
Concaténer les diférents ichiers
Miniier les ichiers obtenus
Proposer quelques règles de coniguration serveur
Conigurer les en-têtes HTTP
Indiquer que le codage de caractères utilisé est utf-8
Renseigner le type MIMEde certains ichiers
Autoriser l’utilisation de fontes hébergées sur un domaine tiers
Interdire le mode de compatibilité sur Internet Explorer
Optimiser les performances
Compresser les ichiers
Contrôler la date d’expiration d’une ressource mise en cache
Supprimer les ETags
Renforcer les paramètres de sécurité
Restreindre l’accès aux ichiers sensibles
Interdire l’exploration des répertoires n’ayant pas d’index
Éviter certains problèmes de contenu dupliqué
Personnaliser les pages d’erreur
Annexes
Annexe A1

Annexe A2

Annexe B

Annexe C

Annexe D

Annexe E

Index

XIX

AVANT-PROPOS
Avant d’entrer dans le vif du sujet, permettez-moi de vous présenter cet ouvrage en
quelques mots.

À qui s’adresse ce livre ?
Ce livre s’adresse à tous les intégrateurs, professionnels ou amateurs, qui ont à cœur de
réaliser une intégration qui soit aussi propre, accessible et performante que possible. Il
se veut clair et exhaustif, sans toutefois reprendre les bases fondamentales des langages
HTML et CSS. De ce fait, il risque d’être assez diicile d’accès aux débutants
souhaitant découvrir les joies du code, car il requiert une connaissance minimale de ces deux
langages pour pouvoir être pleinement exploité.
Malgré tout, il cible un public relativement large puisqu’il est destiné à toutes les
personnes qui ont envie de produire un code de qualité : les étudiants souhaitant
approfondir leurs cours devraient y trouver leur compte tout autant que les professionnels
aguerris désirant mettre leurs connaissances à jour.

Pourquoi ce livre ?
La qualité globale d’un site repose bien souvent sur des points de détail qui ont un
impact positif ou négatif sur son utilisabilité, son accessibilité et ses performances
d’aichage. Et bien que les outils et techniques aient considérablement évolué ces dernières
années, l’intégration est une discipline qui reste encore très artisanale : son résultat
luctue en fonction des connaissances de l’intégrateur.
Or, bien souvent, il ne manque pas grand-chose pour que la qualité de l’intégration soit
considérablement améliorée : spéciier un changement de langue, prévoir
l’indisponibilité d’une ressource ou tirer parti de l’héritage en sont quelques exemples.
Forte de ce constat, j’ai mûri l’idée de créer une sorte de recueil de bonnes pratiques
de l’intégration web. Mais ce n’est qu’une fois le travail rédactionnel commencé que
je me suis rendue compte de l’ampleur réelle de la tâche. Car même si certains usages
sont considérés comme étant de bonnes pratiques, beaucoup restent à la discrétion du
développeur : l’intégration n’est pas une science exacte, elle dépend d’une multitude de
paramètres qui en font une discipline aussi complexe qu’intéressante.

2

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S

L’écriture de ce livre aura donc été l’occasion d’une remise en cause de mes méthodes de
travail. Le plus diicile aura été d’évaluer la pertinence réelle de ma méthode, car même
si elle me convenait parfaitement, rien ne pouvait me laisser penser qu’il s’agisse de la
« meilleure » façon de faire. Je me suis donc posée de nombreuses questions, ai discuté
avec d’autres professionnels, et ai souvent changé d’avis devant la justesse des
arguments avancés. Vous tenez entre vos mains le fruit de ces dix-huit mois de recherches,
de questionnements, d’introspection et de discussions passionnantes avec des
intégrateurs de tous bords.

Durant ce laps de temps, la technique a évolué et des méthodes qui étaient autrefois
conseillées sont aujourd’hui considérées comme de mauvaises pratiques : dix-huit mois
dans un domaine où les techniques évoluent constamment, c’est beaucoup. Et s’il
s’agitlà de la première version papier, sachez que certaines parties en sont au moins à leur
troisième mise à jour : je n’ai eu de cesse de réactualiser le contenu pour assurer la
véracité des informations qui y igurent.

C’est pourquoi j’espère sincèrement que ce livre répondra à vos attentes. S’il vous permet
d’approfondir de nouvelles techniques, de vous mettre à niveau, de prendre
connaissance de certains efets de bord indésirables ou de découvrir une nouvelle
méthodologie, j’aurai gagné mon pari.

Comment le livre est-il organisé ?
Ce livre est organisé dans un ordre logique qui respecte les diférentes étapes devant
être efectuées pour mener à bien une intégration. Ces dernières sont réparties en quatre
parties que sont la préparation en amont, la conception du contenu HTML, la mise en
forme CSS et la préparation des livrables.
Vous aurez certainement remarqué qu’aucune partie n’est dédiée à JavaScript. Pourtant, il
y aurait de quoi faire : un livre entier pourrait même être consacré à ses bonnes pratiques
de développement. Mais je n’estime pas avoir les compétences suisantes pour pouvoir
l’aborder avec le degré d’expertise que je souhaiterais. C’est pourquoi je préfère laisser
cette tâche à un développeur JavaScript qui saura le faire bien mieux que moi.
Pour autant, cela ne signiie pas que la question de son utilisation ne soit pas abordée :
son emploi impose de nombreuses contraintes qui sont évoquées tout au long de ce
livre. Car même si l’intégrateur ne développe pas lui-même les fonctions, il se doit de

AVA N T- P R O P O S

maîtriser les bases du langage et de pouvoir concevoir certaines interactions à l’aide (ou
non) d’un framework.

La méthode présentée ici n’a pas vocation à devenir universelle : je doute d’ailleurs
qu’aucune méthode ne fasse jamais cette unanimité. Elle tend plutôt à être aussi
exhaustive que possible et aborde toutes les étapes qui peuvent afecter la qualité inale de
l’intégration. C’est pourquoi ce livre débute avec l’organisation de l’espace de travail et
se termine avec la préparation des livrables. Tout au long de son développement, vous
retrouverez ces notions d’accessibilité, de sémantique, de lisibilité, de maintenabilité et
de performance qui composent ce tout qu’est la qualité web.

3

4

I N T É G R AT I O NW E B: LE SB O N N E SP R AT I Q U E S

REMERCIEMENTS
Si je m’écoutais, je remercierais la terre entière pour la chance qui m’a été donnée de
concrétiser cette opportunité. Je commencerais d’ailleurs par ma maman, sans qui rien
de tout ça n’eut été possible. Mais s’agissant d’un livre professionnel, je crains
malheureusement que cela ne soit guère adapté... Je vais donc me restreindre aux personnes
qui ont donné de leur temps et n’ont pas hésité à partager leur expertise pour que ce
livre puisse voir le jour. Si cet ouvrage vous plaît, c’est aussi à toutes ces personnes que
vous le devez : sans leurs remarques constructives, leurs encouragements et leur
disponibilité, vous n’auriez certainement pas ce livre entre les mains.
Occasionnels ou au long court, les relecteurs ont eu la lourde de tâche de vériier
l’exactitude de mes assertions. Ils ont relevé les erreurs, approximations et incohérences qui
avaient échappé à ma vigilance, et m’ont conseillé de nombreux ajouts très pertinents.
C’est pourquoi je tiens à remercier chaleureusement :
ƉAnthony Ricaud, Laurent Denis, Loïc Mathaud et Sébastien Delorme, pour avoir
gentiment accepté de se prêter au jeu ;
ƉVincent Valentin, qui a trouvé un peu de temps entre deux biberons pour me relire et
répondre à mes interrogations diverses et variées ;
ƉJérémie Patonnier, pour avoir passé de longues heures, tard le soir, à relire plusieurs
chapitres et pour m’avoir fait de nombreux retours toujours très judicieux, bien qu’un
peu « bruts de décofrage » parfois ;
ƉEt enin, Marie Alhomme qui a accepté de relire ce livre dans son intégralité. Je la
remercie du fond du cœur pour tout le temps qu’elle y a consacré et les longs moments
passés à discuter détails techniques, méthodologie et bonnes pratiques.
Dans un registre diférent, je tiens également à remercier :
ƉNoëlie Amiot pour ses éclairages sur certains points techniques ;
ƉÉlie Sloïm et Laurent Denis qui m’ont fait l’honneur de rédiger à quatre mains la préface
de cet ouvrage ;
ƉVirginie Caplet, une graphiste de talent, qui a accepté — pour mon plus grand bonheur —
de réaliser les magniiques illustrations qui introduisent les parties principales de ce livre ;
Ɖles éditions Eyrolles pour m’avoir fait coniance, et plus particulièrement Karine Joly qui
a fait preuve d’une patience sans borne, acceptant sans mot dire mes retards de
livraison et n’ayant de cesse de m’encourager jusqu’à la dernière minute ; Sophie Hincelin et

R E M E R C I E M E N T S

Géraldine Noiret qui ont repris le projet juste avant sa inalisation et se sont démenées
pour le boucler dans les temps ;
ƉEt surtout Yannick — mon homme — qui m’a incitée à me lancer dans cette aventure,
soutenue de la première ligne jusqu’à la dernière relecture, rassurée quand j’étais en pleine
phase de doute, et supportée même lorsque des nuits bien trop courtes me rendaient
absolument exécrable. Si j’ai réussi à mener ce projet à son terme, c’est surtout grâce à lui.

5

BIEN
PRÉPARER
SON PROJET





On estime bien souvent que l’intégration d’un site web débute
avec la conception du code HTML/CSS. Or si le code est très
certainement la partie la plus visible du site, il est important de
ne pas considérer la préparation du projet comme une simple
formalité qu’il est possible d’expédier. Qu’il s’agisse de
l’organisation des éléments (ichiers et répertoires), du choix des outils ou
de la mise en place de l’environnement de test, toutes les étapes
préparatoires doivent faire l’objet de la plus grande attention.

PARTIE
1

1
Organiser son espace
de travail
Une arborescence logique et facilement compréhensible, une règle
de nommage appliquée à l’ensemble des composants ou encore la
présence d’une iche de suivi à la racine du projet participent
pleinement à la qualité globale du site et contribuent à simpliier son
évolution future. Ainsi, même s’il n’existe aucune règle absolue à suivre, ni
aucune organisation qui soit parfaite, il est important de réléchir à
la façon dont le projet va être organisé, avant de rédiger la moindre
instruction.

Dans ce chapitre
ƉArborescence : créer un dossier par projet
ƉUniformité : adopter une convention de nommage
ƉQualité : mettre en place une checklist détaillée

10

PA R T I E1 – BI E NP R É PA R E RS O NP R O J E T

ARBORESCENCE : CRÉER UN DOSSIER PAR PROJET

Avoir tous les éléments à portée de main
La première chose à faire avant de démarrer une nouvelle intégration est de préparer
l’espace de travail. L’idéal est de rassembler tous les éléments relatifs à un projet dans
un même dossier ou répertoire. Il suit simplement d’organiser à l’intérieur de celui-ci
une arborescence claire dans laquelle viendront se placer les documents. En
centralisant ainsi toutes les données, vous ne perdrez pas de temps à chercher des éléments
manquants ou à vériier que vous vous référez à la dernière version des spéciications.
De même, un collègue arrivant sur le projet en cours de route aura une vue exhaustive
du projet et de son avancée.
Bien sûr, chaque intégrateur a sa façon de faire et son propre système d’organisation.
L’essentiel étant qu’il s’y retrouve et qu’une personne tierce ne soit pas perdue dans
l’arborescence. Voici par exemple une classiication en trois dossiers, qui permet de
répartir simplement tous les éléments du projet.
ƉLe dossiersourcesaccueille les documents utiles à l’intégration. Il peut s’agir du code à
reprendre, des maquettes à intégrer ou encore des textes à publier. Suivant le nombre
d’éléments (et surtout de maquettes), il peut être utile d’avoir recours à des sous-dossiers.
ƉLe dossierspecl’ensemble des spéciications fonctionnelles du projet. Y recueille
prennent place le cahier des charges, le zoning, l’arborescence ou encore les demandes
d’évolution.
ƉEnin, le dossierwwwest réservé à l’intégration proprement dite. Il constitue la racine
du site web et contient l’ensemble des éléments qui vont être livrés ou mis en ligne, au
contraire des sources et des spéciications qui ne seront pas poussées en production.
Certains préfèrent, pour plus de clarté, rassembler l’ensemble des ressources en ligne.
Indispensable pour les gros projets (longs de plusieurs mois, sur lesquels interviennent
plusieurs personnes en parallèle), cette organisation présente le défaut de nécessiter une
connexion Internet lorsque vous travaillez. Ce qui n’est pas toujours le cas si vous êtes
en situation de mobilité ou si vous faites les frais d’une coupure temporaire.

GLOSSAIREcomposants d’un projet Les
Chaque nouvelle intégration amène son lot d’éléments à analyser. Détaillant le projet dans son
ensemble ou traitant de points particuliers, les spéciications sont généralement composées de
plusieurs documents : présentations, textes, images, graphiques...

Lecahier des charges(oubrief) est sans conteste l’élément le plus important de toutes les
spéciications : il sert de il conducteur au projet et fait référence en toute situation. Il décrit entre
autres les objectifs à atteindre, la forme du livrable, les critères d’évaluation, les contraintes à
respecter, le délai de réalisation et, bien sûr, le résultat attendu.

1 – OR G A N I S E RS O NE S PA C ED ET R AVA I L

L’arborescence (ouarchitecture) se concentre uniquement sur l’organisation du site.
Généralement représentée sous la forme d’un arbre inversé, elle permet de visualiser
rapidement l’agencement des pages et les interactions qui les lient les unes aux autres.
Lezoningschématise l’organisation générale d’une page en identiiant les diférentes zones à
l’aide de blocs (voir l’annexe A1). Il permet d’illustrer le fonctionnement global et de dégager
les zones de contenu principales. Chaque zoning s’attachant à un seul type de page (page
d’accueil, page de contenu…), il est fréquent d’en avoir plusieurs pour un même site.
Établi à partir du zoning, lewireframe(ou maquette il de fer) met en avant le contenu. Les
zones précédemment identiiées sont remplies et leur contenu est organisé de la manière la
plus fonctionnelle et ergonomique possible (voir l’annexe A2).
Partant de l’agencement validé dans le wireframe, le graphiste imagine et réalise un univers
propre à la marque qui véhicule ses valeurs et son identité. Il s’agit de lamaquette graphique.

Organiser les répertoires en fonction du type de fichiers
Une fois que l’arborescence est en place et que les éléments sont répertoriés, il convient
de préparer le dossier d’intégration (wwwdans notre exemple).
Il arrive que l’organisation générale soit fournie par le client. C’est souvent le cas lorsqu’il
s’agit d’une refonte et qu’il n’est pas envisageable de modiier le système de dossiers
utilisé. En l’absence de consignes particulières, il est important de regrouper les ichiers
suivant leur type et leur fonction.
Bien que certains usages se soient mis en place, il n’existe aucune règle stricte
concernant le nommage des éléments. Ainsi, il est fréquent de rencontrer plusieurs approches
diférentes : l’emploi de noms très courts (iles images, poursles scripts, etc.), pour
de noms complets (images,scripts, etc.) ou encore de noms abrégés (img,js, etc.). Au
inal, les noms utilisés importent relativement peu, du moment qu’ils sont courts et
explicites. C’est pourquoi la tendance générale consiste à privilégier les appellations
raccourcies et à utiliser l’extension de ichier comme nom de dossier :css,js,swfou
encore». Cette façon de faire est un bon compromis entre les performances et la
lisibilité des noms abrégés.

Cas particulier : les images
Au cours d’une intégration, trois types d’images sont à distinguer : les images de contenu,
les images décoratives et les images temporaires ou contribuables.

Les images de contenu

Porteuses de sens, elles font partie intégrante du code HTML : c’est le cas d’un logo ou
d’une icône de menu. Généralement, elles sont enregistrées dans un dossierimgla à
racine du dossier d’intégration. Bien sûr, ce dernier peut contenir l’un ou l’autre
sous

11

12

PA R T I E1 – BI E NP R É PA R E RS O NP R O J E T

dossier (commeiconeoupicto), pour regrouper certaines images en fonction de leurs
similitudes.

Les images décoratives
Utilisées pour la mise en forme du document, elles sont appelées depuis le code CSS.
Certains les enregistrent dans un dossierimgà la racine decss. Une autre manière de
faire consiste à les placer dans un dossierthemedans directementwww. Ainsi, il suit
d’ajouter un sous-dossier pour chaque nouveau thème ou déclinaison saisonnière
(comme les fêtes de Noël ou la période des soldes).

BONNE PRATIQUE Utiliser les classes et identifiants comme noms d’images

Nommer les images avec les noms de classes et d’identiiants qu’elles habillent permet d’établir
un lien entre le code et les images. La gestion des ressources en est ainsi facilitée, puisque
chaque élément peut aisément être relié à la structure HTML et aux styles CSS.
#footer { background: url("../theme/footer.jpg") repeat-x 0 100%; }

Les images temporaires (ou contribuables)
Issues de la maquette, elles sont généralement employées par le graphiste pour illustrer
l’une ou l’autre mise en situation. Il peut par exemple s’agir d’un avatar, d’une
illustration d’article, ou encore de la capture d’une vidéo. Faciles à identiier, elles doivent être
stockées dans un dossier distinct qui ne sera pas mis en production. Dans notre
arborescence, le dossiertmpse trouve à la racine dewww. Nous y plaçons l’ensemble des éléments
temporaires (images, sons, vidéos...) utilisés au cours de l’intégration.

CONSEIL Employerdes images factices

Dummy Image(Dynamic Dummy Image Generator)est un générateur d’images factices. Générées
suivant les paramètres passés dans l’URL, les images peuvent être utilisées pour remplacer les
ichiers temporaires. Ainsi, il n’est plus nécessaire d’exporter des éléments qui ne seront pas
utilisés en production. Cela permet surtout d’attirer l’attention du client sur ses futures
contributions (les dimensions du visuel étant incluses dans l’image).
http://dummyimage.com

CONSEILun « dossier projet » type Créer

Une fois que vous avez opté pour une arborescence qui vous convient et avec laquelle vous
vous sentez à l’aise, enregistrez-la soigneusement, car il est fort probable que vous la réutilisiez
sur l’ensemble de vos intégrations ultérieures. Ne perdez donc pas de temps à repartir de zéro
à chaque fois : dupliquez plutôt cette arborescence au démarrage de chaque nouveau projet.

1 – OR G A N I S E RS O NE S PA C ED ET R AVA I L

Fig. 1-1 : Exemple d’arborescence réutilisable à chaque nouveau projet

Adopter une convention de nommage
L’une des erreurs les plus fréquentes en intégration est sans nul doute l’erreur
d’inattention. Qui n’a jamais passé de longues minutes à essayer de déboguer un élément au
comportement étrange, avant de se rendre compte qu’une erreur s’était glissée dans
l’appel du sélecteur ?
L’absence de convention de nommage standardisée force les intégrateurs à inventer la
leur. Malheureusement, rares sont ceux qui se ixent un ensemble de règles à suivre et
qui les appliquent d’un bout à l’autre du projet. Bien souvent, chacun établit ses règles
de manière plus ou moins arbitraire sans réelle rélexion : les singuliers sont mélangés
aux pluriels, l’anglais au français, les traits d’union côtoient les tirets bas et les
majuscules sont utilisées sans raison apparente.
Un bon moyen pour diminuer le risque d’erreurs est de mettre en place une
nomenclature stricte que l’on applique à tous les composants du projet : dossiers, ichiers et
sélecteurs. Cela évite les allers-retours inutiles pour vériier si le nom de ichier est en
anglais ou en français, ou pour savoir exactement à quels endroits placer les tirets de
séparation. Il est possible que certains y trouvent peu d’intérêt et considèrent qu’une
bonne logique personnelle suit amplement. Mais c’est sans compter les personnes qui
reprendront le projet une fois l’intégration terminée : il y a fort à parier qu’un
déve

13

14

PA R T I E1 – BI E NP R É PA R E RS O NP R O J E T

loppeur ait à dynamiser le tout ou qu’une tierce personne soit en charge de la
maintenance. En les prenant en considération, vous leur rendrez un ier service !

BONNE PRATIQUE Demanderconseil au développeur

Suivant le système de gestion de contenus utilisé, il est fort probable qu’un certain nombre
de classes, d’identiiants et d’usages soient prédéinis. Demandez au développeur de vous les
donner et prenez-en connaissance avant de iger vos règles de nommage. Vous lui éviterez
ainsi une surcharge de travail et il vous en sera reconnaissant.

Exemples de règles de nommage
Une nomenclature n’a pas besoin d’être très verbeuse. Il s’agit de faire simple et
compréhensible. Une liste d’airmations accompagnées d’exemples telle que celle présentée
ci-après est donc largement suisante.
ƉEmployer des noms anglais pour tous les éléments, car la v2 sera multilingue :.alert
au lieu de.alerte.
ƉIndiquer tous les noms au singulier :.slideau lieu de.slides.
ƉUtiliser uniquement le trait d’union - :.open-popinau lieu de.open_popin.
ƉDonner des noms pertinents aux éléments :ɤau lieu de#block-block-1.
ƉUtiliser les classes et identiiants comme noms d’images :body.jpgau lieu defond.jpg.
ƉPrivilégier les intitulés courts :#slideshow-controlau lieu de#playpause_slideshow_
slider_block-3.
ƉDiférencier le premier élément d’une liste plutôt que le dernier, car c’est plus facile à
programmer que l’inverse.

À préférer
<ul>
<liclass="first">Premier item</li>
<li>Deuxième item</li>
<li>Troisième item</li>
</ul>

À éviter
<ul>
<li>Premier item</li>
<li>Deuxième item</li>
<liclass="last">Troisième item</li>
</ul>

ƉClasses et identiiants à employer :
– #breadcrumbpour le il d’Ariane ;
– #searchpour le formulaire de recherche générique ;
– .submitpour les éléments de soumission de formulaire ;
– ŜŞpour les éléments visibles aux seules technologies d’assistance.

Où placer la convention de nommage ?

1 – OR G A N I S E RS O NE S PA C ED ET R AVA I L

Une fois la convention de nommage établie, placez-la à la racine du dossier projet ain
que chaque intervenant puisse en prendre connaissance et se l’approprier. En la rendant
ainsi accessible, vous augmenter vos chances d’avoir un projet uniforme de bout en
bout, et ce, quel que ce soit le nombre de personnes prenant part au projet.

QUALITÉ : METTRE EN PLACE UNE CHECKLIST DÉTAILLÉE
Lachecklistde vériier méthodiquement certains points récurrents à prendre permet
en compte lors de l’intégration. Bien qu’elle ne puisse pas garantir la qualité d’un site
à 100 %, elle y contribue fortement. Le rendu navigateur, l’accessibilité, la conformité
et la performance y trouvent naturellement leur place, mais vous pouvez bien sûr y
ajouter d’autres paramètres spéciiques au projet, comme le détail des fonctionnalités à
implémenter.
La liste proposée ici est le résultat d’un recoupement de trois listes distinctes : les bonnes
pratiques en intégration d’Opquast (voir la section « Les bonnes pratiques Opquast »
dans le chapitre suivant), « la checklist ultime pour le lancement d’un site web » de
Dan Zambonini (Box UK) et « la checklist d’accessibilité que je m’étais juré de ne pas
rédiger » d’Aaron Cannon (North Temple).

RESSOURCES Les checklists
1
Opquast Checklists :http://bp.inté.net/1-1
2
Box UK (Dan Zambonini) :http://bp.inté.net/1-2
3
North Temple (Aaron Cannon) :http://bp.inté.net/1-3

Véritable référence, la checklist Opquast dédiée à l’intégration regroupe 57 bonnes
pratiques âprement débattues et triées sur le volet. C’est donc sans surprise que vous en
retrouverez la grande majorité dans la liste ci-après. Scindée en trois parties, elle répond
à plusieurs objectifs : servir d’index aux gabarits déjà intégrés, permettre l’évaluation
individuelle de chaque page et, enin, permettre l’évaluation transversale d’un ensemble
de points communs aux diférents gabarits. Suivant le contexte, ce ichier peut
avantageusement être remplacé par un outil en ligne (comme Opquast Reporting) qui se
charge de vériier automatiquement un ensemble de points qui ne nécessitent pas d’être
validés manuellement.

1.https://checklists.opquast.com
2.http://www.boxuk.com/blog/the-ultimate-website-launch-checklist
3.http://northtemple.com/1608

15

16

PA R T I E1 – BI E NP R É PA R E RS O NP R O J E T

Index des maquettes
Toutes les pages à intégrer sont listées et associées à un numéro, ain qu’elles soient
identiiables rapidement. Les URL sont par la suite progressivement ajoutées,
permettant au ichier de servir d’index aux maquettes.

Fig. 1-2 :La checklist sert d’index aux maquettes et renseigne sur l’état d’avancement du projet.

Évaluation individuelle des pages
On regroupe ici l’ensemble des vériications à faire de manière individuelle pour chaque
page. Il s’agit sans conteste de la partie la plus importante de la checklist. En pratique, il
s’agit d’indiquer pour chaque ligne si la vériication est un succès (OK), un échec (NOK)
ou si elle n’est pas applicable dans le cadre du projet (N/A).
Les points à contrôler pour chaque page étant nombreux et variés, ils ont été regroupés
par thématique. Cette partie de l’évaluation vous amènera donc à vériier la conformité
de vos pages et leur rendu sur les navigateurs visés, la qualité du code HTML, la
structure et l’harmonisation du contenu, son accessibilité, l’optimisation pour le
référencement et bien sûr le caractère fonctionnel du site.

1 – OR G A N I S E RS O NE S PA C ED ET R AVA I L

Tableau 1-1 :Checklist d’évaluation individuelle des pages
(version détaillée :https://github.com/inseo/bpi-checklist)

CONFORMITÉ ET RENDU NAVIGATEUR

Validation HTML

Firefox

Chrome

Safari

Opera

Internet Explorer 9

Internet Explorer 8

Internet Explorer 7

Internet Explorer 6

iPhone

iPad

Android

Blackberry

Opera Mobile

HTML

Le code source débute par undoctypedont la syntaxe est conforme aux
recommandations du W3C.

Une métadonnée déinit le jeu de caractères de la page.

Le jeu de caractères utilisé est UTF-8.

Le code source ne contient ni éléments ni attributs de présentation.

La capitalisation à des ins décorative est efectuée en CSS.

Les mots ne comportent ni espaces ni balisage interne(<span>L</
span>ettrine).

Les styles en ligne sont utilisés de manière appropriée.

1

1

2

2

3

3

17

18

PA R T I E1 – BI E NP R É PA R E RS O NP R O J E T

Chaque lien est doté d’un intitulé dans le code source (entre les balises ouvrantes
et fermantes de l’élément<a>ou, si nécessaire, via l’alternative textuelle d’un
élément<img>ou<object>).

Les icônes de navigation sont accompagnées d’une légende explicite (altpour les
éléments<img>ettitlepour les éléments<a>,<button>ou<input>).

CONTENU

Aucun contenu de test ne subsiste (lorem ipsum, images temporaires).

Le contenu est exempt de fautes d’orthographe et de grammaire.

Il n’y a pas plusieurs variantes d’un même mot (mailoue-mailoucourriel).

Le ton employé est uniforme (tuouvous).

Les formules passe-partout (en savoir plus,cliquez ici) sont remplacées par des
intitulés utiles.

Les textes qui ne sont pas visibles par défaut (attributsalt, textes aichés via une
fonction JavaScript, retranscriptions) sont pertinents.

Les éléments de listes sont conclus de manières identiques (virgule, point ou
point-virgule).

Les entités HTML sont utilisées à bon escient (&hellip;pour ...,&laquo;pour «,
&copy;pour ©).

Le contenu ne comporte pas de tableaux imbriqués.

Les fenêtres modales sont dotées d’un bouton de fermeture explicite.

Les images ne sont pas redimensionnées côté client.

Chaque champ de formulaire est associé à une étiquette qui lui est propre (balise
<label>).

L’étiquette de chaque champ indique si la saisie est obligatoire (via un texte ou une
image).

Les listes d’options (balise<select>) sont présentées dans un ordre facilement
identiiable.

Les champs de formulaires traitant d’un sujet commun sont regroupés via
ʳºʴsousun même intitulé (<legend>).

Des liens d’aide ou des instructions en ligne facilitent la complétion des champs.

1

2

3

1 – OR G A N I S E RS O NE S PA C ED ET R AVA I L

4
Les captchassont remplacés par un test plus simple à efectuer.

À la soumission, l’ensemble des erreurs de saisie sont indiquées à côté du champ
concerné ou à un emplacement bien visible.

L’utilisateur reçoit un feedback pour chaque action réalisée.

ACCESSIBILITÉ

La langue principale du contenu est indiquée via l’attributlangdans la balise
<html>.

Les passages en langage secondaire sont encadrés par une balise qui précise ce
dernier.

Le sens de lecture du contenu est précisé lorsqu’il difère de celui par défaut (dir).

Des liens d’évitement sont placés au début du code source.

La navigation au clavier s’efectue dans un ordre prévisible (tabindex).

Les en-têtes des tableaux de données sont balisés (<th>) et chaque cellule est
associée à son en-tête.

Les sons et vidéos sont déclenchés par l’utilisateur.

Les animations ne bloquent pas la navigation ou l’accès aux contenus.

Les animations, sons et clignotements peuvent être mis en pause.

Aucun contenu ne clignote plus de trois fois par seconde.

Une retranscription, un sous-titrage ou une traduction en langue des signes est
disponible pour tous les sons et vidéos contenant un discours.

Chaque vidéo transmettant une information essentielle sous forme visuelle est
également disponible en audio description.

Le contraste entre le contenu et le fond de la page est suisant (se référer aux
5
WCAG ).

La couleur ne doit pas être le seul vecteur d’information (saisie obligatoire dans un
formulaire, par exemple).

1

2

3

4. Testsdestinés à diférencier un utilisateur lambda d’un robot, les captchas sont généralement utilisés dans les
formulaires pour se prémunir d’une soumission massive efectuée par certains programmes malveillants.
5. LesWCAG(Web Content Accessibility Guidelines)sont formées de recommandations destinées à rendre les contenus
web plus accessibles.

19