Projet Responsive Web Design PDF

Jrmie Patonnier
Rudy Rigot
Projet
Responsive
Web Design
DU RECUEIL DES BESOINS LA MISE EN LIGNE
DESIGN
Prface de Kaelig Deloumeau-Prigent
RUSSIR SA CONDUITE DE PROJET
EN RESPONSIVE WEB DESIGN
Adapter lafchage dun site web toutes les tailles dcrans pour
rpondre aux besoins des internautes dans tous les contextes dutilisa-
tion : un d lheure o le Web mobile a envahi notre quotidien !
Permettant de crer des sites qui ragissent intelligemment lcran
sur lequel ils sont consults (ordinateur, smartphone, tablette), le
responsive web design convainc de plus en plus de concepteurs web.
Mais alors que la pratique se rpand, comment adapter les processus
dindustrialisation dun projet web ces nouvelles mthodes ?
Au-del de la mise en uvre technique, ce livre accompagne le chef de
projet, mais aussi tous les intervenants (designers, dveloppeurs), tout
au long du droulement dun projet, prvenant contre les embches
et proposant des rponses aux ds techniques et humains que cette
adaptabilit ne manque pas de poser.
Un guide indispensable pour apprhender de manire dtendue
la gestion de projet web aujourdhui !
AU SOMMAIRE
Responsive ou adaptatif ? Quelques
notions cls pour bien commencer
Recueil des besoins et cahier des charges
Monter lquipe projet
Conception, design graphique
et intgration
Dveloppement back-end
Rle et formation des contributeurs
ditoriaux
Recette applicative et TMA
C
o
d
e

G
1
3
7
1
3
I
S
B
N

9
7
8
-
2
-
2
1
2
-
1
3
7
1
3
-
2
C
o
n
c
e
p
t
i
o
n

N
o
r
d

C
o
m
p
o

Graphiste de formation, Jrmie
Patonnier est aujourdhui expert en
dveloppement web chez Clever Age.
Cofondateur des sites Typographisme
et Le train de 13h37, il est aussi
contributeur au projet Mozilla.
Passionn du Web sous toutes ses
approches et membre du think-tank
dinnovation Zenexity, Rudy Rigot
fut lun des premiers signaler les
consquences du responsive web
design sur la gestion de projet.
Tous deux interviennent dans des
confrences de renom en France
(Paris Web, Sud Web) comme
ltranger.
DESIGN
Projet
Responsive
Web Design
DU RECUEI L DES BESOI NS
LA MI SE EN LI GNE
Chez le mme diteur
Mmento Performances web.
Armel Fauveau et Lionel Pointet.
N 13658, 2013, 18 pages.
Mmento Sites web : les bonnes pratiques.
lie Slom.
N12802, 3
e
dition, 2010, 18 pages.
Accessibilit web. Normes et bonnes pratiques
pour des sites plus accessibles. Armony Altinier.
N12889, 2012, 320 pages.
Ergonomie web. Pour des sites web effcaces.
Amlie Boucher.
N13215, 3
e
Ergonomie web illustre. 60 sites la loupe.
Amlie Boucher.
N12695, 2010, 336 pages.
Bien rdiger pour le Web. Stratgie de contenu
pour amliorer son rfrencement naturel.
Isabelle Canivet.
N13750, 3
e
dition, 500 pages.
Russir son rfrencement web.
Olivier Andrieu.
N13664, 2013, 552 pages.
CSS avances. Vers HTML5 et CSS3.
Raphal Goetter.
N13405, 2
e
HTML5. Une rfrence pour le dveloppeur web.
Rodolphe Rimel.
N12982, 2011, 604 pages.
Relever le df du Web mobile. Bonnes
pratiques de conception et de dveloppement.
Franois Daoust et Dominique Hazal-Massieux.
N12828, 2011, 300 pages.
Gestion de projet agile. Avec Scrum, Lean,
eXtreme Programming... Vronique Messager.
N13666, 2013, 294 pages.
Coacher une quipe agile. Guide lusage
des ScrumMasters, chefs de projet, managers...
et de leurs quipes ! Vronique Messager.
N13414, 2012, 324 pages.
Dans la collection A Book Apart
Dans la collection Design Web
Stratgie de contenu mobile. Karen McGrane.
N13675, 2013, 172 pages.
Mtier web designer. Mike Monteiro.
N13527, 2012, 156 pages.
Mobile frst. Luke Wroblewski.
N13406, 2012, 144 pages.
Design motionnel. Aarron Walter.
N13398, 2011, 110 pages.
Responsive Web Design. Ethan Marcotte.
N13331, 2011, 160 pages.
Stratgie de contenu web. Erin Kissane.
N13279, 2011, 96 pages.
CSS3 pour les Web designers. Dan Cederholm.
N12987, 2011, 132 pages.
HTML5 pour les Web designers. Jeremy Keith.
N12861, 2010, 98 pages.
Intgration web : les bonnes pratiques.
Le guide de survie de lintgrateur !
Corinne Schillinger.
N13370, 2012, 412 pages.
CSS maintenables avec Sass & Compass.
Outils et bonnes pratiques pour lintgrateur web.
Kaelig Deloumeau-Prigent.
N13417, 2012, 272 pages.
Design dexprience utilisateur. Principes
et mthodes. Sylvie Daumal.
N13456, 2012, 192 pages.
Rfrencement mobile. Web Analytics et strat-
gie de contenu. Isabelle Canivet Bourgaux.
N13667, paratre 2013, 400 pages.
Card Sorting. Ne perdez plus vos internautes !
Gautier Barrre et ric Mazzone.
N13448, 2012, 108 pages.
La stratgie de contenu en pratique.
30 outils passs au crible. Isabelle Canivet
et Jean-Marc Hardy.
N13510, 2012, 170 pages.
Projet
Reponsive
Web Design
DU RECUEI L DES BESOI NS
LA MI SE EN LI GNE

Pr f ace de Kael i g Del oumeau- Pr i gent
Jrmie Patonnier Rudy Rigot
DITIONS EYROLLES
61, bld Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com
Remerciements Anne Bougnoux et tous les relecteurs
de cet ouvrage.
En application de la loi du 11 mars 1957, il est interdit de reproduire intgralement
ou partiellement le prsent ouvrage, sur quelque support que ce soit, sans autorisation
de lditeur ou du Centre Franais dExploitation du Droit de Copie, 20, rue des Grands
Augustins, 75006 Paris.
Groupe Eyrolles, 2013
ISBN : 978-2-212-13713-2
un grand philosophe, Daniel Rigot, qui se trouve tre mon pre
et que jai toujours entendu parler dcrire son propre livre.
Tu vois, au fnal, tu lauras crit travers moi
R.R.
PRFACE
Lorsque jai commenc bricoler des pages web dans le bureau
de la maison familiale, je navais pas de connexion Internet.
Pour mettre ces pages en ligne, lopration tait un poil compli-
que : il sagissait de compresser au maximum les fchiers (et
notamment les images) pour les stocker sur une disquette
(1,44Mo). Celle-ci tant parfois capricieuse, chaque fchier tait
dupliqu une ou deux fois, histoire de sassurer quil serait rcu-
prable. Je me rendais ensuite la mdiathque (quipe dordi-
nateurs connects Internet) pour tlverser les mises jour
via FTP depuis les disquettes.
Quel rapport entre cette anecdote et la conception de sites web
aujourdhui? La dmocratisation des connexions haut dbit a
dcomplex les designers web, dont les pages ont enf jusqu
peser des poids hier dlirants (plusieurs mgaoctets). Or, retour
de bton inattendu, cette infation fait nouveau obstacle aux
performances des sites web et lon revient une recherche
forcene de loptimisation des pages. La rapidit daccs
linformation est devenue cruciale, alors que les conditions de
navigation sur mobile sont aussi variables quimprvisibles. La
spectaculaire pntration du march par les smartphones et les
tablettes a boulevers notre modle de conception, chose que
personne naurait souponne avant larrive de liPhone en
2007. Tandis que nous produisions des produits destins des
plates-formes vieillissantes, les consoles de jeu portables se sont
mises intgrer des navigateurs web dignes de ce nom, puis les
consoles et platines de salon ont suivi la tendance. Demain, il
sera compliqu de trouver un tlviseur qui ne soit pas quip
dun navigateur web. Au fur et mesure que le march se
standardisait (rsolutions dcran plus uniformes, connexions
ADSL), nous nous sommes confortablement habitus une
conception en 1024768pixels toujours considre comme
la norme dans de nombreuses agences sans nous soucier
de la multiplicit des priphriques inhrente au World Wide
Web. Nous sommes dsormais mis devant cette vidence: nous
avons cass le Web.
PRFACE vii
viii PROJ ET RESPONSI VE WEB DESI GN
La question qui se pose est celle de la livraison de nos contenus
ce panel grandissant de priphriques et dusages. Nous
pouvons nous vertuer produire des sites spcifques
chaque type de plate-forme et des applications ddies, mais
long terme, cette approche nest viable ni fnancirement ni sur
un plan pratique.
Les exprimentations rcentes autour du trio des langages du Web
que sont HTML, CSS et JavaScript montrent quil est possible
de produire des sites qui sadaptent intelligemment aux plates-
formes de nos utilisateurs, quel que soit le contexte dans lequel ils
accdent linformation. Le concept de base derrire cette ide,
quEthan Marcotte a nomm responsive web design ou RWD pour
les intimes a inspir des mthodes qui en sont encore ltat
embryonnaire, mais qui semblent tellement prometteuses quelle
sont sans aucun doute le futur de la chane de conception web.
Adopter cette approche permettra darchitecturer des produits qui
fonctionnent sur les navigateurs dhier et daujourdhui, tout en
restant accessibles sur les priphriques du futur.
En creusant le sujet, on se tournera vers ladaptive web design
(design adaptatif ), grce auquel on saura proposer des dclinai-
sons du mme document pour quil se transforme de manire
adquate sur des priphriques aussi disparates que des lunettes
connectes, des interfaces gestuelles, des consoles de jeu, une
montre intelligente
Le livre que vous tenez entre les mains est le tmoin de lin-
trt que la communaut des professionnels du Web porte au
responsive web design, mais il ne sagit pas ici de suivre un efet
de mode passager. Sensibiliser le client, former lquipe, garder un
cap prcis tout en tant fexible en cours de projet Tant de dfs
techniques et humains auxquels ont t confronts les auteurs en
conditions relles. Merci eux pour ce prcieux partage.
Kaelig Deloumeau-Prigent

Intgrateur et auteur du blog Le ministre de lintgration
Auteur du livre CSS maintenables avec Sass et Compass,
aux ditions Eyrolles
http://kaelig.fr
TABLE DES MATI RES ix
1 Avant-propos
5 Remerciements
chapitre 1
7 Quelques concepts cls
pour bien dmarrer
8 Responsive? Adaptatif?
11 Amlioration progressive et dgradation lgante
14 Le lcher-prise du Web
15 Rappel sur les mthodologies de gestion de projet
chapitre 2
23 Recueillir les besoins
24 La prise de contact: ltape fondatrice
27 Faire parler le client et lcouter
30 Le projet est-il manifestement responsive?
chapitre 3
37 Rdiger le cahier des charges
38 Les principales contraintes dun projet
40 Dfnir le primtre du projet
chapitre 4
45 Monter lquipe projet
46 Comment orchestrer les rles projet?
48 Lvolution des rles projet typiques
dans un contexte responsive
56 Les changements en cours dans les mtiers
du Web
60 Lamlioration continue des expertises
TABLE DES MATIRES
x PROJ ET RESPONSI VE WEB DESI GN
chapitre 5
63 La pr-conception
63 Les approches de conception
67 Grer les gabarits
74 Les outils ncessaires la conception
chapitre 6
77 La conception
77 La rpartition des rles
79 Le prototypage
chapitre 7
87 Le design graphique
87 Organisation et chifrage
91 Les livrables graphiques
chapitre 8
97 Lintgration
98 La gestion des images
104 Dfnir une stratgie de tests
106 Documenter le projet
chapitre 9
109 Le dveloppement back-end
110 Grer les risques lintrieur
du primtre intgr
115 Grer les risques lextrieur
du primtre intgr
121 Grer les images fuides ct serveur
chapitre 10
127 Rle et formation
des contributeurs ditoriaux
128 La contribution dimages
TABLE DES MATI RES xi
131 Texte: de nouvelles contraintes
135 Tenir compte de la mise en page
chapitre 11
139 Efectuer la recette applicative
140 Se prparer pour une recette efcace
145 Pendant la recette applicative
chapitre 12
149 Aprs la mise en production
151 Le dilemme habituel: trouver
le bon consultant de TMA
153 Une difcult: la continuit du travail
dintgration
155 Aprs-propos: le mot de la fn
157 propos des deux auteurs
159 Index
AVANT- PROPOS 1
AVANT-PROPOS
Chaque vnement de progrs ressemble un peu un galet qui
tombe dans un tang : au dbut, beaucoup de bruit vient de
la surface, et chacun y va de son opinion sur la direction quil
prendra. Puis, le galet tombe lentement, leau et les autres galets
se positionnent progressivement pour lui permettre davancer
son rythme, prenant le temps de la rfexion chaque goutte.
Alors quil heurte le fond et prend sa position fnale, chacun
stonne de tout le chemin parcouru et reste un peu en moi sur
ce qui a t construit, ce qui a chang. Enfn, progressivement,
le galet se fait oublier Il fait maintenant partie dun tout, il
est maintenant une partie du monde et plus personne ne sen
tonne.
Cest ce qui sest historiquement pass pour chaque innovation
stant avre un progrs: quelle est la dernire fois que vous
vous tes enthousiasm du confort de vie que vous ofre votre
voiture ou votre transport en commun ? Quand votre grille-
pain vous a-t-il fascin pour la dernire fois?
Alors que le concept de mobilit se consolide enfn et que nous
en sommes dj ltape de lmoi devant le chemin parcouru,
la sphre du Web ( dfaut du grand public) est aujourdhui
en train dobserver lavance progressive que ralise linnova-
tion du responsive web design, qui consiste concevoir un site
pour quil sadapte toutes les largeurs dcrans possibles. Les
premires observations empiriques de sites refondus selon
ces techniques tmoignent dun vritable progrs : le taux de
rebond mobile a baiss de 26 % depuis la refonte du site du
magazine Time, le chifre dafaires du site ONeill a augment
de 101,2% pour les visiteurs sur iPhone/iPod et de 591,4% sur
Android, le chifre dafaires du site Skinny Ties a augment de
377,6% pour les visiteurs sur iPhone et de 42% tous visiteurs
confondus, les inscriptions en ligne ont augment de 63% sur
le site du Regent College
1
Certes, ce nest sans doute pas le
1. Source: http://www.lukew.com/f/entry.asp?1691
2 PROJ ET RESPONSI VE WEB DESI GN
responsive web design en soi qui est la cause de ces chifres
enthousiasmants, mais plus largement la prise en compte des
terminaux modernes, notamment par le design.
Grce ces premiers retours, parmi les clameurs que nous
avons entendues lorsque le concept a frapp la surface, nous
savons aujourdhui que celles qui le dcrivaient comme un efet
de mode passager semblent stre trompes. Le responsive web
design est bel et bien cens rejoindre le fond de ltang, celui o
toutes les innovations qui restent dans le temps reposent sous
nos yeux dans leur tat fnal.
Pourtant, aujourdhui, il en est encore un tat davancement
assez jeune de son industrialisation. Charge nous de pousser
chaque goutte deau de manire rfchie.
Que trouver dans ce livre ?
Si vous avez prcdemment manipul loutil technique que
sont les requtes de mdia CSS (CSS media queries), vous tes
sans doute tomb comme tout le monde en admiration devant
la simplicit dutilisation de cet outil, qui apporte pourtant des
possibilits incroyables. Vos premires mises en uvre (votre
site personnel, peut-tre?) ont t tellement simples raliser
que vous avez peut-tre imagin, au premier abord, tre devant
un concept la courbe dapprentissage trs favorable.
Peut-tre avez-vous ensuite eu loccasion de mettre en uvre
des designs responsive sur des projets en quipe. Si cest le cas,
cest l que vous avez d rencontrer vos premiers vritables
problmes: designers ne sachant pas comment structurer leurs
livrables, intgrateurs levant des alertes rouges dinfaisabilits
techniques et, videmment, tout le retard qui saccumule
force de devoir invalider du travail refaire...
Et si vous avez eu ensuite loccasion de participer un projet
responsive denvergure, vous vous tes alors aperu que la
AVANT- PROPOS 3
complexit de mise en uvre de ce type de projets grimpe en
fche en mme temps que la complexit du projet.
En prenant un peu de recul, vous vous tes alors certainement
fait cette rfexion, que nous nous sommes faite nous-mmes:
ce nest pas le design qui se complique, ce sont nos habitudes
et nos outils, que nous avons forgs autour des pages largeur
unique, que nous avons de plus en plus de mal tordre pour ce
nouveau contexte.
Dans ce livre, nous avons essay daider rsoudre tous les
problmes typiques que nous avons frquemment rencontrs
sur des projets denvergure (et de taille moyenne), en compa-
raison avec les projets dont nous avions lhabitude prc-
demment. Vous, lecteur, qui vous posez des questions sur la
manire dont vous devriez aborder votre prochain projet qui
vous inquite tant, nous avons essay de vous prendre par la
main pour drouler les tapes et rfexions importantes qui
devront jalonner son droulement.
Ce livre ne contient absolument pas de recettes toutes faites
appliquer tout projet; nous considrons lindustrialisation de
ce type de projets comme tant un travail en cours de dcou-
verte et navons pas toutes les rponses, pour la simple raison
quaujourdhui, personne ne les a. En revanche, nous avons nos
rponses nous, notre vision des problmatiques et, dans la
mesure du possible, nous avons essay de les accompagner dun
maximum de pistes de rsolution adapter votre situation.
Un guide pratique, mais pour qui ?
Ce livre sadresse toute personne tant intervenue, sur le point
dintervenir ou souhaitant intervenir terme sur des projets
utilisant le responsive web design et dsireuse de perfectionner
sa rfexion sur la meilleure manire dy participer.
Ce livre aura une rsonance dans son intgralit pour les chefs
de projet, puisquils sont les tmoins de toutes les tapes du
projet. Il sera globalement intressant pour les autres profls,
mais ils y trouveront des chapitres qui leur seront davantage
destins que dautres, quils aient le rle du client (ou product
owner), du designer, du commercial, du dveloppeur, etc.
Afn de rendre plus efcace son objectif de guide pratique pour
tous ces profls, nous avons dcid de le construire dans lordre
chronologique du droulement dun projet web typique. Nous
vous conseillons fortement de lire le premier chapitre, qui vous
servira de base de connaissance thorique pour vous lancer
sereinement dans les autres sujets; mais nhsitez pas, ensuite,
choisir entre lire le reste dans lordre chronologique ou privi-
lgier les chapitres qui vous intressent le plus. Il a t construit
de sorte rendre ce mode de lecture possible.
Le blog du livre !
Retrouvez les auteurs et changez avec eux sur :
http://projetresponsive.fr
REMERCI EMENTS 5
REMERCIEMENTS
Nous remercions trs chaleureusement nos relecteurs volon-
taires, qui ont men une course efrne contre la montre et
ont apport une norme valeur au livre grce leurs retours,
tous trs pertinents : Stphane Deschamps, Damien Boyer,
Nicolas Catherin, Sophie Taboni, Yan Paquis, Florian Lonqueu-
Brochard, Vincent Valentin, Marie Guillaumet, Nicolas Hoizey,
avec une mention particulire pour Olivier de Villardi, aussi
connu sous le nom de lhomme qui relisait plus vite que son
ombre!
Aussi, nous prsentons des remerciements accompagns dex-
cuses Julien Femia et Matthias Dugu, qui se sont aimable-
ment ports volontaires pour relire, mais ont eu la malchance
darriver tout juste trop tard. De mme pour Corinne Massacry,
qui nous a aimablement propos des jolies illustrations, que
nous aurions ador intgrer au livre, si nous ne lavions pas
oublie en chemin... (oups, dsols!)
Nous remercions aussi Vanessa Paquerot-Rigot, pour sa
patience infnie, mais aussi ses crpes magiques qui nous ont
redonn du cur louvrage lapproche de la ligne darrive!
Nous remercions aussi Kaelig Deloumeau-Prigent, qui nous
signe une prface digne du philosophe web quil est.
Et nous remercions tout particulirement Karine Joly, des
ditions Eyrolles, qui nous a propos cette aventure de fous
et a gr avec brio notre approche trs approximative de la
littrature!
Merci tous, ce livre est aussi le vtre!
Quelques
concepts cls
pour bien
dmarrer
QUELQUES CONCEPTS CLS POUR BI EN DMARRER 7
1
Quelques
concepts cls
pour bien
dmarrer
Le Web est une science relativement neuve, charge de bon sens
et de bonnes pratiques qui sutilisent au fur et mesure quelles se
dcouvrent, et quil faudra dcouvrir au fur et mesure quelles
voluent naturellement. Ce bon sens se dduit de valeurs simples
qui snoncent clairement, comme laccessibilit (universalit
daccs des contenus et services tous les utilisateurs, quel que
soit leur matriel, handicap), les performances (quelles soient
du ct des technologies serveur ou client), loptimisation pour
les moteurs de recherche (SEO, Search Engine Optimization), etc.
Dans le contexte du responsive web design, le bon sens de notre
rfexion viendra de plusieurs notions quil nous faudra gale-
ment noncer clairement, pour tre sr de bien les comprendre
avant de nous lancer la tte la premire.
RESPONSIVE ? ADAPTATIF ?
Quest-ce que le responsive web design ?
Avant de dcortiquer fnement un concept tel que le responsive
web design, il serait bienvenu de le dfnir. Un site ayant t
conu selon ce principe est un site dont le design (fonctionnel
ou graphique) change en fonction de la taille de lcran sur
lequel il est consult (ou de la fentre du navigateur, selon
votre choix de conception). En franais, la traduction design
ractif serait la plus juste, mais force est de constater que cest
le terme anglais qui sest impos.
Lamalgame est facile, mais ce concept est difrent de celui des
media queries; ces dernires sont un outil technique de la spci-
fcation CSS3 qui permet dexcuter des rgles CSS en fonction
de certaines conditions (la taille de lcran nest quune partie
des 13 rgles existantes dans la recommandation, ltat fnal
depuis le 19juin2012).
Fig.1-1 : Capture dcran de la recommandation fnale CSS3 media queries
publie par le W3C
Recommandation nale CSS3 media queries
http://xav.cc/css2mq
1
Lvolution de la dnition du terme responsive web design
LorsquEthan Marcotte a initialement crit larticle
Responsive Web Design sur le blog A List Apart, puis le
livre du mme nom (initialement aux ditions ABook Apart,
puis traduit en franais et publi aux ditions Eyrolles), la
dfnition quil proposait ntait pas exactement celle que
nous venons de poser. Il le dfnissait comme lalliance de
plusieurs technologies (dont les CSS3 media queries, mais
aussi les grilles fuides et les images fuides) pour permettre
une nouvelle approche moins contraignante (dun point de
vue design) de la fabrication des pages fexibles.
http://xav.cc/rwd-article
2
E. Marcotte, Responsive Web Design, A Book Apart,
Eyrolles, 2011
Seulement voil, la dcouverte du responsive web design
et sa publication ont t ralises sous lgide dun certain
Jefrey Zeldman (fondateur du magazine A List Apart et
de la collection ABook Apart) et, quelques mois plus tard,
Zeldman remettait gravement en question la dfnition quils
avaient prcdemment choisie pour correspondre cette
appellation, dans un article sur son blog : Responsive
design, je ne pense pas que ce mot signife ce que vous
pensez quil signife.
Il y dclare : Je pense aussi quil sagit sans doute dune
plus grande ide que ce que nous imaginions, une ide trop
large pour tre limite une unique approche technique
pour rsoudre le problme de multiples environnements de
1. http://www.w3.org/TR/css3-mediaqueries/
2. http://alistapart.com/article/responsive-web-design
consultation trs segments. () Notre comprhension du
design responsive devrait tre largie pour contenir toute
approche mise en uvre dans lintention de proposer une
exprience visuelle lgante quelle que soit la taille de lcran
de lutilisateur. Voici pourquoi il sagit de la dfnition que
nous prfrons proposer ici.
http://xav.cc/rwd-zeldman
3
Et le design adaptatif ?
Le concept de responsive web design est trs souvent injuste-
ment confondu avec celui dadaptive web design ou design adap-
tatif ; cest excusable, car tous deux partagent davantage que
des sonorits voisines. Tout comme le responsive web design,
ladaptive web design est prsent par son propre livre, crit par
Aaron Gustafson (Jefrey Zeldman en signe la prface). Alors
que le responsive consiste grer uniquement les difrentes
tailles dcran, ladaptive sapplique plutt une catgorie de
sites dont le design (fonctionnel ou graphique) change en fonc-
tion des capacits du navigateur (Est-il capable dexcuter du
JavaScript? Est-il capable de stocker de la donne ct client?
Est-il capable de reprsenter des blocs avec des dgrads en
CSS? Etc.) ou du systme dexploitation.
On y retrouve la mme ide dadaptation, mais une difrence
notable est que, pour un contexte client donn, le design adap-
tatif apportera par dfnition une seule rponse (puisquil
sadapte aux capacits du navigateur et du systme dexploita-
tion, qui ne bougent pas pour un mme contexte), tandis que le
responsive web design apportera souvent plusieurs rponses:
en efet, la taille peut changer soit parce quon retaille la fentre
du navigateur (pour un systme dexploitation multifentre),
3. http://www.zeldman.com/2011/07/06/responsive-design-i-dont-think-that-
word-means-what-you-think-it-means/
soit parce quon change lorientation du terminal (sil a un
gyroscope).
Si beaucoup des conseils que vous trouverez dans ce livre sont
applicables pour adapter un design aux capacits du terminal
(surtout lorsque lon vous incitera prvoir et documenter des
alternatives difrentes), ce ne sera volontairement pas le centre
de nos proccupations: en ce qui concerne la conception et la
gestion de projet, cest larrive du responsive web design, et
non du design adaptatif, qui a fortement rendu nos manires de
faire obsoltes. Cest donc sur la gestion des tailles dcrans que
nous nous concentrerons ici, mme si nous nous autorisons
doccasionnels commentaires concernant le design adaptatif.
AMLIORATION PROGRESSIVE
ET DGRADATION LGANTE
Ces concepts sont pertinents pour notre sujet car il sagit gale-
ment dadapter un design un contexte.
La dgradation lgante
La dgradation lgante sutilise sur les langages dits tolrants
aux erreurs: cest le cas de HTML et CSS, dont les spcifcations
prvoient les cas o linterprteur ne comprend pas lune des
instructions, de sorte la rendre transparente et laisser les
autres sexcuter quand mme. Cela permet dutiliser les tech-
nologies les plus avances sur les navigateurs les plus jour,
tout en les laissant se dgrader seules et lgamment sur les
autres.
Un exemple typique est la proprit border-radius en CSS :
lorsquelle est applique un lment, les navigateurs modernes
donnent ce dernier des bords arrondis. Toutefois, les navi-
gateurs plus anciens et incapables de traiter cette proprit
laissent des bords angulaires classiques llment. moindre
efort, tout reste accessible, seul laspect esthtique est lgre-
ment afect; voil qui est lgant!
Un exemple typique ct HTML est la multitude dlments de
formulaires qui ont fait leur apparition dans les spcifcations
HTML5. En efet, un champ de type color, par exemple, va
tre interprt par un colorpicker (slecteur de couleur) dans
les navigateurs modernes, mais se dgradera en champ texte
simple pour les autres navigateurs, dans lequel lutilisateur aura
toute possibilit de saisir le code dune couleur. videmment,
cet exemple de dgradation technique simple entrane une
dgradation ergonomique forte (il est souvent beaucoup plus
simple pour un utilisateur de slectionner une couleur dans un
colorpicker que de saisir son code hexadcimal). Cependant,
certaines dgradations sont plus lgantes fonctionnellement:
datepicker natif se dgradant en champ texte o saisir la date,
slider natif se dgradant en champ texte o saisir la valeur, etc.
Fig.1-2 : Le colorpicker, tel quinterprt gauche par le navigateur Chrome, au
milieu par Opera et, droite, par un navigateur ancien
Lamlioration progressive
Lamlioration progressive, au contraire, consiste enrichir le
site en dtectant proactivement les fonctionnalits acceptes
par le navigateur. Ceci a notamment du sens en JavaScript, car
ce nest pas un langage tolrant lerreur: une instruction inva-
lide en JavaScript parce que la mthode ou lobjet utilis nexiste
pas dans un navigateur peut totalement interrompre lexcution
des autres instructions.
La solution consiste sassurer que vous avez prvu un compor-
tement alternatif pertinent pour toutes les fonctionnalits les
plus susceptibles de ne pas tre implmentes sur les naviga-
teurs de vos utilisateurs.
Lexemple typique frquemment utilis est la golocalisation :
on peut imaginer un bouton Me localiser, dont le comportement
serait adapt pour les navigateurs qui ne limplmentent pas.
On peut citer aussi un cas qui devient de plus en plus perti-
nent aujourdhui : un comportement difrent si le terminal
sutilise avec un cran tactile. En efet, bien quon trouve chez
certains dveloppeurs une volont de considrer les crans
tactiles comme mobiles , cette approche est de moins en
moins satisfaisante, surtout depuis que les tablettes font, en
mode paysage, une largeur quivalente certains crans dordi-
nateur; cest dautant plus vrai depuis que Microsoft pousse le
modle de lcran tactile sur ordinateur avec son Windows8. La
solution consiste donc prvoir un comportement manipuler
avec la souris dans un premier temps (qui puisse tre gr par
les navigateurs anciens), puis de lamliorer lorsque la capacit
interagir avec un cran tactile est dtecte, en remplaant le
comportement par un autre ou en lenrichissant.
Vous laurez compris, la dgradation lgante et lamlioration
progressive sont deux approches difrentes (et compatibles)
permettant dadapter un design aux capacits du navigateur
ou du systme dexploitation. Vous aurez peut-tre reconnu la
dfnition : il sagit en fait de deux solutions techniques pour
mettre en place des stratgies de design adaptatif.
LE LCHER-PRISE DU WEB
Le blog qui a vu natre le concept de design responsive, AList
Apart, fait partie des rfrences les plus anciennes en ce qui
concerne le design web. Aussi serez-vous peu surpris en appre-
nant que ses plus anciens billets datent de 1998 et que lide quil
mettait en avant de raliser des designs laide de standards du
Web tait trs avant-gardiste lpoque. Toutefois, si lon vous
dit que lun de ses plus anciens articles, publi le 7avril2000,
semble toujours la pointe de la modernit aujourdhui, vous
serez sans doute plus intrigu.
En signant A Dao of Web Design , John Allsopp expose un
message de fond incitant ne pas tenter de faire des ralisations
qui se veulent matrises de bout en bout et absolument iden-
tiques dans tous les contextes dutilisation. lpoque, il est
en guerre contre la perfection au pixel prs hrite des mdias
imprims et pousse renoncer aux tentatives dapprivoisement
excessif du Web. Il ne sagit pas ici de perdre en qualit, mais de
se concentrer sur la garantie dune cohrence seulement l o
elle est ncessaire, pour justement gagner en qualit globale ;
notamment, il pouvait sagir, lpoque, de prfrer utiliser un
texte (accessible et non matrisable esthtiquement) une image
contenant un texte (inaccessible mais fortement matrisable)
car, nen dplaise aux graphistes travaillant pour limprim,
laccessibilit tait plus importante quune esthtique parfaite.
lire : A Dao of Web design
http://xav.cc/dao
4
4. http://alistapart.com/article/dao, traduction en franais disponible
http://www.pompage.net/traduction/dao
Plus dune dcennie plus tard, ce message rsonne encore beau-
coup alors que les terminaux ayant accs au Web se multiplient,
et avec eux, les moyens dinteragir avec le Web. Du navigateur
trs limit sur un feature phone (tlphone fonctionnalits,
de la gnration ayant prcd les smartphones, dont lutilisa-
tion est trs prdominante dans certains pays, notamment en
Afrique) au dernier Chrome sur un ordinateur tout juste sorti,
les contextes du ct client se sont tellement diversifs que
vouloir tous les matriser est une aventure impossible.
On peut alors reprendre ce lcher-prise du Web que John
Allsopp nous prsentait et concevoir une exprience optimale
dans les meilleurs cas, mais qui sadaptera au mieux dans tous
les autres cas, en nhsitant pas mettre en uvre la dgrada-
tion lgante et lamlioration progressive.
Ce lcher-prise du Web est une notion dangereuse, car elle
pourrait servir dexcuse une certaine paresse ( La police
dcriture ntait pas celle prvue en design ? Cest bon, lche
prise!) Il faut donc toujours sassurer de lutiliser dans le but
de tirer la qualit vers le haut pour la globalit des contextes
client, lexception tolrable des clients les plus la pointe.
Nous reparlerons trs souvent de cette notion au cours du livre.
RAPPEL SUR LES MTHODOLOGIES
DE GESTION DE PROJET
Sil y a quelque chose de relativement similaire dun projet web
lautre, cest sans doute lordre des tapes qui le composeront
(bien quil y ait des exceptions notables). Pour ne garder que
les tapes quasi invitables, on commencera toujours par lister
les charges, puis on rdigera les spcifcations, on ralisera le
design fonctionnel et graphique, lintgration, le dveloppe-
ment back-end, puis la mise en ligne. Cest dailleurs la raison
pour laquelle nous avons dcoup ce livre suivant les tapes du
projet qui nous semblent les plus immuables.
Toutefois, la mthodologie pour grer les contraintes lint-
rieur des phases, ainsi que lenchanement des phases, difre
selon les contextes (que les raisons soient fnancires, lies
la confance du client ou une souplesse exceptionnelle de
lquipe projet, etc.).
Bien que les informations que vous trouverez dans ce livre
restent pertinentes quelle que soit la mthodologie que vous
choisirez, nous avons jug utile, pour un livre qui parle de
gestion de projet, de rappeler rapidement les principales mtho-
dologies; nous pourrons alors utiliser librement ces concepts
dans les chapitres suivants.
Le modle en cascade
Le modle en cascade (vous lentendrez aussi appel waterfall
par les amateurs de franglais) est le plus basique et il ne connat
quune contrainte : la fn dune phase projet doit tre sanc-
tionne dune validation pour dclencher la phase suivante.
Cela signife aussi que chaque phase de projet doit se conclure
par un livrable valider. partir de ces hypothses, le planning
est simple raliser, mme sil est idaliste et prend rarement
les risques en compte.
Hrit du BTP (Les fondations sont bien en place? On pose
les murs!), ce modle est celui utilis le plus souvent dans les
cas rels. Cependant, il arrive souvent, sur un projet web, quon
ne valide une phase que partiellement pour pouvoir dclencher
une partie de la suivante ; bien videmment, nous ne recom-
mandons pas cette pratique, bien quelle puisse se rvler indis-
pensable pour rattraper des glissements de planning avec un
minimum de perte de qualit.
Fig.1-3 : Un exemple simplif de modle en cascade pour un projet web
typique
Le cycle en V
Le cycle en V considre que le travail fait en premier sur un
projet doit aussi tre le dernier tre valid, une fois toutes
les autres phases projet passes. Il permet de sassurer que lac-
cumulation de complexit au fl du droulement du projet ne
dtourne pas le produit fni des conceptions qui ont t rali-
ses en amont.
En Web, un cycle en V typique va ressembler au schma repr-
sent sur la fig.1-4, page suivante.
Fig.1-4 : Un exemple simplif de cycle en V pour un projet web typique
En rgie ou en forfait ?
Que vous fonctionniez en cascade ou en V, en spirale, ou
encore selon lune des nombreuses mthodologies projet aux
formes gomtriques plus incongrues les unes que les autres,
sil se trouve que vous travaillez dans le service, les modes de
contractualisation avec le client sont nombreux ; mais deux
dentre eux sortent du lot comme tant les plus frquemment
rencontrs.
La rgie correspond un engagement de moyens : une
ressource (dans notre cas, un consultant web) est mise dispo-
sition du client pendant un temps dfni et interviendra sur les
projets comme le client le dcidera. Comme aucun engagement
nest pris par personne sur le travail qui est produit, chacun
des partis peut savrer perdant: le client, si le consultant nest
pas aussi dou que son commercial lavait promis, et le presta-
taire, si le client dcide darrter de travailler avec lui du jour au
lendemain.
Le forfait correspond un engagement de rsultats: sufsam-
ment dinformations sont obtenues en dbut de projet par le
prestataire pour lui permettre de sengager sur lintgralit de la
suite des vnements. Le prestataire met alors une proposition
commerciale avec une charge prvisionnelle, un planning et un
tarif fg pour lensemble du projet. videmment, tout ceci ne
tient aucun compte des risques rels (qui sont alors inconnus)
et, ds que les imprvus saccumulent, la situation est idale
pour que chacun se renvoie la faute: le client rappelle au pres-
tataire quil sest engag un rsultat pour un tarif fg et quil
ne paiera pas plus, le prestataire cherche tout cart de conduite
du client pour justifer le retard (validation plus longue que
prvue, recette mal faite) et demander une rallonge budg-
taire, tout en essayant au maximum de rduire les cots (et
donc la qualit) pour sauver sa chemise. Le client pense partir
gagnant car il matrise son budget, mais il sagit aussi du type de
contractualisation qui fnit le plus souvent trs mal...
Il faut modrer ce constat, malgr tout : dans une entente
cordiale entre un client et un prestataire, il arrive quand mme
trs souvent que la ngociation en cas dimprvus se passe bien
et que lun des deux (ou les deux conjointement) assume le
dcalage. Notons que ce type dentente ncessite une souplesse
daction du ct du client, ce qui nest pas toujours possible,
notamment dans le cadre des marchs publics ; nous revien-
drons sur ce cas trs particulier.
Les mthodes agiles
Lapproche agile tente dapporter simultanment une rponse
viable en tant que mthodologie de projet (au mme sens que le
modle en cascade ou le cycle enV) mais aussi en tant que cadre
de contractualisation (au mme titre que la rgie ou le forfait).
Elle apporte une philosophie qui a le vent en poupe, car elle
tente de dfavoriser le moins possible lensemble des interve-
nants au projet (ct client comme prestataire).
Tout projet (web ou non) contient toujours trois contraintes
principales surveiller : les dlais, le budget et la couverture
du chantier (dans notre cas, la couverture fonctionnelle). Tout
dbordement de lun des axes (couverture fonctionnelle qui se
rvle plus large que prvue, pertes de temps) devrait natu-
rellement ncessiter du mouvement sur les autres axes aussi;
mais le modle du forfait fxe ces trois axes en dbut de projet,
sans possibilit de mouvement.
Fig.1-5 : Les trois contraintes principales de la gestion de projet:
tirez sur un des angles du triangle et cest lensemble du triangle qui est cens
grandir, sur les deux autres axes galement.
Dans le cadre des mthodes agiles, le prestataire et le client
vont convenir dun budget fxe et souvent de dlais fxes; mais
ils vont accepter que le troisime axe, la couverture fonction-
nelle, ne soit pas fxe.
Pour atteindre cet objectif, le projet va tre dcoup en fonc-
tionnalits, regroupes par ce que lon appelle des sprints,
priodes fxes au terme desquelles le produit est toujours stable
et testable, mais incomplet fonctionnellement. Les premiers
sprints contiennent les fonctionnalits indispensables et les
derniers contiennent celles dont il est possible de se passer.
Au terme de chaque sprint, on pourra efectuer la recette du
produit, stable, et toute fonctionnalit ayant un problme sera
repositionne dans le sprint suivant (pour tre nouveau teste
par la suite). Ce principe des mthodes agiles est dailleurs
fondateur: celui que lon appelle le product owner (responsable
de la vision globale du produit) sera plus fortement prsent
tout le long du projet et aura un rle actif dans sa construc-
tion. Dans le cadre dune relation client-prestataire, le product
owner sera le client; mais un diteur de logiciel ne pourra pas
se passer dun product owner pour autant, alors quil nest pas
un client proprement parler; pour cette raison, nous utili-
serons prfrentiellement le mot product owner client
dans le reste de ce livre.
Enfn, puisque les mthodes agiles sous-entendent des phases de
recueil des besoins puis de conception qui ne sont pas incluses
dans ce fonctionnement, on parle de cycle semi-itratif.
La fig. 1-6 donne une reprsentation graphique dun projet
suivant les mthodes agiles: aprs la phase de conception, on
itre avec autant de sprints quil a t dfni lors du cadrage
du projet. Chaque sprint livre un produit stable, mais non
complet; le dernier sprint est sanctionn par un produit stable,
auquel il manque les fonctionnalits secondaires ne rentrant
pas dans le budget initialement prvu.
Fig.1-6 : Reprsentation graphique dun projet suivant les mthodes agiles
Recueillir
les besoins
Mthodes agiles
Au pays des mthodes agiles, il y a plusieurs coles, appor-
tant chacune ses outils et ses procds : Scrum, le Kanban,
Crystal... En voici une prsentation gnrale, compare aux
mthodologies traditionnelles de gestion de projet:
V.Messager, Gestion de projet agile, Eyrolles, 2013
Si vous souhaitez mettre en uvre la mthode Scrum (la plus
complte et la plus populaire), nous vous conseillons dappro-
fondir le sujet avec le livre:
A. Vannieuwenhuyze, Scrum, une mthode agile pour votre
projets, ENI, 2013.
RECUEI LLI R LES BESOI NS 23
Tout projet commence par un recueil des besoins dtaills par
le client. Du premier contact la qualifcation du projet, cette
tape est cruciale car cest elle qui va dterminer toute la suite.
Prendre du temps lors de cette premire tape, cest sassurer que
le projet se droulera dans les meilleures conditions, pour vous
aussi bien que pour votre client.
Nous allons donc analyser les difrentes tapes du recueil des
besoins. Il va de soi que chaque projet est unique et chaque
client a ses propres proccupations. Pour cette raison, nous
nallons pas essayer de dresser un tableau exhaustif des besoins
possibles, ni mme essayer de dfnir des profls de clients.
Non. Nous allons nous concentrer sur les points cls et, surtout,
sur les points spcifques un projet de type responsive web
design.
2
Recueillir
les besoins
LA PRISE DE CONTACT : L TAPE FONDATRICE
Tout commence par une prise de contact. Elle peut tre votre
initiative ou bien celle du client, selon la qualit de votre rseau
commercial. De deux choses lune : soit le client vient directe-
ment vous en vous exposant son projet, soit cest vous qui allez
au client, trs souvent en rpondant un appel dofres. Dans ce
dernier cas, son examen peut dj vous en dire long sur le projet.
Lart de lire un appel doffres
Dissquer un appel dofres est une tape importante dans la
vie dun projet. Soyons clair, sa lecture sapparente beaucoup
une forme de voyance; tout le moins, sans sombrer dans le
mysticisme, vous devrez savoir lire entre les lignes.
Avant mme le projet en soi, un appel dofres en dit beaucoup
sur le client. Le formalisme du document vous en dira long sur
sa capacit structurer ses demandes. La prcision dans lusage
des ventuels termes techniques vous permettra de dduire sil
les matrise, sil fait croire quil les matrise ou sil ny connat
strictement rien.
Dans le premier cas, il est important de sassurer si cette ma-
trise sera un avantage (vous pourrez parler ensemble de ma-
nire claire et ouverte sur les difrentes solutions techniques)
ou un problme (vous allez devoir vous battre avec le client
pour faire valoir votre savoir-faire). Cela peut ncessiter plu-
sieurs entretiens avec le client, ne soyez donc pas trop press.
Les cabinets AMOA
Notez que si le client passe par lintermdiaire dun cabinet
dAMOA (assistance matrise douvrage outille), les choses
risquent dtre biaises. Les chefs de projet AMOA sont
souvent trs au fait du vocabulaire technique, mais cela ne
prjuge en rien de la matrise efective de ces questions et de
leurs enjeux par le client.
Dans le deuxime cas, il vous faudra vrifer sil sagit dune
faon de se mettre votre niveau pour bnfcier de votre
exprience ou bien sil sagit de masquer linquitude que
reprsente votre savoir-faire unique.
Enfn, dans le dernier cas, il faudra vrifer que cette absence
de connaissance des rouages techniques ou fonctionnels
vous permettra dexercer pleinement votre expertise.
En bref, la premire chose faire est de sassurer que le client
souhaite travailler dans un esprit de collaboration plutt que de
contrle. L, malheureusement, il ny a pas de recette miracle:
cest lexprience qui vous indiquera quoi vous en tenir.
Cependant, cet aspect des choses est trs important car, comme
nous allons le voir, la gestion de projet responsive requiert de
la souplesse et de la confance, en raison des nombreux ajuste-
ments qui auront lieu tout au long du projet.
Concentrons-nous sur le projet. Lappel dofres est trs souvent
le premier contact que lon a avec ce projet. En consquence, il
est tout aussi important de sarrter sur ce qui y est dit que sur ce
qui en est absent. La lecture en creux des documents est essen-
tielle. En efet, la rponse un appel dofres fait souvent lobjet
dun document dtaill et dune soutenance face au client. Pour
remporter le projet, il est donc primordial davoir bien compris
ce que veut le client... parfois mme mieux que lui!
Un bon appel dofres vous indique quels sont les objectifs du
client, mais aussi ses attentes fonctionnelles pour atteindre
ces objectifs. Malheureusement, les appels dofres clairs sont
rares. Pour cette raison, vous aller devoir vous poser beaucoup
de questions et, le cas chant, les poser votre client pour
savoir ce quil en est exactement. Que lon ne sy trompe pas,
les raisons pour lesquelles un appel dofres nest pas clair sont
lgion. Dans certains cas, il sagira simplement dun oubli, mais
dans dautres, ce pourra tre une sous-estimation des enjeux
du projet. Dans ce dernier cas, si vous sentez que le projet a un
potentiel mais quil est trop mal exprim pour pouvoir faire une
ofre de mise en uvre, nhsitez pas proposer une mission
de cadrage pralable de quelques jours pour aider le client
formaliser sa demande clairement.
Rencontrer le client en face face
Ainsi, il arrive toujours un moment ou vous allez rencontrer
le client. Ny allons pas par quatre chemins: vous tes l pour
lui tirer les vers du nez, pas pour prendre le th. Assez parado-
xalement, un client est parfois rticent parler de son projet;
en consquence, vous allez devoir gentiment mais fermement
le soumettre la question. Si cela est vrai dans tout projet, cest
encore plus critique dans un projet qui se rvlera responsive.
Ici, cest bien la question de ce que va devenir le projet qui est
en jeu. En efet, au moment ou vous croisez le client pour la
premire fois, au mieux, vous avez une intuition et il va vous
falloir la transformer en certitude, au pire, vous nen savez rien
et, l encore, il va falloir vous assurer de ne rien oublier.
Le risque est de vous retrouver avec un projet qui ne rponde
pas exactement aux attentes du client et qui conduise, dans le
meilleur des cas, des tensions accompagnes dun ou plusieurs
avenants endommageant durablement la relation avec le client.
Dans la pire des situations, le projet va tourner court, avec
suites judiciaires dans les cas extrmes. Soyez donc ferme
lors de vos rencontres. Cela sera toujours bnfque aux deux
parties: vous cernerez bien le projet et le droulerez sereine-
ment et, pour le client, ce sera lassurance que son projet est
matris et en de bonne mains.
Vous devez donc tout savoir pour apporter une rponse
adapte et correctement chifre. Quelles questions faut-il donc
se poser?
FAIRE PARLER LE CLIENT ET L COUTER
Faire parler un client de son projet est toujours un peu dlicat.
En efet, de deux choses lune : soit le projet implique un
certain enjeu personnel et, dans ce cas, votre client peut parfois
y mettre beaucoup plus dafect que nen ncessite vraiment le
projet, soit il implique un enjeu plus large (parfois mme poli-
tique) et votre futur client nen est alors que le garant face une
autorit suprieure. En consquence, il peut arriver que lon ait
faire face des types particuliers de ractions.
Les bavards: ils vous parlent linfni de leur projet, quel
point il est gnial, quel point il va rvolutionner Internet...
et regardez, la photo du petit dernier, l il a dit Kapou.
La plupart du temps, il en ressort peu de choses utiles et il est
bien difcile dorienter la discussion vers les points cls que
lon va voir ci-aprs.
Les muets : exacte inverse des prcdents, pour obtenir la
moindre miette dinformation, il vous faudra dployer des
trsors de diplomatie, au risque de le voir se refermer comme
une hutre.
Les dsempars: il sagit souvent de chefs de projet mtier ou
issus dun cabinet AMOA qui ne sont pas dcisionnaires sur
le projet. Dans ce cas-l, plusieurs rendez-vous seront sans
doute ncessaires.
Dans un cas comme dans lautre, un brin de fermet vous
sera salutaire. Limportant est de ne rien lcher tant que vous
naurez pas clairci lensemble des points suivants, quil sagisse
dobjectifs ou de contraintes connatre.
Les objectifs du projet
Afn de dterminer dans quelle mesure le projet va devenir
responsive, il est important de connatre quel sont ses objectifs.
qui sadresse le site?
Est-il destin des jeunes ou des plus gs, des hommes ou
des femmes, des cadres ou des ouvriers, des professionnels
ou des particuliers, etc.?
Cela conditionne grandement les habitudes des utilisateurs et
leur facilit utiliser les difrents moyens daccder Internet.
Par exemple, le taux dquipement peut varier selon lge et
la catgorie socioprofessionnelle ; de mme, les navigateurs
utiliss au bureau sont parfois sensiblement difrents de ceux
utiliss la maison, etc. Connatre les cibles du futur site va
vous permettre dextrapoler sur les attentes et la capacit des
visiteurs utiliser le site.
quoi sert le site?
Que permet-il de faire? Sagit-il de vente en ligne, dun rseau
social, dune application utilitaire, etc.?
Connatre les usages du site est primordial, car cela permet dan-
ticiper sur les conditions dutilisation ( la maison, au bureau,
dans les transports, en station debout ou assise, en intrieur ou
en extrieur, etc.). Cependant, il ne faut pas hsiter demander
explicitement ce qui est attendu en la matire. Cest dailleurs
sans doute la question la plus importante pour valuer la nces-
sit dadaptation dun site. Quels sont les cas dusage ? Dans
quelles conditions le site va-t-il tre utilis? quel moment? Et
inversement, y-a-t-il des cas dusage qui ne doivent surtout pas
tre couverts par le site? Cette dernire question est galement
trs importante. En efet, un usage prvu ne prsume pas dune
absence dusage. Par exemple, si vous posez assez directement
la question Votre site va-t-il tre utilis assis un bureau?,
une rponse positive ne signife pas que ce site ne sera pas
utilis debout dans les transports.
Faites toujours trs attention ne pas tirer de conclusions
htives. Prenez le temps de poser des questions qui se recoupent
et, si votre client commence devenir bavard, essayez de lui
poser des questions ouvertes (cest--dire des questions qui
commencent par comment plutt que par est-ce que). Les
questions ouvertes sont toujours un exercice un peu dlicat, car
cest la porte ouverte aux digressions improductives ; cepen-
dant, leurs rponses peuvent amener des lments auxquels
vous nauriez sinon pas pens.
Les utilisateurs pourront-ils contribuer au contenu
du site?
Et si cest le cas, de quelle faon? Ce point a de limportance, car
les moyens de contribution rejoignent de prs les cas dusage.
L aussi, cela vous permettra dextrapoler sur ce que devra ou
ne devra pas faire le site, ou comment il devra sadapter, le cas
chant.
Les contraintes connatre
Dans un autre ordre dides, il va tre galement crucial de
connatre les contraintes spcifques du projet. Certes, les
contraintes habituelles de dlais et de budget sont importantes
et sont souvent celles auxquelles le client pense spontanment.
Pourtant, il y en a dautres qui vont tre tout aussi capitales
pour vous.
Quels sont les matriels et navigateurs cibles?
Quels est le degr de dgradation acceptable pour les vieux
navigateurs?
Les clients sont loin dtre au fait de ces problmatiques et il est
parfois ncessaire de faire preuve de pdagogie pour expliquer
les contraintes que peut induire la compatibilit avec de vieux
navigateurs. En particulier, il est ncessaire dtre parfaitement
transparent sur les questions de faisabilit, de performances et,
surtout, du cot supplmentaire, parfois signifcatif, que cela
peut reprsenter pour le projet.
LE PROJET EST-IL MANIFESTEMENT RESPONSIVE ?
Nous avons dsormais sufsamment dinformations pour
qualifer le projet. Cette qualifcation va se matrialiser par le
choix entre trois possibilits.
Le site na aucun besoin dtre adaptable.
Il sagit typiquement des projets ciblant des populations parti-
culires sur des cas dusage spcifques. Le besoin dadaptabi-
lit est alors minime et le responsive web design est inutile.
Le site a besoin dadaptation, mais une approche responsive
nest pas adquate.
Trs souvent, il sagit des sites ofrant un panel fonctionnel
trs large et pour lesquels il est ncessaire de construire des
parcours utilisateur spcifques telle ou telle plate-forme.
Dans ce cas, il est parfois ncessaire de crer des sites dits
adaptatifs. Dans les cas les plus extrmes, on peut mme en
arriver crer plusieurs sites difrents plutt quessayer de
tordre tout prix un site pour le faire rentrer dans un moule
pour lequel il nest pas fait.
Le site est ligible une solution responsive.
Bravo, ce livre est fait pour vous, nous allons donc creuser la
faon de mener bien ce projet!
Les cas Twitter et Facebook
Ces deux sites sont un excellent exemple de notre
problmatique.
Dun ct, Twitter propose un service simple, facilement
dclinable sur tout format. Malgr cela, ses concepteurs
ont fait le choix dun site mobile ddi, difrent du site
gnral. Le service ofert est fondamentalement le mme.
Cependant, ce choix sest fait sur la base de deux contraintes
spcifques : loptimisation des performances et la cration
dune exprience utilisateur spcifque cet environnement.
Dun autre ct, Facebook propose quantit de fonctionna-
lits. Le problme, cette fois, est un peu difrent. La version
mobile de Facebook nofre pas du tout la mme couverture
fonctionnelle que le site gnral. Il y a une volont claire
de simplifer les services pour ofrir une exprience utilisa-
teur de meilleure qualit tout en ofrant des performances
optimales.
On trouve quelques dfenseurs du responsive pour tous,
qui considrent que tous les sites web pourraient sadapter
aux difrentes tailles dcran ; nous ne partageons absolu-
ment pas leur approche et ne sommes pas surpris que des
leaders dopinion tels que Facebook, Twitter ou Google
ne la partagent pas non plus (et les restrictions de budget
qui peuvent expliquer la rticence de certains clients sont
franchement inapplicables ici !) Une seule explication est
possible : une simple approche responsive naurait
simplement pas suf optimiser tous les points qui leur
semblaient stratgiques.
Aprs mre rfexion, vous avez donc identif un projet de site
responsive et vous allez donc pouvoir lannoncer votre client.
L encore, plusieurs cas vont se prsenter: soit le client parle
spontanment de responsive , soit vous allez devoir le lui
proposer.
Le client parle spontanment
de responsive : mfiance !
Si lors de vos difrents rendez-vous avec le client ou lors de la
lecture des difrents documents quil vous aura fournis, celui-
ci a explicitement demand que son site soit responsive, il
va falloir vous mfer un peu. En efet, le terme responsive
web design est, bien des gards, un terme marketing ou buzz
word rpt lenvi ici et l.
De fait, les clients peuvent facilement se faire de fausses ides et,
dans le meilleur des cas, imaginent quelque chose de magique
qui va leur permettre de raliser moindre cot un site qui
fonctionnera partout. Cette vision est susceptible de vous poser
un petit problme quand vous allez annoncer votre client que
la cration dun site responsive induit certains surcots.
Il va vous falloir faire preuve, l encore, de diplomatie et de
pdagogie pour expliquer la nature de ces cots et limportance
quils revtent pour la bonne tenue du projet.
Les cots de conception sont plus levs, car le design va
devoir tre dclin avec plus ou moins de fnesse selon les
difrents cas dusage prvus. De plus, la phase de proto-
typage sera plus longue, afn de bien valider les difrentes
adaptations fonctionnelles.
Les cots de dveloppement sont plus importants, car le
nombre des exceptions qui doivent tre gres augmente
proportionnellement au nombre de plates-formes explicite-
ment cibles, le tout avec des temps de dbogage parfois plus
importants.
Les cots de recette sont accrus, du fait du nombre plus im-
portant de plates-formes vrifer, ainsi que des nombreux
tests supplmentaires crire, sans compter les ventuels
appareils quil faudra acheter pour loccasion.
ct de ces cots, il sera galement ncessaire de rappeler au
client que son implication va tre galement plus importante
que dans un projet traditionnel. En efet, pendant le projet lui
mme, les sollicitations seront plus importantes (validation,
rdaction de contenu, etc.), mais aprs le projet, des cots de
formation seront peut-tre envisager pour que ses quipes
puissent sereinement prendre en main les spcifcits du site
(en particulier lors de la contribution).
Alors certes, le cot du projet nest pas multipli par deux, mais
selon les exigences du client, il nest pas exceptionnel de voir le
budget augmenter de 20% 50%.
Comment proposer une solution responsive ?
Vous voici donc face au client. Ce peut tre dans le cadre dun
rendez-vous en face face ou lors dune prsentation formelle.
Comme nous venons de le voir, le plus gros cueil lors de la
prsentation dun projet responsive est trs souvent celui du
budget. Si, pour une raison ou une autre, le client trouve que
vous tes trop cher, il va falloir faire valoir les avantages spci-
fques de ce type de projets, et ils sont plus nombreux quon ne
le croit.
Dun point de vue budgtaire direct, il est important de men-
tionner que pour couvrir tous les cas dusage demands, cette
solution reste moins onreuse que la cration difrencie de
deux sites distincts.
Dun point de vue technique, un projet responsive correcte-
ment men simplifera la maintenance du site, ce qui rduira
les cots rcurrents lis la correction de bugs ou aux invi-
tables volutions fonctionnelles qui ne manqueront pas de se
prsenter une fois le projet livr.
Dun point de vue utilisabilit, ce type de sites ofre un double
avantage. Pour les administrateurs du site, la gestion est sim-
plife. Quel que soit le support, les oprations de contribu-
tion et de gestion ne se feront quune seule fois, ce qui, l
encore, rduira les cots rcurrents (certes, cest galement
possible sur des sites difrencis, mais au prix dune architec-
ture serveur qui peut se rvler complexe et donc coteuse).
Pour les utilisateurs, cest une exprience unife qui leur est
propose, quel que soit leur moyen daccs. Cela contribue
valoriser limage de marque du client, tout en favorisant la
fdlisation (si un site marche dans tous les contextes prvus,
et mme au-del, un client est moins tent daller voir ailleurs
si lherbe y est plus verte).
Dun point de vue infrastructure, l aussi, les avantages sont
nombreux. En particulier, cest une seule et mme infrastruc-
ture qui va rpondre tous les cas dusage en dlguant une
grande partie du travail au navigateur du client, ce qui rduit
trs srieusement les cots dinstallation et de maintenance.
Attention tout de mme, ce nest pas magique et cela doit tre
pens en consquence, par exemple avec la question type :
Quid de la bande passante, si tout le trafc est rout vers
la mme infrastructure ? Eh bien, l aussi, des conomies
sont possibles sous rserve de disposer dun systme de
cache correctement confgur. Sur cette question, ce nest pas
la nature responsive du projet qui aura une infuence, mais
bien la comptence des dveloppeurs et des administrateurs
systme.
Dautres avantages spcifques au projet peuvent galement
exister : nhsitez pas les dtailler. Cest votre savoir-faire et
votre capacit identifer ces bonus qui vous permettront
de remporter le projet en expliquant comment un surcot appa-
rent (la facture payer) peut en ralit induire une conomie
long terme.
Tous les clients ne sont pas ncessairement rceptifs ce genre
dargumentaire et certains exigeront mme des engagements de
rsultats conomiques ou techniques. Dans ce cas, soyez trs
prudent avant de vous engager quoi que ce soit. En efet, len-
vironnement Internet, surtout en matire de responsive web
design, est trop complexe et changeant pour prdire comment
les choses vont voluer. Entre le dbut dun projet et sa rali-
sation, plusieurs mois peuvent scouler. Pendant ce temps,
les pratiques techniques voluent, les navigateurs changent,
les modes passent... Bref, sengager sur un rsultat a quelque
chose dhasardeux. Prfrez un engagement sur les ressources
ncessaires mettre en uvre pour mener le projet bien tel
quil a t dfni lors de son lancement. Un tel type dengage-
ment ne vous dispense pas, bien au contraire, de prendre garde
aux volutions de primtre fonctionnel lors de la ralisation
du projet, volutions qui ne manqueront pas darriver et qui
devront obligatoirement faire lobjet davenants et de chifrages
circonstancis.
Voil, vous avez fait de votre mieux : vous avez dcortiqu
la demande du client et vous avez dfni la meilleure rponse
possible. Il ne vous reste plus qu patienter. Quelques jours
(semaines?) dangoisse plus tard, la rponse tombe: cest vous
qui tes slectionn pour prendre en main le projet. Nous
allons donc maintenant passer aux choses srieuses.
Rdiger le cahier
des charges
RDI GER LE CAHI ER DES CHARGES 37
Maintenant que vous vous tes entendu avec le client et que,
puisque le contrat est sign, vous savez que cest vous qui allez
raliser le projet, il va falloir entrer dans les dtails. Comme vous
vous en doutez, on ne part jamais bille en tte dans un projet sans
en dfnir le primtre et sans savoir o lon met les pieds. Bref,
avant de planter un beau parterre de feurs, on commence par
dbroussailler le terrain et on se renseigne sur le prix des graines.
Ltape prliminaire tout projet est la rdaction du cahier des
charges. Il sagit de formaliser lexpression des besoins du client
dans des documents structurs qui seront les tables de la loi du
projet. Le cahier des charges dfnit les tenants et les aboutis-
sants du projet. Il est loin dtre monolithique, mais se subdi-
vise rgulirement en plusieurs documents:
le cahier des charges fonctionnel, qui dfnit toutes les fonc-
tionnalits attendues lors de la ralisation du projet;
le cahier des charges technique, qui pose toutes les bases
techniques du projet : choix technologiques, dfnition des
architectures matrielle et logicielle;
Rdiger le cahier
des charges
le cahier des charges graphique, qui regroupe tous les l-
ments lis au design du projet : planches tendance, charte
graphique, dtail des parcours utilisateur, personas, etc. Tout
projet ne requiert pas tous ces lments, mais assurez-vous
davoir ce dont vous aurez besoin.
La plupart du temps, il sagit de documents fournis par le
client, mais il peut parfois vous revenir de les formaliser afn
quils soient plus facilement exploitables. Dans le cadre de cet
ouvrage, nous nallons pas rentrer dans le dtail de tous ces
documents, mais nous attacher simplement ceux qui ont une
incidence particulire dans un projet responsive.
LES PRINCIPALES CONTRAINTES D UN PROJET
Les projets qui font appel au responsive web design ont un
certain nombre de contraintes qui leur sont propres et quil est
ncessaire de prendre en compte ds les premires heures. Leur
formalisation au sein du cahier des charges vitera nombre de
problmes et autres dceptions.
Le projet est-il responsive ?
Nous lavons voqu prcdemment: ce nest pas parce quun
projet va se dcliner sur plusieurs matriels quil va ncessaire-
ment tre trait sous la forme du responsive web design.
tablir des priorits de fonctionnalits
selon les supports
Ainsi, contrairement au design adaptatif, le design responsive
montre ses limites. Il se borne a travailler sur laspect graphique
dun site ou dune application, sans jamais remettre en question
ses difrentes fonctionnalits, quel que soit le matriel de luti-
lisateur. En efet, le client arrive le plus souvent avec une liste
de fonctionnalits, un peu comme un enfant rdige sa lettre au
pre Nol.
Cependant, afn destimer au mieux les charges du projet, il est
indispensable de bien dfnir les fonctionnalits selon le mat-
riel : chacune sera qualife en fonction de sa difcult tre
ralise sur un matriel donn, ainsi que par son importance au
regard des objectifs du projet.
Cette dfnition des priorits est importante deux titres. En
premier lieu, elle va vous indiquer prcisment si le projet se
destine tre responsive ou bien adaptatif. Il y a peu de chances
que cela se rvle tre un projet dissoci (avec des sites ou des
applications difrentes selon le matriel), car vous avez dj
d liminer cette possibilit lors de lanalyse de lappel dofres.
Cependant, si cela ce rvle ncessaire, cest maintenant quil
faut le signaler. Aprs, il sera trop tard et vous risquez de mettre
en danger la gestion budgtaire du projet, tout en crant une
insatisfaction nuisible au projet. Quoi quil en soit, vous identi-
ferez rapidement les impossibilits de mise en uvre (la difu-
sion de vidos sur un mdia print, par exemple) ainsi que les
aberrations conceptuelles (par exemple, avec un smartphone,
lafchage sur une seule page de dix fonctionnalits considres
comme critiques).
Dans un second temps, ce travail sur les priorits vous permettra
de planifer le travail faire. Ce sera dautant plus important si
vous faites le choix dorganiser votre travail selon les prceptes
des mthodes de dveloppement agile. Cest ce travail de mise
en priorits et de rationalisation qui vous aidera dfnir vos
rythmes de livraisons (de sprints, si vous faites du Scrum), en vous
donnant une premire vision du backlog fonctionnel (cest--dire
la liste des fonctions que va vous demander le product owner).
Dun point de vue purement mthodologique, il ny a pas de
solution miracle. Cela va dun ensemble de tableaux croiss
dynamiques dans votre tableur prfr jusqu la liste rdige
sur un coin de table. Limportant est davoir, au fnal, une liste
claire et dtaille qui serve de garde-fou tout au long du projet.
DFINIR LE PRIMTRE DU PROJET
Avec la dfnition des priorits, vous disposez dj dun premier
primtre fonctionnel. Quon ne sy trompe pas, ce primtre
va voluer en cours de projet, mais vous pourrez en toute lgi-
timit demander une rallonge budgtaire sil volue de manire
trop importante; cest pour cette raison quil est ncessaire de
bien le dlimiter.
Cependant, le primtre fonctionnel nest pas le seul qui ait
besoin dtre clairement bord. Le primtre technique, lui
aussi, se doit dtre dfni.
Dfinir clairement les plates-formes cibles
Parmi les facteurs de succs dun projet, la partie la plus impor-
tante sera sans doute la dfnition des plates-formes cibles.
Entre un smartphone, une tablette et un ordinateur, il y a
beaucoup de difrences et il est important de savoir quoi est
destin exactement le projet. Cela ne veut pas dire que vous ne
tiendrez pas compte des autres plates-formes (aprs tout, les
projets responsive ont toujours une dimension universelle) ;
cela signife seulement que vous ne prendrez pas dengagement
contractuel sur ces autres plates-formes.
Une mise en page parfaite, a nexiste pas!
Ce quil faut bien comprendre, cest quavec la diversit sans
cesse croissante des matriels disponibles, il nest pas raliste
de croire quil sera possible de couvrir tous les cas de fgure.
En particulier, il va tre ncessaire de faire comprendre votre
client que la notion de mise en page parfaite nexiste pas vous
savez, le fameux lcher-prise avec lequel on vous rebat
les oreilles rgulirement, celui dont nous avons parl dans
lintroduction
Un projet responsive impose cette vision du design web. En
efet, il nest pas rare, en fn de projet, de voir le client arriver
avec un matriel et vous reprocher que la mise en forme nest
pas optimale (pour rester poli). Dans ces cas, il faut savoir
quoi rpondre; sinon, vous vous retrouverez corriger des bugs
qui nont jamais t identifs et qui vont, dune part, retarder
le projet (et donc accrotre le risque que le client revienne vous
voir avec un nouveau matriel exotique) et, dautre part, grever
le budget que vous devrez prendre votre charge, car le client
refusera de payer pour un travail quil estimera mal fait.
Poser de bonnes bases de travail en la matire est donc imp-
ratif. Le cas chant, il vous faudra prendre le temps de faire
de la pdagogie auprs de votre client pour quil comprenne
les contraintes et prenne des dcisions claires. Linformation
et lducation des clients est sans doute lun des points les plus
sous-estims des projets responsive, mais cest celui qui mettra
le plus dhuile dans les rouages du projet.
quoi sert la plate-forme cible?
Avant de voir comment dfnir une plate-forme cible, rappe-
lons ce quoi elle va servir et, surtout, ce quoi elle ne va pas
servir.
La plate-forme cible, cest celle sur laquelle vous vous engagez
corriger tous les bugs dcouverts avant la livraison du projet
et sur laquelle vous allez galement engager une garantie.
Une garantie est un engagement de rsolution des bugs non
dcouverts lors de la recette, pendant un priode donne (par
exemple, un mois aprs la livraison en production du projet).
Cependant, pas de mprise ! Ce nest pas parce quun bug est
dcouvert sur une plate-forme non cible que vous nallez pas le
corriger. Non. Tous doivent tre corrigs. Cependant, un bug
sur une plate-forme non cible ne sera jamais bloquant pour la
mise en production du projet et pourra ventuellement faire
lobjet dun avenant au budget, sil apparat quil sera particu-
lirement coteux rsoudre, voire diagnostiquer (lexemple
typique tant un problme de performances sur une plate-
forme vieillissante ou la prise en charge des images retina
nous y reviendrons dans le chapitre 8 alors que cela na pas
t prvu dans le primtre dorigine).
Comment dfnir cette plate-forme cible?
Comment dcide-t-on alors des plates-formes cibles ? Petite
dfnition en prambule: une plate-forme est un couple form
dun navigateur et dun systme dexploitation. Il est trs impor-
tant de toujours bien prciser les deux, car sinon, vous aurez
des surprises. Par exemple, si vous dterminez que la plate-
forme est Firefox, sans prciser le systme dexploitation, cela
voudra dire que vous vous engagez prendre en charge Firefox
sous Windows, sous MacOS et sous Linux. Cest un problme,
car les optimisations du navigateur ne sont pas les mmes
pour tous les systmes dexploitation. Vous pouvez aussi vous
retrouver avec de mauvaises performances, qui vous coteront
trs cher si vous navez pas pens tester toutes les versions
du navigateur. Pire! Cela veut galement dire que vous devrez
corriger des bugs sous Android, en version smartphone ou en
version tablette Si vous navez travaill quavec une version
desktop en tte, a va faire mal!
Il y a donc trois faons de dfnir lensemble des plates-formes
cibles.
tudier les statistiques dutilisation. Dans lventualit o il
y en ait, interprter des statistiques nest pas toujours chose
aise et on peut, dans certains cas, passer ct de certaines
plates-formes. Cest typiquement le cas si le site actuel ne
fonctionne pas avec une plate-forme donne. Cependant,
dans le cas dune refonte ou dun projet destination dun
public connu, cela vous donnera de grandes lignes directrices
assez robustes.
Observer le matriel utilis par votre client. Cest bte dire,
mais quelle que soit la cible du projet, votre client regardera
toujours le rsultat avec son matriel lui. Certains clients
ont du mal accepter que le rsultat ne soit pas impeccable
sur leur propre matriel. Ainsi, mme si vous tes persuad
que la cible du projet ne va utiliser que des navigateurs der-
nire gnration, si votre client utilise une vieille version
dInternet Explorer, pas de chance... mais il va falloir lint-
grer dans les plates-formes cibles.
couter les demandes explicites formules par le client. Si
le projet a clairement pour objectif de cibler un ensemble de
plates-formes donnes, il ne faut pas oublier de les prendre
en compte. Cela peut paratre vident, mais mfons-nous du
nombre de fois o lon a tendance oublier les vidences...
Normalement, un projet responsive demande que lon cible
entre 4 et 6plates-formes pour la recette (2 3versions desktop,
1tablette et 1 2smartphones). Dans tous les cas, nacceptez pas
plus de 10plates-formes. En efet, le temps de dveloppement,
ainsi que les cots de test et de dbogage risquent de grimper
en fche, sans garantie que le projet soit de meilleure qualit au
bout du compte. Avec un trop grand nombre de plates-formes
cibles, vous risquez de passer trop de temps sur des dtails insi-
gnifants en perdant de vue lobjectif global.
Planifier l imprvu, mission impossible ?
Quel que soit le soin que vous preniez dfnir les plates-formes
cibles du projet, limprvu est toujours au rendez-vous du design
responsive: taille des crans (de 3 24pouces), conditions de
luminosit (intrieur, extrieur, en plein soleil, lombre, etc.),
priphriques daccs (cran tactile, clavier, souris, touchpad,
stylo capacitif, etc.) et bien dautres, le tout combin linfni. Il
y a l de quoi prendre de sacres migraines si lon veut absolu-
ment tout prvoir... Nessayez pas, cest impossible!
Non, vous ne pourrez pas tout prvoir ; oui, il y aura des cas
o a va se dgrader. La question est darriver anticiper les
dgradations. Lunivers du responsive web design contraint l
encore trs fortement faire siennes des techniques qui nont
rien de nouveau. Les notions damlioration progressive et de
dgradation lgante prennent une toute nouvelle dimension
dans ce genre de contexte.
Dfnir des points de rupture
Cela se matrialise en particulier par la dfnition de ce quon
appelle les points de rupture, ainsi que des comportements
de linterface entre deux points de rupture.
Traditionnellement, la dfnition de ces points de rupture se fait
de manire assez brutale en prenant les tailles dcran des plates-
formes cibles, et puis voil. Cest une mauvaise ide. Avec une
telle approche, vous pouvez tre certain que vous allez trs vite
rencontrer des cas o a ne marche pas . Nous verrons au
chapitre4 quil existe une meilleure manire de dfnir prcis-
ment les points de rupture. Cependant, lapproche par plate-
forme cible reste une bonne faon davoir les ides claires
ltape du cahier des charges.
Monter
lquipe projet
MONTER L QUI PE PROJ ET 45
Bien que les choix qui restent faire au cours du projet puissent
encore avoir un certain efet sur les charges ncessaires pour les
mettre excution, vous devriez maintenant avoir sufsamment
les grandes lignes du projet en tte pour imaginer son droule-
ment approximatif dans son ensemble. Dans votre tte sentre-
choquent alors les diverses possibilits de planning et la combi-
naison parfaite des intervenants pour recouvrir tous les besoins,
au bon moment.
Selon le type de structure dans lequel vous travaillez, cette tche
de directeur de casting web sera plus ou moins simple... et
dans certains cas, totalement infaisable! Cest pourtant un exer-
cice qui aura des consquences svres sur le produit fni. Voila
qui mrite une rfexion de fond...
Une particularit qui distingue le Web de beaucoup dautres
domaines est quil existe un nombre incroyable dexper-
tises fouiller, qui voluent toutes continuellement. Pour les
passionns du Web, cest un excellent art de vivre: vous avez la
4
Monter
lquipe projet
garantie que vous ne cesserez jamais dapprendre. En revanche,
pour monter une quipe avec une expertise globale satisfaisante
sur tous les fronts, cet tat de fait rend la tche trs complexe.
Les lecteurs les plus cartsiens seront ravis de lapproche
que nous allons suivre : nous tentons daborder ce problme
complexe en le dcoupant en parties simples, que nous allons
appeler les rles projet.
COMMENT ORCHESTRER LES RLES PROJET ?
Avec un peu de recul, on constate que lindustrialisation de la
ralisation de sites web est un concept relativement rcent.
Aprs tout, il y a dix ou quinze ans, un amateur seul au fond de
son garage pouvait raliser, sans autre assistance, un site web
conforme ltat de lart: contenus basiques, peu voire pas du
tout de services fonctionnels (les outils techniques nexistaient
pas encore) et peu dinquitude quant au fait que les internautes
accdent tous au site dans des conditions optimales.
Aujourdhui, les attentes lies au Web, quelles viennent des utili-
sateurs ou des annonceurs, ont spectaculairement augment et
les sites web denvergure doivent rpondre des contraintes
couvrant une grande varit dexpertises, et donc de nombreux
rles projet.
Face cette volution, les travailleurs du Web daujourdhui
ne sont pas tous gaux. une extrmit, les grands groupes
piochant leurs profls dans un pool de sous-traitants ont peut-
tre parfois la libert, si leur budget le permet, de runir un
casting de rve. Au milieu, les agences web sappuient en prio-
rit sur les ressources dont elles disposent dj dans leurs
rangs et doivent donc composer de manire quilibre avec
les comptences et les disponibilits de chacun. Enfn, lautre
extrmit, les petits diteurs de produits (de type start-up,
par exemple) devront compter sur des efectifs trs limits et un
panel dexpertises restreint pour parvenir tout raliser, malgr
tout.
Ne paniquons pas et restons ralistes: de toute manire, y compris
dans les meilleures conditions, vous naurez simplement jamais
lutilit davoir une personne spare pour chaque rle projet. Il
faut donc viser une distribution intelligente des rles selon les
intervenants qui sont disponibles, en afectant intelligemment
chaque personne les rles qui lui sont les plus adapts.
Dans tous les cas, il ne faut surtout pas approcher les rles
comme un concept statique dans la vie dun projet: dune part,
plusieurs rles seront afects une mme personne et certains
rles seront partags entre plusieurs personnes ; dautre part,
les difrents rles nont pas pour utilit de se drouler lun
aprs lautre, mais souvent simultanment. Cest la complmen-
tarit de ces rles projet et leur capacit intervenir en bonne
conscience des autres qui rend ce dcoupage pertinent.
Puisquil faut distribuer intelligemment, noubliez pas de
responsabiliser aussi les profls juniors. Privilgiez plutt un
rle fort sur un lot limit, par exemple: responsable du design
graphique pour le tunnel dachat ou responsable du dve-
loppement sur lAPI publique.
Matriser limprvu et le facteur humain dans la conduite de qualit :
la charte CATEEA
propos de la distribution des rles projet, Rudy Rigot a
prsent Paris Web 2011 une confrence o il proposait
une solution simple pour la reprsenter symboliquement
auprs des acteurs du projet, par le biais dune charte non
contractuelle afectant nommment les expertises, quil
nommait CATEEA (Collaborative Achievement Through
Everyones Expertise Acknowledgement). Cette charte doit tre
moralement comprise et accepte par tous les intervenants,
chef de projet et client (product owner) compris.
Lide, en dsignant un responsable pour chaque rle
projet, est de parvenir responsabiliser chaque membre de
lquipe par rapport ses expertises et celles des autres.
Lobjectif est un produit dont chaque axe correspond la
vision cohrente dun seul expert.
http://xav.cc/cateea
5
L VOLUTION DES RLES PROJET TYPIQUES
DANS UN CONTEXTE RESPONSIVE
Il existe une myriade de mtiers du Web et, plus on explore les
possibilits de ce support, plus on constate quils se multiplient.
Il existe des mtiers que lon retrouve frquemment, sur la large
majorit des projets; mais certains sont propres des besoins
atypiques.
Par exemple, vous recherchez un efet waouh gnral
lorsque vos utilisateurs regarderont les textes de votre design?
Il vous faut trs certainement un expert en typographie...
Vous allez devoir manipuler des quantits astronomiques de
donnes? Il vous faut trs certainement un expert en big data
(qui ne se stocke pas du tout comme de la donne relationnelle
classique).
Lobjectif, lorsque vous montez votre quipe, est le mme
pour les rles typiques de projet ou pour les rles atypiques:
plus le rle est stratgique, plus vous devrez vous eforcer de
lafecter la personne la plus pertinente possible. linverse,
plus le rle est secondaire, plus vous pourrez vous autoriser des
compromis: par exemple, ce sera le cas avec le rle de designer
fonctionnel pour un site de contenus simples (blog, etc.), ou le
5. http://www.paris-web.fr/2011/conferences/maitrisez-limprevu-et-le-facteur-
humain-dans-votre-conduite-de-qualite-la-charte-cateea.php
rle darchitecte back-end pour un site avec peu de dveloppe-
ments spcifques.
Le chef de projet
Comme pour tout projet non web, le chef de projet doit
conserver la matrise de ses trois sempiternelles contraintes
(budget, dlais, couverture fonctionnelle), mener lquipe pour
sassurer que chacun travaille dans les meilleures conditions et
faire un reporting continu et de qualit auprs du client. Il a toute
la latitude ncessaire pour laisser sexprimer son expertise.
La complexit supplmentaire dans le domaine du Web est
que le chef de projet doit matriser et arbitrer la manire dont
cette myriade dexpertises sarticule. Et celle-ci est tellement
tendue que lon prfre souvent diviser le rle en deux : le
chef de projet fonctionnel, qui va soccuper de tous les mtiers
front-end, et le chef de projet technique, responsable de tous les
mtiers back-end.
Dans le contexte indit du design responsive, une nouvelle
problmatique du chef de projet fonctionnel sera darbitrer
selon le nouveau dcoupage des expertises dsormais impos.
Cette tche sera particulirement difcile face des quipes
habitues au cycle dun projet habituel (designers ne souhai-
tant pas de nouvelles contraintes techniques, intgrateurs
pas intresss pour conseiller les designers...). Toutefois, au
fur et mesure que les quipes monteront en comptence et
prendront de laisance, cet efet indsirable devrait sestomper
progressivement.
Le product owner
Le product owner est responsable de la vision globale du projet,
surtout par rapport tout lcosystme contextuel qui lentoure
(le plan de communication global dans lequel il sinscrit, les
objectifs marketing en gnral, les potentielles contraintes
politiques). Chez un diteur de logiciels, ce sera certaine-
ment un employ, ou lentrepreneur lui-mme sil sagit dune
start-up ; dans une agence web, il se trouvera le plus souvent
ct client.
La confusion est facile entre ce rle et celui du chef de projet;
toutefois, il nest pas toujours sain de faire tenir ce rle par la
mme personne. Lopposition des deux objectifs est construc-
tive. Le chef de projet doit comprendre les contraintes et limi-
tations poses par le product owner, mais se concentrer en
priorit sur la qualit du projet lintrieur de ces contraintes.
Le product owner doit tre preneur des conseils en qualit du
chef de projet, mais doit sassurer avant tout que les contraintes
diverses (marketing, politiques) sont respectes. La russite
du projet dpend trs fortement de la qualit de cette opposi-
tion de pouvoirs; la bonne entente entre ces deux profls sera
donc un facteur critique de la russite du projet.
Si vous apprciez les analogies, nous oserons mme comparer
ces mtiers ceux du cinma : le producteur est le product
owner, qui doit sassurer de la bonne sortie du projet, dans
les temps, pour le distribuer tel que promis et dans le budget
prvu, tandis que le ralisateur est le chef de projet, qui doit
avant tout se concentrer sur la qualit artistique et technique du
projet. Il sagit rellement de la mme opposition saine.
Dans notre contexte, le product owner nest pas cens tre
concern par les nouveauts techniques, puisque le chef de
projet lui sert justement darbitre et de conseiller sur ces probl-
matiques. En revanche, ces nouveauts techniques ont des
consquences marketing, car la stratgie dune marque et les
attentes des utilisateurs peuvent tre globalement difrentes
sur mobile et sur desktop. Il faudra donc que le product owner
connaisse bien les objectifs de ses internautes pour chacun de
ces types de priphriques, en tant capable de les sparer clai-
rement afn que ses retours soient les plus pertinents possibles
pour chacune des versions.
Le directeur artistique
Comme le dit un certain directeur artistique habitu travailler
sur le march amricain, Christophe Zlobinski-Furmaniak,
en France, on voit toujours fortement le mot artistique; mais
dans les pays anglo-saxons, on voit avant tout le mot directeur.
Le rle du directeur artistique est particulirement incontour-
nable dans des contextes stratgiques de communication: il est
le garant du respect optimal des valeurs de la marque (dont il
a parfois lui-mme cr lidentit). Souvent, il ne fera pas lui-
mme le design du site, mais traduira les besoins de communi-
cation du client en concepts graphiques et livrera une charte
lquipe de design graphique pour quelle travaille sans risquer
de faux pas. Il est responsable du bon respect de cette charte
par les quipes, et aussi le garant du maintien ou de la monte
en comptence artistique des quipes.
Design motionnel
Linvitable collection A Book Apart publie un livre du nom
de Designing For Emotion (Design motionnel, en franais), qui
apporte des preuves concrtes que lempreinte motionnelle
mise par un design conditionne fortement le comportement
de lutilisateur. Il explique galement des mcanismes pour
parvenir difuser lmotion la plus adapte au contexte.
Parmi les dmonstrations les plus spectaculaires du livre,
lauteur Aaron Walter explique comment un changement de
quelques couleurs lui a permis daugmenter sensiblement le
chifre dafaires dun site e-commerce majeur.
A. Walter, Design motionnel, A Book Apart , Eyrolles, 2011
Si lon dit que le directeur artistique sur des projets web
largeur fxe doit, dans la mesure du possible, avoir une bonne
connaissance des contraintes web, cette comptence devient
un prrequis indispensable lorsquil sagit dadapter le design
aux difrentes tailles dcran. En revanche, le contenu de son
travail changera peu dans ce contexte, surtout sil est habitu
travailler sur des projets multicanaux (une charte graphique
applicable simultanment un site web, une application
mobile, des supports imprims). Ici, la charte devra conserver
sa pertinence travers tous les contextes dcrans; mais ce nest
pas un exercice spcialement nouveau.
Lergonome et le designer fonctionnel
Lobjectif de lergonome est simple : rendre le site aussi facile
et rapide prendre en main que possible pour tout utilisateur.
Lobjectif du designer fonctionnel est aussi simple : porter la
vision fonctionnelle du projet (organisation de linformation,
fuidit dutilisation, correspondance aux objectifs dutilisa-
tion), ce qui le mnera le plus souvent la production de
nombreux wireframes/prototypes/storyboards/scnarios fonc-
tionnels, quil ne restera plus qu habiller esthtiquement. Les
deux rles ont des objectifs sufsamment proches pour tre
souvent mis en uvre par la mme personne, mme si lon peut
imaginer un ergonome nintervenir quen conseil, par exemple.
Il sagit de lun des rles les plus concerns par la gestion des
difrents crans. Une reprsentation fonctionnelle par gabarit
ne sufra plus : il faudra reprsenter toute la complexit de
tous les cas dutilisation, qui peuvent tre nombreux. Il faudra
aussi parfois remettre en cause les outils habituels, adapts aux
designs fxes. Nous reviendrons en dtail sur la conception
fonctionnelle au cours du chapitre5, qui lui est ddi.
Design persuasif : pourquoi et comment ?
Le design persuasif (persuasive design) est une notion qui fait
petit petit son apparition dans les rfexions de consul-
tants fonctionnels, notion autant controverse quelle est
potentiellement puissante. Lide initiale est dutiliser des
mcanismes de manipulation psychologique pour mener un
utilisateur atteindre un objectif donn.
Prenons un exemple concret utilisant lefet de gel (tendance
humaine vouloir rester cohrent contre sa propre volont):
on remplace le texte dun bouton Je souhaite accder
cette information par le texte Je souhaite accder cette
information et acheter ce produit . Lorsque, sur la page
suivante, on prsentera lutilisateur un bouton Acheter
ce produit , il aura alors plus frquemment tendance
raliser son achat jusquau bout, car il sy est psychologique-
ment engag au pralable.
Bien que la technique soit controverse, elle est au centre
des discussions en ce moment: nhsitez pas lire larticle
Persuasive Design: pourquoi et comment? par Raphal
Yharrassarri.
http://xav.cc/persuasive
6
Le designer graphique
Arm du travail du designer fonctionnel, le designer graphique
peut dcliner un site cohrent, respectant les contraintes
tablies par le directeur artistique. Il devra parfois faire des
choix tranchs quand ces deux ressources savrent incompa-
tibles, tout en matrisant continuellement la cohrence esth-
tique du site.
Si le fruit du travail fonctionnel est trs dtaill, rien ne chan-
gera, part le volume de crations rendre (sil est vraiment trs
dtaill, il faudra parfois une cration par gabarit et par largeur
dcran !) Dans les faits, les designers fonctionnels ne ralisent
pas toujours des livrables de type wireframes ou prototypes faci-
6. http://letrainde13h37.fr/31/persuasive-design-pourquoi-comment/
lement exploitables par le designer graphique. Ce dernier devra
donc intelligemment reconstituer ce qui est laiss son appr-
ciation, en suivant les rgles tablies par le designer fonctionnel.
Il sera alors soumis aux mmes contraintes techniques que lui.
Mme si le design fonctionnel et le design graphique sont deux
comptences bien distinctes, associes des approches trs
difrentes, il est frquent que ces deux rles soit tenus par la
mme personne. Une nouvelle fois, ces rles sont distribuer
intelligemment et, si votre designer est comptent sur les deux
aspects, vous auriez bien tort de vous priver de le mettre
contribution sur lensemble!
Le travail du designer graphique est dtaill dans le chapitre6.
L intgrateur
Un observateur lil peu expriment pourrait penser que le
travail de lintgrateur ne paie pas de mine, puisque sa fnalit
est de transformer des crations graphiques en pages statiques
ralises avec les technologies web front-end. Il commettrait
une double erreur.
En efet, ce travail ne pourra tre ralis quavec une compr-
hension avance des deux mondes: technique et design ( lex-
ception du chef de projet, il sagit du seul intervenant qui devra
matriser toutes ces notions). De plus, dans sa ralisation mme,
lintgrateur va souvent devoir porter seul la responsabilit
dun trs grand nombre dexpertises, notamment laccessibilit,
les performances et tous les aspects techniques du rfrence-
ment naturel. Sur les projets o il na pas t ralis de proto-
type dynamique, ce qui est trs frquent, il peut tre amen
prendre en charge une partie du design dinteraction et parfois
mme, une partie des lments graphiques manquants ; et il
devra combler tous les manques du travail artistique et fonc-
tionnel, sil y en a. Limiter son rle lintgration technique
dun support artistique serait donc terriblement rducteur...
Dans notre contexte, videmment, son travail est concern par
de nouveaux outils et il doit sapproprier de nouvelles bonnes
pratiques, mais ce nest pas le plus gros changement. Puisquil
est celui qui comprend le mieux les consquences techniques
du responsive web design, il sera bien oblig dajouter son
spectre un rle de conseil auprs des autres membres de
lquipe, quant ce qui est faisable ou non et ce qui est une
bonne pratique technique ou non. Cette responsabilit de
conseil est un rle complexe et trs difcile mettre en uvre
dans des quipes distribues; mais cest aussi une responsabi-
lit qui devrait sattnuer avec le temps dans le travail de lint-
grateur, au fur et mesure que les experts fonctionnels et ceux
du back-end se familiarisent avec leurs nouvelles contraintes.
Larchitecte back-end, le dveloppeur
et l architecte infrastructurel
Ces trois rles sont trs difrents et ne correspondent abso-
lument pas aux mmes tches, mais nous les avons regroups
ici car tous trois sont trs faiblement afects par ce contexte
particulier.
Larchitecte back-end a pour rle de construire les fonda-
tions techniques du projet, de manire le rendre ensuite plus
robuste et plus performant, plus rapide dvelopper et plus
simple maintenir dans le temps. Il sert aussi souvent dexpert
en bases de donnes (qui est parfois un rle spar).
Le dveloppeur a pour mission de connatre toutes les bonnes
pratiques de dveloppement dans la technologie back-end
choisie et de raliser la construction des pages en fonction des
donnes stockes et du contexte de lutilisateur.
Larchitecte infrastructurel a pour rle de faire les choix dor-
ganisation des serveurs physiques et des diverses applications
faire tourner sur les serveurs de production, afn de garantir
une disponibilit maximale.
Nous dvelopperons leurs quelques spcifcits au cours du
chapitre8.
Le contributeur
Lorganisation de ce rle est hautement dpendante des ambi-
tions ditoriales du site. Si le rythme de composition du
contenu est faible, toute la contribution sera peut-tre gre par
le product owner lui-mme. En revanche, dans le cas dun site
de presse national, le nombre de contributeurs locaux peut tre
norme et ncessiter un responsable des contributions pour
tout organiser (voire plusieurs responsables des contributions,
voire un chef des responsables des contributions!)
De nouvelles contraintes techniques lies au contenu sim-
posent ncessairement avec la gestion des difrentes tailles
dcrans; aussi le mtier du contributeur est-il ncessairement
chang. Dans le chapitre 10, nous dtaillerons les nouveauts
lies cette spcialit.
LES CHANGEMENTS EN COURS
DANS LES MTIERS DU WEB
Comme nous lvoquions prcdemment, lune des spcifcits
sympathiques des mtiers du Web est ltendue des nombreuses
expertises, mais aussi le fait que ces dernires voluent conti-
nuellement. Avec ces volutions, de nouveaux mtiers se crent
et les mtiers habituels voluent. Nous avons souhait runir
ici quelques volutions, rcentes ou en cours, susceptibles de
peser sur la sparation des expertises dont vous allez dcider
pour votre projet.
Lergonome devient UX designer
Lobjectif de ces deux mtiers peut sembler similaire (les deux
visent optimiser la facilit prendre en main ou utiliser
un produit), mais lUX design (design deXprience Utilisateur)
a apport une nouvelle philosophie et, par consquent, de
nouveaux processus et outils. Cette philosophie propose de
considrer un design comme un tout (une exprience) plutt
que comme la somme de ses parts (des composants lergo-
nomie optimise sparment). Elle exige donc que le designer
utilise des mthodes pour se mettre efcacement dans les chaus-
settes de lutilisateur et propose des solutions cet objectif.
Les solutions sont multiples et il faudra dfnir au pralable
celles quil vous semble pertinent dappliquer (et potentiel-
lement, les faire accepter au client). Parmi les plus simples
mettre en place, on trouve la ralisation de personas (fches
descriptives dutilisateurs imaginaires situs dans la cible) ou
le card sorting (tri de cartes, qui consiste faire regrouper des
fonctionnalits par un chantillon dutilisateurs). Certaines
pratiques sont un peu plus complexes efectuer et analyser,
comme les tests utilisateur en conditions relles ou leye-tracking
(enregistrement du trac du regard des utilisateurs lorsquils
visitent le site). Le vice peut mme tre pouss des pratiques
trs complexes et trs fnes, telles que des scanners crbraux
lors de la consultation dun design par un chantillon dutili-
sateurs (procd interdit en France, ce qui nempche pas les
annonceurs franais daller le faire raliser ltranger).
Le directeur artistique devient directeur
artistique interactif
Sil est vident que le Web a t loccasion de remettre en ques-
tion une bonne partie du mtier de concepteur dinterfaces (et
cest en partie cette remise en question que lon a coife du
surnom maladroit de Web2.0), la continuit de lexpertise
du directeur artistique a eu la vie dure pendant beaucoup plus
longtemps. On trouve toujours aujourdhui, en particulier dans
les agences de communication historiquement non web, des
gens convaincus que les talents et les connaissances ncessaires
un directeur artistique sont les mmes, quil fasse du Web ou
quil nen fasse pas.
Ce prjug est en train de sestomper, en mme temps que
changent les attentes du public envers le Web: linternaute nat-
tend plus aujourdhui le mme type de messages (ne serait-ce
que pour lorientation service forte des nouveaux mdias...
un site efet waouh mais sans utilit ne convainc plus).
Ajoutez cela aux procds cognitifs fortement difrents, que
lon connat de mieux en mieux, et vous obtenez une spcialit
qui doit revoir les partis pris sur lesquels elle sest construite,
pour dsormais mieux sadapter aux besoins interactifs.
L intgrateur devient... ?
Nous vous disions que le rle de lintgrateur tait celui qui
contenait le plus de responsabilits difrentes; sachez que la
tendance nest absolument pas la simplifcation!
Sur laxe technique, tout dabord, ce qui tait prcdemment
un mdia de consultation de documents avec une interactivit
limite se complique progressivement pour devenir un vritable
enchevtrement de technologies autorisant des possibilits de
plus en plus compltes. Pour commencer, les spcifcations
existantes se compliquent (enrichissement rapide du CSS, du
HTML, du JavaScript) et de nouvelles spcifcations deviennent
de plus en plus utilisables en production (monte du format
SVG Scalable Vector Graphics qui ne date pourtant pas dhier,
mais aussi du Canvas, du WebGL). Par consquent, les outils
permettant de manipuler ces technologies sont bien obligs de
se compliquer aussi. Les frameworks CSS apportent chacun
leurs solutions au problme dindustrialisation, pendant que
les design patterns que lon avait lhabitude de ctoyer du ct
back-end conquirent petit petit le front-end (voir lencadr
page suivante).
Lintgrateur na donc jamais t aussi technique et les faiseurs
de Web francophones sannoncent de plus en plus sduits par
lappellation anglo-saxonne pour le mme mtier: dveloppeur
front-end. Et pourtant, cette appellation serait toujours rduc-
trice bien des gards: le rle de lintgrateur ne se complique
pas seulement sur le plan technique, mais aussi sur le plan
du design. Avec lefet grandissant de linteractivit toutes
les phases de design, lintgrateur est amen de plus en plus
corriger et assister les designers, tout en ayant un rle de
validation de faisabilit dans la rfexion UX.
Il est possible dimaginer qu terme, il devra progressivement
devenir le lien privilgi entre les deux quipes, design et tech-
nique (et si nous souhaitions pousser le bouchon peine plus
loin, il sera sans doute lultime super-hros du Web!)
Le design pattern par lexemple
Le sujet du design pattern (pardon, ternels Acadmiciens :
le patron de conception !) est trs technique et ncessite
une bonne afnit avec le dveloppement applicatif pour
tre compris. Sil faut poser une dfnition, il sagit dune
manire thorique dorganiser le code dune application ou
dune partie dapplication complexe. On parle trs souvent
du design pattern MVC (Modle, Vue et Contrleur) qui
est un excellent exemple, car valable pour de nombreux
cas dapplications autonomes : on y divise le code en trois
couches : la couche Modle , qui gre le contact avec
les donnes, la couche Vue, qui compose linterface, et
la couche Contrleur , qui manipule les deux autres et
efectue les calculs ncessaires.
Dans le cadre du back-end (ct serveur), la distribution est
simple imaginer: la couche Modle lit et crit dans la
base de donnes et la couche Vue compose le HTML
renvoyer au client. En revanche, dans le cas dinterfaces
complexes comme Facebook, il vaut mieux dcouper lin-
terface elle-mme en composants simples, qui sautogrent.
La couche Modle, dans le code Javascript (ct client),
assure alors le contact avec le serveur web, qui lui envoie des
donnes brutes. La couche Vue manipule ces donnes
brutes reues pour leur donner leur forme fnale en HTML.
Pour lexemple de Facebook, cela permet notamment
chacun des commentaires de votre fl dactualits de se
mettre jour en temps rel, sparment des autres, les
difrents statuts interagissant avec le serveur chacun sa
manire.
Les interfaces complexes se gnralisant, le besoin devient
de plus en plus frquent, tel point que des outils traitant le
problme commencent simposer, avec en tte Backbone.JS,
Angular.JS, ainsi que Ember ou Knockout.
LAMLIORATION CONTINUE DES EXPERTISES
Si vous faites partie dune agence qui commercialise du service,
la valeur ajoute de votre entreprise par rapport sa concur-
rence est surtout reprsente par trois lments: le fruit de sa
capitalisation (sous forme doutils et de mthodologies, notam-
ment), la capacit de ses employs travailler ensemble efca-
cement (cest une de vos forces par opposition des travailleurs
en free-lance venant potentiellement dhorizons difrents) et
surtout, lexpertise globale de ses employs. Et si vous tenez
ne pas voir saltrer votre valeur ajoute, alors deux soucis
devraient vous proccuper au quotidien : ne pas perdre les
expertises que vous possdez au sein de votre organisation et
les faire continuellement crotre pour suivre au mieux leurs
volutions.
Avec la vague de rcentes volutions dexpertises lies au
responsive web design, cette inquitude pourrait prendre
de nouvelles proportions : si vous navez jamais fait de site
responsive denvergure, il y a fort parier que vos quipes
vont connatre des difcults substantielles sur les premiers
projets, car il faut un certain temps dapprentissage. Il existe
toutefois des solutions plus ou moins simples mettre en place
pour maintenir et amliorer le niveau gnral de vos quipes:
le rapprochement des comptences, la capitalisation sur les
expertises internes et la mise en place dune culture de veille.
Le rapprochement des comptences
Ne repoussez pas les occasions de permettre un membre
de votre quipe den savoir plus sur une comptence quil ne
matrise pas, mais qui est matrise par un autre collaborateur.
Certes, la solution simple est dafecter le chantier la personne
qui le matrisera dj le mieux, mais lorsquil est imaginable de
faire difremment avec une faible perte de qualit, nhsitez
pas sauter sur loccasion. Une mthode trs efcace pour
atteindre facilement cet objectif consiste simplement runir
des intervenants dexpertises trs difrentes dans la mme
pice; lapprentissage se fera alors en douceur, sans aucun efort
de la part de vos collaborateurs. Les rsultats seront excellents
pour vous long terme: non seulement vous perdrez le moins
possible des expertises de vos collaborateurs le jour o ils quit-
teront lentreprise, mais vous faciliterez aussi la gestion de vos
collaborateurs en vous ofrant plusieurs options chaque fois
que vous devrez monter une nouvelle quipe.
Capitaliser sur les expertises internes
Ce qui peut sembler simple est en ralit le cauchemar de la
plupart des agences web. Comment organiser les retours dex-
prience de manire retrouver ce qui est pertinent pour votre
projet actuel, tout en favorisant la simplicit de contribution?
La solution passe souvent par plusieurs outils, correspondant
plusieurs cas dutilisation; mais le plus important est de trouver
les solutions qui sont adaptables votre cas, et cest l ce qui est
le plus difcile.
Mettre en place une culture de veille
Vous ne pourrez pas faire monter votre quipe en comp-
tence avec votre seule veille, car les mtiers du Web sont bien
trop tendus pour quil soit possible de les suivre une seule
personne. La veille doit absolument tre efectue par chacun
de vos collaborateurs. Il sagit souvent dune culture mettre
en place: vous pouvez donner les outils et linspiration. Incitez
vos collaborateurs et collgues lire des sources que vous
savez de qualit et partager les sources quils dcouvrent eux-
mmes. Vous ne savez pas par quoi commencer? Vous dtenez
peut-tre un dbut de solution entre les mains ! Vos quipes
auront peut-tre des opinions et pourraient ouvrir des dbats
intressants sur les approches proposes par ce livre...
La pr-
conception
LA PR- CONCEPTI ON 63
La phase de pr-conception est une tape importante du projet.
Cest elle qui va permettre de poser ses prrequis dfnitifs
avant sa prise en main par lquipe projet. Cest typiquement
ce moment l que lon dfnit le primtre exact de ce que le
client appelle responsive . cette occasion, il nest pas rare
que lon produise des prototypes ou des POC (Proof Of Concept)
pour obtenir les premires validations du client.
LES APPROCHES DE CONCEPTION
Les projets responsive sont souvent plus difciles mettre en
uvre car ils demandent de faire le grand cart entre des condi-
tions dutilisation parfois radicalement difrentes. Entre, dun
ct, un ordinateur de bureau avec connexion ADSL, clavier,
souris et cran 27 pouces et, de lautre, un smartphone avec
connexion EDGE, interface tactile et cran de 3,5 pouces, la
difrence est norme. Et pourtant, il va vous falloir grer laf-
fchage dun mme site et ses interactions sur ces deux envi-
La pr-
conception
ronnements, ainsi que sur tous les systmes intermdiaires
imaginables.
Pour cette raison, il est ncessaire de passer un temps beaucoup
plus important en conception, le nombre de points prendre en
compte tant bien plus lev. Cependant, pour ne pas sombrer
dans le pige dune conception qui nen fnit jamais, ce travail
peut tre orient de diverses manires.
Mobile first : le mobile dabord !
Une des approches de conception les plus connues est celle
appele mobile frst. Cette mthode recommande de commencer
par la conception mobile, qui comprend le plus souvent les appa-
reils les plus petits: petit cran, petit processeur, petite connexion.
Cest une logique de contrainte maximale : si a passe dans ces
conditions, a passera forcment avec de meilleures conditions!
Cette logique de contrainte maximale oblige se concentrer sur
les points essentiels du projet : les contenus et les fonctionna-
lits les plus importants. De plus, les tout petits crans des smart-
phones supportent difcilement les mises en page complexes; le
rfexe habituel est donc de tout linariser sur une seule colonne,
le plus efcace tant mme dadopter une logique de une page
gale une fonctionnalit unique . Cela aussi est trs pratique,
car cela permet de formater clairement le fux HTML correspon-
dant, les mises en forme des contenus sur des crans plus grands
pouvant alors se reposer sereinement dessus.
Cependant, cette approche a quelques dfauts.
Elle peut vous conduire commettre une grave erreur: sup-
primer ou repousser des fonctionnalits plus complexes
en prtextant quelles sont peu ou pas adaptes au contexte
mobile. Ce nest pas parce quune fonctionnalit ne peut pas
tre utilise dans un certain contexte quelle nest pas valable
pour autant. Lexemple le plus criant est un tunnel dachat
e-commerce. Dans un contexte mobile, cette fonctionnalit
peut tre un vritable repoussoir pour les utilisateurs et un
cauchemar mettre en uvre, mais sur un site de vente, on
ne peut tout simplement pas sen passer.
Elle peut conduire une simplifcation excessive du design
ou de lexprience utilisateur. La simplicit quon attend dun
site sur un appareil mobile nest pas ncessairement celle
quon attend quand on est confortablement assis son bu-
reau. Chaque contexte dutilisation a ses propres codes duti-
lisation et il est important de ne pas les oublier.
User first : l utilisateur dabord !
Une autre approche de conception en vogue est celle appele
user frst. Elle commande de mettre les usages et fonctionnalits
ncessaires aux utilisateurs au centre de la conception. Cest
souvent la mthode prfre des UX designers (designers dex-
prience utilisateur). Elle repose sur la mise en place de tests
utilisateur visant sassurer que les fonctionnalits et leur utili-
sation sont toujours optimales quels que soient les contextes
dutilisation.
Cest souvent la mthode qui donne les meilleurs rsultats,
mais l encore, elle nest pas parfaite...
Elle peut coter cher. En efet, organiser des tests utilisateur
a un cot: temps de prparation des entretiens, locaux pour
raliser les tests, temps danalyse, correction et amlioration
des interfaces le tout rpt parfois plusieurs fois. Si vous
voulez vous engager dans cette voie, vous devrez souvent
commencer par convaincre votre client de fnancer cette par-
tie du travail de conception.
Elle ne favorise pas les interfaces innovantes ou valeur
ajoute. Demander un panel dutilisateurs ce quils pen-
sent dune interface, mme en sachant habilement mener des
tests utilisateur, conduit souvent produire des interfaces
moyennes, sans asprit. Ainsi, si dans le cadre dun site
de vente en ligne traditionnel, cela peut se rvler intressant,
vous nobtiendrez jamais des interfaces qui se dmarquent
des autres ; moins, videmment, de travailler avec un
designer particulirement comptent qui sera capable de pas-
ser outre certains retours des utilisateurs et de valoriser les
plus cratifs (on a parfois des surprises)... auquel cas vous tes
dj en train de vous loigner de cette mthode.
Les autres logiques et la gestion
des contraintes
Choisir lune ou lautre de ces mthodes dpend de vos prf-
rences et de votre contexte projet. Il existe bien dautres
approches de conception, chacune avec ses avantages et ses
inconvnients. force dexprience, vous vous rendrez compte
quau-del de la mthode, cest clairement les demandes du
client et les contraintes associes qui vous aiguilleront : opti-
misation pour les moteurs de recherche (SEO), accessibilit,
performances, etc. sont autant dlments qui vous pousse-
ront tordre les mthodes en fonction de vos besoins. Cela
peu paratre un peu simpliste, mais faire preuve de bon sens et
viter de vous compliquer la vie inutilement sera sans doute ce
qui vous permettra de vous en sortir le mieux.
Cependant, en tout dbut de projet, choisir une mthodologie
de conception aidera les difrents intervenants du projet
connatre la direction prise. Ne vous arc-boutez pas dessus
tout prix, mais utilisez-la comme un garde-fou pour vous
assurer que tous les membres de lquipe et le client sont sur la
mme longueur dondes.
lire : les approches *-rst
Nicolas Hofman a trs bien synthtis les limites des approches
de conception web *-frst sur le blog dOpenweb:
http://xav.cc/frst
7
7. http://openweb.eu.org/blog/les-approches-frst
GRER LES GABARITS
Une des principales difcults des projets responsive consiste
crer une synergie efcace entre les intgrateurs et les
designers. Si ces profls sont amens travailler chacun de leur
ct sans interactions rgulires, vous pouvez tre sr que
votre projet virera la catastrophe. En efet, les contraintes et
les possibilits quofrent les interfaces responsive sont encore
mal matrises, dun ct comme de lautre. En particulier, les
designers sont souvent mal laise avec les interfaces qui
changent et sadaptent. De leur ct, les intgrateurs sont parfois
drouts par des contraintes lies lexprience utilisateur.
Les principales difcults tournent autour de deux points
spcifques quil conviendra de rsoudre le plus tt possible :
les types de gabarits du projet et les points de rupture associs.
Les diffrents types de gabarits
En matire de design web, les types de gabarits utilisables se
divisent en trois grandes catgories : les gabarits fxes, las-
tiques et fuides. Dfnir quel type vous allez utiliser lors du
projet vous aidera mieux cadrer les quipes de design et din-
tgration, tout en leur permettant de dvelopper un langage
commun.
Les gabarits fxes
Il sagit du type de gabarits le plus utilis. Aprs tout, il sagit du
plus simple apprhender pour tout le monde. Sa principale
caractristique tient au fait que toutes les dimensions sont fxes.
Elles sont fxes en pixels et sont donc invariables. Cest cette
caractristique qui le rend si facile utiliser.
En efet, du point de vue du design, il sapparente ce qui se fait
dans le monde du papier et tous les outils de production pour
ce support (logiciels de mise en page ou de retouche dimages)
sont facilement rutiliss pour designer ce genre de gabarits.
Du point de vue de lintgration, ils sont galement les plus
simples mettre en uvre, dans la mesure o seuls les change-
ments de dimensions verticales sont prendre en compte. Cest
beaucoup plus facile.
Cependant, si cela est toujours vrai aujourdhui, le changement
apparu depuis quelques annes dans la notion de pixel rend
les choses moins videntes quil ny parat (nous y reviendrons
au chapitre7, consacr au design graphique).
Les gabarits lastiques
On parle aussi parfois de gabarits fexibles. Ceux-ci sont trs
similaires aux gabarits fxes, la difrence tenant dans les units
de mesure utilises. Si les gabarits fxes reposent sur le pixel,
qui est une unit de mesure invariable, les gabarits fexibles
reposent sur des units relatives bases sur la taille des polices
de caractres.
Le principal avantage de ces gabarits vient de leur capacit
sadapter automatiquement la taille des fontes du document,
quels que soient les rglages du navigateur. Les proportions
entre les textes et la mise en page seront toujours respectes.
B.A.-BA : units de mesure
La norme CSS connat quatre units de mesure pour la taille
des polices : le ex, le ch, le em et le rem. Les units ex et ch
sont peu employes car fortement dpendantes de chaque
fonte, ce qui rend leur valeur difcilement prvisible si lon
utilise plusieurs fontes difrentes dans un document. Lunit
la plus utilise ce jour est le em, mais les rgles dhritage qui
lentourent rendent son usage dlicat. Pour cette raison, lunit
rem, toujours identique, va vraisemblablement la remplacer
rapidement. Le seul dfaut de lunit rem est de ne pas tre
prise en charge par les navigateurs les plus vieux que sont
Internet Explorer 6 8.
La manipulation de ce type dunits de mesure pouvant tre
assez dlicate, les intgrateurs rencontrent parfois des dif-
cults importantes pour lutiliser. Dans ce cas, lutilisation dun
framework de dveloppement ou dun prprocesseur CSS peut
tre une bonne solution.
Les gabarits fuides
Contrairement aux deux prcdents, les dimensions de ces
gabarits sont dtermines par la taille du viewport du navi-
gateur. Pour cela, lunit la plus utilise est le pourcentage.
Cependant, cette unit soufre du mme problme que le em,
sa valeur exacte dpendant de la taille de son conteneur. CSS3
a dfni de nouvelles units plus pratiques utiliser, mais elles
ne sont pas encore disponibles dans tous les navigateurs, mme
les plus modernes.
La notion de viewport et ses mesures
Le viewport correspond lespace visible ddi lafchage
dune page dans le navigateur.
Les nouvelles units de mesure CSS pour les gabarits fuides
sont le vw (1vw est gal une fois la largeur du viewport), le vh
(1vh est gal une fois la hauteur du viewport), le vmin (1vmin
est gal une fois la plus petite des dimensions du viewport), le
vmax (1vmax est gal une fois la plus grande des dimensions
du viewport).
Ce type de gabarits est particulirement adapt aux interfaces
applicatives ou pour les plates-formes matrises (avec un
seul appareil connu), pour lesquelles il peut tre plus efcace
de se baser sur le contenant plutt que sur le contenu lorsquon
cre linterface.
Les autres types de gabarits
Dans les faits, il est assez rare que les gabarits utiliss soient
tout lun ou tout lautre des catgories cites prcdemment.
titre dexemple, les gabarits les plus connus sont ceux qui
mlangent des colonnes fxes et fuides, avec une contrainte
sur les colonnes fuides pour viter quelles ne deviennent trop
larges ou trop troites.
Des proprits CSS exploiter
Les proprits CSS min-width, min-height, max-width et
max-height restent encore largement sous-exploites, alors
quelles sont disponibles dans tous les navigateurs.
Il existe deux autres types de gabarits sur le Web, particuli-
rement exotiques car peu ou pas utiliss, que ce soit pour des
raisons ergonomiques ou de difcults de mise en uvre. Il sagit
des gabarits horizontaux et des gabarits pagins. Les premiers
sont en gnral complexes comprendre dun point de vue utili-
sateur (mme sil est vrai que larrive des appareils mobiles tend
attnuer cette difcult, du fait de labsence de souris et de leurs
molettes verticales). Les seconds sont particulirement difciles
mettre en uvre et ne sadressent qu des cas trs particuliers
comme les livres numriques ou les imprimantes.
Dfinir des points de rupture
Faire face la diversit croissante des terminaux
Comme nous lavons dit plus avant dans ce chapitre, un projet
responsive va devoir faire le grand cart entre des appareils aux
capacits parfois radicalement difrentes. La difrence qui
sera sans doute la plus fagrante sera la taille des crans.
Mme sil est techniquement possible dafcher exactement la
mme mise en page sur tous les terminaux, il sera trs difcile,
voire impossible, de garantir la mme exprience utilisateur
dans tous les cas. Pour cette raison, il est souhaitable dadapter
le design dun site aux capacits exactes dun terminal donn.
Concrtement parlant, cela passera par lusage de plusieurs
techniques, la plus connue tant lusage des requtes de mdia
CSS (CSS media queries).
B.A.-BA : les CSS media queries
Les requtes de mdia CSS, en anglais CSS Media Queries, sont
une solution permettant dappliquer une feuille de styles en
fonction des caractristiques du support qui lutilise. Il sagit
dune volution rcente de CSS. Alors que CSS2 ne connaissait
que des mdias tels que screen ou print, CSS3 a ajout les
caractristiques intrinsques de ces supports.
http://xav.cc/css3mq
8
Il est intressant de noter que cest limplmentation massive
et rapide de cette recommandation, associe la sortie du
premier iPhone en 2007, qui a men la cration de ce que lon
appelle aujourdhui le responsive web design.
La grande question que lon devra se poser systmatiquement
est la suivante : partir de quel taille de viewport vais-je
changer mon design pour amliorer lexprience utilisateur?
Ces difrentes tailles dfnissent ce quon appelle les points de
rupture, parce que lon cre une rupture dans la continuit des
designs.
Comment dfnir les points de rupture?
Jusqu prsent, nous avions pris lhabitude de choisir une
palette de matriels reprsentative comme base pour dfnir
les points de rupture. Ne nous le cachons pas, il sagissait le
plus souvent de liPhone, de liPad (dans les deux orientations)
8. http://www.w3.org/TR/css3-mediaqueries/
et dun grand cran. Malheureusement, cette approche est
aujourdhui une voie sans issue. En efet, la diversit des mat-
riels tend crotre une vitesse alarmante et il devient illusoire
den trouver une palette reprsentative. Si cela est bien connu
avec les appareils Android, il en va de mme dsormais avec
les appareils Apple. En efet, avec la sortie de liPad mini et de
liPhone5, les cartes se brouillent de plus en plus.
propos de liPad mini
LiPad mini a une particularit qui gne beaucoup de dve-
loppeurs web. Cet appareil est physiquement deux fois plus
petit quun iPad ordinaire. Cependant, il est techniquement
impossible de difrencier les deux: requtes de mdia, dtec-
tion de fonctionnalits en JavaScript ou chane dagent utili-
sateur, tout est identique. tout point de vue, liPad mini se
prsente donc comme un iPad normal, alors quil ne lest pas.
Sil nest plus possible de sappuyer sur le matriel, alors que
faire ? Il sagit l souvent dun drame, car les designers qui
sont trs habitus travailler sur des tailles fxes sont souvent
compltement perdus. Ce nest pourtant pas si compliqu, car
il suft de se poser deux questions.
Combien de colonnes doit comporter le design? Les cas les
plus courants sont 1, 2 et3: 1pour les smartphones, 2pour
les tablettes et 3pour les grands crans. Vous pouvez bien sr
aller au-del ou en-de, tout dpendant encore une fois du
contexte.
Quelles sont les tailles minimale et maximale que doit avoir
chaque colonne? Ces tailles dpendront du contenu de cha-
cune des colonnes (texte, photos, les deux), mais aussi du fait
que vous envisagiez ou non de les diviser en sous-colonnes.
Ce sera typiquement le cas si vos designers utilisent des sys-
tmes de grille typographique. Il ny a pas de bonne taille en
soi. Gardez juste lesprit quil existe quelques rgles dacces-
sibilit simples qui peuvent vous aider faire les bons choix:
une ligne de texte doit toujours faire entre 60 et 80caractres
de large pour tre agrable lire et le texte courant ne devrait
jamais faire moins de 12pixels de haut.
Bien sr, le colonage nest que la partie merge de liceberg et
il vous faudra galement vous poser des questions sur la navi-
gation et toutes les formes dinteractions entre lutilisateur et
le site. Quoi quil en soit, ce sera l aussi le contenu qui vous
guidera dans vos choix.
La gestion des cas intermdiaires
Sur ce point, nous en avons soit trop dit, soit pas assez, et nous
vous sentons piafer avec une question au bord des lvres: que
se passe-t-il dans les cas intermdiaires ? Avant toute chose,
sachez que la rponse est la mme que si vous aviez dfni vos
points de rupture de manire totalement arbitraire. Prenons
un exemple : imaginons un cas ou nous pourrions afcher
2 colonnes et 9 diximes de colonne, mais pas 3 colonnes. Et
bien, l, cest le talent de vos designer et intgrateur qui est mis
lpreuve. Pour faire simple, soit vous travaillez sur la base de
colonnes largeur fxe et, dans ce cas, vous devez prvoir avec
vos designers dhabiller le vide, soit vous travaillez avec des
colonnes largeur fexible et, dans ce cas, cest le talent de votre
intgrateur qui va faire la difrence (que ce soit en proposant
des colonnes qui sadaptent en largeur ou en changeant la taille
des polices pour sadapter la largeur du priphrique). Ainsi,
en plus de la question Combien de gabarits difrents sont-
ils ncessaires?, une nouvelle question fait son apparition:
Comment ces gabarits sadaptent-ils leur environnement?
L encore, en dfnissant clairement des rgles dadaptation
lmentaires, vous balisez prcisment les limites de vos gaba-
rits et vitez les questions embarrassantes de fn de projet du
type: Mais pourquoi sur mon cran 27pouces la maison, le
site safche-t-il tout petit et tout moche?
Ces rgles vont galement vous tre indispensables si votre
client fait appel une agence tierce pour grer le design.
Avec une dfnition claire des points de rupture bass sur les
contenus, vous pouvez canaliser les designers sans pour autant
les enfermer dans des schmas trop rigides. En revanche, il
vous faudra tre infexible. Si vous avez dfni des gabarits de
ncolonnes au maximum, lagence de design devra imprative-
ment fournir le nombre de gabarits correspondant. L encore,
plus cela sera tabli en amont, plus vous prviendrez les carts
et les problmes en cours de projet.
Ainsi, en vous posant ces quelques questions, vous aurez sans
aucun problme des points de rupture qui sadapteront tous
les cas de fgure, tout en garantissant une exprience utilisateur
optimale. Lultime question sera le nombre de points de rupture
souhait. En efet, au-del du nombre de colonnes, vous pour-
riez vouloir ajuster dautres paramtres sans changer de gabarit
(les tailles de polices typographiques, par exemple). Les possibi-
lits sont quasi infnies, aussi vous faudra-t-il faire des choix de
fond entre qualit dexprience utilisateur, complexit de main-
tenance, capacit faire des quipes, souhaits du client, etc.
Au fnal, cest votre budget qui vous indiquera jusquo vous
pouvez aller.
LES OUTILS NCESSAIRES LA CONCEPTION
Vous tes donc prt entrer en conception. Avant de plonger
dans le grand bain, parlons un peu doutillage. L non plus, nous
ne rentrons pas dans une liste dtaille qui, de toute faon, sera
obsolte dans quelques semaines. Nous allons plutt rapide-
ment passer en revue les trois grands types doutils qui vont
vous aider lors de la phase de conception. Bien sr, vous nou-
blierez jamais le papier et le crayon, qui resteront toujours vos
meilleurs amis en matire de conception.
Les outils de conception fonctionnelle
Ces outils vont vous aider crer des schmas et wireframes
tout en les annotant. Les plus avancs permettent de produire
des cahiers des charges fonctionnels complets. Le plus connu
dentre eux est sans doute le logiciel Axure.
Les outils de cration des wireframes
Ces outils, plus spcialiss que les prcdents, servent crer
facilement des rendus flaires (les fameux wireframes, en anglais)
de vos gabarits pour les soumettre la sagacit de votre client,
sans le distraire avec un design parfois inachev. Lun des plus
connus est sans doute le logiciel Balsamiq, mais il en existe des
quantits sur le march ; titre dexemple, citons UX Pin ou
Moqups. Peu de gens le savent, mais le logiciel InDesign de
Adobe se prte particulirement bien ce type dexercice, du
fait de sa prise en charge du format ePub.
suivre : Adobe Edge Reow
Dans le cadre de sa suite doutils Edge ddie au dveloppe-
ment web moderne, Adobe vient de mettre disposition un
outil spcifquement ddi la conception de sites et appli-
cations reponsive: Refow. Certes encore jeune, cet outil doit
tre suivi de prs.
http://html.adobe.com/edge/refow/
Les frameworks de dveloppement rapide
Ces outils sont utiliss lorsquon veut produire des prototypes
fonctionnels rapidement ou si la phase de conception se fait en
troite collaboration avec les intgrateurs. Lide est moins de
dfnir des fonctionnalits particulires que de sassurer de leur
faisabilit ou de leur pertinence dans un contexte dynamique.
Lun des plus connus est sans doute Bootstrap, le framework de
Twitter, mais l aussi, il en existe quantit dautres.
Avec ces outils, vous tes arm pour la suite. Nous pouvons
donc passer en conception.
La conception
LA CONCEPTI ON 77
La conception est un passage oblig pour tout projet. Cest ce
moment-l que sont dfnies toutes les demandes fonctionnelles
et que la faisabilit technique est concrtement value. Cette
phase prend une dimension toute particulire pour les projets
faisant appel au responsive web design, puisque cest l que vont
se heurter frontalement les demandes du client et les contraintes
techniques que nous avons voques prcdemment.
LA RPARTITION DES RLES
Lune des principales caractristiques dans la conception des
projets responsive est la rpartition des rles entre designers
et intgrateurs. Alors que, traditionnellement, la conception
est supervise par le chef de projet avec lappui des quipes de
design, la prsence dun intgrateur expert est ici un avantage
non ngligeable. Voyons exactement ce que cela apporte.
6
La conception
Le designer web
Son rle au niveau de la conception joue essentiellement sur
deux aspects : dune part, le design, tche qui lui est dvolue
traditionnellement; dautre part, la conception de lexprience
utilisateur.
Concernant le design, il ne cre rien de visuel pendant la
phase de conception, mais est le garant de ladaptabilit des
contraintes graphiques et fonctionnelles. Concrtement, il
vrife que, quels que soient les contextes dutilisation dfnis,
il sera possible de crer et de proposer par la suite un univers
graphique cohrent. En efet, les carts de contextes dont nous
avons dj parl (taille dcran, accessibilit des zones dac-
tion, prcision des interactions utilisateur) ont des incidences
parfois radicales sur le design. Cela requiert une expertise bien
particulire, souvent lie lexprience dInternet qui, au mme
titre que le support papier, a ses propres rgles de conception
et ses contraintes spcifques. Cest dautant plus critique ici car
le nombre de contraintes lies cette approche est encore plus
important.
L intgrateur expert
Comme nous lavons vu au chapitre3, lintgrateur peut avoir
plusieurs comptences parfois trs difrentes. Lors de la
phase de prototypage, vous aurez besoin dun expert en CSS et
HTML. En efet, cest lui qui doit valider la faisabilit technique
des partis pris de conception. Pour tre trs prcis, au-del de
la faisabilit pure, se pose galement la question du cot de la
ralisation. En efet, il y a peu de choses qui sont totalement
infaisables dans un navigateur, pour peu que vous y mettiez
plusieurs centaines de kilo-octets de JavaScript. Attention ce
pige redoutable! Ce nest pas parce que cest faisable que cest
facile et gratuit... loin sen faut.
LA CONCEPTI ON 79
Ainsi, chaque fois que vous vous posez la question Est-ce
faisable?, vous devez toujours la complter par en Xjours.
De mme, il est important de sassurer que toutes les contraintes
du projet ont t clairement exposes (SEO, accessibilit, perfor-
mances...) Cest ces seules conditions que lintgrateur expert
pourra qualifer la faisabilit. Si cette qualifcation est faite sur
des bases imprcises, vous pouvez tre sr que le budget du
projet sera revoir pendant la phase de ralisation. En clair, si
lexpert dit Non!, alors cest non; sil dit Oui, alors vri-
fez deux fois que vous lui avez pos la bonne question.
LE PROTOTYPAGE
Lquipe est prte? Parfait, cest maintenant que lon passe aux
choses srieuses. Le prototypage sert faire valider fonctionnel-
lement tout ce qui a t dfni prcdemment: pertinence des
points de rupture, choix des fonctionnalits selon le contexte,
etc. Cest galement loccasion de dfnir trs prcisment les
difrents parcours client et de mettre en place les premires
briques de lexprience utilisateur.
Un prototype nest rien dautre que la transformation dun
cahier des charges et de tous les prrequis du projet en un
objet qui sera manipulable comme le site fnal. Entre autres
bnfces, il permet dclairer tous les non-dits du cahier des
charges, sachant quun prototype est parfois utilis mme par
les dveloppeurs back-end pour comprendre ce quils doivent
faire. Il prsente galement lavantage de faire comprendre au
client certaines difcults lies aux transitions entre les dif-
rents contextes de navigation, grce une formalisation trs
concrte.
Soyez prvenu, cette phase du projet est longue car elle solli-
cite normment le client, alternant les phases de travail frn-
tique et les longues journes dattente. Cela a une incidence non
ngligeable sur le stress des quipes. Lors de cette phase, il est
donc crucial que le chef de projet soit trs prsent, en souf-
fant le chaud et le froid afn de sassurer que tout se droule
correctement. En efet, si le travail de conception est correcte-
ment ralis, la phase de mise en uvre se droulera avec un
minimum de problmes. linverse, si la phase de conception
est nglige, tout le monde soufrira jusquaprs la livraison du
projet, quand il faudra rsoudre les problmes lors de la phase
de TMA (la fameuse tierce maintenance applicative dont nous
reparlerons au chapitre12).
Valider par une intgration minimale
de la maquette
Un prototype nest pas le produit fni, mais seulement un sque-
lette qui permet de valider le fonctionnement du site fnal.
Pour cette raison, il est crucial de mettre le moins dlments
graphiques possibles dans ce que vous allez montrer au client.
Ajoutez une couleur ou une police typographique exotique
et vous pouvez, hlas, tre sr que votre client se focalisera
l-dessus plutt que de vous faire des retours constructifs sur le
fonctionnement global de ce que vous lui montrez. Cependant,
cela ne veut pas dire quil ny a rien du tout. En particulier, cest
souvent le bon moment pour fxer prcisment les rythmes
horizontaux et verticaux utiliss pour caler les textes (la grille
typographique qui sera plus tard utilise en design graphique).
Cela donne un aspect fni au prototype sans pour autant
engendrer de bruit graphique qui pourrait distraire votre client.
Bonne pratique : le Lorem Ipsum
Le Lorem Ipsum ou faux texte est une technique aussi
vieille que la composition typographique, consistant
utiliser un texte de substitution pour raliser une mise en
page sans connatre les textes dfnitifs. On utilise bien
videmment cette technique aussi en conception web,
soit pour prsenter un texte neutre dont le contenu ne
perturbera pas la personne qui va devoir faire des valida-
LA CONCEPTI ON 81
tions, soit pour simuler des volumes arbitraires de textes sur
des emplacements de contribution dynamique.
On notera que les designers web ne manquent pas dhumour
sur ces faux textes. Nous vous laissons apprcier le Gangsta
Ipsum ou bien le Van damme Ipsum:
http://chooseyouripsum.com
http://www.faux-texte.com
Sinon, plus srieusement, il existe galement des faux textes
cibls pour leur donner un ct raliste:
http://notloremipsum.com
Enfn, le concept existe aussi avec les images. Il existe des
gnrateurs dimages temporaires pour se fgurer leur
emplacement sans utiliser quelque chose de fguratif. Le plus
connu dentre eux est sans doute Dummy Image:
http://dummyimage.com
Comme nous lavons vu au chapitre 5, il existe moult outils
pour raliser des prototypes. Cependant, il peut tre pertinent
de prototyper directement en HTML. Ce type de prototypes
permet de mesurer concrtement la faisabilit technique de
tel ou tel parti pris de conception sur les questions de design
responsive. Des frameworks comme Twitter Bootstrap sont
particulirement adapts ce genre dexercice et des solutions
wysiwyg (what you see is what you get) pour simplifer leurs
usages, comme le site jetstrap.com, sont en train de voir le jour.
Bien sr, si vous avez vos propres frameworks, ce peut tre une
excellente faon de mutualiser les tapes de conception et din-
tgration, le prototype tant alors repris tel quel pour raliser
lintgration fnale. Attention cependant, ce nest pas parce quil
est possible de mutualiser ces deux phases quil sera possible
de faire baisser le cot du projet. Prenez a plutt comme une
scurit budgtaire et assurez-vous que les deux phases sont
toujours chifres indpendamment. En efet, il nest pas rare
de devoir refaire compltement ce qui a t fait pendant la
phase de prototypage pour rpondre une contrainte particu-
lire lors de lintgration.
Lobjectif du prototype nest pas davoir un squelette pour lint-
gration, mais de faire valider tous les aspects fonctionnels du
site par le client.
Comment traiter les retours ?
Le prototype vous servira tout autant de livrable matrialisant
la vision fonctionnelle que de support de communication sur
lequel chacun sappuiera pour changer. cet gard, les retours
que le client (ou votre product owner) vous fera sont cruciaux
et il faut aussi bien les provoquer et les cadrer que les prendre
en compte intelligemment.
Pour provoquer ces retours efcacement, il faut une commu-
nication riche entre le client et vous ; autant que possible,
bannissez les retours sous forme de liste rdige et privilgiez
les changes lors de rencontres ou, au pire, au tlphone. Une
manire efcace de diminuer les itrations est dorganiser ces
retours sous forme dateliers de travail en prsence du consul-
tant fonctionnel, si le client est ouvert ce type dexercice.
Pour cadrer les retours, nhsitez pas formuler ce qui vous
semble tre des vidences et expliquer au client exactement ce
quoi sert ce livrable (et ce quoi il ne sert pas). Votre client a le
droit de ne pas tre un professionnel du design web, cest aussi
pour cela quil a besoin de votre professionnalisme. Pour faire
cette ducation de manire performante, nhsitez pas tre
physiquement prsent lors du rendu des premiers prototypes,
plutt que de tenter une explication par courriel.
Rappelez-lui de se concentrer sur le fond et non sur la forme.
Cependant, concernant la forme, noubliez pas de lui rappeler
toutes les tapes qui restent venir pour la mettre en place, ainsi
que tous les autres travaux raliser avant davoir un produit
fni. Vous vous protgerez alors dun double efet ngatif,
qui peut survenir suite la charge de travail qui incombe au
client lorsquil travaille sur les prototypes. Dune part, il peut
LA CONCEPTI ON 83
avoir limpression quil est proche davoir fni son travail, avec
le risque pour vous de le voir moins disponible par la suite.
Dautre part, il peut avoir limpression que le travail qui reste
faire ne reprsente plus grand-chose et donc grogner contre les
phases dintgration et de dveloppement quil pourrait penser
anormalement longues. Ce nest pas une situation systma-
tique, mais ces remarques mergent parfois, alors mieux vaut
les dsamorcer ds maintenant.
Un autre efet possible de cette mprise pourrait mener le client
croire que vous venez dabattre 80% du projet avec 20% des
charges ; plus que jamais, le chef de projet doit jouer le rle
de mdiateur qui arbitre les compromis entre les demandes du
client et le respect des charges.
Enfn, sil est prfrable que le chef de projet soit en commu-
nication frontale avec le client pour excuter cet arbitrage, il
est aussi essentiel, maintenant plus que jamais, quil ne pense
pas son expertise meilleure que celle de son quipe. Cest une
erreur bien souvent commise (surtout lorsquil est face au client
et tent de ne pas reconnatre une faiblesse ou de gagner du
temps), mais si de grands pouvoirs donnent de grandes respon-
sabilits, ils ne donnent pas pour autant une grande expertise!
Avant de ragir aux retours de votre client par des promesses
fonctionnelles qui pourraient savrer trs complexes mettre
en uvre, nhsitez pas temporiser et dclarer avoir besoin
de la validation de votre expert technique. Non seulement vous
vous assurerez de ne pas vous engager sur une piste glissante,
mais aussi le client respectera dautant plus lexpertise de votre
quipe et apprciera sans doute votre respect de cette expertise.
Laccessibilit fonctionnelle des services
et contenus pour toutes les versions
Alors quun nombre grandissant de types de sites adopte le
responsive web design (blogs, puis sites journalistiques, institu-
tionnels, e-commerce), nous voyons scrire progressivement
les bonnes pratiques qui resteront dans le temps, mais aussi
merger de mauvaises pratiques qui, dfaut dune industria-
lisation complte de cette pratique de design, ont aujourdhui
toujours la vie dure.
Lune dentre elles semble tre tolre aujourdhui, sans que
nous ne voyons de bonne raison cela : il sagit de cette
fcheuse habitude de supprimer ou de masquer certains
contenus ou services pour certaines versions dafchage, dans
le but peine cach de gagner de la place pour les versions
les plus troites. Ces fonctionnalits sont sacrifes sur lautel
dun scnario utilisateur assum par le designer sans justifca-
tion : Mon utilisateur est sur un mobile, donc il naura pas
besoin de.... Masquer du contenu ou des services un utilisa-
teur en fonction de son matriel est une violation vidente et
inexcusable de laccessibilit du Web.
Vous tes-vous retrouv dans une situation o, depuis un tl-
phone portable, vous visitiez le site dune compagnie arienne pour
connatre le poids autoris des bagages en soute? Soudainement,
vous vous apercevez que la version mobile de ce site ne propose
que la recherche et lachat de vols, ainsi que quelques autres fonc-
tionnalits rapides destines lutilisateur mobile. Vous recher-
chez alors fbrilement un lien vers le site non mobile et, frustr,
vous trouvez un intrt limit ce site mobile.
Sur un site destin sadapter aux difrentes rsolutions
dcrans, vous ne proposez pas de lien vers le site non mobile
(ce serait techniquement possible, en changeant de viewport
ou en dsactivant des rgles CSS, mais nous navons jamais
rencontr ce cas sur les sites existants). Lutilisateur na donc
aucun moyen daccder linformation que vous avez souhait
lui masquer. Nous considrons que vous navez simplement pas
le droit de la lui masquer!
LA CONCEPTI ON 85
Fig. 6-1 : Le site de Google News, lorsquil est visionn sur un cran large,
prsente des fonctionnalits connexes en colonne de droite.
Fig. 6-2 : Lorsquil est visionn sur un cran plus rduit, la colonne de droite
disparat et ses fonctionnalits avec (elle ne se situe pas plus bas dans la
page, elle est simplement masque). Lutilisateur mobile recherchant ces
fonctionnalits est en droit dtre frustr...
Lapplication de cette rgle est trs difrente entre le responsive
web design et le design adaptatif (adaptive design). Puisque ce
dernier est infuenc par les capacits du navigateur, il est tout
fait tolrable, et mme trs lgant, dimaginer une fonction-
nalit totalement masque si le terminal nest pas capable de
lexcuter (un bouton Me golocaliser sur un terminal incapable
de golocalisation, par exemple). Toutefois, cette rgle est inva-
riablement pertinente dans le cas du design responsive, car
la taille dun cran ne dit absolument rien de sr propos du
contexte dutilisation du visiteur.
Cela dit, si votre gabarit desktop na pas dautre choix que de
contenir un nombre lev de fonctionnalits, trop lev pour
une page mobile utilisable, ne vous culpabilisez pas, il existe
des solutions. Ne surchargez pas votre gabarit mobile pour
autant, votre rticence tait fonde ! Prfrez plutt masquer
cette fonctionnalit avec possibilit de lafcher nouveau en
JavaScript, par exemple ; ou alors, si vous souhaitez pousser
plus loin, vous pouvez toujours dplacer cette fonctionnalit
sur une autre page, potentiellement ddie. Limportant est de
rendre tout contenu ou service accessible pour toutes les rso-
lutions; mais personne na dit quil devait ncessairement tre
accessible de la mme manire...
Accessibilit et responsive web design : un certain conit dintrt ?
Si vous souhaitez dcouvrir davantage de techniques possibles
pour mettre en uvre simplement cette rgle incontournable,
lun des coauteurs de ce livre, Rudy Rigot, en dtaillait certaines
dans un article ddi sur le magazine Le Train de 13h37.
http://xav.cc/resp-acc
9
9. http://letrainde13h37.fr/7/accessibilite-et-responsive-un-certain-confit-d-interet/
LE DESI GN GRAPHI QUE 87
La cration graphique est une phase trs structurante de la
conception du projet. Comme dans tous les projets, cest souvent
la phase o le client est le plus actif avec, dans ce cas prcis,
une complexit supplmentaire grer. En efet, la multiplica-
tion des gabarits dont il faut faire la maquette, lie aux difrents
contextes de navigation, complexife les phases dchange et
de validation avec le client. De plus, la phase de design devient
dautant plus critique quune conception graphique mal mene
aura des consquences importantes sur la faisabilit globale du
projet et donc sur le budget. Oui, vous attaquez lascension de la
face nord du projet!
ORGANISATION ET CHIFFRAGE
Fixer des limites de temps et de budget
Lun des principaux risques est de voir se produire un glisse-
ment, parfois consquent, sur le budget allou la cration
graphique. En efet, cest sur cette partie que le client (ou votre
7
Le design
graphique
responsable produit, sil sagit dun projet interne) exerce
souvent son devoir de validation avec le plus de zle. Sans
compter quon est encore en dbut de projet et quon ne se sent
donc pas ltroit au niveau du budget. Cette terrible combi-
naison peut avoir des efets dltres pour un projet...
Votre rle consiste placer des limites fermes. Autant le dire,
vous aller passer pour le mchant de service, le rabat-joie qui
empche de creuser tous ces petits dtails siiiii importants. Et
mme si le client est prt vous donner une rallonge budgtaire
(oui, cela arrive parfois), ne cdez pas. Un temps de cration
graphique plus long ne sera pas ncessairement le gage dune
russite pour le projet; cela risque mme dtre le contraire. En
efet, il est toujours possible dallonger la phase de design, de
creuser dautres pistes, dexplorer diverses approches cratives
ou ergonomiques. Sans limites fermes, le projet peut sengluer
au point de ne plus tre capable davancer, voire, dans le pire
des cas, de pricliter. Fixer des limites de temps et de budget est
toujours salutaire lors de cette phase du projet. Pour toutes ces
raisons, soyez donc vigilant dans lestimation de votre budget.
Lexprience nous a ainsi montr quun designer ne travaille
jamais mieux que sous une contrainte de dlais claire, sans
quoi le risque est fort quil se perde dans des petits dtails sans
importance (et le client aussi). Attention, cela ne veut pas dire
pour autant quil faut demander limpossible vos designers:
demander la fnalisation complte dun gabarit en partant de
zro en une demi-journe relve de lordre du miracle... Sachez
donc correctement estimer les charges ncessaires.
Pour vous faire une ide, en gnral, la cration dun gabarit
donn prend entre un et deux jours de travail et sa dclinaison
dans une version alternative pour un type de contexte donn
demande une demi-journe supplmentaire. De mme, pour
prendre en compte les difrents retours du client, comptez
l aussi une demi-journe supplmentaire. Cela est bien sr
nuancer en fonction des comptences des designers avec
lesquels vous travaillez, mais oui, la cration graphique cote
cher. Si vous avez un doute, demandez leur avis vos collgues
ou amis designers, recoupez avec dautres projets et ajoutez
systmatiquement une marge de scurit de 20 % de temps
supplmentaire. Cette marge est importante, car si le client est
daccord sur le budget, ce temps donnera un peu de souplesse
cette phase. Et si le client vous demande un geste commercial...
eh bien, vous pourrez toujours lui faire cadeau de ces 20% sans
mettre en danger le projet (mais en revanche, vous serez intrai-
table quand il sagira de tenir le budget).
Dfinir les gabarits utiles finaliser
Le premier point garder en tte, lorsquil sagit de contrler
le budget de cration, est de commencer par bien cerner ce qui
est indispensable de ce qui ne lest pas. Comme nous venons de
le voir, la phase de cration peut tre lune des plus coteuses.
Ainsi, il nest pas du tout ncessaire de fnaliser graphiquement
lintgralit des gabarits qui ont t dfnis pendant la phase de
conception. En efet, de nombreux lments vont se rpter
entre les difrents gabarits ; il est donc inutile de perdre du
temps les refaire encore et encore. Outre le temps perdu, vous
vous exposez deux gros risques.
En montrant plusieurs fois la mme chose un client, celui-
ci peut vouloir revenir sur les lments quil a dj valids ou
bien demander un cas particulier qui na pas ncessairement
lieu dtre autant de revirements particulirement domma-
geables.
remanier plusieurs fois les mmes lments, le risque
dcart minime mais visible entre des lments censs tre
identiques augmente. Cela peut avoir dimportantes cons-
quences sur la phase dintgration: dans le pire des cas, les
intgrateurs perdront du temps faire et dfaire ces petites
difrences ou, au mieux, ils passeront beaucoup de temps
se poser des questions inutiles.
Photoshop pour le design web
Encore trop peu de designers savent utiliser des outils tels
que Photoshop leur plein potentiel. Dans le cadre du design
web, celui-ci dispose de deux outils indispensables : les
objets dynamiques, qui partagent une mme ressource entre
plusieurs fchiers Photoshop, et les compositions de calques,
qui permettent dutiliser un mme calque dimage ou groupe
de calques dans plusieurs confgurations difrentes.
Grer votre budget avec prudence
Une fois que la phase de cration a commenc, vous devez donc
devenir particulirement intraitable. En efet, il nest pas rare
que le client souhaite contrler tous les aspects graphiques du
projet. Soyons clair, au mme titre que vous ne connaissez pas
les arcanes du mtier de votre client, celui-ci na pas de comp-
tences graphiques particulires. En consquence, cest vous quil
incombe de donner le rythme de cette tape de cration. Le prin-
cipal danger est de voir se multiplier les allers-retours en direct
entre lquipe charge du design et le client. Si vous constatez
que le client fait plus de deux allers-retours sur un gabarit, cest
la responsabilit du chef de projet dy mettre le hol et de sinter-
poser fermement entre les quipes de design et le client.
Entre autres mthodes, il y a trois points qui sont salutaires
mettre en place.
Quitte faire le passe-plat si tout se passe bien, le chef de
projet doit toujours tre le principal interlocuteur du client.
Cette position nest pas l pour remettre en question la com-
ptence des quipes de design, mais pour lutter contre les
allers-retours sur des dtails parfois totalement insignifants.
Exigez toujours une validation crite des gabarits. Cela peut
aller dun simple courriel un vritable PV de validation for-
mel, selon votre niveau dexigence ou celui du client. Cela vous
aidera responsabiliser les clients qui ne peuvent sempcher
de toujours remettre en cause les choix qui ont t faits.
Nhsitez pas organiser des runions formelles de valida-
tion (incluant un ordre du jour et en temps limit) avec le
client et, ventuellement, le ou les responsables de la cration
graphique. Dans les cas les plus extrmes, vous pouvez aller
jusqu mettre en place une war room.
War room
Une war room est une forme de runion o tous les interve-
nants sont littralement enferms jusqu ce quils aient pris
une dcision ferme et dfnitive sur une question donne.
Il sagit ici dun vocabulaire emprunt aux organisations mili-
taires, qui ont des salles ddies la gestion de crise (en
franais, on parle de salle des oprations ). Ce terme est
souvent utilis en gestion de projet pour signaler une runion
ayant pour objet de rsoudre une crise, trs souvent lie des
problmatiques de validation ou de budget.
http://fr.wikipedia.org/wiki/Salle_doprations
La plus grosse difcult de la phase de cration rside dans
les incertitudes du client lui-mme, quil sagisse dhsitations
personnelles ou de contraintes professionnelles qui lui sont
propres. Cela est dautant plus prononc quil faut une certaine
exprience pour bien anticiper et comprendre la faon dont va
saltrer un design en fonction de conditions de consultation
parfois totalement imprvisibles. Sur ce dernier point, vous
devrez, encore une fois, faire preuve dun grand sens de la
pdagogie, de beaucoup de patience et, encore une fois, dune
fermet imparable pour viter les remises en question.
LES LIVRABLES GRAPHIQUES
Les livrables graphiques sont de trois types possibles: la charte
graphique web, le catalogue des composants types et les fchiers
graphiques sources. Chacun a une fonction et une importance
particulire. Tous sont optionnels, en fonction des contraintes
de votre projet.
La charte graphique web
Il sagit typiquement du livrable que doit produire un direc-
teur artistique. Comme toute charte graphique, ce document
contient lensemble des rgles fondamentales dutilisation
des lments graphiques qui constituent lidentit visuelle du
projet, mais en incluant quelques spcifcits lies au Web et,
dans notre cas, au design responsive.
Ainsi, en plus de toute la dfnition des difrents signes
graphiques utiliser et de lusage en faire, elle doit imprati-
vement comporter les lments suivants.
Toutes les couleurs utiliser doivent tre dfnies dans un
rfrentiel RVB (Rouge, Vert, Bleu), idalement sous forme
dune chane hexadcimale. Si des couleurs doivent tre utili-
ses avec une transparence, il faudra alors prciser les valeurs
RVB sous trois formes (comme sur la fig.7-1):
1. les valeurs RVB dorigine de la couleur plus sa valeur de
transparence;
2. les valeur RVB de la couleur sans transparence, comme
si elle tait applique sur un fond clair (blanc ou bien en
fonction de la charte graphique);
3. les valeurs RVB de la couleur sans transparence, comme
si elle tait applique sur un fond fonc (noir ou bien en
fonction de la charte graphique).
La description prcise de la ou des grilles typographiques
appliquer inclut:
1. les tailles minimale et maximale du texte courant;
2. la hauteur de ligne utiliser en fonction de la taille du
texte courant;
3. la largeur des colonnes et gouttires;
4. les nombres maximal et minimal de colonnes utiliser
en fonction du contexte;
5. si plusieurs grilles peuvent tre imbriques, les rgles
prcises permettant de raliser cela.
Si la charte graphique dfnit des symboles, logos ou formes
types utilisables, chacun de ces lments doit tre fourni de
manire individuelle dans un format vectoriel, idalement du
SVG (Scalable Vector Graphics).
Il va videment de soi que toutes les tailles doivent tre expri-
mes dans des dimensions exploitables dans un environne-
ment web, comme le pixel ou des ratios de proportion, mais
jamais en centimtres ou en millimtres, qui sont des notions
extrmement foues dans lunivers du numrique.
Fig. 7-1 : Exemple dune mme couleur, respectivement de gauche droite:
#5493CD avec 50% de transparence;
#A9C9E6 sur fond blanc sans transparence;
#2A4A67 sur fond noir sans transparence.
Le catalogue des composants types
Il sagit sans doute du document graphique le plus important
pour nous. Il recense lintgralit des composants individuels
qui vont tre utiliss sur le site: liens, boutons, onglets, titres,
listes, accordons, etc.
Quel que soit le composant graphique utilis, il sera reprsent
dans tous ses tats possibles (survol, actif, cliqu, touch, etc.)
et dans toutes ses variations selon le contexte dutilisation.
Lobjectif est quun intgrateur puisse prendre ce document et
reconstruire tous ces lments en HTML/CSS, de manire ce
quils soient rutilisables pour monter les difrents gabarits
trs rapidement... y compris ceux qui auraient pu tre oublis.
Fig. 7-1 : Planche des composants de linterface de FirefoxOS
Source: http://xav.cc/fos
10
Les fichiers sources
Finalement, les fchiers sources graphiques seront la principale
ressource utilise par les intgrateurs. Pour cette raison, les
designers doivent prendre particulirement soin de les struc-
turer de manire ce quils soient facilement exploitables. Pour
cela, il y a quelques bonnes pratiques suivre.
10. https://blog.mozilla.org/ux/2012/09/mozcamp-warsaw-design-principles-
behind-frefox-os-ux/
Ces fchiers doivent tre traits en basse dfnition (72pixels
par pouce), en RVB (avec le profl sRVB utilis par tous les
crans du march) et avec des mesures en pixels.
Tous les calques dimages et groupes de calques doivent tre
nomms de manire explicite.
Le seul mode de fusion utilisable sous Photoshop est le mode
Normal. En efet, aucun autre mode de fusion nest actuelle-
ment ralisable avec des technologies web (cela va changer
dans les annes venir avec larrive du module CSS Compo-
siting and Blending propos par Adobe).
Bonnes pratiques : les chiers sources
Pour un exemple plus complet de bonnes pratiques associes
la prparation des fchiers sources, nous vous invitons lire
cet article du blog de Christophe Andrieu: http://xav.cc/psd
11
Le cas des polices typographiques ncessite galement un peu
dattention. En efet, limplmentation massive de la fonction-
nalit @font-face de CSS dans les navigateurs a ouvert un
tout nouvel horizon lusage de la typographie sur le Web.
Cependant, si la mise en uvre en est assez facile, il est indis-
pensable de vrifer les points suivants.
Vrifez toujours la licence dusage des fontes choisies. En
efet, de nombreuses fontes livres avec des produits comme
Photoshop ne sont pas autorises pour une exploitation sur
le Web. Il est de votre responsabilit de vous renseigner sur
les cots des licences pour cet usage particulier et de vous
assurer que votre client est daccord pour acquitter ces droits.
Sil refuse, vous devez exiger une dcharge sil insiste pour
que vous utilisiez cette fonte malgr tout. En efet, un tel
usage serait alors illgal.
Les fonderies, lorsque vous vous acquittez des droits de li-
cence, vous donnent gnralement accs des fchiers sp-
cialement optimiss pour le Web. Cependant, mme dans ces
11. http://www.stpo.fr/blog/guidelines-pour-produire-des-psd-adaptes-au-web
conditions, il est toujours possible de rencontrer des difcul-
ts. Cela sera dautant plus vrai que vous faites le choix de
polices typographiques gratuites. Ainsi, vous ne pouvez pas
vous dispenser de tester ces fchiers de polices avant de les
dployer sur le site de votre client. Cela vous vitera de nom-
breuses (mauvaises) surprises.
Web Font Specimen
Pour tester vos polices typographiques, vous pouvez utiliser le
spcimen qua conu Tim Brown et qui a t traduit en Franais
par Vincent Valentin: http://wfs.typographisme.net
L I NTGRATI ON 97
La phase dintgration est une des plus documentes ce jour,
car elle est souvent au cur des projets responsive. En particu-
lier, le livre Responsive Web Design dEthan Marcotte reste la rf-
rence en la matire. Cest pourquoi nous nallons pas entrer dans
le dtail des subtilits lies lintgration, mais nous concen-
trer sur les points qui auront une incidence particulire sur la
gestion de projet en elle-mme. Cela couvre essentiellement
deux domaines: la gestion des images et la stratgie de tests de
lintgration.
Les fondements de lintgration dun site responsive reposent
sur un certain nombre de points, dont la gestion technique des
grilles de mise en page, ou encore la matrise des requtes de
mdia CSS. Il sagit l de prrequis que devront matriser vos
intgrateurs. Lutilisation de prprocesseurs CSS tels que LESS
ou Sass sera galement dune grande aide pour augmenter lef-
cacit et la productivit des quipes.
8
Lintgration
Responsive web design et intgration
Si vous souhaitez creuser ces questions, nous vous invitons
lire ces deux ouvrages:
Ethan Marcotte, Responsive Web Design, A Book Apart,
Eyrolles, 2011
Corinne Schillinger, Intgration web : les bonnes pratiques,
Eyrolles, 2012
LA GESTION DES IMAGES
De toutes les difcults lies lintgration, la gestion des
images reste la plus aigu. En efet, cest sur cette question que
les limites et contraintes techniques sont les plus fortes.
Un pixel nest pas un pixel
Une des plus grosses difcults dans la gestion des images vient
de la notion de pixel. Cette notion, que lon a crue longtemps
immuable, est pourtant en train de changer, parfois de manire
trs surprenante.
En 2007, liPhone a fait son apparition. Ce nouvel appareil a
bouscul lunivers du mobile avec un changement majeur : il
permet daccder au Web dans des conditions proches de ce
que lon trouve sur les ordinateurs de bureau. Pour raliser ce
tour de force, la grande ide dApple a t damener la notion de
viewport sur le Web. Safari mobile a un comportement assez
surprenant. Sur un appareil qui fait 320pixels de large, il afche
un site web comme si la fentre du navigateur mesurait en
ralit 1024pixels. Ainsi, par un habile jeu de transformation
mathmatique, un site qui navait jamais t pens pour mobile
safche peu prs proprement sur un cran minuscule.
L I NTGRATI ON 99
Avec cette astuce, nous nous retrouvons tout dun coup avec
deux sortes de pixels:
les pixels physiques, qui dfnissent la rsolution de lcran;
les pixels CSS, qui sont utiliss par les dveloppeurs web pour
mesurer les dimensions des lments dans la page afche.
En 2010, Apple a rcidiv en sortant liPhone4 et son fameux
cran retina . Ce fut une grosse surprise, car lcran de
liPhone4 fait 640960pixels, mais sur une taille dcran qui
na pas chang (toujours 3,5pouces de diagonale). Si la densit
de pixels physiques a augment, le nombre de pixels quuti-
lise le systme iOS pour mesurer les dimensions et afcher
les lments lcran na pas chang, lui, et est toujours de
320480pixels.
Retina display
Ce terme, cr loccasion de la sortie de liPhone4, dsigne
les priphriques dont lcran a une rsolution particulire-
ment leve. Le terme est souvent vivement critiqu, car il a
t choisi par Apple pour signifer une prcision suprieure
celle de lil humain (qui nest alors plus cens dceler de
pixellisation), alors que lacuit visuelle perue est galement
dpendante de la distance entre lcran et lutilisateur. Le troll
atteint son niveau ultime lorsque les dtracteurs font remar-
quer que lcran retina de liPad ( partir de liPad2) nest tech-
niquement pas retina si on le tient comme il est tenu par
Steve Jobs dans la fameuse keynote de prsentation de liPad
(assis sur un canap).
En ce qui concerne le Web, on dtecte souvent les crans
retina avec la CSS media query propritaire -webkit-min-
device-pixel-ratio. Toutefois, il est aussi possible dutiliser,
pour englober les autres priphriques haute rsolution, la
media query min-resolution (dont Apple na pas le monopole
du tout, contrairement une croyance populaire!)
Bien videmment, la bonne pratique consiste raliser une
intgration compatible retina qui ne se limite pas aux pri-
phriques dApple.
Ainsi, avec ces nouveaux crans haute densit, nous nous
retrouvons encore avec deux notions de pixel difrentes. Dun
ct, nous avons toujours les pixels physiques, qui reprsentent
vritablement les petits points de lumire afchs par lcran,
et de lautre, nous voyons apparatre la notion de pixel afch
(ou pixel OS), qui reprsente lunit de rfrence du systme
dexploitation pour calculer la taille des lments afcher sur
lcran.
Cela a une consquence importante en gestion de projet. En
efet, il va falloir prcisment identifer de quelle sorte de pixel
on parle chaque fois quon y fait rfrence, pour viter les
confusions et les sources derreurs.
Le pixel CSS
Cest de lui quil est question quand on parle de pixel dans le
cadre dun dveloppement web. Dans de trs, trs nombreux
cas, la taille du pixel CSS correspond la taille du pixel OS.
Nanmoins, il faut se mfer car ce nest pas toujours vrai. En
efet, un dveloppeur web, surtout dans le cadre dun projet
responsive, peut dcider de changer la taille du pixel CSS. Pour
cela, il y a deux mthodes possibles:
la balise meta viewport, pour linstant uniquement dispo-
nible sur les navigateurs mobiles (mais rien ne dit quelle ne
fera pas son apparition un jour sur les navigateurs de bureau);
la proprit CSS transform, qui, avec la fonction scale,
permet de changer la taille dun lment et donc la taille des
pixels CSS lintrieur de cet lment.
L I NTGRATI ON 101
Le pixelOS
Trs souvent, lorsquon voque la rsolution dun cran (mon
cran a une rsolution de 19001200pixels), on parle en fait
du nombre de pixels utiliss par le systme dexploitation pour
dfnir la taille de lcran, et donc pour calculer lafchage des
lments. Cest particulirement vrai des crans mobiles, avec
toutefois lexception des crans notoirement retina, comme les
iPhone ou les iPad, dont il nest pas exceptionnel de donner la
rsolution en pixels physiques; soyez donc vigilant.
Le pixel physique
Alors l, il y a un pige. Quand on parle de la taille dune image
dans un logiciel de traitement dimages, en fait, il sagit toujours
de pixels physiques. Cest lune des plus grosses sources de
confusion qui soit chez les dveloppeurs et designers web.
La confusion vient du fait que, trs souvent, on dfnit la taille
dafchage dune image via une feuille de styles ou via des attri-
buts HTML. ce moment-l, lunit quon utilise, lepx, repr-
sente bien sr le pixel CSS. Ensuite, on va passer sur son logiciel
de traitement dimages pour prparer son fchier et l, lapplica-
tion demande quelle est, en pixels, la taille donner limage,
sans prciser quil sagit de pixels physiques. Le problme est
que, pendant des annes et des annes, la taille du pixel CSS
correspondait celle du pixel physique. Malheureusement,
aujourdhui, ce nest plus le cas, do les confusions frquentes.
Il est trs important que ces notions soient assimiles aussi bien
au niveau des intgrateurs qu celui des designers qui produi-
ront les fchiers sources, car devoir refaire tout ou partie de ces
fchiers sources cause dun oubli de cette nature peut coter
cher un projet.
Proposer des images adaptes aux capacits
de l cran
Avec ces histoires dcran retina et de pixels, il est souvent tentant
de produire des images en haute dfnition et de les servir tous
les matriels possibles. Le problme, cest quune telle stratgie
simpliste aura des consquences parfois importantes sur les perfor-
mances de votre site. Cela va afecter deux points en particulier.
Le temps ncessaire pour charger les images : plus une
image est lourde, plus elle est longue charger, ce qui est
particulirement visible sur des rseaux de mauvaise qualit
comme les rseaux mobiles (3G ou EDGE).
Le temps ncessaire pour afcher ces images : on sous-
estime souvent le temps ncessaire un navigateur pour redi-
mensionner une image. Ce nest pas anodin et, l aussi, on le
constatera dautant plus facilement sur les appareils mobiles,
qui nont souvent pas les mmes capacits graphiques quun
ordinateur de bureau.
Certes, lusage des requtes de mdia CSS permet de servir
des images dcoratives adaptes aux capacits du matriel en
vous basant sur vos points de rupture. Cependant, mme si
cette technique limite les principaux cueils, elle est loin dtre
parfaite. En particulier, il y a deux points problmatiques quil
faut surveiller de prs.
Les media queries ne connaissent pas la qualit du rseau:
par cette seule technique, il est impossible de savoir si luti-
lisateur utilise une connexion de bonne qualit (ADSL ou
FTTH) ou de mauvaise qualit (3G ou EDGE). Par ailleurs, la
taille de lcran ne vous donne aucun indice sur la question,
puisquun smartphone peut accder au WiFi et un ordinateur
portable utiliser une cl3G.
Les media queries sont confnes CSS et JavaScript et ne
permettent donc pas dinfuer sur la source des images in-
cluses dans le code HTML laide de balises comme <img>
ou <object>.
L I NTGRATI ON 103
Optimiser les images ct serveur
Lune des solutions ces deux problmes consiste mettre
en place un dialogue entre le navigateur et le serveur.
Concrtement, dans le navigateur, vous utiliserez JavaScript
pour essayer de mesurer la qualit de la connexion et la taille
de la fentre du navigateur. Il est alors possible de passer ces
informations au serveur pour quil construise, la demande, les
images les mieux adaptes au contexte de lutilisateur.
Il existe de nombreuses techniques pour raliser ce genre de
dialogue navigateur/serveur. La plus connue dentre elles est
sans doute celle du site http://adaptive-images.com.
La valse des solutions
On ne compte plus les solutions pour grer cette problma-
tique dimages responsive. Lune des dernires en date consiste
produire des images de trs grande taille, mais galement trs
compresses, qui seront redimensionnes par le navigateur
afn de ne pas voir les dfauts de la compression.
http://xav.cc/48443
12
Nanmoins, avant de vous jeter sur telle ou telle technique,
prenez le temps de bien analyser vos contraintes et de vous
assurer que ces techniques ne sont pas bloquantes si, pour une
raison ou une autre, elles ne sexcutent pas correctement. En
efet, elles non plus ne sont pas parfaites:
elles ncessitent des dveloppements supplmentaires et
doivent donc tre prvues dans votre chifrage initial;
elles ne sont pas totalement fables, du fait de lutilisation de
JavaScript, et ne peuvent se substituer totalement un usage
des requtes de mdia.
12. http://flamentgroup.com/lab/rwd_img_compression
Le problme JavaScript
JavaScript nest pas totalement fable et il est bon de sen
souvenir dans le cadre dun dveloppement responsive.
En efet, les cas de non-excution de JavaScript sont plus
nombreux quon ne le croit:
il peut ne pas se charger correctement (totalement ou
partiellement);
il peut entrer en confit avec un autre script;
il peut entrer en confit avec une extension du navigateur;
et, accessoirement, lutilisateur peut le dsactiver
volontairement.
Pour toutes ces raisons, il est indispensable, dune part, de
ne pas oublier les alternatives en cas de problme dexcu-
tion de JavaScript et, dautre part, de sassurer que les autres
technologies comme CSS ou HTML ne dpendent pas inti-
mement de son excution.
DFINIR UNE STRATGIE DE TESTS
Une fois que vous aurez rsolu la question des images, vous
devrez vite faire face la question des tests des navigateurs. Il
ne sagit pas l de dfnir une stratgie de tests fonctionnels ou
techniques. Il sagit juste de sassurer que les intgrateurs auront
de quoi faire les tests sufsants pour garantir que ce quils vont
livrer fonctionne dans les navigateurs cibles attendus.
Les navigateurs de bureau
Sil est dj particulirement difcile de tester un site responsive
lors des phases de recette prvues cet efet, des tests interm-
diaires pour garantir la qualit du projet ncessitent parfois de
faire des choix difrents de ce qui est attendu sur les plates-
formes cibles.
L I NTGRATI ON 105
A minima, tester les principaux navigateurs pour les ordi-
nateurs de bureau dans leur dernire version est essentiel.
Firefox, Chrome et Opera sont multi-plates-formes ; il ny a
donc pas de problme particulier pour faire des tests avec eux.
La plus grosse difcult sera sans doute Internet Explorer. En
efet, ce navigateur est totalement li au systme Windows
de Microsoft. Pour cette raison, la seule faon fable de le
tester sera de monter des machines virtuelles faisant tourner
difrentes versions de Windows avec difrentes versions
dInternet Explorer. Safari sous Mac OS prsente le mme
genre de difcults, avec une subtilit en plus: la licence duti-
lisation du systme MacOS nautorise pas la virtualisation sur
dautres machines que des Mac. Nous reviendrons sur la virtua-
lisation dans le chapitre11, lorsque vous devrez mettre en place
les outils ncessaires la recette sur le poste du product owner.
Tester Internet Explorer
Microsoft a bien compris cette difcult et il est important de
souligner leur initiative http://www.modern.ie, qui fournit aux
dveloppeurs web tous les outils et conseils ncessaires pour
tester les difrentes versions dInternet Explorer, que ce soit
en ofrant des accs au service http://www.browserstack.com,
en fournissant gratuitement des machines virtuelles dj conf-
gures ou en proposant des systmes de validation de code.
Les navigateurs mobiles
Les navigateurs mobiles reprsentent souvent un problme plus
pineux. En efet, si vous ne disposez pas des matriels corres-
pondants, il est encore assez difcile de raliser des tests sur ce
type de navigateurs. Firefox Mobile et Opera Mobile restent les
plus faciles tester. En efet, ces deux navigateurs utilisent des
moteurs de rendu sensiblement quivalents leur version pour
ordinateur de bureau; il est donc possible de passer par ce biais
pour les principaux tests dafchage. L o cela se corse, cest
dans le cas des navigateurs natifs pour Android et iOS (sans
parler dautres encore plus marginaux, comme les navigateurs
des appareils BlackBerry). Il est toujours possible dutiliser les
mulateurs fournis avec les SDK (Software Development Kits)
ofciels. Cependant, leur installation est difcile et leur fabi-
lit, toute relative. Nous reviendrons aussi de manire avance
sur ces notions au cours du chapitre11.
ce jour, en dehors dun investissement massif dans du
matriel, la meilleure faon de tester ces navigateurs reste le
site http://www.browserstack.com, qui propose un ensemble
denvironnements de virtualisation accessibles distance la
demande.
DOCUMENTER LE PROJET
Maintenant que lon a commenc le travail de dveloppement, il
nous semble essentiel de rappeler un point crucial de la gestion
de projet: limportance de la documentation.
On ne dira jamais assez quel point la documentation dun
projet est essentielle. Que ce soit en cas derreur, de reprise
du projet ou de gestion de la maintenance, la documentation
sera toujours dun grand secours pour tous les intervenants
du projet. La difcult de la documentation, cest que tout le
monde trouve cela pnible crire, alors que tout le monde est
extrmement content de la trouver quand cest ncessaire.
Les projets responsive ne font pas exception. La difrence est
que le besoin de documentation technique survient ds la phase
dintgration. En efet, la dlicatesse et la complexit du travail
dintgration pour ce type de projets requirent que les choix
techniques soient clairement documents, afn que tout nouvel
intervenant puisse reprendre le travail avec une perte de temps
minimale. Dans cette optique, lutilisation de frameworks est
une approche qui a fait ses preuves. En apportant outillage et
mthodologies, ils rduisent les problmes de dveloppement
L I NTGRATI ON 107
et dintgration rcurrents, ofrant aux intgrateurs et dve-
loppeurs lopportunit de se concentrer sur la rsolution des
problmes originaux du projet.
En particulier, documenter lintgration de la planche de
composants dont nous avons parl au chapitre6 est un lment
souvent structurant.
Cette documentation peut prendre difrentes formes : page
wiki, fchier au format Markdown, commentaires dans les
fchiers sources HTML/CSS/JavaScript. Limportant est de vous
assurer que cet efort de documentation sintgre vos processus
de la manire la plus harmonieuse possible. Par exemple, si
vous travaillez avec GitHub, ldition dun fchier Markdown
peut faire partie des livrables exigs lors des commits; si vous
travaillez avec Trac, Redmine ou autre, demander un lien vers
une page du wiki correspondant la documentation peut tre
exig pour fermer un ticket. Limportant, encore une fois, est
de rendre tout cela fuide et partie intgrante de vos processus.
LE DVELOPPEMENT BACK- END 109
Puisque le responsive web design se vit ct client, maintenant
que vous avez en main vos maquettes intgres, vous croisez
sans doute les doigts pour que toutes les difcults du projet
soient passes: Avec un peu de chance, le reste de laventure
devrait se drouler sans encombre...
Surtout, ne relchez pas votre vigilance, car si vous avez, en efet,
surmont les preuves les plus difciles (conception et intgra-
tion), plusieurs dfs restent devant vous, parmi lesquels le dve-
loppement ct serveur.
Quelles que soient les mthodologies que vous avez lhabitude
demployer dans vos projets, une partie du travail front-end
sera ncessairement ralise par votre intgrateur (idalement,
toutes les CSS, fournies avec des exemples de fchiers HTML,
et les parties du JavaScript qui relvent du design dinteraction)
et une autre par les dveloppeurs back-end (notamment les
parties du JavaScript qui relvent des communications en Ajax
avec le serveur ou reposent sur des services tiers).
9
Le
dveloppement
back-end
La manire de grer chacune de ces parties va tre trs difrente,
encore plus que lors dun projet classique. Les acteurs du projet
devront donc mettre un point dhonneur tracer une ligne franche
entre ce qui est dans le primtre intgr et ce qui ny est pas.
GRER LES RISQUES L INTRIEUR
DU PRIMTRE INTGR
Pour tout projet web humainement constitu, quand bien mme
vous aurez efectu une conception parfaite et des maquettes
idalement intgres, les dveloppeurs back-end, mme en y
mettant la meilleure des volonts, endommageront ncessaire-
ment la qualit front-end du projet. Dans la gestion de la qualit,
tout le jeu consiste limiter ces altrations au maximum.
Back-end, front-end cest la guerre !
Cette perte de qualit provient de plusieurs sources, tenant pour
beaucoup au rle dexpertise de lintgrateur: il est le garant des
aspects techniques de laccessibilit du site, le fer de lance de la
performance et il doit peaufner une smantique assurant une
comprhension optimale par les moteurs de recherche le tout
en produisant un code compatible avec tous les terminaux et
navigateurs de la cible, et avec un maximum de terminaux et
navigateurs hors cible, intelligemment choisis. Voil beaucoup
de responsabilits pour deux frles paules!
Vous comprendrez que lquilibre entre ces caractristiques
est fragile. Dans les faits, le dveloppeur ne testera pas autant
les aspects front-end que lintgrateur : il efectuera les tests
sans doute sur un nombre moins important de plates-formes,
oubliera quelquefois de dsactiver son JavaScript avant de livrer
un dveloppement, etc. Ces oublis, qui sont habituellement
dj dangereux, deviennent autrement plus risqus lorsque la
cible tester slargit lchelle dun projet responsive.
En bref, sur un site utilisant le responsive web design, les ralisa-
tions HTML/CSS/JavaScript sont encore plus intimement couples
pour fonctionner de manire cohrente travers les difrents
terminaux. Le risque quun dveloppeur back-end dgrade invo-
lontairement un design sur un terminal est dautant plus fort.
Pas de panique, vous trouverez vos solutions en appliquant vos
bonnes vieilles recettes de qualit habituelles, mais avec une
surcouche ncessaire de vigilance et de rigueur.
Chacun son domaine !
Nous vous le conseillions dans le chapitre 3 et nous vous le
rptons ici: dans un domaine aussi vari que les sciences du
Web, vous gagnerez mettre en place une saine sparation
humaine des expertises. Cette vrit est dautant plus pertinente
lorsquon souhaite sparer les expertises back-end et front-
end, les consultants spcialistes des deux simultanment tant
extrmement rares. Votre quipe vous remerciera : lusage,
il savre que les participants au projet sont souvent soulags
de pouvoir se concentrer sur leur expertise, au lieu de devoir
dborder maladroitement sur celle des autres.
Aussi, nhsitez pas dcharger lquipe back-end de soucis qui
ne sont pas les siens, en faisant systmatiquement raliser toute
tche lie au front-end par lintgrateur, mme sil sagit dun
besoin mergent aprs la phase dintgration. Votre qualit web
vous en sera reconnaissante...
Tests : qui fait quoi ?
Nous lavons vu, les dveloppeurs back-end ont une tendance
bien excusable ne pas tester leurs ralisations sur autant de
terminaux que les intgrateurs ; bien excusable, car dans le
cadre de la sparation des expertises, le dveloppeur back-end
doit dj sinquiter de son modle de donnes, de sa stratgie
de cache et de ses implmentations de services en tout genre.
Toutefois, cette phase de recette interne ne peut tomber aux
oubliettes aprs le dveloppement back-end et nous avons dj
discut des risques daltration du front-end : pas le choix, il
faudra la prvoir!
Tout dabord, il vaut mieux accepter cette insufsance de tests
lors du dveloppement back-end en le cadrant et en dfnis-
sant clairement avec lquipe quelles confgurations prcises le
dveloppeur est suppos tester. Lobjectif consiste couvrir un
maximum de cas en un minimum de tests: un projet ciblant par
exemple Internet Explorer partir de la version6, mais aussi
un ensemble de 3 navigateurs natifs de smartphones nomm-
ment identifs, de 2 navigateurs natifs de tablettes nommment
identifes, ainsi que les dernires versions desktop de Firefox,
Chrome et Opera pourra exiger une recette back-end syst-
matique dun navigateur moderne, au choix du dveloppeur,
avec une fentre retaille 1 000, 500 et 300 pixels de large,
ainsi que IE6 , en esprant limiter dj une grande majorit
des dgts.
Fig.9-1 : La mal nomme Vue adaptative de Firefox permet au dveloppeur
de tester facilement une page web selon des tailles dcrans prenregistres. Ici,
il peut simuler rapidement le mode paysage sur une tablette...
Fig.9-2 : puis passer en mode portrait en un clic sur le bouton Rotation...
Fig.9-3 : et enfn consulter le site comme sil tait en mode portrait
sur un smartphone.
Une fois les dveloppements raliss (parmi lesquels le front-
end a t test moiti par le dveloppeur), il faut imprative-
ment que quelquun procde une recette totale, sur tous les
terminaux cibles, avant lenvoi en recette client. Bien entendu,
cette tape peut tout fait tre utile dans le cadre dun projet
classique, mais dans une trs large majorit des cas, elle nest
pas du tout vendue et encore moins ralise ; lintgrateur et
le designer ont parfois tout juste loccasion de faire quelques
retours juste avant la mise en production (ou mme parfois,
juste aprs !) Ici, la cible de navigateurs est trop large pour
prendre ce risque, nous naurons pas le choix : il faudra lin-
clure dans le budget, ce qui gonfera lgrement les charges du
back-end.
Il peut tre trs pertinent que cette recette technique soit ralise
par le chef de projet, qui connat mieux que personne le compor-
tement attendu de lapplication ; nanmoins, lopration tant
relativement fastidieuse, elle savre trs coteuse en temps et
le temps du chef de projet est souvent trs coteux en argent!
Un bon compromis pour matriser ses charges de gestion de
projet serait dimaginer un intervenant dont lunique rle serait
de tester sur tous les terminaux cibles. Aprs tout, chez Google,
Test Engineer est un poste part entire et tout fait respectable!
Enfn, il sera toujours constructif de prvoir, en fn de projet
(peut-tre mme aprs la recette client), une intervention fnale
de lintgrateur, dans le but de remonter les dtails peaufner
pour matriser au mieux la perte de qualit front-end lors du
dveloppement back-end. Lidal et le plus pratique est alors
de faire dune pierre deux coups, en faisant raliser lintgra-
teur la recette technique sur toutes les plates-formes juste aprs
les livraisons des dveloppeurs. Aprs tout, qui mieux que lui
connat les piges techniques viter?
Le Test-Driven Development
Une approche extrme, mais efcace, pour sassurer de la
qualit de lapplication et de ses tests unitaires (code auto-
matisant la vrifcation que lapplication fonctionne bien
comme prvu) est le Test-Driven Development (TDD).
Cette approche exige que le dveloppeur travaille en itra-
tions courtes, contenant toujours ces trois tapes:
1. Avant de raliser une fonctionnalit, le dveloppeur code
un test, qui choue initialement (par exemple, un code qui
automatise la cration dun compte par un utilisateur et
vrife ensuite que le compte utilisateur est bien cr).
2. Puis le dveloppeur ralise la fonctionnalit avec un
minimum de temps et de code, afn que le test initialement
dvelopp nchoue plus.
3. Enfn, il reprend ce code et lamliore pour sassurer de lui
faire respecter toutes les bonnes pratiques avant de le livrer.
Cette approche est trs pertinente pour des ralisations
back-end, mais difcilement applicable nos problma-
tiques responsive: les tests unitaires sur le front-end repr-
sentent un domaine mal matris et nous pourrions baser
cette approche sur des tests fonctionnels, mais ils sont plus
difciles crire avant que la fonctionnalit ne soit ralise.
GRER LES RISQUES L EXTRIEUR
DU PRIMTRE INTGR
Mme si votre dveloppeur se sent en scurit par son appui sur
les comptences de lintgrateur, il existera toujours une partie
du front-end qui ne pourra tre ralise que par le dveloppeur.
La solution ne se trouve alors plus dans les processus de gestion
de projet, mais dans les astuces et facties techniques.
Votre meilleure ennemie : la publicit
La question de la publicit est bien entendu purement dpen-
dante de votre modle conomique. Si votre site en a besoin
pour tre viable fnancirement, alors vous naurez pas dautre
choix: dune manire ou dune autre, il vous faudra afcher des
annonces publicitaires.
La rgie de publicit est un mtier trs particulier: il consiste
notamment trouver des annonceurs, matriser la quantit
dafchages dune publicit en fonction de ce que lannonceur
a pay, calculer le retour sur investissement procur par le
clic dun utilisateur, etc. Il est souvent trs difcile de raliser
ces tches en interne; on prfre alors passer par une structure
ddie, qui aura lexpertise sufsante pour soccuper de tous les
dtails.
Or, les rgies de publicit en ligne que lon trouve actuellement
sur le march ne se sont absolument pas adaptes au responsive
web design et se fent des contraintes techniques qui lui sont
totalement incompatibles. Comment garantir contractuelle-
ment la bonne visibilit dune image que lon naura pas dautre
choix que de rtrcir? Comment sen sortir avec les formules
de calcul de la valeur dun clic qui prennent en paramtre le
niveau dapparition de la publicit dans la page, alors que vous
ne pourrez jamais mettre la publicit au mme niveau dans la
page dune version lautre ? Et ne mentionnons mme pas
les publicits base de pop-ins, dobjets fottants sur la page ou
autres interactions prvues uniquement pour le desktop! Voil
le vritable problme de fond.
lire : Responsive Advertising
Si la langue de Shakespeare ne vous fait pas peur, ce billet de
Mark Boulton rsume trs clairement et trs simplement la
problmatique de la publicit en ligne pour les sites conus en
responsive web design: http://xav.cc/advert
13
la suite de la ralisation du site du journal amricain Boston
Globe, ses crateurs ont largement partag leurs difcults
discuter des problmatiques dadaptation avec des rgies publi-
citaires peu comprhensives. La solution quils ont trouve est
un contournement du problme : ils ont mathmatiquement
13. http://www.markboulton.co.uk/journal/comments/responsive-advertising
adapt la grille pour quelle soit partiellement fxe (dans les
colonnes contenant des publicits) et partiellement fuide (le
reste des colonnes).
Sagissant dun problme culturel, rien ne soppose ce quun
jour (et le plus tt possible !), une rgie de publicit en ligne
aux solutions techniques compatibles avec le responsive web
design voie le jour pour mettre tout le monde daccord. Nous
pourrons alors connatre le soulagement de mettre tous ces
piges et contournements au pass...
Les autres cas d intgration de services tiers
Il existe deux manires dintgrer un service tiers: via le front-
end (insertion dune balise <iframe>, intgration dun fchier
JavaScript, etc.) ou via le back-end (interrogation de Web
Services, etc.). Bien que souvent beaucoup plus simple raliser
techniquement, lintgration par le front-end est aussi la plus
dangereuse pour la qualit: dans le meilleur des cas, on aura un
alourdissement des performances et, dans le pire, des erreurs
JavaScript empchant la bonne excution du script dans le reste
de la page ou des fchiers bloquant le tlchargement du reste
des ressources, donnant limpression dune page indisponible.
Scripts tiers et appels induits : ne perdez pas le contrle de votre site !
Pour un rquisitoire plus dtaill de lintgration de services
tiers par le front-end, cet article de Boris Schapira apporte son
lot de retours dexprience enrichissants et dtaills:
http://xav.cc/scripts-tiers
14
14. http://letrainde13h37.fr/6/scripts-tiers-appels-induits-ne-perdez-pas-le-controle-
de-votre-site/
videmment, la solution la plus propre et la plus simple
matriser sera dintgrer le service via le back-end lorsque cela
est possible. Par exemple, si un service mto vous propose,
au choix, une balise <iframe> vers une page web sur leurs
serveurs ou un service web en REST (Representational State
Transfer) pour rcuprer un fragment de code HTML injecter
dans votre page, prfrez toujours le second. Ce choix prend
tout son sens lorsque vous travaillez en responsive web design:
vous aurez en efet la possibilit, en linjectant via le back-end,
dappliquer au code HTML tous les styles que vous voulez pour
vous adapter toutes les largeurs dcrans!
Parfois, il vous faudra malgr tout appliquer des styles un
service tiers qui ne propose quune intgration via le front-end.
Et pour ces cas-l, aucune solution universelle nexiste, vous
devrez grer le problme au cas par cas.
Si vous intgrez des lments multimdias thoriquement
fxes (image, vido), vous avez des possibilits techniques
pour les rendre responsive (voir le chapitre prcdent). Tou-
tefois, noubliez pas de vous assurer que les conditions gn-
rales du service tiers vous y autorisent. Dans le cas contraire,
il peut tre salutaire de demander tout simplement une auto-
risation, en expliquant votre cas.
Si vous intgrez des balises <iframe>, alors leur contenu
pourra tre soit fuide et dpendant de la largeur de leur
<body> (auquel cas, vous vous retrouvez dans la mme situa-
tion quavec une image), soit largeur fxe, auquel cas votre
salut consistera contacter le service tiers pour tenter de les
convaincre de raliser une version fuide... (Bon courage!)
Si vous intgrez des fchiers JavaScript, cest alors des mon-
tagnes de courage qui vous seront ncessaires pour pratiquer
une rtro-ingnierie sur le contenu des fchiers et tenter de
comprendre comment rendre responsive ce quil cre... tout
en vrifant, encore une fois, que les conditions gnrales du
service vous y autorisent, videmment!
Vous laurez compris, selon votre cas, il se peut que cet aspect
du projet prenne des proportions que vous naviez pas anti-
cipes. Nhsitez pas, lors de lavant-vente, dfnir prcis-
ment la liste des services tiers, pour tenter destimer les cots
dintgration ds le chifrage (et avec un peu de chance, vous
gagnerez des points sur vos concurrents qui ngligeront peut-
tre cet aspect!)
Le front-end aux spcialistes !
Comme nous lavons voqu prcdemment, vous rencon-
trerez sans doute certaines fonctionnalits quil nest pas perti-
nent de confer lintgrateur (notamment celles contenant des
appels Ajax). Et si une fonctionnalit vous met dans le doute
(le dveloppeur back-end pourrait tout aussi bien la raliser
que lintgrateur), alors elle a certainement tout gagner tre
efectue par lintgrateur. En efet, mme si le dveloppement
a commenc et si lintgrateur nest plus disponible, la qualit
du site mrite certainement dattendre quil le soit nouveau!
Pour les fragments de HTML qui ne peuvent exister quen envi-
ronnement de dveloppement (code produit suite un appel
Ajax, version lgrement difrente dun bloc ne semblant pas
ncessiter de refaire une maquette intgre de zro pour si peu,
etc.), la solution sera toujours la mme : faire en sorte que ce
morceau de code passe dans les mains de lintgrateur un
moment ou un autre. Lintgrateur doit imprativement livrer
quelque chose pour chaque cas dutilisation dune maquette.
Une solution pour viter les trente maquettes intgres pour
la mme page consiste demander lintgrateur de laisser les
fragments alternatifs de code en commentaires HTML, direc-
tement dans la page (voir lexemple, fig.9-4, page suivante). Le
dveloppeur les trouvera l et saura ce quil est cens en faire.
Fig.9-4 : Exemple de code source laiss par lintgrateur aux dveloppeurs
pour proposer deux exemples de fragments HTML: celui produire quand
lutilisateur est connect et celui crer quand lutilisateur nest pas connect.
Une autre solution, que nous avons voque au chapitre prc-
dent, passe par la ralisation dune documentation par lintgra-
teur, livrer au dveloppeur avec les maquettes; celle-ci pourra
contenir directement les morceaux de codes HTML alterna-
tifs. lusage, on saperoit tout de mme que la mthode des
commentaires HTML est plus agrable mettre en uvre pour
lintgrateur, mme si une documentation additionnelle ne fait
jamais de mal.
Vous laurez compris, toutes ces astuces (le maximum dint-
gration de services tiers par le back-end pour matriser la vue
et le maximum de CSS/JavaScript par lintgrateur, mme dans
certains cas typiquement rservs aux dveloppeurs) visent
un objectif: rduire le risque de surprises aprs intgration, en
maintenant un primtre intgr le plus large possible.
GRER LES IMAGES FLUIDES CT SERVEUR
Lorsque le Web des annes 1990 tait majoritairement fuide,
insrer des images et des lments fxes tait dj tout un
labeur, tel point quon a considr plus simple de sembarquer
dans quinze annes dun Web largeur fxe, dans lide dendi-
guer le problme ! videmment, nous parlons ici des images,
mais tous les lments ayant une taille dorigine fxe (vidos,
objets embarqus comme les applets Flash) sont concerns,
les images tant llment le plus courant.
Le retour la fuidit, ncessaire pour couvrir la diversit des
largeurs dcrans daujourdhui, remet ce problme sous les
projecteurs et en fait lun des sujets techniques les plus dtaills
du livre Responsive Web Design dEthan Marcotte. Lenjeu est de
taille : comment servir intelligemment la mme image, mais
des chelles difrentes et sans commettre dabus de perfor-
mance? (Vous laurez compris, prendre une image gigantesque
et la retailler en front-end pour la version mobile nest pas une
option !) Les astuces se trouveront en grande partie du ct
front-end, mais puisquil faudra servir plusieurs versions de
votre image, de plusieurs tailles difrentes, les meilleures solu-
tions ncessiteront que votre serveur soit capable de crer ces
versions et de les stocker.
Or, ce petit dtail, coupl lincapacit frquente des CMS
(Content Management Systems) et frameworks modernes def-
fectuer eux-mmes cette tche, pourra reprsenter votre plus
mauvaise surprise dans vos aventures back-end sur le champ
de bataille responsive. Voil une mauvaise surprise qui mrite
que lon sy arrte un peu.
Quelle stratgie de redimensionnement ?
Ds lestimation de votre budget, vous devrez rfchir la stra-
tgie du redimensionnement des images. partir du moment
o votre contributeur met en ligne une image de contenu, vous
avez le choix entre trois possibilits:
soit elle est redimensionne et multiplie au moment de sa
contribution;
soit elle est redimensionne et multiplie lgrement aprs
sa contribution;
soit elle est redimensionne et multiplie lors du premier af-
chage de la page lutilisant.
Dans le premier cas, le contributeur qui charge limage sur le
serveur voit son attente plus longue pour que cette tche sex-
cute immdiatement. Cette piste a pour avantage de ne ralentir
que le temps de contribution et de proposer une solution fonc-
tionnelle immdiatement aprs la cration du problme ; elle
est la plus sense si lon admet que le contributeur puisse perdre
quelques secondes (ce nest donc pas un internaute) et, surtout,
si la solution ct serveur contient dj des briques permet-
tant cette confguration (ce qui peut tre long et complexe
dvelopper).
Dans le deuxime cas, la tche est mise en fle dattente pour
tre traite de manire asynchrone. Cette solution est similaire
la premire, mais est plus adapte au cas o le contributeur est
linternaute (en train de publier sa photo de profl, par exemple,
si lon prend lexemple dun rseau social). En revanche, si des
utilisateurs se rendent immdiatement aprs la contribution
sur les pages utilisant ces images, elles ne seront peut-tre pas
encore prtes tre servies; on peut alors imaginer leur servir
une image temporaire.
Une troisime solution, sans doute la plus simple en labsence
doutils dj existants, consiste laisser la contribution dimages
se drouler comme pour un site largeur fxe et ne rcuprer
le problme quau premier afchage dune page incorporant
limage: le premier utilisateur observe alors un ralentissement,
mais les images sont ensuite stockes et prtes tre servies aux
utilisateurs suivants. Le processus nest pas tranger une mise
en cache; et comme tel, il faudra rfchir ce qui se produit
si un contenu (ici, une image) est remplac et, si cest le cas, la
stratgie applicable pour vider le cache.
Un chose est sre: quelle que soit la stratgie que vous dcidez
de mettre en uvre, vous devrez vous assurer que limage est
bien propose dans un format sufsant pour couvrir toutes les
tailles dimages ncessaires pour toutes les versions. Prenez
dailleurs bien soin de ne pas supprimer limage tlcharge :
il sagit de votre information brute, avant que vous ne lalt-
riez Qui sait de quelle autre manire vous en aurez besoin
lavenir?
Quels outils ?
Si vous avez de la chance, peut-tre que loutil de gestion de
contenus (CMS) sur lequel le projet est construit embarque une
brique permettant de grer plusieurs tailles pour une mme
image soumise par le contributeur. La problmatique na pas
attendu le responsive web design pour exister : que ce soit
pour le cas dune image ayant un format difrent selon quon
lafche sur son article li ou sur une rubrique de contenus, ou
alors (comme dcrit prcdemment) pour le cas dune image de
profl de rseau social, reprise sur difrents types de pages, les
scnarios sont lgion et les CMS sy sont adapts!
Le CMS franais Spip (http://www.spip.net), par exemple,
propose un calcul lafchage de la page et sassure que chaque
nouvelle image soumise possde un identifant difrent (et
donc une cl de cache difrente) ; toutefois, en cas despace
disque trop utilis pour des images obsoltes, il ofre la possibi-
lit de vider manuellement ce cache (fig.9-5).
Fig.9-5 : Page de gestion du cache dans linterface dadministration de Spip
Certaines solutions autonomes (qui peuvent donc sinstaller
et sutiliser seules, la difrence dun plug-in) existent aussi,
proposant ce type de services de manire simple. Par exemple,
la solution que nous avons dj voque dans le chapitre 8,
Adaptive Images (http://adaptive-images.com) notez labus de
terminologie!, sinstalle comme nimporte quel site en PHP
sur votre serveur Apache et, moyennant une confguration
rapide, est capable de trouver les images concernes dans le
systme de fchiers et de les transformer la vole. Elle gre
son propre cache et apporte une rponse limite en fonction-
nalits mais satisfaisante, avec lavantage dignorer totalement
les autres technologies que vous employez pour votre site,
puisquelle sinstalle sparment.
Fig.9-6 : Le site dAdaptive Images vous apportera des dtails sur cette solution.
Source: http://adaptive-images.com
RLE ET FORMATI ON DES CONTRI BUTEURS DI TORI AUX 127
Si le goufre entre les mtiers du design et ceux du dveloppe-
ment continue avoir la vie dure dans certains environnements
de travail (nous lavons tous vu chez certains clients !), il tend
heureusement sefacer dans le milieu du Web, conscient que
la russite dun projet dpend toujours beaucoup de la bonne
comprhension mutuelle de lensemble de ses nombreux mtiers.
Toutefois, les mtiers de lditorial sont encore souvent tenus
grande distance des autres spcialits et, mme si leur industria-
lisation progresse de manire intressante, le contributeur est
rarement en contact direct avec la majorit du reste de lquipe.
Or, tandis quon voit apparatre de plus en plus de vritables
chargs de contenus web, sachant trs bien comment composer
un texte pour optimiser son rfrencement ou comment le
rendre plus accessible, voil que de nouvelles contraintes techni-
ques apparaissent, apportes par le responsive web design. Que
faire alors?
10
Rle et formation
des contributeurs
ditoriaux
Sur un projet typique, les contributeurs peuvent appartenir
lagence de communication ayant conu le site web ou une
agence spcialise dans lditorial, mais le plus souvent, ils font
directement partie des efectifs du client. Do quils viennent, il
semble indispensable que les contributeurs amens faire vivre
le site soient intgrs la recette fnale (ils sont les premiers
utilisateurs !) Malheureusement, cela reste aujourdhui trop
rarement le cas.
Une chose est sre : avant de se lancer dans la recette, vos
contributeurs auront certainement besoin de vos explications
sur ce qui va changer pour eux avec le responsive web design.
Inclure une petite mission de formation dans votre estimation
de budget initiale sera probablement trs apprci par le client
(surtout quune demi-journe sufra souvent dsamorcer
bien des incomprhensions).
LA CONTRIBUTION D IMAGES
Constituant lun des points techniques les plus ardus, la contri-
bution dimages devra ncessairement tre lobjet dune grande
attention. En efet, les images seront redimensionnes en
fonction des largeurs dcrans et, si la situation nest pas celle
attendue au dpart, ce redimensionnement pourrait avoir des
efets hasardeux.
Un livrable dfinissant toutes les tailles
d images
Une manire simple et efcace de garantir une bonne compr-
hension dans lquipe est de documenter prcisment la liste
des tailles dimages attendues. Le livrable est dautant plus
pratique que plusieurs acteurs du projet vont devoir manipuler
ces tailles dimages:
lintgrateur les dfnira selon les besoins techniques;
le dveloppeur les utilisera pour dvelopper ou confgurer les
scripts de redimensionnement;
et, lobjectif tant quil nait donner limage quune seule fois,
le contributeur devra la fournir au plus grand format dcrit.
Pour chaque format attendu sur tout le site, il existera un
nombre fni de versions de cette image. Le plus simple est donc
de produire un tableau avec, en abscisse, les difrentes largeurs
dcrans prvues pour le site et, en ordonne, les cas dutilisa-
tion des images fournies, comme sur la fig.10-1. Lintgrateur
qui a rdig cette documentation y a clairement identif dune
phrase la colonne qui est pertinente pour les contributeurs.
Fig.10-1 : Extrait de documentation pour dcrire prcisment les tailles existant
sur le site suivant toutes les versions
Ce livrable est raliser par lintgrateur, qui est le plus mme
de matriser les besoins techniques et graphiques simultan-
ment, pour toutes les versions du site. Il indiquera clairement
quelle est la colonne du tableau listant les tailles attendues pour
limage fournir, afn que les contributeurs puissent sy rfrer
tout moment de la vie du site (il livreront bien videmment la
version ofrant la meilleure rsolution).
Le livrable pourra contenir une description prcise de chaque
cas dutilisation des images, si possible avec des captures
dcrans. Lors de la formation, vous expliquerez les points
suivants aux contributeurs:
pourquoi un redimensionnement est ncessaire et en quoi il
est important pour servir une meilleure performance et une
meilleure qualit dimage;
les cas dutilisation dimages, un par un, tels que vous les d-
crivez dans le livrable;
si votre intgration est compatible retina, une explication
de ce que le terme signife (et si vous avez un doute, vous
pourrez le retrouver au chapitre7!) Notamment, si vous dis-
posez dun terminal capable de rendre du retina, lapporter
pour montrer la difrence sera immdiatement convaincant.
Les redimensionnements non homothtiques
Si le design prvoit que certains redimensionnements ne soient
pas homothtiques, cest--dire quils ne conservent pas le ratio
longueur/largeur des images, vous ajoutez une trs intense
couche de complexit votre projet. La difcult vient de la
bonne comprhension du fonctionnement de ce redimension-
nement par tous les membres de lquipe et de la manire dont
il va afecter leurs images.
Un exemple trs simple comprendre serait dimaginer une
image qui safche en mode portrait pour une certaine largeur
dcran (avec une hauteur plus longue que la largeur) et en
mode paysage pour une autre largeur dcran (avec une largeur
plus longue que la hauteur). Non seulement votre contributeur
devra comprendre si son image sera tire ou rogne, et quel
endroit exactement, mais ce fonctionnement afectera jusquau
photographe prenant initialement le clich!
Dune manire gnrale, nous nous permettons de vous dcon-
seiller cette espiglerie de design, lexception du cas o vous
matrisez parfaitement les images concernes (sil sagit dun cas
trs rare sur vos pages, par exemple).
TEXTE : DE NOUVELLES CONTRAINTES
Si lajout des images est intrinsquement complexe de par leur
nature rsolument fxe, la contribution dun texte brut sera sans
douleur dans la plupart des cas: le texte est un lment fuide
par nature et il survivra trs confortablement aux changements
de rsolution. Toutefois, il existera souvent dans vos designs
des zones de texte dont il vous faudra contrler la taille, pour
des raisons techniques ou de mise en page. Et cest ici que les
problmes commencent : un texte ne se laisse pas matriser
aussi facilement!
Identifier clairement les zones taille contrle
Vous nignorez sans doute pas cette fameuse bonne pratique:
dans un souci dadaptabilit du design aux cas de contribution
les plus fous ou aux cas dutilisation les plus atypiques, un
intgrateur web qui se respecte rsistera toujours autant que
possible lopportunit de fxer la hauteur dun bloc. En efet,
que se passe-t-il si le titre renseign tient sur plus dune ligne?
Et que se passe-t-il si lutilisateur utilise un zoom navigateur?
Il existe pourtant des cas dutilisation pour lesquels lintgrateur
doit capituler et o la solution la plus lgante imposera de fxer
une hauteur. Les raisons peuvent tre tout autant techniques
(le texte est encapsul dans un carrousel, par exemple) ques-
thtiques (deux blocs qui doivent commencer et se terminer
au mme niveau, par exemple notons tout de mme que lon
peut faire le choix de rgler ce cas lgamment en JavaScript, en
suivant un principe damlioration progressive).
Puisque ces zones de texte devront faire lobjet dune attention
plus particulire que les autres, fournir un livrable produit par
lintgrateur pour les identifer de manire claire semble tre un
bon point de dpart.
Contribution et recette : comment procder ?
Pour un site classique, il est dj parfois bien difcile de faire
prendre lquipe ditoriale le rfexe de regarder les efets de
leurs contributions sur linterface client. Une seconde difcult
survient quand vous tentez de leur expliquer quil est bon de
prvoir une marge de scurit, car il est impossible de prvoir
le comportement dun texte pour tous les navigateurs.
La typo, mon navigateur et moi
Jrmie Patonnier, coauteur de ce livre, a donn une conf-
rence Paris Web, en octobre 2011, sur les raisons techniques
qui expliquent une telle difcult rendre des polices de carac-
tres similaires dun navigateur lautre. On y dcouvre que les
causes sont multiples, mais tiennent plus souvent au systme
dexploitation quau navigateur, mme si rien ne vous garantit
pour autant que deux utilisateurs sur le mme systme dex-
ploitation, avec la mme version du mme navigateur, utilisent
le mme moteur de rendu typographique!
http://xav.cc/typos
15
Dans un projet responsive, les choses se corsent, puisquil va
falloir convaincre les contributeurs non seulement de faire ces
vrifcations, mais de les faire sur toutes les versions dfnies en
conception ! En efet, il ny a aucune raison technique que la
taille prvue pour le texte soit la mme dune version dinter-
face lautre. Le texte est susceptible de dborder de nimporte
laquelle des versions et il faut donc que les contributeurs testent
le rendu imprativement sur chacune des versions, une par une.
Par exemple, sur la capture dcran de la fig.10-2, il est vident que
le contributeur a test sa contribution sur son ordinateur, peut-
tre mme sur un smartphone, mais pas sur la version interm-
diaire (tablette), o le carrousel napparat pas de la bonne taille.
15. http://www.paris-web.fr/2011/conferences/la-typo-mon-navigateur-et-moi.php
Fig.10-2 : Capture dcran dun site responsive o la version tablette (en
2
e
position) prsente un cas mal test. (Inutile daller chercher en ligne, le
problme a t corrig entre temps!)
Lors de votre formation de lquipe ditoriale, il vous faudra
expliquer comment tester toutes les versions de votre site, que
ce soit par le simple redimensionnement du navigateur ou par
lutilisation de terminaux natifs, sil y en a disposition.
L internationalisation,
toujours une rjouissance !
Vous laurez compris, les occasions de faire des erreurs de
contribution dans ces zones de texte, par manque dattention
envers certaines largeurs dcrans, risquent dapporter tout un
lot de problmes. La solution rside dans un test continu de
la part des contributeurs, pour chaque modifcation dans les
zones risque; cependant, cest un efort permanent quil
sera parfois difcile de maintenir dans le temps.
Les habitus de lditorial web reconnatront ici sans doute les
mmes symptmes que ceux causs par linternationalisation
des sites, problmatique technique courante, en particulier de
ce ct de lAtlantique. Que celui qui a contribu un site multi-
lingue sans tre confront des problmes lis aux caractris-
tiques particulires dune langue nous jette la premire pierre!
Des mots composs sans espace en allemand (qui sont donc
interprts par le navigateur comme un seul mot interminable)
aux phrases trs denses en chinois, les raisons de voir altrs
lquilibre dun design et mme lintgrit technique dune
maquette HTML sont lgion sur un projet que lon a conu en
ne gardant quune seule possibilit linguistique en tte.
La fig.10-3 prsente un bon exemple de ce genre de problmes:
ce nest qu la recette de son site marchand que ce dtaillant
franais dans le domaine du pneu sest aperu que son design
trs contraint, pens pour la langue franaise, se retrouvait
malmen avec les libells polonais, signifcativement plus
longs. Le mot scurit , notamment, ne peut se traduire
que par le beaucoup plus long Bezpieczestwo. Les mots appa-
raissent donc coups et le texte dborde maladroitement. Cet
exemple est excellent pour rappeler que linternationalisation
est un exercice quil faut prvoir ds le design.
Ici aussi, aprs des annes de bonne connaissance et danalyse du
problme, une seule solution viable reste la plus efcace: tester
le rendu de chaque contribution, dans chacune des langues.
Dans le cadre dun site la fois responsive et multilingue, le
risque nen est que plus lev et la tche dautant plus difcile: il
faudra tester les zones de texte risque dans toutes les langues
et, pour chaque langue, dans toutes les versions de largeurs
dcrans! Autant de potentielles fautes dinattention, qui nces-
siteront dautant plus de vigilance long terme...
Fig.10-3 : Le design trs contraint du site de ce comparateur de pneus,
pens pour la langue franaise, est malmen avec les libells polonais,
signifcativement plus longs. Les mots sont coups par le design et le texte
dborde maladroitement (rsultat mis en valeur par les fches rouges).
TENIR COMPTE DE LA MISE EN PAGE
Il arrive toujours un moment o le contributeur utilisant un
CMS rve de fchir les spcifcations qui ont t dfnies et
qui rgissent la manire dont les lments sont mis en page.
Rencontrer le besoin dajouter librement un lment graphique
non prvu, et donc de dtourner les outils mis en place, est
totalement naturel. Cest dailleurs une cause de perte de qualit
qui revient assez frquemment.
Nous ne citerons pas de noms, mais on a mme trouv parfois dans
les contributions des fragments de code CSS qui surchargeaient les
rgles ralises par les intgrateurs, ou alors des lments HTML
au positionnement absolu en CSS, pour les disposer volont
dans le gabarit; ou, plus souvent encore, des cas de paragraphes
vides pour sparer des paragraphes jugs trop proches.
videmment, la solution idale est de demander lintgra-
teur de raliser proprement lvolution dont le contribu-
teur a besoin ; mais cette solution risque dtre coteuse, en
argent comme en temps (car bien sr, ce nouveau document
doit absolument tre en ligne tout de suite !), sans compter
que ce problme ne sera pas facilit dans le cadre dun projet
responsive, bien au contraire.
Encore et toujours l internationalisation !
Une premire contrainte technique souvent minimise lors de
loccurrence de ces erreurs est lefet de linternationalisation
sur la mise en page. De mme que certaines langues entranent
des contraintes sur les conteneurs de texte (voir la section
prcdente), des contraintes de layout peuvent apparatre.
Le cas le plus connu, notamment parce quil demande un
surplus important de travail la ralisation, est celui des
langages RTL (right-to-left, qui se lisent de droite gauche). En
efet, comment, en dtournant la mise en page prvue par le
biais dune contribution, sassurer que notre abus fonctionne
aussi lorsque tout le design de la page est invers (fig.10-4)?
Introduction la localisation, RTL et LTR
Dans cet article, Aurlien Masfrand dtaille les dfs tech-
niques poss par cette nouvelle contrainte. Il explique quune
solution se trouve dans la ralisation dune feuille de styles
additionnelle, qui nest incluse que dans le cas de ces langues
et surcharge les rgles CSS dfnissant les caractristiques de
positionnement horizontal des blocs de pages (fottement,
marge intrieure, marge extrieure, image de fond, etc.).
http://xav.cc/rtl
16
16. http://letrainde13h37.fr/13/introduction-localisation-rtl-et-ltr/
Fig.10-4 : Capture dcran de Wikipdia en langue arabe; on retrouve
clairement les rgles de design invers propres aux langues RTL.
Source: http://ar.wikipedia.org
Dans le cas du responsive web design, de la mme manire
que dans les corps de texte taille limite, les langues prsen-
tant des caractristiques susceptibles dafecter la mise en page
devront imprativement bnfcier dun surplus de vigilance, et
ce, dans toutes les largeurs dcrans. Puisque les rgles de posi-
tionnement changent tout autant dune version dinterface
lautre que dun layout linguistique lautre, une bonne solution
consiste garder en tte une liste des langues pour lesquelles
les consquences seront les plus importantes et procder
une recette permanente des pages o cette version linguistique
est modife, et ce, dans toutes les largeurs dcrans.
Le lcher-prise comme mthode
de contribution
Quel que soit le dfcit de qualit introduit par un contributeur,
que ce soit en dtournant lgrement les outils (code CSS insr
ou sauts de lignes vides espiglement introduits) ou de faon
totalement involontaire (texte saisi dans une langue trop peu
teste en intgration), les consquences peuvent tre domma-
geables. Limage positionne en absolu qui tombe parfaitement
sur le design franais tombera-t-elle toujours parfaitement sur
la mise en page inverse du design arabe? Le saut de ligne vide
sera-t-il interprt visuellement comme un saut de ligne par
tous les navigateurs, mme les plus anciens?
Et surtout, posez la question nimporte quel charg de
contenus web : est-il cens faire une recette continue aussi
intensive que celle qui a t faite par lintgrateur lors de la
ralisation?
Souvenez-vous que le Web est un environnement de dvelop-
pement particulirement hostile et quil est impossible que
lintgrateur parvienne faire face lintgralit des possibilits
de contribution ni lintgralit des confgurations ct client.
Son rle est justement de tenter de minimiser les problmes,
pour un maximum de cas rels.
Cest pourquoi, pour viter de vrifer en continu le rsultat de
ses contributions, le rdacteur devra seforcer de rester dans
les clous de ce que lintgrateur a prvu afn dassurer que lenvi-
ronnement incertain du Web naltre pas le beau travail de tout
le monde. Cependant, puisquil est le seul matriser en dtail
lvolution du site tout au cours de son existence en ligne, il sera
aussi le plus mme de garder un il vigilant sur les rendus
les plus risqus, afn de dnicher les cas les plus atypiques non
prvus lors de lintgration.
Lors de votre formation des contributeurs, un petit mot sera
sans doute utile pour leur rappeler que le responsive web
design ajoute des contraintes front-end encore plus risques
et donc des piges de contribution dautant plus frquents. Il
faudra les aider pointer du doigt les gabarits et les langues
les plus dangereux pour ce projet en particulier ; il ne faudra
galement pas hsiter leur rappeler o commence le rle dun
contributeur et o sarrte ce quil peut sautoriser faire en
matrisant les risques.
Reconnatre que tout nest pas possible et sadapter aux
contraintes: cest nouveau ce fameux lcher-prise du Web dont
nous vous entretenions ds le premier chapitre de ce livre!
EFFECTUER LA RECETTE APPLI CATI VE 139
Vos contributeurs sont maintenant forms et prts torturer
vos ralisations... et ces dernires sont fn prtes pour leur
tre livres ! La recette interne de fn de dveloppement back-
end est termine et tout le monde est satisfait du rsultat.
Dune main, votre client et/ou vos contributeurs sortent alors le
cahier de recette, sil a t ralis en dbut de projet, ou alors les
spcifcations fonctionnelles encadrant prcisment le primtre
du projet (si vous tes en mode forfait) ou du sprint (si vous
tes en mode agile). De lautre main, ils ouvrent le bugtracker ou
tout autre outil de remonte de bugs que vous avez lhabitude
dutiliser...
Une recette nest pertinente que si elle est ralise par quelquun
qui reprsente efcacement les futurs utilisateurs du site ; et
mme si ce rle peut sembler lui tre naturellement destin, il
ne doit pas sagir ncessairement du product owner (ou du chef
de projet mtier, ou du chef de projet ct client, selon votre
mode de fonctionnement). En ce qui concerne les contenus,
tout dpend de leur volume: si une seule personne est charge
11
Efectuer
la recete
applicative
de mettre tous les contenus en ligne, alors cest elle qui doit
tre sur le pont lors de la recette! Sil sagit dune quipe large
de contributeurs de divers horizons (par exemple, un site de
presse avec de nombreux correspondants locaux), alors votre
interlocuteur sera le responsable de la cohrence entre toutes
ces contributions avant mise en ligne.
En ce qui concerne les services et fonctionnalits, il faudrait
une personne capable de se mettre aisment dans le rle de
lutilisateur fnal. Thoriquement, certes, la personne experte
sur le projet est lergonome. Cependant, pour la recette, il faut
imprativement quelquun dextrieur lquipe, afn dviter
les confits dintrts et de confronter le projet au plus proche
de la ralit du monde extrieur. Cest l toute lexpertise du
product owner: il devra savoir comprendre et reprsenter les
utilisateurs du site (et donc avoir des afnits fonctionnelles
fortes), tout en sachant matriser les intrts de la marque quil
reprsente.
SE PRPARER POUR UNE RECETTE EFFICACE
Puisquil sagit peut-tre de leur premire recette sur un projet
responsive, vos clients devront sans doute tre rassurs et
informs sur la manire de bien adapter leurs habitudes. Les
encadrer en comit de pilotage pour poser quelques rgles de
base et manires de procder peut tre trs constructif. Au
besoin, prvoyez un peu de temps avec les clients pour les aider
mettre en place leurs outils techniques. Quelle quen soit loc-
casion, on ne se lance pas dans une aventure ambitieuse sans
un minimum de prparation pragmatique!
Choisir le bon matriel
Tout comme lintgrateur a scrupuleusement respect la
couverture matrielle dfnie en amont du projet pour tester ses
ralisations sur les priphriques pertinents, il sera constructif
de poser ouvertement la question au client propos des pri-
phriques exacts quil utilisera pour procder la recette, de
son ct.
Lobjectif est de contrler la validit de tous les aspects raliss
lors du sprint ou du projet. Donc, thoriquement, le client
doit procder strictement aux mmes tests que lintgrateur.
Toutefois, on observe quen ralit, il existe un efet de vase
communicant: lintgrateur ralise souvent des tests sur davan-
tage de navigateurs que ce qui est prvu et donc teste locca-
sion sur des navigateurs hors couverture; linverse, le client,
surtout lorsquil est en confance, teste souvent sur moins de
navigateurs que la couverture prvue.
Il est indispensable que le client teste la totalit des largeurs
dcrans cibles, puisque les fragments de code front-end (que
ce soit le CSS ou le JavaScript) qui sont interprts ne sont pas
les mmes. Mieux : si la couverture vise certains terminaux
particulirement populaires pour la cible marketing du site, il
sera dautant plus pertinent que le client dispose de ce terminal
pour sassurer dtre au plus proche de la ralit dutilisation.
Par exemple, cibler nommment liPad pour un site durable
nest pas pertinent, puisquon ne sait pas quel avenir est rserv
cette marque de tablettes en particulier; en revanche, le cibler
pour un site de culture occidentale faible dure de vie est
pertinent en 2013, car on connat le taux de pntration lev
de cette tablette sur cette chelle de temps et de gographie.
Dans un tel cas, il faut imprativement que la recette du site soit
efectue avec un vritable iPad.
Il est bon, pour les autres largeurs dcrans, de tester en prio-
rit avec dautres moteurs de rendu web, afn de maximiser la
couverture daccessibilit en augmentant le nombre de types
de cas ct client. Par exemple, si votre client teste sur iPad et
souhaite se limiter un navigateur moderne sur le desktop,
conseillez-lui de fuir Safari (qui est le mme navigateur),
dviter Google Chrome (qui utilise depuis peu le moteur de
rendu Blink, driv de WebKit) et de prfrer Firefox (moteur
de rendu Gecko). Il pourra ventuellement trancher en fonc-
tion de ce qui est le plus utilis par la cible du site.
Si votre client (ou votre product owner) se retrouve bien
malgr vous avec un terminal exotique entre les mains pendant
la priode de recette, il ne pourra pas sempcher daller tester
le projet avec, et il y a fort parier quil vous remontera certai-
nement des bugs sur ces plates-formes. Ce sera alors au chef
de projet de matriser ses excs de zle et de rester dans le
primtre des navigateurs dfnis dans le cahier des charges.
videmment, rien ne vous interdit de corriger quelques bugs
simples hors primtre pour tre sympathique, mais ne vous
embarquez pas dans des promesses pour des cas la marge qui
pourraient, au fnal, faire vaciller vos charges.
Et sinon ? Virtualisation !
Si votre client ne possde pas, pour ses sessions de tests, tout le
matriel compatible avec les navigateurs que vous avez dfnis
ensemble, il reste la solution de la virtualisation. Elle vise
installer, sur un systme hte , un logiciel permettant de
lancer un systme invit dans une fentre du systme hte;
tout logiciel ou cas dutilisation du systme invit sera alors
applicable dans cette fentre.
Cest potentiellement vous de lui dire si ses besoins en virtua-
lisation sont ralisables dans son cas. Vous devrez mme
parfois laider pour confgurer le systme ncessaire avant quil
ne se lance dans ses tests.
La virtualisation pour les navigateurs desktop
Les navigateurs modernes grand public pour ordinateurs
sont souvent multi-plates-formes : vous trouverez Firefox,
Chrome ou Opera aussi bien sous Linux ou Mac OS X que
sous Windows. Or, lusage, il savre que les difrences de
rendu sur le mme navigateur, entre deux systmes dexploi-
tation difrents, sont extrmement rares (hors rendu des
polices de caractres, toujours dpendantes du systme,
quoi quil arrive). Safari est une exception notable, puisquil
nest disponible que pour Mac OS X ; mais, sauf cas trs
particuliers, il est aisment remplaable par un autre naviga-
teur moderne, avec un risque de difrences qui reste assez
faible.
Le problme est difrent avec Internet Explorer, qui ne
fonctionne plus que sous Windows depuis la version 6 (les
versions prcdentes existaient pour Mac OS), et dont le
rendu est souvent trs difrent de celui des autres naviga-
teurs; il est mme trs difrent dune version du navigateur
lautre! VirtualBox est une solution gratuite (il y a mme une
version open source) pour virtualiser certains systmes dont
Windows, dans la plupart des systmes htes. Il ne vous reste
plus qu tlcharger une copie de Windows, que vous trou-
verez sur le site de Microsoft http://www.modern.ie.
Attention, cependant : toutes les versions dInternet
Explorer ne sont pas compatibles avec toutes les versions de
Windows. Pour tester sous Internet Explorer6, 7, 8, 9 et 10
(qui sont les versions notablement utilises dans le monde
en 2013), il vous faudra imprativement un WindowsXP, un
Windows7 et un Windows8.
Le march des navigateurs pour mobiles ou tablettes est beau-
coup plus segment que celui des navigateurs desktop.
Le navigateur natif Android (celui utilis par une majorit
dutilisateurs) nexiste que sous Android.
Firefox Mobile existe sous Android uniquement (et Fire-
fox OS, en cours de construction au moment o nous cri-
vons ces lignes).
Chrome existe sous Android uniquement (voir lapart qui suit).
Opera Mobile ( ne pas confondre avec lapplication Opera
Mini, voir lapart) existe sous Android et J2ME (plate-forme
Java, compatible avec lnorme majorit des feature phones,
en tte du march dans les pays en voie de dveloppement).
Pour Safari, cest encore plus simple: il nexiste que sous iOS
(systme dexploitation de liPhone et de liPad) et, par rgle-
ment dApple, aucun autre navigateur na le droit dy exister.
Chrome et Opera sur iOS ?
Le navigateur Google Chrome est disponible sur lApp Store,
mais il embarque une WebView de Safari ; cest donc en fait
Safari qui interprte votre page, Chrome pour iOS napportant
quune surcouche de fonctionnalits.
Opera Mini est galement disponible sur lApp Store, mais aussi
pour Android, J2ME, Blackberry Toutefois, il ne sagit pas
proprement parler dun navigateur : la page est interprte
sur les serveurs dOpera et une version simplife (et plus
lgre) est alors envoye au terminal. Ceci explique le succs
avanc de cette application un peu partout en Afrique et dans
les pays o linfrastructure est rudimentaire ou les forfaits,
limits. Dans tous les cas, nous vous dconseillons fortement
dinclure ce navigateur dans votre couverture de recette: il ne
respecte pas convenablement les standards du Web et ne sen
cache pas, son objectif principal tant la performance avant
toute chose.
Pour virtualiser un systme Android sur lequel votre client
pourra installer tout navigateur Android de son choix, la proc-
dure est trs technique et peu accessible un utilisateur non
familier de ces techniques.
Pour muler iOS (et donc ouvrir un iPhone ou un iPad sur
son bureau dordinateur), vous naurez pas dautre choix que
dutiliser... Mac OS X ! Votre client devra dabord installer
Xcode, loutil de dveloppement dApple, via le Mac App Store
(attention, un tlchargement de 4gigaoctets de donnes vous
attend). Puis, lmulateur iOS se trouve dans le sous-menu Open
developer tools et a llgance de vous proposer toutes les rso-
lutions existantes de lunivers Apple. Attention, cependant: il
sagit bien dune mulation (faisant semblant dtre iOS) et non
de virtualisation (qui aurait t un vrai iOS); en consquence,
il existe quelques difrences mineures avec un vrai iOS. Une
recette avec un vrai terminal pour sassurer que tout va bien est
donc une excellente ide dans tous les cas.
Fig.11-1 : Le moins transportable des iPhone du monde! (Mais aussi le moins
onreux, si vous utilisez dj un MacBook pour tester.)
PENDANT LA RECETTE APPLICATIVE
Votre client est maintenant entirement quip pour se mettre
dans le rle de vos utilisateurs. Il ouvre votre systme de
gestion de tches, prt saisir ses remontes : la recette peut
commencer.
Il existe de nombreuses manires de bien ou mal saisir des
tickets (ou tches, ou bugs) et ne pas tre avare de dtails
relvera du bon sens. Attention cependant, avec des versions
multiples, la couverture de la recette va tre multiplie et votre
zle sera encore plus ncessaire.
Rdiger un rapport de bugs
Nous vous conseillons la lecture du billet Rdiger un rapport
de bug, a na pas lair mais cest du boulot! sur le blog Les
Intgristes: http://xav.cc/bug
17
Les systmes de gestion de tches ou de tickets
Si votre technique habituelle vise traiter les remontes de
bugs ou de besoins dvolution par courriel (ou pire, par tl-
phone), sachez quil existe des outils ddis ce besoin et
qui vous viteront le syndrome du bug oubli et celui des
changes prcdents introuvables sur le sujet.
Le systme de gestion de tches ou de tickets (que lon
appelle aussi parfois bugtracker) est un outil qui vous servira,
ainsi qu votre client, tracer les discussions et ralisations,
problme par problme. Coupl un systme de gestion de
code source, il devient encore plus magique.
Lofre est trs large et trs varie : elle contient des outils
gratuits comme Trac, Mantis, Bugzilla, Redmine, etc. mais
aussi des outils payants comme Jira, Basecamp, etc.
Rendre vos tickets plus pertinents
Lors de la recette, le df le plus risqu va tre de sassurer
que, pour un bug remont, la largeur dcran sur laquelle il
est constat est claire pour tout le monde. Selon le systme
de gestion de bugs que vous utilisez, vous avez sans doute la
17. http://www.lesintegristes.net/2011/10/19/rediger-un-rapport-de-bugs-ca-na-
pas-lair-pas-mais-cest-du-boulot/
possibilit dajouter un champ vos tickets, qui spcife clai-
rement des intervalles de largeurs dcrans. Cest une manire
intelligente de sassurer que linformation nest pas oublie,
lorsquelle est pertinente.
Par analogie, si votre site contient certaines fonctionnalits
adaptatives (trac ditinraire masqu si le terminal ne dispose
pas de golocalisation, communication vido non disponible
si le navigateur ne sait pas rcuprer le fux de lventuelle
webcam du client...), il est toujours pertinent, pour les bugs
touchant ces fonctionnalits, de spcifer clairement les plates-
formes sur lesquelles ils sont constats (systme dexploitation,
nom et version du navigateur). Si cest une bonne pratique que
vous aviez dj mise en uvre pour vos autres projets, tant
mieux, vous ne pourrez dsormais plus vous en passer!
Dans tous les cas, la reproduction du bug est potentiellement
plus difcile que dhabitude. Il faut alors faire appel aux tech-
niques habituelles, mais appliques plus systmatiquement.
Par exemple, nhsitez pas tre trs spcifque sur le dtail
du mode opratoire. Par ailleurs, puisquil peut tre plus dif-
cile de simuler les conditions front-end dautrui, une simple
capture dcran est quelquefois trs salvatrice pour comprendre
le problme en un clin dil!
Lexercice de la recette
lexception de linhabituel nombre de plates-formes applica-
tives sur lesquelles tester, lexercice de la recette en lui-mme
sera relativement similaire nos habitudes. Le pige inter-
viendra avant tout lors des retours de bugs: il faudra, comme
dhabitude, contrler leur correction convenablement, mais
aussi sassurer que celle-ci nengendre pas defets de bord sur
les autres versions de largeurs dcrans.
Sil faut bien penser tester toutes les versions, il existe un
critre sur lequel il ne faut pas se focaliser: les animations entre
versions ! Certes, il est toujours constructif de sassurer de
conserver un site accessible en cas de redimensionnement du
navigateur desktop par lutilisateur, mais souvenez-vous quil
sagit dun cas dutilisation marginal et que la mouvance visant
peaufner les transitions dune largeur dcran une autre a tout
de lefet de mode. Si les utilisateurs rels ont besoin de redi-
mensionner leur cran (ne serait-ce quen basculant du mode
portrait en mode paysage sur leur priphrique mobile), seuls
nous autres web-geeks nous amusons retailler les navigateurs
pour le plaisir des yeux!
APRS LA MI SE EN PRODUCTI ON 149
Flicitations! Votre recette applicative est maintenant termine,
le client est sufsamment satisfait du rsultat pour considrer quil
ny a plus de raisons de cacher ce bel ouvrage aux yeux du public.
Certes, il reste peut-tre un bug ou deux par-ci par-l et toutes
les fonctionnalits secondaires ne sont peut-tre pas encore int-
gres (a fortiori si vous menez ce projet en mode agile), mais le
choix est tranch: pourquoi attendre plus longtemps, alors que
nous avons dj un site tout fait fonctionnel et satisfaisant ?
Une fois le site en ligne, tous vos amis et ceux du client a
minima sy rendent dans la foule et vous remontent une quan-
tit de dtails que vous naviez pas remarqus (tous sans gravit
ou, en tout cas, on vous le souhaite !) Ces premires opinions
externes donnent quantit dides dvolutions pour le site que le
client commence formuler. Comment sy prend-on, alors? Cest
tout lart de la TMA (tierce maintenance applicative).
12
Aprs la mise
en production
Contractuellement, la TMA (tierce maintenance applicative)
est toujours un exercice de style. Si votre projet tait vendu
avec une obligation de rsultat, le client vous a potentiellement
impos une priode de garantie, mais vous devez mettre un
point dhonneur ny accepter que les bugs (cest--dire des
difrences claires entre les spcifcations et le fonctionne-
ment observ). Que faire alors des bugs dcouverts aprs cette
priode et de toutes les volutions?
Deux choix sofrent vous:
soit ces volutions et ces bugs sont connus aujourdhui et faci-
lement chifrables, auquel cas il est possible de les regrouper
simplement en un projet qui ressemblera contractuellement
nimporte quel projet (rgie? forfait? agile? les mmes ques-
tions se posent nouveau...);
soit le client a besoin de disponibilit continue pour rsoudre
des problmes encore inconnus, qui surviendront avec le
temps, au jour le jour. Dans ce cas, vous pouvez partir sur
la rservation pour lui dun contingent de x jours par mois.
La difcult est, comme pour tous les projets, dvaluerx en
fonction dun nombre inconfortable de facteurs, parmi les-
quels la vlocit de lquipe de TMA (avec qui vous venez
peut-tre tout juste de faire connaissance), la complexit et
la maintenabilit de lapplication web, ainsi que le nombre de
problmes qui surviendront chaque mois.
TMA
On dit de la TMA que cest une tierce maintenance appli-
cative, car elle est frquemment ralise par une autre quipe
que celle qui a dvelopp le projet. Que ce soit rellement le
cas ou non, on dsigne tout de mme en ces termes les modi-
fcations apportes au projet au-del de la couverture fonc-
tionnelle contractualise pour la ralisation du site, le plus
frquemment aprs sa mise en production.
Le contexte contractuel de ces oprations (inclus dans le
contrat initial en tant que priode de garantie, dpenses suppl-
mentaires prvues dans le contrat initial, dpenses supplmen-
taires encadres par un avenant au contrat...) est fortement
dpendant de laccord que vous avez avec votre client et, bien
souvent, il existe autant de modalits de TMA que de clients,
voire de projets!
Dans ce chapitre, nous voquons indifremment nimporte
quelle forme contractuelle de maintenance ou dvolution dun
projet web aprs sa mise en production.
LE DILEMME HABITUEL : TROUVER LE BON
CONSULTANT DE TMA
Dans la mthodologie agile Scrum, il est clairement spcif
que lquipe doit rester la mme du premier au dernier jour
du projet, car linverse peut entraner trois consquences: une
perte de qualit, une perte de temps et une totale impossibilit
de calculer la vlocit de lquipe. Mme si cet enseignement
est clairement nonc dans le manifeste Scrum, il nen reste pas
moins efectif dans les autres types de projets.
Si certaines agences web peuvent se permettre de conserver
les mmes acteurs sur un projet aprs sa mise en production,
pour dautres, cela est totalement irraliste en termes de gestion
du personnel. Il faudra alors accepter que la perte de temps,
la perte de qualit et la perte de toute information sur la vlo-
cit de lquipe sont invitables. On peut toutefois diminuer la
perte de qualit en donnant la nouvelle quipe lopportunit
de mettre en place une vritable continuit avec les mthodes
de lquipe sortante.
Globalement, le choix dun intervenant de TMA sur un
rle particulier peut tre efectu en se posant les questions
suivantes, dans lordre.
1. Le consultant qui tait en poste lors de la ralisation du
projet sera-t-il disponible pour grer la TMA ? Si oui,
vous avez bien videmment dj sous vos yeux votre
consultant TMA idal ! Si non, poursuivez avec les
autres questions...
2. Le consultant qui tait en poste lors de la ralisation
du projet sera-t-il disponible de temps en temps, pour
intervenir en qualit de conseil auprs de lquipe
TMA? condition daccepter de lui rserver un temps
sufsant, cette solution peut savrer trs efcace.
3. Existe-t-il un consultant disponible pour grer la TMA
qui soit trs familier avec les mthodes du consultant
sortant? Cette question est particulirement pertinente
pour les mtiers faiblement industrialiss : dfaut
dindustrialisation technique reconnue, privilgions
lhumain!
4. Le consultant sortant laisse-t-il derrire lui une
documentation dtaille sur sa mthodologie? Le travail
peut tre fastidieux, mais reste alors votre dernire
opportunit dofrir une continuit...
Le niveau dindustrialisation du mtier en question (industria-
lisation publiquement reconnue, dune part, mais surtout, lin-
dustrialisation rellement applique au cours du projet) rendra
ce besoin de continuit plus ou moins relatif: les consultants
en infrastructure dhbergement, suivant la lettre des rgles
prcises de scurit infrastructurelle, seront plus facilement
interchangeables que des consultants en design fonctionnel,
utilisant potentiellement des outils difrents.
Dans tous les cas, mme si le consultant prsent en cours de
projet est disponible (solution n1 dans notre liste), on ne peut
pas compter sur cette issue de manire prenne: ce consultant
peut trs bien quitter lentreprise ou navoir plus de souvenirs de
ses mthodes lpoque de la ralisation du projet (si plusieurs
mois se sont couls), et vous serez alors soulag davoir mis
en place un plan de continuit plus avanc, surtout par le biais
dune documentation (solution plus prenne que de compter
sur la connaissance par chacun des mthodologies des autres).
UNE DIFFICULT : LA CONTINUIT DU TRAVAIL
D INTGRATION
Dans le cas dun projet responsive, la problmatique reste la
mme, mais elle est beaucoup plus stratgiquement posi-
tionne autour du travail dintgration front-end. Cet efet a
deux causes: il sagit non seulement de lune des expertises les
plus cruciales du projet, mais aussi dun domaine encore mal
industrialis. Ainsi, mme une mthodologie de travail appli-
que la lettre par lintgrateur lors de la ralisation du projet
ne sufra pas, puisquil nexiste pas vritablement de mtho-
dologie globalement reconnue. Tout le soin du monde nemp-
chera pas que le prochain consultant pourrait trs bien tre un
parfait tranger ne connaissant pas la mthode que vous avez si
soigneusement applique.
Aux mmes causes, les mmes efets : sil est impossible que
lefort soit encadr par le mme expert front-end que pendant
la ralisation, il faudra privilgier la passation la plus douce
possible. On sappuiera le plus possible sur de la documen-
tation, ou mieux, on slectionnera en TMA un expert front-
end trs familier avec les mthodes de celui qui a fait le travail
jusqu maintenant.
Il existe un efet pervers supplmentaire, apport par lvolu-
tion rapide des bonnes pratiques dans le domaine du responsive
web design actuellement : le mme intgrateur peut trs bien
intervenir en TMA quelques mois plus tard sur le projet, mais
avoir compltement chang sa manire daborder les projets
entre-temps. Il peut rellement arriver que le changement soit
si intense que la situation sera trs similaire celle o lintgra-
teur est un nouvel intervenant sur le projet. Encore une fois,
cest la documentation laisse lpoque qui sauvera la situa-
tion; lintgrateur, en se relisant, retrouvera naturellement son
chemin.
Il en va de lvolutivit du projet : mme si la modifcation
de la conception fonctionnelle (notamment via la retouche
des prototypes fonctionnels initiaux) peut sembler impres-
sionnante au premier abord, dans le contexte responsive, on
saperoit lusage quelle nest pas particulirement complexe
en tant que telle. En revanche, elle remet parfois en question
des partis pris fondateurs qui avaient t acts par lintgrateur
pour correspondre cette conception initiale. Cest donc bel
et bien sur la continuit du travail dintgration que se situe le
risque le plus fort.
APRS- PROPOS : LE MOT DE LA FI N 155
APRS-PROPOS : LE MOT DE LA FIN
Eh bien, voil, cest fni! Ou plutt non, cest maintenant que
tout commence Ce livre est lun des tout premiers traiter
de la gestion de projet men en responsive web design, mais
cest loin dtre le dernier. Notre petite ambition, si jamais il
y en eut une, tait de poser les premires bases dun terrain
beaucoup plus vaste. En efet, le responsive web design est
trs largement trait ici et l dans sa dimension technique ;
on ne remerciera dailleurs jamais assez Ethan Marcotte pour
tout ce quil a pu crire en la matire. Cependant, force de
travailler sur des projets web de cette nature, nous navons pu
que constater limmense absence de littrature concernant les
aspects pratiques de la gestion de projet. Dans ce domaine, les
pratiques voluent tous les jours et les prestataires, aussi bien
que les clients, gagnent en maturit. Nous ne sommes donc pas
inquiets : une bonne partie de ce que nous avons crit ici va
devenir obsolte dans les mois et annes venir.
Aussi surprenant que cela paraisse, surtout si vous avez dpens
de largent pour faire lacquisition de cet ouvrage (au fait,
merci !), cest une excellente nouvelle. En efet, le responsive
web design et son petit frre, le design adaptatif, ne sont sans
doute que la partie merge dun Web actuellement en pleine
rvolution. Lapparition du Web mobile a forc les dve-
loppeurs et concepteurs de sites retrouver des contraintes
quon croyait oublies (petits crans, faibles ressources de
calcul, rseaux lents). En parallle, les navigateurs deviennent
de plus en plus puissants, ces simples liseuses de documents se
transformant en de vritables plates-formes dexcution appli-
cative. Tout cela va pousser de profondes remises en question
de la gestion des projets web. De nouveaux modles vont appa-
ratre, de nouvelles mthodologies, de nouvelles pratiques.
Essais, erreurs... Que de moments passionnants devant nous.
Vivement demain!
Comme vous le voyez, le sujet est nouveau et vaste, aussi
navons-nous fnalement fait quouvrir une porte, que nous
vous invitons franchir. Nous navons en aucune manire eu la
prtention dtre exhaustifs ni mme visionnaires. Nous avons
simplement voulu partager notre exprience des problma-
tiques rencontres quotidiennement sur ce sujet. Dsormais, la
balle est dans votre camp: faites-vous votre propre ide, exp-
rimentez et, fnalement, partagez votre tour votre savoir-faire.
Ils seront nombreux, nous les premiers, vous en remercier.
PROPOS DES AUTEURS 157
PROPOS DES DEUX AUTEURS
Jrmie Patonnier
Au sortir dtudes dimprimerie et darts appli-
qus, Jrmie se lance dans le Web en tant que
designer web. Il dcouvre alors le dveloppe-
ment informatique, trouve a rigolo et dcide
de devenir dveloppeur web. Comme a ne lui
suft toujours pas, il dcide de passer au management en deve-
nant responsable dquipe web. Aprs toutes ces tribulations,
il est maintenant consultant web pour lagence parisienne du
cabinet dexpertises Clever Age, o il fait bnfcier ses clients
de son expertise aussi bien ct serveur que ct client.
ct de a, il mne plusieurs projets de front, qui ont tous
pour objectif de donner aux designers et dveloppeurs web
toutes les connaissances ncessaires pour bien faire leur travail.
Cofondateur des sites typographisme.net et letrainde13h37.fr, il
est galement contributeur au projet Mozilla, o il participe la
documentation des technologies du Web ouvert sur le Mozilla
Developer Network (MDN). Il intervient rgulirement en tant
quorateur des confrences, aussi bien en France (Sud Web,
Paris Web) qu ltranger (The Graphical Web).
Rudy Rigot
Rudy est un passionn du Web sous toutes ses
approches : tomb dedans par la technique
(en gagnant ses premiers galons au cur du
dveloppement Java/JEE), il a ensuite trouv
son bonheur dans dautres contres, du design fonctionnel au
webmarketing, et surtout, dans la jonction de tous ces mtiers.
Toujours laft de nouvelles choses apprendre, mais aussi
soucieux de partager ses dcouvertes, il intervient comme
orateur dans diverses confrences et comme auteur dans divers
magazines professionnels. Il est aussi lun des membres fonda-
teurs des confrences Sud Web, qui ont lieu depuis 2011.
Lorsque le responsive web design a merg, il a t parmi les
premiers mettre en garde quant aux impacts sur les processus
habituels de conception et de gestion de projet (notamment lors
de son intervention aux confrences Front Row Cracovie, en
octobre 2011, ou dans un article publi en avril 2012 par le maga-
zine en ligne Dev.Opera).
Il doit son apprentissage et ses travaux de recherche sur le
responsive web design la collaboration efcace avec ses coll-
gues de lagence Clever Age, pendant quatre ans. Depuis, il a
dirig le produit Steerious (fond par Clever Age, et aidant les
organisations piloter leur stratgie numrique) et fait main-
tenant partie du think-tank dinnovation web Zenexity (dont le
produit phare est le framework Play).
I NDEX 159
A
accessibilit 7, 72, 83
Adaptive Images 124
adaptive web design 10
agence web 60
agile (mthode) 19
Allsopp, John 14
amlioration
continue 60
progressive 13
AMOA (assistance matrise douvrage
outille) 24
appel dofres 24
architecte
back-end 55
infrastructurel 55
B
budget 33, 90
bug 145
bugtracker 146
C
cahier des charges 37
fonctionnel 37
graphique 38
priorits 38
technique 37
card sorting 57
CATEEA (charte) 47
charte graphique 92
chef de projet 49, 77, 83, 114
client 27
prise de contact 24, 26
colonne 72, 73
composant graphique 93
conception 77
approches 63
outils 74
contributeur 56, 127
formation 128
gestion des images 122
recette 132
texte 131
cot 32, 78
design graphique 87
CSS (Cascading Style Sheet)
@font-face 95
media queries 8, 71, 102
pixel 100
transform 100
D
dgradation lgante 11
dlais
design graphique 88
mthodes agiles 20
design
adaptatif 10
dexprience utilisateur 57
motionnel 51
graphique 87
persuasif 52
designer 78
dexprience utilisateur (UX) 57
fonctionnel 52
graphique 53
design pattern 59
dveloppement
back-end 109
front-end 97, 109, 119
dveloppeur
back-end 110, 115
front-end 59
directeur artistique 51, 92
interactif 57
documentation 106, 120, 152, 153
E
cran
capacits 102
largeurs 1
ditorial 127
quipe 45
rle projet 46, 48, 77
ergonome 57
exprience utilisateur 31, 65
conception 78
design 57
INDEX
expertise 45
amlioration continue 60
sparation 111
eye-tracking 57
F
Facebook 31, 60
fchier source graphique 94
fuidit 121
fonte
licence 95
units de mesure 68
framework
de dveloppement rapide 75
HTML 81
G
gabarit 67, 89
fuide 69
horizontal 70
pagin 70
gestion de projet 15
cycle en V 17
en forfait 18
mthode agile 19
modle en cascade 16
grille typographique 72, 80
Gustafson, Aaron 10
I
iframe 117
image 98, 102
contribution 128
gestion ct serveur 121
optimisation ct serveur 103
redimensionnement 122
redimensionnement non homoth-
tique 130
industrialisation 3, 46, 152
intgrateur 54, 58, 110, 114, 119
expert 78
intgration 80, 97
continuit 154
documentation 106
gestion des images 98
stratgie de test 104
internationalisation 134, 136
iPad mini 72
J
JavaScript 104
services tiers 118
L
lcher-prise 14, 40, 137
livrable
graphique 91
liste des tailles dimages 128
prototype 82
lorem ipsum 80
M
maintenance 151
Marcotte, Ethan 9, 97, 121, 155
mtier 48, 56
mise en page 135
mobile frst 64
N
navigateur
de bureau 104
desktop 142
mobile 105, 143
moteur de rendu 141
recette 141
O
objectifs du projet 27
Opera Mini 144
P
performances 7, 31
images 102
persona 57
persuasive design 52
Photoshop 90
pixel 68, 98
CSS 99, 100, 101
OS 100, 101
physique 99, 101
plate-forme cible 40, 41, 42
point de rupture 44, 71, 73
police de caractres 95, 132
licence 95
units de mesure 68
pr-conception 63
I NDEX 161
product owner 49
projet
contraintes 29, 38
objectifs 27
primtre 40
responsive ou non ? 30
prototypage 78, 79
retours 82
publicit 115
R
recette
applicative 139
contributeurs 128
contribution 132
exercice 147
interne 112
matriel 140
technique (back-end) 113
tickets 145, 146
virtualisation 142
recueil des besoins 23
responsive web design 8, 9
retina display 99
S
Scrum 151
service tiers 117
T
TDD (Test Driven Development) 114
test
back-end 111
contributions 132
navigateurs 104
recette 141
stratgie 104
utilisateur 57, 65
TMA (tierce maintenance applicative)
149, 150
Twitter 31
typographie 95, 132
U
unit de mesure 68, 69
user frst 65
utilisateur
conception centre ~ 65
tests 57
UX designer 65
V
veille 62
viewport 69, 100
virtualisation 105
W
war room 91
wireframe 75
Z
Zeldman, Jefrey 9, 10

Projet Responsive Web Design PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

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 :

Formats disponibles

Projet Responsive Web Design PDF

Transféré par

Droits d'auteur :

Formats disponibles

Jrmie Patonnier

Vous aimerez peut-être aussi