Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Conduite de Projet Web - 5ème Edition

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 456

G12665_Projet_Web_5e_XP 11/12/09 16:55 Page 1

Conduite 5e édition S T É P H A N E B O R D A G E

STÉPHANE
BORDAGE
de p rojet Web Avec la collaboration de D. Thévenon, L. Dupaquier et F. Brousse

Mener son projet avec méthode


Comment gérer avec efficacité un projet Web ? Comment préparer

Conduite
au mieux son déroulement et garantir la réussite de chaque phase ?
Sur le CD-Rom :
• 60 modèles de documents prêts Nourri par la grande expérience de l’auteur, cet ouvrage vous four-
à l’emploi (étude de faisabilité, cahier nira les moyens d’y parvenir, en proposant des solutions concrètes et
opérationnelles pour chaque étape. Émaillé de nombreuses check-

5e édition
des charges, spécifications techniques…)
aux formats Word, Excel et PowerPoint listes et grilles d’analyse, ce guide très concret synthétise les princi-
pales pratiques rencontrées sur le terrain pour chaque type de site :

Conduite de projet Web


• un outil de création de business plan, le
Montpellier Business Plan Classic sites catalogues, marchands, institutionnels, de marques, communau-

de projet
Vous créez une entreprise innovante : le Montpellier Bu- taires, éditoriaux, portails d’entreprise, intranets…
siness Plan Classic, développé par le Business and Innova-
tion Centre de Montpellier Agglomération (élu meilleur Toutes les phases de gestion d’un projet Web y sont développées :
incubateur mondial en 2007 par la NBIA, labellisé Soft stratégie, définition de l’offre, construction du business plan, suivi du
Landings pour l'accompagnement d'entreprises étran-
gères en 2008 et certifié ISO 9001 en 2009 par l'Afaq) avec budget, étude de faisabilité, appel d’offres, choix des prestataires,
un taux de réussite supérieur à 80 % trois ans après sa cahier des charges, réalisation du site, promotion, hébergement, réfé-
création, répond à toutes vos attentes avec :
- sa large palette d'outils de gestion rencement, aspects juridiques… Entièrement actualisée, la cinquième
prévisionnelle et de suivi de l'activité
- sa méthode simple et complète qui édition de cet ouvrage est complétée par cinq études de cas
crédibilisera votre projet auprès détaillées et de nombreux avis d'experts.

Web
d'Oséo, des banques et des capitaux
risqueurs.
Découvrez la gamme complète des
logiciels Montpellier Business Plan et
accédez au service d'aide en ligne sur À qui s’adresse ce livre ?
5e édition
www.montpellier-business-plan.com.
– Aux chefs de projets Web
Configuration minimale requise :
Word 97, Excel 97, PowerPoint, Windows 2000 (pour – Aux dirigeants de petites et moyennes entreprises
Montpellier Business Plan Classic) – Aux chefs de produits et de marques souhaitant intégrer
des solutions Web dans leur plan marketing
– Aux responsables de communication interne ou externe
http://www.free-livres.com/
Les auteurs
Titulaire d’une maîtrise en marketing, Stéphane
Bordage se consacre totalement à l’accompagne-
ment des projets Web depuis 1999. Son expertise Autodidacte, Laurence Dupaquier alias « la sorcière
porte sur les phases amont des projets (stratégie, du référencement », a réalisé une centaine de sites
besoin, faisabilité, conception, cahier des charges, Internet avant de s’intéresser au référencement, STRATÉGIE - BUSINESS PLAN - SUIVI DU BUDGET
appel d’offres) et aval (recette, formation). Il est prenant conscience rapidement de l’enjeu que
aujourd’hui associé fondateur de l’agence Breek. représente la visibilité pour les entreprises. Elle ÉTUDE DE FAISABILITÉ - APPEL D’OFFRES
sbordage@breek.fr exerce son activité de positionnement de sites
Internet depuis de nombreuses années dans des CHOIX DES PRESTATAIRES - CAHIER DES CHARGES
Diplômé de l’École supérieure de commerce contextes concurrentiels élevés.
de Tours, David Thévenon a occupé différents lasorciere@prestataire.net
RÉALISATION DU SITE - PROMOTION - RÉFÉRENCEMENT
postes financiers en France et à l’étranger au sein
d’Elf Atochem, Fujitsu Services, Dell et T-Mobile
International. Il travaille actuellement pour Google.
HÉBERGEMENT - ASPECTS JURIDIQUES
david@coolmind.net 5 ÉTUDES DE CAS
ISBN : 978-2-212-12665-5
Code éditeur : G12665

Avocat au barreau de Paris, Franklin Brousse est spé-


9 7 8221 2 1 2665 5

cialisé dans l’accompagnement juridique des entre-


prises et des collectivités locales menant des projets L’informatique professionnelle
technologiques et innovants dans le domaine de l’in- www.indexel.net
formatique, d’Internet et des télécommunications.
fbrousse@simonassocies.com

35 €
G12665_Projet_Web_5e_XP 11/12/09 16:55 Page 1

Conduite 5e édition S T É P H A N E B O R D A G E

STÉPHANE
BORDAGE
de p rojet Web Avec la collaboration de D. Thévenon, L. Dupaquier et F. Brousse

Mener son projet avec méthode


Comment gérer avec efficacité un projet Web ? Comment préparer

Conduite
au mieux son déroulement et garantir la réussite de chaque phase ?
Nourri par la grande expérience de l’auteur, cet ouvrage vous four-
nira les moyens d’y parvenir, en proposant des solutions concrètes et
opérationnelles pour chaque étape. Émaillé de nombreuses check-

5e édition
listes et grilles d’analyse, ce guide très concret synthétise les princi-
pales pratiques rencontrées sur le terrain pour chaque type de site :

Conduite de projet Web


sites catalogues, marchands, institutionnels, de marques, communau-

de projet
taires, éditoriaux, portails d’entreprise, intranets…
Toutes les phases de gestion d’un projet Web y sont développées :
stratégie, définition de l’offre, construction du business plan, suivi du
budget, étude de faisabilité, appel d’offres, choix des prestataires,
cahier des charges, réalisation du site, promotion, hébergement, réfé-
rencement, aspects juridiques… Entièrement actualisée, la cinquième
édition de cet ouvrage est complétée par cinq études de cas
détaillées et de nombreux avis d'experts.

Les auteurs
Titulaire d’une maîtrise en marketing, Stéphane
Bordage se consacre totalement à l’accompagne-
À qui s’adresse ce livre ?
– Aux chefs de projets Web
– Aux dirigeants de petites et moyennes entreprises
– Aux chefs de produits et de marques souhaitant intégrer
des solutions Web dans leur plan marketing
– Aux responsables de communication interne ou externe
Web 5e édition

ment des projets Web depuis 1999. Son expertise Autodidacte, Laurence Dupaquier alias « la sorcière
porte sur les phases amont des projets (stratégie, du référencement », a réalisé une centaine de sites
besoin, faisabilité, conception, cahier des charges, Internet avant de s’intéresser au référencement, STRATÉGIE - BUSINESS PLAN - SUIVI DU BUDGET
appel d’offres) et aval (recette, formation). Il est prenant conscience rapidement de l’enjeu que
aujourd’hui associé fondateur de l’agence Breek. représente la visibilité pour les entreprises. Elle ÉTUDE DE FAISABILITÉ - APPEL D’OFFRES
sbordage@breek.fr exerce son activité de positionnement de sites
Internet depuis de nombreuses années dans des CHOIX DES PRESTATAIRES - CAHIER DES CHARGES
Diplômé de l’École supérieure de commerce contextes concurrentiels élevés.
de Tours, David Thévenon a occupé différents lasorciere@prestataire.net
RÉALISATION DU SITE - PROMOTION - RÉFÉRENCEMENT
postes financiers en France et à l’étranger au sein
d’Elf Atochem, Fujitsu Services, Dell et T-Mobile
International. Il travaille actuellement pour Google.
HÉBERGEMENT - ASPECTS JURIDIQUES
david@coolmind.net 5 ÉTUDES DE CAS
Avocat au barreau de Paris, Franklin Brousse est spé-
cialisé dans l’accompagnement juridique des entre-
prises et des collectivités locales menant des projets L’informatique professionnelle
technologiques et innovants dans le domaine de l’in-
formatique, d’Internet et des télécommunications.
fbrousse@simonassocies.com
www.indexel.net
Gratuit !
• 60 modèles de livrables
prêts à l’emploi
• un outil de création
de business plan
Conduite
de projet
Web
CHEZ LE MÊME ÉDITEUR

O. Andrieu. – Réussir son référencement web (2e édition).


N°12646, 2009, 462 pages.

A. Boucher. – Ergonomie web (2e édition). Pour des sites web efficaces.
N°12479, 2009, 426 pages.

N. Chu. – Réussir un projet de site web (5e édition).


N°12400, 2008, 246 pages.

A. Boucher. – Mémento Ergonomie web.


N°12386, 2008, 14 pages.

E. Sloïm. – Mémento Sites web (2e édition). Les bonnes pratiques.


N°12456, 2009, 14 pages.

M.-V. Blond, O. Marcellin et M. Zerbib. – Lisibilité des sites web.


Des choix typographiques au design d’information.
N°12426, 2009, 314 pages.

S. Roukine. – Améliorer ses taux de conversion web. Vers la performance des sites web au-delà du webmarketing.
N°12499, 2009, 268 pages.

I. Canivet. – Bien rédiger pour le Web. …et améliorer son référencement naturel.
N°12433, 2009, 412 pages.

D. Mercer. – Réussir son site e-commerce avec osCommerce.


N°11932, 2007, 446 pages.

C. Porteneuve. – Bien développer pour le Web 2.0 (2e édition).


N°12391, 2008, 674 pages.
S T É P H A N E B O R D A G E
Avec la collaboration de D. Thévenon, L. Dupaquier et F. Brousse

Conduite
de projet
Web
Cinquième édition
ÉDITIONS EYROLLES
61, bd Saint-Germain
75240 Paris Cedex 05
www.editions-eyrolles.com

Le code de la propriété intellectuelle du 1er juillet 1992 interdit en effet expressément la


photocopie à usage collectif sans autorisation des ayants droit. Or, cette pratique s’est
généralisée notamment dans les établissements d’enseignement, provoquant une baisse
brutale des achats de livres, au point que la possibilité même pour les auteurs de créer des
œuvres nouvelles et de les faire éditer correctement est aujourd’hui menacée.
En application de la loi du 11 mars 1957, il est interdit de reproduire intégralement ou
partiellement le présent ouvrage, sur quelque support que ce soit, sans autorisation de l’éditeur ou du Centre
Français d’Exploitation du Droit de Copie, 20, rue des Grands-Augustins, 75006 Paris.
© Groupe Eyrolles, 2003, 2005, 2006, 2008, 2010, ISBN : 978-2-212-12665-5
Ce livre est dédié à Christian Anèse et Philippe Demota qui m’ont donné
goût à la gestion de projet en me montrant sa dimension humaine autant
que technique.

V
Remerciements

Un livre est un projet d’équipe.


Merci à Jérémy, Vincent, Laurent, Frédéric, Céline, Léa, Brigitte, Michel,
Isabelle et Rose pour leur soutien quotidien.
Merci à Olivier Cordonnier, Gérard Bouron et Serge Cadenat pour leur
confiance toujours renouvelée.
Merci à RFI musique et notamment à Olivier Bourrassé qui m’a permis
d’utiliser notre travail commun pour illustrer certains chapitres.
Merci aux étudiants de l’HETIC et à Jean Christophe Beaux avec qui les
échanges sont toujours riches d’enseignements.
Merci enfin à tous les clients avec lesquels je travaille sur des projets
enthousiasmants et vis des expériences humaines enrichissantes.

VII
BordageTDM.fm Page IX Vendredi, 20. novembre 2009 2:13 14

Table des matières

Avant-propos ............................................................................ XIX


Quel est l’objectif de cet ouvrage ? ...................................... XIX
À qui s’adresse cet ouvrage ? ............................................... XX
Comment lire cet ouvrage ? ................................................ XX

Partie I - Les projets Web


Chapitre 1 - Qu’est-ce qu’un projet Web ?................................ 3
De la page HTML à l’application intégrée
au système d’information.................................................... 3
Notre définition des projets Web ....................................... 5
Les différents types de projets Web..................................... 6
Les sites catalogues............................................................ 6
Les sites marchands .......................................................... 11
Les sites institutionnels ..................................................... 16
Les sites de marques.......................................................... 22
Les sites communautaires.................................................. 25
Les intranets .................................................................... 27
Les portails d’entreprise .................................................... 31
Les enjeux des projets Web................................................. 37
Être rentable.................................................................... 37
Être pérenne .................................................................... 39
S’intégrer au système d’information ................................... 39
Les questions récurrentes .................................................... 40
Solution sur mesure ou progiciel ?...................................... 40

IX
BordageTDM.fm Page X Vendredi, 20. novembre 2009 2:13 14

Conduite de projet Web

PHP, Java ou .NET ? ...................................................... 42


Stockage des données : XML ou SGBDR ? ......................... 45
Pour aller plus loin ............................................................. 46
Ouvrages ......................................................................... 46
Sites ................................................................................ 47

Chapitre 2 - Les acteurs du projet.............................................. 49


L’équipe de l’entreprise....................................................... 50
Gestion de projet et relation avec les utilisateurs ................. 51
Profils fonctionnels ........................................................... 52
Les équipes prestataires ....................................................... 53
Gestion de projet et relation avec le client .......................... 54
Profils fonctionnels ........................................................... 55
Profils techniques ............................................................. 55
Profils artistiques ............................................................. 57
L’organisation générale ....................................................... 59
Définir clairement les rôles et les responsabilités.................. 60
Favoriser l’interlocuteur unique ........................................ 60
Ne pas sous-estimer la charge de travail ............................. 61
Intégrer les utilisateurs...................................................... 61
Piloter en fonction de la nature du projet........................... 62
Pour aller plus loin ............................................................. 64
Ouvrages ......................................................................... 64
Site ................................................................................. 64

Chapitre 3 - La dimension juridique du projet Web .................. 67


Les formalités préalables ..................................................... 67
Dépôt d’un nom de domaine............................................. 67
Déclaration préalable auprès de la CNIL .......................... 71
L’information à destination des internautes ........................ 73
Sur les données personnelles collectées ................................ 75
Sur l’identité de l’exploitant et la propriété du site .............. 76
Sur la publicité et la prospection en ligne............................ 78
Sur la publicité ................................................................ 78
Sur la prospection en ligne ................................................ 79

X
BordageTDM.fm Page XI Vendredi, 20. novembre 2009 2:13 14

Table des matières

Sur la responsabilité des cybermarchands............................ 80


Comment négocier des contrats Web ?............................... 82
Phase précontractuelle ...................................................... 82
Périmètre contractuel du projet ......................................... 83
Contrôle de conformité ..................................................... 84
Propriété et garantie des incorporels................................... 84
Obligation de moyens et obligation de résultat ................... 84
Limite de la responsabilité ................................................ 85
Cohérence et équilibre du contrat...................................... 86
Gestion d’un contrat multi-objet....................................... 87
Spécificités des contrats de réalisation
et d’hébergement de sites Web ........................................... 87
Les risques juridiques liés au référencement
et aux hyperliens .............................................................. 88
En conclusion..................................................................... 89
Pour aller plus loin ............................................................. 89
Ouvrages......................................................................... 89
Sites ................................................................................ 90
Chapitre 4 - Rassembler les facteurs clés de succès .................... 91
Construire un projet crédible.............................................. 91
Quantifier le projet .......................................................... 92
Se donner les moyens de vérifier l’atteinte des objectifs......... 98
Construire un projet motivant............................................ 99
Fédérer en interne............................................................ 100
Capitaliser l’expérience..................................................... 102
Parier sur les synergies ...................................................... 104
Pour aller plus loin ............................................................. 106
Ouvrages......................................................................... 106
Sites ................................................................................ 106

Partie II - La conduite des projets Web


Chapitre 5 - La stratégie............................................................ 111
Comprendre le marché ou le contexte ................................ 112
Le benchmark du marché ................................................. 113
L’audit de l’existant ......................................................... 118

XI
BordageTDM.fm Page XII Vendredi, 20. novembre 2009 2:13 14

Conduite de projet Web

Les tables rondes d’utilisateurs........................................... 126


La réunion de présentation et de validation ....................... 128
Définir l’offre ..................................................................... 130
Définir le positionnement ................................................. 131
Définir le marketing mix.................................................. 134
La réunion de présentation et de validation ....................... 143
Pour aller plus loin ............................................................. 144
Ouvrages ......................................................................... 144
Sites ................................................................................ 144
Chapitre 6 - Le business plan .................................................... 145
Le business plan dans le cadre du projet Web ..................... 145
Le business plan, un outil stratégique................................. 146
Qu’est-ce qu’un business plan réussi ? ................................ 146
Rédiger le business plan ...................................................... 147
La synthèse du business plan ............................................. 148
La demande, le marché .................................................... 148
La vision, la stratégie et les objectifs :
raisons d’être du projet ..................................................... 150
Les éléments financiers...................................................... 150
L’analyse des risques ......................................................... 151
L’organisation.................................................................. 152
La partie financière ............................................................. 152
Préparer et collecter l’information nécessaire....................... 153
Les documents de base ...................................................... 155
Pour aller plus loin ............................................................. 163
Ouvrages ......................................................................... 163
Sites ................................................................................ 163
Chapitre 7 - La faisabilité .......................................................... 165
Préciser le besoin ................................................................ 166
L’expression des besoins..................................................... 166
L’étude de l’existant ......................................................... 169
Le diagnostic ................................................................... 173
La réunion de présentation et de validation ....................... 174
Choisir des solutions........................................................... 175

XII
BordageTDM.fm Page XIII Vendredi, 20. novembre 2009 2:13 14

Table des matières

Présenter les solutions ....................................................... 176


Étudier les solutions ......................................................... 177
Choisir une solution ......................................................... 180
La réunion de présentation et de validation ....................... 181
Pour aller plus loin ............................................................. 182
Ouvrage .......................................................................... 182
Sites ................................................................................ 182
Chapitre 8 - L’appel d’offres ..................................................... 185
Choisir les prestataires ........................................................ 185
Les types de prestataires..................................................... 186
Combien de prestataires choisir ?....................................... 190
Constituer la short-list...................................................... 192
Le cahier des charges .......................................................... 194
Choix de la procédure ...................................................... 195
Rédaction du cahier des charges......................................... 197
Briefer les candidats............................................................ 199
Analyser les réponses........................................................... 202
Analyser la solution.......................................................... 202
Analyser le budget ............................................................ 204
Formaliser la synthèse....................................................... 205
Pour aller plus loin ............................................................. 206
Ouvrages......................................................................... 206
Chapitre 9 - La conception ....................................................... 211
Conception fonctionnelle ................................................... 212
Approche éditoriale .......................................................... 212
Approche par processus ..................................................... 216
Conception graphique........................................................ 224
Du concept board aux templates ...................................... 224
De la maquette HTML à la charte graphique ................... 229
Spécifications fonctionnelles............................................... 231
Conception technique ........................................................ 233
Architecture..................................................................... 234
Modélisation ................................................................... 236
Spécifications techniques .................................................... 241

XIII
BordageTDM.fm Page XIV Vendredi, 20. novembre 2009 2:13 14

Conduite de projet Web

Tests utilisateurs ................................................................. 242


Survol des principales techniques ....................................... 242
Les différents tests............................................................. 243
Pour aller plus loin ............................................................. 247
Ouvrages ......................................................................... 247
Sites ................................................................................ 248
Chapitre 10 - La réalisation ....................................................... 251
Production des contenus..................................................... 252
Contenus éditoriaux......................................................... 252
Contenus graphiques ........................................................ 255
Développements................................................................. 257
Lotir les développements ................................................... 257
Développer les lots ............................................................ 258
Réaliser les tests unitaires .................................................. 259
Intégrer les lots ................................................................. 259
Conduire les tests d’intégration.......................................... 259
Documentation .................................................................. 260
Rédiger le manuel d’exploitation ....................................... 260
Rédiger le manuel utilisateurs ........................................... 260
Reprise de l’existant ............................................................ 261
Préparer la reprise............................................................ 261
Réaliser la reprise ............................................................. 262
Hébergement...................................................................... 262
Les formes d’hébergement.................................................. 262
Quel hébergement choisir ? ............................................... 264
Pour aller plus loin ............................................................. 266
Ouvrage .......................................................................... 266
Sites ................................................................................ 266
Chapitre 11 - La mise en service ................................................ 267
Formation .......................................................................... 268
Préparer les formations ..................................................... 268
Réaliser les formations ...................................................... 271
Recette de l’application....................................................... 273
Survol des principaux tests réalisables ................................ 273

XIV
BordageTDM.fm Page XV Vendredi, 20. novembre 2009 2:13 14

Table des matières

Tests fonctionnels avec Selenium ....................................... 275


Réalisation de la recette .................................................... 288
Communication ................................................................. 290
Définir le plan de communication .................................... 290
Mettre en œuvre le plan de communication ....................... 293
Analyser les résultats de la campagne de communication ..... 295
Pour aller plus loin ............................................................. 297
Ouvrages......................................................................... 297
Sites ................................................................................ 297
Chapitre 12 - Référencement et positionnement....................... 299
Cahier des charges .............................................................. 300
Stratégie ............................................................................. 301
Identifier le contexte concurrentiel..................................... 304
Lister les moteurs ............................................................. 307
Trouver les bons mots-clés................................................. 309
Mise en œuvre.................................................................... 312
Optimiser le site............................................................... 312
Mettre à jour................................................................... 315
URL rewriting................................................................. 315
Indice de popularité et page rank ...................................... 316
Soumettre le site............................................................... 317
Pour aller plus loin ............................................................. 321
Ouvrages......................................................................... 321
Sites ................................................................................ 322
Chapitre 13 - Impact du Web 2.0 sur les projets Web .............. 323
Le Web 2.0 ........................................................................ 323
Une évolution sociale ....................................................... 323
Une évolution technique................................................... 324
Ce qui change dans les projets ............................................ 330
Projets individuels et projets d’entreprise ............................ 330
Co-design ........................................................................ 330
Choisir la bonne démarche ................................................. 331
Les démarches linéaires..................................................... 332
Les méthodes agiles........................................................... 332

XV
BordageTDM.fm Page XVI Vendredi, 20. novembre 2009 2:13 14

Conduite de projet Web

Quelle méthode choisir ? ................................................... 333


Limiter les risques juridiques liés au Web 2.0 ..................... 334
Nouveaux usages….......................................................... 334
…nouveaux risques.......................................................... 335
Pour aller plus loin ............................................................. 338
Ouvrages ......................................................................... 338
Sites ................................................................................ 338

Partie III - Études de cas


Chapitre 14 - Étude de cas 1 : site institutionnel ....................... 343
Le contexte ......................................................................... 345
Les enjeux........................................................................... 345
Impliquer les contributeurs dans la démarche..................... 345
Définir une nouvelle stratégie ........................................... 346
Sélectionner une solution cohérente.................................... 346
La solution ......................................................................... 346
L’analyse des logs pousse à revoir le périmètre ..................... 346
Les audits confirment les soupçons ..................................... 347
Les tables rondes internes font prendre conscience
de l’enjeu organisationnel ................................................. 348
Les bases d’une stratégie à long terme sont déterminées ........ 348
Une stratégie à court terme est définie................................ 350
Des tables rondes d’internautes valident le concept.............. 350
L’étude de l’existant est limitée, l’expression des besoins
est détaillée ...................................................................... 351
Le diagnostic est rapide..................................................... 351
L’étude des solutions est limitée à un scénario ..................... 351
Choix de la procédure et rédaction des cahiers des charges ... 353
Le bilan .............................................................................. 354
Chapitre 15 - Étude de cas 2, site B-to-B................................... 355
Le contexte ......................................................................... 357
Les enjeux........................................................................... 357
S’adapter aux processus métier pour garantir l’efficacité
de la solution ................................................................... 357
Budget et planning limités ................................................ 358

XVI
BordageTDM.fm Page XVII Vendredi, 20. novembre 2009 2:13 14

Table des matières

Intégrer les futurs animateurs de sorte qu’ils s’approprient


l’outil .............................................................................. 358
La solution ......................................................................... 358
Étape 1 : modélisation des processus................................... 358
Étape 2 : choix du mode de paiement, de la technologie
et de l’hébergeur............................................................... 359
Étape 3 : constitution de l’équipe de développement............ 360
Étape 4 : développements.................................................. 360
Étape 5 : lancement ......................................................... 360
Le bilan .............................................................................. 361
Chapitre 16 - Étude de cas 3, portail d’entreprise ..................... 363
Le contexte......................................................................... 365
Les enjeux........................................................................... 366
Créer un outil simple et accessible...................................... 366
Remotiver les utilisateurs .................................................. 366
Apporter une solution pragmatique à des besoins
quotidiens ....................................................................... 366
Fédérer autour d’une même vision de l’entreprise ............... 366
La solution ......................................................................... 367
Étape 1 : expression des besoins et étude de l’existant........... 367
Étape 2 : profils, sécurité, contenu, communication ............ 369
Étape 3 : création, test et mise en ligne du pilote ................ 370
Étape 4 : spécifications fonctionnelles, faisabilité, cahier
des charges et appel d’offres ............................................... 371
Étape 5 : développement, documentation et lancement ....... 372
Le bilan .............................................................................. 372
Chapitre 17 - Étude de cas 4, site e-commerce B to C............... 375
Le contexte......................................................................... 375
Les enjeux........................................................................... 376
Budget et plannings serrés ................................................. 376
Indépendance .................................................................. 376
Évolutivité ...................................................................... 377
La solution ......................................................................... 377
Étape 1 : choix de l’outil (T + 1 semaine).......................... 377
Étape 2 : conception (T + 2 semaines)............................... 378

XVII
BordageTDM.fm Page XVIII Vendredi, 20. novembre 2009 2:13 14

Conduite de projet Web

Étape 3 : réalisation (T + 4 semaines) ............................... 379


Étape 4 : mise en œuvre (T + 5 semaines).......................... 379
Le bilan .............................................................................. 380
Chapitre 18 - Étude de cas 5, générateur d’intranets ................. 381
Le contexte ......................................................................... 381
Les enjeux........................................................................... 382
Autonomie de création, de personnalisation
et de supervision............................................................... 382
Facilité d’extension des fonctionnalités............................... 382
Adoption par les utilisateurs.............................................. 382
Adoption par la DSI ........................................................ 383
La solution ......................................................................... 383
Étape 1 : AMOA préalable............................................... 383
Étape 2 : choix de la solution ............................................ 383
Étape 3 : réalisation ......................................................... 384
Étape 4 : mise en œuvre et pilotage.................................... 384
Le bilan .............................................................................. 384
Annexe 1 - Contenu du CD-Rom.............................................. 387
Le dossier MBP .................................................................. 387
Le dossier fichiers ............................................................... 387
Suivi............................................................................... 388
Stratégie .......................................................................... 391
Business plan ................................................................... 403
Faisabilité ....................................................................... 405
Appel d’offres ................................................................... 410
Conception ...................................................................... 413
Réalisation ...................................................................... 419
Mise en service................................................................. 421
Annexe 2 - Glossaire.................................................................. 423

Index ......................................................................................... 427

XVIII
Avant-propos

Ce sont mes clients qui m’ont poussé à écrire ce livre. Ils attachent beau-
coup d’importance à la qualité de la gestion de projet et recherchent, en
permanence, l’équilibre entre des méthodologies trop lourdes et une
absence totale de méthode.
Étant de culture marketing, je me suis intéressé aux méthodes « informati-
ques » pour mieux servir mes clients. En parallèle, la gestion de nombreux
projets et d’équipes pluridisciplinaires m’a apporté une source d’expé-
riences riches et variées.
Ce livre concrétise la rencontre de ces deux cultures et montre comment
elles se complètent au quotidien pour créer des projets Web efficaces.

Quel est l’objectif de cet ouvrage ?

L’objectif de cet ouvrage est de synthétiser les principales pratiques rencon-


trées sur le terrain et ayant donné satisfaction en matière de projet Web.
Son ambition est d’apporter une vision globale tout en proposant des solu-
tions concrètes et opérationnelles à chaque étape.
Il ne constitue cependant pas un précis de conduite de projet ou de
méthode informatique. Ainsi, certaines méthodes et certains concepts ont
été simplifiés pour en faciliter la compréhension. Des ressources (sites,

XIX
Conduite de projet Web

ouvrages, etc.) sont présentées en fin de chaque chapitre pour les


lecteurs désireux d’approfondir un sujet précis.

À qui s’adresse cet ouvrage ?

Cet ouvrage s’adresse à tous les acteurs du projet Web, qu’ils


travaillent en entreprise ou chez des prestataires et en particulier :
• aux dirigeants de petites et moyennes entreprises qui souhaitent
comprendre les enjeux pour maîtriser leur projet ;
• aux chefs de produits et de marques qui sont de plus en plus
amenés à intégrer des solutions Web avancées dans leur plan
marketing ;
• aux responsables de communication interne ou externe ;
• aux chefs de projet Web qui pourront s’appuyer dessus pour
préparer et gérer leur projet. Ils apprécieront particulièrement
les modèles de documents, les check-lists et les grilles d’analyse ;
• aux directeurs de projet qui y trouveront un pense-bête pratique
autant qu’une base pouvant servir d’outil de sensibilisation ;
• aux étudiants qui recherchent une synthèse des différentes étapes
d’un projet.

Comment lire cet ouvrage ?

Cet ouvrage a été pensé comme un guide pratique ayant pour voca-
tion d’accompagner le lecteur sur la totalité d’un projet étape par
étape.
Il peut être utilisé de deux façons : en amont du projet pour en
préparer le déroulement et rassembler les facteurs clés de succès ou
pendant le projet pour gérer au mieux chaque étape et en garantir la
réussite, notamment en préparant la réception de chaque livrable.
La première partie pose les bases nécessaires à une bonne compré-
hension de la problématique :
• Le chapitre 1 donne une définition de chaque type de projet
Web et décrit les dernières évolutions du Web (Web 2.0).
• Le chapitre 2 présente les acteurs et les grands principes d’orga-
nisation.

XX
Avant-propos

• Le chapitre 3 expose les principaux aspects juridiques du projet


Web.
• Le chapitre 4 explique comment rassembler les principaux fac-
teurs clés de succès.
La deuxième partie expose, étape par étape, la mise en œuvre du
projet Web :
• Le chapitre 5 est consacré à la stratégie Web. Il explique com-
ment comprendre le marché et définir son offre.
• Le chapitre 6 évoque la construction du business plan et le suivi
du budget au quotidien.
• Le chapitre 7 détaille la démarche de l’étude de faisabilité et
explique notamment comment préciser le besoin et trouver des
pistes de solutions.
• Le chapitre 8 guide le lecteur tout au long du processus d’appel
d’offres, du choix des prestataires à l’analyse des réponses en pas-
sant par le cahier des charges et le brief.
• Le chapitre 9 couvre les principales étapes de la conception, tant
fonctionnelle et technique que graphique.
• Le chapitre 10 est consacré à la réalisation du projet de la pro-
duction du contenu à la recette en passant par la reprise de
l’existant, les développements et la documentation.
• Le chapitre 11 fait le point sur les actions à mener lors du lance-
ment du projet : hébergement, formation et communication.
• Le chapitre 12 détaille la démarche la plus efficace pour réussir
son référencement et se positionner dans les premiers résultats
des moteurs de recherche.
• Le chapitre 13.
La troisième partie est consacrée à cinq études de cas :
• La première (chapitre 14) couvre la stratégie, la faisabilité et
l’appel d’offres d’un site institutionnel.
• La deuxième (chapitre 15) s’intéresse à la stratégie, la concep-
tion, la réalisation et le lancement d’un site B-to-B.
• La troisième (chapitre 16) zoome sur la stratégie, la faisabilité,
l’appel d’offres, la conception et la réalisation d’un portail
d’entreprise.
• La quatrième (chapitre 17) étudie la faisabilité, la conception, la
réalisation et la mise en œuvre d’un site commercial B to C.

XXI
Conduite de projet Web

• Enfin, la cinquième étude de cas (chapitre 18) porte sur l’expres-


sion du besoin, la faisabilité, la conception, la réalisation et la
mise en œuvre d’un générateur d’intranet.

Guide de lecture

PROFIL BESOINS CHAPITRES À LIRE

Dirigeants PME/PMI Comprendre les enjeux 1, 4, 5,12


Maîtriser la dimension 6
financière du projet
Maîtriser la dimension 3
juridique du projet
Chefs de produits Comprendre la démarche… 1, 2, 3, 13, 14, 15 , 16,
ou de marques 17, 18
… pour pouvoir encadrer 5, 6, 7, 8, 9, 10, 11,12
les prestataires
Chefs de projet Web Préparer et gérer le projet 5, 6, 7, 8, 9, 10, 11,12
Voir la méthode en application 13, 14, 15 , 16, 17, 18
Directeurs de projet Pense-bête, sensibilisation 5, 6, 7, 8, 9, 10, 11,12
Étudiants Disposer d’une vue synthétique 5, 6, 7, 8, 9, 10
Voir la méthode en application 13, 14, 15 , 16, 17, 18

XXII
PARTIE I
Les projets Web
Chapitre 1

Qu’est-ce qu’un
projet Web ?

Un projet Web est avant tout un outil qui concourt à l’atteinte d’objectifs
stratégiques. Il participe à la compétitivité de l’entreprise en répondant effi-
cacement aux besoins des utilisateurs. Cependant, la nature des projets
Web est difficile à cerner car leurs périmètres fonctionnel et technique
évoluent sans cesse. Au départ simples pages HTML, ce sont aujourd’hui
de véritables applications interfacées avec le système d’information de
l’entreprise.
 Système
Les pages suivantes précisent notre vision du projet Web au travers d’une d’information :
définition générale, de la description des principaux types de projets ensemble des
rencontrés sur le terrain et de l’identification des nouveaux enjeux. Enfin, éléments qui contri-
buent au traitement
le chapitre se termine par l’évocation des grandes questions qui se posent à et à la circulation de
chaque fois et donne des pistes de bonnes pratiques. l’information dans
l’entreprise (base de
données, applica-
De la page HTML à l’application intégrée tions, procédures,
documentation,
au système d’information1 etc.), y compris le
système informati-
que proprement dit
(unité centrale de
La nature, les objectifs et les acteurs des projets Web ont considérablement traitement, périphé-
évolué entre l’apparition des premiers sites en 1996 et l’arrivée à maturité riques, système
du marché. d’exploitation, etc.).

3
Partie I – Les projets Web

Figure 1-1
Des sites de marques aux portails d’entreprises, évolution des projets Web
Les objectifs, les acteurs et les technologies ont considérablement évolué en
quelques années.

Les premiers projets répondaient à des objectifs simples : vendre des


produits, communiquer une image positive auprès des clients,
informer les collaborateurs de l’entreprise… La technologie et
l’infrastructure étaient des contraintes fortes. La bande passante
était comptée et l’ergonomie avait force de loi. Les sites Web ressem-
blaient à des plaquettes composées de pages HTML. Ils étaient
réalisés par les services communication. Au même moment, les
premiers intranets apparaissaient sous l’impulsion des services infor-
matiques.
Puis sont apparus les sites dynamiques reposant sur des serveurs
 Serveurs d’applications : d’applications1 et permettant de dissocier le contenu du contenant.
logiciels assemblant des L’utilisation de bases de données et de moteurs de recherche s’est
données et des applications généralisée, apportant un meilleur service aux utilisateurs mais
dans le but de les mettre
à la disposition des utilisa-
surtout une plus grande souplesse et plus d’efficacité pour l’entre-
teurs via un client Web. prise. La gestion du projet a commencé à se répartir entre la direc-
tion de la communication et la direction informatique.

4
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Les sites marchands, les extranets fournisseurs et autres places de


marchés ont complexifié encore la donne. Recourant à de nouveaux
concepts et standards (XML, services Web1, BPM2, architectures  Service Web : un service
techniques multipliant les couches d’abstractions…) ils ont fait Web est un logiciel qui
réalise à la demande une
basculer les projets Web dans le monde de l’informatique applica- tâche bien définie et qui
tive loin des liens hypertextes et des pages HTML. Depuis cette est accessible via Internet.
époque, les projets sont pilotés par les directions informatiques, Chaque service Web est
commerciales et générales, celles-ci faisant éventuellement appel à la défini au moyen du langage
WSDL (Web Service
direction de la communication pour valider la charte graphique. Definition Language) et
Aujourd’hui, le projet Web est si intimement mêlé au système communique via le
d’information qu’il en devient souvent une extension. protocole SOAP (Simple
Object Access Protocol). Les
services Web enregistrés

Notre définition des projets Web sont localisés par l’intermé-


diaire d’un annuaire UDDI
(Universal Discovery Defini-
tion Integration).
Le parti pris de cet ouvrage est de considérer que « le projet Web »
désigne un projet qui possède au moins quatre caractéristiques :  BPM : Business Process
Management. Le BPM
• Il est destiné à tous les utilisateurs d’un navigateur (internautes, est une analyse et une
extranautes). Les utilisateurs d’assistants mobiles (PDA, télépho- modélisation des processus
nes portables…) font partie de cette catégorie. de l’entreprise dans le but
d’optimiser la circulation
• Il utilise des technologies Internet (HTML, PHP, .NET J2EE, et l’exploitation
HTTP, SGBD/R…). de l’information.
• Il est interfacé avec le système d’information mais ne constitue
pas une fonction centrale de celui-ci.
• Son principal facteur clé de succès est lié à Internet ou à l’utilisa-
tion des technologies Web.
Cela recoupe notamment les projets de :
• site catalogue ;
• site marchand ;
• site institutionnel ;
• site de marques ;
• site communautaire ;
• d’intranet ;
• de portail d’entreprise.

5
Partie I – Les projets Web

Les différents types de projets Web

Figure 1-2
Positionnement des différents projets Web

Il n’y a pas un mais des projets Web. On peut même dire qu’il y a
autant de projets que d’entreprises, puisque chacun répond à des
besoins spécifiques, dans un environnement et avec des contraintes
particulières.
Le but de cette partie est de dresser une typologie des projets les plus
courants et, pour chacun d’eux :
• d’identifier les éléments fonctionnels les plus importants ;
• de proposer un échantillon des principales solutions packagées y
répondant ;
• d’évoquer certains points clés de conduite du projet qui nous
semblent importants.

Les sites catalogues


Les sites catalogues présentent la gamme de produits et essayent de
créer un contexte favorable de sorte qu’en situation d’achat, l’inter-
naute préférera le produit de l’entreprise à ceux des concurrents.

6
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Figure 1-3
http://www.audi.com

Repère : les cinq objectifs de l’internaute


1. Évaluer des produits et services.
2. Choisir des produits et les acheter.
3. Obtenir de l’aide.
4. Donner un feedback.
5. Surveiller des produits ou services.
Source : Jodie Dalgleish, Customer effective Web sites (éditions Ft.com).

Objectifs et moyens
Les sites catalogues poursuivent deux objectifs qui correspondent à
deux étapes du processus d’achat. Dans un premier temps, il s’agit
de faire découvrir la gamme dans un contexte favorable. La généra-
tion d’un trafic qualifié, une interface1 ludique (un configurateur  Interface : ensemble des
plutôt qu’une recherche multicritère, une approche par besoins moyens permettant à l’utili-
sateur d’interagir avec un
plutôt que par produits…) et un design restituant bien l’univers de système informatique,
marque sont des facteurs clés de succès. Dans un deuxième temps, comme les pages HTML, les
il faut convaincre le client en phase de réflexion que le produit de listes déroulantes, les cases
à cocher, les pop-ups...
l’entreprise est le plus adapté (processus de réassurance). Pour cela,
le site fournit une information riche, à jour et facilement accessible.
Dans certains cas, il propose, en plus, des services à forte valeur

7
Partie I – Les projets Web

ajoutée tels que des prises de rendez-vous, des simulations, des


comparatifs avec la concurrence...
L’objectif d’un catalogue est aussi de mutualiser les coûts de déploie-
 Place de marché : ment en dehors du site de l’entreprise, sur des places de marché1, des
site d’intermédiation dont le comparateurs de prix ou sur d’autres supports tels que les catalogues
but est de mettre en relation papier, des CD-Rom…
des acheteurs et des fournis-
seurs. La base d’une place Repère : de 20 000 à 200 000 euros pour un catalogue
de marché est le catalogue.
Les catalogues « stand-alone » comme Exsyde Pro sont facturés à partir de 20 000 euros. Mais
pour disposer d’un référentiel unique, d’un catalogue papier, d’une version CD-Rom et d’un site
Internet, le budget est plus proche des 100 à 200 000 euros avec une intégration supérieure à
6 mois.
Source : 01net, juin 2005, http://www.01net.com/article/282687.html

Le cœur fonctionnel d’un site catalogue est, bien entendu, le cata-


 Référentiel sémantique :
logue ! Celui-ci repose sur un référentiel sémantique2 extrêmement
document qui définit le sens
des mots et groupes de mots fin, commun à l’ensemble de l’entreprise. Chaque fiche produit
dans un contexte particulier classée dans ce référentiel est composée de quatre types d’informa-
(métier, langue, etc.). tions : les informations de gestion (référence produit, coût de
Il constitue la base d’une production ou d’achat, etc.), les informations descriptives (taille,
taxonomie.
poids, couleur, fonctionnalités, descriptif, visuel…), les informa-
tions commerciales (prix, remises, garantie…), les informations
 Ranking : le ranking marketing (ranking3, produits complémentaires, etc.).
est l’attribution d’un rang
à des items en fonction de
Plus l’information est atomisée et plus l’adaptabilité et les possibi-
règles prédéfinies (top 50 lités de dialogue avec les tiers sont importantes. De fait, le catalogue
des meilleures ventes fondé doit être en mesure d’intégrer des données en provenance du
sur le volume de produits système d’information de l’entreprise et, à l’inverse, de communi-
vendus par exemple).
quer vers son ERP ou vers d’autres acteurs telles les places de
marché.
Autour du catalogue s’agrègent des fonctionnalités complémen-
 Progiciel : logiciel taires comme la publication multicanal, la gestion de contenu et la
applicatif presque toujours gestion des e-mails entrants.
spécialisé dans un métier
(logistique, comptabilité/ Les principales solutions packagées, pour développer des sites cata-
finance…). logues, se trouvent en mode ASP chez les éditeurs de suites de
 Open Source : logiciel
gestion commerciale et sous forme de progiciels4. On trouve aussi
dont le code source est de nombreuses briques fonctionnelles dans le monde Open Source 5,
accessible et peut être notamment en PHP.
exploité, adapté, amélioré
sous certaines conditions Question clé : solution packagée ou développements sur mesure ?
(en général définies dans Une solution packagée permet de limiter drastiquement la conception et les développements et,
une licence de type GPL).
par la même occasion, de réduire les délais de mise en œuvre. Ce faisant, elle atténue les diffi-
cultés de gestion de projet. La seule phase difficile étant alors le choix de la solution.

8
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Il peut s’agir d’un progiciel sous licence, livré seul ou avec une offre de service (installation, para-
métrage, conseil…). Le même progiciel peut être proposé en ASP (Application Service Provider).
Il peut aussi s’agir de briques fonctionnelles seules ou proposées avec, par exemple, un serveur
d’applications. Le travail consiste alors à adapter la présentation et à développer les fonctions non
prévues.

Les avantages et inconvénients des solutions packagées et des développements sur mesure sont
détaillés ci-après dans la section « Solution sur mesure ou Progiciel ? ».

Tableau 1-1
Quelques solutions packagées pour créer un catalogue

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE


Actinic Actinic Catalog http://www. PME Catalogue
actinic.com
Catalogic Catalogic Préref http://www. PME/ Catalogue
catalogic.info Grand
compte
Requisite eMerge Content http://www. Grand Catalogue
Management System requisite.com compte
Microsoft Microsoft Commerce http://www. PME Catalogue
Server 2007 microsoft.com
Varien Magento http://www. PME Catalogue
magentocom- Grand
merce.com compte
Drupal Ubercart http://drupal.org/ PME Catalogue
project/ubercart Grand
compte

Points clés du projet


« Le premier défi lorsque l’on souhaite se lancer dans le commerce
électronique, c’est la constitution d’un catalogue produits efficace »
explique Roland Tripard, directeur marketing de WStore (Source :
Décision micro et réseaux, janvier 2002). Ce défi n’est pas toujours
simple à relever. Le projet doit donc être abordé différemment en
fonction de deux critères : la courbe d’apprentissage de l’entreprise
porteuse du projet et le niveau stratégique du projet. Pour carica-
turer, l’entreprise se trouve dans deux cas de figure.
Dans le premier cas, le projet est nouveau et n’est pas stratégique
(le catalogue ne constitue pas le référentiel de l’entreprise). Une
méthodologie centrée sur l’apprentissage (méthode itérative, essai/

9
Partie I – Les projets Web

erreur, etc.) et une prise de risque limitée sont alors fortement


recommandées.
Elle peut être facilement mise en œuvre si l’on s’appuie sur les
nombreuses solutions proposées en mode ASP. Les risques sont
limités car ces solutions sont peu coûteuses et ne nécessitent pas la
mise en place d’une infrastructure humaine et matérielle dédiée.
L’entreprise peut donc se désengager facilement en cas de difficultés.
Pour les PME, une autre solution consiste à ajouter un module
« ebusiness » – véritable boutique clé en main – à la suite de gestion
commerciale de l’entreprise. Le coût est limité, l’offre est packagée
(dépôt et réservation du nom de domaine, hébergement, etc.) et le
catalogue est ainsi intégré au système d’information de l’entreprise.
En suivant l’une de ces méthodes, l’entreprise peut se faire une idée
juste de l’intérêt de la démarche avant de passer à un projet plus
ambitieux.
Dans le second cas, l’entreprise est déjà dans la situation décrite
précédemment. Elle souhaite investir dans un projet stratégique,
c’est-à-dire placer le catalogue au cœur de son organisation. Le
recours à une démarche plus « construite » sera alors nécessaire,
notamment si des fonctions d’intégration et d’échange d’informa-
tions avec des partenaires sont prévues. Il s’agira, dans un premier
temps, de mener une étude de faisabilité pour identifier la meilleure
solution. Si un progiciel est sélectionné, il devra être paramétré.
Dans le cas contraire, des développements spécifiques devront être
réalisés. En général, l’existence ou non d’offres sectorielles permet de
trancher entre ces deux options.
Dans tous les cas, la nature et le nombre de références sont à prendre
en compte avant de se lancer dans un projet de catalogue. En effet,
les utilisateurs étant très exigeants, ils ne font confiance qu’aux
fiches produit très riches. Or il n’est pas toujours possible de fournir
une centaine de critères (voire plus !) pour toutes les fiches. Les
coûts peuvent vite devenir prohibitifs, à tel point que le recours à un
prestataire spécialisé est parfois nécessaire. Sans compter la mise à
jour régulière…
Dans ces conditions, réduire le périmètre du catalogue vaut souvent
mieux que de proposer des fiches contenant des informations insuf-
fisantes ou inexactes. Il faut donc, en amont du projet, sélectionner
avec soin les informations les plus importantes en se réservant cepen-
dant la possibilité d’ajouter plus tard des indications secondaires.

10
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Check-list
Avant de lancer le projet, il est important de :
– mener une étude d’opportunité pour déterminer le rôle du catalogue (référentiel de l’entreprise
et/ou nouveau canal de distribution et/ou outil d’échange avec place de marché, etc.) ;
– se renseigner sur les standards techniques en vigueur et à venir (place de marché, fournisseurs,
etc.) ;
– ne pas oublier les aspects réglementaires (mentions légales obligatoires, conditions particulières
de vente, etc.).

Les sites marchands


Contrairement aux sites catalogues, les sites marchands sont tran-
sactionnels : ils permettent aux internautes non seulement de
consulter un catalogue de produits, mais aussi de commander et de
payer en ligne. Par ailleurs, l’organisation nécessaire au fonctionne-
ment d’un site marchand est beaucoup plus complexe que celle d’un
site catalogue, notamment du fait de l’importance de la logistique.

Figure 1-4
http://www.dell.com
Dell vend plus de six millions de dollars de produits en ligne et réalise des
marges supérieures de 30 % à celles des produits qui ne sont pas achetés en
libre service.
Source : Patricia B. Seybold, Clients.com (éditions Dunod).

11
Partie I – Les projets Web

Figure 1-5
http://www.wellsfargo.com
Wells Fargo a divisé par deux le coût de ses transactions et a augmenté
le niveau moyen des soldes de ses clients.
Source : Patricia B. Seybold, Clients.com (éditions Dunod).

Repère : les cinq phases du e-business selon Patricia B. Seybold :


1. Fournir des informations sur l’entreprise et les produits.
2. Apporter une assistance au client et permettre des interactions.
3. Gérer les transactions électroniques (site marchand première génération).
4. Personnaliser les interactions avec le client (site marchand deuxième génération).
5. Favoriser un sentiment de communauté.
Source : Patricia B. Seybold, Clients.com (éditions Dunod).

Objectifs et moyens
L’objectif des sites marchands est évidemment de vendre – c’est-à-
dire de transformer le visiteur en acheteur – mais aussi et surtout de
fidéliser le plus possible les clients de manière à rentabiliser les coûts
d’acquisition. Lors du processus d’achat, l’ergonomie joue donc un
rôle fondamental. En effet, contrairement aux sites catalogues, ce
qui compte, c’est de trouver facilement le produit recherché, de
passer commande puis de payer. L’ambiance n’est pas ludique, elle
est sérieuse et rassurante.

12
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Dans un deuxième temps, pour fidéliser l’internaute, il est néces-  Cross-selling :


saire de lui montrer que l’on tient à lui en le reconnaissant et en en français, « vente croi-
sée ». Stratégie qui vise à
lui proposant des produits a priori adaptés à ses besoins. Cela augmenter les volumes de
implique de mettre en place une politique de fidélisation repo- ventes en suggérant des
sant sur une gestion rigoureuse de la relation client. Des achats complémentaires à
méthodes de cross-selling 1 telles que le filtrage collaboratif 2 l’achat principal (une assu-
rance ou un crédit lors de
peuvent aussi être utilisées pour augmenter le panier moyen des l’achat d’une voiture, des
clients. Un des exemples les plus connus est le fameux « les autres lunettes de soleil ou des
clients qui ont acheté ce produit ont aussi acheté… » d’Amazon. produits solaires lors de
l’achat d’un drap de bain...).
Repère : le panier moyen est de 88,65 € en 2005  Filtrage collaboratif :
technique qui vise à inciter
Avec 8,7 milliards de chiffre d’affaires réalisé auprès de 13,4 millions de cyber consommateurs à l’achat et à augmenter les
français, le chiffre d’affaires du commerce électronique a augmenté de 53 % entre 2004 et volumes de vente en suggé-
2005. Le panier moyen des sites marchands français avoisine toujours les 86 € mais le nombre rant des achats complémen-
taires (« ceux qui ont acheté
de transactions a augmenté de 65 %.
ce livre ont aussi acheté… »).
Source : Journal du Net, janvier 2006, http://www.journaldunet.com/0601/060125fevad-ecom.shtml
 Data mining : discipline
Les sites marchands reprennent toutes les fonctionnalités des sites qui consiste à faire des statis-
tiques avec l’outil informati-
catalogues auxquelles ils ajoutent la possibilité, pour l’internaute,
que, les logiciels de datami-
de commander et de payer en ligne. Le cœur fonctionnel d’un site ning permettent d’extraire
marchand se situe donc, outre le catalogue, autour de la transac- des tendances, d’isoler des
tion. Il est constitué de la gestion des sessions, du panier, des populations de données, etc.
dans une base de données.
commandes, des utilisateurs, du paiement et de fonctions
 Personnalisation : la per-
d’import et d’export de données, notamment vers les logiciels de
sonnalisation est une straté-
routage (UPS, Colissimo). À ces fonctionnalités s’ajoutent la gie qui consiste à personnali-
gestion des promotions, du contenu, des e-mails entrants et ser la relation avec le client
sortants ainsi que des fonctions de type GRC (gestion de la rela- de manière à mieux le satis-
faire et, par là, à le fidéliser.
tion client) : filtrage collaboratif, data mining3, personnalisation4,
Il existe deux types de person-
tarification selon le statut, chèque et liste de cadeaux, gestion de nalisation : implicite et expli-
programmes de fidélisation… cite. Dans le premier cas, elle
est réalisée sans que l’utilisa-
De plus, pour être efficace, un site marchand doit puiser dans le teur ne le sache. Dans le
système d’information des données telles que l’état des stocks, le deuxième cas, l’utilisateur est
temps moyen de livraison du produit, les tarifs de chaque client... informé et participe au pro-
Sans ces informations, la vente est quasiment impossible car cessus de personnalisation.
l’utilisateur ne dispose pas des repères nécessaires à sa décision.  ERP : Enterprise Resource
Planning. PGI en français
Pour que ces données soient justes, le site doit à son tour informer (progiciel de gestion inté-
le système de gestion des stocks (ou la suite commerciale ou gré). Ce logiciel gère
l’ERP5) de l’achat de tel ou tel produit. La problématique d’inté- l’ensemble des processus
gration de données est donc un élément clé du projet. d’une entreprise : ressour-
ces humaines, comptabilité/
Les principales solutions packagées proposent la plupart des fonc- finance, aide à la décision,
tionnalités citées précédemment. Ce sont majoritairement des vente, approvisionnement…

13
Partie I – Les projets Web

extensions de suites de gestion commerciale ou d’ERP et des progi-


ciels sous licence ou en ASP. Dans le cas de développements sur
mesure, de nombreuses fonctionnalités sont disponibles en Open
 EAI : Enterprise Source (catalogue, panier, systèmes complets). Ajoutons que le
Application Integration. recours à des outils d’EAI1 et d’EII2 est parfois nécessaire.
Outils permettant l’inté-
gration de l’ensemble
des applications d’une entre- Tableau 1-2
prise. Le but est de permettre Quelques solutions packagées pour créer un site marchand
le dialogue entre les
applications (via des ÉDITEUR PRODUIT URL CIBLE CATÉGORIE
« connecteurs »), sans pour CyberShopASP CyberShopASP http://www. PME ASP*
autant les redévelopper. cybershopasp.com

 EII : Enterprise PowerBoutique PowerBoutique Expert http://www. PME ASP*


Information Integration. powerboutique.com
Outils permettant l’inté- Digifactory Digicommerce http://www. PME ASP*
gration de l’ensemble digifactory.fr
des informations
Access Caméléon Commerce http://www. Grand CRM**
d’une entreprise.
Commerce Portal access-commerce.com compte
Pivotal Pivotal Interactive http://www. Grand CRM**
Sellingô pivotalcrm.com compte
Selligent SELLIGENT e-CRM http://www. Grand CRM**
selligent.com compte
Sage Sage e-commerce 100 http://www.sage.fr PME SGC***
Microsoft Microsoft Commerce http://www. PME/ progiciel
Server 2007 microsoft.com Grand
compte
Intershop Enfinity Suite 6 http://www. PME/ progiciel
intershop.com Grand
compte
IBM IBM WebSphere http://www.ibm.com PME/ progiciel
Commerce Suite Grand
compte
Actinic Actinic Business http://www.actinic.com PME/ progiciel
Grand
compte
Microsoft Microsoft Commerce http://www. PME Catalogue
Server 2007 microsoft.com
Magento Varien http://www. PME Catalogue
magentocom- Grand
merce.com compte
Drupal Ubercart http://drupal.org/ PME Catalogue
project/ubercart Grand
compte

* ASP = Application service provider, ** CRM = Customer Relationship Management (GRC, en


français), *** SGC = suite de gestion commerciale, **** ERP = Enterprise Resource Planning.

14
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Points clés du projet


Dans le cas d’une boutique à large audience (vente de matériel
informatique, de biens culturels…), la démarche est centrée autour
des futurs clients. La contrainte essentielle est la souplesse de la
solution retenue. Celle-ci doit pouvoir s’adapter en profondeur de
façon à « coller » à l’expression des besoins et aux attentes des utili-
sateurs. L’ergonomie doit en particulier être très travaillée :
séquence de recherche des produits, séquence de commande,
séquence de paiement, séquence de suivi des commandes… Les
étapes clés, outre la stratégie, sont la conception fonctionnelle, la
conception ergonomique et graphique ainsi que le test de la
maquette fonctionnelle.
Les futurs utilisateurs doivent y être associés et il est prudent de
réaliser autant d’itérations que nécessaire.
Dans le cas d’un site à audience professionnelle (fournitures de
bureau par exemple), la démarche est centrée sur la personnalisation
de la relation. La contrainte essentielle est donc la capacité de
dialogue entre le site et le système d’information de l’entreprise. Le
recours aux modules « e-business » des suites de gestion commerciale
ou des ERP peut faciliter le travail même si ces solutions imposent en
contrepartie une grande rigidité. L’ergonomie, notamment la
cinématique1 et l’interface front-office2, est en général peu modi-  Cinématique :
fiable. Les étapes clés sont l’étude de faisabilité – plus particulière- enchaînement de l’ensemble
des écrans constitutifs
ment l’expression des besoins et le choix des critères de sélection de la d’un processus ou sous
solution – puis le paramétrage et les développements spécifiques. Si processus.
un progiciel est retenu, il sera alors intéressant, en phase de choix de
 Front-office : terme
solution, de faire réaliser des prototypes aux différents fournisseurs désignant tous les program-
afin de vérifier l’implémentation concrète de chaque fonctionnalité. mes en interaction avec
Certaines contraintes supplémentaires peuvent singulièrement les clients. En opposition
avec le « back-office »,
complexifier le projet. D’une part, la taille, l’organisation et la répar- ensemble des programmes
tition géographique de l’entreprise jouent un rôle important : un non publics.
catalogue, des stocks et des tarifs spécifiques à trois sites (l’un en
France, l’un en zone euro, l’autre en Asie par exemple) poseront plus
de problèmes que pour une PME monosite ! Il sera, par exemple,
 Reprise de l’existant :
nécessaire de gérer des langues (donc des contenus traduits), des ce processus consiste à
devises et des fiches produit pouvant être différentes selon la zone. récupérer des données
D’autre part, la reprise de l’existant3 sera plus simple si l’entreprise existantes, éventuellement
à les modifier, puis à les
a mené un premier projet de catalogue ou s’appuie sur un ERP ou réinjecter dans la nouvelle
une suite de gestion commerciale. application.

15
Partie I – Les projets Web

Check-list
Avant de lancer le projet, il faut :
– évaluer l’adéquation des produits avec une vente en ligne ;
– évaluer l’acceptabilité du projet par la force de vente (En quoi le projet l’aide ? N’y a-t-il pas de
cannibalisme par rapport au reste de l’activité ?…) ;
– vérifier qu’un groupe d’utilisateurs sera impliqué tout au long du projet ;
– ne pas oublier les aspects réglementaires.

Les sites institutionnels


Les sites institutionnels sont informatifs. Ils présentent l’entreprise,
sa vision et ses valeurs, informent sur l’activité et les résultats finan-
ciers, font découvrir les principales marques et produits, proposent
des opportunités de carrière…

Figure 1-6
http://www.nestle.fr

Objectifs et moyens
Les sites institutionnels poursuivent, en général, quatre objectifs
principaux. Le premier est de participer au développement et au
renforcement de l’image de l’entreprise. À ce titre, la qualité de
l’interface ergonomique et graphique, mais aussi et surtout la
qualité des contenus (style, pertinence, etc.) jouent un rôle prépon-
dérant. Cela sous-entend des moyens de production et de mise à
jour en rapport avec l’intérêt porté à l’image de l’entreprise.

16
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Le deuxième objectif est de tisser une relation privilégiée avec les


journalistes de manière à influencer leur vision de l’entreprise et à
préparer les éventuelles crises. Pour ce faire, des contenus et des
services spécifiquement adaptés à leurs besoins doivent être mis en
place dans un espace réservé : contact dédié et disponible, commu-
niqués pouvant être copiés/collés, photos en haute définition,
schémas dans un format vectoriel, contenus périphériques (histo-
rique, chiffres clés, vision, biographies…). Il faut aussi penser à la
mise en place d’une relation non intrusive, c’est-à-dire qui « ne force
pas la main » au client. Elle peut se traduire par des invitations
disponibles en ligne, la capacité, pour le journaliste, de sélectionner
des alertes sur les sujets souhaités et, à terme, pourquoi pas de lui
offrir une page personnalisée. Les moyens à mettre en œuvre ne sont
pas forcément très importants dans la mesure ou ces actions ne sont
que le prolongement de la politique de relations presse de l’entre-
prise. La mise en place d’un outil Web peut même apporter une
meilleure efficacité et permettre d’optimiser le budget consacré au
fonctionnement de l’agence !
Le troisième objectif des sites institutionnels est de soutenir le travail
de communication financière en informant régulièrement les
publics financiers. Ils créent avec eux une relation suivie dont le but
est de convaincre de la bonne santé et du potentiel de l’entreprise.
Les outils et moyens mis en œuvre sont identiques à ceux utilisés
pour les journalistes.
Le quatrième objectif est de participer activement au recrutement
de talents en leur présentant une vision positive de leur future
carrière au sein de l’entreprise. Pour ce faire, un contenu et des
services spécifiques doivent leur être proposés : interviews de colla-
borateurs exemplaires, parcours types, valeurs, plan de formation,
chiffres clés, opportunités de carrière, candidature spontanée… Une
fois de plus, les moyens à mettre en œuvre peuvent être limités si le
site s’inscrit dans la stratégie générale de recrutement. Dans ce cas,
l’outil de gestion des ressources humaines possède peut-être une
extension Web. De plus, la création d’un outil pour le site peut
rendre plus efficace l’ensemble du dispositif.
Le principal intérêt des sites institutionnels est l’information. À ce
titre, ils doivent fournir un contenu d’une haute qualité, dans la
langue de l’utilisateur, fréquemment mis à jour, enrichi de présenta-
tions multimédias, parfois même personnalisé. Le cœur fonctionnel
de ces sites est donc la gestion de contenu, la personnalisation et la
gestion des e-mails entrants.

17
Partie I – Les projets Web

La gestion de contenu repose sur des fonctions relativement stan-


 Workflow : gestion dardisées enchaînées de manière logique dans un workflow1 (créa-
électronique de processus, tion, validation, catégorisation, stockage, publication).
notamment de publication
d’informations. Les principales solutions sont le développement sur mesure, le
recours à un progiciel sous licence ou en ASP et la mise en place
d’une infrastructure dédiée.
Les développements sur mesure sont recommandés quand le projet
 Volumétrie : évaluation est simple et possède une faible volumétrie2 mais que la structure des
du volume représenté par
articles est complexe. Le temps de mise en œuvre est plus long mais
un site ou une application
Web. Le nombre de pages, la souplesse incomparable.
de données, de transac- Les offres en ASP sont suffisantes pour des sites de taille réduite ou
tions… sont des indicateurs
pour une première expérience. L’entreprise prend peu de risques et
de volumétrie.
la mise en œuvre ne demande que quelques jours.
Les progiciels sous licence répondent à des besoins plus poussés et
des projets plus stratégiques. Ils apportent un cadre structurant tout
en étant plus ouverts que les solutions en ASP.
Enfin, la mise en place d’une infrastructure dédiée répond à des
besoins stratégiques qui dépassent le cadre du site institutionnel
stricto sensu.
Les critères à prendre en compte pour choisir une solution packagée
sont :
• la souplesse de création du contenu (masques de saisie, copier/
coller, éditeur WYSIWYG, importation…) ;
 Métadonnées : données • la puissance de catégorisation (métadonnées3, respects de stan-
qui définissent l’état et le dards tels que RDF4) ;
contenu d’un document
HTML ou XML (<title>, • l’ouverture (recours à un format pivot5 tel que XML) ;
<keywords>, etc.).
• la capacité de dialogue avec des applications tierces telles que
 RDF : Resources d’autres sites de l’entreprise ou des sites partenaires ;
Description Framework.
• la capacité de personnalisation.
Il s’agit d’un langage struc-
turé de description du
contenu d’un fichier créé
par le W3C et promu, entre
autres, par le Dublin Core.

 Format pivot : format


d’échange de données ;
schéma ou DTD XML
par exemple.

18
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Tableau 1-3
Quelques solutions packagées de gestion de contenu

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE


Uzine Spip http://www.spip.net PME/Grand OSS
compte
Communauté Plone http://plone.org PME/Grand OSS
compte
OpenCMS OpenCMS http://www. PME/Grand OSS
opencms.com compte
Noheto Noheto WCM http://www.wedia.fr PME/Grand progiciel
compte
Drupal Drupal http://www. PME/Grand OSS
drupal.org compte
eZ eZ Publish http://ez.no PME/Grand OSS
Compte
Automattic Wordpress http:// PME/Grand OSS
wordpress.org Comple
Joomla! Joomla! http:// PME OSS
www.joomla.org
SilverStripe SilverStripe http:// PME/Grand OSS
www.silvers- comple
tripe.com
Typo3 Typo3 http://typo3.org PME/Grand OSS
comple
Interwoven TeamSite http:// Grand progiciel
www. compte
interwoven.com

La gestion des e-mails entrants utilise des mécanismes standards :


répartition, notification et première réponse automatiques, tableau
de bord, aide à la réponse… Un progiciel sous licence ou en ASP
répond à la majorité des besoins. De même, pour la gestion des e-
mails sortants (newsletter, mailing lists, alertes…) les offres
commerciales sont toutes très performantes. Dans le cas de dévelop-
pements spécifiques, de nombreuses briques sont disponibles dans
la communauté Open Source.

19
Partie I – Les projets Web

 E-mails entrants : e-mails Tableau 1-4


en provenance de l’exté- Quelques solutions packagées de gestion des e-mails entrants 1.
rieur du site ou de l’appli-
cation Web, comme les ÉDITEUR PRODUIT URL CIBLE CATÉGORIE
e-mails d’un utilisateur, d’un
client, d’un journaliste… Akio-Software Mail center http://www. PME/Grand e-mails
akio-software.com compte entrants
Artologik EmailResponse http://www.artolo- PME e-mails
Enterprise gik.net entrants

Points clés du projet


Un projet de site institutionnel peut être mené de deux manières
selon qu’il est simple ou complexe. Dans le premier cas, il s’agit
essentiellement d’un projet éditorial sans conséquences organisa-
tionnelles importantes. Le contenu est géré par une équipe centrale
(une ou deux personnes) qui prend en charge toutes les opérations.
Le point clé est la mise en place d’une solution de publication et de
gestion des e-mails souple et efficace. Le projet ne présente pas de
difficultés particulières. Les solutions qui reposent sur des progiciels
(licence ou ASP) ou des développements spécifiques (à base de
briques Open Source par exemple) répondent parfaitement à la
problématique.
 Publication : Repère : publication2 ou gestion de contenu
ce processus consiste
à récupérer un contenu
Ces deux termes désignent des réalités très différentes. La publication correspond à l’action de
(textes, images, etc.) et déposer sur un serveur en production, c’est-à-dire accessible au public visé, des fichiers tels que des
à l’afficher sur un site Web. pages HTML, des images, etc. Par extension, un outil de publication Web correspond à un système
On distingue en général fermé qui permet de mettre à jour le contenu de pages statiques ou générées. La gestion de
trois phases : la production
du contenu, sa validation et contenu correspond à la production d’informations, classées dans une référentiel commun et
sa mise en ligne (appelée stockées en un endroit unique. En caricaturant, on peut dire que d’un côté le but est de mettre à
également publication). jour une page précise d’un site, alors que de l’autre le but est de produire un contenu calibré sans
se préoccuper de son mode de consommation.

Dans le second cas, il s’agit d’un projet stratégique ayant des réper-
cussions sur l’organisation de l’entreprise. Le contenu est géré de
manière décentralisée par plusieurs acteurs (directions, pays,
filiales…) et le site intègre des fonctionnalités ou des données en
 Périmètre fonctionnel :
délimitation des fonction-
provenance d’autres applications telles que l’outil de gestion des
nalités prises en charge par ressources humaines, etc.
le site ou par l’application La première action à mener est la définition d’une ligne éditoriale et
Web. Le périmètre fonction-
nel doit être défini dans son d’un périmètre fonctionnel3 desquels toutes les autres actions
contexte. découleront.

20
Chapitre 1 – Qu’est-ce qu’un projet Web ?

La deuxième action à mener est la définition de l’organisation


humaine qui alimentera le site et de son mode d’animation. Cette
définition repose sur une évaluation précise de la charge de travail.
Elle peut être réalisée sur la base du rubriquage1.  Rubriquage : ensemble
cohérent et raisonné de
La troisième action à mener est la définition (puis la traduction/ rubriques.
adaptation) d’une taxonomie éditoriale commune à l’ensemble des
contributeurs. Sans elle, l’outil de gestion de contenu est aveugle et
ne sait pas classer les informations. Celle-ci peut être obtenue, en
amont du projet, en confrontant les expériences et les besoins des
futurs contributeurs au cours de séminaires ou de tables rondes
internes. Cette démarche est longue et doit donc être initiée le plus
tôt possible. Le benchmark2 des concurrents (voir la section « Le  Benchmark : démarche
benchmark du marché », chapitre 5) peut être riche d’enseigne- d’évaluation de produits,
de services ou de pratiques
ments et constituer un outil d’animation des séminaires ou tables
d’une organisation par
rondes. comparaison avec les
La quatrième action à mener est la mise en place de l’infrastructure modèles (ou les concurrents)
reconnus comme des
technique qui permet de créer, de catégoriser, de stocker et de normes de référence. Les
publier le contenu. Il s’agit alors de choisir une solution technique deux objectifs principaux
grâce aux enseignements de l’étude de faisabilité et de l’appel sont l’amélioration du
d’offres. Dans certains cas, la mise en place d’un système de person- produit ou du service et
la fixation d’une stratégie
nalisation en front-office sera souhaitable, par exemple si le rubri- marketing.
quage du site est organisé autour de communautés d’intérêt (jour-
nalistes, financiers, étudiants, passionnés…).
La cinquième action à mener est la définition d’une organisation et
d’argumentaires qui permettent de répondre aux e-mails entrants
puis, dans un deuxième temps, la mise en place de la solution tech-
nique retenue.
Enfin, la sixième action à mener est l’intégration3 de certaines appli-  Intégration : ce proces-
cations telles que l’outil de gestion des recrutements. Pour ce faire, sus consiste à assembler
plusieurs composants
une étude de faisabilité déterminera, en amont, le meilleur moyen (ou applications) dans le
d’y arriver. but de constituer une appli-
cation cohérente (gestion
Évidemment, chaque projet étant unique, de nombreuses situations
des commandes, cata
intermédiaires existent ! logue, panier… par
exemple dans le cas
d’un site marchand).
Check-list
Avant de lancer le projet, il faut :
– vérifier que des objectifs quantifiés ont été fixés ;
– dimensionner le projet (site national isolé, site international nécessitant cinq langues et une
localisation des informations, etc.) ;

21
Partie I – Les projets Web

– identifier les principales cibles (et les services qui en découlent) ;


– vérifier qu’un groupe d’utilisateurs sera impliqué tout au long du projet ;
– ne pas oublier les aspects réglementaires.

Les sites de marques


Les sites de marques sont démonstratifs et ludiques. Ils proposent
aux utilisateurs de s’immerger dans l’univers de la marque au travers
de contenus interactifs à forte valeur ajoutée.

Figure 1-7
http://www.nike.com

Objectifs et moyens
L’objectif des sites de marques est de renforcer et d’entretenir la fidé-
lité à la marque en prolongeant l’expérience sur le Web. Ils visent
également à capter le plus d’informations possibles sur les utilisa-
teurs de manière à enrichir les bases de données marketing.
Ils doivent pour cela les faire interagir au travers de jeux-concours,
 E-flyers : invitations/ de services (création en ligne de fonds d’écrans, d’e-flyers 1,
faire-part électroniques. d’e-cards…), de conseils personnalisés (quizz…) ou tout simple-
ment en demandant l’e-mail de l’internaute avant que celui-ci ne
 Goodies : terme puisse télécharger des goodies2.
anglo-saxon qui désigne
des cadeaux à vocation
Chaque site de marque est unique et, en théorie, ne ressemble à
promotionnelle. aucun autre. Cependant, le cœur fonctionnel de chacun d’entre eux
est presque toujours la gestion de contenu et la gestion des e-mails.

22
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Ces problématiques ont été traitées dans la section « Les sites insti-
tutionnels », nous vous invitons à vous y reporter pour plus de
détails.

Tableau 1-5
Quelques solutions packagées de gestion des e-mails sortants

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE

Cabestan eMail Manager http://www. PME/Grand e-mails


cabestan.com compte sortants

Goto Sarbacane http://www.goto.fr PME/Grand e-mails


compte sortants

Akio-Software Akio Direct Email http://www. PME/Grand e-mails


akio-software.com compte sortants

E-MAIL vision Campaign http://www. PME/Grand e-mails


Commander emailvision.com compte sortants

MailPerfor- MailPerformance http://www.mail- PME/Grand e-mails


mance ASP edition performance.com compte sortants

Emailing Emailing http://www. PME/Grand e-mails


solution solution emailingsolu- compte sortants
tion.com

Points clés du projet


Le premier point clé dans la conduite d’un projet de site de
marques est la définition d’objectifs quantifiés et d’indicateurs
permettant d’en mesurer l’atteinte. Ce sont eux qui orientent le
projet et fixent les priorités. Or, entre « obtenir x milliers de visites
par mois » et « capter cinq cents nouveaux contacts qualifiés
chaque mois », il y a une différence fondamentale. Dans le premier
cas, le site est passif. Dans le second, tout un dispositif marketing
est à construire.
Le deuxième point clé est la cohérence du design avec celui présent
sur les autres supports de communication utilisés. Si elle n’est pas
forte, les internautes risquent d’être perturbés. Cela implique de
tirer parti des possibilités multimédias du Web mais aussi d’en
respecter les limites. Pour être efficace, le site doit adapter son niveau
technologique à la cible visée. Il est donc important de décrire la
cible – ou tout du moins le cœur de cible – le plus précisément

23
Partie I – Les projets Web

possible (zone géographique, type d’équipement, habitudes…)


avant de commencer le travail créatif.
Le troisième point clé est la légitimité des services rendus. Elle doit
être la plus forte possible, c’est-à-dire s’inscrire parfaitement dans la
philosophie de la marque. Il est impératif, en phase de conception,
 Panel : groupe de mener un test avec un panel1 d’internautes afin de valider le degré
restreint d’internautes d’intérêt porté à chaque service.
ou d’utilisa-teurs statistique-
Le quatrième point clé, comme pour le site institutionnel, est la
ment représentatifs de la
population étudiée. Un définition d’une organisation et d’argumentaires qui permettent de
panel est en général perma- répondre aux e-mails entrants puis, dans un deuxième temps, la
nent afin d’être interrogé mise en place de la solution technique retenue.
régulièrement et ainsi de
révéler les évolutions de Enfin, le cinquième point est la clarification de la situation des
comportement. droits d’auteurs. Ceux-ci peuvent, en effet, constituer un élément
important de la faisabilité du projet, car ils n’ont pas toujours été
négociés pour une utilisation sur Internet et dans le monde entier.
C’est d’autant plus vrai que la création (spot TV, affiche, etc.) est
ancienne. Or ce sont justement ces vielles créations qui intéressent
les internautes. Une étude juridique peut, dans certains cas être utile
en amont de la conception.
Check-list
Avant de débuter le projet, il est important de :
– vérifier que des objectifs quantifiés ont été fixés ;
– vérifier que les objectifs sont cohérents avec les valeurs et le territoire de la marque ;
– vérifier que les objectifs sont cohérents avec les spécificités et les contraintes du Web ;
– vérifier que les droits d’auteur ne poseront pas de problème. Sinon, en évaluer le coût ;
– vérifier qu’un groupe d’utilisateurs sera impliqué tout au long du projet ;
– ne pas oublier les aspects réglementaires.

24
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Les sites communautaires


Les sites communautaires proposent un contenu et des services créés
par les différents membres de la communauté. Ils sont autant des
lieux d’échanges ponctuels que de diffusion du savoir. La majorité des
communautés virtuelles sont organisées autour d’un thème central
suffisamment fédérateur pour attirer des milliers de membres :
l’informatique, les jeux vidéos, la Bourse… Dans le cas des sites insti-
tutionnels, « support » peut être considéré comme une communauté.

Figure 1-8
http://www.cisco.com
Cisco Systems a économisé plus de cinq cent cinquante millions de dollars par
an en service client au cours des trois dernières années.
Source : Patricia B. Seybold, Clients.com (éditions Dunod).

Objectifs et moyens
Le premier objectif des communautés virtuelles après avoir attiré et
fédéré un volume important de membres est d’obtenir le plus
d’informations possibles sur leur milieu socioprofessionnel, leurs
habitudes, leurs motivations, leurs comportements et surtout leurs
centres d’intérêt… de manière à pouvoir commercialiser des espaces
marchands à très forte valeur ajoutée et éventuellement vendre les
profils qualifiés. Cela sous-entend d’être capable de produire un
important volume de contenu qualitatif. Le seul moyen d’y parvenir
est de recruter des bénévoles qui connaissent bien le sujet et de les
fidéliser.

25
Partie I – Les projets Web

Figure 1-9
http://www.clubic.com. Le principe de vente contextuelle est très utilisé par les
communautés informatiques où des sites marchands peuvent présenter leurs
meilleurs prix pour une carte graphique… à la fin d’un comparatif sur cette
même carte graphique. Le contexte d’achat ne peut pas être meilleur : l’inter-
naute fait confiance aux informations produites par la communauté et sélec-
tionne la meilleure offre sans se poser trop de questions sur le site marchand.

 Trafic : mesure Le deuxième objectif des communautés est de générer un trafic1


du nombre de connexions à suffisant pour vendre leur espace publicitaire – très qualifié – au plus
un site ou à une application offrant. Pour y parvenir, un suivi statistique très fin s’impose.
Web. Le trafic peut être
mesuré par le nombre Le cœur fonctionnel des communautés virtuelles est constitué des
d’utilisateurs, de fonctions de gestion des membres, de gestion de contenu et de
connexions, de requêtes… services communautaires : commentaires, notation, ranking,
forums. Il est complété par des fonctions d’échange et d’intégration
de données, de gestion des e-mails entrants et sortants et de chat.
Pour plus de détails sur la gestion de contenu, reportez-vous à la
section « Les sites institutionnels ».
Les solutions les plus performantes sont issues du monde Open
Source. Les plus connues d’entre elles comme Drupal, Wordpress
Mu, Joomla! ou eLGG permettent de créer le site en quelques
heures. Elles offrent toutes les fonctionnalités souhaitées : gestion
des membres, du contenu, sondage, agenda… rien ne manque !

26
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Tableau 1-6
Quelques solutions packagées de gestion de communauté virtuelle

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE


PostNuke.org PostNuke http://www.post- PME/Grand Communauté
nuke.org compte
Xoops.org Xoops http:// PME/Grand Communauté
www.xoops.org compte
eLGG.org eLGG http://elgg.org/ PME/Grand Communauté
compte
Drupal.org Drupal http://drupal.org/ PME/Grand Communauté
compte
joomla.org Mamboserver http://www. PME/Grand Communauté
joomla.org compt

Points clés du projet


La fixation d’un objectif d’acquisition de membres échelonné dans
le temps est un préalable incontournable. En effet, toute commu-
nauté virtuelle repose sur un volume minimal de membres qui
permet de rentrer dans un cercle vertueux : plus il y a de membres
actifs, plus le contenu est de qualité (articles et animation des
forums), plus le taux de transformation des visiteurs en membres est
important, plus le contenu est de qualité… Le modèle économique
et notamment le calcul du point mort repose sur cette estimation.
Dans le cas d’une communauté lancée par une entreprise, celle-ci devra
impérativement évaluer l’organisation nécessaire à la production initiale
du contenu et aux premières semaines d’animation des forums. Cette
dimension est une composante essentielle de la faisabilité du projet, les
moyens à mettre en œuvre étant, en général, assez importants.
Check-list
Avant de débuter le projet, il est important de :
– vérifier l’adéquation de ce type de site avec les objectifs de l’entreprise ;
– valider l’engouement du public pour le thème envisagé ;
– vérifier qu’un groupe d’utilisateurs sera impliqué tout au long du projet ;
– ne pas oublier les aspects réglementaires.

Les intranets  Travail collaboratif :


travail réalisé entre
S’il existe autant d’intranets que d’entreprises, la plupart d’entre eux plusieurs intervenants
offrent cependant aux utilisateurs un point d’accès unique vers un qui nécessite un haut degré
contenu à valeur ajoutée et des fonctionnalités de travail collaboratif1. de coordination.

27
Partie I – Les projets Web

Figure 1-10
Inside Bank One. Concept d’intranet développé par Mark Gallagher pour
Bank One. Source : http://www.gallagher.com/intranet/home_page_design.

Bonne pratique : cinq axes stratégiques pour les intranets


1. Reconfigurer les processus (automatiser des tâches, dématérialiser des flux d’information).
2. Améliorer les synergies (partenaires, e-procurement, supply chain...).
3. Gérer la connaissance (rationaliser l’information, capitaliser le savoir, développer les réseaux).
4. Développer les relations clients (prospecter, conquérir, fidéliser, développer).
5. Favoriser l’appartenance (identité, etc.).
Source : D’après Frédéric Alain, Marc Saliou et Frédéric Amoros, L’entreprise intranet (éditions Eyrolles).

Objectifs et moyens
Les objectifs d’un intranet sont, d’une part, d’augmenter la compéti-
tivité de l’entreprise en accélérant la circulation de l’information et en
facilitant le travail de groupe et, d’autre part, de fédérer les collabora-
teurs autour d’une même vision stratégique et de valeurs communes.
Augmenter la circulation de l’information dans l’entreprise est un
enjeu vital car le partage du savoir-faire en dépend. Un intranet peut,
au travers d’une démarche éditoriale ou métier, fédérer ce savoir et le
faire partager à l’ensemble des collaborateurs.
Il peut aussi faciliter l’accès à l’information en structurant les ressources
documentaires au travers de bases de connaissance ou de simples

28
Chapitre 1 – Qu’est-ce qu’un projet Web ?

référentiels (modèles de documents, brochures commerciales, devis,


contrats, catalogue des produits de l’entreprise, démarches et
processus, informations sur les concurrents, avantages salariaux…) et
en offrant un accès « intelligent » : recherche multicritère, historiques,
présentation personnalisée...
En proposant des espaces de travail collaboratif (e-mails, forums,
workflows collaboratifs…), l’intranet décloisonne l’organisation de
l’entreprise, ce qui facilite le travail en mode projet et, par conséquent,
fait gagner du temps aux collaborateurs travaillant sur un même
dossier mais ne se trouvant pas, par exemple, dans les mêmes locaux.
Au final, l’intranet est un puissant outil de fédération des collabora-
teurs autour d’une vision commune car il offre, dans les faits, une
image fédérative de l’entreprise : chacun contribue à l’enrichir et
chacun, à son tour, en bénéficie.
Le cœur fonctionnel d’un intranet repose sur la gestion des droits utili-
sateurs, la gestion de contenu, des fonctions de personnalisation et des
fonctions de collaboration. À ces principales fonctions s’ajoutent une
multitude d’autres fonctions moins vitales (forums, agendas,
streaming1…).  Streaming : flux audio
Il n’existe pas d’offre intranet à proprement parler. La solution finale ou vidéo qui permet
est donc souvent un savant mélange de progiciels et de développe- d’écouter ou de visualiser
un fichier au fur et à mesure
ments spécifiques. La gestion des droits utilisateurs s’appuie, en
de son téléchargement.
général, sur l’annuaire LDAP de l’entreprise. À cette brique de base
s’ajoutent généralement des outils de groupware et une solution de
gestion de contenu ou de publication. Cela étant, un intranet peut très
bien être développé sur mesure. Dans certains cas, des solutions Open
Source telles que eLGG, Drupal ou PostNuke peuvent même être
intéressantes.

Tableau 1-7
Quelques solutions packagées de travail collaboratif

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE


mayeticvillage mayeticvillage http://www. PME/Grand travail
mayetic.fr compte collaboratif
Moregroupware Moregroupware http://source- PME/Grand travail
forge.net/ compte collaboratif
projects/
moregroupware/
eGroupware eGroupware http://www.egrou- PME/Grand travail
pware.org compte collaboratif
Microsoft Sharepoint http://www. PME/Grand travail
Portal server microsoft.com compte collaboratif

29
Partie I – Les projets Web

Zimbra Zimbra Collabo- http:// PME/Grand travail


ration Suite 5.0 www.zimbra.com compte collaboratif
37signals Basecamp http:// PME/Grand travail
www.basecam- compte collaboratif
phq.com
Link eLink http:// PME/Grand travail
www.nextapplica- compte collaboratif
tion.fr
IBM Lotus Quickr http://www.ibm.com PME/Grand travail
compte collaboratif
Development Open Atrium http://development PME travail
SEED seed.org/product/ collaboratif
open-atrium
Jean-Philippe Redmine http://redmine.org PME travail
Lang collaboratif

Points clés du projet


La détermination d’objectifs quantifiés constitue un point clé du projet.
Ceux-ci ont l’avantage de forcer l’entreprise à réfléchir sérieusement aux
gains attendus et, par la même occasion, à évacuer les fausses « bonnes
idées ». Si les objectifs sont définis avec précision, ils constitueront une
base très utile pour définir le périmètre fonctionnel du futur intranet lors
de l’expression des besoins (voir la section « L’expression des besoins »,
chapitre 7).
Un projet d’intranet, qui s’inscrit dans la stratégie de l’entreprise, aura de
fortes répercussions sur le travail quotidien de la plupart des collaborateurs.
Or ceux-ci n’aiment guère changer leurs habitudes. Le premier facteur clé
de succès du projet sera donc de mener, en amont, une mission de
conduite du changement1 dont les principaux objectifs seront de sensibi-
 Conduite du liser les futurs utilisateurs et de créer un environnement favorable au projet.
changement : stratégie et
moyens qui visent à adapter
Cette première étape s’accompagne forcément d’une campagne de
l’organisation en vue de la communication bottom-up (des collaborateurs à la direction), fondée sur
mise en place de nouveaux le dialogue et la concertation. Celle-ci s’étale, à l’idéal, tout au long du
processus et/ ou d’une projet, le cœur de la campagne pouvant coïncider avec l’expression des
nouvelle organisation besoins et l’étude de l’existant (voir la section « L’étude de l’existant »,
(formation, réingéniering,
communication...).
chapitre 7) de manière à montrer des avancées concrètes.
Mais attention, cette action est très engageante pour la direction dans la
mesure où il ne sera plus possible de « reculer pour mieux sauter ». Une
fois les collaborateurs informés, il sera extrêmement périlleux de faire
marche arrière (et de remettre à plus tard la réalisation de l’intranet).
L’implication des utilisateurs tout au long du projet est un élément essentiel.
Car ce sont eux qui utiliseront l’outil au quotidien. Ils sont par conséquent
les mieux placés pour évaluer la qualité de l’ergonomie en général et l’inter-

30
Chapitre 1 – Qu’est-ce qu’un projet Web ?

face en particulier. Ce sera aussi l’occasion de communiquer auprès d’un


public sélectionné qui pourra se faire le relais informel de l’avancée du projet.
Enfin, la définition, le plus tôt possible, de l’organisation nécessaire à
l’animation de l’intranet sera un facteur clé de succès. En général, elle
repose sur une équipe dédiée réduite qui s’appuie sur des correspon-
dants. Plus tôt ils seront associés à la démarche et plus les chances de
réussite seront grandes, car, de simples exécutants, ils deviendront des
concepteurs. Ce qui est beaucoup plus valorisant… et motivant !
Check-list
Avant de lancer le projet, il faut :
– vérifier que des objectifs quantifiés ont été fixés ;
– vérifier qu’un plan de conduite du changement est prévu ;
– vérifier qu’une campagne de communication est prévue ;
– vérifier qu’un groupe d’utilisateurs sera impliqué tout au long du projet ;
– ne pas oublier les aspects réglementaires.

Les portails d’entreprise


Il n’existe pas de définition unique du terme portail d’entreprise. La plus
courante pourrait être : « un outil qui agrège, sur un seul écran, person-
nalisé en fonction du profil1 de chaque utilisateur, toutes les informa-  Profil : terme qui désigne
un ensemble de caractéris-
tions et applications dont il a besoin pour travailler au quotidien ». Les tiques attachées à un indi-
portails sont destinés à la fois aux collaborateurs in situ et aux nomades. vidu ou à un groupe
d’individus.

Figure 1-11
IBM Websphere portal

31
Partie I – Les projets Web

Objectifs et moyens
L’objectif principal des portails d’entreprise est d’unifier l’accès aux
applications et aux informations de manière à améliorer l’efficacité
des collaborateurs et à réduire les coûts de fonctionnement. On
distingue en général cinq grands champs d’application :
• la diffusion de l’information ;
• le travail collaboratif ;
• la fluidification et la simplification des processus métier ;
• le partage de la connaissance ;
• l’intégration des applications métier.
Dans les faits, deux types de projets coexistent : des projets de fédé-
ration des informations existantes – qui ne remettent pas en cause
le fonctionnement des intranets existants – et des projets d’intégra-
tion en profondeur qui vont jusqu’à offrir une interface avec des
applications telles que SAP. Ces projets s’appuient sur des démar-
ches et des outils très différents.
Dans la première approche, le portail d’entreprise est considéré
comme la suite logique de l’intranet. Moins coûteux qu’une
refonte globale, il facilite l’accès aux ressources existantes sans
remettre en cause le processus d’alimentation en contenu des
différents intranets. Le portail fédère l’information existante et
propose un accès homogène et personnalisé. Il agit comme un
puissant moteur de recherche capable d’indexer de nombreux
intranets qui comportent eux-mêmes de nombreuses bases de
données, systèmes de fichiers, etc. Les outils spécialisés qui répon-
dent à cette demande font essentiellement gagner du temps lors de
la mise en œuvre du projet. Ils apportent en outre un cadre rigou-
reux pour gérer la publication des nouveaux contenus. Cette
approche du concept de portail remporte l’adhésion des entre-
prises. Elle est simple, l’offre logicielle est mature et les produits
 Vue : affichage
sont financièrement abordables.
du résultat d’une requête. La deuxième approche reprend toutes les caractéristiques de la
Une vue ne permet que première et ajoute un niveau d’intégration supplémentaire. Les
la consultation
des informations.
sources d’information, les applications, la gestion des utilisateurs,
etc. : tout est intégré au sein d’une interface graphique unique et
 Traitement métier : hautement personnalisée. Véritable projet d’infrastructure, ce type
ensemble de règles et de de portail permet d’accéder indifféremment à une vue1 SAP, à sa
programmes qui permettent
de traiter des données
messagerie, ou à un traitement métier2 développé sur mesure sans
en cohérence avec les sortir du portail. On est donc loin du simple « moteur de
pratiques d’un métier. recherche ». Mais un tel niveau d’intégration nécessite des investis-

32
Chapitre 1 – Qu’est-ce qu’un projet Web ?

sements coûteux. Cela correspond à une démarche de fond : le déve-  Composant :


programme indépendant
loppement d’applications métier sous forme de composants1.
que l’on assemble avec
Chaque brique logicielle2 s’appuie alors sur une infrastructure d’autres pour construire
commune qui apporte à la fois des services transactionnels mais une application.
aussi de présentation et une gestion standard des utilisateurs. Extrê-
 Brique logicielle :
mement souple et réactive, cette architecture est en train d’émerger. voir « Composant ».
Le cœur fonctionnel d’un portail est constitué de la gestion des utili-
 SSO : Single Sign-On
sateurs, de l’intégration de contenu, de l’intégration d’application, ou authentification unique
de la personnalisation, et du Single Sign-On (SSO3). en français. Cette fonction-
nalité permet aux utilisa-
Tableau 1-8 teurs de ne s’identifier
Quelques solutions packagées de Single Sign-On qu’une fois pour accéder à
l’ensemble des applications
ÉDITEUR PRODUIT URL CIBLE CATÉGORIE sécurisées auxquelles
ils sont autorisés.
Evidian AccessMaster http://www.evi- Grand SSO
SSO / PortalXpert dian.com compte
Oracle Oracle Identity http://www. Grand SSO
Management oracle.com compte
Microsoft Microsoft Passport http://www. Grand SSO
microsoft.com compte
RSA Security SecurID http://www. Grand SSO
rsasecurity.com compte
Baltimore UniCERT 5.0 http://www. Grand SSO
baltimore.com compte
Entrust TruePass http://www. Grand SSO
entrust.com compte
University of pubcookie http://www. PME SSO
Washington washington.edu
Red Iris PAPI System http://papi. PME SSO
rediris.es/

33
Partie I – Les projets Web

Tableau 1-9
Quelques solutions packagées de portail

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE

Autonomy Portal-in-a-Box http://www. PME/ Portail


autonomy.com Grand
compte
Hummingbird Hummingbird http://www. Grand Portail
Connectivity hummingbird.com compte
IBM WebSphere Portal http://www.ibm.com Grand Portail
Server 6 compte
Ever EverSuite http://www. Grand Portail
mediapps.fr compte
Microsoft SharePoint 2007 http://www. PME/ Portail
microsoft.com Grand
compte

Oracle Oracle Portal http://www. Grand Portail


oracle.com compte
Vignette Vignette V7.4 http://www. Grand Portail
vignette.com compte
Drupal Drupal http://drupal.org PME/ Portail
Grand
compte

Tableau 1-10
Quelques solutions d’EAI

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE

webMethods Integration Platform http://www. Grand EAI


webmethods.com compte
Microsoft Biztalk Server 2006 http://www. Grand EAI
microsoft.com compte
CapeClear Cape Clear 7.5 ESB http://www. Grand EAI
capeclear.com compte
Iona Orbix(WEB Services http://www.iona.com Grand EAI
Integration Platform) compte

34
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Tableau 1-11
Quelques solutions packagées d’EII

ÉDITEUR PRODUIT URL CIBLE CATÉGORIE

BEA AquaLogic Data Ser- http://www.bea.com Grand EII


vices Platform compte
Composite Composite http://www. Grand EII
Software Information compositesoftware. compte
Server 4.5 com
Red Hat MetaMatrix Server http://www.redhat.com Grand EII
compte
OpenLink Virtuoso http:// Grand EII
Universal Server www.openlinksw.com compte
Enterprise Edition
Polarlake Database Integrator http:// Grand EII
www.polarlake.com compte
Sagent EII http:// Grand EII
www.sagent.com compte
Informatica Informatica 8.5 http:// Grand EII
www.informatica.com compte
XAware XAware 5 http:// Grand EII
www.xaware.com compte

Points clés du projet


La mise en place d’un portail est l’aboutissement d’une démarche
stratégique beaucoup plus vaste qui consiste à clarifier l’organisation
et les processus de l’entreprise. En effet, toute l’architecture fonc-
tionnelle de ce dernier repose sur la définition de profils d’utilisa-
teurs auxquels sont associées des informations et des applications.
La définition de ces profils peut avoir un tel impact sur l’organisa-
tion de l’entreprise qu’elle constitue un projet à part entière. Ce
préalable est un facteur clé de succès de la mise en place du portail.
Dans un deuxième temps, l’entreprise doit lister les applications
existantes et réellement utilisées afin de déterminer celles qui sont
stratégiques pour le projet. Certaines pourront être réutilisées telles  Plan de migration :
qu’elles, d’autres en revanche devront, a priori, être redéveloppées. stratégie et moyens visant
Le plan de migration1 de ces applications constitue le deuxième à déplacer des données
existantes d’un système à
facteur clé de succès. un autre (souvent d’un vieux
système au nouveau
système).

35
Partie I – Les projets Web

Il est également nécessaire de lister les contenus existants puis de


s’assurer de leur fiabilité et de la capacité de chaque équipe à les
produire régulièrement. Sur cette base, il est possible de vérifier qu’à
chaque profil (ou groupe de profils dans un premier temps) corres-
pond un contenu spécifique d’une quantité et d’une qualité suffi-
santes pour justifier son intégration. Dans le cas contraire, le recours
à une équipe dédiée (interne ou externe) pour produire le contenu
est nécessaire.
Comme pour l’intranet, la fixation, en amont, d’objectifs quantifiés
permettra de vérifier l’opportunité de l’intégration de chaque appli-
cation et de chaque contenu en regard de son coût.
Enfin, le portail reposant sur une identification fine de chaque utili-
sateur via un login et un mot de passe, un annuaire d’entreprise (de
type LDAP) unifié, complet et à jour, constitue un préalable indis-
pensable à la conduite du projet. Or, un tel annuaire, s’il n’existe pas
encore, doit être considéré comme un projet à part entière. D’autant
plus que pour être réellement ergonomique, le portail doit proposer
une solution d’authentification unique (Single Sign-On) qui évite
aux utilisateurs de ressaisir plusieurs dizaines de fois dans la journée
leur mot de passe.
Dans ce contexte, la définition et la mise en œuvre d’une conduite
du changement en amont puis tout au long du projet sont deux
tâches incontournables. Elles devront s’appuyer, comme dans le cas
d’un intranet, sur une campagne de communication bottom-up
favorisant le dialogue et la concertation.
Check-list
Avant de lancer le projet, il faut vérifier :
– que l’organisation est stabilisée après la refonte des processus métier ;
– qu’une liste de profils opérationnels est disponible et qu’à chacun d’eux sont associés des appli-
cations et des contenus existants ;
– qu’un annuaire LDAP (ou équivalent) existe, qu’il est complet et à jour ;
– que les méthodes d’authentification des applications permettront de mettre en place un SSO à
un coût raisonnable ;
– que des objectifs quantifiés ont étés fixés ;
– qu’un plan de conduite du changement est prévu ;
– qu’une campagne de communication est prévue ;
– qu’un groupe d’utilisateurs sera impliqué tout au long du projet.Il est aussi nécessaire de lister :

36
Chapitre 1 – Qu’est-ce qu’un projet Web ?

– les applications existantes, définir un plan de migration priorisé en fonction des objectifs, de
l’expression des besoins, des profils définis (arbitrer le cas échéant) ;
– les contenus existants, définir un plan d’intégration priorisé en fonction des objectifs, et des pro-
fils définis (arbitrer le cas échéant).

Les enjeux des projets Web

Les projets Web ont désormais des obligations de rentabilité et de


pérennité. Ils doivent s’intégrer le plus possible au système d’infor-
mation de l’entreprise. Le but n’est plus d’apprendre mais de tirer
les leçons, et d’industrialiser les processus de manière à augmenter
la compétitivité de l’entreprise.
Être rentable
Les retours d’expérience montrent que les premiers projets Web
étaient plus rentables que ceux actuellement menés par les entre-
prises. D’une part, la simplicité des projets et des technologies
employées était telle que l’investissement était souvent limité à quel-
ques dizaines de milliers d’euros… Ce qui est bien naturel puisqu’il
s’agissait souvent d’expériences menées dans le but de convaincre en
interne avant de déployer des budgets beaucoup plus importants !
D’autre part, la dimension des budgets ne nécessitait pas un contrôle
de gestion poussé, voire pas de contrôle du tout, la rentabilité réelle
est donc restée à la discrétion des chefs de projet. Sans compter la
bienveillance des directions de l’époque devant le nécessaire appren-
tissage pour suivre la mode de ces « nouvelles technologies ».
La majorité des projets Web actuels ne bénéficie pas de tant de
clémence et ne peut pas s’improviser. Ils doivent presque toujours
justifier leur budget en démontrant leur rentabilité a priori avec, par
exemple, des business cases. Ce qui est d’autant plus difficile qu’ils
n’apportent presque jamais d’amélioration perceptible (par rapport
au premiers projets) par l’utilisateur final, directions générales y
compris. Celles-ci ont par conséquent du mal à comprendre pour-
quoi les nouveaux projets Web sont si complexes et nécessitent de
tels investissements. Un travail pédagogique est souvent nécessaire
en amont pour expliquer la différence entre des projets « jetables »

37
Partie I – Les projets Web

et la construction d’une infrastructure Web pérenne, donc rentable,


mais sur une période de référence plus longue.

Bonne pratique : « Le ROI est maître de tout dans nos projets », Malek Zan-
zouri, DSI de 3M France
« Une des cinq initiatives majeures de notre groupe est « l’e-productivité ». Elle vise à utiliser les
technologies de l’information pour augmenter la productivité interne, libérer des ressources pour
les focaliser sur la croissance de l’entreprise et améliorer les relations que nous entretenons
avec tous nos partenaires au sens large. Nous travaillons donc en étroite collaboration avec les

entités métier pour lister et développer les projets, dans un strict respect de la notion de ROI.
(…) J’insiste sur le fait que le ROI n’a jamais été aussi omniprésent qu’aujourd’hui dans tous
les projets que nous menons. Il est véritablement le maître de tout – sans pour autant que nous
en soyons esclaves – et nous aide à éviter certains écueils, comme les projets sans fondement
logique qui durent et coûtent le double de ce qui était prévu, avec entre-temps un changement
du besoin de l’utilisateur ! ».
Source : Journal du Net, http://solutions.journaldunet.com/itws/030423_it_mmm.shtml

La première bonne pratique à mettre en œuvre est la définition


d’objectifs quantifiés auxquels sont associés des indicateurs de
performance. Pour avoir un intérêt, ces objectifs doivent être précis
 Business plan : et étalés dans le temps. Cette pratique s’applique bien sûr à
document qui décrit
le marché et la stratégie
l’ensemble des projets, quelle que soit leur nature. Un site de
envisagée pour le conqué- marque visera, par exemple, à recruter 1 000 nouveaux « suppor-
rir, complété d’un ensemble ters » à un coût moyen de X € la première année, 1 500 à un coût Y
d’éléments financiers (tels
que compte d’exploitation
en année 2, 2 500 à un coût Z en année 3… La création d’un busi-
prévisionnel, plan de finan- ness plan est donc une étape quasiment obligatoire.
cement…). Le but du busi-
ness plan est de convaincre
La deuxième bonne pratique est d’intégrer le contrôle de gestion le
les investisseurs ou plus tôt possible dans les phases amont du projet et de s’appuyer sur
la direction générale son expertise en aval pour en mesurer la performance économique. En
de l’intérêt du projet.
amont, il aidera à fixer les objectifs, à définir les indicateurs et à cons-
truire le business plan1 dans le respect des principes et objectifs finan-
ciers de l’entreprise. En aval, il vérifiera l’atteinte des objectifs et appor-
tera son expertise dans l’analyse de la situation économique du projet.
Cette approche a le mérite de lever les doutes et les incompréhen-
sions lors des bilans de fin d’année et d’intégrer, dans les faits, la
dimension économique du projet. Elle pose en revanche un
problème de moyens et d’organisation car pour qu’elle soit viable, le
contrôleur de gestion doit être disponible et formé aux nouvelles
technologies.

38
Chapitre 1 – Qu’est-ce qu’un projet Web ?

La troisième bonne pratique est d’assurer un contrôle permanent de


l’activité du site et de considérer le contrôle a posteriori comme une
opération de vérification annuelle. Le but est de piloter l’activité du
site de la même manière que les autres activités de l’entreprise. Ainsi,
il est possible d’anticiper les problèmes et d’y trouver des parades.
Par exemple, dans le cas d’un intranet, les rubriques peu visitées
pourront être temporairement (ou définitivement) supprimées de
manière à réduire les coûts. Dans le cas d’un site marchand, une
baisse de trafic supérieure à la moyenne saisonnière pourra être
limitée par l’intensification des opérations d’e-mailing.

Être pérenne
L’utilisation des technologies Internet par les entreprises est en train
de se rationaliser. On assiste donc à la fin des sites « jetables » – qui
correspondaient au processus d’apprentissage de ces organisations –
au profit de projets beaucoup plus pérennes. Trois raisons peuvent
être évoquées.
Premièrement, les projets Web s’inscrivent désormais dans l’activité
quotidienne de l’entreprise. Ce sont donc des projets stratégiques
qui doivent être capables d’évoluer avec elle tout en gardant leur
cohérence.
Deuxièmement, les choix technologiques sont désormais très struc-
turants, les projets Web n’étant plus de simples compilations de
pages HTML isolées mais des applications complexes interconnec-
tées au système d’information de l’entreprise. Pour les concevoir, il
est nécessaire de comprendre la stratégie technologique à moyen et
long terme de l’entreprise afin de tirer parti de l’architecture géné-
rale et des standards.
Troisièmement, la complexité croissante des projets aboutit à des
plannings de réalisation de plus en plus longs donc à des coûts de
plus en plus importants. De tels investissements demandent du
temps pour être rentabilisés.
Pour garantir la pérennité de chaque projet Web, une bonne
pratique consiste à impliquer les utilisateurs à chaque étape, de la
définition du concept au test du pilote en passant par la conception.
Enfin, coordonner les différents projets Web de l’entreprise permet
de capitaliser sur les zones de recoupement fonctionnel de chaque
projet. Par exemple, le portail, l’intranet, le site marchand et le site
institutionnel utilisent tous un outil de gestion de contenu. La solu-
tion retenue à donc intérêt à être polyvalente et durable.

39
Partie I – Les projets Web

S’intégrer au système d’information


Trois motivations poussent de plus en plus d’entreprises à intégrer
les projets Web dans le système d’information de l’entreprise. Un
projet intégré est plus efficace. Dans le cas d’un site marchand, cela
permet, par exemple, d’afficher des informations qui aident l’inter-
naute à passer à l’acte, de fluidifier la gestion des stocks et la logis-
tique, de simplifier la consolidation financière… le tout en appor-
tant une meilleure fiabilité aux données puisqu’elles sont stockées à
un endroit unique et mises à jour régulièrement.
Un projet intégré permet de réaliser des économies. D’une part, en
mutualisant le coût des composants, il réduit le coût de chaque projet.
Dans le cas d’un site institutionnel, un outil de gestion de contenu
dédié à l’ensemble de l’entreprise est, par exemple, plus vite rentabilisé
que dix projets menés en parallèle par chaque direction. D’autre part,
la mise à jour peut être déléguée aux utilisateurs finals, ce qui réduit
les doubles saisies et augmente la fiabilité des informations.
Un projet intégré apporte de la cohérence. En adoptant les choix
techniques validés par la DSI (direction du système d’information),
il contribue à la convergence des applications vers un système
d’information homogène.
En se plaçant au-dessus des projets Web, on s’aperçoit qu’ils ne sont,
la plupart du temps, que des extensions du système d’information
de l’entreprise : l’extranet fournisseurs permet d’accéder aux
éléments comptables, le portail autorise les commerciaux à réaliser
leur reporting hebdomadaire, les collaborateurs à saisir leurs notes
de frais, le site institutionnel et l’intranet diffusent des informations
stockées au même endroit…

Les questions récurrentes

Trois questions reviennent de manière récurrente lors des projets


Web : Doit-on s’appuyer sur un progiciel ou plutôt réaliser des
développements sur mesure ? Quelle plate-forme retenir : PHP,
.NET ou J2EE ? Doit-on utiliser XML ?
Cette section tente d’apporter des pistes de réponse. Les choix sont
cependant éminemment liés au contexte de chaque projet et aux
politiques des DSI de chaque entreprise.

40
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Solution sur mesure ou progiciel ?


Pour pouvoir répondre à cette question, il est indispensable de
disposer d’une vision très claire du futur site. Quelles sont ses fonc-
tionnalités ? Quelles en sont les caractéristiques ? Quelles sont les
contraintes qui portent sur le site ?... Une fois chaque fonctionnalité
et chaque contrainte définies, une grille de critères pondérés peut être
établie. Sur cette base – et sur cette base seulement – le choix d’une
solution est réalisable. C’est l’objet du chapitre 7 « La faisabilité ».
Développements sur mesure : souples, rentables mais risqués
Le principal intérêt des développements sur mesure est qu’ils permet-  Code source : ensemble
tent de répondre parfaitement et dans les moindres détails aux fonc- des programmes qui consti-
tuent une application avant
tionnalités spécifiées. S’ils sont bien réalisés et documentés, ils appor- qu’ils aient été compilés.
tent en plus une grande souplesse et de fortes capacités d’évolution.
Les développements sur mesure sont aussi, dans une vision à moyen
terme, moins coûteux que les progiciels. En effet, une fois l’investisse-
ment initial amorti, il n’est plus nécessaire de payer une licence
annuelle. Cela fait une grande différence au bout de quelques années !
Enfin, comme l’entreprise détient les droits de propriété et le code
source1, elle peut en tirer un avantage compétitif, ce qui n’est pas le
cas avec un progiciel.

Bonne pratique : cahier des charges, spécifications, code et documentation


technique à jour et cohérents
Le piège des développements spécifiques est leur coût de maintenance évolutive ou corrective. En
effet, si le cahier des charges, les spécifications détaillées et la documentation technique ne sont pas
de très grande qualité, ni cohérents avec le code et à jour, un nouveau prestataire sera incapable
d’intervenir efficacement sur l’application. Il est donc impératif de prendre le temps de vérifier le code
et la formalisation des livrables. Cet investissement fera économiser beaucoup d’argent ensuite !

La principale limite des développements sur mesure est le risque lié


à la gestion de projet. En effet, il est souvent difficile de rester dans
les coûts et les délais impartis au développement et au déploiement,
même quand une démarche qualité a été mise en place. Il y a deux
raisons à cela. D’une part, en cas de vraies difficultés, le ou les pres-
tataires peuvent ne pas aboutir. D’autre part, l’organisation du
projet est plus complexe. Elle fait intervenir plusieurs prestataires
qu’il est nécessaire de coordonner.
Les développements sur mesure sont aussi plus longs que le paramé-
trage d’un progiciel car ils nécessitent une phase de conception et de
développement.

41
Partie I – Les projets Web

Enfin, pour être efficaces, ils doivent concrétiser un besoin très


précisément défini, ce qui n’est pas toujours possible. En règle géné-
rale, les développements sur mesure sont adaptés aux projets de
petite taille mais complexes, quand aucune solution progicielle ne
donne satisfaction, pour répondre à un besoin très précis.
Progiciels : structurants, rapides, mais limités
Le principal intérêt des progiciels est leur aspect structurant : l’orga-
nisation de l’entreprise et ses processus doivent s’adapter à la logique
de la solution.
La mise en œuvre de cette dernière est très rapide puisqu’il ne s’agit que
de la paramétrer. Sans compter que les progiciels leader capitalisent un
retour d’expérience qui leur permet de respecter délais et coûts.
Enfin, la simplicité de mise en œuvre autorise une démarche très
itérative qui est parfois incontournable et que les développements
sur mesure ne permettent pas.
La principale limite des progiciels est leur périmètre fonctionnel.
Excepté certaines offres métier, la plupart des solutions ne répon-
dent jamais à toutes les fonctionnalités souhaitées (ou pas de la
bonne manière). Pire, elles offrent souvent des interfaces et des ciné-
matiques complexes qui perturbent l’utilisateur.
Le principe de licence et de support est aussi un frein important car
la plupart des éditeurs mettent tout en œuvre pour rendre l’entre-
prise dépendante de manière à lui facturer au prix fort des services
sans réelle valeur ajoutée. Or, passé un certain temps, le coût de
possession est beaucoup plus élevé qu’une solution fondée sur des
développements sur mesure.
Cette dépendance peut devenir dramatique en cas de cessation
d’activité de l’éditeur. La solution n’étant plus maintenue, il est
souvent nécessaire de la redévelopper.
En règle générale, le recours à un progiciel, quand il existe en ASP,
est intéressant pour une première expérience. Beaucoup d’entre-
prises apprécient leur effet structurant et s’en servent en prévision de
croissance ou lors de fusion/acquisition. Ils permettent de respecter
un planning très serré. Enfin, les progiciels sont la plupart du temps
mieux adaptés à une problématique professionnelle.
Sur le terrain, des solutions mixtes
Concrètement, dans bien des cas, la solution retenue consiste à inté-
grer une ou des offres progiciels et à y ajouter des développements
spécifiques (connecteurs, vues métier, etc.) de manière à bénéficier

42
Chapitre 1 – Qu’est-ce qu’un projet Web ?

globalement des avantages des progiciels et de la souplesse des déve-


loppements sur mesure.

PHP, Java ou .NET ?


Avant de penser à une technologie en particulier, il est primordial de
choisir une architecture. C’est de celle-ci que dépendra le choix de la
technologie permettant d’implémenter le projet. Le choix d’une
architecture dépend essentiellement de quatre paramètres techniques
– la volumétrie de l’application, la capacité à factoriser certaines fonc-
tionnalités, la criticité du projet et le budget disponible – et de
nombreux paramètres « fonctionnels » : doit-on privilégier les perfor-
mances pures de l’application ou son évolutivité ? L’entreprise
souhaite-t-elle être totalement autonome ? Possède-t-elle les compé-  Montée en charge :
tences nécessaires en interne ? Etc. L’ensemble de ces réponses capacité de l’architecture
permettent de choisir entre deux types d’architectures : une architec- logicielle et matérielle
ture à trois niveaux ou une architecture orientée services. à traiter une certaine
quantité simultanément sans
Orientée projet : l’architecture à trois niveaux dégradation de perfor-
mance ni perte de données.
L’architecture à trois niveaux, dite aussi architecture 3-tiers, est
un grand classique désormais maîtrisée par la plupart des presta-  Synchrone : modèle
taires. Elle consiste à découpler la présentation, les traitements et de communication entre
deux programmes qui privi-
les données pour garantir un minimum d’évolutivité et de tenue légie un envoi de données
en cas de montée en charge 1 lors de pics d’utilisation. Cette de type RPC (Remote
architecture est constituée d’éléments synchrones 2 fortement Procedure Call). Tant que le
couplés et repose sur des communications point à point 3 avec programme A n’a pas reçu
de réponse du programme
l’existant. Elle est adaptée à des projets techniques relativement B, il n’exécute pas la suite
peu complexes ou à des projets départementaux autonomes qui des instructions. La capacité
doivent être réalisés rapidement pour un budget modique. à monter en charge de
Comme son nom l’indique, l’architecture à trois niveaux repose ce type d’archi-tecture
est donc limitée.
sur trois couches.
 Point à point : liaison
définie entre deux entités
spécifiées (deux serveurs
par exemple).

 Framework :
regroupement logique
de composants sous forme
de classes (ensemble de
groupes de composants)
et présentation homogène
de leurs interfaces de
Figure 1-12 programmation (API).

43
Partie I – Les projets Web

 Asynchrone : protocole Architecture à trois niveaux (vue simplifiée)


de communicaton qui
repose sur un couplage Orientée infrastructure : SOA
lâche. Lorsque le
programme A envoie une L’architecture orientée services fait généralement partie d’un plan
information au programme directeur informatique. Elle constitue une cible à atteindre à long
B, il n’attend pas d’accusé terme. Sa conception requiert des compétences de très haut niveau.
de réception.
Elle repose sur un empilement de services regroupés en couches
(ou framework1). Les couches et les services sont faiblement couplés
– d’où de nombreuses couches d’abstraction intermédiaires – et
l’ensemble de l’architecture repose généralement sur des communi-
cations asynchrones1. On distingue un minimum de cinq couches
mais celles-ci peuvent être plus nombreuses : présentation, services
métier de haut niveau, services métier de bas niveau, services
techniques, accès aux données. Le principal intérêt de ces architec-
tures est la garantie de la meilleure évolutivité possible de chaque
composant. La mise à jour d’un composant n’affecte que ses rela-
tions. Ce type d’architecture garantit en outre une excellente
montée en charge et une bonne réutilisabilité des composants.

 Machine virtuelle :
du point de vue de
l’architecture, une machine
virtuelle est une couche
d’abstraction qui masque
l’hétérogénéité des systè-
mes d’exploitation et
permet donc d’exécuter un
même code source sur tous
les ordinateurs. La machine
virtuelle est à la fois
un compilateur et un socle
d’exécution.
Figure 1-13
 Précompiler : Architecture SOA (vue simplifiée)
un compilateur est un
programme qui transforme
un code source en instruc-
Trois technologies similaires
tions directement PHP, .NET et J2EE permettent de mettre en œuvre ces deux archi-
compréhensibles par tectures. Ces trois technologies reposent sur les mêmes concepts
le microprocesseur.
Les programmes qui techniques. Une machine virtuelle2 (JVM, CLR, Zend Engine)
précompilent les pages précompile3 un code source. Le code source est organisé en compo-
Web réduisent le temps sants de plus ou moins grosse granularité. Ces frameworks de
entre la requête et composants correspondent aux couches des architectures citées plus
l’affichage de la page.
haut.

44
Chapitre 1 – Qu’est-ce qu’un projet Web ?

PHP pour les projets nécessitant peu de connectivité


Le design de PHP et son manque de connectivité avec l’existant
désignent plutôt cette plate-forme pour des projets à trois niveaux
simples. PHP est un langage extrêmement souple. Il nécessite en
conséquence un minimum d’organisation dans les développements.
Les compétences et les composants Open Source sont légion. Toutes
les conditions sont réunies avec ce langage pour tenir les délais du
projet et assurer un coût de revient sans commune mesure avec
J2EE et dans une moindre mesure .NET.
.NET et J2EE pour les projets complexes
.NET et J2EE possèdent de leur côté une couche de composants
intermédiaires (COM+ et EJB) optimisée qui destine ces langages à
de très gros projets dans lesquels l’entreprise peut se permettre de
gérer de multiples couches de composants métier. Le formalisme de
ces deux technologies impose une méthodologie et des compétences
techniques encore peu nombreuses sur le marché des prestataires  XQuery : langage
français. Les coûts de licences et de fonctionnement (hébergement, de requête qui permet
etc.) sont bien plus élevés qu’avec PHP. Ainsi, dans les faits, encore d’accéder à chacun des
très peu de projets Web J2EE utilisent réellement les EJB. Ils se éléments d’information d’un
document XML, d’en sélec-
contentent la plupart du temps de JSP… tionner des listes et de les
manipuler. XQuery est un
Stockage des données : XML ou SGBDR ? sur ensemble de XPath.
La médiatisation d’XML amène naturellement à se poser la ques-  XSLT : eXtensible Style
tion : dois-je stocker mes données en XML ? La réponse est claire- Language Transformation.
ment non. Il n’existe en effet que très peu de bases de données Ce langage permet d’effec-
compatibles nativement avec XML. Elles n’atteignent pas les perfor- tuer des transformations
et des traitements sur
mances des bases relationnelles et coûtent encore excessivement les données XML.
cher. Vous devez en outre posséder des compétences telles
qu’XQuery1 et XSLT2 en interne pour en tirer réellement parti.  SOAP : Simple Object
Access Protocol. SOAP
Le langage XML est intéressant pour l’interopérabilité qu’il amène est un protocole de commu-
en exposant des données ou des services via SOAP3 et en jouant le nication qui favorise
rôle de format pivot entre deux schémas métier de deux entreprises l’interopérabilité des appli-
différentes. XML doit donc plutôt être utilisé comme une vue au cations au travers d’autres
protocoles tels que http,
même titre qu’HTML ou PDF dans une logique MVC4. SMTP, MOM, etc.
SQL pour stocker les données  MVC : Model View
Les bases de données relationnelles proposent une solution pérenne, Controller. Structure de
sûre, bon marché et performante pour stocker les données de toutes programmation (Design
pattern) permettant de
les typologies de projets Web. Il existe de très nombreuses bases de séparer l’application,
données gratuites – MySQL et PostgreSQL par exemple – ou bon les traitements et
marché adaptées à l’ensemble des projets Web : site Web, portail, la présentation.

45
Partie I – Les projets Web

application distribuée sur PDA avec données locales mais mises à


jour via SOAP, etc. En outre, la logique de fonctionnement des
bases de données relationnelles est parfaitement maîtrisée par la
plupart des ingénieurs alors qu’XML, XQuery, XSLT et toutes les
 Design pattern : technologies XML associées sont encore rares sur les CV.
les design patterns sont
des concepts de program- XML pour les exposer
mation destinés à rendre Stocker les informations du projet dans une base de données relation-
le code plus simple à main-
tenir et à comprendre.
nelle ne veut pas dire que ces informations ne pourront pas être exposées
dans un format XML. Bien au contraire, en respectant le modèle d’archi-
tecture (design pattern1) MVC2 ou l’un de ses dérivés, un même modèle
(afficher les données d’un compte client par exemple) peut être associé à
plusieurs vues. Ainsi, la fonction AfficherFicheClient pourra très bien
être exposée en HTML, en XML ou même via SOAP. L’étape de trans-
formation peut s’effectuer soit au niveau du serveur d’application, soit au
niveau d’un hub de données (Enterprise Information Integration).

Pour aller plus loin

Ouvrages
Frédéric Créplet
Ingénierie de projet intranet
Éditions d’Organisation – 2003 – ISBN : 978-2708128798
Frédéric Alin, Xavier Amoros, Marc Saliou
L’entreprise intranet
Éditions Eyrolles – 2002 – ISBN : 978-2212111187
Pascal Lannoo et Corinne Ankri
E-marketing et e-commerce
Vuibert – 2007 – ISBN : 978-2711787210
André Corbille et Vincent Dumas
Business intelligence et portails : Le décisionnel dans un environnement web
Dunod – 2006 – ISBN : 978-2100495252
Véronique Messager Rota et Jean Tabaka
Gestion de projet : Vers les méthodes agiles
Éditions Eyrolles – 2007 – ISBN : 978-2212121650

46
Chapitre 1 – Qu’est-ce qu’un projet Web ?

Valéry-Guilhem Frémaux
Le projet informatique de A à Z : Approche pragmatique de la gestion
de projet
Ellipses Marketing – 2006 – ISBN : 978-2729826789
Rose Dieng, Olivier Corby, Fabien Gandon et Alain Giboin
Knowledge management : Méthodes et outils pour la gestion des
connaissances
Dunod – 2005 – ISBN : 978-2100496358
Franck Rebillard
Le web 2.0 en perspective : Une analyse socio-économique de l’internet
L’Harmattan – 2007 – ISBN : 978-2296040366
Graham Vickery et Sacha Wunsch-Vincent
Participative Web And User-Created Content: Web 2.0 Wikis and
Social Networking
Organization for Economic Cooperation & Devel – 2007 – ISBN :
978-9264037465
Yves Michaud, Maxence Layet, Frédéric Kaplan et Philippe Bultez
Adams
Futur 2.0 : Comprendre les 20 prochaines années
FYP éditions – 2007 – ISBN : 978-2916571041
Chris Anderson, Brigitte Vadé et Michel Le Séac'h
La Longue Traîne : La nouvelle économie est là
Pearson Education – 2007 – ISBN : 978-2744062698
Jean-François Gervais
Web 2.0 Les internautes au pouvoir : Blogs, Réseaux sociaux, Partage
de vidéos, Mashups...
Dunod – 2006 – ISBN : 978-2100507016
Loïc Le Meur et Laurence Beauvais
Blogs et podcasts
Dunod – 2007 – ISBN : 978-2100500598
Annabelle Klein, Nathalie Burnay, et Collectif
Objectif blogs ! : Explorations dynamiques de la blogosphère
L’Harmattan – 2007 – ISBN : 978-2296046702

47
Partie I – Les projets Web

Sites
Douze portails d’entreprise au banc d’essai
http://www.01net.com/article/197636.html
Répondre aux e-mails, c’est bien ; bien y répondre, c’est mieux
http://www.01net.com/article/204246.html
CMS Matrix – Bien choisir son CMS
http://www.cmsmatrix.org
CMS Report – La gestion de contenu d’aujourd’hui
http://cmsreport.com/
Enterprise Integration Patterns – L’EAI en cinq leçons
http://www.enterpriseintegrationpatterns.com
CIGREF – L’évolution de l’informatique
http://www.cigref.fr/
KnowledgeStorm – L’une des meilleures places de marché IT
http://www.knowledgestorm.com/

48
Chapitre 2

Les acteurs
du projet

Figure 2-1
Les acteurs du projet

49
Partie I – Les projets Web

Le succès d’un projet Web dépend essentiellement de la complé-


mentarité des équipes et de la qualité de leur relation. Chaque acteur
y joue un rôle indispensable en apportant un savoir-faire spécifique
(connaissance de l’entreprise, expertise technique, créativité…) et
une culture complémentaire. L’enjeu réside dans la capacité de
chacun à comprendre la tâche de l’autre pour travailler efficace-
ment. L’organisation du travail au quotidien est décisive dans la
réussite du projet.

L’équipe de l’entreprise

L’équipe projet de l’entreprise joue un rôle fondamental dans la


réussite du projet. C’est elle, en effet, qui oriente, au travers de choix
stratégiques (technologie, méthodologie, prestataire…) ce que sera
le futur site.
Elle est en général composée d’un chef de projet, parfois à temps
plein, souvent à temps partiel. Les autres contributeurs participent
ponctuellement au projet soit parce qu’ils font partie d’un comité
(de pilotage ou de projet) soit parce qu’ils interviennent en tant
qu’experts.
Repère : l’équipe minimale
Un chef de projet peut suffire pour piloter un projet Web… s’il est réellement disponible pour
cette tâche. Il devra alors s’entourer de prestataires en qui il peut avoir pleinement confiance, car
sa disponibilité, quelle qu’elle soit, ne lui permettra pas de maîtriser le projet. Le choix des presta-
taires sera, dans ce cas, un facteur clé de succès.

Dans tous les cas, l’expérience montre qu’il vaut mieux privilégier de
petites équipes dédiées à temps plein au projet. En effet, une orga-
nisation qui repose sur une équipe nombreuse travaillant à temps
partiel sur un projet aboutit presque toujours à un désengagement
progressif des collaborateurs parce que le quotidien reprend
toujours le dessus.

Bonne pratique : un binôme à la tête du projet


Une bonne pratique consiste à créer un binôme composé d’un profil fonctionnel et d’un profil
technique. Outre un meilleur éventail de compétences, cette solution apporte un bon équilibre
lors des prises de décision. En général, le profil technique apporte des méthodes qui permettent
de rationaliser et d’objectiver les décisions, tandis que le profil fonctionnel isole les éléments
fonctionnels qui feront la réussite du projet.

50
Chapitre 2 – Les acteurs du projet

Les pages suivantes proposent un aperçu des principales fonctions


qui composent l’équipe de l’entreprise.
Gestion de projet et relation avec les utilisateurs
Ces acteurs sont principalement le comité de pilotage, le comité
projet et le chef de projet. Ils ont pour mission d’encadrer le projet
de sorte que le résultat produit soit conforme aux attentes. Ils
doivent tout mettre en œuvre pour respecter les délais et le budget
impartis.
Le comité de pilotage
Le comité de pilotage représente la maîtrise d’ouvrage (MOA). Il
définit les besoins métier puis commande le projet, en assure un
contrôle régulier et, à la fin, vérifie que le projet correspond à sa
demande. Le comité de pilotage doit donner au comité de projet les
moyens nécessaires à sa mission.
Le comité de pilotage doit être constitué de membres du comité de
direction de l’entreprise en phase avec le projet (DRH, DG, DSI
pour un projet RH par exemple). Dans tous les cas, ses membres
doivent disposer de l’autonomie nécessaire à la prise de décisions
pouvant avoir un impact réel sur l’organisation de la société et son
image.
Le comité de pilotage se réunit chaque mois tout au long du projet.
Il arbitre et décide.
Le comité de projet
Le comité de projet joue le rôle de maître d’œuvre (MOE). Il
assiste le comité de pilotage lors de l’évaluation du coût du projet,
établit les spécifications détaillées et les spécifications techniques,
rédige le cahier des charges, le cas échéant lance l’appel d’offres et
gère les relations avec le(s) prestataire(s). Le comité de projet
valide les recettes techniques et assiste la maîtrise d’ouvrage lors de
la recette fonctionnelle. Enfin, il assure la mise en exploitation de
la solution, garantit la qualité du service et réalise le support aux
utilisateurs.
Le comité de projet est idéalement composé de représentants des
services concernés par le projet et de la direction du système d’infor-
mation (DSI). Tous doivent posséder une excellente culture projet
et connaître parfaitement l’entreprise.

51
Partie I – Les projets Web

Le chef de projet
Le chef de projet assure au quotidien la conduite du chantier sous
la direction du comité de pilotage avec l’appui du comité de
projet. Il rend compte, au nom du comité de projet, au comité de
pilotage auquel il fournit le suivi du planning de réalisation, des
charges ainsi que toute indication technique utile à la direction de
projet.
Le chef de projet dépend du comité de pilotage. Son autonomie
est limitée à la gestion des prestataires internes et/ou externes.
Selon la nature du projet, le chef de projet peut être soit de culture
informatique (par exemple ingénieur d’études…) soit de culture
fonctionnelle. Dans tous les cas, ses qualités sont avant tout une
grande rigueur, de la ténacité et un excellent relationnel.
Profils fonctionnels
Ces acteurs sont essentiellement les correspondants, les utilisateurs
et les directions support. Chacun apporte une vision spécifique du
projet et peut être sollicité pour trouver et/ou évaluer des solutions.
Les correspondants
Pour que le projet soit une réussite, l’entreprise doit impliquer le
plus de relais internes possible. Plus ils seront nombreux et proches
des utilisateurs finals et plus la conduite du changement sera facile
à mener.
Ces correspondants peuvent être issus de toutes les strates hiérarchi-
ques et de tous les corps de métier mais leur ancienneté dans l’entre-
prise augmente leur influence.
Les correspondants interviennent du kick-off (réunion « officielle »
de lancement du projet) au lancement. Certains d’entre eux peuvent
être choisis pour devenir formateurs relais.
Les utilisateurs
Des utilisateurs finals doivent être identifiés dès le début du projet.
Ils pourront être sollicités lors des phases de conception pour valider
le concept et les grandes orientations fonctionnelles et ergonomi-
ques. Ils seront aussi sollicités lors des tests finals.
Les utilisateurs interviennent de l’expression des besoins jusqu’à la
recette fonctionnelle.

52
Chapitre 2 – Les acteurs du projet

Les directions support


De nombreuses directions interviennent tout au long du projet
en apportant leur savoir-faire. C’est notamment le cas de la DSI
qui joue un rôle fondamental lors de l’étude de faisabilité en
cadrant et en facilitant les choix de solution technique, puis lors
de la réalisation en apportant sa méthodologie et un support
opérationnel. C’est aussi souvent elle qui conduit les formations
et assure le support aux utilisateurs lorsque le projet est en
production.
La direction marketing ou commerciale est souvent sollicitée en
phase amont pour réaliser et valider la pertinence du benchmark
puis du positionnement. La direction de la communication inter-
vient dans la définition de l’interface utilisateur et de la charte
graphique ainsi que lors de la campagne de lancement.
Enfin, la direction des ressources humaines joue de plus en plus un
rôle actif, notamment dans le cas des portails d’entreprise, en vali-
dant l’adéquation des informations et des outils proposés avec les
profils de postes des collaborateurs.

Les équipes prestataires

Il y a quelques années, un concepteur-graphiste-développeur


« bricolait » les sites de A à Z. Les étapes de stratégie, de faisabilité
et de conception étaient le plus souvent virtuelles car les choix tech-
niques étaient des plus limités et l’objectif des entreprises très clair :
être présent sur le Web.
Après un premier retour d’expérience, la multiplication des
concepts et des technologies a ouvert un nouvel univers de possibi-
lités. Les projets sont de plus en plus ambitieux et surtout, les tech-
nologies Web s’insèrent de plus en plus dans le système d’informa-
tion. De quelques pages HTML, les projets ont évolués vers de
véritables applications.
Repère : l’équipe minimale
L’équipe minimale, pour être efficace, doit être composée de trois personnes : un chef de projet,
un designer et un développeur. Chacun joue un rôle essentiel et possède un savoir-faire complé-
mentaire. Le chef de projet gère les relations avec l’entreprise cliente ce qui permet au designer et
au développeur de travailler sereinement.

53
Partie I – Les projets Web

Aussi, plus le temps passe et plus les métiers liés aux projets Web se
spécialisent avec, à la clé, le risque de voir se généraliser de véritables
« armées mexicaines », même pour les projets les plus simples.

Bonne pratique : un juste équilibre entre simplicité et spécialisation


Une bonne pratique consiste à limiter la taille de l’équipe du prestataire en s’appuyant sur quel-
ques profils très expérimentés qui peuvent jouer plusieurs rôles et n’avoir recours aux experts
que pour des domaines très pointus. Ainsi, un chef de projet technique peut parfois jouer aussi
le rôle de chef de projet fonctionnel et de consultant technique. Cela limite le nombre de briefs
internes et permet de maintenir une bonne cohérence au projet.

Les sections suivantes proposent un rapide aperçu des principaux


métiers que l’on peut trouver chez la plupart des prestataires.
Gestion de projet et relation avec le client
Le directeur de projet et le chef de projet s’engagent pour leur entre-
prise à produire, dans les temps et la charge impartis, un produit
conforme aux exigences du client. Ils réalisent l’interface entre les
équipes du client et les équipes de l’entreprise.
Le directeur de projet
Le directeur de projet intervient de la définition de la stratégie au
lancement du site. Il coordonne les différents projets ou lots en
cours de réalisation, gère les chefs de projet et assure un suivi global,
quantitatif et qualitatif. Sa mission est aussi de garantir à son client
la disponibilité des équipes, la qualité des livrables et, bien sûr, le
respect des délais et du budget.
Le directeur de projet est autonome. Il gère son projet comme il
l’entend mais doit rendre des comptes au chef de projet de l’entre-
prise cliente et à la direction hiérarchique de son entreprise.
Il possède en général une double culture fonctionnelle et technique.
Il appuie son expertise sur au moins cinq ans d’expérience et de
nombreux projets gérés en tant que chef de projet. Ses qualités
essentielles sont une grande rigueur, un excellent sens de l’écoute, la
capacité à fédérer et à motiver.
Le chef de projet
Le chef de projet intervient de la conception au lancement du site.
Sa mission est de coordonner et de motiver les équipes (graphistes,
rédacteurs, ingénieurs, traducteurs, partenaires…) dans le but
d’aboutir à la livraison de livrables de qualité, dans le respect des
délais et de la charge.

54
Chapitre 2 – Les acteurs du projet

Le degré d’autonomie est lié à la taille et à la typologie des projets.


Globalement, le chef de projet est autonome sur les missions courtes
et dépend du directeur de projet sur les missions longues et/ou
morcelées en lots.
Selon la nature du projet, le chef de projet peut être soit de culture
informatique (par exemple ingénieur d’études…) soit de culture
fonctionnelle (chef de publicité, consultant, etc.). Dans tous les cas,
ses qualités sont avant tout une grande rigueur, de la ténacité et un
excellent relationnel.

Profils fonctionnels
Les acteurs fonctionnels sont souvent soit des consultants fonction-
nels soit directement le chef de projet quand ce dernier possède une
double culture.
Le consultant fonctionnel
Le consultant fonctionnel intervient de la définition de la stratégie
au lancement du site. Il conseille ponctuellement l’entreprise dans
son domaine de spécialité et apporte un support technique aux
équipes internes. Ses interventions correspondent presque toujours
à des livrables : benchmark, audit, étude de faisabilité, etc.
Le consultant peut être autonome sur des missions ponctuelles en
amont du projet (étude de faisabilité, etc.) mais dépend du chef de
projet quand il intervient tout au long du projet.
Il possède forcément une double culture métier et Web. En règle
générale, soit il a commencé sa carrière dans un secteur d’activité
précis (banque, BTP, etc.) puis s’est spécialisé dans les projets Web ;
soit il a commencé sa carrière en gérant des projets Web et s’est
progressivement spécialisé dans un secteur d’activité. Les qualités
essentielles d’un consultant fonctionnel sont un bon sens de
l’écoute, une grande rigueur intellectuelle, ainsi qu’une forte capa-
cité de synthèse et de formalisation.

Profils techniques
Les acteurs techniques du projet sont, en général, le consultant tech-
nique, l’architecte, le chef de projet technique, l’ingénieur d’études.
Ils interviennent dans le projet de la faisabilité à la réalisation.
Le consultant technique
Le consultant technique intervient en amont du projet, lors de la
faisabilité, au début de la phase de réalisation, puis par intermittence,

55
Partie I – Les projets Web

jusqu’au lancement. Son expérience lui permet de recommander la


meilleure solution à chaque problème en tenant compte de l’envi-
ronnement fonctionnel, organisationnel et technique du projet.
Il peut être autonome sur des missions ponctuelles (choix d’outil,
etc.) mais dépend du chef de projet quand il intervient tout au long
du projet.
Le consultant technique maîtrise parfaitement une ou plusieurs
technologies. Il a souvent commencé sa carrière comme ingénieur
d’études puis comme chef de projet. Son parcours – au moins cinq
ans en tant que chef de projet – l’a amené à conseiller de nombreux
clients.
Ses principales qualités sont le sens de l’écoute, une grande rigueur
intellectuelle ainsi qu’une forte capacité de synthèse.
L’architecte
L’architecte intervient de l’étude des solutions au développement.
Sa mission est de traduire les besoins fonctionnels et les contraintes
techniques d’un projet en une architecture technique cible qui
répond aux principaux objectifs de l’entreprise. Il choisit les design
patterns les mieux adaptés et découpe le projet en frameworks. Il
peut intervenir en amont des projets à la place du consultant tech-
nique pour caractériser techniquement le projet et choisir une solu-
tion technique adaptée à l’architecture cible.
L’architecte est autonome dans le choix de l’architecture technique
cible bien qu’il la valide avec les équipes techniques de l’entreprise.
Il possède en général une double culture fonctionnelle et technique.
Il a acquis une grande expérience en tant que développeur (sur de
multiples technologies), maîtrise parfaitement l’architecture tech-
nique des principaux outils e-business (.NET, J2EE, outils d’EAI/
BPM, portail, etc.) et a encadré des projets dans leur ensemble. Une
 RUP : Rational Unified formation aux méthodologies avancées (RUP1, etc.) est indispen-
Process, méthodologie sable car l’architecte doit être capable de formaliser, dans un langage
de développement orientée
objet et Web. conceptuel normé (design patterns, etc.), l’architecture cible du
projet. Enfin, l’architecte revendique au minimum sept à dix années
d’expérience.
Le chef de projet technique
Le chef de projet technique intervient de la conception à la réalisa-
tion du site. Sa mission est de préparer et de coordonner le travail
de son équipe. Dans le cadre d’un projet limité, il arrive qu’il soit en
charge de la conception technique du site. Son objectif est d’aboutir

56
Chapitre 2 – Les acteurs du projet

à la livraison du code source avec la qualité souhaitée, dans le respect


des délais et de la charge.
Globalement, le chef de projet technique est autonome sur les
missions courtes et dépend du directeur de projet sur les missions
longues et/ou morcelées en lots.
Le parcours type d’un chef de projet technique commence par une
école d’ingénieur puis plusieurs années en SSII en tant qu’ingénieur
d’études. Ses qualités sont avant tout une grande rigueur, de la téna-
cité et un excellent relationnel.
L’ingénieur d’études
L’ingénieur d’études intervient lors du développement. Sa mission
est de réaliser le développement de la solution dans le cadre défini
par le chef de projet. Il arrive qu’il prenne en charge la documenta-
tion et la formation des utilisateurs dans le cas d’un projet limité.
L’ingénieur d’études dépend du chef de projet. Ses principales
qualités sont de fortes connaissances dans une technologie (J2EE,
ASP, PHP…) et beaucoup de rigueur.

Profils artistiques
Les équipes artistiques peuvent être très complètes. On y retrouve
fréquemment un directeur de création qui chapote des directeurs
artistiques et des directeurs éditoriaux ainsi que des Web designer,
des ergonomes et des concepteurs-rédacteurs.
Le directeur de création
Le directeur de création intervient lors de la conception. Il conseille
le client sur tous les aspects créatifs du site : concept général, ligne
graphique, ligne éditoriale… C’est lui qui garantit la cohérence
finale des créations et manage les équipes créatives en s’efforçant de
créer de bonnes synergies.
Le directeur de création est autonome en ce qui concerne les choix
créatifs et l’organisation de ses équipes. En revanche, il dépend du
chef de projet pour le planning général.
Le directeur de création commence souvent sa carrière comme desi-
gner, puis directeur artistique. Il peut également être issu de la
conception-rédaction ou être autodidacte. Quel que soit son
parcours, ses principales qualités sont le sens de l’écoute, une grande
créativité et une excellente capacité de formalisation. Il possède
forcément plus de dix ans d’expérience. Enfin, son ambition doit

57
Partie I – Les projets Web

être de servir la marque de l’entreprise plutôt que son book ou celui


de son agence !
Le directeur artistique
Le directeur artistique intervient du benchmark à la conception. Sa
mission est, bien sûr, de concevoir les interfaces graphiques des sites
Internet, intranet, extranet, WebTV, PDA, borne interactive…
mais aussi d’aider l’entreprise à effectuer les bons choix graphiques.
Enfin, il formalise les chartes graphiques.
Le directeur artistique dépend du directeur de création. Il a presque
toujours occupé le poste de designer pendant plusieurs années. Ses
qualités essentielles sont une bonne capacité d’écoute et une grande
créativité.
Le Web designer
Le Web designer intervient de la conception à la réalisation. Il
décline le travail du directeur artistique et produit les éléments
graphiques nécessaires à la réalisation des interfaces. Son degré
d’autonomie est lié à la taille et à la typologie des projets. Globale-
ment, le Web designer est autonome sur les missions courtes à faible
valeur ajoutée et dépend du directeur artistique sur les missions
longues et à forte valeur ajoutée.
Le Web designer dépend du directeur artistique ou du directeur de
création. Bien que le parcours le plus fréquent soit une école de
graphisme puis des stages en tant qu’infographiste, maquettiste… il
n’existe pas de parcours type et tous les chemins mènent à ce poste !
Les principales qualités d’un Web designer sont une excellente
connaissance des contraintes des technologies et de l’environne-
ment Web, la maîtrise des logiciels et, évidemment, un sens créatif
développé.
L’ergonome
L’ergonome intervient lors de la conception au côté du designer, du
consultant fonctionnel ou du directeur éditorial pour définir l’inter-
face utilisateur. Il veille au respect des normes et des règles d’ergo-
nomie en usage sur Internet dans le but de faciliter l’accès à l’infor-
mation et aux produits. Il est le garant de l’efficacité de l’interface.
L’ergonome dépend du chef de projet. Certains ergonomes possè-
dent un profil scientifique, d’autres sont autodidactes. L’expérience
montre qu’il n’y a pas de règle en la matière. L’essentiel est qu’il soit
au service des utilisateurs avant d’être au service de l’entreprise et

58
Chapitre 2 – Les acteurs du projet

qu’il maîtrise parfaitement tous les standards, règles et comporte-


ments au fur et à mesure de leur évolution.
Le directeur éditorial
Le directeur éditorial intervient de la conception à la réalisation. Sa
mission est la conception éditoriale des sites et la rédaction d’une
partie ou de la totalité des textes. Dans le cadre d’un projet important,
il doit, en plus, coordonner les concepteurs-rédacteurs ou les pigistes.
Le directeur éditorial dépend soit du directeur de création soit du
chef de projet. Il a souvent commencé sa carrière comme pigiste,
journaliste ou concepteur-rédacteur. Il revendique au moins dix
années d’expérience. Ses qualités essentielles sont, outre de fortes
capacités rédactionnelles, un bon sens de l’écoute, un esprit réaliste
et pragmatique, ainsi qu’une bonne capacité de synthèse.
Le concepteur-rédacteur
Le concepteur-rédacteur intervient lors de la réalisation du site. Il
rédige les textes, les accroches, les relances, etc. dans le respect de la
charte éditoriale établie par le directeur éditorial et l’entreprise.
Le degré d’autonomie est lié à la taille et à la typologie des projets.
Globalement, le rédacteur est autonome sur les missions courtes à
faible valeur ajoutée et dépend du directeur éditorial sur les missions
longues et à forte valeur ajoutée.
La majorité des concepteurs-rédacteurs commence leur carrière
dans une agence de publicité. Certains se spécialisent dans la créa-
tion de contenu pour le Web, d’autres maintiennent une double
activité.

L’organisation générale

La composition et l’organisation des équipes d’un projet Web sont


devenues un facteur clé de succès. En effet, les changements intem-
pestifs de collaborateurs, la sous-estimation des besoins humains,
l’absence de décision faute de responsable identifié conduisent,
chaque année, des milliers de projets à la faillite. Or, les difficultés
sont presque toujours d’ordre organisationnel.
Dans les faits, le début du projet pose rarement de problème. Mais dès
que le calendrier accélère, que la date butoir est en vue, chaque acteur
fait ses comptes, vérifie la charge et le planning… Un peu de retard,

59
Partie I – Les projets Web

quelques dysfonctionnements apparaissent. Rien de très grave. À


moins que les décisions correctives ne puissent pas être prises à temps !
En pratique, quelques règles simples permettent de limiter les risques.
Définir clairement les rôles et les responsabilités
La première action à mener consiste à définir clairement les rôles et
les responsabilités attribués à chaque acteur en commençant par la
maîtrise d’ouvrage et la maîtrise d’œuvre internes. Le même travail
sera en suite réalisé avec les prestataires de manière à bien préciser
« qui est responsable de quoi » et « qui reporte à qui ». Cette action
est directement liée à la définition des livrables auxquels un respon-
sable doit être systématiquement associé.

Bonne pratique : trois critères pour séparer MOA et MOE


Trois critères peuvent être pris en compte pour déterminer le degré de séparation entre MOA et
MOE.
– La nature du projet : plus elle sera complexe (site transactionnel vs site produit) et plus la
séparation sera forte.
– L’enjeu : plus il sera stratégique (réduire les coûts et augmenter le service aux clients grâce à
un guichet on-line par exemple) et plus MOA et MOE auront intérêt à être séparées.
– Les moyens : plus le budget et les équipes internes seront importants et plus MOA et MOE
pourront être séparées.

Une fois les responsabilités internes définies, il s’agit de départager


ce qui sera confié aux prestataires de ce qui sera réalisé en interne. Se
pose alors le choix difficile du type de prestataires à retenir et,
parfois, de l’articulation entre les différents prestataires.
Cependant, dans certains cas, la répartition des rôles et des respon-
sabilités s’effectue de facto, notamment entre les prestataires car :
• les domaines de compétence à couvrir sont très pointus (sécurité,
CRM, ERP…) ;
• la direction des achats a édicté des règles de sélection précises
(qui séparent conception et réalisation par exemple) ;
• la direction du système d’information ou des études a mis en
place un cadre méthodologique pour les projets Web ;
• la politique de sécurité consiste à multiplier les intervenants.
Favoriser l’interlocuteur unique
La réussite d’un projet Web est toujours liée à une organisation efficace
entre les différents acteurs. Au sein de l’entreprise, le projet doit être
porté, au quotidien, par un directeur de projet ou un chef de projet

60
Chapitre 2 – Les acteurs du projet

unique. Cela facilite son identification et ses échanges avec les diffé-
rents contributeurs internes. Vis-à-vis des prestataires, cela permet de
limiter les allers-retours en centralisant les échanges. Enfin, cette orga-
nisation diminue significativement les risques de blocage du projet
pour cause de non-décision. Le prestataire doit lui aussi proposer un
interlocuteur unique dans le but de simplifier les échanges avec l’entre-
prise. C’est ce dernier qui recueillera toutes les demandes et les répar-
tira ensuite vers les experts compétents de son équipe. Inversement, il
centralise toutes les questions et les transmet à l’entreprise.
Ainsi, les interlocuteurs uniques de l’entreprise et du prestataire
construisent, au fur et à mesure de l’avancement du projet, une rela-
tion qui facilitera la résolution des éventuelles difficultés.
En plus d’être simple et efficace, cette organisation a le mérite de
responsabiliser les interlocuteurs et de réduire les risques de biais
dans les circuits de communication.

Ne pas sous-estimer la charge de travail


Les projets de site dépassent aujourd’hui largement le cadre de la
simple plaquette pour s’attacher au métier de l’entreprise. Ils néces-
sitent donc des démarches transversales qui impliquent plusieurs
services ou directions. Pour être cohérentes, les différentes démar-
ches doivent être pilotées par un groupe de projet central.
De plus, en menant un travail de réingéniérie des processus métier,
le rôle ou les habitudes des collaborateurs sont souvent modifiés. Le
projet Web peut donc avoir des conséquences directes sur la vie de
l’entreprise et sur les comportements des utilisateurs. Une vraie stra-
tégie de conduite du changement devient alors nécessaire.
Ainsi, il ne faut surtout pas négliger l’importance des charges de
travail liées d’une part à la coordination interne et, d’autre part, à
l’accompagnement et la formation des utilisateurs. Loin d’être
négligeables, elles peuvent parfois être supérieures à celles néces-
saires à la réalisation du site.
TF1 Publicité a par exemple perdu un an sur son planning de
refonte de ses applications métier à cause d’une sous-estimation des
ressources humaines nécessaires au projet (deux personnes au lieu de
cinq). Source : 01 informatique n° 1635, 25 mai 2001.

Intégrer les utilisateurs


Le Web est simple à utiliser… et complexe à concevoir, car contrai-
rement aux autres médias, il propose de nombreuses interactions.

61
Partie I – Les projets Web

Or, le moindre défaut de conception se traduit par l’abandon des


utilisateurs et une perte pour l’entreprise. En effet, les internautes ne
sont pas patients et ont appris à « zapper » sur le site du concurrent
à la moindre contrariété.
Il est par conséquent essentiel de s’assurer que le contenu, les
services et l’interface proposés soient en phase avec les attentes des
utilisateurs. Il suffit pour cela de les intégrer à chaque étape du
projet, ou, à défaut, lors de quelques moments clés.
Lors des phases amont, des tables rondes ou des entretiens qualitatifs
permettent de se faire une idée juste des attentes des utilisateurs.
Ensuite, il est très important de tester les différents concepts et proto-
types des sites. Cela évitera de persévérer dans de mauvaises direc-
tions. C’est aussi un moyen très efficace pour ajuster le concept. Les
proportions contenus/services, l’ergonomie, le ton rédactionnel, etc.
pourront être affinés, assurant ainsi une plus grande efficacité.
Enfin, l’une des étapes essentielles est le test du produit final par un
échantillon représentatif d’utilisateurs afin d’identifier les éventuels
éléments de friction puis de les corriger pour garantir une expé-
rience utilisateur satisfaisante.

Piloter en fonction de la nature du projet


La nature de chaque projet détermine des priorités spécifiques qui
se concrétisent par un pilotage, des livrables et une répartition
budgétaire adaptés. Voici quelques exemples :

Figure 2-2
Piloter le projet de site de marque

Un projet de site de marque doit laisser la marque s’exprimer. Les


choix ne doivent donc pas être dictés par la technologie mais par les
 Flash : format graphique objectifs marketing. Choisir Flash1 avant de commencer le projet ou
de la marque Macromedia imposer des contraintes ergonomiques drastiques n’a donc aucun
qui permet de créer des
animations reposant sur
sens. Les efforts doivent être investis avant tout sur la stratégie marke-
des éléments vectoriels. ting (Quels sont les services capables de renforcer les valeurs de ma

62
Chapitre 2 – Les acteurs du projet

marque ? Comment instaurer un dialogue récurrent marque/consom-


mateur ?…) et le design (transcription des valeurs de la marque).

Figure 2-3
Piloter le projet de site marchand

À l’inverse, un projet de site marchand doit être piloté en fonction


de trois priorités : l’offre (le catalogue et l’information autour du
catalogue), les services et l’ergonomie. Dans ce cas, la marque ne sert
qu’à rassurer l’internaute. Elle ne doit pas influencer les grandes
décisions du projet.

Figure 2-4
Piloter le projet de portail d’entreprise

Enfin, dans le cas d’un portail d’entreprise et plus généralement de


tout projet fortement transactionnel, la priorité doit être donnée à
la définition des aspects fonctionnels et à l’ergonomie du site.
Fiche projet (fiche_projet.rtf )
Ordre du jour (ordre_jour.rtf )
Compte rendu de réunion (compte_rendu.rtf )
Procès-verbal de recette (PV_recette.rtf )
Bilan de fin de projet (bilan_projet.rtf )

63
Partie I – Les projets Web

Pour aller plus loin

Ouvrages
Jean Le Bissonnais
Les compétences pour gérer un projet
Éditions Afnor – 2003 – ISBN : 978-2125050474
Jean-Michel Oullion
Les métiers de l’Internet
L’Etudiant Pratique – 2007 – ISBN : 978-2846247382

Site
Guide des métiers du Web
http://www.01net.com/rubrique/1971.html

Avis d’experts

Projet Web :
comment faire respecter les délais
Le retard d’un projet Web peut avoir un fort impact : lancement de produit retardé,
mauvaise communication financière, etc. Pour éviter d’en arriver à une telle situation, le
chef de projet Web doit définir avec son prestataire un cadre de travail qui garantira la tenue
des délais.
1. Intégrer la gestion des risques à la méthode
La connaissance de l’environnement du projet et la mise en œuvre d’une gestion des risques
permettent une meilleure maîtrise des délais, synthétise Christian Anèse, expert en manage-
ment de projets. Concrètement, le chef de projet a intérêt à réaliser un tableau de bord de
suivi des risques et une liste d’actions correctives. Ainsi, il pourra anticiper les dérapages de
planning et les corriger suffisamment tôt pour éviter le pire, ajoute Christian Anèse. De son
côté, le prestataire peut proposer une série d’actions complémentaires. Pour nous, l’idéal est
de développer une fonctionnalité et la mettre en production dès le début du projet. Cela nous
permet de mesurer avec le client l’adéquation entre le niveau de formalisme souhaité (documen-
tation du code, manuel utilisateur, etc.) et ce qui est faisable dans la charge impartie. C’est aussi
l’occasion d’identifier en conditions réelles les risques liés à la mise en production, commente
Frédéric Bon, fondateur de Clever-Age.

64
Chapitre 2 – Les acteurs du projet

2. Mettre en place une politique contractuelle de dissuasion


Pour Franklin Brousse, avocat spécialisé en nouvelles technologies, un rétroplan-
ning précisant les délais impératifs est à joindre au contrat. Ces délais font l’objet d’un
engagement de résultat de la part du prestataire et déclenchent des pénalités en cas de
retard. Si le fournisseur refuse, on peut essayer d’imposer des jalons contractuels inter-
médiaires – basés sur les livrables par exemple – ou assortir les délais impératifs d’excep-
tions. La pénalité la plus courante correspond au versement de x euros par jour de
retard dans la limite d’un plafond égal à 5 ou 10 % du contrat. Une clause de
bonus malus peut aussi être utilisée : en cas de réussite, le prestataire est rémunéré
forfaitairement à hauteur de 5 à 10 % du contrat ; en cas de retard, il est sanc-
tionné dans les mêmes proportions. Au quotidien, chaque retard doit être notifié par
lettre recommandée avec accusé de réception ou mentionné dans le compte rendu validé
par le comité de suivi de projet. Si le périmètre fonctionnel a évolué ou si le retard n’est
pas du fait du prestataire, l’idéal est de renégocier les délais et de créer un avenant au
contrat, précise Franklin Brousse.
3. Planifier sur deux échelles
Selon Christian Anèse, le principal outil du chef de projet est un planning décliné
sur deux vues : La vue macroscopique fait apparaître les grandes phases, précise les
points de contrôle contractuels et les livrables attendues. La vue microscopique détaille
la vue précédente en découpant chaque phase en étapes, elles-mêmes segmentées en
tâches élémentaires. Je conseille de bien y faire apparaître le « Qui Fait Quoi » relatif à
la charge de travail incombant au MOA et au MOE. Les phases ou étapes de tests, de
validation et de réception, ainsi que les réunions de suivi nécessitant l’implication du
MOA et du MOE doivent également apparaître dans le planning, ajoute-t-il. Les
plannings prévisionnels initiaux seront réactualisés au cours du projet et validés par
tous les acteurs.
4. Valider le réalisme des plannings
Pour Frédéric Bon, un prestataire ne peut pas répondre sérieusement à un appel d’offres
sans spécifications fonctionnelles assorties de contraintes techniques précises. Quand
l’entreprise n’en dispose pas, elle doit prévoir lors de la réunion de lancement un ajuste-
ment conséquent du planning théorique. Lors de l’appel d’offres le but n’est donc pas
d’obtenir le planning définitif mais plutôt d’en évaluer le réalisme en fonction de
la liste des tâches, y compris la documentation et la formation. Quand cela se
justifie, le prestataire doit en plus expliquer comment il gère les risques simples tels
que le manque de disponibilité en raison de vacances d’été ou de la formation de
ses équipes sur des technologies peu répandues. Pour valider le planning, le chef de
projet pourra utiliser plusieurs méthodes d’évaluation reconnues – algorithmique,
analogique ou empirique – et le soumettre à l’avis des experts qui réaliseront les tâches.
Il devra ensuite le réévaluer tout au long du projet, précise Christian Anèse.
Article paru sur http://www.indexel.net

65
Chapitre 3

La dimension
juridique
du projet Web

La mise en œuvre d’un projet Web implique la prise en compte d’étapes


nécessaires à sa sécurisation juridique et au respect des différentes régle-
mentations applicables aux sites Web. Elle s’articule autour de la réalisation
de démarches préalables obligatoires et de précautions dans la rédaction et
la négociation des différents types de contrats. La conduite juridique d’un
tel projet nécessite une bonne appréhension des obligations et des respon-
sabilités de chacune des parties prenantes.
Enfin, des informations spécifiques liées aux données à caractère personnel
et à l’identité de l’exploitant du site Web doivent être portées à la connais-
sance du public sous peine de sanction. Des formalités préalables à la négo-
ciation des contrats Web, la réussite d’un projet Web passe ainsi par la prise
en compte de sa dimension juridique.

Les formalités préalables


Des formalités spécifiques doivent être prises en compte en fonction de la
nature des services proposés ou de l’identité du créateur d’un site Web.

Dépôt d’un nom de domaine


Un nom de domaine1 est constitué d’une dénomination associée à un  Nom de
suffixe qui peut être : domaine : nom
simplifié qui désigne
• une extension « géographique » comme le « .fr » pour la France ; un site Web ou
• une extension « générique » comme le « .com » pour les entreprises un ensemble
commerciales du monde entier. de sites Web.

67
Partie I – Les projets Web

L’exploitation d’un site nécessite de procéder à une réservation d’un


ou plusieurs noms de domaine permettant :
• son identification sur le Web ;
• la personnalisation de ses adresses électroniques.
La réservation consiste à enregistrer un nom de domaine qui est
attribué pour une durée limitée et renouvelable (en principe deux
ans). Quelle que soit l’extension retenue (.fr, .com, .org, .net), le
nom de domaine reprend le plus souvent :
• une dénomination sociale ;
• une marque déposée ;
• un nom patronymique.
Préalablement au choix d’un nom de domaine, il convient de
s’assurer que la dénomination choisie ne fait pas obstacle à l’exploi-
tation de droits d’un tiers sur une marque ou dénomination sociale,
ce afin de prévenir tout risque de conflit ultérieur. Cette vérification
s’effectue par le biais d’une recherche d’antériorité destinée à iden-
tifier les dénominations déjà existantes identiques ou similaires au
nom de domaine envisagé.
L’attribution d’un nom de domaine en .fr peut être effectuée par
tout prestataire de services Internet habilité à enregistrer des noms
de domaine se terminant par .fr, comprenant les extensions .asso.fr,
.nom.fr, .prd.fr, .presse.fr, .tm.fr, .com.fr. La liste des prestataires
habilités figure sur le site Web de l’AFNIC à l’adresse http://
www.afnic.fr/obtenir/prestataires.
Les prestataires se chargent d’effectuer toutes les démarches auprès
de l’AFNIC. Toute entité officiellement déclarée en France ou titu-
laire d’une marque officiellement enregistrée en France peut réserver
un nom de domaine en .fr.
Aux termes de la charte de nommage de l’AFNIC accessible à
l’adresse http://www.afnic.fr/obtenir/chartes, le demandeur doit :
1. Prendre connaissance et accepter les termes de la charte.
2. Vérifier que sa demande, et particulièrement le choix du terme
ou des termes qu’il entend utiliser pour l’attribution d’un nom de
domaine :
– est licite au regard du droit et notamment des règles d’ordre
public ;
– ne porte pas atteinte aux droits de tiers notamment aux droits
d’auteur, aux droits des marques et aux droits de la personne,
sans que cette liste soit limitative ;
– est conforme aux dispositions de la charte.

68
Chapitre 3 – La dimension juridique du projet Web

3. Fournir à son prestataire Internet les pièces justificatives qui lui


seront demandées en application de la charte.
4. Vérifier l’exactitude des informations qu’il communique à son
prestataire Internet et s’engager à les actualiser si nécessaire.
Préalablement à la demande d’enregistrement, il convient donc de
s’assurer de la disponibilité du nom de domaine envisagé. Le nom
de domaine choisi doit respecter les dispositions de la charte de
nommage de l’AFNIC pour la zone .fr disponible à l’adresse http://
www.afnic.fr/obtenir/chartes/nommage-fr. Cette procédure a pour
objet de s’assurer que les noms de domaine sont attribués sur la base
d’une identification claire des personnes physiques ou morales solli-
citant l’enregistrement. Pour plus d’informations, l’AFNIC a édité
un guide interactif accessible à l’adresse http://www.afnic.fr/guide/
genic.

Tableau 3-1
Tableau récapitulatif des catégories de domaine enregistrées sous conditions –
Extrait de la Charte de l’AFNIC

DOMAINES DEMANDEUR JUSTIFICATIONS

fr Personnes Ne peuvent être titulaires d’un nom de domaine au sein de


physiques la zone .fr, c’est-à-dire de premier ou de second niveau,
ou personnes soit à l’occasion d’un enregistrement, soit à la suite d’une
morales transmission d’un nom de domaine, que :
• les personnes morales :
– dont le siège social est situé en France ; ou
– qui disposent d’une adresse en France figurant expres-
sément au sein des bases de données électroniques publi-
ques des greffes des tribunaux de commerce ou de
l’Institut national de la statistique et des études économi-
ques (INSEE) ; ou
– les institutions et services de l’État, les collectivités terri-
toriales ainsi que leurs établissements ; ou
– qui sont titulaires d’une marque déposée auprès de
l’Institut national de la propriété industrielle ou titulaires
d’une marque communautaire ou internationale enregis-
trée visant expressément le territoire français.
• les personnes physiques :
– de nationalité française ; ou
– de nationalité étrangère dont le domicile habituel est
situé en France ; ou
– qui sont titulaires d’une marque déposée auprès de
l’Institut national de la propriété industrielle ou titulaires
d’une marque communautaire ou internationale enregis-
trée visant expressément le territoire français.

69
Partie I – Les projets Web

DOMAINES DEMANDEUR JUSTIFICATIONS

.asso.fr Association L’extension .asso.fr est réservée aux associations.


Afin d’obtenir le code d’autorisation, le bureau d’enregis-
trement doit fournir à l’AFNIC :
• la dénomination complète de l’association ;
et
• le numéro de département dans lequel elle a été déclarée
ou son identifiant au répertoire SIRENE.
En cas d’identification infructueuse, l’AFNIC se réserve la
possibilité de demander les documents suivants :
• copie de la parution au JO ;
• copie de la déclaration en Préfecture (ou autre selon les
règles locales) ;
• copie de l’identifiant au répertoire SIRENE.
Le nom de domaine doit correspondre en tout ou partie au
nom de l’association ou à son enseigne, telle qu’elle appa-
raît sur l’acte justificatif, ou à son sigle.
.nom.fr Personnes Les justificatifs admis par l’AFNIC sont :
physiques • pour les personnes de nationalité française : copie de
leur carte d’identité ou passeport ;
• pour les personnes de nationalité étrangère établies en
France : justificatif d’identité (passeport ou carte d’iden-
tité) et justificatif de domicile de moins de trois mois
(EDF-GDF, facture téléphonique, etc.).
Cette extension répond à la syntaxe suivante : [patro-
nyme.nom.fr] ou [patronyme-champlibre.nom.fr].
Le nom patronymique s’entend du nom de famille, du nom
de jeune fille ou du pseudonyme tel qu’il apparaît sur le
document d’identité du demandeur.
.prd.fr Projet ou Justifier d’un document attestant de la réalité dudit projet
programme ou programme et correspondre avec l’intitulé dudit projet
de recherche et ou programme.
développement
.presse.fr Organisme L’extension .presse.fr est réservée aux publications de
de presse presse qui doivent justifier de cette qualité par la copie du
document ISSN de la Bibliothèque nationale de France.
Le nom de domaine choisi doit correspondre au titre clé
du document ISSN.
.tm.fr Marque L'extension .tm.fr est réservée aux titulaires de marques
déposée qui souhaitent utiliser leur marque telle qu'enregistrée ou
une partie du « champ marque», à titre de nom de
domaine.
Les justificatifs nécessaires à l’obtention du code d’autori-
sation sont :
• la demande d'enregistrement de la marque validée par
l'INPI ;
• le certificat définitif OHMI ou OMPI sous réserve que la
France figure parmi les pays concernés par le dépôt.

70
Chapitre 3 – La dimension juridique du projet Web

DOMAINES DEMANDEUR JUSTIFICATIONS

.tm.fr Marque Pour les noms de domaine en .fr créés sur la base d'une
déposée demande d'enregistrement validée par l'INPI, il est précisé
que :
• si la demande d'enregistrement de la marque adressée à
l'INPI fait l'objet d'un rejet lors du contrôle de recevabilité,
et n'obtient pas le statut « déposée », le nom de domaine
est purement et simplement supprimé sans préavis ou
indemnités par l'AFNIC, laquelle en informe le bureau
d’enregistrement. Le nom de domaine retombe alors dans
le domaine public ;
• si la marque ne fait pas l'objet d'une publication au BOPI
dans le délai réglementaire des 6 (six) semaines de l'INPI,
et n'obtient pas le statut « publiée », le nom de domaine
est bloqué par l'AFNIC pendant une période de 30 (trente)
jours. Faute de régularisation ou information complémen-
taire, le nom de domaine est supprimé sans préavis ou
indemnités. Le bureau d’enregistrement en est automati-
quement informé ;
• • si la marque n'est pas enregistrée dans le délai régle-
mentaire de 6 (six) mois de l'INPI, et n'obtient pas le sta-
tut « enregistrée », le nom de domaine est bloqué par
l'AFNIC pendant une période de 30 (trente) jours. Faute de
régularisation ou information complémentaire, le nom de
domaine est supprimé sans préavis ou indemnités. Le
bureau d’enregistrement en est automatiquement informé.
.com.fr Toute L’enregistrement sous l’extension .com.fr ne requiert pas
personne de justification du nom.
physique ou L’enregistrement n’est autorisé que si le terme n’est pas
morale déjà enregistré à l’identique dans l’une des extensions du
domaine public.
L’enregistrement sous l’extension .com.fr n’empêche pas
un organisme demandeur d’enregistrer postérieurement le
même terme dans une des autres extensions du domaine
public.

L’attribution d’un nom de domaine en .com, .net, .org peut être


effectué auprès de tout prestataire de services Internet habilité par
toute personne physique ou morale dans le monde entier. Elle ne
nécessite aucun justificatif. La seule règle applicable est celle du
premier arrivé, premier servi.

Déclaration préalable auprès de la CNIL


L’exploitation d’un site Web implique généralement la mise en
œuvre de traitements automatisés de données à caractère personnel,
collectées notamment par le biais de formulaires en ligne ou
d’espaces de discussion.

71
Partie I – Les projets Web

Selon les dispositions de l’article 2 de la Loi n° 78-17 du


6 janvier 1978 relative à l’informatique, aux fichiers et aux libertés,
« constitue une donnée à caractère personnel toute information relative
à une personne physique identifiée ou qui peut être identifiée, directe-
ment ou indirectement, par référence :
– à un numéro d’identification, ou
– à un ou plusieurs éléments qui lui sont propres.

Pour déterminer si une personne est identifiable, il convient de consi-


dérer l’ensemble des moyens en vue de permettre son identification dont
dispose ou auxquels peut avoir accès le responsable du traitement ou
toute autre personne ».
Les données permettant d’identifier une personne sont notam-
ment :
• son adresse ;
• son numéro de téléphone ;
• son adresse électronique ;
• son profil.
Qu’il s’agisse de l’envoi de newsletters, de forums, de chats, de blogs
ou d’achat en ligne, la collecte des données à caractère personnel
entraîne l’application de la loi du 6 janvier 1978 et le respect de
trois grands principes :
• la déclaration préalable des traitements auprès de la Commission
nationale de l’informatique et des libertés (CNIL) ;
• l’information préalable des internautes sur l’objet d’un traite-
ment ;
• la mise en œuvre de mesures de sécurité quant à l’accès aux don-
nées collectées.
Les traitements de données personnelles mis en œuvre à partir d’un
site Web font l’objet d’une déclaration dont la forme dépend du
secteur d’activité. La CNIL met à disposition un outil pour vous
guider dans le choix de la déclaration adaptée à votre situation.
(http://www.cnil.fr/vos-responsabilites/declarer-a-la-cnil/)
Il s’agit souvent d’une déclaration simplifiée issue de la norme
NS 048, dans la mesure où les traitements concernés n’ont pour seul
objet que la gestion des fichiers de clients et/ou de prospects.
Rappelons que le formulaire spécifique institué par la CNIL pour
les sites Web a été supprimé en 2006.

72
Chapitre 3 – La dimension juridique du projet Web

En l’absence de déclaration préalable, tout contrevenant s’exposera


à une peine de trois ans d’emprisonnement et de 45 000 €
d’amende en application des dispositions de l’article 226-16 du
Code pénal, et ce, même en l’absence d’élément intentionnel ou en
cas de négligence.

L’information à destination des internautes

Outre l’obligation de déclaration préalable auprès de la CNIL, l’exploi-


tant du site Web doit s’attacher à informer les internautes sur les condi-
tions de traitement de leurs données ainsi que sur son identité.

73
Partie I – Les projets Web

74
Chapitre 3 – La dimension juridique du projet Web

Figure 3-1
Procédure de déclaration d’un site Web

Sur les données personnelles collectées


Les internautes doivent être informés du traitement des données
personnelles les concernant.
L’information des internautes sur l’objet de ce traitement doit leur
être communiquée préalablement en rappelant :
• l’identité du responsable du traitement (l’exploitant du site Web) ;
• la finalité poursuivie par le traitement auquel les données sont
destinées (ex : prospection par e-mail/courrier postal) ;
• le caractère obligatoire ou facultatif des réponses ;
• les conséquences éventuelles, à leur égard, d’un défaut de
réponse ;

75
Partie I – Les projets Web

• les destinataires ou catégories de destinataires des données ;


• les droits d’accès et de rectification des données ;
• le droit de s’opposer à faire l’objet de prospection commerciale ;
• les éventuels transferts de données à caractère personnel envisagés
à destination d’un État non membre de la Communauté euro-
péenne.
Des modèles de mentions relatives à l’information des internautes
ainsi qu’un guide pratique sont disponibles sur le site Web de la
CNIL à l’adresse suivante : http://www.cnil.fr/vos-responsabilites/
informations-legales/.
Ces modèles doivent être complétés et affinés en adéquation avec
l’objet du traitement des données des internautes.

Sur l’identité de l’exploitant et la propriété du site


Depuis la loi du 21 juin 2004 pour la confiance dans l’économie
numérique, dite LCEN, modifiant la loi n° 86-1067 du 30 sep-
tembre 1986 relative à la liberté de communication, les personnes
dont l’activité est consiste en un service de communication au
public en ligne, mettent à disposition du public, dans un standard
ouvert :
a) leurs nom, prénoms, domicile et numéro de téléphone s’il
s’agit de personnes physiques, et, si elles sont assujetties aux
formalités d’inscription au registre du commerce et des sociétés
ou au répertoire des métiers, le numéro de leur inscription ;
b) leur dénomination ou raison sociale, leur siège social et leur
numéro de téléphone s’il s’agit de personnes morales, et, s’il s’agit
d’entreprises assujetties aux formalités d’inscription au registre
du commerce et des sociétés ou au répertoire des métiers, le
numéro de leur inscription, leur capital social ainsi que l’adresse
de leur siège social ;
c) le nom du directeur ou du codirecteur de la publication et, le
cas échéant, celui du responsable de la rédaction conformément
à l’article 93-2 de la loi n° 82-652 du 29 juillet 1982 précitée ;
d) le nom, la dénomination ou la raison sociale et l’adresse et le
numéro de téléphone du prestataire.
La loi du 21 juin 2004 précise que les éditeurs de sites Web non
professionnel peuvent ne tenir à la disposition du public que le
nom, la dénomination ou la raison sociale et l’adresse de leur héber-
geur (pour préserver leur anonymat), sous réserve de lui avoir
communiqué les éléments d’identification personnelle susvisés.

76
Chapitre 3 – La dimension juridique du projet Web

Ces informations doivent figurer sur le site Web de l’entreprise ou


de la personne concernée par le biais d’une notice légale. Cette
dernière a pour objet d’informer et de responsabiliser le public
notamment quant à l’existence de droits réservés sur les éléments
composant le site Web (contenu protégé par le droit d’auteur, logo
et dénomination protégés par le droit des marques, etc.). Elle cons-
titue une sorte de carte d’identité du site Web qui reprend les prin-
cipales informations concernant l’exploitant du site Web. Elle ne
dispense pas pour autant de réaliser les procédures et formalités
nécessaires telles que le dépôt de marque et de brevet auprès de
l’Institut national de la propriété industrielle (INPI).

Figure 3-2
Exemple de notice légale : http://www.liberation.fr

En pratique, cette notice peut être accessible à partir de la page


d’accueil et comprend notamment :
• le rappel des droits de propriété intellectuelle relatifs aux
éléments du site Web (bases de données, marques déposées) ;

77
Partie I – Les projets Web

• la référence à la déclaration effectuée auprès de la CNIL en vue


du traitement des données relatives aux internautes.

Sur la publicité et la prospection en ligne

La Loi pour la confiance dans l’économie numérique (LCEN) du 21


juin 2004 a remis en cause les conditions de gestion de la relation
client au sein des entreprises utilisant l’Internet comme canal de
prospection.
Qu’il s’agisse de conditions spécifiques d’information ou de recueil
du consentement (opt-in) des internautes, la LCEN a introduit de
nouvelles obligations venant s’additionner à celles issues de la loi
Informatique et Libertés modifiée par une loi du 6 août 2004.
La publicité et la prospection par voie électronique sont désormais
clairement définies et strictement encadrées dans un objectif de
renforcement de la protection des internautes consommateurs ou
professionnels.

Sur la publicité
Toute publicité – sites Web, e-mails, SMS, 3G, etc. – accessible en
ligne, doit pouvoir être clairement identifiée comme telle.
Elle doit rendre clairement identifiable la personne physique ou
morale pour le compte de laquelle elle est réalisée.
Il convient donc d’éviter toute confusion quant au caractère publi-
citaire d’une démarche de prospection, l’envoi de newsletters et
autres communications en ligne mêlant des éléments d’information
ou d’actualité à des éléments publicitaires pouvant être considérés
comme une prospection.
Il convient également de bien distinguer les marques de vos produits
et/ou services de votre dénomination sociale ainsi que, le cas
échéant, une filiale de sa maison mère.
Ces obligations s’ajoutent à celles existantes en matière de publicité
trompeuse.
De même, les publicités, et notamment les offres promotionnelles
(rabais, primes, cadeaux ainsi que les concours ou les jeux promo-
tionnels adressés par courrier électronique), doivent pouvoir être
identifiées de manière claire et non équivoque dès leur réception par
leur destinataire, ou en cas d’impossibilité technique, dans le corps
du message.

78
Chapitre 3 – La dimension juridique du projet Web

Les conditions détaillées d’une offre ou la participation à des jeux/


concours par voie électronique doivent être clairement précisées et
aisément accessibles pour chaque personne. Il convient donc de
prévoir un lien vers ces conditions ou, si cela est possible, de les
indiquer directement dans le message électronique ou sur la même
page Web.
Il est important de souligner que ces règles sont applicables aux
publicités, offres, concours ou jeux à destination des professionnels.

Sur la prospection en ligne


La prospection directe en ligne, sous quelle que forme que ce soit,
est interdite dès lors que la personne physique destinataire n’a pas
exprimé son consentement préalable à recevoir de telles prospec-
tions.
Constitue une prospection directe l’envoi de tout message destiné à
promouvoir, directement ou indirectement, des biens, des services
ou l’image d’une personne vendant des biens ou fournissant des
services.
Toutefois, la prospection directe par courrier électronique est auto-
risée si les coordonnées du destinataire ont été recueillies directe-
ment auprès de lui.
En clair, il n’est pas possible de faire de la prospection sans le consen-
tement préalable des personnes concernées. Il convient donc de
recueillir un consentement spécifique pour chacun des moyens de
prospection envisagés (télécopieur ou courrier électronique).
La personne physique doit être considérée comme la personne desti-
nataire du message, peu importe qu’elle reçoive ce message à titre
personnel ou dans le cadre de son activité professionnelle.
Il convient donc de prévoir, lors de la collecte des données person-
nelles d’une personne physique, une mention spécifique accompa-
gnée d’une information précise sur la nature de la démarche et la
destination des données collectées.
Si la LCEN n’indique pas explicitement le moyen de recueillir le
consentement direct et préalable des destinataires, il convient toute-
fois d’éviter l’utilisation de cases précochées qui peuvent être
remplacées par des cases non cochées, des boutons oui/non ou des
menus déroulants.
Pour résumer, la prospection en ligne est interdite ou illicite dans les
cas suivants :

79
Partie I – Les projets Web

• si elle utilise des coordonnées recueillies sans le consentement


préalable du destinataire ou en dehors du cadre d’une vente
ou d’une prestation ;
• si elle concerne des produits ou services distincts ;
• si elle est faite par une personne morale distincte (filiale) ;
• si l’internaute n’est pas informé clairement de son droit de
s’opposer sans frais à l’utilisation de ses coordonnées lorsque
celles-ci sont recueillies et chaque fois qu’un courrier électro-
nique de prospection lui est adressé ;
• s’il n’est pas fait mention des coordonnées valables auxquelles
le destinataire puisse utilement transmettre une demande
tendant à obtenir que ces communications cessent sans frais ;
• s’il y a dissimulation de l’identité de la personne pour le
compte de laquelle la communication est émise ;
• s’il est fait mention d’un objet sans rapport avec la prestation
ou le service proposé.
En pratique, il convient :
• d’éviter le partage de fichiers entre filiales d’un même
groupe ;
• d’éviter les campagnes de parrainage (l’envoi d’e-mails par le
biais d’une adresse fournie par un parrain n’est pas valable) ;
• d’éviter toute confusion entre votre société et un partenaire
ou une autre filiale d’un groupe ;
• d’éviter toute confusion entre l’objet du message et les servi-
ces proposés ;
• d’avertir la personne concernée de la finalité du traitement
des données collectées ;
• de prévoir, dans chaque message, la possibilité de s’opposer à
l’utilisation des coordonnées par une case à cocher avec les
coordonnées du service en charge des données.

Sur la responsabilité des cybermarchands

La Loi pour la confiance dans l’économie numérique (LCEN) du


21 juin 2004 définit les règles applicables à toutes les activités de
commerce électroniques qu’elle définit comme toute activité
économique par laquelle une personne propose ou assure à

80
Chapitre 3 – La dimension juridique du projet Web

distance et par voie électronique la fourniture de biens ou de


services.
Cette définition est assez large puisqu’elle comprend les services
tels que ceux consistant à fournir des informations en ligne, des
communications commerciales et des outils de recherche, des
informations d’accès et de récupération de données, d’accès à un
réseau de communication ou d’hébergement d’informations, y
compris lorsque ces services ne sont pas rémunérés par ceux qui
en bénéficient.
Mais le principal apport de la LCEN concerne la responsabilité
des cybermarchands. En effet, elle stipule que les cybermar-
chands sont responsables de plein droit à l’égard des acheteurs de
la bonne exécution des obligations résultant du contrat, que ces
obligations soient à exécuter par eux-mêmes ou par d’autres
prestataires de services, sans préjudice de son droit de recours
contre ceux-ci.
Il existe donc une présomption de responsabilité des cybermar-
chands, lesquels ne peuvent s’exonérer de tout ou partie de cette
responsabilité qu’en apportant la preuve que l’inexécution ou la
mauvaise exécution du contrat est imputable soit à l’acheteur,
soit au fait, imprévisible et insurmontable, d’un tiers étranger à
la fourniture des prestations prévues au contrat, soit à un cas de
force majeure.
La charge de la preuve pèse donc sur les cybermarchands.
Par ailleurs, les cybermarchands sont tenus d’une obligation
d’information renforcée à l’égard des consommateurs qui va au-
delà de la notice légale devant figurer sur tout site Web. Ils
doivent ainsi assurer aux acheteurs un accès facile, direct et
permanent aux informations suivantes :
• s’il s’agit d’une personne physique, ses nom et prénoms et,
s’il s’agit d’une personne morale, sa raison sociale ;
• l’adresse où elle est établie, son adresse de courrier électroni-
que, ainsi que son numéro de téléphone ;
• si elle est assujettie aux formalités d’inscription au registre du
commerce et des sociétés ou au répertoire des métiers, le
numéro de son inscription, son capital social et l’adresse de
son siège social ;

81
Partie I – Les projets Web

• si elle est assujettie à la taxe sur la valeur ajoutée et identifiée


par un numéro individuel en application de l’article 286 ter
du Code général des impôts, son numéro individuel d’identi-
fication ;
• si l’activité est soumise à un régime d’autorisation, le nom et
l’adresse de l’autorité ayant délivré cette autorisation ;
• si elle est membre d’une profession réglementée, la référence aux
règles professionnelles applicables, son titre professionnel et
l’État membre dans lequel il a été octroyé ainsi que le nom de
l’ordre ou de l’organisme professionnel auprès duquel elle est
inscrite.
Cette obligation d’information renforcée porte également sur le prix
qui doit être indiqué de manière claire et non ambiguë, notamment
au regard des taxes éventuelles et des frais de livraison. Cette obliga-
tion vient s’ajouter aux dispositions légales régissant la publicité
trompeuse et l’information sur les prix stipulées par le Code de la
consommation.

Comment négocier des contrats Web ?

En parallèle des déclarations préalables à l’exploitation d’un site


Web, la mise en œuvre d’un projet Web nécessite la prise en compte
d’étapes techniques successives susceptibles d’avoir un impact sur les
obligations juridiques des parties au projet. Ces étapes doivent être
gérées dans le cadre d’une démarche de conduite et de gestion des
risques juridiques du projet. Cette démarche doit permettre d’asso-
cier la mise en œuvre technique du projet à la gestion des différents
droits afférents au projet, de l’étude de l’analyse des besoins à
l’exploitation effective de l’objet du projet Web.

Phase précontractuelle
La phase précontractuelle définit le cadre dans lequel une entreprise
initie la mise en œuvre d’un projet par l’analyse de ses besoins et le
choix d’un prestataire ou d’un partenaire pour l’assister. Tout projet
passe nécessairement par une phase d’analyse précise des besoins et
des objectifs de l’entreprise qui souhaite développer son image ou
son activité. Le choix du prestataire constitue en tant que tel une
étape importante de la phase précontractuelle. Le prestataire doit
être capable d’assurer d’une part une qualité du suivi des prestations

82
Chapitre 3 – La dimension juridique du projet Web

et d’autre part un respect des délais compatibles avec les objectifs et


le planning du client.
Il doit participer à la validation du cahier des charges établi sur la
base de l’analyse préalable des besoins de l’entreprise. Cette valida-
tion est primordiale car le cahier des charges constitue un référentiel
technique et fonctionnel qui permettra de contrôler la conformité
des prestations et le respect des engagements du prestataire.

Périmètre contractuel du projet


La phase d’analyse préalable conduit à la conclusion d’un contrat qui
régit les obligations des parties dans le cadre de l’exécution des presta-
tions de réalisation du site Web. La signature d’un contrat peut être
toutefois précédée d’une proposition commerciale ou d’une lettre
d’engagement définissant plus sommairement les principes selon
lesquels les cocontractants souhaitent s’engager dans le projet.
En principe, le projet de contrat, proposé par l’un ou l’autre des
futurs cocontractants, reprend la teneur des engagements initiaux
ou les précise pour mieux déterminer le périmètre contractuel du
projet. Toutefois, il n’est pas rare de voir naître des incohérences ou
des contradictions entre les engagements initiaux et les propositions
formulées au sein du projet de contrat. Il est nécessaire de procéder,
préalablement à la signature du contrat, à un contrôle de cohérence
entre le contrat et les documents précontractuels. En effet, ces
derniers font souvent partie du périmètre contractuel et sont
annexés au contrat.
Le cahier des charges doit impérativement figurer dans les annexes
du contrat, en sa qualité de référentiel commun aux parties servant
de base au contrôle de conformité des prestations.
Afin d’éviter tout litige lié à l’interprétation des obligations des
parties, il convient d’introduire, au sein du contrat, une hiérar-
chisation des documents constituant le périmètre contractuel. En
principe, le contrat prévaudra sur tous les autres documents
contractuels.
Repères : hiérarchie type des différents documents contractuels d’un projet
Web
1. Contrat.
2. Annexes du contrat.
3. Cahier des charges.
4. Spécifications techniques et spécifications fonctionnelles.
5. Proposition commerciale.

83
Partie I – Les projets Web

Contrôle de conformité
En matière de projets Web, les manquements contractuels résultent
d’un défaut total ou partiel de conformité des prestations et des
engagements pris par le prestataire par rapport aux besoins et aux
objectifs consignés dans le cahier des charges du client.
Afin de prévenir et/ou de démontrer de tels manquements, il
convient d’organiser contractuellement le contrôle de conformité
des prestations. Ce contrôle doit donner lieu, à l’issue d’une phase
de tests, à la signature d’un procès verbal actant des réserves émises
sur la conformité des prestations ou de l’absence de telles réserves
sur les prestations réalisées. La signature des procès-verbaux de
conformité provisoires puis définitifs fait, en principe, courir le délai
de garantie contractuelle qui pèse en général sur le prestataire
lorsque l’objet du contrat est lié à la réalisation d’un site Web.
En l’absence de signature de tels procès-verbaux, l’acceptation des
prestations par le client sera, en principe, considérée comme tacite,
surtout si le client a commencé à exploiter son site Web sans émettre
aucune réserve.

Propriété et garantie des incorporels


En matière de projet Web, une attention particulière doit être portée
aux problématiques relatives à la propriété des informations échan-
gées et des œuvres cédées ou utilisées dans le cadre de l’exécution du
contrat.
L’absence de dispositions très précises sur la propriété de chacun des
éléments protégeables par le droit de propriété intellectuelle ou par
le secret, est susceptible de créer une confusion quant aux condi-
tions d’utilisation de ces éléments et un usage illicite en cours
d’exécution du contrat.
De même, des désaccords pourraient survenir lors de la cessation des
relations contractuelles. La désignation précise de ces droits de
propriété et d’utilisation doit être accompagnée de garanties sur la
titularisation des droits, notamment contre toute action en contre-
façon qui pourrait résulter de l’un des éléments cédés au titre du
contrat.

Obligation de moyens et obligation de résultat


Au même titre que la propriété et les garanties, la responsabilité des
parties au contrat doit être définie dans une clause à part entière, qui

84
Chapitre 3 – La dimension juridique du projet Web

précise si le prestataire est soumis à une obligation de moyens ou de


résultat.
Cette qualification n’est pas neutre quant au régime juridique de la
charge de la preuve en cas de manquement de l’un des cocontractants.
En effet, la charge de la preuve incombe, en principe, à celui qui se
prévaut d’un manquement de son cocontractant.
Ce principe s’applique en l’absence de toute disposition mais égale-
ment dans l’hypothèse où les parties ont conclu un engagement sur
la base d’une obligation de moyens, que ce soit pour l’une et/ou
l’autre des parties. En revanche, dans l’hypothèse d’une obligation
de résultat, il incombe à la partie soumise contractuellement à une
telle obligation, et non à la partie qui s’estime victime des manque-
ments, de démontrer qu’elle n’a pas commis de faute contractuelle.
La qualification de la nature de l’obligation à laquelle l’une et/ou
l’autre des parties entend se soumettre au titre de l’exécution d’un
contrat dépend des dispositions du contrat en termes :
• de respect des délais contractuels ;
• de conformité des prestations ;
• d’appréciation des dispositions contractuelles par un juge.
Au-delà de la qualification juridique de l’obligation de moyens ou
de résultat, la clause responsabilité définira les limites de responsa-
bilité de chacun des cocontractants.
Limite de la responsabilité
La plupart des contrats Web prévoient des limitations de responsa-
bilité, principalement financières, en faveur du prestataire sur lequel
pèse la plus grande responsabilité dans la bonne exécution du
contrat.
Ces limitations ont pour effet de réduire, parfois de manière subs-
tantielle, le montant des sommes susceptibles d’être réclamées par le
client en cas de manquement du prestataire à l’une de ses obliga-
tions. Les parties fixent, en principe, une limite financière au cas où
la responsabilité du prestataire serait engagée au titre de l’exécution
des obligations du contrat. C’est de cette limite, définie lors de la
conclusion du contrat, que dépendra l’étendue de la réparation qui
pourra être sollicitée en cas de manquement.

85
Partie I – Les projets Web

Cohérence et équilibre du contrat


La constitution d’annexes, qui regroupent les aspects techniques du
projet, permet d’améliorer la lisibilité des dispositions juridiques
insérées dans le corps même du contrat.
À l’instar des documents précontractuels, il convient de s’assurer
de la cohérence de ces annexes à caractère technique avec les
dispositions juridiques du contrat. Ces annexes techniques sont
susceptibles d’avoir un impact sur les obligations énoncées au
sein du contrat.
Bien souvent, le projet de contrat est directement proposé par le
partenaire ou le prestataire qui s’engage à réaliser tout ou partie du
projet. Il doit alors faire l’objet d’une analyse, par le service juridique
de l’entreprise ou par un avocat spécialisé dans la rédaction et la
négociation des contrats Web, au regard des problématiques essen-
tielles rappelées précédemment et de la nécessité d’équilibrer les
obligations des parties.
Ce type de projet de contrat est très souvent fortement orienté en
faveur des prestataires, notamment en ce qui concerne les limites et
exclusions de responsabilité ainsi que les délais de réalisation.
Repères : les dix points à vérifier avant de signer un contrat de création de
site Web ou d’intranet
1. Périmètre des prestations.
2. Périmètre des documents contractuels.
3. Calendrier et délais de réalisation.
4. Engagement du prestataire sur le résultat et la qualité des prestations.
5. Contrôle de conformité des prestations.
6. Propriété sur les différents éléments du site Web.
7. Cession de droits de propriété au profit du client.
8. Limite de responsabilité et de réparation financière.
9. Garanties.
10. Conditions de réalisation de prestations complémentaires.

Une attention particulière doit être portée sur les engagements du


prestataire en termes de calendrier et de délais afin de limiter les
éventuelles dérives dans le temps et la hausse du coût du projet. Le
calendrier doit coïncider avec les objectifs de lancement du projet,
d’où la nécessité d’établir un rétroplanning.
En outre, le respect des délais implique une collaboration active
entre les parties et une vigilance particulière du client. Ce dernier

86
Chapitre 3 – La dimension juridique du projet Web

doit également gérer, au plus près, le suivi de son projet et ne pas se


reposer uniquement sur son cocontractant. Le respect des délais, la
qualité des prestations et la réussite du projet en dépendent. Un
suivi attentif du projet permettra aux parties de prévenir et/ou de
limiter les risques de litiges qui sont de plus en plus nombreux en
matière de projets Web.
Gestion d’un contrat multi-objet
Il n’est pas rare que l’objet d’un contrat concerne à la fois la réalisa-
tion, l’hébergement, la maintenance, le référencement, etc. du site
Web. Le régime juridique applicable à ces éléments est sensiblement
différent.
Il convient de les distinguer comme autant d’objets à part entière au
sein du contrat notamment en termes de propriété, de garanties, et
de responsabilités.
D’une manière générale, il est préférable de conclure séparément
autant de contrats qu’il existe d’objets juridiques dans un projet
Web. Il s’agit d’éviter toute difficulté liée à la cessation d’un des
objets d’un seul et même contrat, susceptible d’entraîner de facto la
fin des autres objets du contrat.
L’une des parties peut avoir un intérêt à poursuivre une ou plusieurs
des prestations régies par un contrat, alors que d’autres prestations
ne seraient plus essentielles ou seraient devenues obsolètes du fait,
notamment, d’une évolution technologique marquante.
Dans l’hypothèse de contrats ayant déjà fait l’objet d’une signature,
la possibilité est aussi offerte aux co-contractants de conclure un
avenant qui modifie et/ou annule tout ou partie du contrat initial.
La gestion d’un contrat multi-objet est donc essentielle en matière
de projets Web dans la mesure où ces projets mettent en jeu l’utili-
sation de nouvelles technologies et la création d’œuvres graphiques
ou logicielles qui obéissent à des régimes juridiques particulier et
distincts.
Spécificités des contrats de réalisation
et d’hébergement de sites Web
Les contrats de réalisation et d’hébergement de sites Web contien-
nent des spécificités sur lesquelles le futur exploitant doit porter une
attention particulière.

87
Partie I – Les projets Web

Pour le contrat « Réalisation du site Web »


Ainsi qu’il vient d’être exposé, la création d’un site Web repose,
préalablement à la réalisation effective du site, sur la définition des
besoins et des attentes du client dans le cadre d’un cahier des
charges. Ce cahier des charges présente notamment les spécifica-
tions techniques et fonctionnelles du site Web.
La mise en ligne du site doit être obligatoirement précédée d’un
contrôle de conformité des prestations et des données. Des tests
doivent être organisés afin d’apprécier la fiabilité et la performance
du site Web. Le prestataire étant le titulaire originel des droits sur le
site, en tant que créateur, il est impératif d’organiser un transfert de
propriété des droits détenus par le prestataire sur les éléments qui
composent le site.
Un contrat de réalisation doit ainsi comporter une clause relative à
la cession exclusive et définitive des droits sur les éléments compo-
sant le site. À défaut, l’entreprise n’en sera pas le propriétaire. En
conséquence, elle pourrait être considérée comme contrefacteur en
cas de modification ou de cession de son site Web à un tiers.
Pour le contrat « Hébergement du site Web »
L’exploitation d’un site Web nécessite souvent le recours à un pres-
tataire d’hébergement afin de connecter le site au Web grâce aux
serveurs mis à disposition par ce dernier.
En principe, l’entreprise ne dispose pas d’un serveur propre, dédié
au site Web. Elle doit donc conclure un contrat avec un prestataire
disposant d’un centre serveur relié à Internet. Par ce contrat, l’entre-
prise et le prestataire organisent soit la location d’un espace disque
sur un serveur, soit la location d’un serveur dédié pour assurer la
diffusion du site Web et permettre l’accès au site par les internautes.
Ce contrat permet également d’assurer la maintenance du site Web,
et de déterminer le taux de fréquentation du site par les internautes.
Afin d’anticiper l’éventualité d’une rupture des relations contrac-
tuelles avec le prestataire choisi, le contrat doit prévoir les modalités
de la réversibilité de l’hébergement, c’est-à-dire du transfert de
l’hébergement du site Web vers le serveur d’un autre prestataire.

Les risques juridiques liés au référencement


et aux hyperliens
Le site Web prêt à être mis en ligne, l’une des dernières formalités
consiste à le référencer sur les moteurs de recherche afin de le
promouvoir auprès des internautes. Ce référencement est opéré à

88
Chapitre 3 – La dimension juridique du projet Web

l’aide de métatags (ou mots-clés) permettant de définir un certain


nombre de mots-clés qui renvoient au site Web.
Attention : ces mots-clés ne doivent pas reprendre la dénomination
de produits ou de services concurrents sous peine de tomber sous le
coup d’une action en contrefaçon de marque et/ou en concurrence
déloyale.
Par ailleurs, il est possible de mettre en place des liens en direction
d’un ou plusieurs sites. Ces liens permettent aux internautes d’être
redirigés vers chacun des sites Web ayant établi des liens entre eux.
La mise en place d’hyperliens présente un risque relatif à la respon-
sabilité dans l’hypothèse où les contenus de l’un des sites Web reliés
seraient contraires aux lois et règlements en vigueur.
Afin d’écarter ou de limiter toute responsabilité, la mise en place
d’un hyperlien pourra faire l’objet d’un contrat définissant les obli-
gations réciproques des propriétaires des sites concernés.

En conclusion

La prise en compte de la dimension juridique d’un projet Web parti-


cipe directement de sa réussite et de sa pérennité. Au-delà du respect
des réglementations applicables, la réussite implique une collabora-
tion active entre les parties.
Le futur exploitant ne doit pas se reposer sur son ou ses cocontrac-
tants et doit porter toute son attention sur la conduite du projet et
notamment sur le respect des délais et la qualité des prestations.
Un suivi attentif du projet permettra en effet de prévenir et, le cas
échéant, de limiter les risques de litiges, nombreux en matière de
projets Web.

Pour aller plus loin

Ouvrages
Christiane Féral-Schuhl
Cyberdroit : Le droit à l’épreuve de l’internet
Dalloz-Sirey – 2006 – ISBN : 978-2247061174

89
Partie I – Les projets Web

Martine Robert et Erol Giraudi


Le guide juridique du portail Internet/Intranet
Eska – 2005 – ISBN : 978-2747206990
Sandrine Carneroli
Les contrats commentés du monde informatique : Logiciels, bases de
données, multimédia, internet
Larcier – 2007 – ISBN : 978-2804420925

Sites
Lentreprise.com
http://www.lentreprise.com/outils/lettre-contrat
Le forum des droits sur Internet
http://www.foruminternet.org
Juris Expert - Le droit en un clic
http://www.jurisexpert.net

90
Chapitre 4

Rassembler
les facteurs clés
de succès

Les premiers projets Web étaient souvent réalisés « par obligation ». Il fallait
être sur Internet, très vite, à n’importe quel coût. Certains prestataires et
éditeurs en ont d’ailleurs largement profité en vendant prestations et
licences à prix d’or…
Aujourd’hui, chaque nouveau projet est un investissement. Les règles du
jeu sont donc très différentes. Pour avoir une chance de voir le jour, le
projet doit être crédible, c’est-à-dire être quantifié et ses performances
mesurées : chiffre d’affaires ou économies réalisées, coût d’exploitation,
bénéfices ou pertes, plan de financement1, audience, temps passé, taux de  Plan
transformation… Plus rien n’est laissé au hasard. de financement :
outil de prévision
Chaque nouveau projet Web doit apporter de la valeur à l’entreprise. Il doit financière qui
être motivant et permettre d’enrichir l’entreprise en capitalisant l’expé- permet d’évaluer
rience. Ce chapitre présente ces différents aspects et explique comment le besoin en finance-
ment d’une entre-
rassembler les principaux facteurs clés de succès.
prise et de le répartir
mois par mois.

Construire un projet crédible

Pour être pris au sérieux, le projet doit, dès ses premières présentations offi-
cielles, être étayé par des chiffres concrets et parlants, au premier rang
desquels doivent se trouver ses objectifs, son budget et le planning envi-
sagé. Pour aller encore plus loin, il est utile de définir les moyens qui
permettront de mesurer la réussite du projet.

91
Partie I – Les projets Web

Quantifier le projet
Un projet Web peut être quantifié au travers de trois éléments : ses
objectifs, son budget de création puis de fonctionnement et l’orga-
nisation humaine nécessaire à son fonctionnement.
Fixer des objectifs chiffrés
Fixer des objectifs chiffrés est une démarche essentielle car elle
oblige à affiner l’idée d’origine, la concrétise et la rationalise. Les
objectifs et les indicateurs d’un projet sont bien sûr liés à sa nature.
Le tableau ci-après propose une synthèse de quelques cas classiques.

Tableau 4-1
Types de projets, objectifs et indicateurs

TYPE DE PROJETS OBJECTIFS INDICATEURS

Site marchand Vendre CA, bénéfices, volumes, panier moyen,


nombre de clients
Compléter Pourcentage du CA en ligne vs pourcentage
le réseau du CA offline
de distribution
Fournir un support Nombre d’appels/cas traités
Marque Exister Points de notoriété, points d’agrément,
nombre de pages vues, nombre de visites,
nombre d’abonnés à la newsletter
Entretenir Nombre de visites, nombre de pages vues,
la relation temps moyen de session, taux de lecture de
la newsletter, nombre de commandes
si boutique

Constituer Nombre de contacts, nombre d’informations


un fichier par contact
Rajeunir la cible Nombre de nouveaux consommateurs recrutés
Portail Informer Nombre d’articles lus
d’entreprise/intranet
Communiquer Nombre de téléchargements, nombre
d’e-mails traités

Réaliser Nombre de procédures automatisées,


 Année homme : unité des économies nombre d’années homme1 économisées
de mesure de la charge
de travail d’un projet. Augmenter Nombre d’informations concurrentielles
la compétitivité collectées/affichées par période

Augmenter Nombre d’applications bureautiques


la mobilité intégrées

92
Chapitre 4 – Rassembler les facteurs clés de succès

Institutionnel Informer Nombre d’articles lus


Communiquer Nombre de téléchargements, nombre
d’e-mails traités
Gérer la crise Nombre d’e-mails, nombre
de téléchargements
Communautaire Échanger Nombre de membres, temps de session,
nombre de visiteurs par période
Constituer Nombre de contacts, nombre
un fichier d’informations par contact
Créer du contenu Nombre d’articles

Le principal objectif d’un site marchand, la vente de produits ou de


services, est en général quantifié par le chiffre d’affaires attendu. Cet
indicateur ne suffit pas. Il doit être complété par au moins trois
autres indicateurs : les volumes, le panier moyen, le nombre de
clients.
Le volume de produits vendus est un indicateur intéressant car il
permet d’évaluer les coûts liés au stockage et à l’expédition. Le
nombre de clients est un élément incontournable pour calculer le
panier moyen et évaluer les coûts marketing visant à les recruter.
Enfin, le panier moyen permet d’affiner les coûts liés à l’expédition
et donne un repère utile pour le suivi commercial du site en activité.
Au final, une simple équation du type : « nombre de clients * panier
moyen (volumes de vente/nombre de clients) = chiffre d’affaires
prévisionnel » a le mérite de préciser considérablement la première
vision.
Quand le but est de fournir un support client, il est utile de définir
le nombre de cas traités par le site et le pourcentage que cela repré-
sente par rapport au total de cas traités.
Les sites de marques ont souvent pour objectif de faire exister la
marque et de poursuivre la relation avec les consommateurs sur
Internet. Outre les indicateurs habituels (notoriété spontanée et
assistée, agrément, etc.), le nombre de visites, de pages vues et
d’abonnés à la newsletter précise le projet.
Le nombre de visites dimensionne le projet : un site visant cinq
mille visites par mois ne demande pas les mêmes efforts qu’un site
en visant cinquante mille ! Les investissements, le type de presta-
taire, l’organisation du projet… en seront influencés.

93
Partie I – Les projets Web

De même, le nombre de pages vues comparé au nombre de visites


est une bonne manière de quantifier les objectifs qualitatifs du site.
Ainsi, plus le ratio (pages vues/visites) sera élevé et plus l’ambition
du site sera forte.
Le nombre d’abonnés à la newsletter – et quand une boutique
d’objets publicitaires est prévue, le nombre de commandes – est
aussi un moyen de dimensionner le projet et de définir des objectifs
qualitatifs.
Lorsque l’objectif est de constituer un fichier, le nombre de contacts
recueillis ne suffit pas et doit être complété du nombre moyen
d’information par contact.
L’un des principaux objectifs de tout intranet et portail d’entreprise
est d’améliorer l’information, la communication et l’utilisation des
applications. Le nombre d’articles lus permet de dimensionner le
projet par rapport aux autres supports (presse interne, circuit vidéo,
etc.). Cet indicateur, associé à d’autres tels que le nombre d’e-mails
traités, est également utile pour dimensionner la future équipe
chargée de produire les contenus.
L’autre objectif habituellement poursuivi est la réduction des coûts,
notamment grâce à l’automatisation des procédures simples comme
la saisie et le traitement des notes de frais. Un premier indicateur, le
nombre de procédures automatisées, complété par une évaluation
des économies espérées, dimensionne efficacement le projet.
Enfin, dans certains cas, la mobilité est aussi l’un des objectifs prin-
cipaux du projet. Les indicateurs les plus pertinents sont alors le
nombre d’applications à « Webiser » et le pourcentage d’utilisateurs
visés.
Dans le cas d’un site institutionnel, l’information et la communica-
tion auprès de cibles spécifiques (publics financiers, journalistes,
actionnaires….) sont les principaux objectifs. Les indicateurs sont
les mêmes que ceux décrits plus haut pour les portails d’entreprise.
En revanche, il est souvent demandé à un site institutionnel de
participer au dispositif de communication de crise. L’indicateur
peut alors être le nombre d’e-mails traités en un temps donné et le
nombre de téléchargements de dossier de presse.
L’objectif d’un site communautaire est d’acquérir le plus de
membres possible de manière à disposer d’effets de seuils propres à
transformer les échanges des membres en sources de profit. Le prin-
cipal indicateur est donc le nombre de membres. Cependant, il a
peu d’intérêt seul ; les temps de session (temps passé sur le site par

94
Chapitre 4 – Rassembler les facteurs clés de succès

chaque visiteur) et le nombre de membres actifs sont plus intéres-


sants car ils reflètent la future activité du site. En outre, le temps de
session divisé par le nombre de pages vues total permet d’imaginer
une partie des futurs revenus.
Bien que l’exercice soit très difficile, la détermination de ces indica-
teurs est incontournable car c’est sur eux que le business plan sera
construit.
Évaluer l’enveloppe budgétaire
Outre les objectifs chiffrés, il est nécessaire d’évaluer le coût global
du projet, ne serait-ce que pour avoir une idée de la méthodologie à
employer et des énergies à rassembler en interne. Évaluer l’enve-
loppe budgétaire permet aussi d’éviter les mauvaises surprises dues
à l’oubli de certains postes tels que les licences, les coûts de migra-
tion de l’hébergement, la création des contenus…
Si, à ce stade, il n’est bien sûr pas possible de procéder à une revue
de détails, le recours à des études du type Forrester ou Gartner, peut,
en revanche, donner un premier ordre de grandeur budgétaire.
Parfois, une revue Web peut également laisser transparaître quelques
chiffres intéressants. Une autre méthode consiste à s’attacher les
services d’un prestataire spécialisé (cabinet de conseil, assistant à
maîtrise d’ouvrage, consultant indépendant…) qui, parfois, peut
évoquer les budgets d’autres projets, ne serait-ce qu’indirectement,
par exemple au travers de fourchettes de prix.
Repère : coûts des différents types de sites
Le coût d’un projet Web dépend essentiellement de trois facteurs :
– la place qu’il prend dans la stratégie générale de l’entreprise ;
– la position de l’entreprise sur la courbe d’apprentissage (c’est-à-dire sa maturité face aux
projets Web) ;
– le type de prestataire réalisant le projet (indépendant vs grande SSII de type Logica).

Ainsi, un projet stratégique dans une entreprise qui se situe en haut de la courbe d’apprentissage
nécessitera beaucoup plus de moyens qu’un projet non stratégique réalisé par une entreprise en
bas de la courbe d’apprentissage.

Les lignes suivantes proposent, à titre indicatif, des fourchettes de budgets* :


– site institutionnel : de quelques milliers d’euros (site statique + offres d’emploi et news déve-
loppées en PHP/MySQL, réalisation par un indépendant) à plusieurs centaines de milliers d’euros
(site dynamique, multilingue, gestion de contenu, fonctionnalités avancées, développements sur
mesure s’appuyant sur des technologies telles que .NET ou J2EE).

95
Partie I – Les projets Web

– site catalogue/marchand : de quelques milliers d’euros (offre en ASP, peu de références, per-
sonnalisation minimale) à plus de deux cent mille euros (sites développés sur mesure qui
s’appuient sur des produits possédant des coûts de licence importants tels que Broadvision, Webs-
phere, Oracle 9iAS…).
– intranet : de quelques milliers d’euros (personnalisation par un indépendant d’un package
Open Source tel que PHPNuke ou Spip pour réaliser un intranet éditorial) à plus de cent
mille euros (intranet international, multilingue avec intégration de données, développements sur
mesure s’appuyant sur des technologies telles que .NET ou J2EE).
– portail d’entreprise : plusieurs centaines de milliers d’euros, qu’il s’agisse du paramétrage et de
la personnalisation d’un progiciel de type Plumtree ou de développements sur mesure.
* Toutes phases du projet, hors hébergement, coûts matériels et humains.

Dans tous les cas, pour que l’enveloppe budgétaire soit crédible, il
faudra construire les grandes masses budgétaires avec un minimum
de précision. Les check-lists ci-après constituent un bon point de
départ.
Le tableau suivant présente la check-list des principaux postes à
envisager pour la phase création du projet.

Tableau 4-2
Synthèse des coûts d’un projet

PRINCIPAUX POSTES DÉTAIL

Coûts de création de l’outil – stratégie – faisabilité


– appel d’offres – conception – réalisation
– licences
– amortissement matériel
Coûts de création des contenus – textes
– visuels
Coûts juridiques – nom de domaine – CNIL
 CGV : Conditions – CGV1
générales de vente. – règlement
Informations légales qui
Coûts liés au lancement – formation
précisent le cadre de vente
– campagne de communication
des produits sur un site
– référencement
Internet.
Coûts liés à l’équipe projet – formation
– recrutement

Le tableau suivant présente la check-list des principaux postes à


envisager pour la phase d’exploitation du projet.

96
Chapitre 4 – Rassembler les facteurs clés de succès

Tableau 4-3
Synthèse des coûts d’animation

PRINCIPAUX POSTES DÉTAIL

Coûts de possession de l’outil – licences


– amortissement matériel
– hébergement
Coûts de maintenance – maintenance évolutive
– maintenance corrective
Coûts d’animation – équipe dédiée
– création de contenus
– achat de contenus
Coûts liés à la promotion – campagne de communication
– référencement

Les budgets obtenus serviront de base pour la constitution des


éléments financiers du business plan.
Imaginer l’organisation nécessaire
L’organisation nécessaire à la réalisation du projet peut être un
élément déterminant de la prise de décision. Il est donc important
d’imaginer ce que sera l’équipe projet puis l’équipe dédiée à
l’animation.
À ce stade, l’équipe projet est en général composée, comme nous
l’avons vu dans les pages précédentes, d’un chef de projet qui
s’appuie sur des experts, d’un comité de projet et d’un comité stra-
tégique. Les risques liés à son activité sont mineurs.
En revanche, la composition de l’équipe dédiée à l’animation du site
« en vitesse de croisière » peut être déterminante. En effet, entre un
Webmaster et une équipe de quinze personnes, il y a une marge qu’il
n’est pas toujours si simple d’affiner, le choix de certaines solutions
techniques pouvant influencer fortement le nombre de contribu-
teurs. Par exemple, une équipe support répondant aux e-mails de
clients sera plus ou moins étoffée selon que la solution sera capable
ou non de répondre automatiquement à certaines demandes et aura
ou non la capacité d’apprendre. L’étude de la concurrence ou de sites
a priori similaires peut parfois donner des indications.

97
Partie I – Les projets Web

Se donner les moyens de vérifier l’atteinte des objectifs


Cette démarche porte sur deux catégories d’objectifs. À court terme,
il s’agit de vérifier que la mise en œuvre et le déploiement sont
conformes aux attentes, que le lancement a porté ses fruits, que le
budget et le planning ont été respectés et que l’impact sur l’organi-
sation a été maîtrisé. À moyen terme, le but est de vérifier, à inter-
valles réguliers, que le site atteint les objectifs qui constituent sa
raison d’être (CA, notoriété, économies…). Cette démarche aide à
rationaliser le projet, à préparer la capitalisation et à objectiver les
futurs résultats. Avant tout interne, la mise en place d’indicateurs et
d’outils dans le but de vérifier l’atteinte des objectifs peut aussi servir
lors du bilan de projet avec les prestataires.
Vérifier les objectifs à court terme
La vérification de l’atteinte des objectifs à court terme repose prin-
cipalement sur les documents contractuels du projet. À chaque
étape, ils devront être rédigés avec le même souci de cohérence et à
chaque fois, avant de les valider, il faudra se poser les mêmes ques-
tions : En quoi cela contribue-t-il à l’atteinte des objectifs ? Est ce
cohérent avec les objectifs principaux ?… Cette démarche est parti-
culièrement importante dans le cas de prestations « aux résultats »
telles que le développement au forfait ou le positionnement garanti
dans les moteurs de recherche.
La vérification de la conformité du produit repose sur la confronta-
tion entre les attentes exprimées dans l’expression des besoins dans
le cahier des charges et dans les différents contrats et les capacités
 Clic through : « Taux de réelles du produit fini. Les éléments à vérifier sont l’existence d’une
clic » en français. Rapport, réponse à chaque fonctionnalité ainsi que la qualité et les perfor-
exprimé en pourcentage,
mances de chaque réponse. Pour plus de détails, lire les sections
entre le nombre de clics
publicitaires constatés et « Tests utilisateurs » et « Recette de l’application » du chapitre 10.
le nombre d’impressions ou Les objectifs de la campagne de lancement – en général le trafic, la
pages vues constatées.
notoriété et/ou l’image – peuvent être appréciés en comparant les
Les taux de clics mesurent le
nombre d’internautes qui se objectifs contractualisés pour le référencement, le positionnement
connectent sur un site Web et certains supports tels que les bannières (via le clic through1) avec
à partir d’un bandeau les résultats obtenus. Pour plus de détails, lire « Analyser les résultats
publicitaire, c’est-à-dire le
de la campagne de communication » du chapitre 11.
nombre de personnes qui
ont cliqué sur le bandeau Les principaux indicateurs quantitatifs d’un projet sont le budget, la
divisé par le nombre de fois charge et le planning. Seule l’entreprise en a une vision globale. Elle
où le bandeau a été vu.
Ils sont une bonne indica-
est donc seule à pouvoir s’assurer de l’atteinte des objectifs généraux.
tion de l’efficacité d’une Cependant, elle doit prendre soin de contractualiser l’intervention
publicité en ligne. de chaque prestataire sur la base de la charge, du planning et du

98
Chapitre 4 – Rassembler les facteurs clés de succès

budget précisés dans leurs propositions commerciales. Le bilan, en


fin d’intervention de chaque prestataire, permettra de comprendre
quelles étapes ont eu, au final, le plus d’impact sur le budget ou le
planning. C’est notamment à cette occasion, en tirant les leçons de
chaque bilan, que se prépare la capitalisation d’expérience.
La capacité à limiter l’impact du projet sur l’entreprise peut aussi
être mesurée, bien que sur des bases plus subjectives. Il s’agit de
comparer ce qui était prévu lors de l’étude de faisabilité et dans le
plan de conduite du changement avec les résultats effectifs. Les prin-
cipaux éléments quantitatifs de comparaison sont le nombre de
recrutement et/ou de suppression ou de reconversion de postes, et
le nombre de formations. Les principaux éléments qualitatifs de
comparaison sont le degré d’acceptation de la solution et le degré de
satisfaction lié à son utilisation.
Vérifier les objectifs à moyen terme
Les objectifs à suivre, à moyen terme, sont ceux du site en fonction-
nement. Il s’agit, en général, de mesurer pour chaque période de
référence les indicateurs cités plus haut tels que le chiffre d’affaires
ou les économies réalisés. Pour atteindre ses principaux objectifs, le
site doit offrir une disponibilité, des temps de réponse (temps entre
l’envoi de la requête et la réponse du serveur) et des temps de télé-
chargement (temps nécessaire au téléchargement de tous les
éléments d’une page HTML) homogènes. C’est pourquoi il est
important d’effectuer un suivi qualitatif continu de ses perfor-
mances. Des prestataires spécialisés proposent des outils adaptés à
cette problématique.
De plus, quand le site est transactionnel (site marchand, portail
d’entreprise, etc.) son ergonomie doit être régulièrement optimisée
et ajustée en fonction des remarques des utilisateurs. Il est donc
important de mettre en place un suivi qualitatif de ces aspects au
travers, par exemple, de baromètres trimestriels.

Construire un projet motivant

Outil de management pour les cadres, source de profits ou d’écono-


mies pour la direction générale, atout concurrentiel pour la force de
vente et, surtout, solution pragmatique à des besoins quotidiens
pour les utilisateurs, le projet Web doit convaincre toute l’entre-
prise. Plus encore, il doit devenir un projet d’entreprise, inscrit dans

99
Partie I – Les projets Web

la stratégie générale. Ainsi, chacun y percevra un intérêt réel et


contribuera à son succès.

Fédérer en interne
La réussite d’un projet Web repose en grande partie sur son appro-
priation par les différents acteurs qui participent à sa création puis à
son animation. En effet, si la direction n’est pas convaincue de son
intérêt, les moyens alloués ne permettront probablement pas de le
réaliser correctement. Ensuite, il suffit qu’un utilisateur qui parti-
cipe à l’expression des besoins ne comprenne pas bien les enjeux ou
ne voit pas son intérêt dans le projet pour que son apport soit limité
au strict minimum. Pire, si les acteurs ayant déjà tenté l’expérience
ne sont pas associés à la démarche, ils risquent fort de ne pas
soutenir le projet alors qu’ils sont les plus à même d’en comprendre
l’intérêt, et donc de le promouvoir.
Évaluer la situation
Avant d’essayer de fédérer les différents acteurs, il est intéressant
d’essayer de les identifier et de comprendre leur rôle dans le projet.
Les plus importants d’entre eux sont ceux qui pourront bloquer le
projet par leur décision ou leur indécision. Ce sont souvent des
directions fonctionnelles de l’entreprise, ou des membres par
exemple, de la direction générale, du contrôle de gestion, de la direc-
tion des ressources humaines, de la direction commerciale…
D’autres acteurs, aussi importants, sont ceux qui apportent leur
soutien technique tout au long du projet. Il s’agit presque toujours de
la DSI, de la direction de la communication, mais aussi du support
utilisateur (bureautique) et de directions fonctionnelles. Ils pren-
dront part à des décisions techniques très importantes telles le choix
de la solution technique ou la validation de l’interface utilisateur.
Les relais d’opinion (managers, chefs de services, membres du
comité d’entreprise…) jouent eux aussi un rôle essentiel car ils
doivent distiller l’information officielle au fur et à mesure et mettre
un terme aux rumeurs et autres bruits de couloirs relatifs aux projet.
Enfin, les utilisateurs finals doivent, bien évidemment, être pris en
compte, car sans leur adhésion, rien n’est possible.
Une fois les différents intervenants et leurs rôles respectifs identifiés,
il est nécessaire d’évaluer les forces en présence de manière à disposer
d’une vision claire de qui risque d’être les « supporters » du projet,
ses « détracteurs » ou les « sans opinion ». Sur cette base, il sera
parfois possible de discuter de manière informelle avec certains

100
Chapitre 4 – Rassembler les facteurs clés de succès

d’entre eux pour comprendre leurs motivations (projets avortés,


audits sans suite, échec..) et lister les questions pièges.
Préparer l’argumentaire
Pour que le projet soit fédérateur, il doit s’inscrire dans la stratégie
générale de l’entreprise. Un premier travail de réflexion est donc
souvent nécessaire pour rationaliser et formaliser les raisons qui ont
présidé à l’idée originelle.
Il faut ensuite montrer en quoi le projet peut être un formidable
outil de management. Il existe évidemment autant de bonnes
raisons que de situations pour se lancer dans un projet Web. Cepen-
dant certaines d’entre elles sont assez transversales : attrait des
nouvelles technologies, management en mode projet, possibilité
pour les collaborateurs de rompre avec le quotidien, challenge
implicite du fait de plannings souvent serrés…
Mais une vision fédératrice ne suffit pas. Il est indispensable de
l’appuyer avec des chiffres et des exemples concrets. Les principaux
éléments chiffrés à fournir sont les objectifs, les coûts de création et
de fonctionnement présentés précédemment. Pour que ces éléments
soient pris au sérieux, il est utile de fournir une base de comparaison
avec les concurrents ou, à défaut, avec des entreprises du même
secteur ou de taille et d’organisation identiques.
Enfin, l’exercice le plus délicat consiste à essayer d’imaginer quelles
seront les questions posées par les différents publics et à préparer
une argumentation spécifique pour chacune d’entre elles.
Vendre le projet à la direction
Une fois l’argumentaire finalisé, le travail de séduction commence.
Le premier défi est d’identifier un « champion » (terme anglo-saxon
désignant un appui au sein de la direction générale) et de le
convaincre de l’intérêt du projet. Il est souvent nécessaire de laisser
passer un peu de temps entre le moment où le projet est présenté au
champion et le moment où se dernier est réellement convaincu.
Avec son appui, il sera alors possible d’envisager une présentation
auprès du comité de direction.
La présentation officielle à la direction doit être préparée avec le
champion de manière à identifier les principaux freins à lever et les
idées reçues à démystifier. Cette étape est souvent périlleuse car
d’une part les niveaux de sensibilisation aux nouvelles technologies
sont souvent disparates – tout le monde à un avis sur la question,
mais rares sont ceux qui maîtrisent le sujet – et d’autre part l’image

101
Partie I – Les projets Web

des projets Web tend à se dégrader bien que les premiers projets
n’aient pas eu le temps de produire les résultats escomptés (quand
des objectifs ont été fixés). Ainsi, quand c’est possible, il est utile
d’attendre de disposer du business plan avant de tenter l’aventure.
Mener la conduite du changement
Une fois la direction convaincue, il faudra se mettre en position de
persuader à la fois les principaux relais d’opinion de l’entreprise et
l’ensemble des futurs utilisateurs. Pour cela, une conduite du chan-
gement est nécessaire. L’objectif est de réaliser un bilan de la situa-
tion, de décider d’un plan d’action et de le mettre en œuvre puis
d’en assurer le suivi.
Le bilan s’effectue, auprès des collaborateurs, au travers de question-
naires et d’interviews et, pour la direction, au cours d’un séminaire
qui permettra, en plus, d’élaborer le plan d’action. Ce dernier
comprend en général trois dimensions :
• l’accompagnement des utilisateurs clés (souvent appelés « key
 Key users : users1 ») grâce à un travail de coaching ;
utilisateurs clés. Ce sont
• l’accompagnement collectif des futurs utilisateurs grâce à la
des utilisateurs intégrés
au projet de manière à construction d’une stratégie et d’une vision partagée, le but
ce qu’ils puissent communi- étant de susciter l’adhésion et de renforcer la cohésion d’équipe ;
quer avec les utilisateurs • le déploiement et l’alignement des compétences au travers de la
finals et, si besoin,
leur apporter formation clarification des processus, des missions et des responsabilités, de
et conseil. sorte que chaque utilisateur puisse être formé en fonction de son
rôle futur.
La mise en œuvre du plan d’action commence par le choix d’une
équipe projet clairement identifiée et officiellement présentée aux
collaborateurs. Sa mission est de piloter le projet et d’assurer une
communication régulière avec les futurs utilisateurs mais aussi de
mettre en place des indicateurs qui permettent de mesurer les
résultats.
Pour que cette démarche réussisse, elle doit impérativement impli-
quer les dirigeants et les responsables, favoriser une concertation
continue plutôt qu’une communication descendante, s’ancrer dans
la durée (l’objectif est de favoriser la répétition des contacts plutôt
que de communiquer lors de shows annuels !) et être mesurée par
des indicateurs partagés par tous.

Capitaliser l’expérience
Capitaliser l’expérience permet de réaliser des économies d’échelle
conséquentes (méthodologie unique, choix technologiques effectués

102
Chapitre 4 – Rassembler les facteurs clés de succès

une seule fois pour une même problématique, etc.) et de renforcer la


cohérence entre les différents projets de l’entreprise.
Cette démarche nécessite également une réelle volonté politique de
la part de la direction de l’entreprise. Cette dernière doit pouvoir
accorder au projet quelques jours de charge supplémentaires et lui
allouer un faible pourcentage du budget.
Enfin, la capitalisation de l’expérience repose au quotidien sur un
animateur motivé, capable de faire partager ses objectifs aux presta-
taires comme aux collaborateurs de l’entreprise.
S’appuyer sur le savoir-faire existant
Il existe de nombreuses raisons de s’appuyer sur l’expérience des
collaborateurs de l’entreprise et plus encore lorsqu’il s’agit d’un
projet Web, car, à ce jour, peu de savoir-faire est formalisé. Chaque
expérience est donc précieuse car elle permet d’éviter les erreurs les
plus évidentes autant que les pièges insoupçonnés. Au final, l’entre-
prise qui fait le pari de s’appuyer sur l’expérience interne dispose de
plus de temps et optimise son budget. Cette démarche est aussi
bénéfique en termes de management car elle permet de vivre le
nouveau projet comme une source de motivation plutôt que comme
un acte de récupération de l’effort collectif.
Adopter la bonne attitude
La clé est de se mettre en position d’apprentissage, c’est-à-dire de
rester ouvert aux suggestions et de considérer qu’en matière de
projets Web, personne n’a la meilleure réponse. Chaque projet est
une nouvelle aventure où le travail collectif enrichit autant l’entre-
prise que le prestataire.
En adoptant cette attitude, l’entreprise construit une approche
gagnant-gagnant avec ses prestataires, ce qui aura pour effet de les
motiver. Elle obtiendra ainsi certainement plus qu’en négociant
chaque ligne budgétaire ! Elle pourra, en outre, demander de
nombreuses explications et des éclaircissements qui constitueront,
un véritable transfert de savoir-faire.
Créer un cadre rigoureux
Attention cependant, capitaliser l’expérience demande une grande
rigueur et des efforts quotidiens car, à chaque étape, les journées
sont bien remplies et le temps manque… Difficile dans ces condi-
tions de prendre du recul pour formaliser le problème rencontré et
la solution trouvée !

103
Partie I – Les projets Web

Une technique efficace consiste donc à intégrer la capitalisation


directement au cœur du projet, par exemple en demandant aux
prestataires de formaliser des comptes rendus de réunion, établis sur
un modèle incluant des tableaux problème/solution. Si l’entreprise
est rigoureuse lors de la validation de chaque compte rendu, il
suffira alors en fin de projet de réaliser une compilation classée par
étapes.
Une autre solution consiste à effectuer un bilan à la fin de chaque
étape ou de chaque phase et de profiter de cette occasion pour
formaliser les leçons apprises. Des solutions aussi simples peuvent
faire sourire, elles fonctionnent pourtant très bien et ne nécessitent
pas de logiciel complexe et coûteux !

Parier sur les synergies


Le projet Web est rarement isolé. Il interagit avec des projets pilotés
par les autres directions de l’entreprise (système d’information,
communication, commerciale…) et les moyens généraux. Tous ont
beaucoup à gagner dans la mise en place de réelles synergies. Les
sections suivantes en présentent quelques aspects.
Des synergies avec la communication
Dans le cadre d’un projet de portail, d’intranet ou de site institu-
tionnel, la coordination et la répartition des efforts de production
de contenu avec les équipes en charge du consumer magazine et de
la presse interne peut aboutir à un contenu de meilleure qualité et
d’une quantité plus importante. Elle peut aussi limiter les ressaisies
et diminuer les budgets iconographiques, faisant ainsi gagner du
temps et économiser de l’argent. Plus encore, l’efficacité du dispo-
sitif global de communication à destination des clients internes peut
être améliorée en utilisant à bon escient les caractéristiques de
chaque support.
Le magazine interne peu, par exemple, être réservé à l’analyse et aux
sujets qualitatifs (présentation de services, stratégie de l’entreprise,
point sur un marché…) alors que le portail communique l’informa-
tion chaude sur la concurrence, les performances de l’entreprise et
les mouvements de collaborateurs (le fameux trombinoscope, par
exemple). De même, un site institutionnel peut avantageusement
participer à la diffusion des communiqués de presse et relayer des
messages stratégiques auprès des journalistes. Sans compter son rôle
primordial en cas de crise.

104
Chapitre 4 – Rassembler les facteurs clés de succès

Dans tous les cas, la direction de la communication sera impliquée


dans le projet ne serait-ce que pour valider l’interface. Il est donc
intéressant d’essayer d’identifier les opportunités croisées avant que
ne commence le projet de manière à pouvoir proposer de réelles
synergies dès les premières réunions.
Des synergies avec les commerciaux
De même, les projets menés par les équipes commerciales, notam-
ment ceux liés à la GRC peuvent procurer des atouts importants aux
sites catalogues et aux sites marchands qui, eux, peuvent les alimenter
en données qui permettent de créer des profils, et ainsi de suite.
Un site de marque peut être en partie conçu en fonction des
données du programme de GRC et tenir compte de ce dernier de
manière à lui fournir des adresses de prospects.
Une fois de plus, chaque projet est enrichi par l’autre. Leur valeur
globale est supérieure sans avoir nécessité une dépense d’énergie
supplémentaire.
Des synergies avec les moyens généraux
Dans le cadre d’un portail d’entreprise, certaines saisies incombant
aux moyens généraux (notes de frais, fournitures, etc.) peuvent être
déportées vers les utilisateurs finals. Le portail y gagne des services à
valeur ajoutée pour les utilisateurs. Les moyens généraux peuvent se
concentrer sur des tâches à plus forte valeur ajoutée.

105
Partie I – Les projets Web

Pour aller plus loin

Ouvrages
Jean-Claude Corbel
Management de projet : Fondamentaux-Méthodes-Outils
Éditions d’Organisation – 2005 – ISBN : 978-2708134485
Scott Berkun et Denis Priou
L’art du management de projet
O'Reilly – 2006 – ISBN : 978-2841774203
Jean-Pierre Vickoff
AGILE : l’Entreprise et ses Projet
QI Éditions – 2007 – ISBN : 978-2912843005
Véronique Messager Rota et Jean Tabaka
Gestion de projet : Vers les méthodes agiles
Éditions Eyrolles – 2007 – ISBN : 978-2212121650
Sites
Anere MSI - Les livrables du projet Web
http://www.anere.com/
Gestion de Projet - Organisez-vous !
http://www.gestiondeprojet.com
RAD - Le portail du chef de projet
http://www.rad.fr/
Veblog - Retours d’expériences
http://www.veblog.com/
Maîtriser les risques - Management des risques dans les projets
http://perso.wanadoo.fr/courtot.herve/
Comment ça marche - Introduction à la conduite de projet
http://www.commentcamarche.net/projet/projetintro.php3
Indexel - Le site des décideurs informatiques
http://www.indexel.net
Temesis - La qualité des services en ligne
http://www.temesis.com/

106
Chapitre 4 – Rassembler les facteurs clés de succès

Avis d’experts

Projet Web :
comment convaincre sa direction
Échaudées par des projets Web qui n’ont que rarement tenu leurs promesses, les
directions demandent à être convaincues avant de débloquer des budgets qui pèse-
ront sur la rentabilité de l’entreprise. Voici la synthèse de la démarche gagnante.
1. Identifier le futur groupe de travail
Pour partir du bon pied, le projet doit en premier lieu reposer sur un groupe de
travail solide et motivé. Déterminer qui intervient sur le projet et créer un consensus
peut durer jusqu’à trois mois si la problématique est stratégique ! Mais mettre tout le
monde d’accord autour d’un cahier des charges compréhensible n’a pas de prix,
témoigne Guillaume Laroche, consultant fonctionnel chez SQLI.
2. Rationaliser le besoin
On peut alors aborder le cœur du problème : prouver que le besoin existe, chiffres
à l’appui. Nous sommes en constante écoute du marché. Nous utilisons pour cela des
focus group, des entretiens en face à face et des enquêtes en ligne. Chaque décision,
chaque amélioration, est testée auprès des utilisateurs, résume Claire de Gramont,
directrice marketing de l’éditeur médical Elsevier et responsable de la mise en place
du projet emc-consulte.com. Ces tests sont au final assez intéressants puisqu’ils
permettent à la fois de valider les postulats de travail mais aussi de recueillir très
régulièrement des informations sur les utilisateurs.

107
Partie I – Les projets Web

3. Définir un objectif prioritaire et le quantifier


L’étude de marché ou les entretiens internes doivent déboucher sur un objectif clair
et quantifié dont la définition est loin d’être anodine puisque c’est lui qui
permettra de trancher en cas d’ambiguïté, par exemple entre un portail collaboratif
fournissant du contenu et un intranet de publication fournissant des services. Si la
nuance paraît subtile, les priorités organisationnelles et techniques qui en décou-
lent sont pourtant très importantes ! Cet objectif n’est réellement exploitable qu’avec
des indicateurs de performance qui fourniront des repères au quotidien : chiffre
d’affaires, trafic, nombre de pages vues, estime Claire de Gramont. En interne, la
même démarche doit se concentrer sur les aspects mesurables : gains de temps, réduction
des coûts de maintenance ou accélération des processus, ajoute Guillaume Laroche.
4. Valider la faisabilité économique
Une fois le besoin démontré, reste à apporter la preuve de sa rentabilité. Chez nous,
un projet ne commence pas sans un P&L (pour Profit & Loss, l’équivalent d’un business
plan), précise Claire de Gramont. C’est souvent à ce moment que les choses se
compliquent. En effet, comment prouver a priori que l’ajout d’un contenu ou
d’une fonctionnalité possède une légitimité économique ? Comment évaluer le
coût de la future maintenance évolutive ? Comment dimensionner la taille de
l’équipe dédiée ? L’implication du contrôle de gestion ou de la direction financière
peut apporter une aide précieuse. Le cas échéant, le recours à un expert indépen-
dant peut faire gagner du temps et crédibiliser le projet. Dans tous les cas, pour
être vendeur, le business plan doit être précis et étayé.
5. Impliquer les acteurs
Quand le projet est stratégique, les seuls arguments financiers ne suffisent pas. Il
faut en plus fédérer les acteurs autour du projet. C’est une démarche progressive
basée sur la proximité et la répétition comme l’illustre Claire de Gramont : Nous
avons mis en place un comité électronique dont l’un des objectifs était de lever les doutes
et les peurs. Il se réunissait tous les 15 jours et était composé d’une dizaine de personnes
de la direction – dont la finance – et des services concernés. Une philosophie partagée
par Guillaume Laroche : Le soutien doit venir de l’intérieur. En motivant chaque
personne impactée par le projet, on arrive à de meilleurs résultats car, au final, la direc-
tion ressent cette motivation au travers des managers.
6. Utiliser les bonnes techniques de communication
La direction maîtrise rarement le jargon technique. Les supports qui lui sont
adressés doivent être à la fois précis, concis et compréhensibles par tout le monde.
Il ne sert à rien de laisser un rapport de 60 pages qui ne sera jamais lu. Pour
présenter le projet à la direction, j’utilise en général une présentation PowerPoint d’une
dizaine de slides. Elle repose toujours sur des exemples parlants. Je laisse en plus une
synthèse très courte. Souvent, un simple recto A4 suffit, précise Guillaume Laroche.
Article paru sur www.indexel.net

108
PARTIE II
La conduite
des projets Web
Chapitre 5

La stratégie

Figure 5-1
Les différentes étapes de la stratégie

La compréhension de l’environnement concurrentiel de l’entreprise et sa


constante surveillance sont devenues des éléments essentiels de tout projet
Web. Ainsi, il est aujourd’hui impossible de définir son offre sans avoir  Mapping :
auparavant analysé les forces et les faiblesses des concurrents, y compris représentation
pour un site institutionnel. Tenter l’aventure sans en avoir longuement graphique du
marché. Un mapping
discuté avec les futurs utilisateurs est tout simplement suicidaire ! est bâti sur deux axes
Heureusement, de nombreuses techniques, héritées du marketing tradi- (abscisses, ordon-
tionnel, sont à la disposition de l’entreprise : benchmark, audits, tables nées) qui permettent
de délimiter quatre
rondes, mapping1, interviews, enquêtes en ligne… Ce chapitre en détaille zones concurren-
quelques-unes. tielles spécifiques.

111
Partie II – La conduite des projets Web

Comprendre le marché ou le contexte

Obtenir une vision réaliste du marché (Internet) ou du contexte


interne (intranet, portail d’entreprise, extranet) est devenu incon-
tournable, pour au moins trois raisons.
Les concurrents ne sont pas toujours ceux que l’on croit. Des acteurs
inconnus ou considérés comme quantité négligeable peuvent se
révéler, en réalité, très dangereux. C’est le cas des sites et des
communautés d’intérêt construits autour d’une entreprise. Ces
acteurs sont souvent mieux informés sur l’entreprise que l’entreprise
elle-même. Ceux qui en doutent peuvent visiter http://www.trans-
nationale.org.
http://www.transnationale.org : la bible des multinationales
Ce site propose des fiches très complètes sur toutes les grandes multinationales. L’internaute peut
y découvrir une liste exhaustive des produits, des marques mais aussi – et surtout – toutes les
informations financières depuis plusieurs années, tous les manquements aux droits de l’homme
(recours au travail forcé, etc.), toutes les opérations financières louches (îles Cayman, etc.), tous
les licenciements et manquement au droit du travail… de quoi faire réfléchir de nombreuses
directions de la communication !

En interne, les concurrents d’un intranet ou d’un portail ne sont pas


forcément les autres supports de communication (magazine interne,
circuit TV, etc.) mais plutôt le panneau de petites annonces placé à
côté des machines à café ou bien encore les circuits de communica-
tion informels, bâtis autour de quelques « anciens ».
Dès lors, il est impératif de réviser complètement sa vision et déter-
miner la liste des concurrents réels. Deuxièmement, les attentes et
motivations des clients ne sont pas systématiquement transposables
au Web. Les règles habituelles, les profils des consommateurs, leurs
attentes, les paniers moyens… tous ces repères doivent être redécou-
verts.
Ce constat vaut aussi pour l’interne. Il est, par exemple, dangereux
de présumer du niveau de connaissance des outils informatiques des
collaborateurs et encore plus de leurs attentes : l’expérience montre
qu’ils sont souvent beaucoup plus pragmatiques et réalistes que les
équipes en charge du projet !
Les concurrents habituels de l’entreprise développent des stratégies
propres au Web qui brouillent les cartes. Ainsi, certains sites à succès
que l’on peut croire indépendants ne sont, en fait, que des spin-off
(émanation de leaders du marché).

112
Chapitre 5 – La stratégie

Un exemple connu est Ooshop. Lutter contre ce site, c’est lutter


contre Carrefour… Dans le même ordre d’idées, de nombreuses
stratégies Web qui consistent à faciliter les échanges avec leurs four-
nisseurs sont, par essence, difficiles à identifier et encore plus à
analyser. Cela ne veut pourtant pas dire que ces concurrents ne font
rien !

Le benchmark du marché
Le benchmark du marché a pour principal intérêt d’apporter une
vision claire du marché et des différents acteurs. Il permet également de
lister les bonnes idées. Cette étape constitue un préalable fondamental.
Définir le périmètre du benchmark
Cette tâche est cruciale dans la mesure où elle conditionne la perti-
nence des résultats de l’étude… sur laquelle repose la réussite du
projet. Elle permet à l’entreprise de cadrer sa démarche et matéria-
lise le lancement du projet. C’est aussi, le cas échéant, une bonne
base pour lancer un appel d’offres visant à sélectionner un presta-
taire spécialisé.
Selon les problématiques, il peut être intéressant d’examiner super-
ficiellement un grand nombre d’acteurs pour disposer d’une vision
générale ou, au contraire, de détailler les stratégies de quelques
acteurs identifiés comme étant des concurrents directs. Dans tous
les cas, il ne faut pas se contenter de lister les concurrents déjà
connus de l’entreprise. En effet, sur le Web comme en interne, il est
fort probable que de parfaits inconnus se révèlent être les adversaires
les plus redoutables. Quelques exemples de benchmark sont dispo-
nibles gratuitement sur http://www.benchmarkr.com
Question clé : qui sont vraiment les concurrents ?
Un site institutionnel est plus souvent concurrencé par des sites « amateurs », tels que
http://www.adulf.org par exemple dans le cas de Free, que par les sites des concurrents ou
des médias nationaux. En effet, ces sites sont, en général, très bien référencés et possèdent
souvent plus d’informations sur les entreprises… que les entreprises elles-mêmes. Or, dans
le cas présent, plus le contenu est riche et plus les informations semblent crédibles.
 Pression concurrentielle :
indicateur qui permet
Pour déterminer qui sont les concurrents à examiner, plusieurs tech- d’évaluer la présence des
niques sont efficaces. L’analyse de la pression concurrentielle1 concurrents sur Internet.
permet de se mettre à la place des internautes. En attribuant un Elle repose sur la visibilité,
poids à chaque site en fonction de sa visibilité réelle, cette technique elle-même fondée sur une
étude du positionnement,
apporte une vision la plus réaliste possible de l’importance de du référencement
chaque concurrent. et du linking.

113
Partie II – La conduite des projets Web

 Popularité : la popularité Elle s’appuie sur une analyse de la popularité1, de la position et de la


mesure le nombre de liens complexité des requêtes directes2 de chaque site.
externes qui pointent vers
un site.

 Requêtes directes :
terme qui désigne les URL
saisies directement.

Figure 5-2
Exemple de grille d’analyse de la position concurrentielle entre quelques sites
de marques d’eau minérale

Figure 5-3
Exemple de grille d’analyse de la popularité de quelques sites de marques
d’eau minérale Attention, la popularité est évidemment fonction du trafic des
sites sur lesquels se trouvent les liens. Il est donc impératif de vérifier cette
donnée avant de tirer des conclusions !

Figure 5-4
Exemple de grille d’analyse de la saisie des URL (requêtes directes) de quel-
ques sites de marques d’eau minérale.

Vient ensuite l’analyse de l’audience. Elle permet souvent de recons-


tituer le chemin type parcouru par l’internaute pour arriver sur le
site. Il peut alors être utile d’inclure dans le périmètre du benchmark
les sites d’où proviennent les internautes et ceux vers lesquels ils
partent. Pour plus de détails, voir la section « Analyser les résultats
de la campagne de communication », chapitre 11.

114
Chapitre 5 – La stratégie

Dans la pratique, le chef de projet de l’entreprise formalise un


premier périmètre qui est amendé avec les méthodes proposées
précédemment. Les prestataires les plus indiqués pour cette tâche
sont les cabinets de conseil ou les sociétés spécialisées en assistance
à maîtrise d’ouvrage.
Grille d’analyse de la position concurrentielle
(grille_position_concurentielle.xls)
Grille d’analyse de la popularité (grille_popularite.xls)
Grille d’analyse des requêtes directes (grille_saisie_URL.xls)
Réaliser l’analyse
Pour d’obtenir des résultats pertinents, il est essentiel de ne pas
commencer cette étape avant d’avoir :
• étudié la chaîne de valeur ;
• étudié la stratégie générale des différents acteurs ;
• analysé les chiffres clés (nombre de sites, volume de chiffre
d’affaires, etc.) ;
• défini les principales attentes et/ou actions des internautes.
Dans le cas contraire, l’analyse serait subjective et ne ferait que
fausser l’orientation du projet. Dans le même ordre d’idées, le choix
d’un examen superficiel de nombreux acteurs est souvent dangereux
en première analyse car il ne permet pas de se faire une idée juste des
services proposés par les sites et, a fortiori, de l’infrastructure sous-
tendue.
L’analyse du marché doit faire émerger au minimum trois éléments :
• une liste des acteurs à surveiller ;
• une typologie des stratégies rencontrées ;
• une évaluation des moyens mis en œuvre par chaque concurrent.
Quand l’entreprise dispose de temps et d’un budget conséquent, il
est très utile de compléter l’étude par une liste des bonnes idées de
chaque site et des aspects fonctionnels particulièrement bien traités.
La liste des acteurs à surveiller est essentielle. Elle est constituée,
après un premier tour d’horizon, d’une sélection des acteurs ou des
sites identifiés dans le périmètre de la mission. Seuls ceux qui ont
valeur d’exemple – positif ou négatif – ou qui sont directement
concurrents doivent être retenus. Les acteurs ou les sites de cette liste
pourront être ensuite surveillés régulièrement dans le cadre d’une
démarche de veille stratégique.
L’identification et la formalisation des stratégies des concurrents
constituent le cœur de l’analyse. Elles doivent faire ressortir ce que

115
Partie II – La conduite des projets Web

font les entreprises au moment de l’étude (positionnement, offre de


valeur, etc.) mais aussi ce qu’elles feront dans l’avenir (renforcement
de la présence Internet, abandon de site, développement de
nouveaux services ou contenus…).

Figure 5-5
Exemple de mapping reprenant les sites de marques d’eau minérale Ce
mapping n’est bien sûr pas suffisant. Son intérêt est de repérer la zone
d’analyse qui devra être détaillée par une analyse et un mapping beaucoup
plus pointus.

Les moyens mis en œuvre par les concurrents peuvent être, dans
certains cas, déduits de l’étude de leurs sites. En effet, la simple analyse
d’éléments tels que les URL ou les moyens de paiement permettent
de déterminer certains choix technologiques et donnent un ordre de
grandeur des budgets consentis : un site développé en J2EE et un site
développé en HTML n’ont pas les mêmes coûts de création et de
possession et ne s’inscrivent pas dans la même vision stratégique !
Malheureusement, il est souvent difficile de mener l’enquête pour
évaluer les moyens humains et les budgets réellement impliqués.
Toutes les observations doivent être consignées de manière rigou-
reuse et homogène. Des fiches de site sont généralement utilisées
pour un premier tour d’horizon, puis des grilles de critères et, enfin,
un mapping commenté.

Validation du livrable : attention à la pertinence des axes du mapping


Avant de valider le rapport d’analyse, il est important de vérifier :
– la présence de tous les acteurs listés en amont ;

116
Chapitre 5 – La stratégie

– que les fiches de site sont complètes et de qualité (commentaires factuels et justes) ;
– la pertinence du mapping (choix des axes, positionnement de chaque acteur).

Pour cette tâche, le recours à un prestataire externe est souhaitable car


il apporte du recul et de l’objectivité à l’analyse. Selon la priorité de
l’étude, trois types de prestataires peuvent intervenir : des cabinets de
conseil qui maîtrisent les méthodes d’analyse, des Web agencies qui
ont une forte expérience dans un secteur d’activité, ou encore des
consultants indépendants spécialistes du secteur d’activité.
Rapport d’analyse du benchmark (rapport_benchmark.rtf )
Fiche de site (fiche_site.xls)
Formaliser les recommandations
Les recommandations ont pour objectif d’identifier les pistes de
solutions qui devront être développées lors du positionnement de
l’offre. La pratique courante consiste à définir puis à analyser
succinctement deux à trois hypothèses de positionnement. Les
avantages et les risques liés à chacune d’entre elles ainsi qu’un ordre
de grandeur des moyens à mettre en œuvre doivent être précisés. Au
final, l’entreprise possède une vision suffisamment claire pour lui
permettre de stopper ou poursuivre le projet.

Validation du livrable : les solutions sont-elles vraiment réalistes ?


Les recommandations sont très importantes car elles orientent le projet. Leur validation doit
donc être très critique et vise à évaluer :
– leur valeur ajoutée (qu’ai-je appris ? En quoi cela sert-il le projet ? En quoi permettent-elles
d’atteindre les objectifs ?) ;
– leur pragmatisme (est-ce réaliste ? Est-ce faisable ? Quel est l’écart avec le business plan ?) ;
– leur fondement (comment les coûts ont-ils été évalués ? Est-ce la même solution que le
concurrent ?).

Un prestataire externe peut considérablement accélérer cette


démarche en s’appuyant sur les projets réalisés pour d’autres entre-
prises. Il ne vous donnera jamais le détail des budgets des concur-
rents mais pourra peut-être vous fournir des fourchettes budgé-
taires, un ordre de grandeur des volumétries… De même, son
expérience et la diversité des situations rencontrées apportent
souvent la créativité ou l’audace qui font défaut à l’entreprise.
Dossier de recommandations du benchmark
(benchmark_recommandations.rtf )

117
Partie II – La conduite des projets Web

L’audit de l’existant
Cette étape est le complément indispensable du benchmark. Son
principal objectif est d’établir les forces et les faiblesses de l’entre-
prise par rapport au marché. L’audit de l’existant comprend trois
audits : éditorial, ergonomique, graphique. Il peut être complété par
une analyse de l’audience.
Définir le périmètre
Comme pour le benchmark, la définition du périmètre de l’audit est
effectuée en fonction du temps et des moyens que l’entreprise peut
y consacrer. Cette étape est, elle aussi, cruciale, dans la mesure où
plus l’audit pourra être large et précis et plus l’entreprise disposera
d’une vision claire de son existant. Au final, l’entreprise doit pouvoir
réaliser les audits en interne ou lancer un appel d’offres portant sur
la réalisation des audits.
Selon les problématiques, il pourra être intéressant de focaliser les
efforts soit sur une dimension (éditoriale par exemple), soit sur
l’ensemble des dimensions : éditoriale, ergonomique, graphique,
organisationnelle.
Question clé : quels sites auditer ?
Les grandes entreprises ou organisations se posent fréquemment la même question : quels sites
doit-on auditer pour disposer d’une vision juste de l’image institutionnelle de l’entreprise sur le
Web ? Une réponse sans analyse des statistiques d’utilisation est forcément subjective et conduit à
des catastrophes. En effet, l’expérience montre que le parcours type de l’internaute pour ce genre
de site est rarement celui envisagé « en toute logique ». On pourrait par exemple s’attendre à ce
qu’il arrive directement sur le portail ou le site institutionnel et reparte ensuite vers d’autres sites
plus spécialisés. Or, l’internaute passe presque toujours d’abord par un moteur de recherche qui le
renvoie vers de « vieux sites » de l’entreprise ou des sites « régionaux » (souvent plus anciens
donc mieux référencés), lesquels le renvoient à leur tour vers le site institutionnel. Dès lors, il
devient intéressant d’élargir le périmètre institutionnel de l’entreprise aux « premiers points de con-
tacts » entre l’internaute et l’entreprise. La définition du périmètre sans analyse préalable des statis-
tiques d’utilisation aurait conduit à n’analyser qu’un seul site dans les moindres détails. La
définition du périmètre avec analyse préalable des statistiques d’utilisation conduit à analyser plu-
sieurs sites. La différence est fondamentale.

Dans tous les cas, une analyse poussée des statistiques d’utilisation
comme point de départ est fortement recommandée. Elle permet
bien souvent de limiter l’audit aux quelques rubriques ou quelques
sites jouant un rôle important dans le processus. Cette analyse
garantit également une démarche plus objective car elle permet de
choisir sur la base d’éléments à la fois quantitatifs et qualitatifs.

118
Chapitre 5 – La stratégie

Cette tâche peut être réalisée en interne par le chef de projet. Cepen-
dant, un prestataire externe aura l’avantage de maîtriser parfaite-
ment l’analyse statistiques d’utilisation (qu’elle soient basées sur des  Log : fichier contenant
logs1 ou des marqueurs). Il pourra apporter à l’entre-prise recul et le journal des événements
qui se sont produits sur un
objectivité. Si cette solution est retenue, le chef de projet de l’entre- système. Dans le cas d’un
prise formalise un premier périmètre qui est amendé en fonction des site Web, les logs contien-
conseils du prestataire. nent des informations telles
que l’heure de début et de
Analyser les statistiques d’utilisation fin de visite, le temps passé,
le nombre de pages visi-
Cette étape consiste à étudier des statistiques fournies par le serveur tées, la provenance…
Web – sous forme de fichiers de logs ou de données provenant de
 Marqueur : balises
marqueurs2 de manière à disposer d’une vision objective et précise
insérées dans le code de la
des actions des internautes sur le ou les sites de l’entreprise inscrits page HTML qui permettent
au périmètre de l’audit. de comptabiliser avec
L’analyse des statistiques d’utilisation révèle des informations telles finesse et exactitude
des informations similaires
que : à celles contenues dans
• les pages d’entrée ; les logs.
• les pages de sortie ;
• les pages les plus visitées ;
• le nombre de visiteurs par page ;
• le temps passé sur chaque page ;
• les chemins types parcourus ;
• les référents au départ et à l’arrivée ;
• les mots-clés utilisés pour arriver sur le site ;
• les configurations types…

Tableau 5-1
Principaux outils d’analyse de l’audience

OUTILS ÉDITEURS CERTIFICATION TECHNIQUE

Google http://www.google.com/ana- Non Marqueurs


Analytics lytics

Webos- Weborama Label Diffusion Contrôle Marqueurs


cope http://www.weborama.fr (OJD) pour Weboscope2.1

eStat Echo Interactive Label Diffusion Contrôle Marqueurs


http://www.estat.com (OJD)

Xiti Pro et @Internet est l’éditeur de Xiti Label Diffusion Contrôle Marqueurs
Xiti Analy- http://www.xiti.com (OJD)
zer II

119
Partie II – La conduite des projets Web

Webtrends Webtrends Non Logs


http://www.webtrends.com

Webalizer Bradford L. Barrett Non Logs


http://www.webalizer.com

AWstats Laurent Destailleur Non Logs


http://awstats.source-
forge.net/

En fonction des résultats de cette première analyse, le choix des sites


et des dimensions à auditer pourra soit être remis en cause, un
nouveau périmètre sera alors défini, soit être concentré sur les zones
identifiées comme prioritaires.

Validation du livrable : attention aux méthodes de calcul


Les résultats de cette analyse influencent directement le périmètre et les sujets des audits sui-
vants. Il faut donc être très vigilant sur la pertinence de chaque constat et déduction, notam-
ment en vérifiant avant de valider le livrable :
– les méthodes de calcul employées ;
– les méthodes de consolidation ;
– la pertinence des comparaisons.
Il est aussi utile de s’assurer, en cas de doute, que les phénomènes constatés ne sont pas statis-
tiquement anormaux. Par exemple, j’ai pu constater pour le site d’un ministère une fréquenta-
tion très importante en provenance de Chine. Après analyse, nous nous sommes aperçu qu’il
s’agissait de tests automatiques visant à vérifier la connexion d’une université… Dans tous les
cas, il vaut mieux élargir l’analyse à une période de référence plus large que de passer à l’étape
suivante sans être sur des résultats.

Audit éditorial
L’audit éditorial consiste à analyser la structure éditoriale du site et
de pages clés dans le but d’évaluer la cohérence et la lisibilité de
l’information. C’est aussi l’occasion de vérifier l’adéquation de la
ligne éditoriale avec la stratégie de l’entreprise. Au final, l’entreprise
améliore sa capacité à délivrer ses messages clés : valeurs de marque,
vision d’entreprise, bénéfices produits, prise de position sur un sujet
d’actualité…
Cet audit est particulièrement indiqué pour les intranets, les sites
institutionnels et éditoriaux. Il peut aussi apporter une réelle valeur
ajoutée dans l’étude des sites produits et marchands pour lesquels le
contenu fait vendre (vente de matériel informatique par exemple).

120
Chapitre 5 – La stratégie

L’analyse repose sur l’application de scénarios (jeune diplômé, je


veux savoir comment se passe une embauche ; je veux acheter une
carte graphique d’un modèle particulier, pour cela je dois vérifier ses
caractéristiques techniques et j’aimerais en plus avoir l’avis d’autres
consommateurs…) et l’utilisation de grilles de critères personnalisés
en fonction de chaque problématique.
La check-list de base, à compléter en fonction de chaque projet,
pourrait être la suivante.

Tableau 5-2
Check-list audit éditorial

THÈMES QUESTIONS

Organisation – A-t-on une première impression de sérieux ?


générale – A-t-on une première impression de clarté ?
– L’activité de l’entreprise est-elle évidente ?
– Les noms sont-ils signifiants ?
– Les noms sont-ils incitatifs ?
– Les textes sont-ils calibrés ?
– Les textes sont-ils homogènes ?
– Les textes sont-ils standards ?
– La gestion des volumes est-elle homogène ?
– L’équilibre éditorial/liens/téléchargements est-il adapté ?
–…
Valorisation – Les mises à jour sont-elles fréquentes ?
du contenu – Les mises à jour sont-elles signalées ?
– Les mises à jour sont-elles mises en valeur ?
– Y a-t-il des informations périmées ?
– La proportion information chaude/froide est-elle adaptée ?
– La hiérarchie éditoriale sert-elle à l’objectif du site ?
– Les principales informations sont-elles facilement accessibles ?
– Toutes les informations sont-elles également accessibles ?
– Les thèmes transversaux sont-ils systématiquement présentés ?
– Des liens transversaux existent-ils ?
– Des facilités d’appropriation de la page sont-elles proposées ?
– Des services complémentaires sont-ils proposés ?
– Est-il possible de consulter des archives ?
–…

121
Partie II – La conduite des projets Web

Qualité du contenu – Les articles sont-ils signés ?


– L’auteur est-il présenté ?
– Est-il possible de rentrer en contact avec l’auteur ?
– Peut-on constater la présence d’accroche ?
– Peut-on constater la présence de titre ?
– Peut-on constater la présence d’un résumé ?
– Peut-on constater la présence de relances ?
– Peut-on constater la présence d’exergues ?
– Est-il possible d’en savoir plus ?
– Le style est-il adapté aux différents niveaux éditoriaux ?
– Le contenu est-il daté ? – L’organisation est-elle identifiable en
permanence ?
– La proportion textes/visuels est-elle adaptée ?
– Les visuels sont-ils toujours utilisés à bon escient ?
– Les visuels sont-ils légendés ?
– Les crédits photos, illustrations, schémas sont-ils toujours
présents ?
–…

Cette batterie de questions permet de comparer le ou les sites


étudiés à un site ou à un panel de sites de référence (un site jugé
idéal ou au contraire la moyenne des sites concurrents). Dans
certains cas, il peut être utile de compléter l’analyse par des tests
utilisateurs.

Validation du livrable : attention au respect des scénarios


Avant de valider le rapport d’audit éditorial, il est nécessaire de s’assurer :

– du respect des scénarios utilisateurs ;

– du nombre de rubriques auditées ;

– que la formalisation des problèmes est positive ;

– que l’identification de chaque problème rencontré est claire (ton, calibrage des articles, etc.).

Il est fortement conseillé de confier cette mission à un prestataire


spécialisé ou qui dispose de consultants ayant réalisé une partie de leur
parcours professionnel dans le monde de l’édition ou de la presse.
Grille d’audit éditorial (grille_site_editoriale.xls)
Rapport d’audit éditorial (rapport_audit_editorial.rtf )
Audit ergonomique
L’audit ergonomique consiste à analyser la navigation et tous les
éléments interactifs utilisés par les internautes. L’identification
des dysfonctionnements permet à l’entreprise de fluidifier la navi-
gation et, ainsi, d’améliorer l’expérience vécue par l’internaute.

122
Chapitre 5 – La stratégie

L’analyse repose sur l’application de scénarios et l’utilisation de


grilles de critères personnalisés en fonction de chaque probléma-
tique. La check-list de base, à compléter en fonction de chaque
projet, pourrait être la suivante.

Tableau 5-3
Check-list audit ergonomique

THÈMES QUESTIONS

Accessibilité – L’URL est-elle simple et explicite ?


– Le temps de chargement de la page d’accueil est-il inférieur
au maximum fixé ?
– Le texte apparaît-il en premier ?
– L’image de la marque est-elle reconnaissable ?
– L’activité de la société éditrice est-elle aisément identifiable ?
– L’objectif du site est-il clair ?
– La perception des services correspond-elle aux services existants ?
– La perception du contenu correspond-elle au contenu effectif ?
– La recherche rapide est-elle accessible depuis toutes les pages ?
– Les résultats d’une recherche sont-ils paramétrables ?
– Le site s’affiche-t-il correctement sans images ?
– L’augmentation de la taille des polices est-elle bien gérée ?
– Les attributs ALT des balises sont-ils renseignés ?
– Les attributs TITLE des balises sont-ils renseignés ?
–…
Navigation – Des éléments de codes sont-ils détournés ?
– Y a-t-il un retour à la page d’accueil sur toutes les pages ?
– Existe-t-il plus de sept entrées principales sur le menu ?
– La navigation est-elle répétée en bas de page ?
– Des liens mènent-ils vers des pages en construction ?
– La représentation des liens est-elle standard ?
– Les états liens visités/non visités sont-ils respectés
et homogènes ?
– Les liens externes sont-ils bien identifiés ?
– Y a-t-il des textes soulignés ?
– Les « signifiants » (texte/image) utilisés pour les liens sont-ils
efficaces ?
– Les téléchargements sont-ils bien identifiés ?
– Les tailles et formats des fichiers à télécharger sont-ils indiqués ?
– Si la navigation est graphique, existe-t-il une alternative texte ?
– S’il y a des frames, perturbent-elles la navigation ?
– S’il y a des frames, perturbent-elles l’impression ?
– S’il y a des frames, perturbent-elles la gestion des favoris ?
– Existe-t-il un plan du site ?
– Le chemin est-il bien indiqué ?
– La navigation reflète-t-elle bien la structure du site ?
–…

123
Partie II – La conduite des projets Web

Lisibilité – Les contrastes textes/fond sont-ils corrects ?


– Le couple fond clair/texte noir est-il respecté ?
– Le contenu est-il lisible ?
– La présentation est-elle homogène sur l’ensemble du site ?
– Les éléments graphiques d’interface sont-ils optimisés ?
– Y a-t-il des éléments perturbateurs dans la page ?
– L’information est-elle bien aérée ?
–…

Ces outils permettent de comparer le ou les sites étudiés à un site ou


à un panel de sites de référence. L’audit est mené par un consultant
spécialisé qui propose des solutions pour améliorer les problèmes
rencontrés. Dans certains cas, il peut être utile de compléter
l’analyse par des tests utilisateurs spécifiques (achat d’un produit,
par exemple).

Validation du livrable : des solutions concrètes doivent être présentées


Avant de valider le rapport d’audit, il est conseillé de vérifier :
– la pertinence des constats par rapport aux objectifs du projet ;
– le respect des scénarios utilisateurs ;
– que la formalisation des problèmes est positive ;
– que des solutions sont proposées.

Comme pour l’audit éditorial, il est fortement conseillé de confier


cette mission à un prestataire spécialisé. Il en existe deux types : les
experts en conception de sites qui apportent une vision et des solu-
tions concrètes et les experts en tests utilisateurs qui appliquent une
méthodologie rigoureuse. Les premiers sont recommandés quand le
temps et le budget sont comptés. Les seconds sont préconisés quand
l’entreprise peut limiter leur action à l’analyse et confier la définition
des solutions à des prestataires spécialisés.
Grille d’audit ergonomique (grille_site_ergonomie.xls)
Rapport d’audit ergonomique
(rapport_audit_ergonomique.rtf )
Audit graphique
L’audit graphique consiste à analyser d’une part la cohérence entre
la charte graphique Web et l’identité de l’entreprise et, d’autre part,
entre les différents sites de l’entreprise. Au final, l’entreprise peut
homogénéiser les déclinaisons graphiques de son identité sur le Web
de manière à renforcer son image.

124
Chapitre 5 – La stratégie

Les principaux éléments analysés sont :


• les logotypes et leurs déclinaisons ;
• les codes couleurs ;
• les codes typographiques ;
• le traitement des visuels ;
• les structures de pages, etc.
Le consultant ou le directeur artistique compare soigneusement les
éléments constitutifs des lignes graphiques de chaque site et essaie
de dégager des lignes graphiques directrices. Puis il analyse chaque
ligne graphique pour en comprendre l’essence et y classer les diffé-
rents sites. Ensuite, le consultant évalue la pertinence de chaque
ligne de force en regard des objectifs et de l’identité graphique de
l’entreprise.
En cas de décalage fort, il propose des solutions concrètes pour
homogénéiser l’interface graphique des sites concernés.

Validation du livrable : attention au poids attribué à chaque site


Avant de valider le rapport d’audit graphique, il est utile de vérifier :
– qu’il est complet (chaque site, chaque composant ont été étudiés) ;
– que chaque constat est illustré d’exemples parlants ;
– que la formulation des problèmes est positive ;
– qu’il tient compte de la visibilité de chaque site (le poids de chaque site doit être pondéré en
fonction de sa visibilité).

En fonction du projet, l’audit graphique peut être réalisé soit par un


designer qui aura pour mission d’améliorer ou de recréer l’interface
graphique, soit par un consultant qui intervient par ailleurs sur les
autres dimensions du ou des site(s). Dans le cas de sites destinés à
des zones culturelles différentes (Asie, europe, etc.), il est utile de
prévoir le recours à des consultants qui maîtrisent les codes
graphiques de chaque culture.
Grille d’audit graphique (grille_site_graphique.xls)
Rapport d’audit graphique (rapport_audit_graphique.rtf )
Recommandations
Des recommandations concrètes doivent être proposées en réponse
à chaque problème identifié par le ou les audits. Finalement, l’entre-
prise doit être en mesure de lancer un appel d’offres pour mener à
bien la mise en œuvre des propositions.

125
Partie II – La conduite des projets Web

Plusieurs options sont envisageables. Soit le prestataire qui réalise


l’audit est un professionnel de la conception et de la réalisation de
site, et il est alors utile de lui demander de proposer lui-même des
solutions, soit le prestataire est spécialisé uniquement dans la réali-
sation d’audits, au quel cas il est utile de lancer un appel d’offres
en demandant aux soumissionnaires de décrire précisément ce
qu’ils comptent faire pour répondre aux problèmes soulevés par
l’audit.
Dans tous les cas, cela sous-entend que chaque proposition de
solution soit décrite de manière précise et complétée par un point
sur la technique à employer, la charge de travail et le coût qu’elle
représente.

Validation du livrable : la solution ne suffit pas !


Les solutions proposées doivent impérativement préciser, pour chaque problème rencontré :
– la solution ;
– la charge de travail ;
– le planning de travail ;
– la difficulté de mise en œuvre (risque technologique, risque organisationnel, etc.).

Dossier de recommandations de l’audit


(rapport_audit_recommandations.rtf )
Rapport d’audit (rapport_audit.rtf )

Les tables rondes d’utilisateurs


Les tables rondes d’utilisateurs sont l’occasion, pour l’entreprise, de
discuter avec les futurs utilisateurs de leurs attentes, d’obtenir leur
avis sur les concurrents, de tester la perception du site existant…
Pour être efficaces, elles doivent être organisées avec soin.
Organiser les tables rondes
Cette étape consiste à définir et à mettre en place le cadre. À son
issue, l’entreprise est en mesure de réaliser les tables rondes en
interne ou d’en confier la charge à un prestataire spécialisé.
La première tâche est la définition des objectifs. En effet, celles-ci
peuvent servir de nombreux objectifs en fonction des projets :
comprendre les attentes des utilisateurs, travailler des points de détails
d’éléments fonctionnels, définir une offre attractive, positionner un
site, tester un concept… Le panel, le déroulement des tables rondes et
les supports seront très différents selon l’objectif retenu.

126
Chapitre 5 – La stratégie

Bonne pratique : l’objectif conditionne l’organisation des tables rondes


Si l’on veut par exemple tester un concept, il sera utile de créer un support réaliste qui exprime
le concept (piste graphique par exemple). Après une première partie de discussion non dirigée
visant à recueillir des déclarations spontanées, l’interviewer pourra présenter le concept et com-
mencer à orienter la discussion vers des sujets précis permettant de tester le concept. Si l’objec-
tif est de positionner un site ou de définir une offre, il pourra être intéressant d’utiliser les
éléments recueillis lors du benchmark pour animer la discussion.  Conducteur : document
qui précise le déroulement
Dans le premier cas, une élaboration de maquette et/ou un travail de création graphique seront d’un entretien ou d’une
nécessaires. Cela implique un délai de plusieurs semaines et le recours à un prestataire spécia- table ronde. Il contient
parfois un questionnaire et/
lisé. Dans le second cas, aucun travail particulier n’est à prévoir mis à part la récupération d’élé- ou des supports visuels.
ments présents dans le rapport de benchmark.

Le panel devra évidemment être représentatif de la cible visée. Cela


implique souvent de rassembler dans un même lieu et le même jour
plusieurs nationalités différentes… ce qui est relativement aisé lorsque
la cible est grand public ou interne à l’entreprise. Cela devient très
ardu lorsqu’il s’agit de professionnels externes à l’entreprise.
Une fois l’objectif fixé, le conducteur1 sera formalisé. Il mettra en
avant les informations essentielles de chaque phase de la table ronde :
• durée totale ;
• objectif ;
• niveau d’influence de l’intervieweur ;
• support(s) et mode d’utilisation, etc.
C’est à cette occasion que les supports de chaque phase seront
formalisés. Il s’agit très souvent de questionnaires plus ou moins
dirigés mais une maquette de site ou des captures d’écrans peuvent
aussi s’avérées utiles !
Quand objectif, conducteur et support ont été validés, l’organisa-
tion des tables rondes peut commencer. Il s’agit alors de régler des
aspects logistiques tels que la réservation de la salle et de l’équipe-
ment, mais aussi et surtout humains : recrutement des internautes,
gestion des confirmations, etc.
Cette étape est le plus souvent confiée à un prestataire spécialisé qui,
en plus, réalise la passation des tables rondes. En effet, la qualité de
la méthodologie et la rigueur d’animation sont essentielles pour
recueillir des résultats pertinents.
Animer les tables rondes
Cette étape consiste d’une part à animer les tables rondes et, d’autre part
à retranscrire et à synthétiser les échanges avec les futurs internautes.

127
Partie II – La conduite des projets Web

L’animation des tables rondes, si elle est réalisée par un profes-


sionnel, ne pose pas de problème particulier. En revanche, il faut
veiller à la qualité de la retranscription des échanges et plus encore à
la qualité et la pertinence de la synthèse.
Cette étape requiert rigueur et méthodologie si l’on veut obtenir des
résultats pertinents. L’animateur doit à la fois maîtriser les techni-
ques d’enquête, la stratégie Web et la conception de site. Un profil
qui ne maîtrise pas les techniques liées au Web induira des biais
autant qu’un profil ne connaissant pas les méthodes d’enquête.
Le choix du prestataire peut être effectué soit en fonction du budget
de l’entreprise, soit en fonction de l’importance du projet. Dans le
premier cas, des prestataires dont le cœur de métier est la conception
de site seront plus abordables. Dans le second cas, des prestataires
spécialisés en études qualitatives apporteront plus de rigueur dans la
méthodologie donc, a priori, plus de pertinence.
Analyser les résultats
L’analyse consiste à dégager les grandes tendances exprimées par les
utilisateurs puis à identifier les idées et/ou mécanismes sous-jacents.
Au final, l’entreprise dispose d’une base solide pour comprendre les
attentes et motivations des utilisateurs ou valider/invalider un
concept.

Validation du livrable : attention à la pertinence de la synthèse


Le rapport d’analyse doit être validé après vérification de :
– la présentation de la méthodologie ;
– la pertinence de la synthèse ;
– la présence d’exergues illustrant le propos général ;
– la présence des conducteurs en annexe ;
– la transcription intégrale des échanges en annexe.

Le recours à un prestataire spécialisé tel que Tangenciels (http://


www.tangenciels.com) est fortement conseillé.
Rapport d’analyse des tables rondes (rapport_table_ronde.rtf )

La réunion de présentation et de validation


La réunion de présentation des résultats auprès du comité stratégique
doit être préparée avec soin. La première difficulté de cette étape est
que certains membres peuvent avoir chacun une vision de la réalité
du marché. À partir de là, les remises en cause peuvent morceler la

128
Chapitre 5 – La stratégie

présentation. La deuxième difficulté tient au fait que pour l’audit, il


ne s’agit plus de présenter, comme c’était le cas pour le benchmark,
une vision pertinente du marché, mais bien de critiquer, de manière
constructive, le résultat du travail réalisé par l’équipe actuellement en
charge du dossier. Il est donc essentiel de respecter certaines règles
pour que la réunion se déroule correctement.
En introduction, il est fortement conseillé de mettre en avant :
• le commanditaire de chaque action ;
• les objectifs ;
• les moyens alloués ;
• les outils employés ;
• la rigueur de la méthodologie employée.
Ensuite, et tout au long de la présentation, il faut appuyer le
discours par des :
• chiffres clés ;
• captures d’écrans ;
• exemples irréfutables.
Enfin, les susceptibilités, les rancœurs et les sujets de conflit doivent
être, si possible, identifiés avant la réunion de manière à préparer
une présentation la plus constructive possible.

Tableau 5-4
Comprendre le marché : éléments à valider lors de la réunion

CHAPITRES ÉLÉMENTS À VÉRIFIER


Benchmark – Le périmètre est-il adapté ?
– Les axes du mapping sont-ils pertinents ?
– Le positionnement de chaque acteur est-il précis ?
– Les fiches de site sont-elles complètes ?
– En quoi les recommandations permettent-elles d’atteindre
l’objectif ?
– Les recommandations sont-elles pragmatiques ?
Audit de l’existant – Le périmètre est-il adapté ?
– Les méthodes de calcul utilisées pour analyser l’audience sont-
elles fiables ?
– La logique des déductions liées à l’analyse de l’audience est-elle
fiable ?
– Les scénarios ont-ils été respectés pour réaliser les différents
audits ?
– La formalisation des problèmes est-elle positive ?
– L’identification de chaque problème est-elle claire et détaillée ?
– Chaque constat est-il illustré par des exemples ?
– Les recommandations précisent-elles, pour chaque problème
rencontré, la solution, la charge et le planning de travail, la difficulté
de mise en œuvre ?

129
Partie II – La conduite des projets Web

Tables rondes – La méthodologie est-elle détaillée ? Si oui, les conducteurs


utilisés sont-ils présentés en annexe ?
– Existe-t-il une synthèse des résultats ? Si oui, est-elle
pertinente ?
– Des extraits d’interviews sont-ils présents pour illustrer
le propos ?

Définir l’offre

Définir une offre Web demande de remettre en cause ses croyances


car les utilisateurs, nous l’avons vu dans les pages précédentes, ne
sont pas tels que nous les imaginons.
Ils sont intraitables et n’adhèrent à une offre que si elle leur apporte
davantage que ce qu’ils peuvent obtenir d’une manière plus conven-
tionnelle. Ainsi, l’offre doit impérativement améliorer l’existant ou
apporter une nouveauté. Il peut s’agir de services équivalents
commercialisés à des prix beaucoup plus bas (matériel informatique
par exemple), de services à forte valeur ajoutée sans équivalents
 Fil : texte d’information
très court de type télex. On
(abonnement à des fils1 d’informations personnalisés) ou encore de
parle souvent d’un fil AFP. services complémentaires (guichet de banque en ligne).
Dans tous les cas, les internautes sont sensibles au respect du terri-
toire de la marque et à ses valeurs. Ils n’acceptent que rarement des
discours et des offres décalés. Attention donc aux marques position-
nées différemment en fonction des zones géographiques. Sur
Internet, l’internaute y accède en deux clics !
Beaucoup de produits ne peuvent pas être vendus directement sur
le site pour des raisons de logistique, de coût ou de législation. Les
sites de ces produits sont par conséquent « condamnés » à innover
dans des services complémentaires. L’information est alors au cœur
de la bataille.

130
Chapitre 5 – La stratégie

Figure 5-6
http://www.nestle.fr
Plus qu’un simple site institutionnel : conseils, idées, recettes, informations
nutrition, santé, bien-être…

Définir le positionnement
L’objectif de cette étape est de préparer le travail de définition de
l’offre en arrêtant un positionnement et en précisant le concept
général du produit.
Positionner le site
Cette tâche consiste à définir et à formaliser le positionnement du
site par rapport à ses concurrents et ce, dans une vision dynamique,
c’est-à-dire planifiée dans le temps. Au final, l’entreprise doit
disposer d’un axe clair sur lequel s’appuyer pour définir et faire
évoluer son offre.
Le positionnement Web est défini en opposition aux concurrents de
manière à différencier l’offre de l’entreprise, à moins, bien sûr,
qu’une stratégie me too1 ait été décidée.  Me too : « moi aussi »
en français. Stratégie qui
Le positionnement Web ne doit pas déroger aux règles tradition- consiste à laisser le leader
nelles du marketing. En effet, le positionnement du site ne sera du marché innover puis
perçu et accepté comme légitime que s’il s’inscrit totalement dans les à copier l’innovation. Elle
permet de présenter au
valeurs d’image de la marque et apporte en outre un bénéfice utili- consommateur un produit
sateur réel. Cela paraît évident mais bien peu de sites de marques performant à moindre coût.
respectent cette règle ! La marge est donc plus
importante. La seule limite
est liée à l’image de suiveur
qui en découle.

131
Partie II – La conduite des projets Web

Repère : les onze lois immuables de la construction d’une marque sur Internet
Al & Laura Ries proposent onze lois à suivre pour créer une marque Internet pérenne :
1. Loi du et/ou (Internet peut être un business ou un support de communication, mais pas les deux).
2. Loi d’interactivité (sans échange avec l’internaute, la marque ne se développe pas).
3. La loi des noms communs (sans un nom original, la marque n’existe pas).
4. La loi du nom se suffisant à lui-même (le nom est la marque, il doit donc être bien choisi).
5. La loi de singularité (la marque est première ou n’est pas).
6. La loi de communication (la marque à plus d’opportunités de communication offline qu’online).
7. La loi de globalité (la marque est d’emblée internationale et « vit » vingt-quatre heures sur
vingt-quatre, sept jours sur sept).
8. La loi du temps (pour exister, la marque doit être la première).
9. La loi de vanité (la marque doit rester concentrée, être humble).
10. La loi de divergence (tout le monde parle de convergence alors que c’est l’inverse qui se passe).
11. La loi de transformation (les marques sont profondément transformées par Internet).
Source : The 11 Immutable Laws of Internet Branding (éditions Herper Business).

Le positionnement Web s’inscrit dans le temps. Le benchmark est un


outil précieux qui permet d’anticiper les actions des concurrents et de
définir un positionnement Web qui évolue dans le temps. Cet aspect
est fondamental car la relation site/utilisateurs se construit dans la
durée. Il est en effet difficile d’apporter un niveau de service maximal
dès la première année. Le positionnement doit donc évoluer en fonc-
tion des capacités de l’entreprise et des résultats du site.
À noter : le positionnement Web est dynamique
L’un des exemples les plus réussis de construction programmée d’un positionnement est celui
d’Amazon. En effet, le site a d’abord été positionné comme LA librairie en ligne. Puis l’entreprise
s’est donnée le temps de maîtriser tous les aspects de la relation avec ses utilisateurs avant de se
repositionner comme LE site de commerce électronique. Il est évident que les promesses liées au
deuxième positionnement n’auraient pas pu être tenues dès le lancement.

Dans la pratique, cette tâche est réalisée soit en interne par le chef
de projet soit par un duo chef de projet de l’entreprise/consultant
externe. L’expérience montre que la deuxième solution, bien que
plus coûteuse, est aussi plus riche et aboutit à des positionnements
plus équilibrés et plus réalistes.

Validation du livrable : le positionnement est-il dynamique ?


Avant de valider la note de positionnement, il faut vérifier que le positionnement proposé est
précis et que son évolution dans le temps est décrite.

132
Chapitre 5 – La stratégie

Note de positionnement (note_positionnement.rtf )


Définir le concept général
La définition du concept est un exercice de style qui permet de
trouver un juste équilibre entre les attentes des internautes, les
objectifs de l’entreprise (fidéliser ses clients acquis, recruter de
nouveaux clients, communiquer), les valeurs de la marque et le posi-
tionnement envisagé. Au final, l’entreprise a résumé son projet en
une phrase clé et jeté les bases du marketing mix Web.
Une technique efficace revient à définir l’USP1 du site puis à la  USP : Unique Selling
Proposition ou « proposi-
formuler sous forme soit d’une proposition de valeur utilisateur soit
tion de vente unique »
d’une promesse. Les deux formulations se valent et le choix de l’une en français. Ce concept
d’elles est réalisé en fonction de la culture du groupe projet. permet de formaliser l’offre
de valeur du produit (ou
La proposition de valeur utilisateur force l’entreprise à formuler le du site) de manière
concept dans l’optique et avec les mots d’un utilisateur. Plus qu’un à le différencier.
exercice de style, cela lui permet d’aller directement à l’essentiel et
surtout de rester très claire jusqu’à la fin du projet.
La promesse doit être appréhendée comme la promesse de la copie
stratégie utilisée par les agences de publicité. L’entreprise définit
donc une promesse qui se traduit par un bénéfice consommateur et
une justification.

Figure 5-7
Les quatre éléments du concept

133
Partie II – La conduite des projets Web

Exemple de formulation de l’offre d’un site de marque d’eau minérale tel que
volvic.fr
A - Formulation « Copy strategy »
Promesse : volvic.fr vous coache au quotidien.
Preuve : Zinedine Zidane vous donne ses conseils…

B - Formulation « USP »
Proposition : Zinedine Zidane m’aide au quotidien à maintenir mes efforts grâce à un agenda
motivant et des conseils efficaces.
L’intérêt de la première formulation est qu’elle est simple, mémori-
sable et incitative. Elle peut être utile, même en interne, pour faire
adhérer au projet. L’intérêt de la deuxième formulation est qu’elle
décrit, avec concision et en « termes utilisateur », ce que le site doit
être.

Validation du livrable : une offre évidente


Avant de valider le livrable, il faut vérifier que l’offre, telle qu’elle est formulée, semble « évi-
dente » à l’ensemble des collaborateurs du projet.

Cette tâche peut être réalisée en interne ou confiée à un prestataire


spécialisé en stratégie Web (cabinet de conseil, Web agency, etc.).
Note de présentation du concept (note_concept.rtf )

Définir le marketing mix


Pour concrétiser l’offre, un marketing mix Web est indispensable. Il
constitue le socle sur lequel le business plan sera créé, s’il n’existe pas
encore.
Le marketing mix Web doit être appréhendé comme n’importe quel
marketing mix même si les possibilités offertes par les technologies
Web brouillent les cartes en poussant à mixer les offres, à les
présenter sous plusieurs formes, à vendre plusieurs fois un même
produit avec des politiques tarifaires spécifiques…
Le produit (les contenus et les services)
La base du marketing mix est la définition du produit en fonction
de la cible visée. Contrairement aux idées reçues, dans le cas d’un
projet Web, le « produit » n’est presque jamais le site lui-même, mais
le contenu ou les services que l’on y trouve. Attention donc à ne pas
confondre contenant et contenu !

134
Chapitre 5 – La stratégie

Repères : où trouver des études sur les internautes ?


En dehors des chiffres clés gratuits du Journal du Net (http://www.journaldunet.com) ou ClickZ
(http://www.clickz.com/stats/), des sites comme eMarketer (http://www.emarke-
ter.com), Nielsen//NetRatings (http://www.nielsen-netratings.com), ou Omniture (http://
www.omniture.com) fournissent des informations payantes de qualité.

La dématérialisation de l’offre, rendue possible par les technolo-


gies Web, balaie les contraintes physiques habituelles : l’accès aux
informations et aux services est quasiment instantané, des
gammes très larges et très profondes peuvent être présentées sans
difficulté, l’information sur chaque produit peut être aussi étoffée
que possible… Bref, on assiste sur le Web à un glissement de la
valeur du produit vers l’information autour produit. C’est
notamment le cas pour les produits complexes ou technologiques
tels que les ordinateurs individuels, les voitures ou les produits
culturels pour lesquels l’achat est souvent raisonné. Observez-
vous en train d’acheter un livre en ligne : vous favorisez les sites
riches en information (auteur, éditeur, critiques officielles et des
autres consommateurs…). Le constat est le même quand vous
choisissez un bar ou un restaurant : les sites qui ne proposent pas
une photo de leur vitrine et de la salle sont, à moins d’être très
connus, systématiquement évités… C’est grâce à cela que des
sites comme http://www.amazon.com ou http://
www.eyrolles.com font quotidiennement la différence. L’infor-
mation a de la valeur !
Le glissement de la valeur perçue peut même être, dans certains cas,
beaucoup plus important. À tel point que les services autour du
produit concentrent la quasi-totalité de la valeur. Ainsi, l’offre des
cybermarchés est plus composée de services que de produits :
Caddie personnalisé et prérempli, livraison à domicile à des heures
pratiques…
L’information ou les services ont d’autant plus de valeur qu’on y
accède facilement. Le consommateur qui a, par malheur, essayé
d’acheter un ordinateur chez Surcouf le samedi matin a souvent dû
faire face à des vendeurs débordés. Le même consommateur qui s’est
connecté au site de la même enseigne au même moment y a trouvé
plus d’informations et y a accédé dans de meilleures conditions. Il y
a fort à parier qu’il soit dorénavant fidèle au site Web plutôt qu’au
magasin. L’accès à l’information conditionne l’expérience vécue par
le consommateur. Cette expérience a de la valeur !
Enfin, le contexte dans lequel le consommateur décide d’acheter est
fondamental. Un consommateur à qui un ami a recommandé une

135
Partie II – La conduite des projets Web

enseigne et un produit sera, dans un magasin, réassuré par le


vendeur ; sur le Web, la fluidité de la navigation, le sérieux des
textes, des visuels et du design, la rapidité avec laquelle il arrive à la
bonne information jouent le même rôle de réassurance. La bonne
information au bon moment sous la bonne forme : voilà la clé pour
maîtriser le processus d’achat impulsif sur le Web. Le contexte a de
la valeur !
La définition d’un produit composé de services consiste à lister les
fonctionnalités centrales (communes à tous les sites du segment) et
secondaires du site (différenciant le site). Ces fonctionnalités
peuvent être présentées graphiquement pour plus de clarté. Par
exemple, le site http://www.houra.fr propose comme fonctionnalité
centrale la vente de produits de grande consommation et comme
fonctionnalité secondaire la personnalisation et la mémorisation du
Caddie. Dans le même ordre d’idées, http://www.amazon.com s’est
fortement différencié (puis ses concurrents ont repris l’idée) avec
son service de personnalisation des cadeaux : choix du papier, possi-
bilité de joindre un message…

Figure 5-8
Exemple de représentation de l’offre du site http://www.houra.fr

La définition d’un produit, constitué de contenu, consiste d’une


part à définir ces contenus en précisant ceux qui sont différencia-
teurs, et d’autre part à fixer la ligne éditoriale.

136
Chapitre 5 – La stratégie

Figure 5-9
Exemple de représentation de l’offre du site http://www.lemonde.fr

Dans bien des cas, le produit est constitué d’un mix entre contenus
et service. Si l’on regarde, par exemple, le site du Monde (http://
www.lemonde.fr) on peut remarquer qu’il présente le contenu du
quotidien papier du jour mais aussi :
• un contenu spécifique via des mises à jours régulières d’articles ;
• un contenu spécifique via des dépêches d’agences en continu et
en temps réel ;
• un contenu spécifique via de nombreuses animations.
Sans oublier des services à forte valeur ajoutée :
• l’accès à plus de sept cent mille articles via un moteur de recherche ;
• des newsletters thématiques ;
• des forums ;
• des chats avec des membres de la rédaction, etc.

Bonne pratique : une étude d’impact pour mesurer les effets sur l’organisation
Définir une nouvelle offre a souvent un impact fort sur l’organisation de l’entreprise. Un « simple »
site institutionnel qui offre de l’information à ses publics cibles doit, pour être efficace, prévoir une
équipe capable de répondre aux e-mails, d’alimenter le site en actualités, d’orienter les journalistes
vers le service adéquat, sans parler de la modification des processus de production de l’infor-mation,
des nouveaux modes de validation à mettre en place… Dans bien des cas, une étude d’impact
permet de mesurer a priori les modifications d’organisation nécessaires et de dimensionner les bud-
gets liés. Dans le cas d’un site marchand, cette tâche est, évidemment, incontournable !

137
Partie II – La conduite des projets Web

Un produit est toujours défini en fonction d’une cible. Pour un


projet Web, cet adage devient fondamental car la relation de force
tend à s’y inverser : le client se connecte quand et où il veut. En
outre, sa capacité à « zapper » en un clic le rend très exigeant, et lui
présenter un contenu ou un service inadapté est le meilleur moyen
de le perdre. Dès lors, chaque produit doit s’adapter autant que
possible à chaque cible ou microcible.
Ainsi, un même contenu peut être présenté de manière différente en
fonction du contexte. Un kit festif sera par exemple présenté pour
les enfants dans la catégorie « organiser un goûter » et pour les
adultes dans la catégorie « préparer le Nouvel An »… Seuls l’accès et
la mise en scène de l’information changent. Pourtant, chaque cible
se reconnaît dans l’offre qui lui est proposée.
Dans certains cas, cela ne suffit pas et un produit spécifique devra
être créé pour chaque cible sur la base d’un concept commun. Le
Journal du net en est un très bon exemple. Le Journal du net, Journal
du Net développeurs, Journal du Net solutions, Emploi Center, L’inter-
naute… partagent la même interface et une base commune de
contenu mais chaque édition est adaptée à une cible particulière (ou
à la même cible mais à des besoins différents dans le cas de Journal
du Net développeurs et Emploi Center).
La définition du produit peut être réalisée en interne ou avec l’aide
d’un prestataire spécialisé en stratégie Web.

Validation du livrable : une description précise


Avant de valider le livrable, il est important de vérifier que :
– les services et/ou le contenu sont présentés en détail (l’idéal est de présenter une grille synop-
tique qui confronte l’offre du projet à celle des concurrents) ;
– la marque est légitime pour proposer le produit et qu’elle est crédible.

Le prix (la contrepartie)


L’une des principales difficultés du marketing mix Web est la défi-
nition de la politique tarifaire car, depuis ses débuts, le Web propose
 Business model : des services et des contenus à valeur ajoutée sans qu’il soit nécessaire
schéma qui représente de payer pour y accéder. Ceux qui essaient de modifier leur business
les interactions commer-
ciales et financières. Il model1 en passant du gratuit au payant connaissent des fortunes
permet d’identifier les prin- diverses. Et, paradoxalement, seuls les sites payants depuis leurs
cipaux points de dépenses débuts s’en sortent bien. Cela ne veut pas dire pour autant
et de revenus d’un projet.
qu’aucune contrepartie ne soit exigible… bien au contraire !
Le business model fait partie
du business plan.

138
Chapitre 5 – La stratégie

En fait, il faut dissocier deux cas de figure : soit le projet a pour but
de vendre un produit ou un service, soit le projet est mené sans but
lucratif mais doit coûter le moins cher possible. Dans le premier cas,
on parlera véritablement de politique tarifaire, alors que dans le
second, il s’agira en réalité de trouver des contreparties permettant
d’alléger le coût final du projet.
La définition de la politique tarifaire consiste à choisir des modes de
facturation (à la durée, à la session, au forfait, sous forme d’abonne-
ment annuel, en bundle avec un produit physique…) et à fixer des
prix acceptables. Ces derniers sont, en général, déterminés, via la
méthode du prix psychologique, en fonction du marché et des spéci-
ficités du produit. Le choix du mode de tarification peut être déter-
miné en étudiant les concurrents mais aussi lors de tables rondes
d’utilisateurs, avec des entretiens en face à face ou des questionnaires.
La définition des contreparties dépend de la nature du projet.
Cependant, en général, la contrepartie exigée pour accéder au
contenu, effectuer un téléchargement, profiter d’un service… est la
saisie d’informations personnelles qualifiées (e-mail, sexe, âge, caté-
gorie socioprofessionnelle, centres d’intérêt…). Ces données seront
plus ou moins fiables en fonction de la cible du projet : des inter-
nautes laisseront souvent de fausses informations alors que des
professionnels seront plus sérieux et que des membres d’une
communauté donneront des informations justes et nombreuses.
Dans certains cas, une contrepartie peut être négociée. C’est notam-
ment le cas quand le projet simplifie ou allège le travail des fournis-
seurs de l’entreprise. Le temps gagné peut alors se négocier.

Validation du livrable : des objectifs pour chaque segment


Avant de valider le livrable, il faut vérifier que :
– les modes de facturation par segments usages/cibles sont précis ;
– les prix par segments usages/cibles sont cohérents ;
– des objectifs quantitatifs sont fixés à chaque segment.

La définition de la politique de prix et de facturation peut être


réalisée en interne ou confiée à un prestataire spécialisé.

139
Partie II – La conduite des projets Web

Figure 5-10
http://www.guerlain.com
Le site propose un premier niveau de service « gratuit », mais pour bénéficier
de conseils personnalisés, l’internaute est invité à donner son adresse e-mail.

La diffusion
La politique de diffusion est très importante dans le cas des projets
Web, et ce pour deux raisons. Premièrement, la dématérialisation
des contenus et services offre plus de possibilités que dans le monde
physique. Deuxièmement, il existe des risques forts de conflits avec
les autres circuits de distribution. Par exemple, il est probable que
Carrefour et WallMart ne voient pas d’un bon œil les ventes directes
réalisées par L’Oréal sur Internet !
Les technologies Internet offrent de grandes opportunités comme la
possibilité de vendre, en marque blanche, un service ou un contenu
sans que l’investissement initial soit pour autant plus élevé (la
conception devra en revanche en tenir compte). Ainsi, l’entreprise
vend plusieurs fois le même service ou contenu alors qu’il ne lui
coûte qu’une seule fois.

140
Chapitre 5 – La stratégie

Figure 5-11
http://www.spreadshirt.com
Spreadshirt permet de créer sa propre boutique en quelques clics et de l’inté-
grer dans son site.

Figure 5-12
http://www.lesnouvelles.net
Le contenu produit une fois est diffusé sur des centaines de sites. À chaque fois,
le rappel de l’origine du contenu constitue un formidable outil de génération
de trafic qualifié pour un coût nul.

141
Partie II – La conduite des projets Web

À l’inverse, certaines entreprises ont la possibilité de ne se concen-


trer que sur la création de contenu à valeur ajouté qui les aidera à
vendre leurs produits… sur d’autres sites que le leur. Ainsi, une
marque d’eau minérale a intérêt à développer une information
détaillée et des conseils cohérents avec sa marque (les bébés, la
minceur, etc.) et à les fournir aux sites marchands plutôt que
d’essayer de vendre ses bouteilles sur son propre site.
Concrètement, la politique de diffusion Web doit préciser les diffé-
rents circuits envisagés et leur attribuer des objectifs quantitatifs.

Validation du livrable : des objectifs quantifiés pour chaque circuit


Le livrable sera validé après avoir vérifié que :
– il existe un objectif quantifié pour chaque circuit ;
– tous les circuits de diffusion ont été envisagés ;
– l’abandon de certains circuits est justifié.

Cette tâche peut être réalisée en interne avec l’aide d’un consultant
externe spécialisé ou d’un cabinet de conseil.
La promotion
La valeur d’un site ou d’un intranet dépend en premier lieu de son
trafic. Plus les visiteurs sont nombreux, plus le potentiel de commu-
nication ou de transaction est important et plus l’investissement
peut être rentabilisé. L’objectif de la promotion est de créer ce trafic
lors du lancement puis de l’entretenir tout au long de la vie du site.
Les stratégies de communication, de positionnement et de réfé-
rencement sont détaillées dans la section « Communication » du
chapitre 11. Elles sont complétées, au quotidien, par des outils
permettant de fidéliser les utilisateurs :
• newsletter ;
• informations utiles ;
• services utiles ;
• e-mailing ;
• marketing viral ;
• forums ;
• alertes...
Le but de la politique de promotion est de déterminer le budget qui
sera alloué à ces actions.

142
Chapitre 5 – La stratégie

Validation du livrable : des choix quantifiés et cohérents


Avant de valider le livrable, assurez-vous que le budget est cohérent avec :
– les standards du marché ;
– les objectifs du projet.

Cette tâche peut être réalisée en interne avec l’aide d’un consultant
externe spécialisé. Elle peut aussi être confiée à un prestataire spécia-
lisé tel qu’une agence interactive.
Marketing mix Web (marketing_mix.rtf )
La réunion de présentation et de validation
Cette réunion de présentatixon a pour objectif de faire adhérer le
comité stratégique au projet. À la fin de la réunion, il décide d’aban-
donner ou de continuer le projet et d’allouer des moyens en consé-
quence.
La présentation doit donc faire ressortir l’intérêt de l’offre (facteur
de différenciation, segment ou niche adressée…) et sa rentabilité
potentielle.

Tableau 5-5
Offre : éléments à valider lors de la réunion

CHAPITRES ÉLÉMENTS À VÉRFIER

Positionnement Le positionnement est-il dynamique ?


L’offre semble-t-elle évidente ?
Marketing Mix Le produit est-il décrit en détail ? Les services ou contenus
différenciateurs sont-ils mis en avant ?
La politique tarifaire est-elle déclinée et quantifiée en fonction
de chaque segment ?
Les objectifs assignés à chaque circuit de diffusion sont-ils
quantifiés ?
Le budget de promotion est-il cohérent avec les objectifs
du projet et les standards du marché ?

143
Partie II – La conduite des projets Web

Pour aller plus loin

Ouvrages
Jean-Noël Kapferer
Les Marques, capital de l'entreprise : Créer et développer des marques
fort
Éditions Eyrolles – 2007 – ISBN : 978-2212539080

Seth Godin et Larry Cohen


Permission marketing : La bible de l'Internet marketing
Maxima Laurent du Mesnil éditeur – 2006 – ISBN : 978-
2840014546

Jonas Ridderstrale et Kjell Nordstrom


Funky Business Forever: How to Enjoy Capitalism
Financial Times Management – 2007 – ISBN : 978-0273714132

Don Peppers et Martha Rogers


Le One to One en pratique
Éditions d’Organisation – 1999 – ISBN : 978-2708117396

Rick Levine, Christopher Locke, Doc Searls et David Weinberg


The cluetrain manifesto: The End of Business As Usual
Perseus Books Group – 2001 – ISBN : 978-0738204314

Chris Anderson, Brigitte Vadé et Michel Le Séac'h


La Longue Traîne : La nouvelle économie est là !
Pearson Education – 2007 – ISBN : 978-2744062698

Sites
Plusdetudes.com
http://www.plusdetudes.com/

Le portail des PME


http://www.portailpme.fr/

Benchmarkr
http://www.benchmarkr.com

144
Chapitre 6

Le business
plan

Figure 6-1
Les différentes étapes du business plan

Le business plan dans le cadre du projet Web


Le business plan et la stratégie sont deux démarches complémentaires. Il
n’existe pas d’ordre précis pour les mener même si les Anglo-Saxons préfè-
rent réaliser d’abord le business plan, au contraire des Français qui ont
l’habitude de commencer par la stratégie avant d’aborder les considérations

145
Partie II – La conduite des projets Web

financières. À mon sens, les deux démarches peuvent être utilement


fusionnées en une seule étape.

Le business plan, un outil stratégique


Le business plan (ou « plan d’affaires » en français) est un document
de synthèse qui contraint le chef de projet à s’assurer qu’il a les
réponses à toutes les questions et l’aide à mieux appréhender les
risques qu’il compte faire prendre à son entreprise et à ses parte-
naires. La rédaction du business plan est donc une tâche ardue et
incontournable.
Plus qu’un simple outil de réflexion, c’est un support de communi-
cation que le chef de projet va utiliser pour expliquer, persuader et
vendre le projet aux collaborateurs internes, aux investisseurs poten-
tiels et, dans certains cas, aux prestataires extérieurs.
Le business plan est également un outil de gestion qui permet au
chef de projet de coordonner les actions dans l’entreprise et de
donner des prévisions chiffrées aux différents interlocuteurs internes
et externes. Une fois le projet accepté, il servira à mesurer l’atteinte
de ces objectifs et devra, par conséquent, être révisé en fonction de
l’évolution de l’activité et de l’environnement. Ce sera plus particu-
lièrement le cas lors d’un changement de concurrence, d’un lance-
ment d’activités nouvelles ou encore d’opérations exceptionnelles.
Le terme « business plan » est issu du vocabulaire financier, mais
rares sont les projets Web dont les facteurs clés de succès sont
uniquement économiques. Ce document doit donc être à même de
convaincre tous les acteurs impliqués et pas uniquement la direction
financière ou les acteurs financiers. Il doit principalement démon-
trer que l’intérêt, qui est à la base du projet, est réel et que l’équipe
qui en a la charge a (ou va acquérir) les compétences nécessaires
pour le mener à bien. Il doit donc couvrir les dimensions marketing,
organisationnelles, technologiques et financières.
Le projet Web étant rarement isolé, le business plan doit clairement
identifier quels en sont les risques, quelle est la place du projet dans
la stratégie de l’entreprise, et quels sont les moyens technologiques
et humains qui devront être mis en œuvre.

Qu’est-ce qu’un business plan réussi ?


Le document final doit être clair et précis. Composé de phrases
courtes et simples, il repose sur une articulation logique et cohérente.
La qualité d’un business plan ne se mesure pas à la quantité d’infor-
mations mises à disposition, mais plutôt à sa concision et à sa perti-

146
Chapitre 6 – Le business plan

nence. C’est pourquoi il doit être avant tout réaliste. Les chiffres
« gonflés » ou les prévisions trop optimistes sont à éviter à tout prix
pour laisser place à des hypothèses pragmatiques, réalistes et justi-
fiées.
Pour garantir la qualité du document et de sa rédaction, il est
possible de se faire aider par des spécialistes, en interne par le dépar-
tement business développement, s’il existe, ou par des collègues
expérimentés, et en externe par un des nombreux organismes d’aide
au développement d’entreprise.

Bonne pratique : le business plan n’est pas figé


Le business plan est dynamique. Il doit refléter la réalité d’un marché et d’une stratégie à
l’instant T. Il doit donc être le plus à jour possible et évoluer au fil des recherches d’informations
et de la mise en place du projet.
De plus, chaque projet étant différent, le plan et l’argumentation devront tenir compte des spé-
cificités de chaque situation.

Le business plan doit être adapté à ses lecteurs. Ce n’est pas un docu-
ment uniquement comptable, la partie financière n’étant que l’illus-
tration des autres éléments. La synthèse doit donc être rédigée en
fonction du public visé de manière à s’assurer que les éléments les
plus importants sont mis en avant. Le document destiné à la direc-
tion financière devra, par exemple, mettre l’accent sur la capacité du
projet à s’autofinancer et limitera les aspects techniques et marke-
ting à la synthèse. Au final, plusieurs versions du document
d’origine seront produites afin de répondre aux besoins du moment
et du public cible.

Rédiger le business plan

Lors de la création du business plan, la préparation du sommaire est


aussi importante que la rédaction du document final. Celui-ci doit
tenir compte des contraintes du projet de sorte que toutes les cases
puissent être remplies avec pertinence dans les délais et le budget
impartis. Mieux vaut être modeste et proposer un document clair
que de se lancer dans la rédaction d’un document certes volumineux
mais de qualité médiocre !

147
Partie II – La conduite des projets Web

La synthèse du business plan


D’une à deux pages, la synthèse du business plan doit présenter le
projet d’une façon intéressante, concise et logique. Le lecteur doit
être à même de comprendre en cinq minutes les objectifs du projet,
la proposition commerciale et, le cas échéant, le soutien attendu. La
technique dite de « l’Elevator Pitch » est efficace : le projet est
résumé en une phrase, puis en un paragraphe et enfin en une page.
Cette partie est la plus importante car elle décide de l’attention
accordée au projet. Il est préférable de la rédiger sur un ton dyna-
mique et enthousiaste, plutôt que de rester dans un style purement
factuel, le principal étant de s’assurer l’engagement du lecteur et de
l’inciter à continuer sa lecture.
Les questions clés auxquelles elle doit répondre sont :
• Quels sont l’objet et les objectifs du projet ?
• Quels sont les caractéristiques uniques du projet/site Web/ser-
vice proposé ?
• Quelle est la stratégie commerciale et le marché cible ?
• Quels sont les besoins financiers et les principales prévisions
financières ? (Cette question ne concerne ni les intranets ni les
portails d’entreprise.)
• Pourquoi est-on persuadé de la réussite du projet ?

Bonne pratique : prévoir plusieurs synthèses


Il est souvent utile de prévoir plusieurs résumés correspondant aux besoins des différents départe-
ments de l’entreprise (angles produit, marketing et financiers par exemple).

La synthèse est créée au début de la rédaction du business plan puis


retravaillée lorsque ce dernier est terminé. L’information présente
dans le corps du document sert alors d’appui à l’argumentation.

La demande, le marché
Les investisseurs veulent avoir la certitude, d’une part que le chef de
projet a parfaitement analysé et compris la problématique, et,
d’autre part que le projet répond aux attentes de la cible.
Les questions clés auxquelles cette partie doit apporter une réponse
sont les suivantes.
• En ce qui concerne l’aperçu du marché :
– Quels sont les composants du marché ?

148
Chapitre 6 – Le business plan

– Quelle est la structure de la clientèle ? Qu’achète-t-elle et pour-


quoi ? Quels ont les paramètres importants (qualité, prix,
nouveautés…) ?
– Quels sont les facteurs de réussite sur le marché ?
– Existe-t-il des créneaux libres pour lesquels les besoins sont ou
ne sont pas couverts ?
• En ce qui concerne la situation actuelle :
– Quelles sont les prestations que l’entreprise vend aujourd’hui
et sur quels marchés ?
– Quels sont les parts de marché, le chiffre d’affaires, le bénéfice ?
– Quelles sont les réactions du marché aux prestations actuelles
(points positifs, négatifs, demande des clients) ?
• En ce qui concerne l’évaluation du marché :
– Comment l’entreprise évalue-t-elle le marché ?
– Quel est le taux de croissance du marché ou quel est le montant
qui représentera le marché dans les trois ou cinq prochaines
années ?
– Quelles sont les tendances du marché ? Comment l’entreprise
réagit-elle ou envisage-t-elle de réagir à ses tendances ?
– Dans quelle mesure le projet Web permet-il d’apporter
quelque chose de nouveau ou de supérieur sur le marché ?
– Quels sont les obstacles à surmonter pour permettre au projet
Web de se réaliser ?
Cette partie est évidemment très importante lorsqu’il s’agit de
sites Web marchands, et elle l’est aussi pour les autres types de
sites, bien qu’elle soit alors souvent négligée. En effet, même si
l’objectif du site n’est pas d’acquérir des clients mais seulement
de promouvoir ou de maintenir une relation client, une solide
étude de la demande permet d’expliquer et de justifier auprès
des différentes directions les moyens mis en œuvre pour le
projet. En fait, dans le cas de sites de marques ou de portails
d’entreprise, une description claire et détaillée du marché cible
et des demandes des utilisateurs permet dans la plupart des cas
de rassurer les preneurs de décisions, et de faciliter leur lecture
de la stratégie du projet.

149
Partie II – La conduite des projets Web

La vision, la stratégie et les objectifs :


raisons d’être du projet
Cette partie est nécessaire pour justifier l’idée du projet Web dans le
contexte de l’entreprise. C’est une présentation claire de la situation
de départ, accompagnée des informations nécessaires à la compré-
hension de la logique et de l’évolution du projet. Les questions clés
auxquelles cette partie doit apporter une réponse sont la définition
de l’offre, l’analyse de la concurrence et le positionnement.
La définition de l’offre doit expliquer en quoi il existe une demande
et un besoin qui justifient l’existence du projet Web. Elle s’appuie
sur une analyse des besoins et des intérêts des consommateurs pour
justifier les prestations commerciales ou autres proposées par le
projet.
Il est indispensable de présenter, en utilisant un langage simple, les
nouvelles technologies utilisées et de joindre en annexe toutes les
informations techniques jugées nécessaires.
L’analyse de la concurrence doit faire ressortir les concurrents les
plus dangereux actuellement, les concurrents potentiellement les
plus dangereux à l’avenir (issus de la même branche d’activité et
issus d’autres branches d’activité), des informations sur les entre-
prises et produits de la concurrence ainsi que les actions envisagées
pour assurer la position du projet sur le marché (actions défensives
ou agressives).
Le positionnement sur le marché doit permettre au lecteur de
comprendre comment le projet Web va atteindre ses objectifs. Cette
partie répond à quatre questions fondamentales :
• Quelles sont les cibles (ou marchés) du projet Web ?
• Quels sont les instruments utilisés pour atteindre les clients ?
• Quelle est la politique commerciale de la prestation ?
• Quels sont les objectifs de ventes dans le cas d’un projet de site
marchand ?

Les éléments financiers


La partie financière du business plan devra être très détaillée si le
dossier est destiné à des financiers. Elle pourra être plus sommaire
s’il s’agit de rechercher ou de convaincre des partenaires commer-
ciaux, la direction commerciale de l’entreprise ou bien si le projet
Web ne nécessite pas d’investissements conséquents (refonte du
contenu d’un site institutionnel par exemple).

150
Chapitre 6 – Le business plan

En général, les destinataires du business plan ne s’attendent pas à ce


que le document contienne un concept de financement parfaite-
ment élaboré. Nul besoin de se transformer en financier chevronné :
il suffit que le business plan contienne un concept global et que les
résultats de gestion financière soient justifiés et logiques. À partir de
là, l’équipe financière de l’entreprise prendra le relais.
Dans le cas de la création d’une nouvelle structure ou société, l’établis-
sement des documents financiers nécessite une bonne connaissance
de la comptabilité, du droit social et fiscal. Il est alors nécessaire de
s’adjoindre les conseils d’un spécialiste, soit en la personne d’un
membre de l’équipe financière de l’entreprise, soit, dans le cas d’une
création d’entreprise, d’un cabinet de conseil spécialisé.

L’analyse des risques


Il est indispensable de connaître les risques associés au projet et de
les décrire objectivement dans le business plan : tôt ou tard, les diri-
geants de l’entreprise ou les financiers aborderont le sujet, et être
préparé permettra de gagner plus facilement leur confiance.
Les risques seront fonction du projet et de sa nature, mais en général
cette partie devra analyser tant les risques internes au projet
(conduite et mise en place du projet, marketing, équipe…) que les
risques externes (changements économiques, juridiques, etc.).
Le tableau 6-1 permettra au chef de projet de revoir certains des
risques associés à chaque type de projet Web.

Tableau 6-1
Des risques différents selon la nature du projet Web

TYPE DE PROJET OBJECTIFS EXEMPLES DE RISQUES

Site marchand – vendre – réaction de la compétition ou apparition d’un concurrent


– compléter le réseau sérieux
de distribution – guerre des prix
– fournir un support… – conflit avec les canaux de ventes traditionnels
– délais de la mise en service du site
– importants problèmes techniques et solutions de secours
mises en place
– problème avec les fournisseurs
– gestion des retours et des plaintes clients suite a un problème
de produit ou de services
– faible fréquentation
– chute d’une source principale de revenue (ex : publicité)
– impossibilité de livrer les clients trop nombreux
– fraude…

151
Partie II – La conduite des projets Web

TYPE DE PROJET OBJECTIFS EXEMPLES DE RISQUES

Marque – exister – faible fréquentation du site


– entretenir la relation – faible « brand awereness »
– constituer un fichier – problèmes légaux liés à la constitution d’un fichier
– rajeunir la cible… client…
Portail – informer – sécurité
d’entreprise / – communiquer – divulgation d’informations confidentielles,
intranet – réaliser des économies – problèmes de mise à jour
– augmenter la compétiti- – faible taux d’adoption au sein de l’entreprise…
vité
– augmenter la mobilité…
Institutionnel – informer – sécurité
– communiquer – piratage…
– gérer la crise…
Communau- – échanger – sécurité
taire – constituer un fichier – pillage du contenu…
– créer du contenu…

L’organisation
Cette partie précise quelle organisation (structure, équipe, moyens
techniques…) sera nécessaire pour conduire le projet puis pour
l’animer en vitesse de croisière.

La partie financière

La construction des éléments financiers est une démarche dyna-


mique qui permet de savoir quel sera l’impact du projet sur les
objectifs financiers de l’entreprise et de vérifier la viabilité du projet
en prévoyant les éléments financiers sur une période pertinente et
suffisamment lisible, en général trois ans, bien que pour les plus gros
projets il ne soit pas rare que les prévisions soient réalisées sur cinq
ou sept ans.
Cette étape conduira soit à valider le projet en interne et à lui
permettre d’obtenir un budget dédié au sein de l’entreprise, soit à
permettre au chef de projet de le remanier ou de le redimensionner
pour adapter les investissements aux revenus potentiels. Dans un cas
extrême, cette étape pourra mettre en avant le fait que le projet n’est
pas bénéficiaire et ne réalisera pas d’argent pour l’entreprise.
Il est recommandé de commencer par établir une gestion financière
à long terme, gestion qui se compose d’un bilan prévisionnel, d’un

152
Chapitre 6 – Le business plan

compte de résultat prévisionnel et d’un tableau de financement.


Dans un second temps, on pourra si nécessaire compléter l’analyse
par une gestion financière pour la première année d’existence du
projet. Cette dernière nécessite une budgétisation des liquidités du
projet et des analyses plus détaillées, et consiste dans les faits à établir
un budget annuel.

Préparer et collecter l’information nécessaire


Les différents choix opérés relatifs à la nature du projet, à la façon
de réaliser des revenus, et au mode de gestion du futur site Web vont
nécessiter le recours à certains moyens techniques et humains qu’il
convient d’évaluer précisément. La méthode la plus simple pour
collecter toutes les informations nécessaires à l’établissement des
documents financiers est de passer en revue les différentes phases du
projet et les fonctions escomptées du site Web et de répondre aux
questions suivantes : Comment ? Avec qui ? Avec quoi ?
La liste suivante peut servir de base pour collecter les informations clés.
• Ventes (sites commerciaux uniquement) :
– Quelles quantités de produits et/ou services prévoit-on de
vendre ?
– À quel prix ?
– Quelle est la répartition des ventes par produits ou services ?
– Quels sont les acteurs de développement compte tenu des
quantités et des prix ?
• Quel est le coût des produits et/ou services vendus ?
– Quel est le coût d’achat ou de production des services ou
biens ?
– Quelles sont les marges commerciales (rémunération d’inter-
médiaires) ?
– Quels sont les coûts opérationnels ?
– Quels sont les frais d’édition ?
– Quel est le coût d’achat ou de production des contenus
(images, textes, information, documents à télécharger…) ?
– Quel est le coût de mise en place des contenus (édition, mise
en page, mise au bon format, etc.) ?
• Animation du site :
– Quels sont les coûts marketing/promotion ?
– Quel est le coût de la campagne de publicité (Internet, presse,
radio, affichage…) ?

153
Partie II – La conduite des projets Web

– Quel est le coût de l’évangélisation ?


– Quel est le coût de la participation à des conférences ?
• Personnel :
– Le projet nécessite combien de personnes ?
– Quels sont les coûts de recrutement ?
– Combien coûtent les consultants ?
• IT :
– frais de construction du site ;
– frais de stockage des informations (site en lui-même, base de
données clients, catalogue marchandises…) ;
– connexion à Internet ;
– frais de constitution de la nouvelle structure : honoraires de
consultants extérieurs, avocats, frais d’enregistrement,
d’immatriculation, etc. ;
– autres charges administratives ;
– achat de noms de domaine ;
– dépôts de noms de domaine.
• Immobilisations incorporelles : licence, marque, fonds de com-
merce, loyers d’avance, redevance franchise, etc.
• Immobilisation corporelles : terrain, murs, travaux, mobilier,
matériel de bureau, ordinateurs, installations, véhicules, etc.
• Autres :
– service client (après-vente, numéro gratuit d’appel, etc.) ;
– frais de facturation.
• Méthodes de financement envisagées, en entreprise, pas de
souci, mais pour une nouvelle structure ou entreprise, il faut
détailler :
– capitaux propres apportés (apports personnels du créateur,
apports des associés, primes et subventions sollicitées) ;
– emprunts à long terme et moyen terme ;
– crédit à court terme.
Il est important de parler de façon claire des estimations et de
mentionner des éléments objectifs pour justifier les montants et
chiffres utilisés. Ce peut être par exemple des études de marché, des
chiffres de cabinet de recherche, des évolutions de produits simi-
laires, etc.
Il est conseillé de toujours surévaluer les charges en fonction des
risques associés et de créer en outre une ligne de charges imprévues

154
Chapitre 6 – Le business plan

avec un montant fonction du montant total des dépenses prévues


(compter de 5 % à 10 %).
Il est préférable de mettre au point plusieurs scénarios pour le calcul
des revenus et des coûts des ventes. Il est conseillé d’avoir des scéna-
rios pessimistes (les ventes marchent mal, il y a des retards dans la
mise en place du projet, un concurrent inattendu apparaît sur le
marché), optimistes (tout se passe pour le mieux et les efforts
commerciaux, marketing et techniques se concrétisent de manière
très positive sur les ventes, les délais, le nombre de clients) et
normaux (la moyenne des scénarios précédents).
Les listes interminables de chiffres sont à éviter. Il ne sert à rien de
compliquer inutilement les calculs en étant précis au centime près,
ou de calculer mensuellement les cinq prochaines années de chiffre
d’affaires. L’utilisation de données strictement nécessaires et pleine-
ment justifiées démontre le sérieux du chef de projet et du projet.
Les montants doivent être considérés hors taxes : en effet, la TVA
relève d’un problème de trésorerie à court terme, qui est géré par le
département comptable.
Pour la recherche d’hypothèses et de chiffres clés sur le développe-
ment du marché, des utilisateurs ou clients, il faut exploiter Internet
au travers des sites d’associations de secteurs, des journaux spécia-
lisés, des bureaux d’études et d’analyse et des bureaux de développe-
ment économique notamment dans le cas de pays étrangers. Dans
tous les cas, il est recommandé de garder une copie de toute
recherche : elle pourrait être utile dans l’avenir, et rien ne garantit
que le site Web en question aura toujours cette donnée en ligne dans
le futur.
Les documents de base
Une fois collectées, les différentes informations et données chiffrées
doivent être organisées en une suite de documents financiers simples
qui pourront alors être intégrés au business plan. Ils permettent
d’organiser les réponses à six grandes questions comme le montre le
tableau suivant :

155
Partie II – La conduite des projets Web

Tableau 6-2
Réponses apportées par chaque document financier

QUESTION DOCUMENT FINANCIER

Comment le projet va-t-il affecter Business model


les revenus et les coûts de l’entreprise ?
Le projet est-il rentable à long terme ? Compte de résultats prévisionnels
Quels sont les capitaux nécessaires Plan de financement
pour lancer le projet ? Quels sont les
besoins financiers à long terme ?
Quelle est la situation financière actuelle Bilans prévisionnels
et à venir ?
Les recettes permettront-elles de faire Gestion prévisionnelle de trésorerie
face aux dépenses de la même période ?

 Seuil de rentabilité : Quel montant minimal de prestations de Seuil de rentabilité1


outil de prévision financière services, de ventes, faudra-t-il atteindre
qui permet de déterminer pour pouvoir au moins faire face à toutes
le niveau d’activité à partir les charges ?
duquel l’activité de l’entre-
prise devient rentable.
Le business model
Le plus important est de décrire la logique économique du projet. Il
s’agit de démontrer, de façon simple, comment le projet peut (et va)
générer des bénéfices. Il est pour cela nécessaire de détailler les
sources de revenus et de coûts. L’idéal est de pouvoir résumer le tout
dans un schéma simple qui mette en avant les principaux flux
d’argent entre les différents acteurs.
Le compte de résultat prévisionnel2
 Compte de résultat
prévisionnel : outil de L’objectif du compte de résultat est de démontrer la rentabilité du
prévision financière qui projet et son impact sur les comptes de l’entreprise. Il faut pour cela
permet d’évaluer le résultat comparer les futures charges et les futures recettes afin de calculer le
comptable de l’activité
d’une entreprise. Il présente résultat d’exploitation. Les financiers se serviront de ces chiffres
essentiellement les produits pour évaluer la valeur future du projet ou de l’entreprise.
et les profits ainsi que Le compte de résultat ne pourra être définitivement arrêté que
les charges et les pertes
de l’exercice.
lorsque la situation de trésorerie aura été calculée. En effet, il sera
peut-être nécessaire d’insérer le recours à d’éventuels crédits de
trésorerie ou emprunts. Ce n’est qu’à ce stade qu’il sera possible de
savoir si le projet est économiquement viable.

Bonne pratique : attention à l’exhaustivité des charges


Pour ne rien oublier des charges prévisibles, le mieux est d’utiliser un plan comptable qui servira
de liste type.

156
Chapitre 6 – Le business plan

Les données peuvent être organisées sous la forme d’une liste ou


d’un tableau similaire à celui de la figure suivante :

Figure 6-2
Exemple de compte de résultat prévisionnel

Compte de résultat prévisionnel (compte_resultats.xls)

Les bilans prévisionnels


Les bilans prévisionnels1 donnent un aperçu de la constitution du  Bilans prévisionnels :
capital et des capitaux propres de l’entreprise ou du projet, au outils de prévision finan-
cière qui permettent de
premier jour et dans le futur. montrer l’incidence de
Le but est d’évaluer, à l’actif, les biens que possèdent l’entreprise et conditions économiques
ou d’événements futurs
la façon dont, à l’avenir, ils pourront assurer l’autonomie financière
prévus sur la situation
de l’entreprise. Outre les dettes, il faut inclure au passif le montant financière de l’entreprise.
des capitaux propres. Tous les engagements éventuels (par exemple
garantie, caution) ainsi que les obligations découlant d’un leasing
doivent être mentionnés en annexe du bilan prévisionnel.

157
Partie II – La conduite des projets Web

Les données peuvent être organisées dans un tableau similaire à


l’exemple présenté figure suivante.

Figure 6-3
Exemple de bilans prévisionnels

Bilans prévisionnels (bilan_previsionnel.xls)

Le plan de financement
Bâti sur les fluctuations des investissements et du financement du
projet, le plan de financement reflète l’ensemble des flux financiers
réalisés au cours d’une année et permet de montrer les évolutions de
la trésorerie et du cash-flow disponible, ainsi que les besoins finan-
ciers à long terme. Le plan de financement permet d’exposer claire-
ment les conséquences financières des projets d’investissement et de
financement.
Il doit être établi pour la période initiale du projet, afin de calculer
les besoins de financement initiaux, puis pour les deux années
suivantes afin de montrer l’évolution des besoins.
Si l’activité relève purement de la prestation de services, la notion de
stocks devra être remplacée par une composante « travaux en
cours ». Pour cela, il convient d’estimer le coût d’une journée de
travail (toutes charges comprises) et d’évaluer la durée moyenne de
travail restant à réaliser pour chaque commande avant de pouvoir
présenter la facture au client.

158
Chapitre 6 – Le business plan

La figure 6-4 est une représentation possible d’un tableau de finan-


cement :

Figure 6-4
Exemple de plan de financement

Plan de financement (plan_financement.xls)

La gestion prévisionnelle de trésorerie


Après avoir déterminé les besoins financiers à long terme, il faut
établir les besoins financiers à court terme.
Il s’agit de présenter tous les décaissements et encaissements prévus
au cours de la première année. La gestion prévisionnelle de
trésorerie1 se déduit du compte de résultat prévisionnel et s’établit  Gestion prévisionnelle
sur une base mensuelle pour une période limitée (généralement la de trésorerie : outil de prévi-
sion financière dont le but
première année d’activité). est de déterminer à
Ce document sert à présenter les répercussions des différents objec- l’avance quel sera chaque
tifs de l’entreprise sur une seule année. Chaque entrée ou sortie de mois le besoin de trésorerie.

fond doit être portée dans la colonne du mois où elle doit normale-
ment se produire. Par exemple, un achat effectué en janvier mais
payable en avril doit être imputé dans la colonne des décaissements
d’avril. Cela permet de déterminer le solde de trésorerie du mois et
un solde de trésorerie cumulée d’un mois sur l’autre. Ainsi, il est
possible de savoir, par rapport aux prévisions d’activité, si tout ce
qu’il y aura à payer pourra l’être grâce aux disponibilités du
moment.

159
Partie II – La conduite des projets Web

Bonne pratique : attention à la TVA


Attention, dans ce document entrées et sorties de fonds doivent être TTC pour les opérations
assujetties à la TVA.

Si à un moment le document fait ressortir une impasse de trésorerie,


il faudra alors trouver une solution de financement avant le démar-
rage de l’activité. Ce pourra être, par exemple, un crédit bancaire ou
la mise à disposition, s’il s’agit d’une entreprise, d’une avance de
trésorerie.
Dans les cas d’un projet Web complexe, où la gestion de trésorerie
est un élément clé, il peut être utile d’établir le solde de trésorerie
trimestre par trimestre pour les deux années suivantes.

Figure 6-5
Exemple de gestion prévisionnelle de trésorerie

Gestion prévisionnelle de trésorerie (gestion_tresorerie.xls)


Le seuil de rentabilité
Le seuil de rentabilité représente le niveau d’activité qui permet,
grâce à la marge réalisée, d’avoir les moyens de payer toutes les autres
charges de l’exercice. Pour le calculer, voici les opérations à réaliser :
1. Répartir l’ensemble des charges de l’exercice en deux catégories :
d’une part, le montant de toutes les charges fixes, c’est-à-dire les
dépenses que l’on va obligatoirement effectuées, que l’on vende
ou pas (par exemple : loyer, salaires, etc.) ; d’autre part, le

160
Chapitre 6 – Le business plan

montant des charges variables, c’est-à-dire les dépenses qui


découlent automatiquement du niveau des ventes (coût d’achat
des marchandises par exemple, commissions versées à des sites de
référencement, etc.).
2. Calculer la marge sur coûts variables qui est égale au montant
prévisionnel des ventes diminué des charges variables entraînées
automatiquement par ces ventes.
3. Traduire cette marge en pourcentage du chiffre d’affaires en divi-
sant la marge sur coûts variables par le montant du chiffre
d’affaires et en multipliant le résultat par cent.
4. Diviser le montant des charges fixes par ce taux de marge pour
obtenir le seuil de rentabilité.
Pour être un bon indicateur, le seuil de rentabilité doit être converti
en un nombre concret comme le nombre de clients nécessaires, le
nombre d’articles ou de prestations à vendre en moyenne par mois,
etc.

Figure 6-6
Exemple de seuil de rentabilité

Seuil de rentabilité (seuil_rentabilite.xls)


Le seuil de rentabilité est une notion facile d’approche dans le cas
d’un site commercial, mais elle est un peu plus complexe à mettre
en évidence dans le cas de site intranet, communautaire, institu-
tionnel ou de marques. Dans ces derniers cas, le calcul de la marge
sur coût variable doit tenir compte des revenus indirects générés par
le site, ou des gains de productivité. Le tableau 6-3 donne des exem-
ples d’éléments à prendre en compte dans le cas des différents types
de sites.

161
Partie II – La conduite des projets Web

Tableau 6-3
Éléments à prendre en compte pour le calcul du seuil de rentabilité

TYPE DE PROJET « REVENUS » POUR LE CALCUL DU TAUX DE RENTABILITÉ

Site marchand Ventes


Site de marques Développement indirect des ventes
Économies de frais de publicité, de production de plaquettes, etc.
Économies générées pour l’acquisition ou la rétention de clients
(par rapport aux méthodes traditionnelles)
Économies générées pour la constitution du fichier client (et impact
indirect sur le revenu généré)
Portail Économies générées par l’automatisation des taches administratives
d’entreprise/ Gains de productivité générés par une circulation plus rapide de
intranet l’information Revenus supplémentaires générés par une mobilité
accrue des employés
Site Économie de frais de publicité, de production de plaquettes, etc.
institutionnel Gains indirect générés par une circulation plus rapide de l’information
vers les partenaires extérieurs de l’entreprise
Site Économies générées pour la constitution du fichier client (et impact
communautaire indirect sur le revenu généré)
Revenus générés indirectement par la création de contenu (revente,
utilisation pour d’autres sites…)

 Valeurs de la marque : Il est en général difficile d’estimer la rentabilité de certains sites, car
croyances constitutives de
les bénéfices sont difficilement mesurables et quantifiables : qualité
la marque, par exemple
simplicité pour Apple, du rapport client, amélioration de la valeur de la marque1, etc. Le
imagination et pragmatisme chef de projet doit savoir et faire savoir qu’il est bon d’estimer la
pour le Crédit Agricole… rentabilité et de donner une idée des retours sur investissement,
mais qu’il faut être conscient que cette pratique a ces limites et qu’il
ne faut pas tomber dans un besoin de sécurisation extrême. Le busi-
ness plan doit mettre en avant lorsque c’est nécessaire les avantages
non ou difficilement quantifiables du projet Web.

162
Chapitre 6 – Le business plan

Pour aller plus loin

Ouvrages
Georges Kalousis et Catherine Leger-Jarniou
Construire son business plan
Dunod – 2006 – ISBN : 978-2100488728
Michel Sion et David Brault
Réussir son business plan : Méthode, outils et astuces
Dunod – 2006 – ISBN : 978-2100500970
Jean-Baptiste Tournier
Construire un business plan pour la première fois
Éditions Eyrolles – 2007 – ISBN : 978-221254018
Jean-Christophe Pic, Véronique Richard et Annick Charron
À chaque enjeu, son business plan
Vuibert – 2007 – ISBN : 978-2711791972
Collectif d’auteurs
Business Plan – Concevoir un business plan efficace
Village Mondial – 2007 – ISBN : 978-2744062940

Sites
Création LR - Des dizaines de modèles téléchargeables gratuitement
http://www.creation-lr.com/modules.php?name=Downloads&d_op
=MostPopular
Bizplanit.com - Le business plan pas à pas
http://www.bizplanit.com/vplan/execsum.html

163
Chapitre 7

La faisabilité

Figure 7-1
Les différentes étapes de la faisabilité

La phase de faisabilité est la première étape vers la réalisation du projet. Son


objectif est de valider la faisabilité fonctionnelle, technique et organisation-
nelle des propositions faites lors des phases précédentes. C’est aussi à cette
occasion que sont évalués avec précision le budget, la charge et le planning.
À son issue, le projet peut soit s’arrêter, soit continuer.

165
Partie II – La conduite des projets Web

Préciser le besoin

Pour préciser le besoin, le plus efficace est de faire appel aux futurs
utilisateurs, ce qui demande beaucoup d’expérience et une bonne
méthodologie. L’enjeu est, en effet, de rester réaliste sans se brider car
les utilisateurs ont souvent tendance à inventer des besoins ou, au
contraire, à minorer certaines demandes parce qu’elles leur semblent
irréalistes ou tellement évidentes qu’il n’est pas nécessaire d’en parler !

Bonne pratique : adapter la méthode en fonction des utilisateurs


Selon les utilisateurs sollicités, il sera nécessaire d’adapter la méthode et les supports. S’ils sont
expérimentés et capables d’exprimer leurs besoins (c’est-à-dire s’ils connaissent le système actuel
et sont capables de réfléchir en termes de processus), de simples interviews et/ou des tables ron-
des suffisent. En revanche, avec des utilisateurs peu expérimentés, il sera parfois nécessaire de
travailler en situation, c’est-à-dire avec l’utilisateur devant son poste de travail puis, dans un
deuxième temps, de reformuler ses remarques. En synthétisant suffisamment d’interviews de ce
type, les vrais besoins émergeront. Cette dernière méthode demande beaucoup plus de temps et
d’énergie et implique un nombre plus important d’utilisateurs. Elle doit donc être accompagnée
d’une communication plus poussée.

Comme à chaque fois que les utilisateurs sont impliqués, il est


nécessaire de beaucoup communiquer avec eux, avant, pendant et
après, pour ne pas qu’ils soient déçus. En leur expliquant clairement
leur rôle dans les différentes étapes du projet et les contraintes, ils
comprennent plus facilement la démarche et sont moins étonnés de
ne pas retrouver dans le livrable la totalité de leurs demandes.
L’expression des besoins
L’expression des besoins est une méthode qui permet de lister, sous
une forme adaptée au projet Web, toutes les fonctionnalités d’une
application. Elle se décompose en quatre tâches : identifier les fonc-
tions de service, les décrire, les caractériser puis les hiérarchiser.
Expression des besoins (expression_besoins.rtf )
Identifier et décrire les fonctions de service
L’expression des besoins commence par une série d’interviews
d’utilisateurs ou de futurs utilisateurs. L’objectif est d’identifier les
besoins fonctionnels auxquels le site devra répondre. Avec la
méthode dite de « l’analyse fonctionnelle », chaque besoin est
traduit en une ou plusieurs fonctions de service. Celles-ci définis-
sent des fonctionnalités « basiques » qui, combinées, répondent au

166
Chapitre 7 – La faisabilité

besoin fonctionnel. La traduction d’un besoin en fonctions de


service consiste à imaginer puis à formaliser chaque donnée et
chaque action nécessaire pour produire le résultat souhaité. Par
exemple, il faut afficher une liste de livres, afficher la fiche détaillée
d’un livre, ajouter le livre au caddie et proposer un formulaire de
paiement pour permettre à l’internaute d’acheter un livre sur un
site. C’est une tâche fastidieuse la première fois car elle demande
une très grande précision. Cependant, les projets Web utilisent tous
une base commune de fonctions de service. Ainsi, dès le deuxième
projet, l’effort initial est amorti car seules les nouvelles fonctions de
service devront être décrites. Au final, le but est d’établir la liste
exhaustive de ces fonctions, sans en oublier mais aussi sans en
inventer.
Tout le projet repose sur la précision et la rigueur avec lesquelles les
fonctions de service sont décrites. Idéalement, chaque fonction
devra être exprimée exclusivement en termes de finalité et être
formulée par un verbe à l’infinitif suivi, si nécessaire, d’un ou
plusieurs compléments. En effet, ces dernières vont servir de base de
comparaison avec l’existant de l’entreprise mais elles vont également
servir à sélectionner des logiciels, quantifier le projet, rédiger le
cahier des charges, briefer les prestataires… Plus la description sera
imprécise et plus le projet sera risqué et nécessitera des efforts
d’encadrement. Le temps économisé lors de cette étape devra être
dépensé trois ou quatre fois ensuite pour gérer les zones floues.

Bonne pratique : exprimer le besoin en fonction de l’outil


Dans certains cas, tout ou partie de la solution technique est connue au moment de la rédaction
du besoin. C’est notamment le cas lorsqu’un CMS ou un outil d’e-commerce a été retenu en
amont du projet. Il faut alors impérativement exprimer le besoin en fonction de ce que fait
l’outil et de la manière dont il le fait. Dans le cas contraire, il faudra « tordre » l’outil pour
l’amener à faire ce qu’il fait… mais d’une manière différente. L’outil ne sera alors plus facile-
ment maintenable car il aura été profondément modifié pour coller à un besoin irréaliste…
Tous les avantages d’un outil packagé seront perdus, sans pour autant bénéficier de la sou-
plesse d’une solution sur mesure…

Quand le projet le permet, la réalisation d’une maquette qui servira


de base à une deuxième série d’interviews permet de trier efficacement
les besoins vitaux des besoins imaginaires ou irréalistes. Elle permet en
outre d’affiner très précisément certains besoins spécifiques. Dans le
cas d’un site Web, c’est un bon procédé pour fixer le front-office mais
aussi pour préciser le back-office et notamment les besoins en outils
de gestion du catalogue, de contenu, des commandes…

167
Partie II – La conduite des projets Web

Validation du livrable : chaque fonction répond-elle à un besoin réel ?


Pour valider la liste des fonctions de service, il faut s’assurer que celle-ci est exhaustive et que
chaque description correspond bien à un besoin réel.

Cette tâche peut être menée en interne par le chef de projet ou par
un prestataire. Ce dernier sera idéalement spécialisé en assistance à
maîtrise d’ouvrage. Cependant, sur des projets de moindre enver-
gure, il peut être intéressant de faire intervenir un chef de projet ou
un consultant issu d’une SSII ou d’une Web agency.
Caractériser et hiérarchiser les fonctions de service
La deuxième tâche consiste à caractériser chaque fonction de
service. Le but est de pouvoir choisir une solution technique sur la
base de critères quantitatifs et qualitatifs objectifs. Pour chaque
fonction, seront donc définis :
• Les critères d’appréciation : ce sont des éléments qui permettent
d’apprécier la manière dont une fonction est remplie. La bande
passante et le nombre de connexions simultanées peuvent, par
exemple, être les critères d’appréciation de la fonction streaming.
• Le niveau de chaque critère : il quantifie le critère et représente
ainsi la performance attendue du service à rendre. Le niveau
peut être formulé sous forme d’objectif à atteindre : 1 Mbit/s et
dix connexions simultanées par exemple.
• La flexibilité de chaque niveau : elle fixe les limites de variations
tolérables pour chaque critère. On pourrait imaginer, pour notre
exemple, +/– 100 Ko et environ une connexion.
Une fois les fonctions caractérisées, il est nécessaire de les hiérarchiser
de manière à pouvoir indiquer à la future équipe de réalisation les
services prioritaires sur lesquels elle devra concentrer ses efforts. La
technique la plus simple consiste à comparer toutes les fonctions puis
à leur donner un rang en rapport avec leur importance.

Validation du livrable : précision et réalisme


Pour valider la caractérisation des fonctions de service, il est nécessaire de toujours garder à l’esprit
l’objectif principal du projet, la hiérarchisation et les contraintes budgétaires. Cela permet de rester
réaliste et de ne pas accumuler des caractéristiques qui finiraient, prises dans leur ensemble, par
devenir irréalistes.

Cette tâche peut être menée en interne par le chef de projet ou par
un prestataire, ou encore, dans l’idéal, par le prestataire qui a réalisé
l’identification et la description des fonctions de service.

168
Chapitre 7 – La faisabilité

L’étude de l’existant
La charge de travail de cette étape est fréquemment sous-évaluée
dans les projets Web, souvent à cause d’un excès d’optimisme.
L’erreur classique est de penser « qu’étudier l’existant, c’est facile : il
suffit de compiler les documents internes ». Malheureusement, ces
documents ne sont presque jamais à jour et ne couvrent, par consé-
quent, qu’une partie ancienne de l’existant... quand ils existent !
Comme pour l’expression des besoins, les détails font la différence.
Une version de logiciel peut par exemple tout changer. Imaginez
que la version de la base de données que tous les acteurs ont en tête
soit ouverte aux technologies Web mais que, malheureusement, la
version réellement détenue par l’entreprise soit… la précédente (et
qu’elle, au contraire, soit fermée aux technologies Web) ou que les
postes de travail ne permettent pas de mettre en œuvre le logiciel.
Ce sont tous les choix techniques qui devront être revus ! L’étude de
l’existant nécessite des efforts particuliers de communication, car, au
même titre qu’un audit, elle peut être perçue comme une remise en
cause du travail réalisé par l’équipe en place. Il est donc essentiel de
communiquer en amont du projet puis régulièrement au fur et à
mesure de l’avancement.
Étude de l’existant (etude_existant.rtf )
Étudier les aspects fonctionnels
Cette tâche consiste à étudier, dans les limites du périmètre de
l’étude, les différents systèmes existants ou en cours de création afin
de réaliser un catalogue complet des fonctions de service existantes
ou à venir.
Une méthode efficace revient, dans un premier temps, à discuter
avec un échantillon représentatif des futurs utilisateurs. Cela permet
de lister rapidement les principales applications et de formaliser une
vision globale de l’environnement fonctionnel. Dans un deuxième
temps, une analyse systématique doublée d’un entretien avec
chaque responsable hiérarchique concerné visera l’exhaustivité. Elle
permettra en outre de pondérer le poids de chaque application en
fonction de son utilisation avérée.

Bonne pratique : les formations font gagner du temps


Parfois, une documentation fonctionnelle à jour existe auprès du service ou de la personne respon-
sable de la formation ou du support aux utilisateurs. C’est un bon moyen de gagner du temps dans
l’analyse fonctionnelle de l’existant.

169
Partie II – La conduite des projets Web

Le tableau ci-après propose une check-list basique pour décrire


sommairement une application Web.

Tableau 7-1
Check-list permettant de décrire une application

THÈME ÉLÉMENTS À RENSEIGNER


Informations générales – nom de l’application
– surnom de l’application
– nom et prénom du responsable
– coordonnées du responsable
Informations fonctionnelles – descriptif fonctionnel
– URL volumétrie (taille mémoire, nombre d’items, etc.)
– liens avec d’autres applications Web
Informations techniques – technologie
– système d’exploitation
– serveur http
– serveur d’applications
– base de données
– type d’accès (ODBC, JDBC, etc.)
– liens avec le système d’information

Validation du livrable : attention à l’exhaustivité


Avant de valider cette partie, il est important de s’assurer qu’elle est complète et surtout que les
futurs projets ont bien été pris en compte.

Cette tâche peut être menée en interne par le chef de projet ou par
un prestataire. Ce dernier est idéalement spécialisé en assistance à
maîtrise d’ouvrage. Cependant, sur des projets de moindre enver-
gure, il peut être intéressant de faire intervenir un chef de projet ou
un consultant issu d’une SSII ou d’une Web agency.
Étudier les aspects organisationnels
L’étude des aspects organisationnels s’intéresse essentiellement aux
moyens humains nécessaires au bon fonctionnement des projets existants
et planifiés. Le but est de décrire et de quantifier les différents intervenants
pour en tenir compte lors de l’étape de recommandation des solutions.
À noter : seule la réalité a de la valeur
Il existe souvent un décalage significatif entre les déclarations obtenues en interview et la réalité.
En effet, dans beaucoup d’organisations, les contributeurs qui sont censés agir sur un système
délèguent cette tâche à un subordonné. C’est l’action du subordonné qui nous intéresse et qui doit
être comptabilisée et formalisée dans le rapport. Dans le même ordre d’idées, il faut toujours faire
très attention aux déclarations chiffrées : selon les cas, les interviewés ont tendance à surestimer
ou au contraire à sous-estimer leur intervention. Recouper les déclarations et les valider par des
extrapolations permet de ne pas aboutir à des aberrations.

170
Chapitre 7 – La faisabilité

Pour mener à bien cette étape, il est nécessaire de rencontrer tous les
acteurs identifiés des projets puis de mener l’enquête pour
comprendre qui fait quoi. Dans bien des cas, il sera important de les
interroger à deux reprises car après un premier tour d’horizon, de
nombreux points resteront immanquablement à élucider (rôle
précis de chacun, fréquences, versions de logiciel…).

Validation du livrable : attention au calcul de la future charge de travail


Avant de valider cette partie, il est important de vérifier que les processus décrits sont le reflet
de la réalité et non l’image de ce qu’ils devraient être. Il est aussi fondamental d’examiner les
calculs ayant abouti à l’estimation de la charge de travail liée au futur système et de s’assurer
qu’ils sont les plus réalistes possible.

L’étude des aspects organisationnels est idéalement confiée à un


prestataire spécialisé en assistance à maîtrise d’ouvrage ou, selon
l’ampleur du projet, à un cabinet de conseil en organisation. Cepen-
dant, sur des projets de moindre envergure, il peut être intéressant
de faire intervenir un consultant issu d’une SSII ou d’une Web
agency.
Étudier les aspects techniques
Cette tâche est fondamentale car de plus en plus de projets Web
s’inscrivent dans un existant technique complexe. Dès lors, il est
essentiel de tirer le meilleur parti possible des technologies déjà
implémentées par l’entreprise. La démarche classique consiste à
lister les différentes applications faisant partie du périmètre de
l’étude puis de les étudier une à une. Au final, une synthèse permet
de se représenter le portefeuille des technologies et leurs poids rela-
tifs. Sur cette base et avec des orientations claires de la direction
informatique, il sera possible de proposer des solutions techniques
cohérentes.

Bonne pratique : prévoir l’avenir


C’est l’enjeu de l’étude de l’environnement technique du projet. En effet, outre une description
précise et exhaustive, il est nécessaire de se projeter dans l’avenir pour imaginer ce que sera
l’environnement technique au moment du développement effectif du projet.

Le premier travail consiste à lister les éléments qui composent


l’infrastructure générale, les technologies Web et les postes clients. Il
est essentiel de bien indiquer les répartitions géographiques de tous
ces éléments.
Une check-list de principe pourrait être la suivante.

171
Partie II – La conduite des projets Web

Tableau 7-2
Check-list permettant de décrire l’existant technique

THÈME ÉLÉMENTS À RENSEIGNER


Réseau – matériel réseau (liaisons, routeurs1, etc.)
 Routeur : dispositif
– logiciels réseau (proxy2, cache3, pare-feu…)
matériel/logiciel qui permet – bande(s) passante(s)…
de diriger (router) les
paquets de données trans- Application – système(s) d’exploitation serveur(s) (type, version, distribution)
mis dans un réseau qui – serveur(s) HTTP
prend en charge le routage
– serveur(s) SMTP
– serveur(s) d’applications
(comme TCP/IP).
– langage(s) de programmation
– base(s) de données
 Proxy : logiciel qui gère
– base(s) documentaire(s)
le trafic Internet et stocke les – outil(s) de gestion de contenu
pages les plus consultées – outil(s) de gestion du catalogue
de manière à réduire la – outil(s) de suivi des commandes
consommation en bande – composant(s) logiciel(s) spécifique(s)…
passante et le temps de
Poste client – marque(s) des postes clients
téléchargement.
– type(s) d’ordinateurs (portables, desktop, handled…)
– processeur(s)
 Cache : tampon
– capacité disques durs
de mémoire. Ce système – mémoire vive
permet de stocker des – écran(s)
données dans une mémoire – système(s) d’exploitation
à temps d’accès plus rapide – suite(s) bureautique(s)
que celle d’où elles – client(s) de messagerie
proviennent. – client(s) Web…

Le deuxième travail consiste à analyser l’environnement technique de


manière quantitative et qualitative. Le but est d’aboutir à la description de
l’environnement futur du projet. La direction informatique joue ici tout
son rôle et doit, en conséquence, être pleinement associée à la démarche.
Enfin, une synthèse est souvent nécessaire pour présenter de manière
compréhensible l’environnement technique au comité stratégique,
puis aux éventuels prestataires. Elle comprend une série de graphiques
qui permettent de visualiser l’existant ainsi qu’une description des
technologies les plus courantes.
Validation du livrable : la précision avant tout
Cette partie doit être examinée avec la plus grande rigueur car chaque information peut avoir
des conséquences importantes. Les principaux éléments à vérifier sont :
– la proportion actuelle de chaque technologie ;
– la proportion future de chaque technologie ;
– le détail technique (volumétrie, versions de logiciels, langages…) de chaque élément faisant
l’objet d’une reprise ;
– dans une moindre mesure, le parc matériel.

172
Chapitre 7 – La faisabilité

Cette tâche est idéalement confiée à un prestataire spécialisé en


assistance à maîtrise d’ouvrage ou à un cabinet de conseil techno-
logique.

Le diagnostic
Le diagnostic consiste à analyser l’écart entre les besoins exprimés et
les solutions existantes. Sur cette base, il est possible de lister les
besoins réels que devra couvrir la future solution.
Diagnostic (diagnostic.rtf )
Analyser l’écart
Deux types d’écarts sont mesurés : l’écart général (la différence
générale entre le besoin et l’existant) et l’écart interne à chaque
besoin (la proportion de couverture d’un besoin partiellement
couvert). Ainsi, l’entreprise se fait une idée claire du chemin à
parcourir.
L’écart général donne une idée de la couverture fonctionnelle géné-
rale de l’existant par macrobesoins : publication, workflow, moteur
de recherche, catalogue, commande…
L’analyse de l’écart interne de chaque besoin vise à s’assurer d’une
part que chaque fonction liée à un besoin est couverte (totalement
ou partiellement) et, d’autre part, que le mode de couverture est
conforme aux attentes. Cette analyse permet d’affiner les éléments
de choix de la future solution.

Exemple d’écart interne


Besoin : répondre aux internautes qui laissent des messages sur le site et en garder une trace
Fonctions de service attendues
FS n° 1 : effectuer une recherche dans les e-mails stockés
FS n° 2 : sélectionner un e-mail
FS n° 3 : récupérer le texte de l’e-mail
FS n° 4 : ajouter du texte riche (mise en forme…)
FS n° 5 : envoyer le nouveau texte après validation du contributeur
FS n° 6 : archiver le nouveau texte en précisant le contributeur et la date d’envoi.
Fonctions de service existantes
FS n° 1 : effectuer une recherche dans les e-mails stockés
FS n° 2 : sélectionner un e-mail
FS n° 3 : récupérer le texte de l’e-mail
FS n° 4 : y ajouter du texte

173
Partie II – La conduite des projets Web

FS n° 5 : envoyer le nouveau texte après validation du contributeur


Écart FS n° 1, 2, 3 & 5 : OK
FS n° 4 : KO, impossibilité de traiter du texte riche, gravité de l’écart : non bloquant
L’analyse de l’écart est idéalement confiée à un prestataire spécialisé
en assistance à maîtrise d’ouvrage ou à un cabinet de conseil. Cepen-
dant, sur des projets de moindre envergure, il peut être intéressant
de faire intervenir un consultant issu d’une SSII ou d’une Web
agency.
Formaliser le diagnostic
Cette tâche consiste à formaliser l’écart analysé précédemment. Si
un rapport détaillé doit être établi avec le plus de précisions possible,
dans bien des cas, il sera utile de prévoir, en plus, une présentation
synthétique dont la forme sera choisie en fonction de l’auditoire. Le
comité de pilotage appréciera une forme graphique permettant de
comprendre la situation en quelques minutes. Ce document pourra
être réutilisé pour briefer d’éventuels prestataires.

Validation du livrable : classer les écarts en fonction de leur gravité


Avant de valider cette partie, il faut s’assurer qu’elle comprend :
– la liste des écarts ;
– une description précise de chaque écart ;
– un classement des écarts en fonction de leur gravité ;
– un classement des écarts en fonction de leur importance pour le projet (certaines fonctions
étant plus importantes que d’autres).

Cette tâche est, en général, réalisée en interne ou confiée au presta-


taire qui réalise l’assistance à maîtrise d’ouvrage.

La réunion de présentation et de validation


Cette réunion est importante car elle valide le travail d’expression
du besoin, de description de l’existant et, surtout, de diagnostic.
C’est à cette occasion que l’on va pouvoir se faire une première idée
de ce que pourra être le projet. Les éléments à valider lors de cette
réunion sont résumés dans le tableau suivant :

174
Chapitre 7 – La faisabilité

Tableau 7-3
Étude de faisabilité : éléments à valider

CHAPITRES ÉLÉMENTS À VÉRIFIER

Expression des besoins Liste des fonctions de service :


– exhaustive,
– chaque fonction correspond à un besoin réel.
Caractérisation des fonctions de service :
– précision de chaque critère,
– complétude des niveaux,
– réalisme de la flexibilité de chaque niveau.
Étude de l’existant Existant fonctionnel :
– exhaustif,
– prise en compte des futurs projets.
Existant organisationnel :
– les processus décrivent la réalité,
– les calculs d’estimation de charge sont réalistes,
Existant technique :
– les proportions actuelles et futures de chaque logiciel
sont présentes,
– pour chaque élément repris, le détail technique est
maximal.
Diagnostic – exhaustivité de la liste des écarts,
– précision de la description de chaque écart,
– présence de classement des écarts.

Choisir des solutions

Pour trouver la meilleure solution, le plus efficace est d’avoir recours


aux services d’un spécialiste qui saura en quelques jours identifier les
solutions les plus intéressantes.
Cependant, il faut faire très attention à ce que les besoins spécifiques
de l’entreprise soient bien pris en compte car ce sont eux qui sont
importants : un détail a priori anodin pour un intervenant extérieur
peut être extrêmement important dans l’utilisation quotidienne de
la future application (attention notamment aux interfaces utilisa-
teurs, une mauvaise conception peut doubler voire tripler la charge
de travail quotidienne).
Au final, le choix est souvent effectué entre progiciels métier et déve-
loppements sur mesure bâtis sur différentes technologies. L’utilisa-
tion de critères pondérés permettra de trancher facilement si la défi-
nition de ces critères a été rigoureuse et objective.

175
Partie II – La conduite des projets Web

Présenter les solutions


Cette tâche consiste à présenter de manière standard et détaillée les
différentes solutions ainsi que leur mise en œuvre et leur impact sur
l’existant. Ainsi, l’entreprise dispose d’une solide base de comparaison.
Une solution comprend habituellement les éléments suivants :
• la solution fonctionnelle ;
• la solution organisationnelle ;
• la solution technique ;
• le passage du système actuel au futur système (notamment
reprise de l’existant) ;
• le scénario de mise en œuvre ;
• le planning prévisionnel ;
• le budget.

Bonne pratique : ne pas oublier la reprise de l’existant


Beaucoup d’acteurs des projets Web ont travaillé sur des projets sans existant. Il s’agissait pres-
que toujours de créer la première version d’un site ou d’un intranet. Aussi, la notion de reprise de
l’existant est-elle peu ancrée dans les habitudes, à tel point qu’elle est parfois oubliée ! Or, cette
étape fondamentale peut représenter jusqu’à un tiers du budget. Elle n’est donc pas à négliger
lors de l’étude des solutions.

La solution technique précise l’architecture logicielle et ses princi-


paux composants : système d’exploitation, serveur d’applications,
serveur HTTP, base de données, connecteurs, moteur de recherche,
briques logicielles… Elle fait aussi le point sur l’architecture maté-
rielle et les principales mesures de sécurité envisagées.
La solution organisationnelle détaille l’organisation humaine et les
processus qui permettront de faire fonctionner le futur système. Pour
cela, elle s’appuie sur une analyse fine du volume d’informa-tion à traiter,
du degré d’automatisation de chaque processus, des compétences
internes disponibles et des éventuels recours à des prestataires externes.
Le passage du système actuel au futur système est un élément fonda-
mental. Cette partie décrit d’une part les solutions techniques et
organisationnelles envisagées pour la reprise de l’existant et, d’autre
part, les moyens à mettre en œuvre pour assurer la conduite du
changement lié à la solution.
Le scénario de mise en œuvre expose les grands choix méthodolo-
giques et leur mise en application : nombre et nature des presta-
taires, relations entre les prestataires, découpage du projet en

176
Chapitre 7 – La faisabilité

grandes phases, charge de travail de chaque étape… La définition


des livrables attendus à chaque étape et leurs modes de validation
doivent être précisés avec soin.
Le planning prévisionnel est déduit du scénario de mise en œuvre.
Il insiste sur l’enchaînement des différentes phases ainsi que sur les
étapes de validation et de tests.
Le budget comporte une évaluation précise des coûts de création et
de possession. Les coûts de création englobent les coûts du matériel,
des licences logicielles, des prestations externes, d’initialisation du
système, de la première année d’hébergement et des équipes internes
monopolisées par le projet. Les coûts de possession correspondent
aux licences, à l’hébergement, aux éventuelles prestations externes
et, bien sûr, aux coûts humains internes.

Validation du livrable : précision et réalisme des solutions


Avant de valider cette partie, il faut s’assurer que :
– les solutions techniques sont décrites concrètement (architecture logicielle, architecture maté-
rielle, versions de logiciels…). Cette partie doit suffire pour briefer un prestataire ;
– les solutions organisationnelles sont dimensionnées (évaluation de la charge par profil, organisa-
tion, etc.) et que tout a été mis en œuvre pour les optimiser en fonction des contraintes du projet ;
– les scénarios de mise en œuvre s’appuient sur des livrables et des méthodes couramment
employées ;
– les plannings prévisionnels sont réalistes (pas de parallélisation excessive des tâches, temps
devalidation corrects, etc.) ;
– les budgets sont suffisamment détaillés et leurs structures sont identiques ;
– la reprise de l’existant fait l’objet d’explications détaillées.

Cette tâche est idéalement confiée à un cabinet de conseil technolo-


gique.
Présentation des solutions (presentation_solutions.rtf ).

Étudier les solutions


L’étude des solutions consiste à définir des critères permettant
d’évaluer les différentes solutions puis à noter les solutions en fonc-
tion de ces critères. Le but est de disposer d’une base objective de
choix. Cette démarche idéale est, dans bien des cas, inutile car la
décision finale est prise en fonction de relations personnelles ou
d’éléments subjectifs. Il n’en reste pas moins qu’elle est la seule à
garantir un choix logique et cohérent.

177
Partie II – La conduite des projets Web

Figure 7-2
Exemple de grille de critères

En général, les critères s’appliquent à quatre domaines :


• la couverture fonctionnelle ;
• l’impact sur l’organisation ;
• le risque technologique ;
• la mise en œuvre (planning, budget, etc.).
La complétude de la couverture fonctionnelle doit être évaluée en
comparant chaque fonction de service souhaitée avec la capacité de
la solution à y répondre. Dans le cas de solutions packagées de type
progiciel, il est important de préciser le niveau de développement et/
ou d’adaptation nécessaire et l’évolutivité offerte.
L’impact sur l’organisation s’intéresse aux modifications organisation-
nelles nécessaires pour faire fonctionner la solution. Le niveau de modi-
fication des processus et de l’organisation (réorganisation, formation,
reclassement des personnels) sont les principaux critères évalués.

178
Chapitre 7 – La faisabilité

Bonne pratique : quinze questions à se poser pour évaluer l’impact organi-


sationnel d’un projet
Dans L’entreprise intranet, (éditions Eyrolles) Frédéric Alain, Marc Saliou et Frédéric Amoros pro-
posent une série de questions qui permettent de mesurer concrètement l’impact du projet sur
l’organisation :
– Le contenu et la fréquence de la remontée d’informations évoluent-ils ?
– Le processus et les outils de remontée évoluent-ils ?
– Les acteurs concernés par la remontée d’information vont-ils évoluer ?
– Les objectifs des équipes seront-ils modifiés ?
– Les structures de fonctionnement des équipes seront-elles modifiées ?
– Les critères de décision seront-ils altérés ?
– Les acteurs qui décident changeront-ils ?
– Le processus de décision va-t-il changer ?
– Les qualifications des postes seront-elles modifiées ?
– Comment vont évoluer les modes opératoires des tâches ?
– Comment vont évoluer la charge, le rythme et le niveau de complexité des postes sur les
processus affectés ?
– Comment vont évoluer les relations interéquipes (décloisonnement, maillage, etc.) ?
– La nature des tâches et responsabilités nécessite-t-elle un changement dans le style de mana-
gement vers d’avantage de flexibilité ou de rigueur ?
– Comment les acteurs intègrent-ils les imprévus ?
– Quels enjeux de pouvoir les changements affectent-ils ?

Le risque technologique est évalué en notant les capacités de la solu-


tion (respect des standards, fiabilité technique, cohérence tech-
nique…), l’accessibilité de la technologie (niveau de compétence
requis, nombre de compétences disponibles, maîtrise interne…) et
la pérennité de l’éditeur (part de marché, résultats financiers, etc.).
La mise en œuvre prend en compte des critères tels que le degré
d’autonomie du projet par rapport à son environnement, la rapidité
de réalisation et le risque général. Dans certains cas, le critère budget
est considéré comme fondamental. Il est alors ressorti et constitue
un cinquième domaine.

Bonne pratique : ne pas sous-estimer le critère « impact sur l’organisation »


Bien souvent, le critère « impact sur l’organisation » est sous-estimé. Dans le feu de l’action,
les différents acteurs sont optimistes et se disent qu’une fois l’application développée, il sera
facile de former les utilisateurs. C’est oublier que les habitudes sont tenaces et que la bonne
volonté des utilisateurs détermine presque toujours la réussite (ou l’échec) du projet.

179
Partie II – La conduite des projets Web

L’étude des solutions proprement dite consiste à noter chaque


critère le plus objectivement possible de manière à obtenir des résul-
tats équilibrés. Il est recommandé, quand le projet le permet, de
faire réaliser l’évaluation par plusieurs personnes

Validation du livrable : attention à l’argumentation


Avant de valider cette partie, il faut s’assurer que :
– l’impact sur l’organisation n’a pas été sous-estimé ;
– des explications objectives et complètes sont proposées pour chaque note.

Cette tâche est idéalement confiée à un prestataire spécialisé en assis-


tance à maîtrise d’ouvrage ou à un cabinet de conseil technologique.
Grille d’étude des solutions (etude_solutions.rtf )
Grille de comparaison des solutions
(grille_comparaison_solutions.xls)
Grille d’étude des aspects fonctionnels
(grille_faisabilite_fonctionnelle.xls)
Grille d’étude des aspects non fonctionnels
(budget, mis en œuvre…) (grille_faisabilite_technique.xls)

Choisir une solution


Le choix d’une solution s’effectue en fonction des notes obtenues
lors de l’étape précédente. Afin de tenir compte des contraintes
propres au projet, chaque critère est pondéré. En fonction des notes
finales, une solution doit se démarquer, ne serait-ce que sur des
critères secondaires.
En pratique, on s’aperçoit vite qu’il est indispensable de donner une
priorité claire au projet si cela n’a pas été fait en amont. Rentabilité,
délais de livraison de la solution, impact sur l’organisation… ce critère
doit permettre de départager les solutions. Pour des raisons de rigueur
et d’objectivité intellectuelles, il est bien sûr indispensable de le fixer
avant que l’évaluation des solutions ne soit commencée.
À noter : les coefficients décident de tout
Le choix d’une solution plutôt qu’une autre repose essentiellement
sur la pondération des différents critères de sélection. L’établisse-
ment de ces critères et leur pondération sont donc des tâches très
importantes qui demandent du recul et une grande objectivité.
Une fois la solution choisie, il est important d’argumenter chaque
critère dans une note de synthèse. Ce document sera très utile lors
de la présentation finale au comité stratégique.

180
Chapitre 7 – La faisabilité

Validation du livrable
Pour valider cette partie, il est nécessaire de :
– vérifier que le poids de chaque critère est en adéquation avec les objectifs et contraintes du
projet ;
– que la solution retenue est cohérente avec les contraintes de chaque acteur majeur du projet
(DG, DSI, DC…).

Cette étape est bien sûr réalisée en interne. Cependant, quand le


projet le permet, se faire accompagner par un prestataire spécialisé
en assistance à maîtrise d’ouvrage ou un cabinet de conseil techno-
logique peut être utile.

La réunion de présentation et de validation


La réunion de présentation a pour but d’entériner le choix de la
solution et de faire valider l’étude de faisabilité dans son ensemble.
Les principaux éléments à valider sont présentés dans le tableau 7-4.

Tableau 7-4
Choix d’une solution : éléments à valider

CHAPITRES ÉLÉMENTS À VÉRIFIER

PRÉSENTATION DES SOLUTIONS – Les solutions techniques sont décrites concrètement


(architecture logicielle, architecture matérielle, versions
de logiciels…). Cette partie doit suffire pour briefer un
prestataire.
– Les solutions organisationnelles sont dimensionnées
(évaluation de la charge, organisation…) et tout a été mis
en œuvre pour les optimiser en fonction des contraintes
du projet.
– Les scénarios de mise en œuvre s’appuient sur des
livrables et des méthodes couramment employées.
– Les plannings prévisionnels sont réalistes (pas de
parallélisation excessive des tâches, temps de validation
corrects, etc.).
– Les budgets sont suffisamment détaillés et leurs
structures sont identiques.
– La reprise de l’existant fait l’objet d’explications
détaillées.
ÉTUDE DES SOLUTIONS – L’impact sur l’organisation n’a pas été sous-estimé.
– Des explications objectives et complètes sont
proposées pour chaque note.
CHOIX D’UNE SOLUTION – Le poids de chaque critère est en adéquation avec les
objectifs et contraintes du projet.
– La solution retenue est cohérente avec les contraintes
de chaque acteur majeur du projet (DG, DSI, DC…).

181
Partie II – La conduite des projets Web

La présentation doit être synthétique bien qu’il soit nécessaire de


rappeler les principaux besoins, l’existant, le diagnostic et les alter-
natives. Une fois de plus, plus la présentation sera graphique et plus
il sera possible de maintenir l’attention du public.
Étude de faisabilité (etude_faisabilite.rtf )

Pour aller plus loin

Ouvrage
O’Shaughnessy Wilson
La faisabilité de projet
Éditions SMG – 2000 – ISBN : 978-2890940512
Sites
Sequoia - Description générale de Sequoia dont l’étude de faisabilité
http://www.sequoia.be/consult/method/francais.htm
Anere MSI - Plan d’étude de faisabilité
http://www.anere.com/Gestion_de_projet/
GP_PF_Etfaisabilite.htm

182
Chapitre 7 – La faisabilité

Avis d’experts

10 bonnes pratiques
pour réduire intelligemment
le coût des projets Web
La compression des budgets et la professionnalisation des équipes poussent de
nombreux responsables à réduire leur budget Web dans le but de faire mieux avec
moins de moyens. Revue des bonnes pratiques qui ont fait leurs preuves, comme
chez Nestlé Waters.
1. Investir sur la définition du besoin
Si je n’avais qu’un conseil à donner, ce serait d’investir du temps en amont de chaque
projet pour bien définir le besoin, conseille Olivier Cordonnier, directeur de la
communication interne et e-business chez Nestlé Waters. On peut alors réaliser
l’inventaire des ressources nécessaires, estimer une charge, en déduire une enveloppe
budgétaire et un planning. Autant de précieux repères qui serviront à sélectionner
le bon prestataire puis à le piloter efficacement.
2. Évaluer l’impact des choix techniques
Pour choisir une plate-forme de développement ou un progiciel, l’idéal est de se
faire accompagner par un spécialiste indépendant. Cela évite de se retrouver avec
une solution surdimensionnée ou vite obsolète mais génératrice de marge pour le
prestataire. C’est aussi l’occasion d’identifier objectivement les coûts cachés, pesant
souvent plus sur le budget que l’investissement initial.
3. Intégrer les compétences en interne
Intégrer une compétence technique et méthodologique me permet de réduire la charge
en challengeant le prestataire et en supprimant des postes coûteux comme les directeurs
de mission. In fine, c’est une garantie de pérennité puisque le savoir-faire est acquis puis
maîtrisé en interne, illustre Olivier Cordonnier.
4. Considérer les offres à bon marché
Il ne faut pas systématiquement mettre de côté les offres les moins chères, même
quand elles paraissent aberrantes comme le démontre Olivier Cordonnier : J’ai
réduit de 50 % le coût d’un important projet en choisissant le moins disant au terme
d’une étude approfondie de ses références. Et le temps m’a donné raison : implication,
respect du timing et qualité sont au rendez-vous.

183
Partie II – La conduite des projets Web

5. Redéfinir l’organisation du prestataire


Mesurer l’implication et l’apport réel du directeur artistique par rapport au directeur
de création est très difficile mais dans le budget la différence est énorme ! Je n’hésite plus
à redéfinir l’organisation du prestataire pour qu’elle soit en phase avec la réalité, cons-
tate Olivier Cordonnier. Résultat : des économies importantes et des projets plus
efficaces car gérés par des équipes plus impliquées.
6. Utiliser des contrats cadres
L’utilisation de grilles de tarifs lors de l’appel d’offres permet de réduire de plus de
10 % le budget du projet, la plupart des prestataires préférant faire un effort
important pour obtenir, en échange, un volume de travail plus important. Elles
vous permettront non seulement de comparer facilement les coûts de chaque profil avec
ceux du marché mais aussi de négocier efficacement un contrat cadre annuel, conseille
Olivier Cordonnier.
7. S’appuyer sur une méthodologie formalisée
En suivant toujours la même méthode je sais en permanence où en est chaque projet et
ce qui reste à faire. Cela me permet d’anticiper les problèmes et de les régler avant qu’ils
ne coûtent trop cher, estime Olivier Cordonnier.
8. Ne pas surévaluer certains postes
Les entreprises ont tendance à surpayer les prestations graphiques alors même qu’elles négligent
la conception éditoriale et la maintenance applicative, synthétise Olivier Bronner, directeur
de la société de services Caxton. La conception éditoriale peut être avantageusement
réalisée en interne, quitte à investir dans un soutien méthodologique, et la tierce main-
tenance doit être négociée lors de la création du site, le prestataire offrant alors de faibles coûts
journaliers dans l’optique de remporter la création du site, recommande-t-il.
9. Capitaliser sur un chef de projet
En capitalisant sur un chef de projet, l’entreprise peut réduire considérablement la
charge liée à la prise de connaissance de chaque nouveau dossier, sans parler des jours
de travail économisés grâce à une communication efficace avec son client, détaille
Olivier Bronner. Il est donc essentiel que le choix du prestataire tienne compte de
la disponibilité du chef de projet présenté lors de l’appel d’offres.
10. Rester objectif
La plupart des besoins peuvent être satisfaits avec une architecture LAMP (Linux,
Apache, MySQL, PHP) et un hébergement à bon marché. Car, si les applications
Web ont tendance à devenir de plus en plus critiques pour l’entreprise, les hébergeurs
« discount » se sont dans le même temps hissés aux rangs des meilleurs hébergeurs en
matière de qualité de service, explique Olivier Bronner.
Article paru sur http://www.indexel.net

184
Chapitre 8

L’appel d’offres

Figure 8-1
Les différentes étapes de l’appel d’offres

Du fait de la complexité des projets et de la relative instabilité des presta-


taires, l’appel d’offres est devenu une étape cruciale. Les choix opérés à
cette occasion déterminent la réussite ou l’échec du projet.
La rédaction d’un cahier des charges, véritable référentiel entre l’entreprise
et ses futurs partenaires, est une étape importante. Celui-ci ne s’improvise
plus et nécessite, pour être solide, une étude préalable.

Choisir les prestataires

Hier, les projets Web étaient menés avec une agence de communication ou
une SSII. Aujourd’hui, la complexité des projets et une plus grande matu-

185
Partie II – La conduite des projets Web

rité du marché poussent les différents acteurs à se spécialiser. Pour


faire face à ce morcellement croissant, l’entreprise joue de plus en
plus le rôle de chef d’orchestre en s’appuyant sur des spécialistes de
l’assistance à maîtrise d’ouvrage. Par ailleurs, sur un marché en cons-
tante mutation, le choix des prestataires est devenu difficile, voire
hasardeux, le savoir-faire n’allant plus forcément de pair avec la taille
ou la renommée de l’entreprise. Enfin, beaucoup de faillites ou de
regroupements aventureux ont laissé des marques que nombre
d’entreprises aimeraient voir s’effacer... Dans ces conditions, la
sélection d’un prestataire est devenue un facteur clé de succès qu’il
ne faut surtout pas négliger.
Les types de prestataires

Figure 8-2
Mapping des différents prestataires

186
Chapitre 8 – L’appel d’offres

Les pages suivantes présentent quelques-uns des prestataires d’un


projet Web. Cette présentation succincte n’est pas exhaustive et doit
être complétée au cas par cas (sécurité, logistique, CRM…). Des
sites comme ebusiness.info (http://ebusiness.org) ou le Journal du
Net (http://www.journaldunet.com) peuvent y aider.

Figure 8-3
http://ebusiness.org
Ce site recense plus de cinq mille prestataires, classés par ordre alphabétique,
domaine de compétence, etc.

Conseils en AMOA/AMOE
Les prestataires spécialisés en assistance à maîtrise d’ouvrage
(AMOA) ou en assistance à maîtrise d’œuvre (AMOE) accompa-
gnent leurs clients dans les phases amont puis tout au long de leur
projet. Ce sont souvent de grands cabinets de conseil comme Accen-
ture, le BCG, McKinsey ou des acteurs ayant intégré des cabinets de
conseil comme IBM ou Capgemini. On trouve aussi quelques
petites entités spécialisées comme Breek.
Ces prestataires interviennent essentiellement dans les phases
amont du projet : définition de la méthodologie du projet, stratégie,

187
Partie II – La conduite des projets Web

faisabilité, business plan, conception. Ils accompagnent ensuite


leurs clients à chaque étape de validation des réalisations.
Leurs principaux atouts sont une présence internationale, une
culture business, une bonne connaissance des métiers de leurs
clients, un savoir-faire méthodologique avéré et des capacités
d’accompagnement du changement reconnu.
La principale limite des conseils en AMOA/AMOE est le manque
de pratique qui les coupe souvent des réalités et des contraintes
terrain des projets. Attention donc aux « usines à gaz ».
Conseils en architecture
Les conseils en architecture sont des prestataires techniques très
spécialisés, capables de traduire les objectifs et les besoins fonction-
nels de leurs clients en architectures techniques opérationnelles.
Certaines SSII intègrent ces compétences. Cependant, la plupart
des prestataires sont de nouveaux entrants comme Octo technolo-
gies, Cosmosbay-Vectis…
Les conseils en architecture s’impliquent dans les phases amont
(faisabilité notamment), lors de la conception puis en fin de projet
lors de la recette.
Les principales forces de ces prestataires sont, d’une part leur grande
spécialisation qui leur permet d’intervenir sur les dossiers de leurs
clients avec souvent une double expertise fonctionnelle et tech-
nique, et d’autre part une véritable indépendance vis-à-vis des solu-
tions du marché, ce qui n’est pas forcément le cas des intégrateurs et
SSII ayant conclu des partenariats stratégiques avec des éditeurs. La
principale limite des conseils en architecture est la dimension ponc-
tuelle de leur intervention.
SSII
Les sociétés de service et d’ingénierie informatique (SSII) sont des
prestataires spécialisés dans la réalisation de logiciels sur mesure.
Bien qu’elles soient en général spécialisées dans une ou plusieurs
technologies et dans un ou plusieurs secteurs d’activité (banque,
télécom, logistique…), les plus grosses d’entre elles sont capables
d’intervenir sur toutes les technologies et tous les secteurs d’acti-
vité. Logica, Atos, Altran, Steria, SQLI… sont les plus connues
mais il existe aussi énormément de petites structures au niveau
local.
Les SSII interviennent soit « au forfait » soit sous forme de « régie ».
Dans le premier cas, elles peuvent participer à toutes les étapes d’un

188
Chapitre 8 – L’appel d’offres

projet, de la faisabilité au lancement, même si leur véritable savoir-


faire se situe surtout au niveau du développement des applications.
Le travail est réalisé dans les locaux du prestataire. L’engagement est
forfaitaire : la SSII s’engage sur la base d’un cahier des charges à
réaliser les développements en respectant une charge de travail et des
délais. En cas de dépassement, la SSII assume seule les surcoûts.
Dans le second cas, elle propose des « profils » techniques qui
travaillent directement dans les locaux et avec l’équipe de l’entre-
prise. L’engagement est alors un engagement de moyens : la SSII
doit assurer la disponibilité des profils proposés. En aucun cas elle
n’est tenue à un engagement de résultat.
Les principaux atouts des SSII sont, d’une part, leur connaissance
des systèmes d’informations de leurs clients et, d’autre part, leur
capacité à gérer de gros projets. Les principales limites des SSII sont
le manque de culture projet – ou à l’inverse des habitudes héritées
des grands projets informatiques, donc inadaptées au projet Web –
et le manque d’intégration des autres métiers : conception fonction-
nelle, ergonomie, design, marketing Web…
Agences interactives
La plupart des agences de publicité intègrent aujourd’hui un
département ou une filiale interactive dans le but de fournir à leurs
clients un service multi-support. Citons parmi les principaux
acteurs de ce secteur : Fullsix, Tequila-Rapido, Smile interactive,
X-Prime, Nurun…
Les agences interactives interviennent essentiellement sur le front-
office pour définir l’interface utilisateur et lors de la phase de lance-
ment pour créer et mettre en place les campagnes de marketing en
ligne. Certaines réalisent le projet de leur client de A à Z soit en inté-
grant des compétences techniques – ce qui est rare – soit en sous-
traitant cette partie à une SSII.
La principale force des agences de publicité est la connaissance des
valeurs des marques de leurs clients et une vision globale du dispo-
sitif de communication de la marque. Leurs principales limites sont
leurs faibles compétences techniques, une culture souvent en déca-
lage avec la réalité du Web (contraintes techniques, attentes des
utilisateurs…) et des budgets prohibitifs.
Intégrateurs
Les intégrateurs sont des prestataires spécialisés dans la définition et
la mise en œuvre de solutions e-business. Le recours à des progiciels

189
Partie II – La conduite des projets Web

plutôt qu’à des développements spécifiques les différencie des SSII.


Citons parmi les plus connus : Keyrus, Klee group, Micropole,
Sopra group, Smile…
Les intégrateurs interviennent souvent avec ou après un cabinet de
conseil de type Accenture pour mettre en œuvre les différents progi-
ciels puis assurer la conduite du changement et notamment les
formations.
La principale force des intégrateurs est leur très bonne connaissance
des secteurs d’activité sur lesquels ils interviennent. Leur principale
limite est le manque de souplesse des solutions proposées.
Hébergeurs
Avec le développement des besoins des entreprises et l’apparition de
nouvelles problématiques comme la migration de l’existant, les
hébergeurs deviennent de plus en plus souvent des acteurs à part
entière du projet. Leur métier est aujourd’hui essentiellement centré
sur les services complémentaires à la fourniture et à la gestion de
bande passante. Les hébergeurs les plus connus en France sont ,
Ornis, Colt France, Easynet, Linkbynet, Telecom Italia, Internet.fr,
Amen.fr, OVH, etc.
L’hébergeur intervient lors des phases amont des projets (faisabilité
notamment) et à partir de la phase de réalisation.

Combien de prestataires choisir ?


L’un des facteurs clés de succès d’un projet Web réside dans le choix
des prestataires qui seront amenés à collaborer ensemble. En effet,
les différences de culture et les rivalités commerciales entre les inter-
venants créent souvent des tensions inutiles et préjudiciables au
projet. Les sections suivantes font le point sur les trois alternatives
les plus courantes.
Le prestataire unique
Cette solution simple et cohérente économise les ressources
humaines de l’entreprise en reportant la charge de travail sur le pres-
tataire. Elle est donc adaptée aux sociétés qui ne disposent pas des
ressources nécessaires à la constitution d’une équipe projet solide.
Cependant, cette option comporte des risques forts. Premièrement,
en s’appuyant sur le prestataire pour assurer la maîtrise d’œuvre et la
coordination du projet, l’entreprise perd de son autonomie. Deuxiè-
mement, il est difficile de trouver le même niveau de compétence en
stratégie, organisation, conduite du changement, conception,

190
Chapitre 8 – L’appel d’offres

design, rédaction, développement… chez un prestataire unique.


Certaines phases seront donc moins bien traitées que d’autres. Troi-
sièmement, en cas de désaccord avec le prestataire, celui-ci reste
incontournable car il est le seul à maîtriser tous les aspects du projet.

Tableau 8-1
Prestataire unique, avantages et inconvénients

AVANTAGES INCONVÉNIENTS

– Globalement plus simple. – Prise de contrôle du projet par le presta-


– Moins d’investissements internes. taire au détriment du client.
– Seule possibilité dans le cas d’une – Personne ne sait tout faire.
équipe projet minimale. – La qualité des différents livrables (surtout
ceux entre les différentes phases) est
souvent inférieure à ce qu’elle devrait être.

Une mosaïque de spécialistes


Cette option consiste à s’entourer, pour chaque étape, du meilleur
spécialiste du moment : spécialiste du marketing Web, agence inter-
active pour le design, SSII pour les développements… Si cette solu-
tion est loin d’être inconcevable, elle est cependant réservée aux
équipes projet expérimentées possédant une méthodologie rigou-
reuse. Il est en effet extrêmement difficile de maintenir la cohérence
du projet avec autant d’intervenants, d’autant plus que chacun
d’entre eux aura tendance à redéfinir les enjeux et objectifs du
projet !
En outre, chaque intervenant étant plus ou moins directement
concurrent (l’agence de publicité développe des sites et la SSII fait
du design), des problèmes de communication apparaissent
fréquemment entre les acteurs. À tel point que certains projets se
retrouvent bloqués afin d’arbitrer un différend… entre prestataires !

Tableau 8-2
Mosaïque de prestataires, avantages et inconvénients

AVANTAGES INCONVÉNIENTS

– Qualité des livrables – Cher, complexe, risqué.


de chaque phase. – Inadéquation possible entre les livrables
de chaque prestataire.
– « Guerre » entre prestataires.

191
Partie II – La conduite des projets Web

Un duo sur mesure


Cette solution consiste à s’attacher les services de deux prestataires
complémentaires. En général, le projet est découpé en deux grandes
phases : soit de la stratégie à la faisabilité et de la conception au
lancement ; soit de la stratégie à la conception et de la réalisation au
lancement. En règle générale, les phases amont sont confiées à un
prestataire spécialisé en AMOA ou à un cabinet de conseil, alors que
les phases aval sont confiées à une Web agency ou à une SSII
(laquelle sous-traite le design). Cette solution est bien sûr à géomé-
trie variable et il existe autant de combinaisons possibles que de
situations.
Si cette option est retenue, il est important d’organiser une première
réunion de travail pour délimiter les rôles de chacun et permettre
aux deux intervenants de définir ensemble les livrables (forme,
contenu, échéance, degré de validation…) qu’ils attendent l’un de
l’autre.
Le principal avantage de cette solution est que les prestataires ont
l’habitude de travailler de cette manière. L’entreprise peut, en plus,
garder une bonne maîtrise du projet.

Tableau 8-3
Duo, avantages et inconvénients

AVANTAGES INCONVÉNIENTS
– Qualité des livrables. – Plus cher qu’un prestataire unique.
– Cohérence du projet. – Plus difficile à gérer qu’un prestataire
– Simplicité de gestion. unique.

Constituer la short-list
Une fois l’option d’organisation générale retenue, il s’agit de sélec-
tionner les prestataires en accord avec la stratégie de l’entreprise, le
but étant de prendre le moins de risques possible.
Lister les prestataires potentiels
Plusieurs approches sont possibles pour lister les prestataires poten-
tiels. La première consiste à exploiter les résultats du benchmark en
répertoriant les prestataires qui ont créé les sites concurrents. Dans
le cas d’un intranet, la même démarche peut être efficace en
s’appuyant sur l’étude de l’existant et en identifiant les prestataires
qui ont travaillé pour les autres directions de l’entreprise. La seconde

192
Chapitre 8 – L’appel d’offres

approche consiste à étudier les annuaires du type Journal du net et à


en ressortir une première liste.
Dans les grandes entreprises, il peut être intéressant de se rapprocher
de la direction informatique et de la direction des achats qui doivent
certainement tenir à jour une liste des prestataires référencés qu’ils
ont eu l’occasion de tester. Enfin, des sociétés spécialisées dans le
choix de prestataires proposent leurs services. C’est le cas par
exemple de http://www.prestataires.com.
Une fois la première liste établie, il faut réduire le nombre de pres-
tataires de cinq à dix de manière à pouvoir les évaluer sérieusement.
Lors de cette opération, il est important de garder à l’esprit que
certains d’entre eux ne répondront pas à l’appel d’offres. Une marge
est donc nécessaire. Un consultant spécialisé en assistance à maîtrise
d’ouvrage peut apporter son aide.
Évaluer les prestataires potentiels
Une bonne technique pour évaluer les prestataires consiste à mener
un entretien de présentation au cours duquel le prestataire présente
sa société et des cas clients comparables à la problématique de
l’entreprise mais aussi ses meilleurs exemples en matière de stratégie,
de design, de développement…
À cette occasion, une grille de critères peut être renseignée de
manière à comparer les prestataires sur des bases identiques. Les
principaux critères à considérer sont liés à l’entreprise elle-même, à
son savoir-faire et à sa compréhension de la problématique de
l’entreprise :
• organisation/structure (date de création, implantation géogra-
phique, mode d’organisation…) ;
• ressources (nombre de collaborateurs, ventilation par pôle et
expertises, nombre de fonctionnels vs « terrain »…) ;
• finances (capital, endettement, CAF1, actionnaires…) ;  CAF : Capacité d’auto-
financement. Encaissements
• stratégie (quelle est la stratégie de l’entreprise ? a-t-elle toujours ou décaissements nets liés
été la même ? à quoi les revirements correspondent-ils ?…) ; aux activités d’exploitation
de l’entreprise qui font
• core business2 (quel est le métier de l’entreprise ? quelle est sa généralement l’objet d’une
spécialité ?…) ; présentation distincte dans
• références (références comparables et vérifiables, nombre de le tableau de financement.

clients, etc.) ;  Core business : cœur


• qualité de service (quels sont les engagements de service de de métier de l’entreprise.
l’entreprise ?…) ;

193
Partie II – La conduite des projets Web

• gestion de projet (l’entreprise met-elle en avant sa capacité à


gérer les projets ? les livrables sont-ils clairement définis ?…).
Cette étape peut être efficacement menée avec l’appui d’une société
spécialisée en assistance à maîtrise d’ouvrage ou d’un consultant
indépendant.
Grille d’évaluation des candidats (grille_candidats.xls)
Formaliser la short-list
 Short-list : liste réduite La constitution de la short-list1 doit s’appuyer sur les prestataires
de prestataires interrogés identifiés lors des étapes précédentes. Cependant, rien n’empêche
lors d’un appel d’offres.
d’ajouter un ou deux challengers que l’entreprise souhaite tester.
Enfin, dans certains cas, il est nécessaire, par correction, d’ajouter le
prestataire sortant.
Si un prestataire intervient à l’étape précédente, il peut être intéres-
sant d’inclure dans sa mission une assistance pour le choix de la
short-list.

Le cahier des charges

Le cahier des charges constitue le référentiel entre l’entreprise et les


prestataires tout au long du projet. Il engage contractuellement
l’entreprise, notamment en cas de désaccord grave finissant devant
les tribunaux.
Le cahier des charges précise le travail à réaliser ainsi que la méthode
pour y parvenir. Dans le cas d’un projet faisant appel à plusieurs
prestataires, il joue le rôle de facilitateur en fixant un cadre
commun.
Le nombre de cahiers des charges et leur type dépendent de la nature
du projet à réaliser. Certains projets complexes peuvent en effet en
nécessiter plusieurs. Pour la conception et la réalisation d’un portail
d’entreprise, il faudra par exemple prévoir :
• un cahier des charges avec des lots distincts pour la stratégie, la
faisabilité et l’appel d’offres ;
• un cahier des charges avec des lots distincts et une tranche con-
ditionnelle pour la conception, la réalisation et la maintenance ;
• un cahier des charges pour le lancement ;
• un cahier des charges pour l’hébergement…

194
Chapitre 8 – L’appel d’offres

Enfin, il est inutile d’essayer de rédiger un cahier des charges solide


sans avoir réalisé une étude préalable… ou la rédaction du cahier des
charges reviendra à réaliser l’étude elle-même !

Choix de la procédure
Le type d’appel d’offres retenu par l’entreprise conditionne la rédac-
tion du cahier des charges. Aussi avant de rédiger ce livrable est-il
nécessaire de déterminer la procédure qui sera suivie.
Réunion de discussion avec la direction des achats
ou le service des marchés
Cette étape consiste à discuter avec le bureau des marchés dans le cas
d’un organisme public ou avec la direction des achats dans le cas
d’une entreprise privée.
Au cours de cette discussion, les différentes procédures utilisables
seront évoquées ainsi que leurs conséquences, notamment en termes
de planning et d’engagement contractuel. Au final, une procédure
devra être retenue.
Le code des marchés publics permet de résumer rapidement les
différentes possibilités : mise en concurrence simplifiée, appels
d’offres restreints ou ouverts, procédure négociée, appel d’offres sur
performances. Des combinaisons sont bien sûr possibles bien que
cela soit rarement nécessaire.
Tableau 8-4
Récapitulatif des types d’appels d’offres

TYPE DE PROCÉDURE CARACTÉRISTIQUES POUR QUEL TYPE DE PROJET ?

Mise en concurrence Annonce publique, tout postu- Projet de petite taille (enjeux,
simplifiée lant accepté, réponse unique, charge, délais réduits), sites
négociation avec prestataire institutionnels…
retenu.
Appel d’offres ouvert Annonce publique, seuls les Tout type de projet sauf ceux
postulants qui en font expres- à dominante créative.
sément la demande peuvent
participer, réponse en deux
parties, négociation avec pres-
tataire retenu.
Appel d’offres Nombre restreint de partici- Projets stratégiques, projets
restreint pants (minimal et maximal). bien cadrés, projets faisant
Réponse en deux parties. Envoi appel à des prestataires très
du cahier des charges seule- spécialisés, manque de temps
ment aux candidats ayant satis- pour l’appel d’offres…
fait à la partie administrative.

195
Partie II – La conduite des projets Web

TYPE DE PROCÉDURE CARACTÉRISTIQUES POUR QUEL TYPE DE PROJET ?

Procédure négociée Principe de la mise en concur- Tout type de projet récurrent.


rence simplifiée mais négocia-
tion avec au moins
trois candidats.
Appel d’offres Principe de l’appel d’offres Site de marques, charte
sur performances restreint mais avec possibilité graphique…
pour les participants d’expli-
quer et de défendre leur créa-
tion au cours d’une audition.
Dédommagement des partici-
pants non sélectionnés en
fonction de leur classement
dans le cas d’un concours.

La mise en concurrence simplifiée consiste à annoncer publique-


ment un appel d’offres (par voie de bulletin officiel des annonces de
marchés publics – BOAMP – dans le cas d’un marché public). Les
prétendants sont conviés à formuler leur réponse et à l’adresser à
l’entreprise. Après examen des offres, l’entreprise négocie avec le ou
les prestataires retenus jusqu’à signature du contrat. L’avantage de
cette procédure est sa simplicité. Elle est adaptée à de petits projets.
L’appel d’offres ouvert reprend la mise en concurrence simplifiée
mais les délais entre chaque étape sont plus longs et le cahier des
charges n’est adressé qu’aux prestataires qui en font la demande. Par
ailleurs, la réponse des prestataires se découpe en deux parties à
présenter dans des enveloppes séparées : une partie administrative et
une partie technique. Lors du dépouillement, la première partie de
chaque offre est étudiée. Celles qui ne satisfont pas aux critères de
l’entreprise sont éliminées. Les offres techniques restantes sont
étudiées et, parmi elles, une est retenue selon les critères fixés par
l’entreprise (l’offre économiquement la plus avantageuse dans le cas
d’un marché public). Aucune négociation n’est prévue. L’avantage
de ce système est qu’un grand nombre de participants peut postuler.
Il y a donc plus de chance d’obtenir des réponses intéressantes.
L’inconvénient est que la procédure de dépouillement est très
lourde.
Dans l’appel d’offres restreint, un nombre minimal et/ou maximal
de prestataires pouvant postuler est (sont) fixé(s). Après une
communication publique de l’appel d’offres, les prestataires sont
invités à adresser la partie administrative à l’entreprise. Celle-ci est
étudiée et seuls les prestataires ayant satisfait à cette première étape
reçoivent le cahier des charges. Les prestataires retenus formulent

196
Chapitre 8 – L’appel d’offres

leur offre et l’adressent à l’entreprise. Parmi ces dernières, une est


retenue selon les critères fixés par l’entreprise. Aucune négociation
n’est prévue. Cette procédure permet de limiter le travail de
dépouillement à ce qui est strictement nécessaire. En limitant la
communication du cahier des charges, elle permet en outre d’être
circonspect quant à son projet. L’inconvénient est que si le nombre
de prestataires fixé est trop réduit, il risque de ne pas y avoir d’offre
satisfaisante.
La procédure négociée reprend la mise en concurrence simplifiée
mais une négociation avec au moins trois candidats est prévue.
L’avantage de cette procédure est bien sûr la souplesse laissée par la
négociation.
Enfin, l’appel d’offres sur performances reprend la démarche de
l’appel d’offres restreint mais les prestataires sont invités à défendre
leur offre lors d’une audition. À l’issue de celle-ci, ils peuvent
préciser, modifier ou compléter leur offre. De même, l’entreprise
peut être amenée à modifier son cahier des charges qu’elle commu-
nique, le cas échéant, à tous les prestataires candidats. Des primes
sont souvent prévues pour dédommager les prestataires malheureux.
Elles sont alors fixées proportionnellement à leur classement. Cette
procédure est adaptée aux projets fortement créatifs où un dialogue
avec l’entreprise est nécessaire.
Le choix de la procédure peut être discuté avec une société spécia-
lisée en assistance à maîtrise d’ouvrage.

Rédaction du cahier des charges


La rédaction du cahier des charges est très importante car ce livrable
est la base de toutes les discussions avec les prestataires. Cette étape
doit être considérée comme un facteur clé du succès du projet et non
comme un « passage obligatoire ».
Le cahier des charges est en général composé de trois parties : la
présentation du projet, la description du futur site et les prestations
attendues.
La partie « Présentation du projet » commence par un point sur le
contexte. L’historique et l’objectif sont rappelés. Ensuite, l’organisa-
tion générale du projet est définie, notamment la composition et les
rôles du comité de pilotage, du comité de projet, de la MOA et de
la MOE. Enfin, les environnements fonctionnel et technique du
projet sont décrits succinctement. Cette dernière partie peut être
issue de l’étude de l’existant.

197
Partie II – La conduite des projets Web

La partie « Description du futur site » précise le périmètre du projet


en positionnant ce dernier dans son environnement et en le décri-
vant globalement. Puis les besoins fonctionnels et techniques sont
détaillés avec le plus de précisions possibles. Pour ces derniers,
l’architecture technique cible, les configurations matérielles et logi-
cielles, la sécurité et les modes de reprise de l’existant envisagés sont
précisés. Tous les éléments de ce chapitre sont présents dans l’étude
de faisabilité. Il suffit donc de les adapter au cahier des charges.
La partie « Prestations attendues » décrit en détail et sans ambiguïté
les prestations attendues, propose un cadre formel pour la réponse du
prestataire et fixe les exigences auxquelles la solution devra répondre.

Validation du livrable : priorité à la clarté


Avant de valider le cahier des charges, assurez-vous que :
– la description de l’application Web est suffisamment précise pour donner une idée juste du tra-
vail à réaliser ;
– la description des prestations attendues est très claire ;
– le cadre de la réponse est sans aucune ambiguïté.

La rédaction du cahier des charges peut être confiée à une société


spécialisée, à un consultant indépendant voire, dans certains cas
(petit projet, partenaire de confiance, etc.), à une SSII. Ces profes-
sionnels font souvent gagner du temps à l’équipe projet de l’entre-
prise car ils utilisent des modèles préexistants et savent sur quels
points insister.
Cahier des charges (cahier_charges.rtf )
Adaptation du plan d’assurance qualité
Cette étape consiste à adapter le plan d’assurance qualité (PAQ) de
l’entreprise de manière à ce qu’il soit applicable au projet Web. S’il
est issu d’appels d’offres informatiques, il sera nécessaire de considé-
rablement l’alléger.
À noter : le recours à un PAQ n’est pas toujours judicieux
L’utilisation d’un plan d’assurance qualité garantit un niveau de qualité globale minimal. Cepen-
dant, quand le projet Web est très créatif (site de marques par exemple) il peut être risqué de l’uti-
liser car les prestataires les plus créatifs sont aussi souvent les moins aptes à appliquer un PAQ.

La première partie présente le contexte, le projet, les objectifs à


atteindre et les grands choix méthodologiques.
La deuxième partie précise le référentiel c’est-à-dire les documents
applicables, les outils, les méthodes, les normes et standards à

198
Chapitre 8 – L’appel d’offres

respecter. On y ajoute parfois un glossaire des abréviations et des


sigles. Elle décrit également l’organisation de la MOA et de la MOE
ainsi que les structures de coordination et de suivi du projet. Le rôle
et les responsabilités de chacun sont bien sûr indiqués.
La troisième partie détaille les produits et prestations attendues.
La quatrième partie précise la démarche projet générale : cadrage,
conception, réalisation, recette, bilan, mode de gestion des événe-
ments (incidents, modifications, etc.), fonctionnement des pro-
cessus de support utilisés (audits, documentation, configuration des
différentes plates-formes, sauvegarde, archivage et sécurité).
Enfin, la cinquième partie explique les modalités du bilan de fin de
projet, de la garantie et des réclamations clients.

Validation du livrable : le PAQ doit être applicable


Avant de valider le plan d’assurance qualité, assurez-vous qu’il est applicable et que le recours à
cet outil poursuit un objectif réel et motivé.

La rédaction ou l’adaptation du plan d’assurance qualité est réalisée


en interne ou confiée au prestataire qui rédige le cahier des charges.

Briefer les candidats

Réaliser un brief peut paraître évident : il suffit d’expliquer au pres-


tataire ce que l’entreprise attend de lui. Pourtant, dans la pratique,
c’est souvent une étape mal gérée, entre surinformation et laco-
nisme.
Préparer le brief
La préparation du brief consiste essentiellement à déterminer ce que
l’entreprise attend du prestataire, dans quels délais et sur la base de
quelles informations. Une fois ces éléments fixés, il convient de créer
les supports du brief.
Les attentes de l’entreprise correspondent aux livrables que le pres-
tataire devra produire au cours de l’appel d’offres. Pour un projet de
site Internet institutionnel, il peut par exemple être demandé :
• une note précisant le concept ;
• une piste graphique ;
• une note précisant les options fonctionnelles retenues ;
• une note justifiant les choix technologiques ;

199
Partie II – La conduite des projets Web

• une note méthodologique précisant méthode, charge, équipe et


planning ;
• une proposition commerciale ;
• une note décrivant les références similaires.
Le format de chacun de ces livrables doit être précisé et, dans
certains cas, il sera intéressant de fournir un modèle. L’analyse des
offres en sera grandement facilitée. C’est notamment le cas pour
l’évaluation de la charge de travail, le planning et la proposition
financière. Les bordereaux de prix et les questionnaires aux fournis
seurs utilisés pour les marchés publics sont de bons outils pour tous
les projets Web.

Tableau 8-5
Exemple de bordereau de prix pour un projet institutionnel simple (extrait de
l’étape « conception graphique »)

1. CRÉATION DES PISTES GRAPHIQUES


Livrable(s) Deux pistes graphiques soit deux pages d’accueil et six pages
intérieures. Les pistes sont présentées sous forme d’images
Photoshop.
Profil(s) + coût jour
Charge
Coût en euros
2. RÉUNION DE PRÉSENTATION DES PISTES GRAPHIQUES
Livrable(s) PV de validation d’une piste graphique
Profil(s) + coût jour
Charge
Coût en euros
3. CRÉATION DES GABARITS
Livrable(s) Quinze gabarits au format Photoshop + quinze gabarits au format
HTML
Profil(s) + coût jour
Charge
Coût en euros

Bordereau de prix (bordereau_prix.rtf )

200
Chapitre 8 – L’appel d’offres

Le déroulement type et le calendrier de l’appel d’offres sont aussi


très importants : ils permettent aux prestataires de s’organiser et
lèvent les doutes sur le rendu de tel ou tel livrable, la possibilité de
poser des questions…
Les supports du brief peuvent être de natures très variées et seront
plus ou moins nombreux en fonction de la nature du projet et des
livrables demandés aux prestataires.

Bonne pratique : un brief court et efficace


Le brief est un moment privilégié qui permet à l’entreprise de faire passer des messages essentiels
aux prestataires candidats à l’appel d’offres. Il ne doit surtout pas servir à détailler le projet, les
documents comme le cahier des charges sont là pour ça. L’idéal est d’expliquer les objectifs pour-
suivis par l’entreprise, le cadre politique du projet, la procédure d’appel d’offres (calendrier, livra-
bles, etc.) et les points fonctionnels ou techniques délicats. Il sera toujours temps, après que le
prestataire aura travaillé sur le cahier des charges, de prévoir une réunion de travail qui permettra
de répondre aux questions portant sur les détails.

La préparation du brief est habituellement réalisée en interne. Dans


certains cas, le recours au prestataire qui a rédigé le cahier des
charges et/ou aidé à la sélection de la short-list peut se justifier.
Réaliser le brief
Le brief peut prendre plusieurs formes : rendez-vous en face à face,
réunion publique, rendez-vous à la discrétion des prestataires… Il
peut être mené avec ou sans l’assistant à maîtrise d’ouvrage.
Le rendez-vous individuel autorise une écoute plus active et facilite
l’établissement d’un climat de confiance. Il est par contre chrono-
phage et induit des biais : le dernier brief est souvent beaucoup plus
clair que le premier car de nombreuses questions ont été posées
entre-temps, forçant l’entreprise à clarifier la présentation de son
projet.
La réunion publique fait gagner du temps et de l’énergie à l’entre-
prise. Elle confronte les candidats, ce qui a le mérite de clarifier la
situation. Cependant, des zones d’ombre importantes risquent de
subsister car les candidats n’osent pas toujours poser toutes les ques-
tions en public par crainte de perdre un avantage ou par peur du
ridicule.
Le principe d’un rendez-vous à la discrétion des prestataires permet
de mesurer l’intérêt qu’ils portent au projet. Cependant, l’expé-
rience montre que des candidats intéressants sont parfois écartés car
ils ne savent pas forcément bien gérer ce genre de situation.

201
Partie II – La conduite des projets Web

La présence du prestataire qui réalise l’assistance à maîtrise d’ouvrage


peut être utile quand, par exemple, des éléments techniques doivent
être mis en avant. Elle est déconseillée dans les autres cas.

Analyser les réponses

L’analyse des réponses des candidats est d’autant plus aisée qu’elle
a été intégrée dans les étapes précédentes, notamment dans le
cahier des charges et lors du brief (questionnaire aux fournisseurs,
bordereau de prix, etc.). Dans le cas contraire, il est utile de
s’armer de patience et de courage, notamment pour comparer les
propositions commerciales !

Analyser la solution
Cette étape consiste à décortiquer les réponses des prestataires au
travers de critères relatifs à la compréhension de la probléma-
tique, à la complétude et à la qualité de la solution. Au final,
l’entreprise doit disposer d’une grille qui résume les points forts
et les points faibles de chaque proposition.
Évaluer la bonne compréhension de la problématique revient à
retrouver les objectifs reformulés clairement ainsi que de
nombreux détails montrant une vraie sensibilité au métier de
l’entreprise.
Exemples de critères permettant d’analyser la problématique
– reformulation des objectifs ;
– identification des points bloquants ;
– identification des facteurs clés de succès ;
– compréhension du métier.

Les critères généraux d’évaluation de la solution portent sur deux


dimensions : la complétude et la qualité. La complétude évalue le
degré de couverture des besoins exprimés, la qualité évalue la
pertinence de la solution en tenant compte des contraintes du
projet.

Exemples de critères permettant d’analyser la solution dans son ensemble


– couverture des besoins fonctionnels ;
– couverture des besoins techniques ;

202
Chapitre 8 – L’appel d’offres

– prise en compte des contraintes ;


– évolutivité de la solution ;
– pérennité de la solution ;
– pragmatisme de la solution.

Les critères spécifiques d’évaluation de la solution portent, en


général, sur des éléments comme le design et l’architecture tech-
nique. La caractérisation des fonctions de service réalisée lors de
l’étude de faisabilité peut être une base pour définir ces critères.
Exemples de critères permettant d’analyser le design
– respect du territoire de la marque ;
– transcription des valeurs ;
– créativité ;
– lisibilité ;
– homogénéité ;
– aisance de la navigation ;
– qualité d’exécution ;
– respect des standards.

Exemples de critères permettant d’analyser l’architecture technique


– complexité ;
– fiabilité ;
– intégration au système d’information ;
– évolutivité ;
– pérennité.

Enfin, la méthodologie proposée doit être analysée avec le plus


grand soin. Les éléments à étudier sont les livrables, le découpage
des étapes et les méthodes employées.
Exemples de critères permettant d’analyser la méthodologie proposée
– clarté des livrables ;
– précision du découpage des tâches ;
– précision de l’évaluation de la charge ;
– capacité annoncée de s’interfacer avec le(s) prestataire(s) amont et aval ;
– présence d’une phase d’initialisation ;
– présence d’un PAQ ;
– garanties en termes de délais ;
– garanties en termes de charges ;
– garanties en termes de qualité des livrables.

203
Partie II – La conduite des projets Web

En règle générale, cette étape est menée avec l’appui du presta-


taire qui a réalisé l’étude de faisabilité et/ou rédigé le cahier des
charges.
Grille d’analyse des solutions (grille_solutions.xls)

Analyser le budget
Dans un premier temps, le but est de comparer les grandes masses
budgétaires par étapes et par profils. L’analyse porte dans un
deuxième temps sur l’étude des charges, des coûts journaliers, des
coûts de création et des coûts de possession. Au final, l’entreprise
dispose d’une grille d’analyse renseignée qui l’aidera à négocier avec
le prestataire retenu.

Bonne pratique : le bordereau de prix simplifie la comparaison


Décortiquer des propositions commerciales construites différemment est presque impossible et
dans tous les cas très long. En imposant une grille commune à tous les candidats, le bordereau
de prix simplifie le travail de l’entreprise et limite les mauvaises surprises.

Le premier critère d’analyse du budget est donc la charge de


travail. L’idéal est de fixer, a priori, une fourchette avec un
minimum et un maximum en deçà et au-delà desquels l’offre
n’est pas crédible. Ils peuvent être issus de l’étude de faisabilité.
Cette base de comparaison objective constituera un repère bien
utile. Le fait que les différentes offres entrent dans cette four-
chette est déjà une indication intéressante. Dans le cas contraire,
soit l’étude de faisabilité n’est pas pertinente, soit – et c’est le plus
probable – le besoin n’a pas été compris et la proposition est hors
sujet.
Des différences apparaissent forcément entre chaque proposition.
Elles sont en général liées à des approches méthodologiques diffé-
rentes. Un prestataire ayant opté pour une méthode « linéaire »
proposera par exemple une répartition de charges de l’ordre de
60 % pour la conception et de 40 % pour les développements.
Inversement, un prestataire ayant choisi une méthode itérative
présentera une répartition de l’ordre de, respectivement, 30 % et
70 %. Une technique efficace consiste dans ce cas à comparer les
prix de vente journaliers moyens (soit le budget total hors
licences et matériel, divisé par la charge totale) Si les différences
méthodologiques ne justifient pas les écarts constatés, il est
probable qu’un point fonctionnel et/ou technique ait été soit mal
formulé, soit mal compris, soit sous-estimé.

204
Chapitre 8 – L’appel d’offres

Tableau 8-6
Répartition des budgets en fonction de la méthode

PART DU BUDGET PART DU BUDGET


DE CONCEPTION DE RÉALISATION

Approche linéaire 60 % 40 %
Approche itérative 30 % 70 %

Le deuxième critère d’analyse porte sur les profils et les coûts jour-
naliers. Ces coûts étant multipliés par la charge, des différences
mineures peuvent avoir, au final, un impact fort sur le budget. Une
technique d’analyse efficace consiste à réaliser une moyenne pour
chaque profil et à comparer chaque proposition sur cette base.
Cependant, dans certains cas, notamment quand les candidats sont
tous très spécialisés, il pourra être utile de se renseigner sur les prix
moyens pratiqués sur le marché.
Pour finir, les différents coûts de création et de possession doivent
être précisément étudiés. En effet, des différences significatives entre
les différentes propositions s’expliquent souvent par des coûts
« cachés ». Dans le budget de réalisation, il faut notamment faire
attention aux coûts des licences, au coût de la reprise de l’existant et
au coût des formations. Dans le budget de possession, les licences,
l’hébergement, la maintenance, le Webmastering, le référencement
annuel… devront être surveillés.
En règle générale, cette étape est menée avec l’appui du prestataire
qui a réalisé l’étude de faisabilité et/ou rédigé le cahier des charges.
Formaliser la synthèse
L’objectif de cette étape est de créer un document synthétique qui
facilitera la prise de décision. Cela revient donc à concaténer les
différentes grilles de critères de manière à disposer d’une synthèse
comparable de chaque proposition. Comme pour le choix d’une
solution lors de l’étude de faisabilité, chaque critère doit être
pondéré en fonction de la priorité du projet : délais, complétude,
respect du budget… Il est aussi très important d’ajouter à ces
critères une note sur la qualité de la relation entre chaque prestataire
et l’équipe qui aura en charge le projet (dans le cas où cette dernière
participe à un appel d’offres sur performances). Ce dernier point
devrait peser dans la décision finale. De cette manière, la note finale
sera représentative des attentes de l’entreprise. Cette étape est
réalisée en interne.
Grille de synthèse (grille_synthese.xls)

205
Partie II – La conduite des projets Web

Pour aller plus loin

Ouvrages
Michel Roux
Appels d’offres : Rédiger, répondre, analyse
Éditions Eyrolles – 2007 – ISBN : 978-2212538373
Valérie Sédallian et Jérôme Dupré
Le contrat d’achat informatique : Aspects juridiques et pratiques
Vuibert – 2005 – ISBN : 978-2711748358
Thierry Craye
Appels d’offres : la stratégie gagnante pour les gérer et les remporter
Chiron – 2006 – ISBN : 978-2702711859
Sylvie Lepont
Le guide des sociétés de services informatiques
Éditions du Management – L’Expansion – 2006 – ISBN :
978-2910987213

Avis d’experts

Recruter efficacement
son prestataire Web
La diversité des acteurs, la complexité des projets et le manque de culture Internet
rendent difficile le choix du prestataire Web. Par chance, les risques peuvent en être
limités en respectant quelques règles simples.
La réussite d’un projet Web repose sur un cahier des charges clair, de bons choix techniques
et un prestataire compétent, synthétise Sylvie Aubin-Zaabi, directrice des éditions du
CIDJ (Centre d’information jeunesse). La publicité faite à l’appel d’offres et le choix
des destinataires sont aussi fondamentaux : trop de visibilité conduit à un travail très
important de dépouillement. À l’inverse, oubliez de communiquer et vous n’aurez pas
assez de bonnes réponses, complète Benoît Léger, consultant chez Stelau Conseil.

206
Chapitre 8 – L’appel d’offres

SSII, indépendant, Web agency ou intégrateur ?


Le choix du candidat est difficile car cela demande une bonne connaissance des
forces et faiblesses de chaque type d’intervenant en fonction des contraintes du
projet. Pour se décider, la taille du projet et sa nature jouent un rôle essentiel. S’il
est modeste et peu stratégique (un site vitrine par exemple), un indépendant peut
apporter plus de souplesse et de réactivité qu’une grosse structure... pour un
budget largement inférieur. En revanche, quand le projet implique des processus
métier comme la gestion des stocks ou la comptabilité, mieux vaut s’appuyer sur
un spécialiste du domaine, souvent une SSII (Société de service et d’ingénierie
informatique) ou un intégrateur. Même si elles recourent fréquemment à la sous-
traitance, les structures de taille moyenne à importante rassurent sur leur pérennité et
garantissent un interlocuteur dans la durée, précise Sylvie Aubin-Zaabi.
Trois à cinq candidats par short-list
Pour Florent Mondolfo, responsable de Prestataires.com, la short-list idéale doit
comprendre de trois à cinq prestataires, ce qui est suffisant pour se faire une idée de la
diversité des solutions et des budgets. Pour les identifier, Sylvie Aubin-Zaabi a sans cesse
en tête la chasse au bon prestataire. Elle note le nom des entreprises ayant développé
un site qui lui plaît, se renseigne auprès des professionnels qu’elle croise, même mon
banquier et mon agence de voyage !, précise-t-elle. Une autre méthode efficace consiste
à confier son besoin à des sites spécialisés comme 123presta, Companeo ou Presta-
taires, qui disposent tous d’une base de plusieurs milliers de spécialistes.
Ne pas oublier de convaincre le prestataire !
Plus votre projet est valorisant pour le prestataire, plus il pourra s’en servir pour se
vendre. Son implication sera donc proportionnelle à l’intérêt que vous saurez éveiller en
lui, indique Florent Mondolfo. Le « brief » doit en conséquence être abordé
comme une réunion de partenaires. Idéalement, une à deux heures seront consa-
crées à chaque candidat pour évoquer les objectifs, les points fonctionnels et tech-
niques importants, ainsi que la procédure d’appel d’offres. Il ne sert à rien de trop
détailler le besoin, le cahier des charges est prévu à cet effet.
Grilles de critères et « ressenti », les clés d’un choix équilibré
L’analyse des propositions commence dès la rédaction du cahier des charges. À
cette occasion, des grilles de critères sont formalisées et pondérées. Elles servent à
analyser les propositions. Quand le projet est complexe, un bordereau de prix est
proposé aux candidats. Les éléments factuels (charge, planning, budget, etc.) pourront
ainsi être comparés en quelques minutes, laissant plus de temps pour évaluer la valeur
ajoutée de chaque prestataire et comprendre les méthodologies proposées, ajoute Benoît
Léger. Reste à évaluer la dimension affective : la première impression est-elle posi-
tive ? Le candidat a-t-il recherché des solutions spécifiques plutôt qu’exposé ses
références ? A-t-on envie de travailler avec lui ?

207
Partie II – La conduite des projets Web

Pour être sûr, contacter les clients du prestataire


Mais attention, la proposition remise lors de l’appel d’offres ne suffit pas. Il faut
voir les autres réalisations et contacter par ses propres moyens des donneurs d’ordre ayant
déjà travaillé avec le prestataire, conseille Florent Modolfo. C’est en effet le meilleur
moyen d’anticiper des problèmes « invisibles » tels qu’un décalage entre la volonté
du client et le site effectivement réalisé ou un manque de réactivité pour les mises
à jour. Je ne suis jamais allée vérifier les certifications type Microsoft de mes presta-
taires : je me fie aux projets développés avec des clients, pas aux peaux de lapins infor-
matiques !, renchérit Sylvie Aubin-Zaabi. Le choix final repose sur un savant équi-
libre entre les critères objectifs et affectifs. Si les premiers sont rationnels, donc
indiscutables, il ne faut surtout pas négliger la dimension humaine. L’implication,
la capacité à se remettre en cause, l’envie de créer une « success story », sont tout
aussi déterminants dans un secteur où les développeurs doivent tout réapprendre
chaque année.
Article paru sur http://www.indexel.net

Avis d’experts

Cahier des charges Web :


mode d’emploi
Premier document contractuel d’un projet Web, le cahier des charges vise à forma-
liser les besoins et les exigences de l’entreprise. Considéré comme un passage
obligé, c’est en réalité le premier pas vers un projet maîtrisé.
Un cahier des charges pour quoi faire ?
En interne, le cahier des charges sert à formaliser le besoin et à l’expliquer aux différents
acteurs pour s’assurer que tout le monde est d’accord. Cela oblige à définir des objectifs
business quantifiés. Il sert ensuite à sélectionner le prestataire puis à gérer la relation
tout au long du projet, résume Anne de Montalivet, responsable des projets Internet
du groupe Chantelle. Référentiel contractuel partagé par le prestataire et l’équipe
interne, le cahier des charges est donc le principal outil de communication du chef
de projet.

208
Chapitre 8 – L’appel d’offres

Comment le rédiger ?
Il ne faut jamais perdre de vue que le cahier des charges vit tout au long du projet. En
imposer une lecture fastidieuse est le meilleur moyen pour que personne ne l’utilise,
précise Anne de Montalivet. Pour être le plus synthétique possible, sa rédaction
doit favoriser les résumés (une page au maximum), les listes à puce et les tableaux.
Concrètement, un cahier des charges est en général composé de quatre parties. La
première explique pourquoi le projet existe, quels sont ses objectifs et qui le pilote :
rôles respectifs de la maîtrise d’ouvrage (MOA) et de la maîtrise d’œuvre (MOE),
procédures de validation, etc. La deuxième présente les besoins fonctionnels, tech-
niques et organisationnels, ainsi que les contraintes et les exigences. La troisième
partie liste les prestations et les livrables attendus.
Cette liste sert de boussole tout au long du projet. C’est autant un pense-bête qu’un outil
pour rappeler à l’ordre les prestataires, explique Anne de Montalivet. Attention à la
cohérence quand plusieurs prestataires sont impliqués, les uns s’appuyant sur les livrables
des autres, ajoute Franck Gonzales, fondateur du cabinet de consultant Osaxis. La
quatrième partie définit le cadre de la réponse : planning de l’appel d’offres, docu-
ments attendus, règles de sélection, etc.
Quels éléments juridiques inclure ?
Pour Anne de Montalivet, il faut absolument impliquer un juriste dans la rédaction
du cahier des charges. C’est véritablement la seule ceinture de sécurité qui garantisse au
minimum le résultat en cas de problème. En effet, trop d’entreprises mettent de côté
les aspects juridiques, espérant les traiter plus tard. L’expérience montre que c’est
le meilleur moyen de se faire imposer le contrat du prestataire, donc d’être poten-
tiellement lésé en cas de différend finissant devant les tribunaux.
Pour éviter d’en arriver là, il suffit de définir des pré-requis en amont du projet et d’en
faire mention dans le cahier des charges ou d’ajouter un projet de contrat en annexe
quand c’est possible. Ce dernier accélère la rédaction puis la négociation du contrat final
et garantit que le projet commencera dans un cadre juridique partagé, explique Fran-
klin Brousse, avocat spécialisé dans les nouvelles technologies. Ce n’est donc pas
une perte de temps et encore moins une dépense inutile.
Concrètement, trois conditions juridiques doivent apparaître dans le cahier des
charges : un planning précis (des dates ou des délais impératifs avec engagement
de résultat et un mécanisme de pénalité de retard) ; les clauses de cession des droits
incluant les droits des éléments de contenu utilisés pour créer le site (textes,
photos, images...) ; les modalités de validation (déroulement et supports des vali-
dations, répartition des rôles lors de la recette, PV de réception provisoire, PV de
réception définitive, etc.).

209
Partie II – La conduite des projets Web

Et la technique dans tout ça ?


Pour Franck Gonzales, la partie technique d’un cahier des charges doit se limiter à
énumérer les contraintes techniques avérées. Le recours à tel ou tel serveur d’applica-
tions, le budget de fonctionnement, la plate-forme de déploiement par exemple. L’erreur
la plus courante – exprimer ses préférences à la place des contraintes – conduit
systématiquement à des incompréhensions et des remises en cause aussi tardives
que dramatiques. Pour l’éviter, il faut confier la rédaction du cahier des charges à un
non-technicien et fournir le même niveau de détail pour chaque besoin, préconise
Franck Gonzales.
Quand on n’est pas à l’aise, le recours à un expert pour valider la cohérence du
cahier des charges peut être une bonne solution. Cela réduit considérablement les
risques sans représenter un budget important (situé entre 300 et 500 euros).
Article paru sur http://www.indexel.net

210
Chapitre 9

La conception

Figure 9-1
Les différentes étapes de la conception

211
Partie II – La conduite des projets Web

Cette phase concrétise la vision définie lors de la stratégie, valide la


faisabilité en commençant à envisager concrètement l’implémenta-
tion de l’une des solutions proposées, et, surtout, donne à voir aux
utilisateurs les premiers résultats concrets : la maquette HTML et/
ou le prototype.
Après de nombreuses itérations, des débats passionnés entre ergo-
nomes et graphistes, des explications entre consultant fonctionnel et
chef de projet technique, le verdict des utilisateurs doit décider
quand passer à la phase suivante : la réalisation.

Conception fonctionnelle

Il y a quelques années, l’étape de conception fonctionnelle consistait


essentiellement à créer le rubriquage du site ou de l’intranet.
Aujourd’hui, la description des processus métier devient le cœur de
la démarche, participant à la lente intégration des projets Web au
système d’information. Il n’en reste pas moins que les approches
éditoriale et par processus sont complémentaires et répondent à un
seul objectif : la description de la future application.

Approche éditoriale
La ligne éditoriale et le rubriquage sont souvent les premières pierres
des projets Web. Ils permettent, si cela n’a pas été fait lors de l’étape
« faisabilité », de clarifier les idées du groupe de projet sur le contenu
et la forme du site.

Créer la ligne éditoriale


Cette tâche consiste à définir les aspects qualitatifs des contenus et
notamment le ton, l’ambiance et les traitements éditoriaux de
chacun d’entre eux.
Le ton et l’ambiance permettent de définir un style propre au site
dont le vocabulaire et le style graphique seront des « relais opéra-
tionnels ». Un portail d’entreprise peut par exemple user d’un ton
amical et essayer d’installer une ambiance décontractée. Les traite-
ments éditoriaux précisent les formats (fil, brève, article court,
article long, dossier, enquête…) et les angles utilisés (factuel, histo-
rique…). Notre portail d’entreprise aura par exemple tendance à
utiliser des formats courts favorisant la lecture (fil, brèves, articles
courts) et des angles incitatifs (histoire).

212
Chapitre 9 – La conception

Tableau 9-1
Exemple de ligne éditoriale

ÉLÉMENT DE LA LIGNE UZINE.NET TF1.FR


ÉDITORIALE

Objectif Faire passer un Relayer l’univers des émissions, renforcer


message politique la dépendance
Fréquence Quotidienne Quotidienne
Ton Engagé, partisan Jeune
Ambiance Sérieuse Spectacle (information scénarisée, photos
choc, etc.)
Formats Brèves, articles Articles courts, multimédias
Angles Polémique, mise Faits divers (les faits sont présentés sous
en perspective l’angle de l’histoire, de l’anecdote, etc.)
Niveau grammatical Moyen Faible
Niveau vocabulaire Moyen Faible
Lisibilité Faible Forte

Validation du livrable : la ligne éditoriale doit être applicable


Avant de valider ce livrable, il est important de s’assurer que la ligne éditoriale est applicable et
que des exemples sont disponible.

Il est conseillé de confier cette étape à un prestataire spécialisé ou au


prestataire qui travaille sur le rubriquage et les workflows.
Ligne éditoriale (ligne_editoriale.rtf )
Charte éditoriale (charte_editoriale.rtf )
Créer le rubriquage
Cette tâche consiste, dans un premier temps, à créer l’arborescence
générale et/ou le premier niveau de rubriquage (rubriques et sous-
rubriques) puis, dans un second temps, à définir précisément les
gabarits éditoriaux et les contenus et à lister les fonctionnalités du
site. Le niveau de détail exigé est important puisque le but est de
décomposer chaque page ou composant en titre, chapeau, intertitre,
texte courant, légende, illustration, rebond… et pour chacun de ces
éléments, de déterminer un calibrage ainsi que des règles de gestion
associées. Au final, l’entreprise disposera d’une vision claire de la
partie éditoriale du front-office du futur site, formalisée sous forme
de dossier de rubriquage.

213
Partie II – La conduite des projets Web

La meilleure base de travail pour y parvenir est l’expression des


besoins réalisée lors de l’étude de faisabilité. Cependant, dans le cas
d’un intranet ou d’un portail d’entreprise, il sera en outre nécessaire
d’impliquer les responsables de chaque service ou de chaque direc-
tion concernés. Ils préciseront quels contenus et services proposés
sont les plus utiles à l’activité quotidienne de leur équipe. Cette
démarche facilitera beaucoup la validation finale du rubriquage.
Pour animer la réunion, le moyen le plus efficace consiste à proposer
un rubriquage de principe qui sera critiqué et modifié par les parti-
cipants. Il est aussi possible de partir d’une feuille blanche, mais
cette méthode n’est pas recommandée car des problèmes de séman-
tique apparaissent très vite entre les participants et tout progrès
devient alors difficile.
.

214
Tableau 9-2
Rubriquage, partie 1

RUBRIQUE SOUS-RUBRIQUE PAGE /GABA- CONTENU VOLUME SOURCE DE RESPONSABLE RESPONSABLE PUBLI-
RIT L’INFORMATION DE MISE À JOUR CATION

Nom de la Nom de la sous Nom de la Découpage de la page en : Nombre Nom de la Nom de la Nom de la per-
rubrique rubrique page (ou du – titre (calibrage et règle asso- de page(s), personne personne sonne identifiée
gabarit) ciée) ; de fiche(s), identifiée identifiée comme responsa-
– chapeau (calibrage d’articles… comme créant comme res- ble de la publica-
et règle associée) ; l’information ponsable de la tion. À défaut type
– corps de texte (calibrage et + coordon- mise à jour. À de profil suscepti-
règle associée) ; nées défaut, type ble de valider la
– liens (calibrage et règle asso- + nature de de profil sus- mise à jour
ciée) ; l’information ceptible de + coordonnées

215
– légende (calibrage et règle (RA, lettre, réaliser la
associée)… note mise à jour
interne…) + coordon-
+ format de nées
l’information
(papier,
numérique,
audio,
vidéo…)
Chapitre 9 – La conception
Partie II – La conduite des projets Web

Une deuxième réunion permet de compléter le dossier de rubri-


quage avec des informations relatives à la fréquence de mise à jour,
au responsable éditorial, au producteur d’information… de chaque
page ou composant. Toutes ces informations permettront de définir,
s’il y a lieu, le workflow de mise à jour.
Bonne pratique : projetez-vous dans l’avenir
Il faut décider d’une fréquence de mise à jour pour chaque page ou chaque composant. Il est
conseillé d’être modeste et, avant de statuer définitivement, de faire une projection sur l’année
pour avoir une idée du travail global que la page demandera.

Tableau 9-3
Rubriquage, partie 2

A - FRÉQUENCE DE B - TEMPS DE C - TEMPS DE D - TEMPS DE E - TEMPS


MISE À JOUR RÉDACTION VALIDATION PUBLICATION ANNUEL
EN MINUTES EN MINUTES EN MINUTES EN JOUR

1 = annuelle Ax(B+C+D)/480
12 = mensuelle
52 = hebdomadaire

Pour être efficace, cette méthode doit être menée avec une grande
rigueur. Ainsi, chaque information du tableau doit être précisée, ce
qui n’est pas toujours évident surtout pour la partie workflow.
Validation du livrable : attention aux détails
Avant de valider le rubriquage, il est utile de vérifier que :
– chaque colonne est complète (le contenu est décrit en détail pour chaque page ou chaque com-
posant) ;
– les personnes citées ont effectivement la disponibilité et l’autorité annoncées ;
– les fréquences de mise à jour sont réalistes.

Cette étape peut être réalisée en interne ou confiée à un prestataire


spécialisé en conception de sites. Elle ne présente pas de difficultés
majeures mais peut prendre un certain temps du fait d’un grand
nombre d’itérations avec les personnes concernées.
Dossier de rubriquage (rubriquage.rtf )
Dossier de workflow (workflow.rtf )
Approche par processus
La plupart des projets Web ont désormais pour objectif de réaliser
des gains de productivité en automatisant certains processus straté-

216
Chapitre 9 – La conception

giques. Les exemples les plus courants sont la prise de commande en


ligne, le support client et les relations fournisseurs automatisés ou
encore, en interne, la saisie déportée des notes de frais, l’e-procure-
ment, la réservation de salle…
Pour y arriver, l’entreprise doit apprendre à se connaître en analysant
les processus constitutifs de son métier, puis les optimiser et, enfin,
les rendre disponibles en ligne.
Plus simplement, un site institutionnel « élémentaire » devra décrire
clairement ses processus de gestion de contenu, de réponse aux
e-mails, d’utilisation de la newsletter…
Pour la plupart des projets, l’approche par processus est complé-
mentaire de l’approche éditoriale.

Décrire les processus


Repère : 125 grands processus
Selon François Tabouro, directeur général de Mega international, il est généralement considéré
que l’activité des entreprises peut être décrite avec environ 125 grands processus.
Source : Décision informatique (http//www.01net.com/rubrique/3345.html)

L’analyse du métier et des processus sous-jacents s’effectue à l’aide


d’entretiens menés individuellement ou collectivement. Le but est
d’obtenir une première vision globale de chaque grand processus
pour ensuite détailler chaque sous-processus voire chaque « sous-
sous-processus ».

Figure 9-2
Exemple de diagramme de flux conceptuel de niveau 1 (achat)

Cette première tâche peut être réalisée à l’aide de méthodes de modélisa-


tion telles que les diagrammes de flux de Merise ou les « use case » d’UML
(Unified Modeling Language). L’idée est de décrire les actions effectuées
par les acteurs d’un processus et d’identifier les informations associées.
On distingue en général :
• les processus métier qui réalisent des missions du domaine ;

217
Partie II – La conduite des projets Web

• les processus support qui ne font pas partie du domaine mais


dont les résultats sont nécessaires aux processus métier ;
• les processus de pilotage qui organisent les activités de pilotage à
l’intérieur du domaine.

Figure 9-3
Exemple de diagramme de flux conceptuel de niveau 2 (sélection produit)

Figure 9-4
Exemple de modélisation des processus de « vente de forfait voyage » avec
le logiciel MEGA

218
Chapitre 9 – La conception

L’intérêt de ces méthodes est qu’elles permettent aux informaticiens


comme aux utilisateurs finals de se mettre d’accord sur une vision
de l’entreprise et de ses processus au travers de la création de
diagrammes assez simples à appréhender (quand ils sont pris sépa-
rément !).

Validation du livrable : attention à la complétude


La validation de ce livrable s’effectue après avoir vérifié que tous les processus du périmètre ont
été couverts.

Cette tâche peut être réalisée en interne ou confiée à un prestataire


spécialisé. Selon la complexité et le type de projet, il s’agira d’un
cabinet de conseil en architecture, d’un spécialiste de la modélisa-
tion des flux ou d’un consultant indépendant spécialiste du métier
analysé.

Optimiser les processus


La seconde tâche consiste, après avoir dressé la cartographie géné-
rale, à identifier les processus qui méritent d’être optimisés. Les buts
poursuivis lors d’une optimisation sont, en général, de mieux
répondre à un besoin client (prise de commande client), de réduire
les coûts pour augmenter la marge (suivi administratif fournisseurs
automatisé par exemple), de dégager du temps pour certains profils
(automatisation du reporting de la force de vente, et donc de la
consolidation)…
Une fois le processus identifié, les dysfonctionnements sont recher-
chés puis corrigés. Au passage, il peut être intéressant de fixer des
indicateurs de manière à pouvoir mesurer le gain apporté par l’opti-
misation du processus.
Des réunions de groupe ou des entretiens en face à face peuvent être
très utiles à ce moment-là. L’expérience de l’intervenant fait gagner
énormément de temps car il peut évoquer, pour des situations clas-
siques, les solutions observées et/ou mises en œuvre dans d’autres
sociétés.

219
Partie II – La conduite des projets Web

Figure 9-5
Exemple d’optimisation de processus

Tableau 9-4
Processus avant et après optimisation

AVANT OPTIMISATION APRÈS OPTIMISATION

Action n° 1 – Ajout du prix Action n° 1 – Ajout du prix


Entrée : fiche produit partielle Entrée : fiche produit partielle
(le prix est absent) (le prix est absent)
Action : ajout du prix Action : ajout du prix
Acteur : assistante commerciale Acteur : directeur commercial
Sortie : fiche produit complète Sortie : fiche produit complète
Volumétrie : 100 fiches/an Volumétrie : 100 fiches/an

Action n° 2 – Validation Action n° 2 – Publication


Entrée : fiche produit complète Entrée : fiche produit validée
Action : validation Action : déplacement du fichier sur le
Acteur : directeur commercial serveur de production
Sortie : fiche produit validée Acteur : automatisation via un script
Volumétrie : 100 fiches/an Sortie : fiche produit en ligne
Volumétrie : 100 fiches/an
Action n° 3 – Publication
Entrée : fiche produit validée
Action : déplacement du fichier sur le serveur
de production
Acteur : Webmaster
Sortie : fiche produit en ligne
Volumétrie : 100 fiches/an

220
Chapitre 9 – La conception

Nous venons de le voir dans l’exemple précédent : les améliorations


sont à la fois organisationnelles et informatiques. Il est donc néces-
saire de définir l’organisation humaine qui fera fonctionner le dispo-
sitif. Celle-ci peut être décrite au travers de rôles (qui fait quoi), de
profils (formation requise, compétences techniques, etc.) et de rela-
tions (le publieur dépend du valideur pour publier un article, etc.).
Avec Merise, il s’agira du modèle organisationnel des traitements
(MOT) et en UML, ce sera le diagramme d’activité. Enfin, il est
nécessaire de préciser la volumétrie de cette organisation : nombre
de rôles, nombre de profils, etc.
Merise
Ce terme désigne une méthodologie inventée dans les années 1970 – à la demande de l’État
français – pour standardiser l’analyse et la conception des systèmes d’information (SI). Elle se
décompose en trois étapes. La première, la formalisation conceptuelle, va permettre de fixer les
choix des informations à manipuler et des traitements à effectuer, avec l’établissement pour les
données du MCD (modèle conceptuel des données) et pour les traitements du MCT (modèle
conceptuel des traitements). La deuxième étape spécifie l’organisation qui régira les données et
les traitements définis précédemment avec le MLD (modèle logique des données) et le MOT
(modèle organisationnel des traitements). La troisième étape (« l’informatique pure ») est la
formalisation opérationnelle qui consiste à spécifier comment sera réalisé ce qui a été défini dans
l’étape précédente avec le MPD (modèle physique des données) et le MOPT (modèle opéra-
tionnel des traitements).

L’optimisation des processus est confiée au prestataire qui a réalisé la


description des processus. Elle peut aussi être menée en interne.
Créer la cinématique
La cinématique (que l’on nomme également story-board ou wire-
frame) traduit les documents conceptuels précédents (dossier de
rubriquage, processus métier, etc.) en une vision concrète et réaliste
du futur site. Il s’agit, en effet, d’une représentation graphique
précise de l’enchaînement et du contenu réel de chaque page. La
cinématique peut être réalisée avec Powerpoint, Visio ou un logiciel
dédié tel que Axure pro.
Repère : dix règles de conception vues de la place de l’internaute
1. L’attente doit en valoir la peine (chaque contenu, chaque image, chaque fonctionnalité doit
poursuivre un objectif essentiel).
2. Dites-moi ce que j’obtiens si je fais ça (expliquer à quoi sert chaque information demandée,
expliquer les processus avant qu’ils aient lieu, situer l’avancement de l’internaute dans le pro-
cessus).

221
Partie II – La conduite des projets Web

3. Je m’enregistrerai moi-même quand je serai prêt (pas de personnalisation implicite sauf si elle
est demandée).
4. Utilisez ce que je vous donne (se rappeler des goûts de l’internaute, ne pas lui demander deux
fois la même chose, etc.).
5. Aidez-moi à comparer vos produits/services (mieux vaut aider à comparer les produits que per-
dre le visiteur).
6. Ne me demandez pas de me décider/d’agir sans information (pour faire agir l’internaute, il
faut lui en donner les moyens, notamment au travers du contenu).
7. N’essayez pas de deviner ce que je pense, donnez-moi plutôt les moyens de trouver ce que je
veux (mieux vaut un contenu à jour et facilement accessible qu’une personnalisation mal pensée
– ce qui est presque toujours le cas !).
8. Faites simple (le principe de navigation, la structure du site et des pages doivent être toujours
les mêmes ; l’internaute doit toujours savoir d’où il vient, où il est et où il va).
9. Ne me rejettez pas ! (ne pas mener les internautes à des zones qu’ils ne peuvent pas utiliser).
10. Ne me noyez pas sous l’information (les propriétés d’Internet doivent être utilisées pour
distiller l’information au fur et à mesure qu’elle est utile).
Source : Jodie Dalgleish, Customer Effective Web Sites (éditions Ft.com).

Figure 9-6
Exemple de cinématique du site http://www.rfimusique.com

La cinématique permet d’atteindre trois objectifs. Premièrement,


elle fait ressortir les erreurs de conception (rubriquage trop détaillé,
pages d’accueil de sous-rubrique inutiles, contenus déséquilibrés,
actions inversées ou mal placées…).

222
Chapitre 9 – La conception

Deuxièmement, elle permet d’améliorer l’ergonomie du site. À ce


titre, c’est un support qui peut être utilement testé auprès des futurs
utilisateurs.
Troisièmement, c’est en analysant la cinématique que l’on déter-
mine les futurs gabarits de la charte graphique. La cinématique est
habituellement formalisée par un consultant fonctionnel ou un
ergonome avec le concours du chef de projet technique. Ils réalisent
ensemble – voire avec des utilisateurs – des choix ergonomiques en
tenant compte des possibilités et limitations techniques de manière
à aboutir à une interface efficace.
Une réunion de présentation permet au chef de projet du prestataire
de présenter la cinématique et d’expliquer ses choix. S’il y a
plusieurs alternatives envisageables, il discute avec l’entreprise des
meilleures options en fonction des objectifs définis dans la note de
cadrage.

Bonne pratique : contenus réels et itération


Pour réussir votre cinématique, utilisez toujours des contenus réels. Le faux texte de type Lorem
ipsum est très dangereux car il vous incite à calibrer le contenu en fonction de l’aspect graphique
plus qu’en fonction du besoin éditorial. Au final, tout le monde se félicite de la validation de la
cinématique… jusqu’au moment où la saisie des vrais contenus commence et là, c’est la douche
froide.
Une autre bonne pratique consiste à créer une première version que l’on teste avec les autres
membres du projet. Une fois améliorée, cette première version est testée avec des utilisateurs qui
ne manqueront pas de relever de nombreuses incohérences et des défauts de conception ! La ver-
sion qui intègre leurs remarques sera alors considérée comme la première version de la cinémati-
que définitive.

Validation du livrable : simple, cohérent, réaliste


Avant de valider une cinématique, il faut s’assurer que :
– elle est la plus simple possible (elle doit paraître évidente même à un collaborateur qui n’a
passuivi le projet) ;
– elle est cohérente (simplification et homogénéisation de pages ressemblantes, etc.) ;
– le contenu proposé est réaliste (volumes, qualité, capacité de production…).

La cinématique peut être réalisée en interne ou être confiée à un


prestataire spécialisé dans la conception et la réalisation de site (SSII,
Web agency, assistant à maîtrise d’œuvre).
Cinématique (cinematique.rtf )

223
Partie II – La conduite des projets Web

Conception graphique

Les premiers sites Internet étaient très proches des plaquettes


commerciales. Il s’agissait souvent d’une accumulation logique de
pages statiques dont l’objectif était d’impressionner l’internaute par
la qualité de son graphisme. Puis les premières études sérieuses sur
les comportements des utilisateurs ont prouvé que le Web était
différent des autres médias et qu’il possédait ses contraintes propres.
Commença alors une guerre de tranchées entre aficionados des
« beaux » sites en Flash et les défenseurs des sites « utiles » construits
en trois colonnes avec des liens bleus.
Aujourd’hui, pour concilier le meilleur des deux camps, une solu-
tion efficace consiste à confier la conception graphique à une équipe
composée d’un directeur artistique (défenseur de la marque) et d’un
ergonome (défenseur des utilisateurs). Le résultat est presque
toujours équilibré… et au service de l’entreprise.
Du concept board aux templates
Du concept board aux templates, chaque étape concourt à dénir de
plus en plus précisément l’interface graphique. La démarche géné-
rale consiste à itérer avec les créatifs jusqu’à être convaincu par le
livrable puis à passer au livrable suivant et ainsi de suite.

224
Chapitre 9 – La conception

 Concept board :
Figure 9-7 représentation simplifiée
Exemple de cheminement du concept board à la charte graphique mais précise d’un concept.
(http://www.rfimusique.com) En général, un concept
board est constitué d’une
juxtaposition de visuels.
Créer le concept board1
Dans le cas d’un concept
L’objectif du concept board est de décrire l’ambiance du futur site board graphique, le but
sans consacrer trop de temps à sa formalisation. Ce qui compte à est de présenter un code
couleurs, un code typo-
cette étape est la justesse de l’idée et du style graphique plus que la graphique, un principe
qualité d’exécution. L’entreprise doit pouvoir itérer jusqu’à être de traitement des visuels...

225
Partie II – La conduite des projets Web

définitivement convaincue. Cette démarche évite de perdre du


temps lors des étapes suivantes.
Le concept board présente des associations d’éléments graphiques
qui permettent de créer l’image recherchée : polices, couleurs,
modes de traitement des visuels...

Figure 9-8
Exemple de concept board pour le site http://www.rfimusique.com

Des réunions de travail sont à prévoir au cours desquelles le direc-


teur artistique guidera l’entreprise dans ses choix graphiques.

Validation du livrable : le style est-il cohérent avec l’image de l’entreprise ?


Un concept board doit séduire instantanément et résister à une analyse plus rationnelle visant à
valider l’adéquation entre les valeurs proposées et celles de la marque, synthétisées dans la
charte graphique. Dans tous les cas, l’analyse doit s’arrêter à ce niveau de subjectivité, les typo-
graphies et les harmonies de couleurs étant beaucoup trop subjectives.

Le concept board doit être confié à un prestataire spécialisé : Web


agency, directeur artistique indépendant, agence de publicité…
Créer les pistes graphiques
Une piste graphique est généralement constituée de la page d’accueil
et de deux ou trois pages intérieures du futur site. Cette étape fonda-
mentale permet d’ajuster puis de valider les grands choix graphiques.
En général, deux pistes, sous forme d’images Photoshop, seront
proposées. Pour les produire, le directeur artistique étudie la ciné-
matique, le concept board et la charte graphique de l’entreprise avec
pour objectifs :
• de fixer l’identité visuelle du site (bandeau de navigation…) ;
• de déterminer la structure générale des pages (deux ou trois
colonnes, etc.) ;

226
Chapitre 9 – La conception

• d’envisager la navigation (menus, liens, etc.) ;


• de hiérarchiser le contenu (brèves, articles, dossiers, fonctionna-
lités…).

Figure 9-9
Exemple de piste graphique pour le site http://www.rfimusique.com

Une première réunion a pour objectif de choisir parmi les deux


pistes proposées celle qui correspond le mieux aux objectifs de
l’entreprise. C’est aussi l’occasion de discuter avec le directeur artis-
tique pour ajuster certains éléments.
Une deuxième réunion permet ensuite de valider la piste choisie,
une fois celle-ci ajustée en fonction des remarques de l’entreprise.
Les pistes sont alors créées au format XHTML et présentées à
l’entreprise pour validation. Cette étape se termine par la signature
du PV de validation de la piste graphique.

Validation du livrable : respect de la marque et faisabilité technique


La piste graphique est validée après avoir jugé :
– la qualité dans différentes résolutions d’écran et avec différents navigateurs/OS ;
 CSS : Cascading Style
– la qualité d’exécution ; Sheet : « feuilles de style »
– la faisabilité technique (respect des contraintes techniques du Web : poids, cross-browsers, en français. Les feuilles de
style permettent de définir
maintenabilité…) ; la mise en forme de chaque
– la factorisation des styles graphiques (logique de composants, utilisation maximale des élément d’une page HTML
(tableau, cellule, colonne,
CSS1…).
texte, image…).

227
Partie II – La conduite des projets Web

Les pistes graphiques doivent être confiées au prestataire qui a réalisé


le concept board.
Créer les templates
Les templates de pages synthétisent les informations contenues dans
la cinématique et les éléments graphiques validés avec les pistes
graphiques. Ce sont des modèles qui seront utilisés pour créer
chaque page nale du site. Ils constituent le cœur opérationnel de la
future charte graphique. En règle générale, le nombre de templates
varie de 5 % à 20 % du volume total de pages.

Figure 9-10
Exemple de template du site http://www.rfimusique.com

L’essentiel à cette étape est de bien comprendre à quoi servira


chaque page pour les construire de manière efficace. L’entreprise
doit donc avoir la possibilité de suivre la création et d’intervenir
quotidiennement via, par exemple, un accès en ligne sécurisé et des
réunions téléphoniques régulières.
Une première réunion a pour objectif de valider l’ensemble des
templates et, le cas échéant, de s’assurer que toutes les corrections
ont été reportées. C’est, une fois de plus, l’occasion de discuter avec
le directeur artistique pour ajuster certains éléments.
Après validation des templates au format .PSD (Photohop), ils sont
intégrés en XHTML en vue d’être présentés à l’entreprise pour vali-
dation définitive lors d’une réunion prévue à cet effet. Cette étape
se termine par la signature du PV de validation des templates.

228
Chapitre 9 – La conception

Validation du livrable : attention à la réalisation technique


Avant de valider les templates, il faut s’assurer :
– de leur qualité dans différentes résolutions d’écran et avec différents navigateurs/OS ;
– que leur réalisation technique est irréprochable (factorisation composants, CSS, code HTML…) ;
– qu’ils sont conformes aux pistes validées.

Les templates doivent être confiés au prestataire qui a réalisé les


pistes graphiques.

De la maquette HTML à la charte graphique


La création et la validation de la maquette HTML sont des étapes
fondamentales car il s’agit des derniers moments où les modifica-
tions d’interface, de structure ou de fonctionnalité n’ont pas
d’impact fort sur la charge et le budget. Il est donc important de
prendre le temps nécessaire avant de valider la maquette HTML,
quitte à demander à plusieurs reprises au prestataire d’apporter des
modifications et des améliorations.
Créer la maquette HTML
La maquette HTML est constituée de l’ensemble des templates
XHTML précédemment validés, reliés entre eux par des liens
hyper-textes. On y ajoute généralement quelques pages supplémen-
taires (contact, plan du site, crédits…). L’idéal est de la réaliser avec
des textes et des visuels validés de manière à disposer d’une vision
qui soit la plus réaliste possible. Au final, l’entreprise a sous les yeux
un exemple de chaque type de page du site.
Une réunion a pour objectif de valider la maquette HTML et, le cas
échéant, de s’assurer que toutes les corrections demandées ont été
reportées. C’est la dernière fois que les aspects fonctionnels pour-
ront être amendés. Chaque détail doit donc être étudié avec le plus
grand soin. Cette étape se termine par la signature du PV de valida-
tion de la maquette HTML.

Validation du livrable : les utilisateurs ont la parole


La maquette HTML est validée après avoir :
– vérifié la qualité des templates dans différentes résolutions d’écran et avec différents navigateurs/OS ;
– validé que les templates sont déclinables ;
– validé que les utilisateurs sont satisfaits.

229
Partie II – La conduite des projets Web

La maquette HTML doit être confiée au prestataire qui a réalisé les


gabarits ou au prestataire en charge des développements (SSII, Web
agency).
Créer la charte ergonomique et graphique
Le travail consiste à optimiser chaque fichier en vue de sa future
utilisation. Les calques et les scripts des fichiers Photoshop et Illus-
trator sont « nettoyés » et classés. Les règles de nommage sont appli-
quées à l’ensemble des éléments livrés avec la charte (renommage
des fichiers, classement des éléments dans les bons répertoires et
sous les bons intitulés…). Au final, l’entreprise dispose d’une charte
papier et de sa déclinaison au format PDF (ou PowerPoint) ainsi
que d’un CD-Rom contenant tous les fichiers source.

Figure 9-11
Exemple de charte graphique et ergonomique pour le site http://www.rfimu-
sique.com

La charte proprement dite présente en détail chaque gabarit, chaque


page orpheline, les grands principes graphiques et ergonomiques
(codes couleurs, typographie, traitement des visuels…) ainsi que les

230
Chapitre 9 – La conception

éléments techniques (feuilles de style, JavaScript1, Server Side  JavaScript : code embar-
qué dans une page HTML,
Includes2…) du site. qui s’exécute dans le navi-
Elle est présentée au cours d’une réunion durant laquelle est assuré gateur si celui-ci l’autorise.
un transfert de compétences auprès du prestataire qui réalise les  SSI : Server Side Include.
développements ou auprès de l’équipe interne. Souvent abrégé en
« include ». Les SSI permet-
tent de découper une page
Validation du livrable : priorité aux aspects opérationnels en plusieurs fichiers indé-
La charte graphique est un livrable opérationnel. À ce titre, il ne faut la valider qu’après s’être pendants (un include pour
assuré que : le menu, un include pour
le bandeau…). Le but est de
– elle respecte la règle de nommage ; simplifier le développement
– elle respecte les standards techniques définis (versions de HTML, ECMAScript3, CSS…) ; et rationaliser la mainte-
nance en factorisant
– il existe au minimum une page détaillée par gabarit (includes, largeurs de colonnes, taille fixe ou le code.
variable, background de cellules, styles appliqués…) ;
– les fichiers Photoshop et Illustrator sont exploitables et optimisés (multicalques non aplatis,  ECMAScript : standard
calques titrés et classés…) ; qui a mis fin à la guerre
entre JavaScript (Sun)
– il existe des fichiers Photoshop spécifiques pour la création de titres, de boutons, etc. ; et JScript (Microsoft).
– les CSS sont concentrées dans un seul fichier externe ;
– les JavaScript sont concentrés dans un seul fichier externe ;
– l’ensemble des éléments est présent (images sources, images optimisées, fichiers HTML…).

La charte graphique doit être confiée au prestataire qui a réalisé les


gabarits.
Charte graphique et ergonomique (charte_graphique.ppt)

Spécifications fonctionnelles

Les spécifications fonctionnelles ont pour objectif de décrire le plus


précisément possible la future application. Elles sont rédigées sur la
base des livrables validés lors des précédentes étapes. Il s’agit donc
essentiellement d’un travail de synthèse et de complément (règles de
gestion notamment). Le but est de donner les moyens au prestataire
qui réalise les développements d’appréhender rapidement le fonc-
tionnement général et de comprendre chaque détail de chaque fonc-
tionnalité. Ainsi, le prestataire pourra développer l’application en
toute autonomie.

231
Partie II – La conduite des projets Web

Bonne pratique : adapter les spécifications à l’outil choisi


Avec le développement des frameworks et des outils packagés (CMS, boutiques…), il devient
important de rédiger les spécifications « dans le sens de l’outil », une fonctionnalité pouvant être
implémentée de plusieurs façons. Plutôt que de « tordre l’outil », il est donc conseillé de l’installer
tout d’abord puis d’en étudier le fonctionnement (ce qui a été fait lors de l’étape de choix) et,
seulement après, d’effectuer les spécifications. Dans le même ordre d’idée, vous devez adapter la
finesse de vos spécifications en fonction de l’outil utilisé : très fine pour du sur mesure, fine si vous
utilisez un framework spécialisé ; peu détaillée si vous utilisé un outil packagé de type CMS.

Spécifications fonctionnelles (specifications_fonctionnelles.rtf )


Le tableau 9-5 résume les différentes parties constitutives des spécifi-
cations fonctionnelles.

Tableau 9-5
Plan type des spécifications fonctionnelles
PARTIE DESCRIPTIF

Contexte Cette première partie présente l’idée force du projet. On peut facile-
ment la rédiger en synthétisant l’étude d’opportunité ou en reprenant
la section « contexte » de l’étude de faisabilité. Le but est d’expliquer
la raison d’être du projet.
Contraintes Cette partie présente les contraintes liées au besoin fonctionnel et à
fonctionnelles l’organisation de manière à ce que le prestataire comprenne les choix
opérés (taille et nature de l’équipe chargée de l’animation, répartition
géographique, etc.). Par exemple, la création de nombreux formu-
laires de saisie et le recours à un éditeur HTML riche s’expliquera par
le fait que l’équipe animant le site est constituée d’experts de la santé
qui ne possèdent pas de compétences informatiques.
Contraintes Cette partie constitue un mini cahier des charges techniques qui
techniques permet au prestataire réalisant les développements de respecter les
choix opérés lors de l’étude de faisabilité. Elle peut d’ailleurs en
reprendre la section « Présentation de la solution ».
Principe général Pour être efficace, il est important de garder à l’esprit que le presta-
de la future taire ne connaît pas le projet. Un effort de synthèse doit donc être
application réalisé de manière à ne pas le noyer sous un déluge de détails, inuti-
les à ce stade. Pour formaliser cette partie, l’expression du besoin
peut être synthétisée et complétée par l’arborescence générale, le
premier niveau de rubriquage et le premier niveau de la cinématique.
Détail de chaque Cette partie, contrairement à la première, doit être la plus détaillée
fonctionnalité possible. Elle constitue le cœur des spécifications fonctionnelles. En
général, elle se fonde sur la reprise de l’expression du besoin, du
rubriquage, de la description des processus et de la cinématique aux-
quels on ajoute les règles de gestion associées.

232
Chapitre 9 – La conception

Tableau 9-6
Exemple de spécifications fonctionnelles

PARTIE AJOUTÉE LORS DE LA


PARTIE RÉDIGÉE LORS DE L’EXPRESSION DU BESOIN RÉDACTION DES SPÉCIFICA-
TIONS FONCTIONNELLES

FONCTION DESCRIPTION CARACTÉRISTIQUES RÈGLE DE GESTION / CAS


D’UTILISATION

1. Afficher un L’internaute ren- Affichage en moins RAS


formulaire seigne un formu- de 2 secondes avec
d’alerte laire pour être une connexion
alerté dès qu’un ADSL 512 kbps.
bien correspon-
dant à ses critè-
res est disponible
sur le site.
2. Vérification Vérification des Vérification côté En cas de temps de vérifi-
des données données saisies client en moins de cation supérieur à
par les internau- 1 seconde. 2 secondes, affichage d’un
tes. Vérification côté message d’attente en
serveur en moins surimpression avec reste
de 2 secondes de l’écran grisé.
avec une con- Cas 1 – Les données sont
nexion ADSL valides
512 kbps. => un message de confir-
mation est affiché.
Cas 2 – Les données sont
invalides
=> affichage du message
d’erreur en en-tête du for-
mulaire.
+
champs incorrects surli-
gnés en rouge.

Conception technique

La conception technique est l’une des étapes fondamentales du


projet. Si elle est menée avec intelligence, elle permettra de réaliser,
tout au long de la vie du site, des économies très substantielles.
En effet, contrairement aux premiers sites « jetables » dont la main-
tenance s’avérait plus coûteuse sur quelques années que leur redéve-
loppement, les projets Web actuels ont une obligation de rentabilité
et de pérennité. Cet objectif peut être atteint grâce à une conception
technique modulaire.

233
Partie II – La conduite des projets Web

Celle-ci se déroule en trois étapes : la formalisation de l’architecture,


la modélisation puis la rédaction des spécifications techniques
détaillées.

Architecture
L’architecture d’une solution Web est décrite à travers son architec-
ture technique (comprenant elle-même les architectures applicative,
technique et matérielle). Ces différentes « vues » vont de la plus
conceptuelle à la plus concrète.
L’architecture applicative
L’architecture applicative répond à un double enjeu : aider les
concepteurs d’un logiciel à en maîtriser sa complexité ; garantir la
maintenabilité et l’évolutivité de la solution.
Le modèle le plus connu est appelé « architecture à trois niveaux ».
Il comprend :
• le client (le demandeur de ressources) ;
• le serveur d’applications (le serveur chargé de fournir la res-
source mais faisant appel à un autre serveur) ;
• le serveur secondaire (généralement un serveur de base de don-
nées), lequel fournit un service au premier serveur.
Dans un souci de réutilisation et de maintenance, le modèle « cinq
couches » tend à se développer. Il comprend :
• une couche présentation ;
• une couche application ;
• une couche composants métier ;
• une couche d’accès aux données ;
• une couche de stockage des données.
L’architecture applicative est réalisée en interne ou par un cabinet de
conseil en architecture.

Validation du livrable : clarté et précision


Avant de valider le livrable, il faut vérifier que les caractéristiques fondamentales de l’architecture
sont clairement définies :
– synchrone/asynchrone ;
– design patterns associés à chaque couche ;
– niveau de granularité des composants ;
– couplage (couplé/découplé)…

234
Chapitre 9 – La conception

L’architecture logicielle
L’architecture logicielle décrit les différentes applications, leurs
interdépendances et les règles associées. Pour un projet Web, elle
comprend en général :
• un niveau incontournable, à savoir l’infrastructure de base :
– pare-feu ;
– serveur HTTP ;
– serveur de messagerie ;
– serveur d’applications ;
– moteur de recherche ;
– connecteurs base de données ;
– bases de données ;
– système d’exploitation…
• un niveau spécifique (exemple pour un site institutionnel) :
– serveur de publication ;
– serveur de contenu…
L’architecture logicielle peut être réalisée en interne ou par le pres-
tataire qui réalise l’architecture applicative.

Validation du livrable : exhaustivité et précision


Avant de valider le livrable, il est important de vérifier que la liste des logiciels est complète et détaillée.

L’architecture matérielle
L’architecture matérielle décrit les ordinateurs (poste client,
serveurs, etc.) et les réseaux sollicités par la solution. Elle permet de
dimensionner précisément le budget et d’effectuer des choix straté-
giques tels que l’hébergement.
Quand le projet est hébergé en interne, l’architecture matérielle
peut être définie avec la fonction support/exploitation. Elle peut
aussi être confiée à l’hébergeur dans le cas d’un hébergement externe
ou, pour les projets stratégiques, à un prestataire spécialisé assurant
à la fois l’hébergement et l’exploitation.

Validation du livrable : attention au dimensionnement


Avant de valider le livrable, il est important de vérifier que le dimensionnement a été effectué
correctement et que les matériels s’inscrivent logiquement dans le parc machine existant.

La sécurité
Les règles de sécurité précisent trois niveaux : la sécurité physique
(accès à la salle machine, alimentation électrique, incendie,

235
Partie II – La conduite des projets Web

sauvegardes, reprise sur incidents…), la sécurité logique (login/mot


de passe, cryptographie, pare-feu1), la sécurité organisationnelle
(attribution/modification/suppression des droits, procédures,
mesure de vérification, tests, gestion des crises…).
 Pare-feu : système Selon la criticité et l’ampleur du projet, la définition de la politique
de sécurité entre Internet de sécurité peut être confiée à un spécialiste de la sécurité ou à un
et la passerelle réseau qui cabinet de conseil technologique s’il intervient par ailleurs sur les
permet de protéger le
système informatique
autres étapes.
de l’entreprise contre
les intrusions. Validation du livrable : attention à la cohérence
Avant de valider le livrable, il est important de vérifier qu’il est cohérent avec les autres règles
de sécurité en vigueur pour le reste du système d’information.

Modélisation
En France, la méthode de modélisation la plus utilisée reste Merise
(relationnel) bien que des méthodes orientées objet telles qu’UML
(Unified Modeling Language) soient en passe de devenir le stan-
dard, grâce, notamment, aux développements J2EE.
Chaque méthode correspond à une approche conceptuelle et à une
vision différente de la programmation. Merise est plutôt adaptée
aux « petits projets » utilisant des structures de données relation-
nelles et une programmation procédurale. UML est plutôt adaptée
aux « gros projets » utilisant des langages et des structures de
données objet.
Il n’y a donc pas de bonne ou de mauvaise méthode, il y a en
revanche des méthodes plus ou moins adaptées à un type de projet.

236
Chapitre 9 – La conception

Figure 9-12
Exemple de modélisation (partielle) de l’achat d’un livre sur un site Web avec
UML

237
Partie II – La conduite des projets Web

Modèle conceptuel de domaine de niveau 1 (MCD niv. 1)

Modèle conceptuel des traitements (MCT)


Figure 9-13
Exemple de modélisation (partielle) de l’achat d’un livre sur un site Web avec
Merise

238
Chapitre 9 – La conception

Présenter une méthode telle que Merise en quelques lignes n’est pas
possible. Nous ne survolons ici que les livrables essentiels : MCD,
MCT, MOPT, MLD, MPD. Le but est de comprendre à quoi ils
servent et en quoi ils représentent un choix stratégique pour le
projet.

Figure 9-14
Vue d’ensemble et articulation des différents modèles de Merise

Le modèle conceptuel des données


Le modèle conceptuel des données (MCD) permet de formaliser
une représentation claire des données du domaine considéré. Il
définit en outre les relations fonctionnelles existant entre elles. Ce
modèle est de loin le plus important. Il permet aux intervenants
fonctionnels et techniques de se mettre d’accord sur une même
représentation de la réalité. Les éléments utilisés pour la formali-
sation d’un MCD sont les suivants :
• Entité type : définition d’entités (objets physiques ou abstraits)
qui ont des caractéristiques comparables.
• Relation type : définition d’une association qui lie plusieurs
entités types. Signification d’un lien entre deux ou plusieurs
types d’objets.
• Propriété type : définition d’une caractéristique d’un objet ou
d’une association. Une propriété type est elle-même caractérisée
par un type (chiffre ou texte...) et une longueur. L’ensemble des
propriétés types du MCD compose le dictionnaire des données.
• Identifiant : propriété type ou concaténation de propriétés types
qui permet de distinguer une entité parmi toutes les autres dans
une entité type.

239
Partie II – La conduite des projets Web

• Cardinalité minimale : nombre minimal de fois où une entité


est concernée par l’association ; 0 indique que les entités ne sont
pas obligatoirement concernées par l’association.
• Cardinalité maximale : nombre maximal de fois où une entité
est concernée par l’association. N signifie plusieurs fois sans pré-
ciser de nombre. Ce nombre ne peut être égal à 0.
Le modèle conceptuel des traitements
Le modèle conceptuel des traitements (MCT) permet quant à lui de
formaliser les traitements en fonction des événements extérieurs
sans s’intéresser à l’organisation qui régira ces traitements. Il est
moins employé que le MCD. Les éléments utilisés pour la formali-
sation d’un MCT sont les suivants :
• Événement : il peut être interne ou externe au SI ; il s’agit d’un
déclencheur pour le lancement d’une opération ou le résultat
d’une opération à destination du monde extérieur.
• Synchronisation : règle qui indique les événements et l’enchaî-
nement de ces derniers nécessaires au lancement d’une opéra-
tion. Il s’agit d’une expression logique composée essentiellement
de OU et de ET.
• Opération : liste des actions à réaliser si la synchronisation asso-
ciée est réalisée. L’ensemble des actions de l’opération s’exécute
sans interruption ni attente d’événement.
• Émission : expression logique qui indique selon le résultat de
l’opération quels événements internes au SI sont créés.
Le modèle opérationnel des traitements
Le but du modèle opérationnel des traitements (MOPT) est de
préparer les développements. Pour ce faire, il décompose chaque
application en composants dont il précise les données et les traite-
ments (présentation et appel du traitement, informations en entrée
et en sortie, résultat, données internes au traitement, algorithme…).
Le MOPT est obtenu suite à une analyse descendante (décomposi-
tion du résultat en éléments de plus faible granularité) ou ascen-
dante (factorisation des composants utilisés par l’application). Cette
dernière se rapproche de la logique objet. Le MOPT est très impor-
tant car il conditionne directement la maintenabilité et l’évolutivité
de la solution.

240
Chapitre 9 – La conception

Le modèle logique des données


Le modèle logique des données (MLD) se situe à un niveau intermé-
diaire entre le modèle conceptuel et le modèle physique des données.
La réalisation d’un schéma logique des données relationnelles permet
d’obtenir le nom des tables de la base et le nom des champs.
Le modèle physique des données
Le modèle physique des données (MPD) est l’implantation concrète
du MCD dans la base de données cible.

Spécifications techniques
Les spécifications techniques ont pour objectif d’industrialiser les
développements en précisant le cadre et les règles. Elles doivent être
les plus précises possible tout en restant digestes. Les lignes suivantes
détaillent le contenu de chaque partie du livrable.
Spécifications techniques (specifications_techniques.rtf )

Tableau 9-7
Contenu des spécifications techniques

PARTIE DESCRIPTIF

Contexte Cette partie présente l’idée force du projet. Elle peut être facilement
rédigée en reprenant la section « contexte » des spécifications fonc-
tionnelles.
Reprise des Cette partie reprend les spécifications fonctionnelles (contraintes
spécifications fonctionnelles, principe général de la future application, détail de
fonctionnelles chaque fonctionnalité) de manière à ce que les développeurs
puissent comprendre le but de l’application.
Idéalement, le document précise pour chaque fonction principale
la réponse technique. Le recours à la fonction mail() de PHP pour
envoyer un e-mail par exemple.
Principes Le but de cette partie est de présenter le cadre général des
architecturaux développements en détaillant les architectures applicative, logicielle
et matérielle ainsi que la politique de sécurité.
Règles de nommage Cette partie précise les règles de nommage de l’ensemble des
et de codage éléments techniques (API, nom des classes, etc.) et de codage
(gestion des variables, etc.).
Modèles de données Cette partie détaille les différents modèles de données.
Composants Cette partie liste l’ensemble des composants de l’application.
Pour chacun, elle précise : son nom, son rôle fonctionnel, ses
dépendances avec les autres composants, sa dépendance par
rapport au framework technique, les connecteurs utilisés.

241
Partie II – La conduite des projets Web

Tests utilisateurs

Les tests utilisateurs sont essentiels dans la réussite du projet Web.


Les sites étant créés pour les utilisateurs, ce sont eux qui peuvent le
mieux dire si leurs préoccupations ont été bien comprises.
Les tests utilisateurs peuvent être utilisés à chaque phase du projet,
cependant, ils sont incontournables lors de la conception. Nous les
présentons donc dans ce chapitre. Les sections suivantes proposent
un aperçu des types de tests à envisager et des techniques liées.

Survol des principales techniques


Globalement, trois techniques de test sont à retenir dans le cadre
d’un projet Web : les entretiens en face à face, les tables rondes
d’utilisateurs, les questionnaires.
L’entretien en face à face
C’est la technique la plus utilisée car elle est souple et relativement
simple à mettre en œuvre. Les entretiens sont menés individuelle-
ment et se décomposent toujours en quatre étapes :
1. Instauration d’un climat de confiance avec la personne inter-
rogée.
2. La personne interrogée est le maître et le consultant l’apprenti.
Cela force la personne interrogée à expliquer clairement ses atti-
tudes, motivations et actions.
3. Entretien au cours duquel la personne interrogée livre ses infor-
mations au consultant.
4. Le consultant reformule de manière synthétique à l’interviewé ce
qu’il a appris pour valider sa bonne compréhension.
Attention cependant, cette technique peut facilement créer des biais
car elle donne beaucoup plus de pouvoir à la personne interrogée
qu’elle n’en a dans la réalité. Celle-ci peut donc être amenée à suren-
chérir ou à développer des idées auxquelles elle n’aurait pas pensé
dans la réalité. En outre, le rôle de l’intervieweur dans le projet peut
avoir un impact direct sur la qualité des résultats. En effet, si celui-
ci est trop en prise avec le projet ou trop loin des aspects concrets
(rubriquage, processus métier, ergonomie de l’interface…), il risque
de manquer de recul et de laisser passer des idées intéressantes.

242
Chapitre 9 – La conception

Les tables rondes d’utilisateurs


Cette technique est aussi très utilisée car elle peut faire gagner du
temps et n’est pas forcément très onéreuse. Elle repose sur les mêmes
étapes que celles de l’entretien en face à face. Son intérêt et sa prin-
cipale limite résident dans la dynamique de groupe. Cette dernière
a un effet bénéfique : en créant une émulation entre les participants,
elle apporte une exhaustivité impossible à obtenir en face à face.
Cependant, des biais importants peuvent être introduits si un ou
plusieurs participants prennent le dessus sur les autres. Cette tech-
nique demande l’intervention d’un professionnel expérimenté, mais
ce dernier peut également avoir un impact direct sur la qualité des
résultats, pour les mêmes raisons que celles évoquées précédem-
ment. Pour plus de détails, voir la section « Les tables rondes d’utili-
sateurs », chapitre 5. Le déroulement complet y est présenté.
Les questionnaires
Les questionnaires, grâce à leur dimension quantitative, sont une
technique complémentaire qui permet de valider les idées ou les
constats recueillis avec des approches plus qualitatives telles que les
entretiens en face à face et les tables rondes d’utilisateurs. Ils sont en
général autoadministrés. De nombreuses solutions permettent de
les construire en ligne et de les diffuser auprès d’un échantillon soit
fourni par l’éditeur soit apporté par l’entreprise. La plupart de ces
solutions intègrent un module d’analyse et de reporting. L’avantage
des questionnaires est qu’ils ne consomment pas trop de temps. En
revanche, les résultats obtenus sont très limités.

Les différents tests


Dans l’idéal, chaque test présenté dans les sections suivantes devrait
être réalisé pour chaque projet Web. Quand cela n’est pas possible,
le mieux est de choisir le test en fonction de la nature du projet.
Le test du concept
Ce test a pour principal intérêt de valider les grandes options de
conception avant de commencer la conception technique. Dans la
plupart des cas, des ajustements seront nécessaires. Selon l’ampleur
de ces ajustements, il pourra être utile de tester à nouveau le
concept.
L’idéal est que le test du concept ait lieu avant la validation de la
cinématique. Il permet principalement de valider la réponse aux
attentes exprimées et l’organisation générale. En fonction de la
nature du projet, les objectifs seront bien sûr affinés : validation de

243
Partie II – La conduite des projets Web

l’accès aux services dans le cas d’un portail, validation du rubriquage


dans le cas d’un site de marque, validation de la composition des
fiches produit et du processus d’achat dans le cas d’un site
marchand… L’impact de ce test sur le projet est très fort puisqu’il
peut aller jusqu’à démontrer la nécessité de reconcevoir ce dernier.
Cependant, ce risque est limité par l’association des utilisateurs à
chaque étape en amont.
La technique la plus adaptée est la table ronde d’utilisateurs au cours
de laquelle certaines parties de la cinématique sont présentées. Il
faut, à cette occasion, prendre soin d’expliquer que les supports
présentés ne sont pas représentatifs du design final. Un exercice inté-
ressant, consiste à hiérarchiser chaque bloc (navigation, service,
contenu...) pour déterminer l’importance attribuée à chaque
élément.

Validation du livrable : priorité à la clarté


Le test du concept est validé après avoir vérifié :
– qu’une tendance claire se dégage ;
– que chaque élément bloquant est décrit et motivé.

Ce travail doit être confié à un prestataire spécialisé ou, à défaut, au


prestataire qui réalise la conception.
Le test de la maquette ou du prototype
Ce test est à mener avant de valider définitivement la maquette
HTML ou le prototype. Il a pour objectif de valider l’organisation
et l’ergonomie générales. Le verdict final doit être l’acceptation ou
un rejet motivé.
Dans le cas d’une maquette HTML, la technique la plus adaptée est
la table ronde d’utilisateurs au cours de laquelle une démonstration
sera réalisée. Dans certains cas (intranet, portail, etc.), il peut être
intéressant de compléter la table ronde par un questionnaire en
ligne. Ce test demande plus de préparation que le précédent,
notamment en ce qui concerne la démonstration. En effet, pour que
cette dernière soit le plus réaliste possible, il est en général nécessaire
de définir un scénario (achat d’un produit, travail collaboratif, etc.)
puis de créer de nouvelles pages HTML pour le simuler.
Dans le cas d’un prototype, la technique la plus adaptée est l’entre-
tien en face à face au cours duquel les utilisateurs devront essayer de
réaliser un certain nombre d’objectifs (vérifier et modifier l’état des
commandes, ajouter un article, etc.). Le but est de valider l’enchaî-

244
Chapitre 9 – La conception

nement logique des tâches et l’ergonomie générale. Le travail de


préparation est important puisqu’il faut définir des scénarii précis
ainsi qu’un questionnaire autoadministré permettant d’évaluer le
niveau d’acceptation du prototype. Il ne faut pas non plus sous-
estimer l’importance de la logistique : l’installation ou l’accès au
prototype depuis une dizaine de postes centralisés dans la même
salle ne s’improvise pas !
Dans tous les cas, l’impact de ce test sur le projet est fort puisqu’il
peut aller jusqu’à une remise en cause de l’organisation générale.

Validation du livrable : des éléments bloquants motivés


Le test de la maquette HTML ou du prototype est validé après avoir vérifié :
– qu’une tendance claire se dégage ;
– que chaque élément bloquant est décrit et motivé.

Ce travail doit être confié à un prestataire spécialisé ou, à défaut, au


prestataire qui réalise la conception. Cette dernière solution n’est
cependant pas idéale puisqu’on ne peut pas être juge et partie : le
concepteur aime rarement entendre que son œuvre est incompré-
hensible !
Le test d’usabilité

Repère : le test en laboratoire augmente la satisfaction utilisateur


Selon J. Nielsen, l’analyse d’un site, en laboratoire et avec des utilisateurs, permet, en moyenne,
de passer d’un indice de satisfaction utilisateurs de 30 % à 82 %.
Source : Useit, http://www.useit.com, sur la base de mille tests en laboratoire.
Ce test est à réaliser en complément du test de la maquette ou du
prototype soit parce que le projet est complexe ou stratégique soit
parce que les premiers tests ont révélé des faiblesses ergonomiques.
L’objectif du test d’usabilité est de déterminer les frictions qui appa-
raissent lors de l’utilisation du site et, si possible, d’en comprendre
les causes. L’issue de ce test est soit une acceptation soit un rejet
motivé.
La technique la plus adaptée est l’entretien en face à face au cours
duquel l’utilisateur essaie d’atteindre des objectifs en respectant des
scénarii imposés (modifier une fiche produit en passant par la
recherche, trouver une information précise sans utiliser la recherche,
etc.). À la fin, un questionnaire autoadministré sert de pense-bête à
l’utilisateur qui est invité à expliquer les problèmes rencontrés et ce
qui lui semble en être la cause.

245
Partie II – La conduite des projets Web

Notons que dans le cas d’une maquette HTML, le travail de prépa-


ration peut s’avérer très lourd (création de plusieurs dizaines de
pages).
À ce stade, l’impact du test est, la plupart du temps, limité à des
éléments spécifiques (recherche, processus et interface de saisie ou
de validation…).

Validation du livrable : des éléments bloquants motivés


Avant de valider ce test, il est nécessaire de vérifier :
– qu’une tendance claire se dégage ;
– que chaque élément bloquant est décrit et motivé.

Ce travail doit être confié à un prestataire spécialisé.

246
Chapitre 9 – La conception

Pour aller plus loin

Ouvrages
Joseph Gabay
Merise, vers OMT et UML, un guide complet avec études de cas
Interéditions – 2007 – ISBN : 978-2225830037
Jodie Dalgleish
Customer-effective Web Sites
ft.com – 2000 – ISBN : 978-0130878274
Jesse James Garrett
The elements of user experience, The User-Centered Design for the Web
New Riders – 2002 - ISBN : 978-2708124738
Sébastien Bailly
Bien écrire pour le Web
OEM – 2003 – ISBN : 978-2746404854
Hubert Tardieu, Arnold Rochfeld, René Colletti
La méthode Merise
Éditions d’Organisation – 2000 – ISBN : 978-2708124738
Céline Labbé
Modéliser les données
Éditions Pratik – 2005 – ISBN : 978-2922889048
Chromatic et Michel Casabianca
Extreme Programming
O'Reilly – 2005 – ISBN : 978-2841773589
Jean-Louis Bénard, Laurent Bossavit, Régis Médina et Dominic
Williams
Gestion de projet : eXtreme Programming
Éditions Eyrolles – 2004 – ISBN : 978-2212115611
Russ Miles et Kim Hamilton et Hervé Soulard
Introduction à UML 2
O'Reilly – 2006 – ISBN : 978-2841774210

247
Partie II – La conduite des projets Web

Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates et Marie-


Cécile Baland
Design patterns
O'Reilly – 2005 – ISBN : 978-2841773503

Laurent Debrauwer
Design Patterns - les 23 modèles de conception : descriptions et solution
illustrées en UML 2 et Java
Éditions ENI – 2007 – ISBN : 978-2746038875

Pascal Roques
UML
Éditions Eyrolles – 2005 – ISBN : 978-2212117257

Pascal Roques
UML 2 par la pratique : Études de cas et exercices corrigés
Éditions Eyrolles – 2006 – ISBN : 978-2212120141

Benoît Charroux, Aomar Osmani et Yann Thierry-Mieg


UML 2, 2e édition
Pearson Education – 2008 – ISBN : 978-2744072871

Sites
BPMS.info - La bible du BPM
http://www.bpms.info/
Useit.com - L’ergonomie selon Jakob Nielsen
http://www.useit.com/
Open Web Group - Des standards compréhensibles !
http://openWeb.eu.org/
abcdRFC - Toutes les RFC en français
http://abcdrfc.free.fr/
UML - UML en français
http://uml.free.fr/
Template Monster - Un site designer en 3 clics
http://www.templatemonster.com/
Redaction - Le site des spécialistes de l’information en ligne
http://www.redaction.be

248
Chapitre 9 – La conception

Avis d’experts

Refondre son site Web


avec succès
La plupart des entreprises ont déjà créé un site Web. L’arrivée à maturité des tech-
nologies et des mentalités est l’occasion de le refondre en profondeur. Pour réussir
cette opération à hauts risques, l’implication et le dialogue avec les acteurs sont
indispensables, dès le début du projet.
Clarifier la commande de la direction
Jusqu’en 1999, les sites étaient refondus pour profiter de nouvelles fonctionnalités
comme les pages dynamiques, le streaming audio ou les animations flash. Aujourd’hui,
avec la maturité des technologies, l’enjeu est plutôt une meilleure réponse aux besoins
fonctionnels des utilisateurs, résume Olivier Bourrasse, directeur architecture du
système d’information de Radio France International. Malheureusement, les
objectifs d’une refonte ne sont pas toujours aussi clairs. Ce qui conduit Isabelle
Blanc, chef de projet Web à l’INRA, à recommander de préciser la commande de la
direction avant de lancer le projet : quel est l’objectif ? Quelle est la profondeur de la
refonte ? S’agit-il d’un lifting graphique ou plutôt de la remise à plat des contenus et de
leur organisation ?… La réponse à ces questions amène la direction à définir une
orientation stratégique claire qui doit aller jusqu’aux choix éditoriaux ou fonction-
nels. Dans le cas d’un intranet, elle devra par exemple orienter le projet soit vers
un support de communication soit vers un outil de travail. Loin d’être anecdo-
tique, ce positionnement impactera fortement toute la suite du projet, y compris
les choix techniques et organisationnels.
Impliquer les parties prenantes dès le début
Un projet de refonte est éminemment difficile car, s’il s’appuie sur un existant, il
devra souvent faire mieux avec moins tout en ménageant les susceptibilités des
contributeurs pour ne pas les démotiver. Le chef de projet, véritable visionnaire,
doit donc à la fois convaincre sa direction et faire adhérer les différents interve-
nants. Pour y parvenir, sa meilleure arme est l’implication régulière de tous les
acteurs dans des séances de travail dès le début du projet : expression des besoins,
définition de l’arborescence, présentation des solutions envisageables… Après
10 mois et plus de 60 interviews, nous sommes convaincus que ce long cheminement
laisse le temps à chacun de bien comprendre l’intérêt de la refonte, facilite l’acceptation
des nouvelles solutions et balaye les doutes. C’est donc un facteur clé de succès, précise
Isabelle Blanc. Car le principal risque d’une refonte est la perte d’adhésion des

249
Partie II – La conduite des projets Web

contributeurs. Maintenir la motivation passe également par des séances d’information


régulières et des points fréquents avec la direction générale au cours desquels le chef de
projet doit concrétiser son travail, au travers d’une cinématique par exemple, ajoute
Isabelle Blanc.
S’appuyer sur un pilote
Un avis partagé par Olivier Bourrasse qui estime que la réalisation d’un pilote
portant sur l’une des fonctionnalités est un investissement inévitable, à intégrer
dans la démarche projet standard : Cela permet de tester toute la chaîne en interne
comme à l’externe, de la production du contenu à son affichage sur le site. C’est aussi
un bon moyen de concrétiser ce qui est souvent trop conceptuels pour les utilisateurs et
la direction : positionnement, définition de l’offre, arborescence, rubriquage, etc. Du
coup les acteurs sont plus impliqués car ils visualisent mieux les possibilités. Quand
c’est possible, cette démarche doit être poussée encore plus loin au travers d’une
version bêta qui donnera l’occasion à un échantillon représentatif d’utilisateurs de
critiquer le site avant sa mise en ligne officielle.
Prendre le temps d’évaluer l’impact de la refonte
Une refonte qui tire vraiment partie de l’existant est souvent plus longue qu’un
nouveau projet « from scratch ». Il est donc indispensable d’évaluer la valeur de
l’existant – plate-forme technique, contenu, etc. – en s’appuyant sur l’analyse
conjointe des statistiques de fréquentation et de l’expression des besoins utilisa-
teurs. L’implication de ces derniers est essentielle, recommande Olivier Bourrasse.
À l’inverse, la mise en place d’un nouvel outil pose souvent des problèmes d’orga-
nisation : modification des tâches des contributeurs existants, suppression de
certains rôles tels que les webmestres techniques, etc. Cette dimension ne doit pas
être négligée, son coût pouvant très vite dépasser celui induit par la technique.
Attention également aux changements de technologie qui se traduisent souvent par une
nouvelle organisation de la maintenance nécessitant la formation de l’équipe interne et
parfois le renfort de prestataires extérieurs, conclut Olivier Bourrasse.
Article paru sur http://www.indexel.net

250
Chapitre 10

La réalisation

Figure 10-1
Les différentes étapes de la réalisation

La phase de réalisation consiste soit à mettre en œuvre un progiciel soit à


réaliser des développements spéciques. Normalement, l’étude de faisabilité
a tranché entre ces solutions. Dans le premier cas, les efforts sont limités
puisqu’il ne s’agit, en théorie, que de paramétrer l’outil, développer quel-
ques modules et créer les templates. Dans le second cas, les efforts sont
importants et demandent un bon suivi du projet.
Dans tous les cas, cinq étapes sont incontournables : la production des
contenus, le développement (ou le paramétrage), les tests internes, la
reprise de l’existant, et la documentation. Ce chapitre détaille ces diffé-
rentes étapes.

251
Partie II – La conduite des projets Web

Production des contenus

La production des contenus nécessite souvent, par son ampleur,


l’implication de plusieurs services ou directions. Ainsi, dans le cas
d’un catalogue, il est souvent nécessaire de travailler à la fois avec la
direction commerciale (tarifs, remises, etc.), la direction marketing
(promotions, logos, visuels) et la direction juridique (CGV, CNIL,
etc.). Les contenus d’un « simple » site institutionnel demanderont
quant à eux la coopération de la direction administrative et finan-
cière pour les chiffres clés financiers, de la direction des ressources
humaines pour les chiffres clés de la politique de recrutement et les
contenus liés à la gestion des carrières, de la direction de la commu-
nication pour l’historique et la synthèse d’activité…

Contenus éditoriaux
La production des textes d’un site demande une grande rigueur et
beaucoup de professionnalisme car écrire pour le Web est difficile :
pour que la lecture soit agréable, le calibrage doit être court, la
titraille incitative et le style très dynamique. Autant de contraintes
qui ne facilitent pas la rédaction !
Par ailleurs, la nature du site est déterminante. Dans le cas d’un site
marchand, les textes, proches du publireportage, ont pour objectif
d’accrocher le visiteur et de l’inciter à acheter. Dans un site institu-
tionnel, le rédactionnel véhicule une image positive de l’entreprise,
rassure et valorise. Dans le cas d’un portail d’entreprise, l’objectif
du contenu éditorial est d’augmenter la productivité et de créer un
cadre favorable pour faire passer les messages stratégiques de la
direction… À chaque fois, le ton et l’angle employés seront diffé-
rents.
La pratique courante est donc de dissocier le contenu rédactionnel
appelé à durer de celui plus ponctuel tel que les actualités ou les
promotions. Cela permet de répartir au mieux le travail entre
l’équipe interne et les prestataires, en fonction des compétences de
chacun.
Produire les textes
Cette étape doit être préparée avec soin car un nombre important
d’acteurs intervient. Le travail consiste à organiser puis à réaliser la
production des textes en tenant compte de la ligne éditoriale définie
dans la charte éditoriale.

252
Chapitre 10 – La réalisation

Le chef de projet ou le directeur éditorial prépare pour chaque


rédacteur et chaque valideur :
• la liste des textes classés par rubriques/sous-rubriques/pages ;
• le calibrage, l’angle, le ton de chaque article ;
• le mode de livraison (via le CMS, par FTP ou par e-mails…) ;
• les standards à respecter (Word 97, RTF, appliquer les feuilles
de style ou non…) ;
• une liste des intervenants (leurs coordonnées, qui rédige, qui
réécrit, qui valide…),
• la date de livraison des textes, etc.
Une fois les textes rédigés et collectés, il est souvent nécessaire de
procéder à une légère réécriture et/ou de retravailler la titraille de
manière à homogénéiser les différents styles.
Puis, les textes sont validés, plus ou moins vite, en fonction du type
de contenu et de la culture de chaque entreprise.
Enfin, les textes sont soit saisis manuellement dans le système soit
intégrés par un procédé automatique défini au préalable. Cela peut
être l’occasion de tester l’outil de gestion de contenu retenu. Cette
dernière solution évite l’étape fastidieuse de ressaisie, permet de
former efficacement les futurs utilisateurs et réduit les coûts. Cepen-
dant, il n’est pas recommandé de l’utiliser sur des projets straté-
giques car des risques réels existent. Un dysfonctionnement grave
peut par exemple bloquer le processus de validation, nécessitant
alors de réorganiser toute la production des contenus.

Validation du livrable : attention au calibrage et à la ligne éditoriale


Avant de valider les textes, il faut vérifier qu’ils respectent :
– le calibrage ;
– la ligne éditoriale ;
– la règle de nommage ;
– les standards techniques.

Cette tâche peut être réalisée en interne ou confiée à un prestataire


spécialisé en création de contenu éditorial destiné au Web.
Réaliser les traductions
Les textes d’un site ou d’un intranet sont souvent rédigés soit en
plusieurs langues soit en anglais. De nombreuses études ont montré
que les lecteurs, comme les utilisateurs, ne lisent que dans leur

253
Partie II – La conduite des projets Web

langue maternelle. Il est donc nécessaire de traduire les textes si l’on


veut que les lecteurs s’y intéressent. Les traductions peuvent être
réalisées de deux manières.
La première consiste à remplacer les textes directement dans les
pages statiques via un éditeur HTML puis à les renommer ou,
quand un CMS existe, à saisir les traductions directement dans
l’outil.

Figure 10-2
http://www.anyword.fr

Des prestataires tels que Anyword peuvent prendre en charge la totalité des
opérations de traduction.

La deuxième méthode, plus classique, consiste à traduire des fichiers


Word en remplaçant au fur et à mesure le texte original. L’idéal est
de prévoir la première solution et, en cas de problème, de se replier
sur la deuxième. Cette tâche est confiée de préférence à un presta-
taire spécialisé.

Validation du livrable : des tests aléatoires


Avant de valider les traductions, il est important de réaliser des tests aléatoires sur 10 % à 20 %
des pages de manière à en vérifier la qualité.

254
Chapitre 10 – La réalisation

Contenus graphiques
Les contenus graphiques d’un site jouent deux rôles, d’une part, ils
assurent une navigation agréable et intuitive et, d’autre part, ils illus-
trent le propos. Leur production peut demander, dans certains cas,
un effort très important, notamment lors de la création d’un cata-
logue. Le niveau de qualité exigé est alors très élevé, car sur Internet,
les photos participent à la vente autant que le prix ou les informa-
tions produit.
Produire les images
Cette tâche consiste à produire l’ensemble des images qui compo-
sent le site. On distingue, en général, les images liées à la navigation
(bandeau, boutons, pictogrammes…) des images liées au contenu
(schémas, photos des produits, etc.). Dans certains cas, une biblio-
thèque d’illustrations est créée au même moment.
Pour créer les images de navigation, le Web designer applique à des
listes fournies par le chef de projet les masques Photoshop présents
dans la charte graphique.
Pour les images liées au contenu, plusieurs possibilités sont envisa-
geables. Quand l’entreprise dispose d’une photothèque, le Web
designer réalise une première sélection de visuels qui est ensuite
validée par l’entreprise. Les visuels sont alors retravaillés dans le style
défini par la charte graphique. Quand l’entreprise ne dispose pas de
photothèque, le Web designer choisit les visuels dans un stock
photos (de type Image Bank, Getty, etc.). Après présentation et
étude du devis, l’entreprise valide ou modifie la sélection.
Dans le cas d’un catalogue pour lequel les visuels produits n’existent
pas ou seulement partiellement, deux solutions sont possibles. Si le
catalogue est peu volumineux et les produits simples à photogra-
phier, le Web designer ou le directeur artistique peuvent avantageu-
sement réaliser les prises de vue. En revanche, quand le catalogue est
volumineux et les produits complexes à photographier (matières,
effets de transparence, etc.), il est nécessaire de faire appel à un
spécialiste. Il peut s’agir d’un photographe indépendant ou d’un
prestataire spécialisé.
Les illustrations sont créées par le directeur artistique. Dans
certaines circonstances, ce dernier peut faire appel à un illustrateur.
Dans les deux cas, l’entreprise valide une esquisse (appelée rough)
des différentes illustrations avant qu’elles ne soient produites.

255
Partie II – La conduite des projets Web

Validation du livrable : des images bien nommées


Avant de valider les images, il est important de vérifier :
– la qualité de leur optimisation ;
– l’application de la règle de nommage.

La production des images peut être réalisée en interne. Elle peut


aussi être confiée soit au prestataire qui a réalisé la charte graphique,
soit au prestataire en charge de la réalisation du site. Dans le premier
cas, des gains de temps et des économies sont possibles car le pres-
tataire possède une excellente connaissance du dossier et est donc
très efficace. Dans le deuxième cas, une grande souplesse est
apportée, ce qui facilite le travail d’intégration et, parfois, limite les
risques de tensions entre prestataires graphique et technique.
Produire les animations
Cette étape consiste à produire les éléments multimédias du site et
notamment les animations Flash. Bien que pour la plupart des sites
ces contenus soient moins fondamentaux, ils demandent cependant
un travail important. Pour créer une animation, la première tâche
est de formaliser un storyboard très précis. Celui-ci détaille,
séquence par séquence, les éléments visuels, sonores et les interac-
tions envisagées. Il faut également préciser les dimensions souhai-
tées en pixel, savoir si l’animation est prévue pour le Web ou pour
CD-Rom et, dans le cas d’une animation pour CD-Rom, si elle doit
être resizable ou non, en fullscreen ou non…

Figure 10-3
Exemple de storyboard

256
Chapitre 10 – La réalisation

Une fois le storyboard validé, le travail de production peut débuter.


Attention, il sera très difficile de revenir sur cette validation. L’inser-
tion ou la suppression d’un élément de l’animation impliquent de
décaler tous les éléments suivants dans la timeline, ce qui prend un
temps considérable. Le directeur artistique créé l’animation et la fait
valider par l’entreprise. Après avoir réalisé les nécessaires ajuste-
ments (réglage des temporisations, etc.), il créé ou commande la
bande son puis la « cale » sur l’animation. L’entreprise peut alors
valider l’animation finale. Il ne reste plus au directeur artistique qu’à
produire l’animation aux formats souhaités.

Validation du livrable : attention aux sources


Avant de valider les animations, il est important de vérifier :
– leur poids ;
– la configuration matérielle requise (processeur, mémoire vive) ;
– que vous disposez des fichiers source (.FLA)

Cette étape doit être confiée à un spécialiste, studio de design,


graphiste indépendant ou agence interactive
Storyboard (storyboard.rtf )

Développements

Avec la complexité croissante des projets Web, une plus grande


préparation de l’étape de développement est aujourd’hui nécessaire.
Le but est d’éviter à tout prix « l’effet tunnel » qui conduit tant de
projets à ne pas respecter la charge et les délais impartis. Le chef de
projet technique prend ici toute sa dimension.
Cette étape est composée de trois tâches principales : le lotissement,
la réalisation des développements et l’exécution des tests.

Lotir les développements


L’une des principales difficultés de la phase de réalisation est de
respecter le planning de développement car de nombreux problèmes
non identifiés peuvent apparaître à ce moment-là. Le lotissement
permet de limiter ce risque en supprimant les goulots d’étrangle-
ment et en rendant autonomes les intervenants.
Cette tâche consiste à diviser les développements en lots qui pour-
ront être développés indépendamment par plusieurs développeurs

257
Partie II – La conduite des projets Web

ou plusieurs équipes de développeurs. Le but poursuivi est de


limiter les risques et de favoriser la production d’un code de qualité
et documenté. En effet, en divisant le travail, le lotissement oblige
chaque développeur à créer un code compréhensible par son voisin,
donc un code cohérent et bien documenté qui facilite le travail
d’intégration. Cette approche contribue pour une grande part à la
simplification de la maintenance du site, et donc permet de réduire
considérablement le coût de possession.
Le lotissement constitue un excellent outil de gestion de projet. Il
donne de la visibilité à l’avancement réel des développements et
permet de faire un point hebdomadaire constructif.

Validation du livrable : attention à la prise en compte de la technologie


Avant de valider le plan de lotissement, il est important de s’assurer qu’il tient compte des contraintes
du projet (planning, taille des équipes, etc.) et de l’architecture technique. Cette dernière peut, en
effet, décider de l’organisation du projet. Entre une architecture à 3 niveaux et une architecture orien-
tée service (type SOA), l’organisation générale du projet et le lotissement seront très différents.

Le plan de lotissement est confié soit au prestataire qui intervient


comme assistant à la maîtrise d’ouvrage soit au prestataire en charge
des développements. L’intérêt de ce dernier cas est qu’il limite les
échappatoires en cas de dépassement de planning, et donc les
discussions infinies sur la responsabilité de chacun.
Plan de lotissement (plan_lotissement.rtf )

Développer les lots


Chaque lot est développé en fonction des spécifications détaillées et
du plan de lotissement. La durée de cette tâche est très variable selon
la nature du projet et de la solution retenue. Un site institutionnel
qui s’appuie sur des briques logicielles existantes (pour la gestion de
contenu et le front-office par exemple) demandera peu de dévelop-
pement par rapport à un portail d’entreprise développé sur mesure.
Le choix du mode contractuel de développement est donc impor-
tant. Il s’agit de choisir entre forfait et régie.
Le forfait possède l’avantage indéniable d’engager le prestataire en
cas de dépassement financier ou de délais. Il est adapté aux projets
dont le périmètre est clairement défini. C’est aussi une solution
confortable pour décharger la direction informatique qui ne peut
pas toujours prendre en charge des projets de développement trop
lourds. Enfin, le forfait peut être envisagé lorsque l’entreprise ne
possède pas les compétences techniques nécessaires en interne.

258
Chapitre 10 – La réalisation

La régie apporte de son côté plus de souplesse, notamment lorsque


les projets sont mal définis ou que le besoin porte sur un ensemble
de petits projets qui nécessitent les mêmes compétences techniques.
C’est aussi un bon outil de formation lorsque les équipes fonction-
nent bien, un prestataire extérieur pouvant apporter son expertise et
la transmettre à ses collègues en interne. Mais attention, la régie
n’étant qu’une obligation de moyens, l’entreprise s’expose à des
dérapages de planning et de charge importants.
En résumé, cette tâche peut être réalisée en interne avec l’équipe de
l’entreprise ou par un prestataire en régie. Elle peut aussi être avan-
tageusement confiée à un prestataire sous forme de projet au forfait.

Réaliser les tests unitaires


Cette tâche consiste à tester les développements de chaque lot pour
s’assurer de leur conformité avec les spécifications détaillées. Elle est,
en général, réalisée par le chef de projet technique.

Bonne pratique : remonter les anomalies dans Mantis


Il est fortement recommandé d’utiliser un bug tracker pour remonter les anomalies liées aux tests
internes. De nombreuses solutions sont disponibles même si les trois principaux leaders sont Man-
tis (http://www.mantisbt.org), Trac (http://trac.edgewall.org) et BugZilla (http://www.bug-
zilla.org). Il existe également quelques solutions en ligne.

Intégrer les lots


Il s’agit de regrouper les différents lots développés en un ensemble
homogène et fonctionnel. Si l’on considère que la gestion de la
mailing list et la gestion des utilisateurs sont des lots différents, alors
l’intégration consiste à regrouper les différents programmes qui les
composent en un programme unique.
L’intégration est réalisée par l’équipe en charge des développements.

Conduire les tests d’intégration


Ces tests sont fréquemment « oubliés » de manière à rattraper le
retard pris lors des phases amont du projet. Ils constituent pourtant
une étape très importante censée garantir la complétude et la qualité
des développements. Résultat, la recette client se déroule mal.
Celui-ci perd confiance et commence à penser que décidemment
rien ne fonctionne. Il arrête la recette en plein milieu et demande au
prestataire de tout corriger… Pour éviter ce genre de situation,
n’oubliez pas d’indiquer dans le contrat les modalités de déroule-

259
Partie II – La conduite des projets Web

ment de la recette et notamment le seuil à partir duquel la recette est


stoppée (trois anomalies bloquantes, par exemple).
Cette tâche est, en général, réalisée par le chef de projet technique.

Documentation

La documentation est souvent considérée, côté client comme côté


prestataire, comme étant secondaire : soit le budget ne permet de lui
attribuer que quelques jours, soit la charge est déjà dépassée et alors
« perdre du temps avec la documentation »…
C’est pourtant sur elle que s’appuient les supports de formation.
C’est aussi vers elle que les utilisateurs se tourneront au quotidien.
Entre quelques jours de formalisation « à chaud » et une charge
annuelle de plusieurs mois homme passées à réexpliquer à chaque
nouveau collaborateur le fonctionnement de l’application… le
choix devrait pourtant être vite effectué !
Rédiger le manuel d’exploitation
Cette tâche consiste à rédiger le manuel d’exploitation de l’applica-
tion qui comprend des informations sur :
• la mise en service ;
• l’exploitation régulière ;
• l’interruption ou la reprise d’exploitation ;
• les consignes liées à la sécurité.
Il est en général rédigé par le chef de projet technique.

Validation du livrable : complet et compréhensible


Avant de valider le manuel d’exploitation, il est important de vérifier qu’il est formulé de façon
claire et simple et que chaque action est décrite en détail. Dans le cas d’un projet stratégique, il
n’est pas inutile de le faire lire par plusieurs futurs utilisateurs de manière à vérifier qu’il est com-
préhensible et complet. .

Rédiger le manuel utilisateurs


Cette tâche consiste à rédiger le manuel utilisateur, qui comprend
en général une description de chaque fonctionnalité (explication
écrite, une ou plusieurs captures d’écran…) ainsi que des processus
types (ajout d’une fiche produit, validation d’un achat…).
Elle est réalisée, selon la nature du projet, par le chef de projet tech-
nique ou fonctionnel.

260
Chapitre 10 – La réalisation

Validation du livrable : votre boulangère doit s’en sortir !


Un bon manuel utilisateurs est construit sur un « pas à pas » décrivant étape par étape toutes les
actions à réaliser à la fois en image et de manière textuelle. Il doit être tellement simple et élémentaire
que même votre boulangère devrait pouvoir réussir à mettre en ligne un contenu en le suivant !

Reprise de l’existant

Les projets Web étant de plus en plus des deuxième ou troisième


versions de site, la reprise de l’existant est une étape désormais
incontournable. À tel point qu’elle détermine parfois la faisabilité de
certains aspects des projets et peut même influencer les choix de
solution lors de l’étude de faisabilité. En effet, la reprise de l’existant
est une étape qui peut être très « lourde » si le système précédent n’a
pas été conçu en accord avec les standards techniques et l’ouverture
nécessaires. Une des problématiques courantes est, par exemple, de
récupérer les milliers de pages HTML statiques produites depuis
plusieurs années pour les insérer dans la base de données de l’outil
de gestion de contenu. La question fondamentale est alors de savoir
quelle technique employer. Il est parfois préférable d’effectuer une
ressaisie manuelle, notamment lorsqu’on profite de cette tâche pour
modifier le contenu. Dans d’autres cas, la reprise peut être automa-
tisable à un moindre coût.

Préparer la reprise
Cette tâche consiste à déterminer la meilleure méthode de reprise
pour chaque élément présent dans le nouveau système. Elle s’appuie
sur l’analyse réalisée lors de l’étude de faisabilité dans laquelle les
procédés envisageables sont listés. Dans le cas d’une reprise automa-
tisée, le chef de projet, après avoir confirmé la liste des éléments à
reprendre, configure un environnement de production identique à
celui existant et récupère un jeu de données représentatives. Il
analyse seul ou avec l’aide d’un consultant technique la méthode de
production et le format de stockage de chaque donnée. Sur cette
base, il imagine le procédé le plus efficace pour reprendre les
données et les injecter dans le nouveau système. Le chef de projet
réalise alors un test de manière à garantir la faisabilité de sa solution.
Si le test est concluant, il formalise un modus operandi qui sera
utilisé lors de la mise en œuvre. Pour la reprise manuelle, le chef de
projet procède globalement de la même manière : analyse des
données, définition d’une méthode de ressaisie, test, formalisation

261
Partie II – La conduite des projets Web

du modus operandi. Les points importants sont alors le nombre de


contributeurs, le nombre de profils, la durée de la tâche et l’utilisa-
tion ou non de l’interface de la nouvelle application. Ce dernier
point est important car les interfaces Web sont souvent conçues
pour une utilisation quotidienne et régulière. Elles sont par consé-
quent rarement adaptées à une saisie en masse.
Plan de reprise de l’existant (plan_reprise_existant.rtf )

Réaliser la reprise
Il s’agit de mettre en œuvre les procédés définis lors de l’étape précé-
dente puis de tester le résultat. Un travail de développement est
souvent nécessaire pour généraliser le procédé de reprise automatisé
à toutes les données concernées. La reprise manuelle a, quant à elle,
souvent commencé au même moment que les développements de
manière à disposer des données pour les tests et la recette.

Hébergement

Le choix du prestataire et du type d’hébergement ne doit pas être


pris à la légère : ils impliquent des coûts récurrents et il n’est jamais
simple de quitter un hébergeur pour un autre.

Les formes d’hébergement


Il existe quatre grandes formes d’hébergement, de la solution
mutualisée au hosting de son propre serveur dans un data center
offrant des prestations d’infogérance.
Mutualisé
C’est la formule de loin la plus abordable. Pour quelques euros par
mois, des centaines d’hébergeurs vous offrent plusieurs centaines de
méga-octets d’espace disque et une bande passante illimitée.
Les avantages de ces offres sont, outre le prix, un trafic souvent illi-
mité (ce qui évite bien des surprises !), de nombreux services associés
tels que liste de diffusion, webmail, etc. fournis en standard. Les
contraintes d’exploitation de ce type de serveur imposent aux héber-
geurs de s’appuyer sur un cadre de développement mature et
pérenne. C’est un avantage certain pour vous car les choix tech-
niques structurants sont réalisés de facto.

262
Chapitre 10 – La réalisation

Les contreparties sont parfois un mauvais temps de chargement dû à


un CPU et une mémoire vive saturés et un débit rapidement limité,
sans parler des contraintes techniques ne favorisant pas les réponses sur
mesure et encore moins l’évolution du site (impossibilité d’utiliser le
dernier CMS à la mode, par exemple, car PHP 5 n’est pas disponible).
Virtualisé
L’hébergeur vous alloue un quota de disque dur, une bande passante,
un CPU, etc., d’un serveur sur lequel d’autres clients sont hébergés.
Le principal avantage par rapport à l’herbergement mutualisé est
l’étanchéité entre votre espace et celui des autres clients. Ainsi, si le
site de votre voisin plante, cela n’aura aucun impact sur le vôtre. Un
autre avantage est qu’il vous offre souvent les mêmes libertés que sur
un serveur dédié : choix de la distribution du système d’exploita-
tion, gestion via un logiciel type Plesk ou cPanel.
Ce type d’hébergement ne présente pas vraiment de contraintes
mais il n’est pas adapté à tous les projets. Une boutique en ligne à
forte activité aura, par exemple, intérêt à s’offrir un serveur dédié
moyenne gamme qui lui apportera davantage de souplesse.
Dédié
Vous disposez de votre propre serveur, loué à l’année. C’est une
solution professionnelle, adaptée aux projets exigeants.
Vous pouvez choisir une configuration matérielle et logicielle
adaptée à vos besoins : Céléron ou bi-Xéon, 512 Mo ou 4 Go de
mémoire vive (voire beaucoup plus !), Linux ou Windows
Server 2003, etc. Les configurations standards sont livrées avec des
outils d’administration très performants tels que Plesk ou cPanel,
grâce auxquels gérer des clients, des utilisateurs, des domaines et
paramétrer leurs droits ou leurs limites (trafic, débit, espace de stoc-
kage, etc.) devient un jeu d’enfant.
Mais attention, cette apparente facilité est accompagnée de
contraintes très fortes. En tant qu’administrateur de votre machine,
vous êtes responsable de son bon fonctionnement et de tout ce que
cela implique : suivi, sauvegardes, redémarrage, etc. Si ce n’est pas
votre métier, mieux vaut ne pas vous lancer dans l’aventure !
Hosting
Le prestataire vous loue un emplacement – et uniquement celui-
ci – dans son data center ce qui vous permet de bénéficier de son
infrastructure. Il s’agit d’une solution professionnelle, adaptée aux
projets exigeants nécessitant une configuration matérielle/

263
Partie II – La conduite des projets Web

logicielle spécifique et/ou des volumétries (trafic et bande


passante) très importantes.
Dans ce cas, le serveur vous appartient. Il peut donc être plus faci-
lement récupéré en cas de litige avec l’hébergeur. C’est un avantage
non négligeable face aux offres mutualisées où votre site et vos
données peuvent facilement devenir inacessibles du jour au lende-
main.
C’est aussi l’occasion de profiter d’une infrastructure de très grande
qualité : sécurité physique et logique, alimentation électrique,
protection incendie, etc.
Enfin, vous pouvez déléguer au prestataire, qui dispose d’équipes
hautement qualifiées, soumises à des astreintes 24h/24 7j/7, toute
l’infogérance ou une partie seulement (sauvegardes, restaurations,
maintenance corrective, etc.).
Pratique : toutes les offres sur un seul site
http://www.abchebergement.com rassemble sur un seul site toutes les offres et permet d’y
accéder par type d’hébergement, par société (recherche sur le nom et/ou le département) et
fournit même un forum où l’on peut obtenir l’avis d‘autres clients.
http://www.guide-serveur.fr propose en plus des avis d’utilisateurs assez complets permettant
de se faire une opinion réaliste.

Quel hébergement choisir ?


Le choix du mode d’hébergement et du prestataire doit être dicté
par les besoins fonctionnels et techniques mais aussi par les coûts et
la criticité du projet.
Les critères à prendre en compte
Disponibilité et bande passante garanties par SLA (Service Level
Agreement) sont les deux principaux critères à vérifier.
La disponibilité représente le temps, sur une période de référence,
pendant lequel le site est visible par les internautes. Plus le niveau
est élevé et plus le prestataire doit prendre de précautions pour
respecter son engagement et donc plus c’est coûteux.
La bande passante représente la quantité de données pouvant être
envoyées par votre site en un temps défini. On parle en général de
10 à 100 Mbps.
Le trafic, illimité ou non, peut également être un critère important.
Dans le cas d’un site institutionnel avec peu de contenu et très peu
de média (vidéo, animations Flash, sons, etc.), cela ne pose pas de

264
Chapitre 10 – La réalisation

problème. En revanche, quand le site propose des téléchargements,


le trafic peut très vite excéder les 5, 20 ou 50 Go alloués en standard.
Les délais de réaction du support technique et la qualité des
réponses apportées sont aussi très importants. Quand l’entreprise ne
dispose pas d’experts en interne, cela peut même devenir le critère
numéro 1. Rien de plus rageant, en effet, que de voir son site indis-
ponible un week-end – faute de support – alors que les ventes de la
semaine ont justement lieu le samedi. Sur ce point, les tarifications
varient selon les prestataires et les contrats du coût d’un appel local
à plus de 0,34 euros/min.
Le budget rentre bien sûr en compte dans le choix d’un hébergeur.
Mais c’est surout à partir des offres de serveur dédié et de hosting
que ce critère fait sens, les principales offres mutualisées offrant
toutes un rapport qualité/prix approchant.
Enfin, la plate-forme technique peut avoir une certaine importance
même si, là encore, les offres mutualisées sont toutes très proches.
Dans ce cas, il s’agit souvent de disposer de la version de PHP ou de
MySQL permettant l’installation ou non d’un outil de gestion de
contenu, d’un forum, etc. Dans le cas des serveurs dédiés, il est
presque toujours possible de réinstaller le serveur d’applications et
la base de données.
Prestataire connu ou discounter ?
C’est souvent la question qui se pose en dernier. Vous avez choisi le
type d’hébergement qui vous convient, les résultats de l’appel
d’offres sont saisis dans votre grille Excel et vous constatez des écarts
de prix allant du simple au triple, voire beaucoup plus !
Les hébergeurs connus font payer très cher leur notoriété et leur
fiabilité. Le problème est donc de savoir si vous souhaitez vous
engager avec un inconnu vous proposant un rapport qualité/prix
imbattable mais sans références et sans contact physique possible ou
un ténor du marché, aux références rassurantes mais offrant un
rapport qualité/prix médiocre.
L’expérience montre que même les ténors subissent des problèmes
importants (la célèbre panne électrique de Redbus en février 2006
malgré ses deux générateurs de secours en est un bon exemple). Par
conséquent, si vous disposez d’un budget très confortable, que le
projet est stratégique et qu’il évoluera à court terme, choisissez un
prestataire connu. Dans les autres cas, les prestataires alternatifs vous
apporteront, a priori, le même niveau de service (hors infogérance)
pour beaucoup moins cher.

265
Partie II – La conduite des projets Web

Pour aller plus loin

Ouvrage
John Watkins
Test logiciel en pratique
Éditions Vuibert – 2002 – 978-2711748068
Sites
Design Up - Le site des développements efficaces
http://www.design-up.com
Wikipedia – Comparaison des outils de gestion de tickets
http://en.wikipedia.org/wiki/
Comparison_of_issue_tracking_systems
Wikipedia – Design patterns
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
Wikipedia – Don’t repeat Yourself (DRY)
http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
Wikipedia – Comparaison des frameworks pour le Web
http://en.wikipedia.org/wiki/
Comparison_of_web_application_framework
Developpez.net – Comparatif des hébergeurs
http://www.developpez.net/forums/showthread.php?t=1670

266
Chapitre 11

La mise en service

Figure 11-1
Les différentes étapes de la phase de mise en service

La mise en service du projet est une phase importante qui a pour objectif
de former les utilisateurs, recetter l’application et faire connaître le projet
quand il s’agit d’un site public. C’est en somme le moment de vérité où
tous les efforts passés doivent trouver un écho positif auprès du public visé.

267
Partie II – La conduite des projets Web

Formation

La formation offre une occasion unique pour sensibiliser les forma-


teurs relais puis les futurs utilisateurs en leur démontrant les avan-
tages qu’ils retireront du nouvel outil. C’est à cette occasion que la
plupart des crises à venir – souvent fondées sur des peurs irration-
nelles et des « bruits de couloirs » – peuvent être désamorcées.
Cependant, pour être efficace, toute action de formation liée à un
projet Web doit s’inscrire dans une stratégie de conduite du change-
ment initiée en amont du projet.

Préparer les formations


Cette étape consiste à définir le plan de formation puis à créer les
supports de formation et à organiser l’accueil physique des utili-
sateurs.
Définir le plan de formation
Le plan de formation est un élément fondamental qui doit être
conçu avec recul et pragmatisme pour que son action soit efficace.
Dans le cas contraire, s’il est « plaqué » au dernier moment « parce
qu’il faut bien former les utilisateurs », ses effets seront négatifs.
Concrètement, ce sont les utilisateurs qui mettent en œuvre et
créent, sur le terrain, le changement en faisant évoluer les processus
qu’ils appliquent au quotidien. Cette démarche n’est pas naturelle
pour eux et ils doivent, dans le même temps, faire face à une perte
de repères liée à la dématérialisation de leurs tâches. Tout cela leur
demande du temps pour être assimilé durablement.
La première action à mener est donc la définition du calendrier du
plan de formation au travers de sa durée et de sa fréquence. En règle
générale, plus la fréquence est élevée et plus le message a une chance
de passer. En effet, les utilisateurs ont tendance à oublier rapide-
ment ce qu’ils ont appris lors de la formation. Le fait de multiplier
des séances courtes permet de réviser au début de chacune d’elles et
ainsi de mémoriser les principes les plus importants.
Il sera par exemple plus efficace de prévoir un miniséminaire de deux
jours suivi d’une demi-journée de formation par semaine pendant un
mois pour former au maniement d’un outil de gestion de contenu que
d’y consacrer une semaine pleine. Entre les sessions, les utilisateurs
peuvent utiliser l’outil à leur rythme, progresser avec le manuel utili-
sateurs et tenter de résoudre leurs problèmes en s’entraidant.

268
Chapitre 11 – La mise en service

Cela implique aussi et surtout de préparer le terrain en amont des


formations en les replaçant dans le cadre d’une stratégie de conduite
de changement.

Figure 11-2
La place des formations dans la conduite du changement

Bonne pratique : un site ou une unité pilote


Lorsqu’il s’agit de projets qui se déploient sur plusieurs sites ou dans plusieurs directions ou uni-
tés, il est intéressant de choisir un site ou une unité pilote avec laquelle le plan de formation
pourra être testé et affiné. Dans ce cas, cette option doit être annoncée clairement aux partici-
pants ce qui, si tout se passe bien, renforcera leur implication.

Le plan de formation précise en outre les moyens mis en œuvre. Il


s’agit, bien sûr, des supports des formations et des moyens physiques
(réservation de salle, etc.) mais aussi, quand cela est possible, des
supports de communications additionnels (rappel des principales
fonctionnalités sous formes de tapis de souris, de sous-mains…) et
d’information (journal dédié et/ou rubrique de l’intranet présentant
le « truc de la semaine »…).
Enfin, le plan de formation intègre un budget découpé action par
action qui permettra, dans un deuxième temps, d’analyser l’effica-
cité relative de chaque action. Malheureusement, le budget forma-
tion est souvent négligé car cette lointaine étape paraît « simple »
comparée à la création de l’application. Et pour tout dire, il sera

269
Partie II – La conduite des projets Web

toujours temps d’y penser en milieu de projet ! Cette erreur conduit


nombre de projets – pourtant bien réalisés – à des échecs motivés
par un rejet des utilisateurs. Il ne faut pas oublier que le projet Web
n’a jamais pour objectif de créer un outil informatique. Ce dernier
n’est qu’un moyen parmi d’autres pour atteindre des objectifs liés au
métier de l’entreprise, c’est-à-dire aux collaborateurs, à leur savoir-
faire, aux processus mis en œuvre quotidiennement. La problé-
matique est avant tout humaine et la répartition du budget doit, par
conséquent, en tenir compte.

Validation du livrable : des informations opérationnelles !


Avant de valider le plan de formation, il est important de vérifier que :
– le calendrier est réaliste et approuvé par les hiérarchies concernées ;
– un listing des collaborateurs devant être formés est présent et à jour ;
– pour chaque support et outil de communication sont précisés une définition claire, des objectifs
(quantifiés) et un budget.

Cette tâche est réalisée en interne par le chef de projet de l’entre-


prise, parfois avec l’aide d’un consultant externe spécialisé en
conduite du changement quand le projet touche de nombreux utili-
sateurs ou plusieurs sites géographiques.
Plan de formation (plan_formation.rtf )
Créer les supports
Les supports des formations sont presque toujours issus des manuels
d’exploitation et des manuels utilisateurs. Ils doivent cependant être
largement illustrés de cas concrets, reprenant, par exemple, les prin-
cipaux scénarios définis pour la recette.
Les supports destinés aux formateurs insistent sur les concepts
fondamentaux de l’outil et les meilleurs moyens de les expliquer
(but pédagogique de chaque exercice, etc.). Ils peuvent être
complétés, en cas de besoin, par un séminaire de sensibilisation aux
méthodes pédagogiques générales.
Les supports destinés aux utilisateurs finals sont en général plus denses :
ils détaillent chaque fonctionnalité de l’outil et propose d’en expliquer
le fonctionnement au travers d’exercices pratiques. Quand le budget le
permet, il est intéressant de s’appuyer sur des formats interactifs
 Director : logiciel de la
marque Adobe qui permet
(Director1, Flash, etc.) pour offrir, en plus, une véritable visite guidée.
de créer des CD-Rom.
Validation des livrables : des modes d’accès pratiques
Outre la complétude des supports, il est important de vérifier que de nombreux modes d’accès sont
disponibles : par processus, par grandes fonctionnalités, index alphabétique, index par situation…

270
Chapitre 11 – La mise en service

Les supports de formation sont, en général, créés par le chef de projet


de l’entreprise en association avec le chef de projet du prestataire.
Les outils de communication, quant à eux, sont presque toujours
pris en charge par la direction de la communication. Dans ce cas, le
chef de projet de l’entreprise fournit les informations, rédige
certains contenus et réalise les captures d’écrans.
Organiser l’environnement de formation
Cette tâche consiste à réserver ou à louer une salle de formation et à
y installer des postes clients permettant d’accéder au nouvel outil.
Dans la plupart des cas elle ne demande que peu de travail.
Cependant, des contraintes liées au réseau (accès sécurisé inexistant,
débits insuffisants, droits d’accès…) peuvent compliquer singulière-
ment les opérations.
Il n’est donc pas inutile, surtout dans le cadre d’une tournée de
formation sur plusieurs sites, de vérifier que certaines conditions
sont réunies :
• accès libre au serveur de production (ou une réplique) ;
• droits sur les répertoires où se trouve l’application ;
• droits sur la base de données ;
• bande passante suffisante ;
• postes clients à niveau (matériel et logiciel)…
Il ne faut pas non plus oublier de communiquer aux participants, clai-
rement et suffisamment à l’avance, les informations pratiques (le lieu,
la date, les prérequis, les objectifs…) et s’assurer qu’ils seront bien là.
Cette tâche est réalisée, en général, par le chef de projet de l’entreprise.

Réaliser les formations


Le principal enjeu de cette étape est la formation des formateurs
relais. S’ils sont motivés par le nouvel outil, leur manière de le
présenter sera positive et aura plus d’impact que toutes les autres
actions de communication.
Former les formateurs relais
Les formateurs relais sont choisis en fonction de leur place dans la
hiérarchie des équipes touchées par le projet. Plus ils en sont
proches, et plus les chances d’appropriation de l’outil sont fortes. Ils
doivent, en effet, comprendre les attentes, les motivations et les
freins des utilisateurs et avoir une légitimité pour en discuter avec

271
Partie II – La conduite des projets Web

eux. Ainsi, le projet n’est pas parachuté par la direction mais porté
par les utilisateurs.
 Middle management : Ce sont, en général, des cadres « terrains » appartenant au middle
ensemble des cadres management1 dans les petites structures et des chefs de bureau ou
intermédiaires se situant d’équipe dans les structures plus importantes.
entre la direction et les
collaborateurs. Les formateurs relais doivent être, si possible, intégrés au projet dès son
lancement. Ils joueront ainsi le rôle de correspondants tout au long des
phases amont (stratégie, faisabilité, conception). Cela permettra, en
outre, de les sensibiliser en profondeur à la problématique en les infor-
mant régulièrement et en les impliquant à certaines étapes (tables
rondes, tests du concept, de la maquette ou d’usabilité…).
Cette tâche est fondamentale car, si elle est bien menée, la formation
des utilisateurs ne posera ensuite pas de problème. Dans le cas
contraire, leurs craintes et leurs peurs risquent d’être renforcées…
Mieux vaut par conséquent s’assurer de la bonne formation des
formateurs relais et y consacrer les moyens nécessaires.

Validation de la tâche : les formateurs doivent se déclarer prêts


Pour valider la qualité de la formation, un questionnaire autoadmnistré et non nominatif peut être
proposé en fin de session. En fonction des scores obtenus sur des questions telles que « Vous
estimez-vous capable de former votre équipe ? » ou « Estimez-vous maîtriser l’utilisation de
l’application ? », la tâche sera considérée comme validée ou non.

Cette formation est habituellement assurée par le chef de projet de


l’entreprise, accompagné par un consultant extérieur ou par le chef
de projet du prestataire ayant réalisé les développements.
Former les utilisateurs
La formation des utilisateurs est assurée par les formateurs relais.
Elle commence par une sensibilisation sous forme, par exemple,
d’une démonstration – dont le but est de balayer les craintes identi-
fiées et de positiver la démarche de suivi d’une session de questions/
réponses.
Dans un deuxième temps, le formateur relais propose la découverte
détaillée de chaque fonctionnalité de l’application avec, à la clé, des
exercices permettant de valider la compréhension et de renforcer la
mémorisation. Dans un troisième temps, des sessions régulières
permettent d’approfondir des points particuliers et de répondre aux
questions des utilisateurs.
Enfin, une série de tests, correspondant aux principaux scénarios
d’utilisation, permet de s’assurer que les utilisateurs ont assimilé le

272
Chapitre 11 – La mise en service

fonctionnement de l’application. En fonction des résultats obtenus,


des séances de perfectionnement pourront être proposées.

Validation de la tâche
La tâche est validée quand le pourcentage d’utilisateurs jugés aptes fixé dans le plan de formation
est atteint.

Recette de l’application

Contrairement à beaucoup d’idées reçues, la recette devrait se


préparer en même temps que le cahier des charges ou, idéalement,
en même temps que les spécifications détaillées. En effet, lister les
scénarios de test et les erreurs potentielles permet d’affiner le cahier
des charges en mettant l’accent sur les aspects délicats du projet.
C’est aussi le moyen de s’assurer, lors de la rédaction des spécifica-
tions détaillées, que les règles de gestion n’ont pas été oubliées.
Précisons que l’objectif d’une recette n’est pas d’identifier le plus
d’anomalies possible (ce n’est qu’un moyen) mais bien de trouver
des solutions avec le prestataire dans une démarche constructive et
bénéfique au projet.
Enfin, la recette est un moment utile – mais aussi sensible – pour
communiquer auprès des formateurs relais. En les faisant participer
aux tests, ils prennent conscience de l’imminence de l’arrivée de la
future application. Si les tests sont concluants, ils porteront la bonne
parole avec plus d’efficacité que tous les autres supports.
Survol des principaux tests réalisables
Les tests présentés ci-après, bien que complémentaires, sont rare-
ment tous réalisés pour un même projet, car, pour être utiles,
chacun d’entre eux doit être mené avec une grande rigueur, ce qui
est très fastidieux !
Test « du singe »
Le test dit « du singe » consiste à essayer de bloquer le système en
réalisant des actions illogiques. Il permet notamment de vérifier les
contrôles de saisie.
Concrètement, les testeurs essaient de passer d’étape en étape en omet-
tant de fournir des informations vitales (validation de la saisie d’une
note de frais sans montant de frais, paiement sans date d’expiration de
la carte bancaire, etc.), réalisent des copier/coller improbables (un

273
Partie II – La conduite des projets Web

rapport de cinquante pages illustrées dans un champ texte par


exemple), quittent le cheminement logique pour y revenir plus tard
(cliquent sur la liste des nouvelles fournitures de bureau disponibles au
moment de valider la commande), simulent des incidents matériels…
Test fonctionnel
Ce test repose sur des scénarios fonctionnels qui visent à reproduire
les actions qui seront effectuées le plus souvent sur le site. Dans le
cas du front-office d’un site marchand, il s’agira, par exemple, de
reproduire les différents modes de sélection d’un article puis ceux de
commande.
Les scénarios sont classés en fonction de leurs dépendances récipro-
ques de manière à pouvoir les enchaîner dans l’ordre le plus logique.
Pour reprendre notre exemple, la commande ne peut pas avoir lieu
avant qu’un article ait été sélectionné.
À chaque scénario est associé un « jeu de tests ». Ce sont des données
cohérentes injectées dans le système qui permettent de simuler les
réactions du site. Fiches produit, délais de livraison, état des
stocks… dans notre exemple.
Les tests fonctionnels demandent une grande rigueur et énormé-
ment de patience : il est parfois nécessaire de travailler plusieurs
heures pour simuler un seul cas d’utilisation.
Test de montée en charge
Ce test valide les performances effectives de l’application lorsqu’elle
atteint les limites de charge et de stress fixées dans les spécifications
détaillées. Il permet ainsi d’obtenir le dimensionnement réel de
l’application (nombre d’utilisateurs simultanés, temps de réponse,
dégradations des performances en fonction de la charge…). L’objectif
est d’optimiser le budget, d’une part en évitant de futurs correctifs liés
à la montée en charge (hors période de garantie), et d’autre part en
optimisant la configuration de la plate-forme matérielle.
Repère : une plate-forme sur deux est surdimensionnée
Mercury interactive annonce que dans 70 % des cas, les plates-formes matérielles de sites criti-
ques sont surdimensionnées. Elle précise que dans 98 % des cas les performances peuvent être
au moins doublées grâce à un meilleur paramétrage des applications.
Source : ZDNet (http://www.zdnet.fr).

La démarche à suivre pour réaliser un test de montée en charge est


assez classique et ne pose pas de problème :
• définition des objectifs ;

274
Chapitre 11 – La mise en service

• définition du cadre (choix de l’application, choix des limites,


dimensionnement des pointes d’activité…) ;
• définition des moyens (humains et matériels, logiciels de test,
jeux de test, autorisations…) ;
• définition des scénarios ;
• réalisation du test (initialisation, test, analyse des résultats, nou-
veau test…) ;
• recommandations.
Mais attention, pour que les tests soient pertinents, l’outil utilisé
doit remonter le plus d’informations possible sur un large spectre de
technologies (pare-feu, routeur, serveur d’applications, base de
données…). En outre, la méthode, les limites et les données du jeu
de tests conditionnent directement la pertinence des résultats. Les
étapes de préparation sont donc fondamentales !

Tests fonctionnels avec Selenium


Selenium rassemble une série d’outils permettant d’automatiser les
tests fonctionnels réalisés lors de la mise en œuvre. Cette section
explique aux chefs de projets fonctionnels et techniques comment
automatiser leurs tests fonctionnels grâce à Selenium IDE, une
extention du navigateur Firefox.

Figure 11-3
Panneau de commande Selenium

Les bonnes pratiques et les conseils sont issus de plusieurs campa-


gnes de tests sur des plateformes de gestion de contenu (Drupal,
eZ Publish…) au cours desquelles environ 1 200 tests ont été para-
métrés et exécutés à 15 reprises, soit près de 18 000 tests réalisés.
Avec de tels chiffres on comprend vite l’intérêt de l’automatisation !

275
Partie II – La conduite des projets Web

Présentation de Selenium

Figure 11-4
Vue d’ensemble des différents composants de Selenium

Selenium
Selenium est un ensemble de composants Open Source et gratuits
dont l’objectif est d’automatiser les tests fonctionnels d’application
Web. Attention, ces outils sont destinés à des tests fonctionnels : le
paramétrage est essentiellement basé sur l’interface de l’application.
Pour réaliser de vrais tests unitaires, il est préférable d’utiliser des

276
Chapitre 11 – La mise en service

outils plus proches du code, tels que JUnit ou TestNG ou encore


simpletest dans notre cas (Drupal 6).
Selenium IDE
Selenium IDE permet de paramétrer les tests très facilement via une
interface WYSIWYG dans Firefox. C’est là sa grande force : un chef
de projet purement fonctionnel peut sans difficulté participer au
paramétrage sans jamais entrer une ligne de code. Les tests ainsi
créés peuvent être joués individuellement ou regroupés dans des
scénarios qui enchaînent les tests dans un ordre précis (nous
détaillerons tout cela plus loin). De cette manière il est possible de
simuler une activité réelle sur le site ou l’application Web.
Selenium RC et Selenium Grid
Pour les projets de grande envergure, il est également possible
d’exécuter ses tests sur les principaux navigateurs (IE, FF, Safari…)
via Selenium Remote Control, un serveur Java. Cet outil propose
aussi de coordonner plusieurs serveurs Selenium RC via Selenium
Grid. Des services de tests de charge basés sur Selenium Grid sont
d’ailleurs en train d’émerger (BrowserMob par exemple).
Enfin, et c’est là un point important, Selenium s’intègre aux princi-
paux frameworks de test tels que JUnit. L’outil permet en effet
d’exporter les tests en PHP, Java, C#, Perl, Python, Ruby…
Préparer un plan de test fonctionnel
Avant de se lancer à corps perdu dans le paramétrage de tests Sele-
nium, encore faut-il savoir quels tests réaliser, comment les orga-
niser, qui participera à leur paramétrage, etc. En un mot : il faut
s’organiser un peu.
Choisir un plan de test
Pour s’organiser en matière de projet Web, rien de tel que des spéci-
fications bien découpées. Prenons un exemple. Pour tester le cycle
de vie d’un article, il faut s’assurer qu’il peut être :
• créé ;
• validé ;
• publié ;
• promu ;
• archivé ;
• supprimé ;
• etc.

277
Partie II – La conduite des projets Web

Il faut aussi vérifier quel profil peut réaliser ces actions :


• rédacteur ;
• valideur ;
• webmasteur ;
• administrateur ;
• etc.
Évidemment, il est impossible de tester l’archivage de l’article avant
sa création.
Première bonne pratique : les tests Selenium doivent être organisés
chronologiquement. Ce qui n’est pas si simple lorsqu’on a 900 tests
à ordonnancer ! L’expérience montre que les étapes classiques, donc
les scénarios Selenium, sont les suivantes :
• création des utilisateurs ;
• paramétrage ;
• création des contenus ;
• validation ;
• publication ;
• listage ;
• affichage ;
• modification ;
• suppression.
À l’intérieur de chaque scénario Selenium, on retrouve également
un ordre logique : il faut créer dans un premier temps l’administra-
teur puis les autres utilisateurs.
Répartir le travail entre les participants
Se pose alors la question de la répartition de la création des tests
entre plusieurs acteurs sans qu’il y ait d’interférences entre eux.
Une répartition en deux temps est nécessaire : tout d’abord, chaque
participant créé un ou plusieurs types de contenu basic (lien, image,
article, vidéo…). Les participants les plus expérimentés créent
ensuite les types de contenu complexe basés sur les types de contenu
basic (par exemple, cas d’un dossier qui regroupe des articles, des
liens, des vidéos…).
Deuxième bonne pratique : les tests Selenium doivent être organisés
en fonction de la complexité structurelle de chaque type de contenu.
Une règle de nommage à toute épreuve
Une fois le découpage réalisé, il faut se mettre d’accord sur la façon
de nommer chaque test, de manière à automatiser par la suite la

278
Chapitre 11 – La mise en service

création des scénarios. Si ce travail n’est pas effectué, vous devrez


renommer manuellement 900 fichiers… Bon courage !
Vous pouvez, par exemple, opter pour la forme :
[id]_[nom_de_la_fonction_a_tester]-[profil].html. Où l’id est à la
fois l’id de la fonction (créé lors de la rédaction des spécifications
détaillées) et l’id du test. Le nom de la fonction est également direc-
tement issu des spécifications.
À ce stade, on commence à voir qu’une méthode intégrée (expres-
sion du besoin>faisabilité>spécifications>tests) garantit une grande
cohérence, tout en réduisant la charge de travail.
Questions à se poser
Deux questions fondamentales vous aideront à établir votre propre plan de test :

– Est-ce que je veux tester un processus complet ou plutôt réaliser une série de tests unitaires (au
sens fonctionnel) ?

– Est-ce que je veux avoir n versions de chaque test (une version par profil par exemple) ou plutôt
un test comportant tous les profils ?

Au final et pour résumer, quelle granularité est nécessaire pour que les tests soient fiables, réalisa-
bles dans les contraintes du projets, puis maintenables ?

Dans notre cas, nous avons pris le parti de créer n versions de chaque test (une version par profil)
pour avoir plus de souplesse lors de la génération des scénarios.

Générer les scénarios


L’un des enjeux majeurs du plan de test est la granularité du décou-
page. Il est important que les scénarios puissent être créés sur
commande, en fonction du besoin du moment, tout en gardant une
vraie valeur unitaire. Pour cela, on doit pouvoir facilement trier les
tests selon la fonction (création, modification…) et le profil (rédac-
teur, webmaster). Tout ce travail de découpage et d’ordonnance-
ment est évidemment facilité par des spécifications détaillées de
bonne qualité.
Paramétrer les tests et scénarios fonctionnels avec Selenium IDE
Une fois le plan de test établi, il ne reste plus qu’à paramétrer chaque
test puis à générer les scénarios.
Avant de commencer
Vous devez disposer :
• d’un site/une application à tester ;

279
Partie II – La conduite des projets Web

• d’un jeu de tests : quelques images, vidéos, sons, textes, données


représentatives ;
• de Firefox 2.x VERSION PC (nous avons rencontré des
problèmes sous Mac) ;
• de l’extension Selenium IDE ;
• d’un accès à MySQL ou PHP MyAdmin (ce n’est pas fonda-
mental mais très pratique, vous verrez).
Quelques conseils utiles si vous travaillez en équipe :
• tous les tests doivent s’appuyer sur un répertoire commun
(c:\selenium dans notre cas) pour être ensuite mis en commun et
exécutés sans problème ;
• toutes les ressources (images, sons…) doivent posséder un nom
unique et être stockées au même endroit (c:\selenium dans notre
cas) pour être ensuite mises en commun et exécutées sans
problème.
Paramétrer un test (via Selenium IDE)
Si vous n’êtes pas à l’aise avec le code, utilisez Selenium IDE, c’est
fait pour ça !
1. Commencez par nettoyer Firefox pour éviter tout problème lié
à une session, un cookie…

Figure 11-5

280
Chapitre 11 – La mise en service

2. Allez dans Outils>Selenium IDE. Une fenêtre pop-up apparaît.


C’est Selenium IDE.

Figure 11-6

3. Cliquez sur la barre gauche pour ouvrir la colonne listant les


tests enregistrés.

Figure 11-7

281
Partie II – La conduite des projets Web

4. Remarquez le rond rose. Il signifie que Selenium est en train


d’enregistrer vos actions. Dans Base URL, renseignez l’URL de
l’application à tester. Cette information est très importante, car
Selenium fonctionne avec des URL relatives.

Figure 11-8

5. Si on clique dans le slider présentant ajouteraupanier.com, on


remarque qu’une ligne vient d’être ajoutée dans l’onglet Table.

Figure 11-9

282
Chapitre 11 – La mise en service

6. Si on clique sur l’onglet Source, on comprend qu’à chaque action


dans Firefox correspond un ligne de tableau structurée comme suit
[commande][cible][valeur]. Continuez à agir sur le site.

Figure 11-10

7. Quand vous avez terminé le test, cliquez sur le rond rouge pour
qu’il arrête d’enregistrer vos actions (il faudra penser à recliquer
dessus au début du prochain test) puis enregistrez le test dans
Fichier>Sauver le test sous… Bravo ! Vous venez de paramétrer
votre premier test Selenium !

Figure 11-11A et 11B

283
Partie II – La conduite des projets Web

8. Rejouez le test pour vérifier qu’il fonctionne. Pour cela cliquez sur
le test (il doit être en gras) puis sur la flèche verte suivie d’une seule
barre (celle suivie de plusieurs barres sert à lancer les scénarios).

Figure 11-12

9. Le test se déroule.

Figure 11-13

284
Chapitre 11 – La mise en service

10. Dans l’onglet Table, la barre verte indique l’action exécutée


avec succès, la jaune indique l’action en cours et la rouge un
échec. À la fin du test, un compteur indique le nombre d’échecs
et la fenêtre log permet de retrouver les erreurs pour
comprendre quel est le problème.

Figure 11-14

Paramétrer un scénario Selenium


La méthode la plus simple consiste à créer un tableau HTML en
suivant la même logique que pour la création d’un test. La seule
différence réside dans l’enchaîchement des lignes : au lieu
d’enchaîner des lignes comprenant trois colonnes, on enchaîne des
lignes avec une colonne qui appellent le test.

Figure 11-15
Exemple de code d’un scénario fonctionnel dans Selenium

Ensuite, il suffit d’ouvrir le test et de le lancer. Les résultats sont lus


de la même manière que pour un test.

285
Partie II – La conduite des projets Web

Passer les tests et scénarios fonctionnels


Quand tous les tests et tous les scénarios sont créés, il est temps de
« passer les tests ». Aucune difficulté à ce stade : il suffit d’ouvrir les
scénarios un par un puis de les exécuter et d’aller boire un café en
attendant.
Avant de commencer
Vous devez disposer :
• d’un site/une application à tester ;
• d’un jeu de tests : quelques images, vidéos, sons, textes, données
représentatives ;
• de Firefox 2.x VERSION PC (nous avons rencontré des pro-
blèmes sous Mac) ;
• de l’extention Selenium IDE ;
• d’un accès à MySQL ou PHP MyAdmin (ce n’est pas fonda-
mental mais très pratique, vous verrez) ;
• d’un ensemble de tests et de scénarios debuggés.
Procéder par étapes
1. Pour lancer un scénario, il suffit de cliquer sur Open Test Suite.

Figure 11-16

286
Chapitre 11 – La mise en service

2. Le scénario est maintenant chargé : il liste les tests individuels.

Figure 11-17

Après avoir lancé un scénario, ne restez pas collé à votre écran. Ne


paniquez pas à chaque problème. Ne stoppez pas le scénario et
n’essayez pas de comprendre le problème… Allez plutôt boire un
café !
Bonne pratique : comment dérouler un scénario
– Faites couler un café.
– Lancez le premier scénario en mode Fast.
– Buvez le café.
– Lorsque cette étape est finie, lancez chaque test en échec en mode Slow. Et, miracle, la plupart
des testes réussissent.
– Analysez ceux qui posent vraiment problème (soit en débuggant le test, soit en remontant
l’anomalie dans votre bugtracker préféré).

Évidemment, nous en parlions au début, il faut lancer les scénarios dans un ordre logique :
– création des utilisateurs ;
– paramétrage ;
– création des contenus ;
– validation ;
– publication ;

287
Partie II – La conduite des projets Web

– listage ;
– affichage ;
– modification ;
– suppression.

Pour éviter de relancer à chaque fois tous les scénarios précédents


(« création » et « validation » par exemple pour tester
« publication »), une bonne pratique consiste à réaliser des dumps
de la base à chaque fin de scénario. De cette manière, il est très facile
de retester des bouts de scénario. C’est tout bête mais il fallait y
penser !
En conclusion…
Les outils Selenium permettent d’aller très loin dans l’automatisa-
tion des tests. Mais pour couvrir les 20 % de tests difficiles à para-
métrer (présence d’Ajax, beaucoup de drag&drop…) cela coûte vite
80 % de la charge de test. Il est donc nécessaire de savoir s’arrêter
pour ne pas tomber dans le débuggage des tests ! À titre d’exemple,
lors de notre dernière campagne, nous avons réalisé 947 tests dont
858 tests Selenium 100 % automatiques (90 % des tests) ; 29 tests
Selenium semi-automatiques, c’est-à-dire nécessitant à un moment
une intervention manuelle (3 % des tests) ; 60 tests manuels (6 %
des tests). Nous avons perdu plusieurs dizaines d’heures de paramé-
trages inutiles car trop complexes ou faisant peu sens.
Selenium force à tester chaque recoin de l’application de manière
systématique et c’est une excellente raison de l’utiliser. C’est aussi un
excellent outil pour traquer les régressions tout au long de la vie du
site ou de l’application Web (ou même tout au long du processus de
recette). Cependant, il ne faut surtout pas partir du principe que
parceque « ça passe dans Selenium alors tout va bien ». L’outil ne
remplacera jamais l’utilisateur et une recette intelligente, en complé-
ment des tests systématiques, est dans tous les cas indispensable.
Réalisation de la recette
Le principe de cette étape est de valider la conformité du produit
fini avec le cahier des charges ou les spécifications détaillées. Elle
ressemble globalement aux tests réalisés en fin de développement à
ceci près que c’est l’équipe projet et/ou les utilisateurs clés que l’on
vient de former qui vont la réaliser.
Organisation de la recette
L’organisation de la recette consiste à formaliser, sur la base du cahier
des charges et/ou des spécifications détaillées, la liste des fonctionna-

288
Chapitre 11 – La mise en service

lités à tester, la liste des tests utilisés, un plan de tests (enchaînement


des différents tests, planning) ainsi que les jeux de test.
Dans le cas de projets riches en fonctionnalités, le planning précise
quels domaines sont testés à quel moment, ce qui permet à chaque
intervenant de se situer.
Les testeurs sont recrutés de manière à être les plus représentatifs
possible. Dans le cas d’un intranet, il est important de recruter un
contributeur pour chaque niveau du workflow (utilisateur final,
rédacteur, valideur…) et de les former.
La préparation de la recette est habituellement réalisée en interne,
parfois avec l’aide d’un prestataire spécialisé en assistance à maîtrise
d’ouvrage ou avec le prestataire en charge des développements.
Mise en œuvre de la recette
Après avoir reproduit l’environnement de production, la réalisation de
la recette consiste à exécuter les actions de chaque test et notamment les
scénarios fonctionnels et à remonter les anomalies dans un référentiel
unique (souvent un logiciel de gestion d’anomalies telles que Mantis).
Chaque anomalie, décrite dans une fiche d’anomalie, est classée en
fonction de sa nature, de sa gravité et de son caractère bloquant, ce
qui permettra, dans un deuxième temps, de « prioriser » la recherche
de solutions.
Suite à l’analyse des fiches d’anomalies, l’équipe qui a développé
l’application réalise les corrections nécessaires jusqu’au moment où
ne subsiste aucun dysfonctionnement.

Validation du livrable : ATTENTION !


Cette tâche est extrêmement importante. À partir du moment où la recette est validée et qu’une
VSR (vérification de service régulier) et/ou une garantie ne sont pas prévues, le lien contractuel
avec le prestataire devient caduc. L’entreprise n’a donc plus de moyens simples pour faire corriger
les éventuelles anomalies qui n’auraient pas été constatées.
L’entreprise doit donc être très vigilante et reprogrammer autant de recettes que nécessaire pour obtenir
satisfaction. Cependant, elle ne doit pas sortir du cadre défini par les spécifications détaillées.

Cette tâche peut être réalisée en interne. Dans certains cas (projet
volumineux, fatigue en fin de projet, etc.) il est conseillé de se faire
accompagner soit par le prestataire intervenu dans les phases amont
(stratégie, faisabilité, conception) soit par un spécialiste de l’assis-
tance à maîtrise d’ouvrage.

289
Partie II – La conduite des projets Web

Fiche d’anomalie (fiche_anomalie.rtf )

Bonne pratique : faites confiance à Mantis


Ce logiciel de remontée d’anomalie est l’un des plus utilisés au monde. Il est très simple à ins-
taller et sa prise en main ne demande que quelques heures. Pour en savoir plus : http://
www.mantisbt.org/index.php (en anglais).

Communication
La valeur d’un site ou d’un intranet dépend en premier lieu de son
trafic, car plus les visiteurs sont nombreux et plus le potentiel de
communication ou de transaction est important. À l’inverse, un site
sans trafic, même s’il est très bien conçu, n’a aucun intérêt. Les
opérations de communication et le référencement lors du lance-
ment du projet sont donc très importants. Ces deux techniques sont
complémentaires : la campagne de communication vise à déve-
lopper rapidement la notoriété du site alors que le référencement
assure sa visibilité continue.

Définir le plan de communication


L’objectif de la campagne de communication est de développer rapi-
dement la notoriété du site. Elle s’appuie pour cela sur l’ensemble des
techniques publicitaire auxquelles elle ajoute les supports propres au
Web. Les pages suivantes présentent les principales actions à mener.
Comme pour toute autre action de communication, la campagne de
lancement d’un projet Web doit commencer par la définition du plan de
communication, de la stratégie de création et de la stratégie des moyens.
Le plan de communication précise les objectifs poursuivis et les cibles
visées. L’objectif, dans le cas qui nous intéresse, est presque toujours de
faire connaître le projet et de motiver les cibles à s’y connecter. Ces
 CSP : Catégorie dernières peuvent être définies de manière classique (sexe, âge, CSP1, ou
socioprofessionnelle.
direction, niveau hiérarchique, métier, site… dans le cas d’un portail
Les CSP classent les indi-
vidus dans des ensembles d’entreprise) mais aussi en fonction de leurs communautés d’apparte-
homogènes en fonction nance et de leurs centres d’intérêt. Cette manière de les définir aidera à
de leur niveau d’études, sélectionner lors du plan média des sites communautaires pertinents,
de leurs revenus… Les CSP
car l’un des avantages du Web est de pouvoir cibler avec énormément
sont utilisées pour définir
une cible marketing. de précision le support sur lequel le message sera diffusé.
La stratégie de création est formulée sous la forme habituelle d’une
copie stratégie. Elle précise notamment la promesse, la preuve, le
bénéfice consommateur et le ton comme le résume le tableau 11-1 :

290
Chapitre 11 – La mise en service

Tableau 11-1
Exemple de copie stratégie

COMPOSANTE EXPLICATION EXEMPLE


La promesse Le message à communiquer à Le site Volvic
la cible. La caractéristique vous coache au quotidien.
essentielle du produit ou du
point de vente.
La preuve La justification, l’illustration Zinedine Zidane vous donne
de la promesse. Elle doit être : ses conseils forme chaque
– très concrète, semaine.
– compréhensible,
– exprimée dans le langage
du consommateur.
Le bénéfice L’intérêt, l’avantage lié Je suis plus en forme, plus
consommateur à la promesse. tonique, je supporte mieux
le stress quotidien.
Le ton L’atmosphère du message Complicité et
reposant parfois sur professionnalisme.
un personnage, le décor, Zinedine Zidane.
une musique…

Enfin, la stratégie des moyens consiste à définir quels types d’actions


seront menées et quels supports seront utilisés : médias (presse, TV,
cinéma, affichage…), hors médias (mailing, publicité sur le lieu de
vente…), promotions (jeux et concours, stands, objets publici-
taires..), relations publiques (communiqué, dossiers…)… et à en
évaluer le budget. En ce qui concerne spécifiquement Internet, les
supports les plus utilisés restent les bannières, le parrainage et les
différentes formes de liens (boutons, logos, hyperliens...).

Tableau 11-2
Impact de la publicité en ligne sur les internautes européens
Source : Journal du Net, janvier 2005, http://www.journaldunet.com/
0411/041125eiaa.shtml

POPULATION POPULATION DELTA


D’INTERNAUTES D’INTERNAUTES
EXPOSÉS DE RÉFÉRENCE

Notoriété de la marque 72,6 % 68,9 % + 5,4 %


Mémorisation des publicités 34 % 23,4 % + 45,3 %
Attribution de la pub à la marque 33,2 % 27,3 % + 21,6 %
Attitude positive vis à vis de la marque 47,1 % 44,6 % + 5,6 %
Intention d’achat 40,2 % 38,3 % + 5,0 %

291
Partie II – La conduite des projets Web

La permission marketing ou l’e-mailing intelligent


Selon Seth Godin, le marketing traditionnel, qualifié d’interruption marketing, vit ses derniers
jours. En effet, ce dernier serait entré dans un cercle vicieux :
– le consommateur n’a qu’une capacité d’attention limitée ;
– le consommateur n’a qu’un pouvoir d’achat limité ;
– l’offre s’élargit, diminuant le budget disponible pour chaque produit ;
– capter l’attention devient de plus en plus difficile et coûteux ;
– plus les budgets augmentent et plus la situation empire ;
d’ou la conclusion : plus les budget augmentent, moins cela marche. Moins cela marche, plus on
dépense...

Seth Godin propose donc une approche plus qualitative : le permission marketing. Il s’agit
d’adresser des messages publicitaires qui sont attendus, personnalisés et pertinents. Ainsi, l’inter-
naute « en a pour son temps ». C’est dans cette optique que les campagnes d’e-mailing doivent
impérativement s’inscrire, ce qui sous-entend que la qualité des fichiers (opt in) est la base d’une
campagne réussie. À tel point qu’il peut être intéressant, pour certaines sociétés (en B-to-B, en
B-to-C quand la marque joue un rôle important...), d’investir dans l’acquisition de ses propres
adresses e-mail.

Attention cependant, car l’efficacité de ces différents supports est


sujette à discussion, même si les spécialistes s’accordent à penser que
les bannières sont un bon complément au plan média traditionnel.
L’affiliation, quant à elle, est en train d’acquérir ses lettres de
noblesse, grâce à une efficacité de mieux en mieux mesurée comme
le montre le graphique ci-après.

50 %

40 %

30 %

20 %

10 %

0%

Figure 11-18
Score d’impact de six formats de sponsoring en ligne, calculé en fonction du
niveau de présence Internet, base 100

292
Chapitre 11 – La mise en service

Validation de la tâche : une stratégie claire, des moyens budgétés


Le plan de communication sera validé après avoir vérifié que :
– la stratégie est claire et pragmatique ;
– des objectifs quantitatifs et qualitatifs ont été fixés pour chaque support ;
– des moyens de mesure ont été prévus pour chaque support et sont intégrés au budget ;
– le budget est détaillé (attention aux nombreuses formules d’achat d’espace) ;
– le planning est détaillé.

La définition du plan de communication doit être confiée à un pres-


tataire spécialisé ou, à défaut, au prestataire réalisant le site quand il
s’agit d’une Web agency.
Plan de communication (plan_communication.rtf )

Mettre en œuvre le plan de communication


Cette tâche consiste d’une part à réaliser le plan média et à acheter
l’espace, et d’autre part à créer et à produire les supports définis. Le  GRP : Gross Rating
plan média en ligne utilise globalement les mêmes outils que le Point. Le GRP calcule la
média planning traditionnel : cibles, couverture, répétition, coût « puissance de feu » d’une
pour mille contacts (CPM), coût pour mille contacts mémorisés campagne en multipliant
la couverture sur cible par
(CPMM), gross rating point (GRP1)… Le plan média s’appuie sur la répétition moyenne du
deux variables intimement liées : le budget qui fixe la taille de la message par individu
campagne, et la couverture qui fixe l’objectif quantitatif de la exposé. Par exemple, une
campagne touchant 50 %
campagne. Les deux objectifs d’une campagne de communication
de la cible avec une répé-
en ligne sont : le développement de la notoriété et de l’image et la tition moyenne de 4 obtien-
constitution d’une base de données clients et/ou prospects. Lors dra ainsi un GRP de 200.
d’une campagne de notoriété, l’objectif est de communiquer auprès
d’une cible large afin de faire connaître ou de développer la noto-  Capping : le capping
riété de la marque ou d’un produit. Pour y parvenir, le taux de répé- consiste, lors de la phase
tition doit être élevé (nombre de visualisations du message par un d’insertion de mise en ligne
même individu). Il peut être obtenu en jouant sur une fréquence d’un bandeau sur un site ou
un réseau de régie, à préci-
élevée et une part de voix de l’ordre de 20 % à 30 % (nombre de ser un nombre d’affi-chage
PAP [Page avec publicité] achetées par l’entreprise par rapport au maximal auprès d’un même
nombre de PAP disponibles sur le site). Dans tous les cas, le taux de visiteur identifié par un
cookie. Un seuil de capping
répétition doit, pour des raisons économiques et d’efficacité, être
fixé à 5 pour huit jours signi-
maîtrisé en utilisant, par exemple, le principe du « capping2 ». Les fie que le même individu ne
sites support seront sélectionnés en fonction de leur forte affinité verra théoriquement que
avec la cible mais pas forcément avec le thème. Les emplacements à cinq fois un même bandeau
sur la période. Le capping
forte visibilité tels que la page d’accueil, les pages d’accueils de rubri- sert à éviter les effets de
ques sont à privilégier… Enfin, le taux de couverture (nombre « burnout » ou l’irritation à
d’individus cibles ayant vu le message/nombre total d’individus l’égard d’un format intrusif.

293
Partie II – La conduite des projets Web

cibles) doit, lui aussi, être élevé afin de s’assurer que la cible verra le
plus possible la marque et les messages sur la période de lancement.
Lors d’une campagne visant à constituer une base de données,
l’objectif est de générer un trafic qualifié sur le site où se trouve le
dispositif marketing qui permet de capter les informations. L’effica-
cité de la campagne est mesurée par le taux de participation (nombre
d’individus fournissant des informations par rapport au nombre
total de visites générées par la campagne). La répétition et la part de
voix peuvent alors être relativement faibles mais, une fois encore, le
recours au capping est souhaitable. Dans ce cas, il s’agira de fixer un
nombre maximal d’exposition très faible de l’ordre de 3 à 4.
Tableau 11-3
Les formats de la publicité en ligne (IAB 2008)
Source : IAB, 2008, http://www.iab.net/
iab_products_and_industry_services/1421/1443/1452

Rectangles et Pop-Ups Bannières et boutons Skyscrapers


300 × 250 IMU 468 × 60 IMU 160 × 600 IMU
(Medium Rectangle) (Full Banner) (Wide Skyscraper)
250 × 250 IMU 234 × 60 IMU 120 × 600 IMU
(Square Pop-up) (Half Banner) (Skyscraper)
240 × 400 IMU 88 × 31 IMU 300 × 600 IMU
(Vertical Rectangle) (Micro Bar) (Half Page Ad)
336 × 280 IMU 120 × 90 IMU
(Large Rectangle) (Button 1)
180 × 150 IMU 120 × 60 IMU
(Rectangle) (Button 2)
*NEW* 300 × 100 120 × 240 IMU
(3:1 Rectangle) (Vertical Banner)
*NEW* 720 × 300 125 × 125 IMU
(Pop-Under) (Square Button)
728 × 90 IMU
(Leaderboard)

Le plan média et l’achat d’espace doivent être impérativement


confiés à un prestataire spécialisé tel qu’une centrale d’achat
d’espace ou une agence de communication interactive.

294
Chapitre 11 – La mise en service

Figure 11-19
Rôle de chaque action de promotion replacé dans le contexte de connexion
à un site

De la publicité sur le lieu de vente (PLV) aux tapis de souris en


passant par les affichettes, la création des autres supports est fonc-
tion de chaque projet et des opportunités liées au réseau de distribu-
tion (PLV guichet, affichettes et relevé de compte, par exemple,
pour les banques).
Cependant, pour les lancements internes, quelques « classiques »
ont fait leurs preuves dans de nombreuses entreprises : tapis de
souris, CD-Rom avec animation Flash, cartes postales et affiches,
encart dans le journal interne…
Dans tous les cas, l’efficacité de ces supports dépend directement de
l’intérêt du projet, d’une argumentation en phase avec les préoccu-
pations des utilisateurs (pas de la direction), de la qualité de la créa-
tion et de la justesse du ton. La solution la plus simple, pour cette
tâche, est de confier la totalité du dispositif à un seul prestataire de
type agence de communication interactive.

Analyser les résultats de la campagne


de communication
Chaque campagne de communication étant un investissement
important, son efficacité doit être mesurée. L’entreprise dispose
pour cela d’indicateurs tels que l’audience, le taux de clics et autres
panels d’internautes.
Repère : les trois niveaux de mesure de l’efficacité publicitaire

295
Partie II – La conduite des projets Web

– niveau cognitif (mémorisation de la marque, mémorisation de la publicité) ;


– niveau affectif (modification de l’image de la marque) ;
– niveau comportemental (intention d’achat, achat réel).
Source : Publicitor, J. Lendrevie et B. Brochand, éditions Dalloz (http://www.mercator-publicitor.fr/)

L’analyse de l’audience est l’une des méthodes phare car elle révèle
les actions générant du trafic. Elle permet, par exemple, via l’analyse
des logs, de retrouver à quel moment une opération d’e-mailing a
été déclenchée, à quel moment elle s’est arrêtée et quelle a été son
influence sur le trafic.
Le taux de clics est un indicateur intéressant pour mesurer la qualité de
la création. Pour Doubleclick (http://www.doubleclick.com), le taux
moyen des formats standards se situait en 2005 aux alentours de 0,6 %
et 1,17 % pour les médias riches. Ce spécialiste de la publicité précise
que « ces chiffres continuent de varier considérablement chaque
trimestre, ce qui reflète l’idée selon laquelle les taux de clics dépendent
davantage de l’intention créative et de l’emplacement spécifique que du
format de la publicité. Le format 550 × 80, le plus souvent utilisé pour
les publicités interstitielles, affiche le taux moyen de clics le plus élevé
avec 0,80 %, suivi du carré (250 × 250), le plus souvent utilisé pour les
pop-ups, avec 0,58 %. Le taux moyen de clics pour une bannière stan-
dard de 468 × 60 est de 0,17 ».
Des analyses plus poussées, menées par exemple avec des panels
d’internautes ou via des questionnaires en ligne fournissent des indi-
cateurs qualitatifs, tels que le taux d’intention de visite ou d’achat,
le taux de mémorisation… Le premier évalue la capacité de persua-
sion de la campagne, donc ses qualités intrinsèques. Le second
apprécie la qualité de la créativité.
Ces quelques outils sont, bien sûr, à compléter par des méthodes
plus classiques qui mesureront l’impact des autres actions et
supports mis en œuvre.

Validation du livrable : disposer d’une synthèse compréhensible


Le rapport d’analyse doit proposer à la fois :
– une synthèse directement opérationnelle et compréhensible (ce qui demande un gros travail
desimplification car les indicateurs ne sont pas calculés de la même manière, ni sur des bases
identiques !) ;
– une analyse détaillée, support par support ;
– l’intégralité des éléments chiffrés dans un format électronique.

296
Chapitre 11 – La mise en service

Cette tâche peut être réalisée en interne, avec l’aide d’un consultant
extérieur spécialisé.

Pour aller plus loin

Ouvrages
Pascal Lannoo et Corinne Ankri
E-marketing et e-commerce
Vuibert – 2007 – ISBN : 978-2711787210

Catherine Viot
Le e-marketing : La connaissance du marché et du cyber consommateur,
le positionnement et le marketing mix d’un site de vente en ligne
Gualino éditeur – 2006 – ISBN : 978-2297000871

Martine Janssens-Umflat, Alain Ejzyn, Marc Vandercammen et


André Toye
M@rketing : E-business, e-marketing, cyber-marketing
De Boeck – 2007 – ISBN : 978-2804152703

Yan Claeyssenet Matthieu Guinard


L’e-Mail Marketing
Dunod – 2008 – ISBN : 978-2100514717

Dave Chaffey
Total E-mail Marketing: Maximizing Your Results from Integrated E-
marketing
Butterworth-Heinemann – 2006 – ISBN : 978-0750680677

Edith Nuss
Le cyber marketing, mode d’emploi : Créer de la valeur avec les
nouveaux médias
Éditions d’Organisation – 2006 – ISBN : 978-2708123533

Sites
Mantis (outil de bug tracking)
http://www.mantisbt.org

297
Partie II – La conduite des projets Web

Trac (outil de bug tracking)


http://trac.edgewall.org/
BugZilla (outil de bug tracking)
http://www.bugzilla.org
Comparaison d’outils de bug tracking
http://en.wikipedia.org/wiki /
Comparison_of_issue_tracking_systems
Site de Selenium (outil d’automatisation des tests fonctionnels)
http://seleniumhq.org/
Open Source Testing
http://www.opensourcetesting.org/
BrowserMob
http://browsermob.com
Arobase - L’e-mail sous toutes ses coutures
http://www.arobase.org
IAB Guidelines
http://www.iab.net/iab_products_and_industry_services/1421/
1443/1452
IAB, France
http://www.iabfrance.com/

298
Chapitre 12

Référencement
et positionnement

Figure 12-1
Les différentes étapes du positionnement

Le référencement est la phase incontournable qui permettra de donner de


la visibilité au site Internet. En effet, pour accéder à un site, l’internaute a
trois possibilités : saisir directement l’URL (ou utiliser ses favoris), cliquer
sur un lien ou encore utiliser un moteur de recherche. Le premier cas est
traité par la campagne de communication ofine qui doit aboutir à une
bonne mémorisation du nom du site et de son URL. Le deuxième est du
ressort de la campagne en ligne qui doit générer du trac via des actions
publicitaires et autres échanges de liens. Enfin, le troisième cas est l’affaire
du référencement mais, comme le nombre d’internautes qui recourent aux
moteurs augmente, le référencement ne suffit plus. Une nouvelle notion
est donc apparue : le positionnement.

299
Partie II – La conduite des projets Web

À noter : référencement et positionnement, deux notions complémentaires


Le référencement est l’action qui consiste à inscrire le site dans les outils de recherche. Le position-
nement consiste à mettre en œuvre une stratégie de référencement qui sera appliquée à l’ensem-
ble d’un site pour qu’il apparaisse, sur des expressions données, dans les premiers résultats des
outils de recherche (au pire les trente premières).

Cahier des charges

Le référencement doit impérativement faire l’objet de la rédaction


d’un cahier des charges qui va prendre en compte tous les aspects du
projet de référencement. C’est encore très marginal car le client a
souvent du mal à exprimer clairement ses attentes. La plupart du
temps, il se soumet à l’offre du prestataire. Or, la visibilité, qui
devrait être au centre des préoccupations des entreprises sur
Internet, est le plus souvent laissée au bon vouloir du référenceur.
S’adresser à un prestataire de référencement sans formaliser ses
besoins est dangereux dans la mesure où la prestation risque d’être
décevante pour l’entreprise. Elle peut aussi se solder par un événe-
ment désagréable, du type blacklistage (suppression du site de la
base d’un outil de recherche).
Très souvent, l’offre ne répondra pas aux besoins du client mais sera
toutefois contractée parce que le client est novice en la matière,
qu’elle est attrayante en termes de coût, de résultats, de garanties,
etc., sans pour autant répondre totalement aux attentes du donneur
d’ordre. Comme dans tout projet Web, n’oubliez pas qu’il incombe
au prestataire de répondre aux attentes du client et non au client de
se conformer à l’offre du prestataire…
La rédaction d’un cahier des charges est une base de travail qui sera
précieuse pour l’entreprise. Celle-ci pourra ainsi conduire le projet
de référencement en indiquant ses attentes en termes de trafic et de
contacts tout en comprenant quels sont les moyens mis en œuvre
par le prestataire. Le décideur disposera ainsi d’un véritable outil de
comparaison pour examiner les différentes offres qui seront réalisées
sur une base unique : la sienne car les offres de référencement
proposées par les prestataires sont toutes différentes et il est souvent
difficile de s’y retrouver.

300
Chapitre 12 – Référencement et positionnement

Stratégie

Aujourd’hui, tous les secteurs d’activités sont concurrentiels en


matière de référencement, même si certains le sont davantage que
d’autres. Prenons l’exemple des parkings et du stationnement, où la
visibilité d’un nouveau site est extrêmement difficile, comme pour
tant d’autres. Le mot-clé « parking» génère à lui seul plus de
224 millions de résultats dans Google ! Cependant, il est encore
possible de positionner le site de son entreprise dans les premiers
résultats en s’appuyant sur une stratégie de référencement perti-
nente, solide et pérenne dans le temps.

Figure 12-2
Première page de résultats obtenue dans Google pour le mot-clé « parking »

301
Partie II – La conduite des projets Web

Figure 12-3
La requête « location studio » génère 12 millions de résultats sur Google, ce
qui n’empêche pas le site http://www.location-etudiant.fr d’apparaître dans
les toutes premières positions depuis trois ans malgré un contexte
particulièrement concurrentiel : l'immobilier. Le secret : une stratégie de
référencement bien pensée en amont, une base de données optimisée de
manière automatique sur la base de calculs de densité pertinents, un contenu
mis à jour quotidiennement et de nombreux liens externes vers le site. Le site
bénéficie d’une veille constante et d’une révision de son référencement en
temps réel si nécessaire.

Le référencement repose moins sur une débauche de moyens que sur


une bonne stratégie. Depuis des années, l’objectif de nombreux réfé-
renceurs – et parfois même des responsables de sites – a été de déve-
lopper les visites coûte que coûte sans tenir compte de la pertinence
des contacts générés et de ce que l’on nomme le « trafic ciblé ». Ce
dernier repose sur des critères qualitatifs au détriment des critères
quantitatifs, très souvent sans intérêt puisque sans transformation du
contact. Ainsi, on a souvent vu des optimisations basées sur des mots-
clés générateurs de trafic mais peu pertinents pour le site visité et donc
pour l’internaute. Ce type d’action induit donc une multiplication de

302
Chapitre 12 – Référencement et positionnement

mots-clés parasites et de pages satellites, pratique sanctionnée par les


principaux outils de recherche.
Repère : le point sur les pages satellites
Créée spécifiquement pour les outils de recherche, la page satellite, souvent invisible pour les
internautes, redirige vers une page « normale » du site. Le principe devrait être réservé à des cas
particuliers, par exemple pour des sites tout en images, ceux réalisés entièrement avec Flash
(bien que les outils de recherche puissent désormais accéder au texte contenu dans les anima-
tions) ou en appui d’une stratégie globale de référencement portant sur un site extrêmement pau-
vre en nombre de pages. Malheureusement, nombre de professionnels s’appuient encore sur les
pages satellites pour référencer les sites, quels qu’ils soient, ce qui leur permet de ne pas avoir à
intervenir sur le contenu ; la pratique consistant à déposer les pages sur le serveur sans travailler
sur les « vraies » pages du site. Il faut noter que la plupart de ces pages sont créées par des logi-
ciels, sans qu'intervienne une réflexion humaine, c'est pourquoi elles sont très souvent dénuées
de sens pour qui les lirait.
Les nombreux abus issus de cette technique ont conduit les principaux outils de recherche à émet-
tre des recommandations négatives sur le recours aux pages satellites, certains sites possédant
plus de pages satellites que de pages réelles !
Le risque en la matière est de voir son site disparaître de la base du jour au lendemain, le moteur
estimant que ces pages dévaluent la pertinence des résultats et saturent les bases de données.
Netbooster, agence spécialisée en référencement, s’est vue déréférencée par Google pour avoir
utilisé ces pratiques1 il y a quelques années.  Source : Le Journal du
net, http://www.journaldu-
Pour obtenir de bons résultats en matière de référencement, le recours aux pages satellites est net.com/0409/
loin d'être utile. De nombreux sites leaders dans leur secteur n’utilisent aucune page satellite en 040916netbooster.shtml
appui de l’optimisation manuelle mise en œuvre car en la matière, rien ne remplace l’expérience
et la réflexion humaine. C’est le cas des sites tels que laguitare.com qui, en tant que spécialiste
des ressources pour les guitaristes, indique que 95 % des requêtes stratégiques pour sa visibilité
apparaissent dans les cinq premiers résultats de Google. Cela apporte un positionnement exem-
plaire, notamment dans Google, sur des mots-clés tels que guitare, actualité guitare, forum gui-
tare, etc. Ce site a investi dans une politique de référencement intelligente, solide et pérenne dans
le temps qui porte ses fruits depuis une dizaine d'années.

303
Partie II – La conduite des projets Web

Figure 12-4
Exemple de résultats obtenus pour le site laguitare.com qui est toujours
premier sur le mot générique guitare (15 millions de résultats), y compris
devant le fameux site Wikipédia.

La position de Google, qui s'oppose à la pratique des pages satellites, montre bien que les straté-
gies de référencement vont devoir évoluer. Le choix d’un prestataire capable de se remettre en
cause s’avère dès lors fondamental. En effet, générer des pages satellites avec un logiciel et opti-
miser manuellement un site Internet sont des métiers qu’on ne peut comparer. Or, face à la fluc-
tuation des stratégies des moteurs, seul un prestataire réactif peut garantir les résultats.
Au final, les pages satellites ne doivent en aucun cas constituer la base du référencement d’un
site, ce qui est malheureusement encore parfois le cas dans les prestations commercialisées par
certaines sociétés spécialisées dans le domaine du référencement.
Il est bien plus efficace et certain de générer des contacts ciblés en
s’appuyant sur l’optimisation manuelle des pages du site. La
réflexion humaine est indispensable et au-delà de la mise en œuvre,
il s’agit d’adapter la stratégie à chaque contexte et type de site et de
la faire évoluer tout au long de la vie du site. Un travail que seul un
humain peut accomplir.
Identifier le contexte concurrentiel
Cette étape doit permettre de disposer d’une vue d’ensemble des
concurrents directs ou indirects qui vont avoir un impact sur la
capacité de l’entreprise à positionner son site.

304
Chapitre 12 – Référencement et positionnement

Déterminer le processus de connexion


Le premier travail consiste à essayer de se mettre à la place des inter-
nautes – en recourant quand c’est possible à des entretiens en face à
face qui aboutissent à un résultat plus pertinent – pour déterminer
comment une cible précise atteint un type particulier de site. Les
scénarios de benchmark présentés dans les chapitres précédents
peuvent s’avérer fort utiles.
Par exemple, le processus de recherche d’un parking à louer à Paris
par un internaute peut être résumé ainsi :
• Saisie de mots-clés dans un moteur de recherche (location par-
king, annonces parking, sites parking, etc.).
• Saisie directe d’URL de sites connus.
• Après avoir fait le tour des sites généralistes et étudié les offres pour
se faire une idée de l’offre, l’internaute va affiner sa recherche.
• Saisie de mots-clés spécifiques dans un moteur de recherche
(nom de localité, autre précision géographique, etc.), par exem-
ple location parking métro Château de Vincennes, stationne-
ment gare de Marseille St-Charles, etc.
Forte de ces constats, l’entreprise peut situer l’offre de son site dans
la chaîne de valeur, ce qui l’aidera à déterminer une liste de moteurs
et de mots-clés pertinents.

Figure 12-5
Exemple de résultats obtenus pour le site http://www.location-parking.com
dont la stratégie de référencement couvre parfaitement la demande des
internautes, faisant de lui l’un des sites incontournables de son domaine.

305
Partie II – La conduite des projets Web

Identifier ses concurrents


En matière de référencement, les concurrents sont rarement ceux
auxquels on pourrait s’attendre car ce n’est pas l’activité réelle du site
qui compte mais plutôt les mots-clés utilisés par celui-ci. Ainsi, une
chaîne de télévision aura pour concurrents non seulement les autres
chaînes de télévision mais également les bijoutiers, les métallur-
gistes, les sites de vente de chaînes hi-fi.... Cette information est
fondamentale puisqu’elle oriente directement le choix des mots-
clés. En l’occurrence, s’il ne faut pas exclure la requête « chaîne », il
sera préférable de réfléchir à des requêtes plus ciblées telles que
« chaînes télé » ou «chaîne câblée ». De cette façon, le site sera mieux
positionné car le couple de mots-clés est pertinent par rapport à
l’activité.

Figure 12-6
Les résultats de recherche sur la requête « chaîne » dans Google font
apparaître des sites de domaines d’activité très différents. Il convient de
préciser la recherche.

306
Chapitre 12 – Référencement et positionnement

Lister les moteurs


Cette étape consiste à lister les moteurs qui devront être pris en
compte par les actions de référencement et de positionnement.
S’appuyer sur les moteurs incontournables
Les moteurs de recherches incontournables sont Google, Yahoo! et
MSN. À eux seuls, ils assurent plus de 90 % des recherches dans le
monde. En France, on peut ajouter Voilà qui dispose de l’audience
captive des abonnés Orange.

Figure 12-7
Seule une poignée de moteurs de recherche génèrent à eux seuls plus de 95 %
des recherches en provenance des outils de recherche.

Le site de l’entreprise devra forcément être référencé auprès de ces


moteurs pour espérer obtenir de bonnes positions dans les résultats
de recherches, y compris au travers des versions locales des moteurs
tels que Google, MSN Live Search ou Yahoo! qui sont déclinés dans
la plupart des langues et des pays. Évitez les propositions qui
« noient » les garanties en vous offrant des résultats sur des outils
très peu usités (Lycos, Altavista, Nomade, etc.) et exigez des garan-
ties pour les outils de recherche générant le maximum de trafic
(Google, MSN Bing et Yahoo!) car ce sont des valeurs sûres !

307
Partie II – La conduite des projets Web

Ajouter des moteurs secondaires spéciques


Parallèlement à ce travail, il est utile d’identifier les sites et les
moteurs spécialisés. Bien que non stratégiques, ils pourront aider, en
phase d’optimisation, à augmenter la popularité du site et donc à en
améliorer le positionnement.

Figure 12-8
Une société spécialisée en logistique aura intérêt à référencer son site sur le
site FraGGo (http://www.fraggo.com), ne serait-ce que pour augmenter sa
popularité.

Pour ce faire, il suffit de saisir des couples de mots-clés tels que


« moteur + spécialisé + domaine d’activité » dans les principaux
moteurs de recherche, ce qui devrait aboutir rapidement à une liste
de sites. Il est aussi possible de s’appuyer sur des sites spécialisés tels
que http://www.lesannuaires.com qui recensent moteurs et
annuaires professionnels.

308
Chapitre 12 – Référencement et positionnement

Figure 12-9
Le site Lesannuaires.com qui recense, comme beaucoup d’autres, les moteurs
spécialisés.

Trouver les bons mots-clés


Cette étape consiste à identifier les requêtes (souvent qualifiées de
« mots-clés ») qui sont les plus représentatives de l’activité et/ou des
services offerts par le site concerné mais également celles qui sont le
plus souvent utilisées par les utilisateurs. Cette réflexion repose sur
un dialogue constructif entre l’entreprise et son prestataire, la
confrontation des points de vue étant un bon moyen d’obtenir une
liste équilibrée, représentative et efficace.
En effet, une entreprise utilise souvent son propre vocabulaire,
lequel n’est pas toujours celui des visiteurs. L’idée principale est de
confronter les points de vue et de permettre d’obtenir une liste rela-
tivement large mais toujours pertinente et ciblée par rapport au
contenu du site. Par exemple, dans le domaine de la téléphonie
mobile, on a coutume de qualifier ces appareils de « téléphones
mobiles » ou de « mobiles » alors que le grand public, une fois sur
deux, les qualifie de « téléphones portables » ou de « portables ». Cet
exemple est très parlant puisque ne travailler que sur l’une ou l’autre
des occurrences équivaudrait à renoncer à environ la moitié du trafic

309
Partie II – La conduite des projets Web

potentiel en provenance des outils de recherche. C’est aussi une


manière de se conformer à la demande potentielle du public en
incluant ses expressions de recherche même si les appellations ne
nous semblent pas d’un grand intérêt.
Lister les mots-clés
Avec la professionnalisation du Web, les requêtes des internautes
sont elles aussi amenées à évoluer et contenir de plus en plus souvent
plus de deux mots-clés. L’entreprise doit donc essayer de lister des
groupes de mots en rapport étroit avec son activité. Plus ces mots-
clés seront précis et spécialisés, plus leur efficacité sera élevée.

Tableau 12-1
Répartition du nombre de mots par requête, en moyenne une requête est
composée de 2,44 mots-clés

NOMBRE DE MOTS PART DES REQUÊTES

1 mot 30,69 %
2 mots 26,80 %
Plus de 3 mots 17,61 %
Source : Baromètre Adoc, http://www.barometre.adoc.fr
On voit ici la nécessité de continuer à « sortir » dans les premiers
résultats des outils de recherche sur des requêtes d’un seul mot dans
la mesure où l’on constate que près d’un tiers des utilisateurs se limi-
tent à taper un seul mot pour guider leurs recherches. Cependant,
on note, année après année, une augmentation très sensible du
nombre de mots-clés tapés dans les outils de recherche.

310
Chapitre 12 – Référencement et positionnement

Figure 12-10
Exemple de résultats obtenus pour une requête d’un seul mot (parachute) dans
un contexte très concurrentiel (9 millions de résultats). Le site Air Libre
Parachutisme, petite école de parachute en Normandie, apparaît pourtant en
2e place de la liste de résultats.

L’analyse des statistiques est également un élément à prendre en


compte pour définir les mots-clés les plus utilisés par les utilisateurs
ayant accédé au site via les outils de recherche. Ces résultats permet-
tront de compléter l’étude des concurrents. Le chef de projet peut
parfaire cette première liste en utilisant les services de sites spécia-
lisés tels AdWords de Google1.  https://adwords.
google.com/select/
Confronter les mots-clés avec le prestataire main?cmd=KeywordSand-
box
La première liste de mots-clés sera ensuite confrontée au regard
critique du référenceur qui décèlera les mots inutiles, hors sujet ou
peu efficaces compte tenu du contexte. Le prestataire de référence-
ment joue un rôle d’arbitre dans ce domaine et doit écarter toute
requête qui ne lui semble pas correspondre à l’activité de l’entreprise
concernée. Ainsi, une entreprise industrielle travaillant au service du
secteur des cosmétiques n’a pas lieu d’opter pour une requête du
type « cosmétiques » mais plutôt pour « fournitures pour
cosmétiques ».
Cette tâche doit être confiée à un prestataire spécialisé dans le réfé-
rencement.
Repère : le point sur les packages
La plupart des référenceurs proposent des packages basés sur un nombre fixe de mots-clés, en
général de 10 à 50 mots.

311
Partie II – La conduite des projets Web

Cette solution, bien qu’attractive en raison de son coût peu élevé, peut aboutir dans certains cas à
un référencement trop… limité et vous priver d’un trafic intéressant.
Cette formule est d’autant moins adaptée que le travail de référencement doit être effectué « sur
mesure » pour être performant. De plus, une action spécifique doit être menée sur la base de don-
nées articles afin de créer une homogénéité des pages pour l’outil de recherche, d’élaborer des
formules particulièrement attractives pour les moteurs de recherche et d’optimiser tout nouvel arti-
cle qui intègre la base.
Les sociétés qui mettent en ligne un site comportant une base de données (catalogue produits,
annonces, etc.) ont besoin d'un travail axé sur de nombreux mots-clés pour refléter l’étendue de
leur offre.

Validation du livrable : des objectifs quantifiés


Avant de valider la stratégie de positionnement, il faut s’assurer que les objectifs sont quantifiés
clairement.

Mise en œuvre

La mise en œuvre d’une stratégie de référencement est un projet


toujours renouvelé. Après avoir optimisé et soumis le site, le référen-
ceur assure un suivi régulier sur les résultats obtenus. En fonction de
ceux-ci, il ajustera et affinera la stratégie mise en œuvre. Plus le
secteur est concurrentiel, plus la pertinence de la stratégie sera vitale.
La révision d’une stratégie de référencement validée et génératrice
de résultats probants peut aussi perdre tout son sens par la modifi-
cation d’une partie même infime de celle-ci, ce qui peut amener à
faire chuter la position du site ou au contraire permettre d’obtenir
des résultats dans les premières pages des outils de recherche. Il faut
réellement laisser toute latitude au référenceur pour qu’il décide de
réviser ou non la stratégie en cours et lui faire confiance car il saura
tirer avantage de ses expériences passées.

Optimiser le site
Cette étape consiste à optimiser, sans excès, la structure du site
(répertoires, nom des images, etc.), à renseigner les balises HTML
et « meta », à documenter les images et à préoptimiser les parties
dynamiques afin que la capacité de référencement du site soit maxi-
misée.

312
Chapitre 12 – Référencement et positionnement

Optimiser le code et la structure du site


Pour positionner le site, tous les éléments constitutifs des pages
comptent. Il est donc essentiel de penser la structure du site en
tenant compte des contraintes de référencement. Dans l’idéal, le
prestataire de référencement doit intervenir lors de la phase concep-
tion du site an de s’assurer qu’il va pouvoir être indexé de façon opti-
male. Ce sera d’ailleurs moins coûteux pour l’entreprise qui n’aura
pas à prévoir de grosses modifications de développement si cela se
révèle nécessaire.
Les répertoires peuvent comporter des mots-clés qui apparaîtront
dans l’URL du site. Ainsi, pour un site de location immobilière, il
peut être utile de remplacer un répertoire « images » par un réper-
toire « location », ce qui aura pour effet de changer l’URL du site en
http://www.site-immobilier/location/ au lieu de http://www.site-
immobilier/images/.
Les URL elles-mêmes doivent également faire sens autant que
possible. Par exemple, il est préférable de transformer les URL
incompréhensibles utilisées par certains sites dynamiques en URL
composées de mots, ce qui est possible avec la plupart des plates-
formes de développement permettant l’URL rewriting. En général,
on précise la rubrique et on reprend le titre de l’article pour obtenir
un résultat tel que :
• URL initiale : http://www.leprojetweb.com/
index.php?do=show&section_id=1&article_id=333&template
= content&theme_id=37
• URL optimisée : http://www.breek.fr/publication/10-criteres-
pour-bien-choisir-son-cms
Le nom des images peut aussi servir à optimiser le positionnement.
Le principe mis en application est le même que pour les URL. Il
s’agit par exemple de remplacer « 001465.gif » par
« livre_conduite_projet.gif ».
Les balises HTML peuvent également avoir un rôle dans la qualité
du référencement. C’est le cas des balises suivantes :
• les balises de titre <h1>, <h2>, <h3>, <h4>, <h5> ;
• les balises <alt>, <img> et <title> associées aux images et aux liens
hypertextes qu’elles contiennent.
Enfin, il est indispensable de favoriser le HTML autant que possible
et de limiter l’usage du JavaScript et du Flash aux illustrations, les

313
Partie II – La conduite des projets Web

menus déroulants en JavaScript ou en Flash n’étant pas (ou mal) pris


en compte par certains moteurs.

Bonne pratique : intégrer le référenceur à l’équipe projet


Intégrer le prestataire en charge du référencement dans l’équipe de conception permet d’obtenir de
meilleurs résultats car en procédant ainsi les contraintes de référencement auront été prises en
compte en amont du développement :
– nommage des pages et structure du site ;
– page d’accueil en HTML ;
– présence de liens et d’un paragraphe décrivant le site sur la page d’accueil avec utilisation
des mots-clés stratégiques ;
– choix optimal du nom de domaine ;
– présence de champs dédiés au référencement dans l’outil de gestion de contenu (balises
<title>, <alt>, etc.).

Renseigner les balises meta


Le référencement passe évidemment par le renseignement des
balises prévues pour décrire le contenu de la page. Ces balises
contiennent des métadonnées ; c’est la raison pour laquelle elles
portent le nom de balises meta.
La plus importante d’entre elles est certainement la balise <title>
qui est prise en compte par tous les moteurs de recherche. Pour
qu’elle soit efficace, elle doit être cohérente avec le contenu de la
page et varier de page en page.

Figure 12-11
La balise <title> est utilisée par tous les moteurs de recherche.

La balise <keywords> n’est plus prise en compte par les outils de


recherche. Elle est désormais peu utilisée au sein de la stratégie de
référencement, voire plus du tout.
La balise <description> est plutôt utilisée pour afcher une descrip-
tion du contenu de la page. Le moteur se sert en général des
premiers caractères d’une page en son absence, ce qui donne parfois
des descriptions curieuses. Pour optimiser cette balise, il faut rédiger

314
Chapitre 12 – Référencement et positionnement

des textes composés de phrases contenant les mots-clés stratégiques


pour le référencement.
La balise <revisit-after> est inutile dans la mesure où le passage des
robots des outils de recherche est déterminé par d’autres éléments.
C’est l’outil de recherche qui va décider de sa fréquence de passage
en fonction du volume du site, de sa régularité de mise à jour…
Une fois les balises renseignées, le chef de projet peut valider la
qualité du travail avec des outils en ligne comme Outiref 1. Il  http://www.outiref.com

convient de rappeler que pour obtenir de bonnes positions, le


travail n’étant pas mécanique, il doit être appréhendé dans la
durée.
Mettre à jour
La mise à jour régulière d’un site, et notamment de la page d’accueil,
est un facteur à prendre impérativement en compte dans la stratégie
de référencement.
Les mises à jour étant décelées par les outils de recherche lors du
passage de leurs robots, les délais de passage de ceux-ci seront
notamment plus réguliers.
Par ailleurs, l’intégration de nouvelles pages et/ou de contenus
textuels au fil du temps est également à prévoir tant pour les visi-
teurs que pour les outils de recherche.
URL rewriting
Tout le monde a compris depuis longtemps qu’avoir l’un de ses
mots-clés stratégiques dans son URL est l’un des maillons de
l’énorme puzzle qui va aider au positionnement de son site.
Or, depuis l’apparition de l’URL rewriting, par exemple, tout le
monde s’est mis à utiliser (parfois de façon excessive) cette technique
d’optimisation qui consiste à ce que les noms des fichiers contien-
nent le maximum de texte optimisé, par exemple : http://
www.monsite.com/achat-maison-paris/studio-paris.php.
De ce fait, si la plupart des sites sont désormais sur un pied d’égalité
de ce côté-là, sans dire que ça ne sert à rien, il fallait s’attendre à ce
que ce critère perde de sa valeur, ce qui semble déjà être le cas.
En conclusion, évitez de suivre uniquement les modes (qui ne sont
qu’éphémères) et pensez stratégie de référencement globale...

315
Partie II – La conduite des projets Web

Indice de popularité et page rank


Si une action de liens entrants peut contribuer à accélérer la procé-
dure d’indexation, le doute persiste sur la notion de « page rank »
qui serait pour partie « responsable » de classements privilégiés dans
les meilleures places.
Cet élément n’est, pour moi, qu’une partie du « puzzle » qui va
permettre un référencement efficace du site. J’ai mené de nombreux
projets qui étaient totalement dénués de liens extérieurs et qui ont,
malgré cette « lacune », bénéficié de résultats exemplaires.
Prenons l’exemple du site de MaCosmetoPerso (www.macosmeto-
perso.com) qui a, dès le début de la mise en place de sa stratégie de
référencement, figuré dans les meilleures places des outils de
recherche (et notamment de Google) avec une URL « toute neuve »
et un page rank de 0 (ce qui est toujours le cas). Le site génère plus
de 700 visites par jour dont 80 % proviennent des outils de
recherche. Sur 300 requêtes testées, le site est présent pour 90 %
dans la première page de Google.
Beaucoup de cas similaires existent parmi ma clientèle. Je considère
donc que les liens externes ne sont qu’un élément de la stratégie de
référencement mais qu’il ne faut pas tout miser sur eux : la mise en
œuvre d’une solide stratégie de référencement est ce qui fait réelle-
ment la différence au final.
Par ailleurs, l’exemple de MaCosmetoPerso permet de se rendre
compte que le site a acquis en très peu de temps un trafic ciblé (plus
de onze pages vues par visite et un fort taux de rendement en termes
de ventes) avec un page rank de 0, trafic acquis uniquement par le
biais de son indexation dans les outils de recherche et de sa stratégie
de référencement, ce qui donne peu de sens aux opérations visant à
« vendre du page rank ».
Si vous souhaitez toutefois exercer une veille sur cet aspect, vous
pouvez télécharger la barre d’outils Google qui fournit des indica-
tions concernant le page rank. À noter, l’apparition d’une barre
d’outils spécial référencement chez Mozilla Firefox.

316
Chapitre 12 – Référencement et positionnement

Figure 12-12
La barre SEO de Mozilla Firefox donne de nombreuses informations sur le site
que vous visitez (page rank, date de naissance du site, nombre de pages
indexées, liens externes…).

Soumettre le site
Une fois le site optimisé, il ne reste plus qu’à le proposer aux
moteurs de recherche et l’inscrire dans les annuaires. Ce travail doit
rester manuel pour les moteurs les plus importants.
Inscrire le site dans les moteurs
Cette étape est certainement la plus simple puisqu’elle consiste à
saisir l’URL du site dans le champ de saisie prévu à cet effet !
Chaque moteur fournit sa propre interface. Les plus importantes
sont listées ci-après.

Tableau 12-2
URL de soumission de site de quelques moteurs internationaux et français

OUTIL DE RECHERCHE URL DE SOUMISSION

Google.com http://www.google.com/addurl/?continue=/addurl
Yahoo.com https://siteexplorer.search.yahoo.com/submit
Msn.com http://search.msn.com/docs/submit.aspx?
Google.fr http://www.google.fr/addurl/?continue=/addurl
Yahoo.fr https://login.yahoo.com/config/
login_verify2?.src=srch&.intl=fr&.done=http://fr.siteex-
plorer.search.yahoo.com/free/request&rl=1
Msn.fr http://search.msn.fr/docs/submit.aspx?

Une fois l’URL soumise, il faut être patient, les moteurs pouvant
prendre en compte plus ou moins vite la demande. On évalue en
général le délai de prise en compte de deux jours à plus de 6 mois.

317
Partie II – La conduite des projets Web

Dans l’intervalle, il ne faut surtout pas resoumettre l’URL car cela


pourrait s’apparenter à du « spamindexing », une pratique que les
moteurs de recherche n’apprécient pas du tout.
Il en va de même pour la durée du projet. Lorsque le site est présent
dans une base d’un outil de recherche, il s’avère inutile de le
soumettre de nouveau. C’est même très mal perçu par les moteurs
de recherche… Par ailleurs, les robots passant sur les sites à inter-
valles plus ou moins réguliers, vos nouvelles pages, rubriques, etc.,
seront découvertes et prises en compte « naturellement » par les
robots sans que vous ayez à intervenir.
Inscrire le site dans les annuaires
Quand la pression concurrentielle est très forte ou qu’aucune stra-
tégie de positionnement n’est envisagée, l’achat de mots-clés (les
liens sponsorisés) est une alternative intéressante bien qu’elle puisse
se révéler plus coûteuse dans le temps puisque le lien sponsorisé a un
effet ponctuel et le positionnement une durabilité dans le temps.

Figure 12-13
L’interface de soumission de l’Open Directory (http://www.dmoz.org), l’un
des principaux annuaires internationaux

318
Chapitre 12 – Référencement et positionnement

Acheter des mots-clés


Une des techniques complémentaires au référencement manuel
peut consister à acheter des mots-clés auprès des principaux
moteurs.
Attention, l’achat de mots-clés ne doit pas être assimilé à du référen-
cement (méfiance envers certaines sociétés de référencement qui
essaient de semer le doute dans les esprits…) mais à de la publicité
payante.
D’excellents ouvrages existent sur ce thème qui relève plus de la stra-
tégie de visibilité online que du référencement.
Suivre la progression du site
Le positionnement d’un site évolue en permanence en fonction des
nouvelles soumissions réalisées chaque jour. Le suivi du positionne-
ment consiste à vérifier tous les mois la position du site dans chaque
moteur, puis à rédiger une synthèse. Sur la base de ce rapport et en
fonction des objectifs présents dans le contrat de positionnement,
des actions correctives doivent être réalisées.
Pour bien suivre l’évolution de votre projet et de l’impact du travail
du référenceur, il est impératif de demander un audit de départ
avant optimisation. Ce document vous servira de point de départ et
vous permettra de vérifier l’évolution des résultats.
Si 6 mois après le lancement du site, ce dernier est bien positionné
et que les positions sont stables sur les 3 derniers mois, c’est que la
stratégie est bonne. Les résultats ne devraient par la suite varier que
légèrement.
Cette tâche est toujours réalisée par le prestataire assurant le posi-
tionnement.

319
Partie II – La conduite des projets Web

Tableau 12-3
Exemple de tableau de suivi de positionnement
Évolution des résultats Google.fr (étude des 30 premiers résultats hors liens
sponsorisés) pour le site MaCosmetoPerso (démarrage du projet/milieu du
projet/août 2009)
MOTS-CLÉS AVRIL 2009 AOÛT 2009
actifs anti-inflammatoires 29 1
actifs antioxydants 27 2
actifs bonne mine 25 1
actifs cheveux – 2
actifs cicatrisants 18 1
actifs cosmétiques 19 4
actifs hydratants 28 6
actifs lissants 16 1
actifs peaux à problèmes 11 1
actifs peaux matures 14 1
actifs réparateurs 12 1
additifs cosmétiques 26 5
additifs en poudre 24 3
additifs liquides 8 1
arôme naturel cosmétique 10 9
beurres végétaux 10 2
cires florales 10 1
contenants maquillage 9 1
exfoliants naturels 13 2
hydrolats bio 21 4
macérats bio 8 1
moules savons 14 2
poudres de fruits 7 1
poudres de plantes 11 5
protéines naturelles 29 8
ustensiles cosmétiques 10 3

320
Chapitre 12 – Référencement et positionnement

Ajuster la stratégie
Cette tâche consiste à modier certaines balises et à optimiser ou
réoptimiser les parties du site qui ne donnent pas satisfaction. Elle
est toujours réalisée par le prestataire assurant le positionnement.
Repères : les 10 éléments clés de la stratégie de référencement
1 – Nom de domaine comportant les deux mots-clés principaux.
2 – Nom des répertoires.
3 – Nom des fichiers (pages, images, etc.).
4 – Balises HTML (<alt>, <title>).
5 – Un contenu texte et un volume de pages suffisant.
6 – Être référencé dans les outils de recherche principaux.
7 – Ne pas utiliser que des mots-clés génériques et privilégier les requêtes contenant plusieurs
mots pour cibler celles permettant de générer des contacts utiles (sur Google :
« location » = 206 millions de résultats, « location voiture » = 2 millions de résultats, « location
voiture paris » = 960 000 résultats).
8 – Inscrire également le site dans les bases des grands outils de recherche internationaux, y
compris quand le site n’est destiné qu’à la France.
9 – Favoriser un référencement « naturel », sans logiciel ni pages satellites.
10 – Toujours penser qualité des contacts plutôt que volume de trafic.

Pour aller plus loin

Ouvrages
Francois-Xavier Hussherr et Sophie Néron
Comportement de l’internaute
Dunod – 2002 – ISBN : 978-2100064083
Collectif d’auteurs
Le Keyword marketing 2007
Abondance.com – 2007 – Étude au format PDF, disponible en télé-
chargement uniquement sur le site Abondance (http://
www.boutique-abondance.com/cgi-bin/pg-
shoppro.cgi?ORD=viewproduct&id_product=11&id_category=3)

321
Sites
Web Rank Info – Au cœur de Google
http://www.webrankinfo.com
Abondance – Référencer sans soucis
http://www.abondance.com
Le blog de La Sorcière du Référencement
http://www.lasorcieredureferencement.com/
Chapitre 13

Impact du Web 2.0


sur les projets
Web

Le Web 2.0

Après un peu plus de 10 ans de maturation, le Web sort de l’enfance et


attaque une seconde étape importante de son évolution. Les implications
techniques et sociales de cette mutation sont si importantes et si
nombreuses qu’on les intègre toutes aujourd’hui dans le concept de
« Web 2.0 ».

Une évolution sociale


Le permier volet du Web 2.0 est social : un milliard d’internautes s’appro-
prient enfin cet outil dans leurs usages quotidiens. En France, par exemple,
plus de la moitié de la population est connectée et ce chiffre atteint 86 %
chez les 13-24 ans.
Ces derniers imposent progressivement leur vision du Web. Ils le construi-
sent à leur image, très différente de la vision que leur impose le Web « insti-
tutionnel », constitué des moteurs de recherche, des sites d’entreprises et
des sites marchands. Le Web 2.0 n’est pas la toile des entreprises, mais bien
celle des internautes. Ils passent notamment d’un statut de consommateurs
passifs à celui de contributeurs actifs. Cette « prise de pouvoir » bouleverse
le rôle des acteurs historiques de la toile, modifiant complètement le
rapport de force entre les entreprises et les consommateurs.
Par exemple, les blogs drainent une audience de plus en plus importante
(9 millions de blogs en France en 2006, source Journaldunet : http://
www.journaldunet.com/diaporama/0604 blogs/2.html) car ils permettent à
n’importe quel citoyen d’exprimer ses points de vue. Ces nouveaux « sites

323
Partie II – La conduite des projets Web

persos » ne demandent que quelques clics pour être mis en œuvre.


Structurés en réseau, les blogs forment une nouvelle toile, véritable
contre-pouvoir citoyen face aux sites institutionnels et marchands.
En parallèle de ce réseau de blogs, une troisième toile est en train de
se former, reposant sur les favoris en ligne des internautes. Les
systèmes de del.icio.us et Yahoo! Mon Web 2.0 leur permettent de
« marquer » n’importe quelle page Web à l’aide de mots-clés.
Stockés en ligne, ces « mots-clés favoris » sont partagés par les inter-
nautes qui créent ainsi une nouvelle génération de moteurs de
recherche basés sur l’intelligence collective de millions d’utilisateurs.
L’impact pour les entreprises est important car pour une même page
Web, les internautes ne choisissent pas du tout les mêmes mots-clés
que les moteurs de recherche. Par exemple, les pages du site Web de
Total peuvent être affublées de mots-clés tels que « marée noire »,
« Erika », « pollueur », etc.
Désormais, quelles que soient les sommes investies en référence-
ment sur les moteurs traditionnels, il existe une toile parallèle sur
laquelle les entreprises ne maîtriseront plus jamais leur image.
Issu du mouvement peer-to-peer, le partage est l’une des valeurs qui
distinguent clairement le Web 1.0 du Web 2.0. L’encyclopédie en
ligne Wikipédia en est l’illustration parfaite. Construit par des
centaines de milliers de bénévoles, ce site bouleverse le marché des
encyclopédies payantes et l’accès à l’information dans le monde. Elle
n’est que le premier exemple d’une longue série de sites collaboratifs
qui vont peu à peu concentrer le savoir du monde autour de théma-
tiques aussi différentes que les vins, l’informatique, l’art, etc. Pour
voir le jour, ces sites s’appuient sur deux axes : le besoin de recon-
naissance et d’appartenance de tout être humain, et une infrastruc-
ture technique – les wikis – facilitant la création collaborative d’un
site Web à mi-chemin entre une base de données, un forum et un
site traditionnel.

Une évolution technique


Les développeurs perçoivent souvent le Web 2.0 comme un non-
événement et le résument à un simple concept marketing. Cette
situation est essentiellement due au fait que le Web 2.0 repose sur
des technologies existantes.
Pourtant, les architectures mises en œuvre sont totalement nova-
trices. Elles consistent notamment à appliquer au Web le concept
d’architecture orientée services (SOA) et ses principes fondateurs :
découplage fort entre les différentes couches, échanges asynchrones,

324
Chapitre 13 – Impact du Web 2.0 sur les projets Web

notion de domaine privé et public…. De l’interface utilisateur à la


structure de la base de données, toutes les couches techniques sont
profondément impactées.
Selon les concepts du Web 2.0, un même service possède par
exemple plusieurs interfaces contre une seule interface HTML pour
le Web 1.0. Cette caractéristique permet de proposer plusieurs
façons d’accéder aux contenus et services d’un site, chacun étant
adapté à un usage précis. Ces interfaces sont à la fois destinées aux
internautes – HTML, flux RSS, client riche… – et aux machines –
API REST publiques, flux RSS, etc. Cela signifie donc que les trai-
tements du modèle 3-tiers doivent être totalement autonomes par
rapport à la couche de présentation. Un impératif technique dont
très peu de sites peuvent se targuer à l’heure actuelle.
Le changement le plus visible pour l’utilisateur final est logiquement la
couche de présentation. L’interface utilisateur repose sur l’architecture
Ajax (Asynchronous JavaScript and XML) qui reproduit au sein du
navigateur le modèle de programmation événementielle du client-
serveur traditionnel. Plutôt que de générer des écrans HTML (modèle
du Web 1.0), le serveur d’application se contente d’exposer des
données et des traitements sous la forme de flux XML. Alors qu’elle
était jusqu’à présent entièrement générée côté serveur, la couche de
présentation du Web 2.0 est complètement déportée du côté client
avec Ajax. Le client Ajax s’exécute en effet au sein du navigateur. Il est
constitué d’une librairie de fonctions JavaScript, de feuilles de style
CSS et d’un peu de code HTML. Chaque composant graphique de
l’interface dialogue avec le serveur à l’aide de flux XML en fonction
d’événements locaux : clic sur un lien hypertexte, saisie d’une chaîne
de caractères, etc. Chaque composant possède donc un comportement
autonome qui permet d’éviter d’avoir à recharger toute la page : seul le
composant incriminé à un instant t est mis à jour. La notion de site
Web disparaît donc au profit d’applications clientes.
Avec un tel niveau de découplage entre la couche de présentation et
les données et services sous-jacents, la toile se transforme à la fois en
une gigantesque base de données et en une plate-forme de développe-
ment d’applications composites. Les API REST et SOAP et les flux
RSS/Atom s’appuient sur le langage XML pour exposer des données
structurées et des traitements à l’aide d’une simple URL. Ce point est
fondamental car il signifie d’une part, que derrière une URL peuvent
maintenant se trouver des données qui ne sont pas destinées à être lues
directement par les internautes, et d’autre part, que la structure même
des sites 2.0 est d’abord construite autour du modèle de données et

325
Partie II – La conduite des projets Web

non plus autour d’un « rubriquage ». L’architecture technique et la


méthodologie du Web rejoignent donc celles des logiciels tradition-
nels. Cette évolution est particulièrement visible dans les outils de
développement qui font de moins en moins la distinction entre Web
et logiciel traditionnel. Par exemple, dans le monde Microsoft, les
développeurs utilisent indifféremment Visual Studio.NET pour créer
des sites Web et des logiciels destinés aux postes de travail.
Pour l’entreprise, les nouvelles interfaces XML sont synonymes d’une
plus grande ouverture. Il est désormais extrêmement facile d’échanger
des données (commande, client, fiche produit, etc.) entre deux sites en
s’appuyant sur l’architecture technique existante (un serveur HTTP et
un serveur d’applications suffisent). Cela signifie que n’importe quelle
PME peut aujourd’hui mettre en œuvre des échanges EDI avec ses
partenaires, pour le coût de création d’un site Web.
Une quatrième et une cinquième toile apparaissent donc. La
quatrième est composée des sources de données au format XML. La
cinquième est constituée de services imbriqués les uns avec les autres
au sein d’applications composites (mash-up en anglais). Alors que le
Web 1.0 était constitué de silos d’informations (les sites), le Web 2.0
se caractérise donc par une plus faible granularité de l’information :
objets et services métiers exposés sous la forme de flux XML.
Ajax (Asynchronous JavaScript and XML)
Nouvelle architecture des interfaces client Web. Elle déplace le site dans des librairies de fonctions
qui s’exécutent directement au sein du navigateur. Le serveur se contente donc de fournir des don-
nées au client Ajax. Il ne génère plus l’interface utilisateur.

API (Application Programming Interface)


Les interfaces publiques de programmation SOAP et REST exposent des traitements et des
données au format XML. Elles simplifient l’échange d’informations d’un site à l’autre et d’une
entreprise à l’autre.

Atom
Format et protocole de publication d’information basé sur XML. Mis au point par l’IETF et soutenu
notamment par Microsoft et Google, Atom est le successeur de RSS.

RSS (Really Simple Syndication)


Enveloppe XML standard permettant de transporter n’importe quelle information ou donnée d’un
site à l’autre. RSS et Atom sont les nouveaux « ODBC du Web ».

SAAS (Software As A Service)


Concept désignant toutes les applications hébergées modernes qui ont été développées en s’appuyant
sur une architecture de service. C’est la deuxième génération d’applications ASP hébergées.

326
Chapitre 13 – Impact du Web 2.0 sur les projets Web

SOA (Service Oriented Architecture)


Une architecture orientée services privilégie un découplage fort entre les données, les services
(ensemble logique de traitements), et la couche de présentation. Cette architecture facilite la
transformation des sites Web en de véritables plates-formes d’échanges XML : flux RSS, API REST,
interface graphique Ajax, etc.

Tableau 1-12
De la toile des sites Web aux multiples toiles du Web 2.0

CONCEPTS UNITÉ DE RECHERCHE OUTILS DE RECHERCHE


WEB 1.0 Sites web Mots-clés affublés Yahoo!, Google, MSN
et pages HTML par les moteurs
aux pages HTML
WEB 2.0 Posts des blogs, Tags Del.icio.us, technorati
sites collaboratifs
API REST et SOAP Tags Programmable web
Flux RSS et Atom Tags Rollyo, Dig !
Favoris en ligne Tags Del.icio.us, Yahoo!
Mon Web 2.0, etc.

Quelques exemples concrets

Figure 13-1
L’encyclopédie en ligne Wikipédia est entièrement élaborée par des dizaines
de milliers d’internautes bénévoles. Chaque page du site peut être enrichie
car elle repose sur un outil de collaboration adapté : le wiki.

327
Partie II – La conduite des projets Web

Figure 13-2
Grâce à Yahoo! Mon Web 2.0, chaque internaute peut désormais partager
ses favoris en ligne et leur attribuer des mots-clés. Une nouvelle toile consti-
tuée des mots-clés des internautes fait donc son apparition.

Figure 13-3
Pionnier des services Web REST, le site d’Amazon possède des dizaines de
milliers de partenaires qui puisent chaque jour dans son catalogue XML pour
construire des librairies en ligne virtuelles.

328
Chapitre 13 – Impact du Web 2.0 sur les projets Web

Figure 13-4
Connu pour son outil de CRM hébergé, salesforce.com propose aussi une
infrastructure technique qui permet à ses partenaires de développer leurs
outils directement sur sa plate-forme AppExchange. Les partenaires utilisent
pour cela les API publiques de AppExchange qu’ils peuvent marier aux leurs,
et même, avec celles d’autres entreprises. C’est par exemple le cas de Skype.

Figure 13-5
Partenaire de salesforce.com, spanning salesforce.com expose l’ensemble
des événements et des objets métier d’un utilisateur de salesforce.com à l’aide
des flux RSS. L’entreprise peut donc, par exemple, alimenter son ERP en temps
réel avec les données saisies dans salesforce.com.

329
Partie II – La conduite des projets Web

Ce qui change dans les projets

Projets individuels et projets d’entreprise


Aujourd’hui, les acteurs les plus innovants sont les entrepreneurs
individuels. Ils lancent (comme en 1999) des projets de start-up
avec optimisme et conviction, sans réserves, ni tabous, ni idées
préconçues, ce qui change tout dans la conduite du projet.
Moins de moyens, plus d’ambition = plus pragmatique
Ces nouveaux Don Quichotte quittent leur travail confortable de
salarié pour une aventure au succès indéterminé et des revenus à
coup sûr très faibles. Pourquoi cette folie ? Pour se faire plaisir ! Mais
aussi pour décrocher le gros lot avec un rachat rapide ou un succès
fulgurant.
Du coup, leur façon d’aborder un projet est forcément plus pragma-
tique que les hommes de l’art. Et pour cause, leurs contraintes ne
leur permettent pas de faire autrement. Le budget est souvent faible
et les connaissances techniques limitées.
Première conséquence, les méthodes de travail doivent être drasti-
quement allégées à la fois pour rentrer dans le budget et pour être
utiles. Les phases de spécification et de développement ne doivent
pas être longues. La documentation doit être réduite au minimum
vital pour avoir une chance d’être lue. La démarche générale est
forcément itérative, les nouvelles idées chassant les anciennes spéci-
fications aussi sûrement que le business model évolue !
Plus de risques, plus de confiance
Les risques étant énormes pour ces acteurs (souvent toutes leurs
économies), ils ne peuvent pas se permettre de ne pas réussir.
Comme leurs moyens sont limités, la seule façon de réduire les
risques est de trouver un partenaire, de bâtir une relation de
confiance avec lui et de tirer parti de son savoir-faire.
Cet état d’esprit change radicalement la façon de conduire le projet
car à partir du moment où la confiance existe réellement, il devient
possible de travailler avec des méthodes plus agiles.

Co-design
Les nouveaux services Web 2.0 étant centrés sur l’utilisateur, celui-
ci prend un rôle de plus en plus important dans la réussite du projet
(animation, production de contenu). Conscient de sa valeur, l’utili-

330
Chapitre 13 – Impact du Web 2.0 sur les projets Web

sateur s’attend de plus en plus à participer à l’évolution d’un projet


qu’il considère être autant le sien que celui des fondateurs.
Écouter les utilisateurs…
Il devient alors incontournable d’écouter ses utilisateurs et notam-
ment les demandes de nouvelles fonctionnalités. De nombreux
moyens sont aujourd’hui à notre disposition :
• bug trackers (Mantis, Trac, etc.) ;
• forums ;
• wikis ;
• listes de diffusion…
La difficulté se situe donc davantage au niveau stratégique qu’au
niveau organisationnel car satisfaire toutes les demandes est épui-
sant et concourt à perdre l’âme du projet. Or, sans âme, le projet n’a
pas d’attrait. Ainsi, 37signals.com explique dans sa méthode Getting
Real (http://gettingreal.37signals.com/toc.php) pourquoi leur stra-
tégie est de ne satisfaire que les demandes vraiment essentielles, et
encore, seulement après avoir reçu un ouragan de demandes.
Écouter les utilisateurs pose donc le problème du commiter, rôle qui
consiste – comme lors d’une recette – à réceptionner toutes les
demandes, les catégoriser et surtout, les hiérarchiser pour finale-
ment décider laquelle est digne d’être prise en compte. De ce point
de vue, les communautés de développement de logiciels open source
ont beaucoup à nous apporter : elles fonctionnent sur ce modèle
depuis plus de 15 ans.
…et adapter le rythme des releases
Avant même de prendre en compte les besoins et suggestions des
utilisateurs, il est impératif de définir un rythme de mise à jour – la
fameuse roadmap – et de s’y tenir.

Choisir la bonne démarche

Les démarches linéaires sont de plus en plus opposées aux méthodes


dites « agiles ». Ces dernières profitent du Web 2.0 et de l’évolution
des mentalités pour se diffuser. Mais attention, bien que très inté-
ressantes, les méthodes agiles ne sont pas miraculeuses et ne doivent
pas être utilisées systématiquement.

331
Partie II – La conduite des projets Web

Les démarches linéaires


Principe
Leur fondement est le découpage du projet en phases et étapes qui
ne peuvent s’enchaîner sans la validation de la précédente (c’est ce
que présente cet ouvrage). Elles sont intimement liées au mode de
relation dit « client-fournisseur ». Dans cette relation, le client est
roi et le fournisseur se plie à ses ordres, sans broncher. C’est la rela-
tion la plus courante en France en 2008. Elle instaure des obliga-
tions réciproques très claires et impératives. Chaque partie se
protège donc le plus possible de manière à limiter la casse en cas de
problème (pénalités de retard, responsabilité, engagement de moyen
vs résultat...).
Forces et faiblesses des démarches linéaires
Le principal avantage des démarches linéaires est la délimitation
précise du périmètre de chacun, ce qui constitue un atout important
dans le pilotage d’un projet car théoriquement les zones d’ombre
susceptibles de gripper le projet suite à une incompréhension sont
éliminées en amont du projet. Les principaux inconvénients des
démarches linéaires sont le manque d’implication du client et
l’absence de confiance réciproque. Pour pallier cela, le prestataire
s’en tient aux spécifications même quand il est persuadé qu’elles sont
obsolètes. Il essaye ensuite, par obligation, de maintenir à jour la
documentation... mais n’y parvient que rarement. Très vite, ce sont
deux projets qui doivent être gérés : d’une part le développement et
d’autre part, la « paperasse » (c’est le terme qui revient le plus
souvent...). Au final, le client obtient sa commande mais sans réelle
valeur ajoutée, et les équipes de développement se contentent du
minimum syndical car il est peut motivant de développer un projet
obsolète ou illogique.
Les méthodes agiles
Principe
Les méthodes agiles sont nées dans les années 1980-90, notamment
avec la méthode RAD (Rapid Application Development), définie par
James Martin, et DSDM (Dynamic Systems Development Method),
créée par Jennifer Stapleton. Ces méthodes visent à combler les
lacunes des démarches linéaires. Les quatre principes fondamentaux
de ces méthodes sont :
• les individus et les interactions plutôt que les processus et les
outils ;

332
Chapitre 13 – Impact du Web 2.0 sur les projets Web

• des fonctionnalités opérationnelles plutôt qu’une documentation


exhaustive ;
• la collaboration avec le client plutôt que la contractualisation des
relations ;
• l’acceptation du changement plutôt que la conformité aux plans.
Les méthodes les plus utilisées sont RUP (Rational Unified Process,
propriété d’IBM depuis le rachat de Rational Software), XP et
Scrum. Plus récemment, 37signals.com a vendu des centaines de
milliers d’exemplaires de sa méthode Getting Real (et offerts des
millions de téléchargements gratuits) qui reprend à son compte les
principes des méthodes agiles en y ajoutant encore plus de pragma-
tisme et en se recentrant sur les applications Web.
Forces et faiblesses des méthodes agiles
Les principales forces des méthodes agiles sont la souplesse et la rapi-
dité de mise en œuvre, rendues possibles grâce aux itérations et aux
livraisons régulières. Les utilisateurs voient plus rapidement un
résultat plus concret. Le résultat final est plus en accord avec le
besoin réel, exprimé initialement ou non. Ce sont donc des
méthodes idéales quand tout se déroule correctement. Malheureu-
sement, cette efficacité repose sur une réelle collaboration entre le
client et son prestataire, aucun des deux ne pouvant garantir à
l’avance le respect du budget et des délais. Ce n’est donc pas la
méthode qui est en cause mais la nature de la relation qu’elle
implique car une relation d’égal à égal, et non de soumission, est en
contradiction avec les pratiques actuelles en France.

Quelle méthode choisir ?


Le tableau ci-après résume dans quels cas recourir à l’une ou l’autre
des méthodes agiles. Il ne s’agit bien sûr que d’un résumé. Le recours
à un spécialiste en AMOA reste incontournable pour vous décider.

Tableau 13-2
Quelle méthode choisir ?

MÉTHODE MÉTHODE
CONTEXTE
LINÉAIRE AGILE

Plus de 100 jours de développement (par lot ou unité d'œuvre) X


Maîtrise impérative du budget X
Maîtrise impérative du planning X

333
Partie II – La conduite des projets Web

Culture managériale « fermée » (je me protège avec mon cahier X


des charges, je transfert les risques sur mes prestataires)
Pas de confiance réciproque (jamais travaillé ensemble, pas envie X
de travailler ensemble, etc.)
Projet complexe (application métier) X X
Équipe externe X X
Co-design X
Projet simple (blog, site institutionnel) X
Moins de 30 jours de développement (par lot ou unité d'œuvre) X
Culture managériale « ouverte » (je travaille en réel partenariat X
avec mes prestataires, je partage les risques)
Confiance réciproque (on travaille ensemble depuis longtemps, X
principe de vivier, etc.)
Équipe interne X

Limiter les risques juridiques liés au


Web 2.0

En repositionnant l’internaute au cœur du Web, le Web 2.0 entraîne


l’évolution des business models, des risques et des responsabilités juridi-
ques, associés jusque-là à l’exploitation des sites et des services Web.

Nouveaux usages…
En utilisant les nouveaux services Web 2.0 permettant de créer,
organiser et partager librement au sein d’une communauté les
contenus les plus divers (textuels, sonores ou visuels), chaque inter-
naute endosse le statut d’auteur/contributeur et une nouvelle
responsabilité liée à la fois à ses propres créations et à l’usage qu’il
fait de celles des autres.
Avec le Web 2.0, l’internaute passe ainsi du statut de « simple visi-
teur/consommateur » à celui de véritable contributeur jusqu’à
prendre, dans certains cas, la maîtrise du contenu d’un service Web
avec toutes les dérives induites en termes de violation des droits de
tiers, qu’ils s’agissent de droits d’auteurs, de droit des marques,
d’atteinte à l’image ou de diffamation.
Ce qui n’était qu’un usage occasionnel ou réservé à certains inter-
nautes (pages Web personnelles ou blogs) est en train de se généra-

334
Chapitre 13 – Impact du Web 2.0 sur les projets Web

liser au travers de nouvelles formes de services (vidéoblog, flux RSS,


service de stockage et de partage de contenus en ligne, création
instantanée d’espace personnel ou de pages Web en ligne, etc.).
Tout le monde devient ainsi responsable ou est susceptible d’avoir
sa part de responsabilité dans le monde du Web 2.0, ce qui n’est pas
sans poser des contraintes et risques juridiques supplémentaires ou
nouveaux aussi bien pour les internautes que pour les titulaires de
droits et les éditeurs des services Web 2.0.

…nouveaux risques
Sur le plan juridique, ses nouveaux services peuvent s’apparenter le
plus souvent aux forums de discussion, aux blogs et aux pages
personnelles mais ils présentent toutefois des risques beaucoup plus
importants du fait de la diversité et de l’origine des contenus mis à
disposition par chaque contributeur.
En la matière, la difficulté réside plus particulièrement dans
l’augmentation quasi exponentielle du nombre de créateurs occa-
sionnels ou réguliers de contenus susceptibles de porter atteinte aux
droits de tiers.
Qu’il s’agisse de textes, d’images ou de vidéos, les contenus mis à
disposition par les internautes empruntent souvent, en tout ou
partie, à des œuvres existantes sans que les contributeurs ne se
soucient du recueil de l’autorisation préalable des titulaires des
droits sur ces œuvres.
Les notions de communauté, de partage et de gratuité du monde du
Web 2.0 favorisent, comme pour les réseaux peer-to-peer, l’exploi-
tation non autorisée d’œuvres protégées notamment au travers de la
création d’œuvres nouvelles, dites « dérivées », reproduisant le texte,
le son, l’image ou la vidéo d’un auteur, d’un artiste, d’un ayant droit,
d’un producteur ou d’un distributeur.
Par ailleurs, dans la mesure où de nombreux services Web 2.0 repo-
sent sur des tags (mots-clés) permettant une indexation personna-
lisée des contenus, le monde du Web 2.0 favorise également la
reproduction de marques et de dénominations qui peuvent être
associées à des contenus susceptibles de porter atteinte à l’image des
marques et/ou à la notoriété de leur titulaire.
À l’instar des blogs, la plupart des services Web 2.0 incitent à une plus
grande liberté d’expression dont le support est désormais sonore et/ou
visuel et donne une portée plus importante aux messages diffusés.

335
Partie II – La conduite des projets Web

On voit ainsi apparaître des formes particulières de dénigrement, de


diffamation ou d’atteinte à l’image des personnes.
Se pose alors à nouveau la problématique de la responsabilité édito-
riale associée à chacun de ces nouveaux contenus sonores et visuels.
Dans la plupart des situations, l’absence quasi totale d’intervention
des éditeurs de services Web 2.0 sur les contenus mis en ligne, fait
des internautes/contributeurs les seuls responsables de ces contenus.
Les cas de mise en cause de la responsabilité des internautes sont
d’ailleurs déjà en augmentation.
Dans ce contexte, le monde du Web 2.0 présente un double visage :
celui d’un monde de liberté et de services offerts aux internautes,
proche de l’esprit du Web original, favorisant la création et la libre
(ré)exploitation de tous types contenus disponibles ou non sur le
Web, et celui d’un enfer juridique et économique pour les titulaires
de droits et les entreprises dont les œuvres sont considérées de plus
en plus comme libres de droits et dont l’image est « libre » d’être
écornée.
Avec le Web 2.0, l’internaute semble reprendre le pouvoir et sa
liberté au détriment des fournisseurs de contenus habituels et des
acteurs traditionnels du Web, même si certains dénoncent déjà
une « fausse liberté » face à laquelle les internautes doivent rester
vigilants.
Auteurs, fournisseurs de contenus et entreprises sont une nouvelle
fois contraints de réagir sur les terrains du droit et de la communi-
cation pour protéger leurs droits et leur image.
La valorisation d’un site ou plutôt d’un service Web 2.0 réside
d’abord dans le niveau d’implication des utilisateurs ainsi que le
nombre et la qualité de leurs contributions. Cette valeur doit être
suffisamment démontrée pour espérer générer les revenus publici-
taires et les partenariats qui garantiront la pérennité de
« l’entreprise ».
À ce jour, les nouveaux projets Web 2.0 donnent, de plus en plus
souvent, lieu à des levées de fonds importantes et le succès des
services déjà lancés suscite déjà l’intérêt d’investisseurs, sans parler
des perspectives d’entrée en bourse pour les meilleurs.
Que l’on soit internaute, titulaire de droits ou entreprise, il est donc
impossible aujourd’hui d’ignorer le phénomène Web 2.0 et les
risques qu’il représente pour chacun de ses acteurs.

336
Chapitre 13 – Impact du Web 2.0 sur les projets Web

Les six mesures à prendre pour tirer profit du Web 2.0


Adopter SOA
Tous les principes techniques du Web 2.0 sont une conséquence
directe de l’architecture orientée service. Les flux RSS et Atom
exposent des objets métiers. Les API REST et SOAP exposent des
traitements métiers. Et la structure des URL d’un site Web 2.0
(del.icio.us et Pandora.com sont de bons exemples) est optimisée
pour exposer ces informations. La première étape de la construction
de services Web 2.0 consiste donc à structurer ses données et
services. Leur exposition ne constitue que la deuxième étape.
Penser son site comme un service public
L’une des différences fondamentales entre le Web 1.0 et le Web 2.0
est la notion d’interfaces publiques (flux RSS/Atom et API). Il faut
donc réfléchir aux données et traitements que l’entreprise souhaite
exposer auprès d’une population clairement identifiée (collabora-
teurs internes, partenaires, etc.), mais aussi auprès d’une population
inconnue : internautes, moteurs de comparaison de prix, start-ups
créant des applications composites à partir de données et services
publics…
Référencer rapidement ses différentes interfaces
sur les générateurs de trafic appropriés
À chaque nouvelle interface sont associés des annuaires et moteurs
de recherche : les API et applications composites sont référencées
par ProgrammableWeb.com, les sites Web et flux RSS sur del.icio.us
et Yahoo! Mon Web 2.0, les objets (produits, par exemple) sur
Google Base, etc.
Encourager les internautes à adopter et « taguer » votre site
Il existe des moyens simples pour aider les internautes à effectuer le
travail de référencement à la place de l’entreprise. C’est par exemple
le cas de boutons de type « add to del.icio.us » qui fleurissent sur les
blogs.
Adapter sa communication aux internautes
Les blogs constituent une excellente opportunité pour nouer un
dialogue avec les prospects, clients et partenaires de l’entreprise.
C’est également un outil simple à mettre en place qui peut générer
rapidement du trafic vers le site institutionnel de l’entreprise.
Mettre en place les outils d’analyse adaptés
Le trafic des blogs et autres flux RSS/Atom ne répond pas au même
schéma que les sites Web. Des outils spécialisés comme FeedBurner

337
Partie II – La conduite des projets Web

et Performancing permettent d’analyser finement les statistiques de


ces nouvelles interfaces pour comprendre le comportement des
internautes.

Pour aller plus loin

Ouvrages
Véronique Messager Rota et Jean Tabaka
Gestion de projet : Vers les méthodes agiles
Éditions Eyrolles – 2007 – ISBN : 978-2212121650
Jean-Pierre Vickoff
AGILE : l’Entreprise et ses Projets
QI Éditions – 2007 – ISBN : 978-2912843005
Ken Schwaber
The Enterprise and Scrum
Microsoft Press – 2007 – ISBN : 978-0735623378
Henrik Kniberg
Scrum and Xp from the Trenches
Lulu.com – 2007 – ISBN : 978-1430322641

Sites
Wikipedia – Méthode agile
http://fr.wikipedia.org/wiki/M%C3%A9thode_agile
CommentCaMarche.net – Génie logiciel - Méthodes agiles (RAD,
XP)
http://www.commentcamarche.net/genie-logiciel/methodes-
agiles.php3
Manifesto for Agile Software Development
http://agilemanifesto.org/
Wikipedia – Technology roadmap
http://en.wikipedia.org/wiki/Technology_roadmap
Getting Real
http://gettingreal.37signals.com/

338
Chapitre 13 – Impact du Web 2.0 sur les projets Web

ReadWriteWeb
http://readwriteweb.com
TechCrunch
http://techcrunch.com
Digital Web Magazine
http://www.digital-web.com

339
PARTIE III
Études de cas
Chapitre 14

Étude de cas 1 :
site institutionnel

343
Conception
fonctionnelle

Expression Conception
des besoins graphique

Étude de Tests
Benchmark
l'existant utilisateurs

Tables rondes Diagnostic Préparation


Partie III – Études de cas

Formation des
Audit formateurs

Présentaion Choix des Conception Formation des


Développements

344
Projet
des solution prestataires technique utilisateurs

Étude des Cahier des Tests Reprise de


Positionnement Stratégie Stratégie
solution charges utilisateurs l'existant

Marketing mix Choix Brief Recette Mise en œuvre

Analyse des
Documentation Contôle
réponses

Stratégie Business plan Faisabilité Conception Réalisation Mise en service

Figure 14-1
Chapitre 14 – Étude de cas 1 : site institutionnel

Le contexte

Une grande institution française, à vocation non commerciale et


présente sur tout le territoire français au travers d’une forte implan-
tation régionale, souhaite améliorer son image institutionnelle sur le
Web.
Cette institution repose sur une organisation matricielle (par
domaines et par situations géographiques) qui laisse une certaine
autonomie aux différentes entités. De ce fait, au moment du brief, il
existe plus de trois cents sites de natures et de qualités très variables.
L’image institutionnelle dégagée par l’ensemble n’est pas homogène et
laisse un sentiment de dérive.
Le site institutionnel national est, lui aussi, déficient : du fait d’une
organisation inopérante, il ne présente que peu d’actualités et
renvoie une mauvaise image.
La situation s’explique d’une part par un manque de coordination
éditoriale entre site national et sites locaux ou thématiques, et
d’autre part par l’absence d’un outil simple de mise à jour pour le
site national.
Du côté des contributeurs du réseau, les attentes sont très fortes ;
qu’il s’agisse des producteurs d’information ou des webmestres. Ils
sont nombreux à demander de l’aide et des outils, conscients du
manque général d’homogénéité. De fait, l’équipe nationale en
charge du dossier Web est trop réduite et ne peut que les conseiller
dans la limite de ses moyens forts limités.
Suite à l’application d’un schéma directeur décidé par la DSI plusieurs
années auparavant, l’environnement technique est très cohérent. Les
applications Web reposent sur Linux, Apache, PHP, MySQL et cons-
tituent une bonne base de départ pour la future solution.

Les enjeux

Compte tenu du contexte, les enjeux du projet sont avant tout orga-
nisationnels et stratégiques.

Impliquer les contributeurs dans la démarche


Le premier enjeu est la capacité du groupe de projet à amener les
contributeurs (les producteurs de contenu, le Webmaster, etc.) à

345
Partie III – Études de cas

s’impliquer dans le projet. Ce point est très important, car, pour


créer les futurs outils d’animation du réseau, il est nécessaire de
disposer d’un retour d’expérience du terrain qui soit le plus riche
possible.
Il est aussi extrêmement important de sensibiliser les contributeurs
pour qu’ils adhèrent à la future stratégie et s’en approprient les règles
et outils. Les faire participer à la démarche, dès le début, est un bon
moyen d’y parvenir.
Enfin, plus globalement, il est nécessaire de remotiver le réseau,
découragé par trop d’effets d’annonce non suivis de résultats concrets.

Définir une nouvelle stratégie


Le deuxième enjeu du projet est la définition d’une stratégie prag-
matique pour le court terme, dont le but est de canaliser les efforts
du réseau vers un minimum d’homogénéité.

Sélectionner une solution cohérente


Le troisième enjeu du projet est l’identification d’une solution tech-
nique. Elle doit être simple à mettre en œuvre et facilement « packa-
geable » dans le but d’une éventuelle distribution à tout le réseau.

La solution

Après avoir analysé les logs et mené les différents audits, une stra-
tégie à long terme et un plan d’action à court terme sont fixés.

L’analyse des logs pousse à revoir le périmètre


Le projet débute classiquement avec une réunion de lancement qui
permet à chaque équipe de faire connaissance. À cette occasion, le
périmètre de la mission est défini avec précision : il s’agit du site insti-
tutionnel et de quelques sites périphériques. Les fichiers nécessaires à
l’analyse statistique des logs des sites existants sont obtenus et étudiés.

L’analyse révèle très vite que le chemin type parcouru par l’inter-
naute n’est pas du tout celui imaginé par les deux équipes : les inter-
nautes n’arrivent pas directement par la page d’accueil du site
national ; ils passent par un moteur de recherche qui les amène vers
une page de contenu d’un site local qui elle-même renvoie vers la
page d’accueil du site national.

346
Chapitre 14 – Étude de cas 1 : site institutionnel

Figure 14-2
Cheminements théorique et réel

Dès lors, le périmètre d’étude initial doit être considérablement


élargi. Pour être représentatif, il comprend désormais une cinquan-
taine de sites en lieu et place du site institutionnel et de quelques
sites adjacents… La méthode d’audit est adaptée et la charge est
répartie de nouveau sur l’ensemble de la mission.
Les audits confirment les soupçons
L’analyse éditoriale, ergonomique et graphique des cinquante sites
révèle une très grande richesse de contenu (élément fondamental
de l’image institutionnelle de cette organisation) mais aussi de
nombreuses difficultés pour y accéder. Ces dernières s’expliquent
de deux manières. D’une part, les structures et traitements édito-
riaux ne sont pas homogènes. D’autre part, les interfaces ergono-
miques et graphiques sont aussi variées que leurs créateurs. Sur
trois cents sites, presque toutes les variantes imaginables sont
répertoriées !

347
Partie III – Études de cas

Les tables rondes internes font prendre conscience


de l’enjeu organisationnel
Les tables rondes internes confirment les attentes très fortes des
contributeurs et affirment l’importance de passer rapidement à
l’action en présentant des résultats concrets. En effet, beaucoup de
contributeurs acceptent de repousser la réalisation de leurs projets
en cours de manière à les inscrire dans la nouvelle stratégie… à
condition que l’attente soit raisonnable. Dès lors, il devient
périlleux de ne pas tenir le planning annoncé !
Les bases d’une stratégie à long terme sont
déterminées
Les résultats des audits et tables rondes poussent les équipes à envi-
sager une réponse en deux temps :
• une stratégie à court terme est incontournable pour montrer aux
contributeurs qu’ils ont été entendus ;
• une stratégie à long terme est nécessaire pour résoudre le problème
de fond.

Figure 14-3
Organisation actuelle

348
Chapitre 14 – Étude de cas 1 : site institutionnel

Figure 14-4
Organisation cible

À terme, le but est de faciliter la production et le partage d’informa-


tions « institutionnelles » (calendrier des événements, actualité,
dossiers de fond…) via une saisie déportée et un stockage centralisé.
Ainsi, l’animateur de chaque site géographique ou thématique
pourra non seulement mettre à jour son propre site, mais, en plus,
en faire bénéficier tout le réseau sans dépenser d’énergie supplémen-
taire. L’information étant la même partout, l’image sera forcément
beaucoup plus homogène.
Cette stratégie nécessite :
• la redéfinition des différents périmètres qui définissent le statut
de chaque site (institutionnel, thématique, etc.), des contenus et
services liés ;
• la définition et l’utilisation d’un référentiel éditorial commun
qui permettra à tous les contributeurs de classer l’information
selon la même logique ;
• l’adoption, par une majorité de sites, d’une architecture techni-
que commune qui facilitera, dans le futur, la mise en place de
solutions techniques d’échange de contenu ;
• l’adoption, par une majorité des sites, d’une structure ergono-
mique commune et d’un habillage spécifique (en fonction du
périmètre) visant à rapidement homogénéiser les interfaces des
principaux sites.

349
Partie III – Études de cas

Dans un délai plus ou moins long, il sera possible de mettre à la


disposition des contributeurs des fils d’informations reprenant le
contenu centralisé. La personnalisation du site institutionnel en fonc-
tion de la région et/ou du thème souhaité est également envisagée.
Une stratégie à court terme est définie
À court terme, le but est d’homogénéiser le plus possible la « partie
visible de l’iceberg » de manière à montrer un signe positif à la fois
aux internautes et aux contributeurs du réseau. Cette stratégie
implique :
• la refonte du site institutionnel ;
• la création d’un outil de mise à jour du site institutionnel ;
• l’adoption de règles ergonomiques et graphiques minimales
pour l’ensemble des sites du périmètre institutionnel ;
• la diffusion à tout le réseau d’outils facilitant l’adoption des
règles (modèles de sites notamment) ;
• l’animation du réseau.
Des tables rondes d’internautes valident le concept
De manière à être sûr du concept envisagé, deux tables rondes
d’internautes (huit personnes chacune) sont organisées. Les partici-
pants valident le concept général et proposent de simplifier l’inter-
face, jugée trop dense.

Avant la table ronde Suite à la table ronde


Figure 14-5
Cinématique avant et après les tables rondes

350
Chapitre 14 – Étude de cas 1 : site institutionnel

L’étude de l’existant est limitée,


l’expression des besoins est détaillée
Après avoir établi la stratégie, le groupe de projet décide de recentrer
l’étude de faisabilité sur les moyens à mettre en œuvre à court terme
tout en tenant compte des besoins à long terme.
Les audits ayant été réalisés, l’étude de l’existant ne porte que sur les
aspects organisationnels et techniques.
L’expression des besoins est très poussée. Elle comprend notamment :
• une liste très détaillée de chaque fonction de service ;
• un rubriquage détaillé du futur site ;
• une grille de correspondance des contenus actuels dans le futur
rubriquage ;
• la cinématique des principales pages en front-office et de
l’ensemble du back-office ;
• une estimation de la charge de travail annuelle pour l’animation
du site (sur la base du futur rubriquage et en prenant en compte
une ébauche des futurs workflows).
Le diagnostic est rapide
Le diagnostic fonctionnel est vite réalisé puisque l’audit a montré
que le site est inadapté et doit être entièrement refondu. Dès lors, le
parti pris est de ne prévoir que la reprise des contenus existants. Le
nouveau site sera reconstruit from scratch.
Le diagnostic est en revanche plus poussé sur la partie organisation-
nelle. Il compare l’organisation actuelle avec la charge de travail et
les rôles évalués lors de l’expression des besoins… et montre un écart
significatif. Il est donc décidé avec le groupe de projet que cet aspect
devra être particulièrement détaillé dans l’étude des solutions.
L’étude des solutions est limitée à un scénario
Dans un souci d’efficacité et compte tenu du contexte très clair
(OSS, contraintes organisationnelles connues, etc.), le groupe de
projet décide que l’étude des solutions ne portera que sur une solu-
tion qui sera détaillée. Celle-ci propose :
• la refonte du site institutionnel ;
• l’adjonction d’un outil de gestion de contenu ;
• la création d’un modèle de site générique en HTML dérivé du
site institutionnel ;
• la création d’un modèle de site générique dynamique dérivé du
site institutionnel ;

351
Partie III – Études de cas

• la création d’une nouvelle entité en charge du Web.


Les aspects organisationnels sont précisés : l’équipe actuelle doit être
renforcée du côté des profils éditoriaux et des chefs de projet/consul-
tants. Les premiers auront pour mission d’animer un réseau de corres-
pondants et d’animer le site national. Ils veilleront à la cohérence des
contenus en fonction de la charte éditoriale définie. Les seconds doivent
être capables d’aider les différentes entités thématiques et régionales à
mettre en œuvre l’un des modèles de site. Au niveau de la solution tech-
nique, un comparatif entre Spip 1.5 et des développements sur mesure
en PHP est réalisé. Il montre rapidement certaines limites de Spip :
• absence de gestion multilingue ;
• structure des articles très basique ;
• impossibilité de regrouper des articles pour créer un dossier.
Mais aussi des avantages indéniables :
• rapidité de mise en œuvre ;
• fiabilité ;
• budget limité ;
• souplesse du front-office ;
• catégorisation (bien que limitée)…
Pour que cette option ait un intérêt, il est décidé qu’elle doit être
envisagée dans une optique « progiciel » : le projet s’adapte à l’outil
et en tire le meilleur parti possible sans se lancer dans des dévelop-
pements nouveaux.

Figure 14-6
Grille d’évaluation des solutions

352
Chapitre 14 – Étude de cas 1 : site institutionnel

Les développements sur mesure en PHP apportent, quant à eux,


une réponse parfaite aux besoins mais à un coût et avec des délais
beaucoup plus importants.

Figure 14-7
Extrait du comparatif entre Spip 1.5 et les développements sur mesure

Au final, le groupe de projet décide de laisser le choix aux presta-


taires qui postuleront à l’appel d’offres et de leur demander d’argu-
menter leur décision. Cela permettra de disposer d’une vision plus
large et de bénéficier de leur savoir-faire.
Choix de la procédure et rédaction
des cahiers des charges
Compte tenu des résultats de l’étude de faisabilité et des compé-
tences internes en conduite de projet, le groupe de projet décide de
lancer deux appels d’offres distincts :
• un appel d’offres ouvert pour les développements ;
• un appel d’offres sur performances pour la création de l’interface.

353
Partie III – Études de cas

Le bilan

Sans l’analyse des logs en début de projet, la vision de la probléma-


tique aurait été complètement arbitraire et aurait conduit à une
réponse inappropriée.
Les tables rondes d’internautes ont permis de valider le concept et
de l’ajuster en fonction de leurs remarques. Elles auront permis
d’éviter de modifier la maquette HTML ou la première version de
site.
Au final, la conduite du changement a représenté une part impor-
tante de la charge de travail et s’est révélée être le facteur clé de
succès le plus important.

354
Chapitre 15

Étude de cas 2,
site B-to-B

355
Conception
fonctionnelle

Expression Conception
des besoins graphique

Étude de Tests
Benchmark
l'existant utilisateurs

Tables rondes Diagnostic Préparation


Partie III – Études de cas

Formation des
Audit formateurs

Présentaion Choix des Conception Formation des


Projet Développements

356
des solution prestataires technique utilisateurs

Étude des Cahier des Tests Reprise de


Positionnement Stratégie Stratégie
solution charges utilisateurs l'existant

Marketing mix Choix Brief Recette Mise en œuvre

Analyse des
Documentation Contôle
réponses

Stratégie Business plan Faisabilité Conception Réalisation Mise en service

Figure 15-1
Chapitre 15 – Étude de cas 2, site B-to-B

Le contexte

Une société spécialisée dans la traduction professionnelle souhaite


créer un site de traduction humaine destiné aux professionnels, en
gérant de bout en bout le processus (du devis à la facturation), y
compris le recrutement des traducteurs. Le but est de recruter de
nouveaux clients sur un marché moins concurrentiel et d’apporter
des services à forte valeur ajoutée à ses clients traditionnels.
La société est une petite structure de moins de cinquante personnes
mais elle gère plus de deux cents traducteurs pigistes. Son équipe ne
possède aucune connaissance informatique mais dispose de très
fortes compétences métier. Faute d’une taille suffisante, l’entreprise
n’a que peu de temps à consacrer au projet. Cependant, un chef de
projet est clairement identifié.
Le besoin fonctionnel exprimé lors du brief est très large :
• devis automatisé (redirection et alerte si devis automatisé
impossible) ;
• gestion des commandes ;
• gestion des traductions (contact traducteur, workflow suivant le
cycle de vie de la traduction, présentation client intermédiaire
pour validation…) ;
• gestion de la facturation ;
• paiement en ligne, etc.
Au moment du projet, il n’y a aucun existant technique mis à part
les postes de bureautique, sous Windows 98 et avec Microsoft
Office 97.

Les enjeux

Le principal enjeu du projet est de transposer les processus métier


avec précision et justesse.

S’adapter aux processus métier


pour garantir l’efficacité de la solution
Le principal enjeu du projet est la capacité de la solution à
« coller » aux processus métier. En effet, la traduction est un
métier très spécifique qui repose sur l’intermédiation entre des

357
Partie III – Études de cas

clients désirant faire traduire des documents et des traducteurs


voulant traduire. Plusieurs profils d’intervenants sont donc à gérer
et chacun joue un rôle précis, créant de nombreuses interdépen-
dances et des goulots d’étranglement dans le workflow. Aussi, une
automatisation complète s’avère trop complexe, trop longue et
trop coûteuse.

Budget et planning limités


Le budget (donc la charge de travail) et le planning du projet sont
limités. Ils ne permettent pas d’appliquer une démarche classique. Il
faut donc faire vite et bien… en sautant des étapes et en se concen-
trant sur l’essentiel.
Ainsi, un seul intervenant préparera la réalisation. Il jouera à la fois
le rôle de chef de projet, de consultant fonctionnel et d’ergonome.
En outre, seule la formalisation des livrables essentiels sera effectuée
et les outils habituels seront troqués pour des logiciels du Pack
Office ou équivalent.

Intégrer les futurs animateurs


de sorte qu’ils s’approprient l’outil
Les futurs animateurs sont la clé du système. En effet, leur rôle n’est
pas uniquement d’animer le site mais aussi de gérer les dossiers et,
par exemple, d’assurer un contrôle qualité sur chaque traduction. Ils
doivent par conséquent être parfaitement à l’aise avec l’outil.
Dès lors, les impliquer dans la conception et la réalisation du projet
devient une nécessité. Ils seront intégrés à chaque étape et leur vali-
dation sera nécessaire pour passer à l’étape suivante.

La solution

Dans un souci d’efficacité, l’entreprise confie son projet à une SSII


partenaire sans réaliser d’appel d’offres (elle ne dispose pas d’un
cahier des charges suffisant). Celle-ci a pour mission de créer le site
le plus complet possible dans la limite du budget et du planning. La
SSII peut s’organiser comme elle l’entend.

Étape 1 : modélisation des processus


Le temps et la charge étant comptés, le plan d’action consiste à créer
directement la cinématique du futur site. Cette démarche est

358
Chapitre 15 – Étude de cas 2, site B-to-B

possible grâce à une importante mobilisation du client pendant huit


jours consécutifs.
Les outils utilisés sont un paperboard, ABCflowcharter, PowerPoint
et Excel. Quatre étapes sont nécessaires :
1. la description, sous forme de diagramme, de chaque processus
réalisé dans le monde physique ;
2. la transposition et l’optimisation, sous forme de cinématique, de
chaque processus ;
3. l’identification des données liées à chaque processus (via l’étude
de chaque écran de la cinématique) ;
4. la traduction de la cinématique en un MLD et un MCD.

Figure 15-2
Les quatre étapes de modélisation

Étape 2 : choix du mode de paiement,


de la technologie et de l’hébergeur
Une fois la cinématique validée, un certain nombre de choix tech-
niques restent à faire. En ce qui concerne la solution de paiement,
un rapide comparatif aboutit à la conclusion que l’offre du Crédit
Mutuel (CyberMut) est la plus adaptée parce qu’elle offre un paie-
ment multidevise, un coût raisonnable par rapport au business
model et que l’entreprise est déjà cliente du Crédit Mutuel.

359
Partie III – Études de cas

Le choix de la technologie est effectué en fonction des trois


contraintes : le budget, le planning et les briques existantes au sein
de la SSII. Celle-ci possède une grande expérience en ASP, PHP et
ColdFusion. Après quelques recherches, les briques les plus exploi-
tables existent en ASP. L’environnement technique final du site est
NT4, IIS 5, ASP, SQLServer 7, Cybermut.
Avec ces deux contraintes en tête (système de paiement et ASP), la
SSII recherche l’hébergeur qui offre le meilleur rapport qualité prix
sur une durée de trois ans. Un hébergeur connu de la place est sélec-
tionné.

Étape 3 : constitution de l’équipe de développement


Une équipe projet est rapidement constituée. Elle est composée :
• d’un chef de projet fonctionnel (qui joue également le rôle de
consultant fonctionnel et d’ergonome) ;
• d’un chef de projet technique (qui joue également le rôle de
consultant technique et de développeur) ;
• de deux ingénieurs d’études ;
• d’un designer (qui joue le rôle de directeur artistique, de designer
et d’intégrateur).
Le chef de projet fonctionnel intervient seul lors des deux premières
étapes. Il briefe dans un deuxième temps alors le chef de projet tech-
nique qui, dès lors, prend le relais.

Étape 4 : développements
La démarche retenue pour le développement est calquée sur le prin-
cipe de la méthode RAD : développement d’une première version,
tests puis optimisation puis tests puis optimisation, etc.
Chaque lot est développé par un seul ingénieur d’études (la partie
statique est prise en charge par le directeur artistique) de manière à
limiter le temps nécessaire et à conserver une bonne cohérence du
code. Il s’écoule environ deux mois entre le début des développe-
ments et la signature de la recette définitive. Dans les dernières
semaines, le chef de projet technique assiste l’entreprise dans les tests
et réalise les corrections.

Étape 5 : lancement
Pendant ce temps, le chef de projet fonctionnel réalise toutes les
démarches nécessaires pour assurer le lancement du site. Aucune
action de communication spécifique n’est prévue car l’entreprise

360
Chapitre 15 – Étude de cas 2, site B-to-B

dispose d’une force commerciale en action depuis le début du


projet. Celle-ci s’intéresse essentiellement au marché des grands
comptes. En outre, le projet bénéficie du relais de grandes entre-
prises high-tech et de la presse spécialisée (management, distribu-
tion, économie, informatique…) car des partenariats et une
campagne de relations presse ont été menés dès le début.
En ce qui concerne le référencement, un travail de recherche statis-
tique de mots-clés est effectué, puis une traduction est réalisée. Dans
un deuxième temps, une société de référencement est sélectionnée
en fonction de son aptitude à travailler à un niveau international et
en plus de cinq langues. Enfin, le chef de projet en charge du réfé-
rencement est briefé. Le suivi est effectué directement par la société
de traduction.

Le bilan

La modélisation des processus métier via une démarche informelle


a été efficace parce que le projet est peu complexe et que l’entreprise
maîtrise parfaitement toutes les dimensions de son métier. Dans le
cas d’un projet plus important ou plus complexe, elle aurait conduit
à un échec.
L’approche itérative retenue pour les développements était la seule
capable de tenir les délais et la charge tout en satisfaisant les utilisa-
teurs finals. Elle a, en revanche, mis une pression importante sur les
ingénieurs d’études qui ont dû modifier (ou refaire) plusieurs fois
leur travail. Cette approche est donc à réserver aux projets peu
complexes pouvant être réalisés par une équipe restreinte et très
motivée. Comme tout repose sur la motivation de l’équipe, cette
démarche fait prendre des risques qui ne sont pas admissibles dans
le cadre d’un projet Web standard.
La principale difficulté a été la mise en œuvre de la solution de paie-
ment chez l’hébergeur, celui-ci ayant remplacé le consultant avant
vente par un chef de projet qui ne connaissait pas la solution. Il ne
faut donc pas négliger le poste hébergement et s’assurer que l’équipe
proposée est réelle et possède bien les compétences requises.

361
Chapitre 16

Étude de cas 3,
portail d’entreprise

363
Conception
fonctionnelle

Expression Conception
des besoins graphique

Étude de Tests
Benchmark
l'existant utilisateurs

Tables rondes Diagnostic Préparation


Partie III – Études de cas

Formation des
Audit formateurs

Présentaion Choix des Conception Formation des


Projet Développements
des solution prestataires technique utilisateurs

364
Étude des Cahier des Tests Reprise de
Positionnement Stratégie Stratégie
solution charges utilisateurs l'existant

Marketing mix Choix Brief Recette Mise en œuvre

Analyse des
Documentation Contôle
réponses

Stratégie Business plan Faisabilité Conception Réalisation Mise en service

Figure 16-1
Schéma des différentes étapes
Chapitre 16 – Étude de cas 3, portail d’entreprise

Le contexte

La filiale d’un groupe international souhaite créer son portail


d’entreprise. Le siège social de cette société de plus de trois cents
collaborateurs est implanté à Paris. On y retrouve la direction géné-
rale et l’ensemble des fonctions transversales. Elle possède en outre
plusieurs centres de production et une force de vente nomade
répartis sur l’ensemble du territoire.
Le projet est piloté par la direction générale et implique la direction
des ressources humaines, la direction du système d’information, la
direction commerciale, la direction de la communication ainsi que
la direction du e-business… Compte tenu du contexte et des inves-
tissements consentis, le projet ne doit pas être un échec. Le délai fixé
par la direction générale pour aboutir à un outil opérationnel est de
dix-huit mois.
Les utilisateurs finals n’attendent rien du projet et sont même peu
motivés. Il est perçu comme le nième audit d’une longue et inutile
série.
Au moment du lancement du projet, il n’existe pas d’intranet. Le
besoin fonctionnel est donc assez large :
• interfaçage de la messagerie ;
• espaces de travail collaboratif ;
• gestion de contenu ;
• gestion des utilisateurs et profils d’utilisateurs ;
• personnalisation ;
• alertes ;
• plannings partagés ;
• nombreuses applications à intégrer, etc.
En ce qui concerne les postes de travail, l’existant est surtout
composé d’applications centrées sur Lotus Notes ou Microsoft
Office (Access et Excel essentiellement) ainsi que des systèmes
propriétaires…
Pour ce qui relève de l’infrastructure, les réseaux, les serveurs et
l’annuaire LDAP sont maîtrisés par la maison mère située dans un
autre pays en Europe. Le système d’exploitation le plus courant est
NT4 et beaucoup de sites sont développés en Lotus Notes Domino.
À noter la présence de serveurs Microsoft SQL Server et de bases
Oracle ainsi que d’une licence Verity K2 enterprise disponible.

365
Partie III – Études de cas

Les enjeux

Créer un outil simple à utiliser, remotiver les utilisateurs, apporter


une solution pragmatique, fédérer l’ensemble des collaborateurs
autour d’une même vision… Le projet répond à des enjeux classi-
ques mais ô combien stratégiques !
Créer un outil simple et accessible
Du fait de l’inexistence d’un premier intranet, les utilisateurs ne
sont pas sensibilisés à l’utilisation des nouvelles technologies. Le
nouvel outil devra donc être le plus simple possible à utiliser et ne
faire appel à aucune connaissance spécifique. Dans ce contexte,
l’articulation des différentes fonctionnalités et l’ergonomie de
l’interface seront des facteurs clés de succès.
Remotiver les utilisateurs
Compte tenu du contexte, le principal enjeu est de faire adhérer les
utilisateurs. Dans un premier temps, un gros travail de sensibilisa-
tion est donc nécessaire. Dans un deuxième temps, l’implication
tout au long du projet d’un groupe de correspondants semble
incontournable.
Apporter une solution pragmatique
à des besoins quotidiens
Les utilisateurs sont habitués au fonctionnement actuel et ne voient
pas vraiment l’intérêt de changer. Le deuxième enjeu du projet est
donc sa capacité à apporter des solutions pragmatiques perçues
comme étant au moins équivalentes à celles qui existent.
Fédérer autour d’une même vision de l’entreprise
L’implantation géographique de la société crée un clivage entre les
collaborateurs du siège, ceux des unités de production et les forces
de vente nomades. Le troisième enjeu du portail est par conséquent
de fédérer les collaborateurs autour d’un projet commun.

366
Chapitre 16 – Étude de cas 3, portail d’entreprise

Figure 16-2
Une organisation géographique favorisant les clivages

La solution

Le projet s’appuie sur une démarche itérative1 découpée en quatre  Démarche itérative :
grandes phases étalées sur dix-huit mois. Un groupe d’une trentaine méthode centrée sur
le principe essai > erreur >
de correspondants est associé à tous les moments clés, à commencer correction > essai…
par le kick-off de lancement. Le rôle des correspondants est essen- Le but est de ne pas perdre
tiellement de représenter les utilisateurs et de diffuser auprès des de temps et d’argent lors
utilisateurs finals une vision positive du projet. des spécifications.

Étape 1 : expression des besoins et étude de l’existant


La première étape est l’expression des besoins. Elle se déroule sous
forme d’entretiens en face à face auprès d’un échantillon de soixante
personnes représentatives de toutes les localisations géographiques
et directions de l’entreprise. Le but est de lister les applications et les
informations utilisées quotidiennement. Un effort particulier est
porté sur les informations et applications métier spécifiques à
chaque direction.

367
Partie III – Études de cas

Après discussion avec les managers de chaque direction, les corres-


pondants et les utilisateurs finals, les principaux besoins qui ressor-
tent de l’étude sont :
• l’accès à la messagerie (Lotus Notes) ;
• l’accès à l’annuaire ;
• l’accès à des bases de données d’informations internes concer-
nant les produits, des aspects juridiques, les processus métier...
(Lotus Notes) ;
• l’accès à des informations sectorielles publiques (actualité,
concurrence, droits…) ;
• l’accès aux applications métier utilisées quotidiennement.
En parallèle, l’étude de l’existant montre que de nombreuses bases
de données citées lors de l’expression des besoins (80 % environ)
sont développées en client/serveur et qu’une majorité des informa-
tions ne sont pas à jour. En outre, les applications métier non offi-
cielles sont légion.

Figure 16-3
Répartition des applications par grandes familles

368
Chapitre 16 – Étude de cas 3, portail d’entreprise

Trois technologies possédées par la société et pouvant servir de base


au futur portail sont répertoriées :
• Documentum 4i apporte un référentiel documentaire unique et
des délais de mise en place réduits car des projets sont en déve-
loppement au sein de la société. Ce produit montre cependant
des limites assez fortes telles que sa capacité d’intégration au sys-
tème d’information de la société, sa capacité à récupérer les con-
tenus existants et sa capacité à publier pour le Web.
• Lotus Notes Domino, compte tenu du contexte, apporte une
bonne intégration au système d’information tout en restant
ouvert. En outre, il facilite la récupération des contenus existants.
Les délais de mise en œuvre peuvent, en revanche, être importants
puisqu’il est nécessaire de réaliser des développements sur mesure.
• Verity Portal One apporte des capacités de recherche excellentes
donc un accès aux informations meilleur que les deux autres
technologies. Ce produit pose des problèmes d’intégration au
système d’information et de récupération des contenus existants.
L’étude de l’existant permet également de prendre conscience des
difficultés à venir, liées aux contraintes imposées par la maison mère,
notamment au niveau du réseau et des serveurs. Enfin, les contrats
en cours d’hébergement et de prestation de services informatiques
(projet en cours, maintenance, etc.) sont étudiés de manière à
disposer d’une vision claire des contraintes de ce niveau.
Le recrutement du Webmaster est lancé en interne et l’objectif est
de l’avoir formé au moment de la mise en production du pilote. Une
première réunion permet de présenter un point de la situation
auprès du comité stratégique qui valide le travail accompli et fixe les
nouvelles priorités. C’est aussi l’occasion d’aborder des aspects
essentiels tels que la politique de sécurité à mettre en place, la
production du futur contenu (qui s’avère être déjà plus importante
que prévue) et le plan de communication.

Étape 2 : profils, sécurité, contenu, communication


Dès le début du projet, plusieurs chantiers de fond sont lancés, au
premier rang desquels la définition des profils utilisateurs, la sécurité,
le recensement des sources de contenu et le plan de communication.
La définition des profils utilisateurs est prise en charge par la direc-
tion des ressources humaines. Celle-ci se fonde sur les fiches de
postes et des entretiens avec les principaux managers pour définir :
• la liste de profils « fonctionnels » (comptable, commercial, etc.) ;

369
Partie III – Études de cas

• une liste exhaustive des informations liées à chaque profil ;


• une liste exhaustive des applications liées à chaque profil ;
• une grille synoptique reprenant toutes ces informations.
Le recensement des contenus est pris en charge par la direction des
ressources humaines qui dispose des ressources nécessaires. Il s’agit de :
• lister les sources de contenu correspondant à chaque profil ;
• évaluer la charge de travail représentée par leur mise à jour ;
• rechercher des fournisseurs spécialisés quand les contenus n’exis-
tent pas ;
• dresser le plan de migration des applications correspondant à
chaque profil ;
• définir et recruter la future équipe d’administration du portail.
Le chantier sécurité consiste à définir les niveaux et moyens de sécu-
rité associés aux différents profils. Cet aspect est pris en charge par
la DSI qui réfléchit déjà à la question depuis quelque temps. Après
plusieurs semaines de travail, une solution de Single Sign-On, repo-
sant sur SecurID et un annuaire LDAP, est validée par le comité stra-
tégique. Enfin, la définition du plan de communication pour le
lancement du portail est gérée par la direction de la communication.
Celle-ci met au point une premier plan qui sera discuté avec le
comité stratégique.
Une réunion avec le comité stratégique permet de valider officielle-
ment les choix opérés précédemment et notamment l’enveloppe
budgétaire nécessaire au développement puis à l’animation du portail.

Étape 3 : création, test et mise en ligne du pilote


Suite aux phases 1 et 2, un mini cahier des charges est établi en vue
de la réalisation d’un « pilote » limité à quelques services et quelques
informations. Le but de ce pilote est de valider le concept et de
laisser du temps au groupe de projet pour réaliser le portail définitif.
Après validation de la cinématique, la conception ergonomique et
graphique est effectuée en parallèle de la conception technique. Le
pilote est développé (en Lotus Notes Domino) puis mis en production.
Des tests utilisateurs sont menés avec les correspondants sur la base
d’un questionnaire en ligne et d’entretiens en face à face. Ils révèlent
que le périmètre fonctionnel du pilote est insuffisant et que d’autres
services et informations doivent être ajoutés pour que le pilote soit
viable. Sur cette base, le cahier des charges est rédigé, à la suite de
quoi l’appel d’offres est lancé puis un prestataire sélectionné. Le

370
Chapitre 16 – Étude de cas 3, portail d’entreprise

prestataire présent en amont est sélectionné car il connaît bien le


projet (c’est lui qui a rédigé les spécifications et le cahier des
charges…) et sa proposition commerciale est parmi les plus accep-
tables. Le pilote définitif propose donc :
• des alertes permettant d’informer sur des sujets graves ;
• des revues de presse thématiques ;
• des espaces d’information « produits » ;
• l’accès à l’annuaire ;
• des rubriques statiques d’information sur l’entreprise (plan
d’accès, etc.).
En parallèle, deux webmasters sont formés. Ils ont la responsabilité
d’animer le pilote et de répondre aux e-mails des utilisateurs au
cours des six ou huit mois à venir.

Étape 4 : spécifications fonctionnelles, faisabilité,


cahier des charges et appel d’offres
Le groupe de projet rédige les spécifications fonctionnelles et réalise
une étude de faisabilité technique. Cette dernière définit clairement
les contraintes techniques du projet, les solutions envisageables et
argumente le choix de l’une d’entre elles.

Figure 16-4
Deux architectures sont envisagées.

371
Partie III – Études de cas

Sur cette base, le cahier des charges est rédigé, à la suite de quoi
l’appel d’offres est lancé puis un prestataire sélectionné. Le presta-
taire présent en amont est sélectionné car il connaît bien le projet
(c’est lui qui a rédigé les spécifications et le cahier des charges…) et
sa proposition commerciale est parmi les plus acceptables.
Le choix du prestataire est argumenté devant le comité de pilotage
qui donne son accord et lance officiellement la phase de réalisation.

Étape 5 : développement, documentation et lancement


L’étude de faisabilité ayant opté pour des développements sur
mesure (Lotus Notes Domino), le chef de projet du prestataire
prépare le plan de lotissement et le fait valider par le comité projet.
Les équipes de développement développent à la fois l’infrastructure
du portail et de nouvelles applications. Elles réalisent, par la même
occasion, la migration de nombreuses applications.
Chaque lot (un élément d’infrastructure ou une application) est
testé et recetté au fur et à mesure, à la fois par un membre du comité
projet et par un échantillon représentatif de correspondants.
Six mois après la validation du plan de lotissement, le portail et les
applications sont mis en production et une série de tests avec
l’ensemble des correspondants est réalisée.
Enfin, le portail est lancé au cours d’une réunion annuelle rassem-
blant l’ensemble des collaborateurs de l’entreprise. Cette première
action est soutenue par un dispositif de communication qui accom-
pagne les utilisateurs au cours des premiers mois d’utilisation.

Le bilan

Le pilote est un principe très utile qui a porté ses fruits en matière
de conduite de changement. Il a permis d’impliquer les correspon-
dants puis les utilisateurs finals et de définir avec eux leurs besoins.
Le seul risque réside dans un changement, même peu important, de
l’ergonomie ou du graphisme du site, les utilisateurs s’étant habitués
au pilote.
Le projet a été mené avec un seul prestataire, ce qui aurait dû simpli-
fier son déroulement. Paradoxalement, le manque de communica-
tion entre les différentes équipes a conduit à la réalisation de spéci-
fications fonctionnelles beaucoup trop légères et d’un cahier des
charges trop vague. Cela s’est traduit par un dérapage de charge et

372
Chapitre 16 – Étude de cas 3, portail d’entreprise

de planning assez important. Enfin, la définition de profils réalistes


et exploitables aura été la vraie difficulté du projet. En effet, une fois
les profils théoriques définis, le groupe de projet s’est aperçu qu’il ne
disposait presque jamais des informations ou applications justifiant
une segmentation fine. Le recours à des sources externes a alors été
nécessaire, avec, à la clé, un coût d’animation beaucoup plus impor-
tant que prévu. Dès lors, sans remettre en cause la nécessité du
projet, il est devenu évident qu’un travail de préparation en amont
aurait été nécessaire avant même de parler de portail.

373
Chapitre 17

Étude de cas 4,
site e-commerce
B to C

Le contexte

1er novembre 2007 : le marché des produits équitables se développe depuis


une dizaine d’années, mais les acteurs sentent une réelle accélération
depuis quelques mois. Il reste encore quelques places à prendre sur des
créneaux précis. De ce fait, le client ne souhaite pas retarder son arrivée sur
le marché et cherche à bénéficier de l’effet « premier arrivé, premier servi ».
Le but est d’imposer rapidement la marque comme une référence incon-
tournable en jouant sur la qualité des produits et du conseil plutôt que sur
la quantité et les prix bas.
La structure est en création avec un responsable à temps plein et deux
ressources à temps partiel. Aucune compétence informatique n’est dispo-
nible mais le responsable du projet connaît bien le secteur visé.
Le besoin exprimé dans le cahier des charges puis lors du brief reste
sommaire. Aucun catalogue n’est présenté : pas de dissociation par classe
de produits, pas de logique d’attributs et d’options. Nous verrons plus loin
dans ce chapitre qu’il s’agit là du principal danger pour les acteurs d’un
projet e-commerce. L’autre difficulté, laquelle n’est pas encore identifiée à
ce stade, concerne l’absence de prise en compte des prestataires tiers
comme les transporteurs et les guides d’achat en ligne.
Voici une liste des besoins répertoriés dans le cahier des charges :
• catalogue;
• promotions ;
• compte client ;

375
Partie III – Études de cas

• suivi de commande ;
• fidélité ;
• multilingue ;
• recherche ;
• FAQ ;
• CGV ;
• contact ;
• newsletter ;
• parrainage ;
• mode de paiement : par Carte Bleue, chèque, etc. ;
• gestion des stocks ;
• gestion des commandes ;
• gestion des clients ;
• gestion des newsletters ;
• statistiques.

Les enjeux

Les enjeux du projet sont classiques pour une aventure en


autofinancement : budget et plannings serrés, volonté d’indépen-
dance vis-à-vis d’une offre type ASP ou d’un fournisseur, besoin de
forte évolutivité, tout en limitant les coûts.

Budget et plannings serrés


Le time to market, ou temps de mise sur le marché, étant un élément
important, la principale contrainte du projet concerne le planning.
Le site doit être lancé début décembre au plus tard pour profiter de
la période de Noël pour réussir le lancement. Il reste donc un mois
pour tout accomplir. Évidemment, le projet doit coûter le moins
cher possible : moins de 12 000 euros tout compris. Ce dernier
point ne devrait pas être le plus compliqué à gérer car, même en
parallélisant la charge de travail, il est difficile de dépenser plus de
30 jours de charge en moins d’un mois de planning !

Indépendance
Le client ne souhaite pas dépendre d’une plateforme en mode ASP
qui pourrait pourtant limiter les risques financiers (à titre
d’exemple, PowerBoutique Expert coûte 150 euros HT par mois) et

376
Chapitre 17 – Étude de cas 4, site e-commerce B to C

garantir la mise en ligne dans les délais impartis. Ce choix est


évidemment pertinent à moyen terme car, une fois amorti, l’inves-
tissement initial n’est, par définition, plus récurrent. De plus, toutes
les données sont faciles à exporter, ce qui n’est pas le cas avec une
plateforme en mode ASP. Ce dernier point est essentiel : en règle
générale, c’est au moment où la boutique réalise un gros volume de
ventes, qu’il devient nécessaire d’ajouter des fonctionnalités sur
mesure permettant de fidéliser les clients et d’augmenter le panier
moyen. C’est aussi le moment pour changer d’outil pour passer à la
vitesse supérieure. Malheureusement, sans export des données, il est
impossible de quitter la boutique ASP.

Évolutivité
Le client souhaite pouvoir faire évoluer facilement et à moindre coût
sa boutique en ajoutant des fonctionnalités en adéquation avec les
retours des clients et des concurrents. La solution retenue doit donc
comporter un système d’extensions par l’ajout de modules complé-
mentaires. Enfin, le client souhaite disposer d’un site en plusieurs
langues même si au moment du lancement seul le français sera para-
métré.

La solution

Le client rencontre plusieurs agences sur la base d’une étude préa-


lable sommaire (devis et planning à grandes mailles). Le prestataire
retenu se voit confier comme missions : le choix de l’outil, la
conception, la réalisation puis la mise en œuvre.

Étape 1 : choix de l’outil (T + 1 semaine)


Le choix de l’outil pour la création de la boutique est extrêmement
structurant et, malheureusement, assez limité. Pour ne pas rater
cette étape fondamentale, il faut très clairement visualiser le contenu
du futur catalogue : les différents types de produits proposés (lit vs
botte de radis), leurs attributs (taille, poids, système d’exploita-
tion…) et la variété des produits commercialisés. Il faut également
avoir en tête les types de frais de port (fixes, variables…) et de
promotions, les outils marketing, la gestion de la logistique… En un
mot, il faut penser à une quinzaine de choix stratégiques qui cons-
titueront une bonne base d’analyse des solutions. Le prestataire en

377
Partie III – Études de cas

discute avec son client et finit ainsi par disposer d’un cahier des
charges plus réaliste.
Voici les 15 points à vérifier avant de se lancer dans un tel projet :
• nombre de classes produits ;
• nombre d’attributs et d’options par classe et par produit ;
• nombre de produits par classe ;
• nombre et natures des frais de port ;
• taux de TVA ;
• écotaxe ;
• types de promotions (par produit, par classe, sur une période de
temps, sur un montant unitaire, sur le montant du grand total,
etc.) ;
• couponing ;
• points de fidélité ;
• colisage ;
• transporteurs ;
• système de paiement ;
• export vers des guides (Kelkoo, LeGuide…) ;
• référençabilité ;
• obligations légales (CGV…).
Reste à choisir un outil basé sur la plateforme LAMP (Linux,
Apache, MySQL, PHP). L’agence s’intéresse de près à Magento,
Drupal+Ubercart, OS Commerce et Prestashop. Si Ubercart offre
de loin la plus grande couverture fonctionnelle, Magento dispose
d’un grand potentiel alors qu’OS Commerce et Prestashop sont très
limités. Compte tenu des besoins du client, Magento et Ubercart
sont retenus pour une inspection détaillée. Le résultat final n’est pas
évident : la combinaison Drupal + Ubercart dispose d’une grosse
communauté et offre de loin la meilleure couverture fonctionnelle.
Néanmoins, cette solution est complexe et doit être localisée
(TVA…) alors que Magento est plus simple à mettre en œuvre mais
aucun système de paiement n’est disponible pour les banques fran-
çaises et la solution doit aussi être francisée (TVA…). Au final,
Ubercart est retenu pour sa couverture fonctionnelle et l’existence
d’un module d’interfaçage avec l’API de paiement d’Atos.

Étape 2 : conception (T + 2 semaines)


Une fois l’outil choisi, l’agence se concentre sur la conception du
front office en travaillant directement sur la cinématique et en spéci-
fiant au fur et à mesure. La cinématique validée, le travail graphique

378
Chapitre 17 – Étude de cas 4, site e-commerce B to C

commence en suivant les étapes classiques : concept board, piste


graphique, déclinaison des principaux templates, allers-retours, etc.
Deux semaines plus tard, le travail de paramétrage et d’intégration
peut commencer.
Étape 3 : réalisation (T + 4 semaines)
Grâce à une bonne préparation, l’installation puis le paramétrage ne
posent pas de difficulté. En revanche, la gestion des taxes et l’affi-
chage des prix HT/TTC deviennent vite un cauchemar, la France
étant un des rares pays à imposer l’affichage des prix TTC. Malheu-
reusement, une facture indiquant les prix HT et TTC avec des taux
de TVA variables et une écotaxe est un cas complexe : aucun outil
Open Source ne le prévoit en standard, ces outils étant développés
dans et pour le monde anglosaxon. Pire les quelques modules déve-
loppés par la communauté ne fonctionnent pas du tout ou pas dans
le bon sens. Résultat, l’agence se retrouve à développer une série de
patchs pour pallier ces problèmes. La facture et le panier posent
également des difficultés car, là encore, le droit français est plus strict
et complexe que la plupart des pays anglo-saxons… Après quelques
nuits blanches et une petite semaine de retard, la boutique est fin
prête !
Étape 4 : mise en œuvre (T + 5 semaines)
Le processus d’obtention de la clé d’activation de l’API de la banque  Démarche itérative :
est lancé. Il nécessitera trois allers-retours (clé de démo, clé provi- méthode centrée sur
soire, clé définitive) en moins de 7 jours ! Parallèlement, le client est le principe essai > erreur >
correction > essai…
formé à la manipulation du back office pour saisir les fiches Le but est de ne pas perdre
produits. Cette dernière étape se déroule sans problème grâce à la de temps et d’argent lors
mobilisation du client et du prestataire qui ne comptent plus les des spécifications.
journées de 15 heures de travail. Malheureusement, deux dernières
difficultés surviennent : il faut développer au dernier moment
l’export d’étiquettes spécifiques à Chronopost et UPS, puis déve-
lopper un troisième export pour Kelkoo. Bien que non bloquantes,
ces dernières difficultés imposent une charge de travail supplémen-
taire au client (saisie manuelle) alors qu’elles auraient pu aisément
être anticipées…

379
Partie III – Études de cas

Le bilan

Les délais n’ont pas été tenus car il est impossible, sans cahier des
charges très précis, de réaliser une boutique sur mesure en moins de
six semaines. Le manque d’expérience du prestataire et du client
aurait aussi pu leur coûter plus cher : décalage supplémentaire, perte
de trafic, etc. Heureusement le principe du forfait a protégé le client
des dérapages de charge qui lui auraient coûté très chers s’il avait dû
les payer. Ce choix-là était donc le bon.
Du côté du prestataire, l’adaptation aux particularités de la législa-
tion française se révèle être la principale difficulté lors de l’utilisation
d’une solution Open Source. Il est donc essentiel de bien valider les
références du prestataire sur deux points : il doit disposer au
minimum d’une expérience e-commerce et d’une expérience avec
l’outil Open Source utilisé.
Le client, de son côté, doit impérativement penser son catalogue
dans les moindres détails avant de lancer son appel d’offres (voir les
15 points à vérifier à la page 378 avant de lancer le projet). Il doit
aussi anticiper le choix de ses prestataires logistique et marketing,
car ils peuvent imposer des contraintes supplémentaires.

380
Chapitre 18

Étude de cas 5,
générateur
d’intranets

Le contexte

Une très grande entreprise française souhaite réduire les coûts de création
et de maintenance de ses 50 intranets régionaux, tout en apportant
toujours plus de fonctionnalités aux utilisateurs finaux.
La culture de la DSI est plutôt de type Microsoft/J2EE. De plus, des
projets de gestion de contenu ou de portails de grande envergure sont à
l’étude ou déjà lancés.
Les contraintes inhérentes aux grosses structures – charte ergonomique et
graphique, respect d’un référentiel d’accessibilité – favorisent la création
d’un outil unique simplifiant le quotidien des communicants.
Le projet pilote est géré par la direction de la communication en mode
essai/erreur. S’il remporte l’adhésion des utilisateurs, il sera généralisé.
Parmi les grandes fonctionnalités identifiées, on note :
• la gestion des utilisateurs ;
• la gestion de contenu avec texte riche ;
• les workflows personnalisés ;
• la galerie médias (photos, vidéos, etc.) ;
• le référentiel documentaire ;
• l’accès restreint sur tout ou partie du site/des contenus ;
• la gestion de newsletters ;
• la recherche à facettes ;
• la notation des contenus ;

381
Partie III – Études de cas

• le filtre des contenus liés ;


• le nuage de tags ;
• les questionnaires et quiz en ligne ;
• les commentaires ;
• les forums ;
• les blogs ;
• l’envoi à un ami ;
• la version PDF de la page.

Les enjeux

Autonomie de création, de personnalisation


et de supervision
Pour réduire les coûts, le client doit pouvoir être autonome. Ses
équipes internes doivent être en mesure de se passer de tout presta-
taire extérieur grâce à une simplicité de mise en œuvre et de person-
nalisation de l’intranet. Ce dernier doit également être utilisable tel
quel, avec une charte ergonomique et graphique déjà intégrée dans
les règles de l’art et dans le respect des contraintes d’accessibilité. Le
client est ainsi en mesure de créer un nouvel intranet en quelques
minutes sans aucune ligne de code.

Facilité d’extension des fonctionnalités


L’intranet doit pouvoir être facilement personnalisé : l’ajout ou la
suppression de fonctionnalités doit se faire en quelques clics et sans
aucune ligne de code. Cette personnalisation doit également être
adaptée aux droits de chaque profil : le rôle d’un rédacteur peut
varier d’une région à une autre. De plus, il est possible d’envisager
de donner accès à seulement certains services ou certains profils dans
une région, et pas dans une autre.

Adoption par les utilisateurs


Plus que tout, les utilisateurs finaux doivent avoir envie d’utiliser ce
nouvel outil. La facilité d’utilisation du back office et la qualité de
l’interface en front office sont donc essentielles. La charte ergono-
mique et graphique de l’entreprise étant assez structurante, c’est
surtout sur le back office que les outils seront étudiés (personnalisa-
tion, simplification, etc.).

382
Chapitre 18 – Étude de cas 5, générateur d’intranets

Adoption par la DSI


Enfin, et c’est l’enjeu majeur du projet, il faut que la DSI ait envie
d’industrialiser l’avant-projet en décidant de le supporter, notam-
ment par une mise en exploitation officielle par ses équipes. Ce
point est fondamental car il est le seul garant de la pérennité du
projet et d’un bon niveau de service client (qualité de l’héberge-
ment, temps de reprise sur incident, sécurité des données, intégra-
tion au système d’information).

La solution

Le client décide de s’appuyer sur ses prestataires habituels afin


d’accélérer le processus. Il prend cependant soin de discuter avec
chaque agence susceptible de répondre à sa demande. Celle retenue
aura la chance d’accompagner l’entreprise dans la durée.

Étape 1 : AMOA préalable


L’équipe client décide très tôt de confier la conception générale du
projet à une société d’Assistance à Maîtrise d’OuvrAge (AMOA)
afin de dégager rapidement les grands besoins de l’entreprise puis de
les concrétiser dans des maquettes PowerPoint. Une fois les grandes
lignes validées par le Comité de pilotage (COPIL), l’AMOA parti-
cipe au choix d’une solution de gestion de contenu susceptible de
répondre aux besoins du client. Avec la solution technique à l’esprit,
il rédige les spécifications fonctionnelles.

Étape 2 : choix de la solution


Des quatre solutions envisagées en début de projet (Vignette,
Drupal, eZ Publish et Joomla!), seuls eZ Publish et Drupal sont
encore en lice. Vignette est beaucoup trop cher et n’offre pas la
souplesse nécessaire. Joomla! dispose de nombreux atouts (solution
connue, nombreux acteurs, nombreuses extensions) mais n’offre pas
la qualité technique des deux finalistes. Le nombre de modules et la
taille de la communauté font la différence : le choix se porte finale-
ment sur Drupal. Mais le client prend un risque important car les
acteurs sérieux (connaissance de l’outil, référence déjà en produc-
tion, etc.) ne sont pas encore nombreux sur le marché.

383
Partie III – Études de cas

Étape 3 : réalisation
Avant de commencer la réalisation, le client doit donc trouver la
perle rare… ce qui n’est pas très difficile car deux de ses agences ont
déjà une sérieuse expérience avec l’outil Drupal. Une aubaine qui
économise deux à trois semaines de planning. La réalisation se
déroule ensuite sans difficulté. Le projet livré ne repose que sur des
modules standards qui ne nécessitent pas de modifications : la
maintenance en sera grandement facilitée.
Le prestataire rédige la documentation technique et utilisateurs
(administration et utilisation quotidienne).

Étape 4 : mise en œuvre et pilotage


L’administrateur est formé en deux heures (un écran, deux clics et
un paramétrage serveur très simple) et les formations des utilisateurs
finaux sont programmées. La recette fonctionnelle peut donc
commencer. Elle est réalisée de manière classique, en se basant sur
une vérification point par point des spécifications. Les anomalies
sont corrigées en trois allers-retours. À ce stade, le projet est suffi-
samment finalisé pour animer, comme prévu, les formations des
utilisateurs finaux. Après une dernière série d’allers-retours, mis en
place suite à l’audit d’accessibilité réalisé par un cabinet spécialisé, le
projet est mis en production.
Le pilotage commence avec deux objectifs :
• garantir la cohérence des modules ;
• assurer l’harmonisation des versions de modules utilisés sur
l’ensemble des intranets générés avec les autres sites en Drupal et
gérés par les équipes internes.
Ce point est fondamental pour limiter au maximum les coûts de
maintenance corrective. Reste à convaincre les utilisateurs pour
ensuite convaincre la DSI.

Le bilan

Première leçon, il faut rédiger les spécifications en fonction de l’outil


ou du type d’outil. Ce point est essentiel car il garantit la faisabilité
– ou non – des spécifications. Or de nombreux AMOA rédigent
« dans l’absolu », ce qui impose ensuite d’adapter les spécifications à
ce qui est réalisable avec l’outil choisi. Un travail imprévu qui

384
Chapitre 18 – Étude de cas 5, générateur d’intranets

demande presque toujours autant de charge – donc de budget – que


la rédaction initiale des spécifications.
Deuxième leçon, la recette fonctionnelle aurait été plus efficace, à
l’échelle des 50 intranets, avec un outil d’automatisation tel que
Selenium (voir chapitre 11 « La mise en œuvre », section « Tests
fonctionnels avec Selenium »). En effet, au-delà de la recette initiale,
chaque projet devra être « recetté ». Or, chaque intranet généré est
constitué de 90 % à 100 % du projet initial. Dans ce contexte, auto-
matiser les tests permettrait de diminuer significativement les temps
de recette tout en augmentant le niveau de qualité en permettant
aux testeurs de se concentrer sur les 10 % spécifiques.
Troisième leçon, l’audit d’accessibilité aurait pu être effectué en fin
de phase de réalisation (en même temps que les tests internes, par
exemple) plutôt qu’à la réception du projet. Cela aurait diminué le
nombre d’allers-retours.
Quatrième leçon, avec une bonne communication autour du projet,
une offre packagée peut remporter l’adhésion des utilisateurs si les
bénéfices (réduction des coûts, rapidité, contraintes d’accessibilité
intégrées) sont supérieurs à la frustration de ne pas pouvoir choisir
son outil et modifier la charte graphique.
Reste à convaincre la DSI, qui joue un rôle fondamental dans la
réussite du projet. Dans ce cas, les avantages de la plate-forme
LAMP (coûts d’exploitation, nombreux fournisseurs, licences
réduites) et les atouts du concept de générateur d’intranet (projets
quasi identiques, limitation des versions) ont fini par convaincre.

385
Annexe 1
Contenu du CD-Rom

Le CD-Rom contient un outil de création de business plan (pour PC),


ainsi que 60 modèles de livrables aux formats Microsoft Word, Excel et
PowerPoint, qui peuvent être lus sous Mac ou PC. Il comprend un fichier
index.html, permettant d’accéder à tous les documents du CD-Rom, et
deux dossiers nommés MBP et fichiers.

Le dossier MBP

Ce dossier contient l’outil de création de business plan baptisé Montpellier


Business Plan Classic, développé par le Business and Innovation Centre de
Montpellier Agglomération. Il s’agit d’un logiciel de modélisation financière
qui vous permettra de générer un business plan complet, rapidement et dans
les règles de l’art. Simple et efficace, cet outil vous aidera à découvrir les forces
et les faiblesses de votre projet, puis à piloter votre activité. Pour l’installer sur
votre PC, il suffit de cliquer sur le fichier setup_MBPClassic.exe. La gamme
complète des logiciels Montpellier Business Plan et le service d’aide en ligne
sont sur le site www.montpellier-business-plan.com.

Le dossier fichiers

Ce dossier contient les 60 modèles de livrables : certains sont commentés


de manière à aider l’utilisateur à les remplir. Pour afficher ces commen-
taires, vous devez aller dans le menu Affichage de Word et cliquer sur
Commentaires.

387
Conduite de projet Web

Chaque modèle, signalé dans l’ouvrage par le pictogramme ,


est classé dans un répertoire correspondant aux différentes phases du
projet :
• Suivi
• Stratégie
• Business plan
• Faisabilité
• Appel d’offres
• Conception
• Réalisation
• Mise en service
Pour des raisons d’efficacité, certains modèles renvoient à des parties
d’autres modèles pour éviter de réécrire plusieurs fois les mêmes
contenus. Tous ces modèles sont libres de droits et peuvent être
utilisés, copiés, et distribués librement sous réserve de :
• ne pas les modifier, sauf pour un usage non commercial et non
promotionnel ;
• faire apparaître systématiquement, sur toutes les pages, la mention
« © 2008 – Modèle fourni par http://www.breek.fr » ;
• ne pas les vendre.
Les modèles de documents disponibles sur le CD-Rom sont
présentés ci-après. Pour chacun des modèles sont précisés :
Le nom du modèle – Le nom du fichier
Ce qui est important
Dans quel but utiliser le modèle
Les pré-requis
La composition
Le plan
Les modèles sont classés par phases et étapes, dans l’ordre chronolo-
gique d’utilisation.

Suivi
Fiche de projet – fiche_projet.rtf
Ce livrable est particulièrement important dans la mesure où il définit
toute l’organisation du projet. En le préparant, le chef de projet liste
toutes les phases, étapes et tâches qui devront être réalisées pour
aboutir au livrable final. Pour être utile, la fiche de projet doit être

388
Annexe 1 – Contenu du CD-Rom

finalisée lors de la réunion de cadrage puis validée. Elle sera ensuite


mise à jour chaque semaine à date fixe. Sans être un document
contractuel, la fiche de projet est un outil mis au service de la transpa-
rence entre le prestataire et son client.
Dans quel but l’utiliser :
• Créer un référentiel entre le client et le fournisseur
• Centraliser les coordonnées de l’équipe du client et du prestataire
• Planifier les étapes
• Suivre la charge de travail
• Suivre le planning
• Suivre la réalisation des livrables
Pré-requis :
• Bon de commande
• Contrat
• Lettre de mission
Composition/Plan :
• Coordonnées des équipes
• Charge de travail prévue/réalisée/restante répartie par profil
• Planning prévisionnel
• Liste des livrables avec date de livraison
Ordre du jour – ordre_jour.rtf
L’ordre du jour est un outil mis au service du chef de projet. Ce
dernier peut ainsi décider qui il convient de faire participer aux
réunions (en dehors des groupes de travail standards tels que le
comité de pilotage, le groupe de projet, etc.). C’est aussi un outil
efficace pour impliquer les participants et gagner en efficacité : en
leur faisant lire les documents avant la réunion, il permet de consa-
crer cette dernière aux prises de décision plutôt qu’à des lectures
interminables et sans valeur ajoutée.
Dans quel but l’utiliser :
• Rappeler la tenue de la réunion
• Convoquer les participants
• Fournir les documents étudiés en réunion
• Rappeler aux participants qu’ils doivent préparer la réunion
Pré-requis :
• Pas de pré-requis

389
Conduite de projet Web

Composition/Plan :
• Sujet de la réunion avec le détail des thèmes abordés et, si néces-
saire, temps consacré à chaque sujet
• Liste des participants
• Liste des documents à consulter pour la réunion
Compte rendu de réunion – compte_rendu.rtf
Le compte rendu de réunion est certainement l’outil le plus impor-
tant pour le chef de projet. Il permet de rendre les décisions offi-
cielles et synthétise les points clés du projet. Un bon compte rendu
de réunion est clair et concis. Orienté vers la solution plutôt que le
problème, il s’attarde sur les décisions et actions à venir. Bannir le
plus possible les comptes rendus du type : « M. Dupont dit que…
M. Durand répond que... ».
Dans quel but l’utiliser :
• Lister les décisions prises au cours de la réunion
• Répartir le travail entre les différents acteurs
• Garder une trace officielle des choix structurants
Pré-requis :
• Ordre du jour
Composition/Plan :
• Rappel de l’ordre du jour indiquant les sujets traités totalement/
partiellement/non traités : un intertitre et un paragraphe par
idée clé ; qui fait quoi pour quand.
• Indications de la date, de l’objectif, des participants et du sujet
de la prochaine réunion
Procès-verbal de recette – pv_recette.rtf
Le procès-verbal de recette est un élément contractuel fondamental
puisqu’il libère le prestataire de ses obligations. Dès lors, ce dernier
n’est plus tenu que par les modalités de la garantie, quand elles ont
été définies. L’entreprise doit donc prendre soin de bien valider tous
les aspects du dossier avant de signer le PV de recette. Faute de quoi,
elle n’aura plus les moyens de faire pression sur son prestataire.
Dans quel but l’utiliser :
• Officialiser la recette et/ou la livraison du livrable objet du
contrat
• Déclencher la période de garantie
• Déclencher la facturation

390
Annexe 1 – Contenu du CD-Rom

Pré-requis :
• Dossier de recette renseigné
Composition/Plan :
• Liste des livrables concernés
• Nom de l’entreprise
• Mentions légales
• Réserves éventuelles
• Date de la signature du document
• Prénoms, noms, fonctions et signatures des deux parties
Bilan de fin de projet – bilan_projet.rtf
Moins anodin qu’il n’y paraît, le bilan de projet permet à l’entreprise
d’évaluer le travail du prestataire en toute tranquillité. Il favorise la
formalisation de dysfonctionnements parfois difficiles à faire émerger
en réunion. C’est aussi le moyen de transmettre la « vision du client »
aux équipes, et ainsi de leur donner un éclairage objectif sur leur
travail. Pour s’assurer d’une réelle objectivité, ce document doit être
retourné au niveau hiérarchique supérieur. À l’échelle d’une business
unit, d’une direction ou d’un service, la compilation des bilans de fin
de projet permet d’identifier les dysfonctionnements structurels.
Dans quel but l’utiliser :
• Déterminer le niveau de satisfaction du client
• Identifier les points à améliorer (de part et d’autre)
• Souligner les points positifs
• Améliorer la qualité des prestations
• Améliorer la qualité du pilotage des prestataires
Pré-requis :
• Procès-verbal de recette
Composition/Plan :
• Document composé d’un seul tableau

Stratégie
Analyse de la complexité de saisie d’une URL
– grille_saisie_URL.xls
Cet outil ne doit pas se substituer à la réflexion faisant appel au bon
sens du chef de projet ou du consultant. Son seul intérêt est de rapi-
dement donner une idée de la complexité du nom de domaine pour
faciliter la prise de décision.

391
Conduite de projet Web

Dans quel but l’utiliser :


• Évaluer la complexité d’un nom de domaine
Pré-requis :
• Liste de noms de domaine
Composition/Plan :
• Document composé d’un seul tableau
Grille de définition de la position concurrentielle
– grille_position_concurrentielle.xls
Recommandée en amont d’un projet, cette grille sert à identifier
quels sites il convient d’analyser en reproduisant le cheminement
logique des internautes : choix d’un moteur, saisie de mot(s)-clé(s),
lecture des premières pages de résultats, etc. La grille d’évaluation de
la position concurrentielle est un outil à manier avec précaution
dans la mesure où le poids des moteurs et des mots-clés n’est pas
pondéré en fonction des usages de chaque cible visée. Or la diffé-
rence entre les résultats pondérés ou non peut être importante.
Dans quel but l’utiliser :
• Évaluer la visibilité réelle d’un site dans les moteurs de recherche
• Évaluer la visibilité des concurrents en fonction de mots-clés
stratégiques
Pré-requis :
• Liste des mots-clés à prendre en compte
• Part de marché des moteurs au moment de l’étude
• Position de la marque ou du produit dans chacun des moteurs
pour chaque mot-clé
Composition/Plan :
• Document composé d’un seul tableau
Grille de calcul de la popularité d’un site – grille_popularite.xls
Cette grille compare la densité de liens pointant vers des sites
définis. Elle est complémentaire de la grille d’évaluation de la posi-
tion concurrentielle à laquelle on ajoute la notion de popularité.
À utiliser en amont d’un benchmark pour établir la liste des sites à
analyser ou lors d’un audit pour éclairer les résultats.
Dans quel but l’utiliser :
• Évaluer la popularité d’un site
• Mettre en perspective la popularité d’un site par rapport à celle
de ses concurrents

392
Annexe 1 – Contenu du CD-Rom

Pré-requis :
• Liste des sites concurrents
• Liste des moteurs à prendre en compte
• Résultats ventilés par moteur
Composition/Plan :
• Document composé d’un seul tableau
Scénarios de benchmark – scenarios_benchmark.rtf
Le scénario de benchmark vise à reproduire la démarche de l’inter-
naute afin de lister les sites potentiellement les plus intéressants à
analyser. Il doit être utilisé en complément de la liste basique des
concurrents directs et indirects. La pertinence des résultats obtenus
avec ce modèle repose sur la justesse de la description du scénario et
des mots-clés utilisés. Il est donc fortement recommandé d’impli-
quer des utilisateurs dans le processus.
Dans quel but l’utiliser :
• Établir la liste des sites à analyser lors du benchmark
• Définir le cheminement logique des internautes
• Décrire le paysage concurrentiel en amont du projet
Pré-requis :
• Rapport de table ronde
• Compte rendu d’entretien utilisateur
• Chaîne de valeur
Composition/Plan :
• Description du scénario
• Description du besoin
• Fréquence du besoin
• Mots-clés a priori utilisés
• Listing de sites
• Sélection de sites à analyser
Rapport de benchmark – rapport_benchmark.rtf
Le rapport de benchmark doit donner une vue d’ensemble le plus
réaliste possible. Plus il sera synthétique et illustré, et plus il sera
percutant. Le modèle fourni ici doit donc être allégé en fonction des
objectifs du benchmark et du nombre de sites analysés. Quand ce
n’est pas possible, il peut être utile de rédiger une synthèse de deux
pages. Bien que caricaturale, elle aura le mérite de donner des
repères clairs au décideur.

393
Conduite de projet Web

Dans quel but l’utiliser :


• Savoir comment conduire un benchmark
• Formaliser les résultats d’un benchmark
Pré-requis :
• Scénarios de benchmark
• Fiches de sites
Composition/Plan :
• Liste des acteurs analysés
• Stratégies rencontrées
• Moyens mis en œuvre
• Recommandations
• Fiches de site
Recommandations suite à benchmark
– benchmark_recommandations.rtf
Ce document est un extrait du rapport de benchmark. Plus opéra-
tionnel que ce dernier, il est recommandé quand le temps est
compté ou que les décideurs expriment clairement le désir d’aller à
l’essentiel.
Dans quel but l’utiliser :
• Présenter une synthèse du benchmark orientée « solution »
• Gagner du temps en formalisant un document plus concis que
le rapport de benchmark
Pré-requis :
• Scénarios de benchmark
• Fiches de sites
• Rapport de benchmark
Composition/Plan :
• Rappel de la situation au travers de quelques mapping clés
• Détail des solutions envisageables
• Comparaison des solutions
• Recommandation d’un positionnement
Fiche de site – fiche_site.xls
La fiche de site est l’outil indispensable pour réaliser un benchmark
objectif et complet. Elle synthétise l’essentiel d’un site en quelques
lignes. Pour être pertinente, elle doit être adaptée et largement
complétée en fonction de la nature du benchmark et du nombre de
sites à analyser. Une variante permettant des tris consiste à utiliser

394
Annexe 1 – Contenu du CD-Rom

les critères en colonne plutôt qu’en ligne. Ainsi, on peut trier les sites
en fonction de la plupart des critères. Cette variante est moins
présentable mais plus efficace. Quand on l’utilise, l’idéal est de
générer les fiches de sites avec un masque de fusion dans Word.
Dans quel but l’utiliser :
• Décrire un site
• Cataloguer ses concurrents
• Réaliser un benchmark
Pré-requis :
• Liste de sites à analyser
• Scénarios de benchmark
• Grille d’évaluation de la position concurrentielle
• Grille de calcul de la popularité d’un site
Composition/Plan :
• L’entreprise (enseigne, activité, etc.)
• Le site en bref
• La ou les cible(s) du site
• Les services proposés
• Points forts
• Points faibles
• Appréciation générale
Note de positionnement – note_positionnement.rtf
La note de positionnement est utile pour formaliser le positionne-
ment et le présenter à la direction de l’entreprise. Elle synthétise les
résultats du benchmark et argumente en vue d’un positionnement
stratégique. Son intérêt tient dans sa concision : elle est idéale pour
valider les grandes orientations du projet sans rentrer dans les
détails. Lors de sa rédaction, il est recommandé de présenter l’évolu-
tion de l’offre de valeur du site sur les trois premières années et expli-
quer en quoi elle contribue à différencier le site de ses concurrents.
Dans quel but l’utiliser :
• Formaliser le positionnement du site
Pré-requis :
• Rapport de benchmark
• Rapport de table ronde utilisateurs
• Recommandations suite à un benchmark
• Rapport d’audit

395
Conduite de projet Web

Composition/Plan :
• Rappel de l’environnement
• Positionnement
Rapport de table ronde – rapport_table_ronde.rtf
Le but d’un rapport de table ronde est non seulement de synthétiser
les grands enseignements mais aussi de rassurer sur la rigueur de la
méthode utilisée. Pour qu’il soit agréable à lire, il est recommandé
d’illustrer chaque idée clé avec des extraits du verbatim et, le cas
échéant, des visuels. Quand c’est possible, présenter en détail les
membres du panel (inclure une photo et un mini-CV).
Dans quel but l’utiliser :
• Conserver une trace écrite de la table ronde
• Communiquer les résultats à la hiérarchie
Pré-requis :
• Conducteur de la table ronde
• Liste de participants
Composition/Plan :
• Contexte
• Méthodologie
• Principaux résultats chiffrés
• Verbatim
• Conclusions
Grille d’audit – aspects graphiques – grille_site_graphique.xls
Cette grille doit être impérativement personnalisée en fonction des
spécificités du site à auditer et du secteur d’activité de l’entreprise.
Chaque item possède un coefficient qui doit être pondéré en fonc-
tion des objectifs de l’audit. L’idéal est de réaliser au moins 4 audits
en commençant par trois sites concurrents. Cette démarche facilite
l’appropriation de la grille et surtout donne des repères permettant
de noter plus justement chaque item.
Dans quel but l’utiliser :
• Valider l’application de la charte graphique Web
• Valider la cohérence entre les sites de l’entreprise
Pré-requis :
• Périmètre de l’audit validé
• Objectifs de l’audit validé
• Charte ergonomique Web disponible

396
Annexe 1 – Contenu du CD-Rom

Composition/Plan :
• Reconnaissance de la marque
• Ambiance générale
• Cohérence du style
• Application du style
• Valeurs de la marque
• Design et contenu
• Design et lisibilité
• Design et repérage
Grille d’audit – aspects ergonomiques – grille_site_ergonomie.xls
Cette grille doit être impérativement personnalisée en fonction des
spécificités du site à auditer et du secteur d’activité de l’entreprise.
Chaque item possède un coefficient qui doit être pondéré en fonc-
tion des objectifs de l’audit. L’idéal est de réaliser au moins 4 audits
en commençant par trois sites concurrents. Cette démarche facilite
l’appropriation de la grille et surtout donne des repères permettant
de noter plus justement chaque item.
Dans quel but l’utiliser :
• Valider l’ergonomie du site
• Optimiser certains processus
• Aider à la conception d’une nouvelle version
• Valider la cohérence entre les sites de l’entreprise
• Améliorer l’expérience utilisateur, etc.
Pré-requis :
• Périmètre de l’audit validé
• Objectifs de l’audit validé
• Charte graphique Web disponible
• Scénarios utilisateurs validés
Composition/Plan :
• Première impression
• Page d’accueil
• Accès au contenu
• Téléchargements
• Navigation
• Liens
• Menu

397
Conduite de projet Web

• Code HTML
• Images
• Couleurs
• Typographies
• Style rédactionnel
Grille d’audit – aspects éditoriaux – grille_site_editoriale.xls
Cette grille doit être impérativement personnalisée en fonction des
spécificités du site à auditer et du secteur d’activité de l’entreprise.
Chaque item possède un coefficient qui doit être pondéré en fonc-
tion des objectifs de l’audit. L’idéal est de réaliser au moins 4 audits
en commençant par trois sites concurrents. Cette démarche facilite
l’appropriation de la grille et surtout donne des repères permettant
de noter plus justement chaque item.
Dans quel but l’utiliser :
• Optimiser l’efficacité du site
• Aider à la conception d’une nouvelle version
• Valider la cohérence entre les sites de l’entreprise
• Améliorer l’expérience utilisateur, etc.
Pré-requis :
• Périmètre de l’audit validé
• Objectifs de l’audit validé
• Charte éditoriale Web disponible
• Scénarios utilisateurs validés
Composition/Plan :
• Wording
• Structure éditoriale
• Accès au contenu
• Mise à jour du contenu
• Editing
• Auteurs
Rapport d’audit – rapport_audit.rtf
Ce document est une synthèse des différents rapports spécialisés
produits en cours d’audit (rapport d’audit ergonomique, graphique,
recommandations, etc.). Il doit être clair et concis de manière à
donner une bonne vision d’ensemble. Le rapport d’audit est idéal
pour présenter les résultats de l’audit à sa hiérarchie ou au prestataire
en charge de la refonte d’un site par exemple.

398
Annexe 1 – Contenu du CD-Rom

Dans quel but l’utiliser :


• Communiquer les résultats de l’audit
• Conserver une synthèse des résultats
Pré-requis :
• Grille d’audit renseignée – aspects graphiques
• Grille d’audit renseignée – aspects ergonomiques
• Grille d’audit renseignée – aspects éditoriaux
• Recommandations du rapport d’audit rédigées
Composition/Plan :
• Contexte
• Synthèse
• Résultats de l’analyse des logs
• Résultats des entretiens utilisateurs
• Résultats des questionnaires
• Résultats de l’audit ergonomique
• Résultats de l’audit éditorial
• Résultats de l’audit graphique
• Recommandations
• Annexes
Rapport d’audit graphique – rapport_audit_graphique.rtf
Le rapport d’audit graphique doit être essentiellement basé sur des
démonstrations visuelles. Pour ne pas fatiguer le lecteur, chaque
démonstration doit être strictement limitée au sujet à illustrer. Les
captures d’écran de l’ensemble de l’interface sont donc à bannir
autant que possible. En revanche, il ne faut pas hésiter à présenter
des planches de plusieurs dizaines de captures d’écran dès lors qu’il
s’agit d’en démontrer la cohérence – ou l’incohérence – sur
l’ensemble des sites de l’entreprise. Il doit donner une vue
d’ensemble facilitant la prise de décision.
Dans quel but l’utiliser :
• Communiquer les résultats de l’audit
• Conserver les résultats détaillés
Pré-requis :
• Grille d’audit renseignée – aspects graphiques
Composition/Plan :
• Contexte
• Synthèse

399
Conduite de projet Web

• Méthodologie employée
• Reconnaissance de la marque
• Ambiance générale
• Cohérence du style
• Application du style
• Valeurs de la marque
• Design et contenu
• Design et lisibilité
• Design et repérage
• Recommandations
• Faisabilité
Rapport d’audit ergonomique – rapport_audit_ergonomique.rtf
Le rapport d’audit ergonomique doit être essentiellement basé sur le
constat de l’application (ou de la non-application) des standards de
fait. L’idéal, pour rythmer le rapport, est d’illustrer chaque problème
par un visuel strictement limité au sujet. Il doit donner une vue
d’ensemble facilitant la prise de décision.
Dans quel but l’utiliser :
• Communiquer les résultats de l’audit
• Conserver les résultats détaillés
Pré-requis :
• Grille d’audit renseignée – aspects ergonomiques
Composition/Plan :
• Contexte
• Synthèse
• Méthodologie employée
• Première impression
• Page d’accueil
• Accès au contenu
• Téléchargements
• Navigation
• Liens
• Menu
• Code HTML
• Images
• Couleurs

400
Annexe 1 – Contenu du CD-Rom

• Typographies
• Style rédactionnel
• Recommandations
• Faisabilité
Rapport d’audit éditorial – rapport_audit_editorial.rtf
Le rapport d’audit éditorial doit multiplier les exemples concrets
afin de rendre compréhensibles les problèmes éditoriaux soulevés. Il
doit donner une vue d’ensemble facilitant la prise de décision.
Dans quel but l’utiliser :
• Communiquer les résultats de l’audit
• Conserver les résultats détaillés
Pré-requis :
• Grille d’audit renseignée – aspects éditoriaux
Composition/Plan :
• Contexte
• Synthèse
• Méthodologie employée
• Wording
• Structure éditoriale
• Accès au contenu
• Mise à jour du contenu
• Editing
• Auteurs
• Recommandations
• Faisabilité
Recommandations du rapport d’audit
– rapport_audit_recommandations.rtf
Les recommandations doivent être concrètes et quantifiées. Elles
doivent décrirent des actions portant sur des éléments précis et
opérationnels : modification de la feuille de style, ajout de
l’auteur de l’article, ajout d’une barre de progression, etc. La
charge, le planning, les risques liés à recommandation, doivent
être précisés.
Dans quel but l’utiliser :
• Présenter les actions à mener suite à l’audit
Pré-requis :

401
Conduite de projet Web

• Grille d’audit renseignée – aspects graphiques


• Grille d’audit renseignée – aspects ergonomiques
• Grille d’audit renseignée – aspects éditoriaux
Composition/Plan :
• Contexte
• Synthèse
• Recommandations éditoriales
• Recommandations ergonomiques
• Recommandations graphiques
• Recommandations techniques
• Recommandations organisationnelles
• Faisabilité
Note de concept – note_concept.rtf
La note de concept doit être courte et percutante. Elle doit être comprise
par tous les collaborateurs, quels que soient leur profil et leur connais-
sance du projet. Pour susciter l’adhésion, la qualité de la rédaction et de
la mise en page est très importante. Il peut être intéressant sur un projet
stratégique de confier la création du logo ou du gimmick à un free-lance.
Dans quel but l’utiliser :
• Vendre l’idée à la direction
• Fédérer les acteurs du projet
• Donner du concret à voir
• Préparer le lancement du projet en interne
Pré-requis :
• Rapport de benchmark
• Rapport de table ronde utilisateurs
• Recommandations suite à un benchmark
• Rapport d’audit
Composition/Plan :
• Attentes des utilisateurs
• Offres de la concurrence
• Positionnement du site
• Concept
• USP
• Logo et baseline

402
Annexe 1 – Contenu du CD-Rom

Marketing mix – marketing_mix.rtf


Le marketing mix rassemble en un document unique tous les
aspects de la futur offre : produit, prix, distribution, promotion. Il
doit être suffisamment détaillé pour permettre la création d’un
premier business plan. La pertinence des évaluations qu’il contient
est donc essentielle, qu’il s’agisse du nombre d’internautes visés, du
prix de l’offre ou des modes de commercialisation envisagés. Le
marketing mix peut être utilement utilisé – en version allégée – pour
les problématiques d’intranet et de portail. Il constituera alors une
base pour définir les indicateurs de performance du projet.
Dans quel but l’utiliser :
• Formaliser la réflexion
• Préparer le business plan
Pré-requis :
• Note de concept
• Rapport de benchmark
• Rapport de table ronde utilisateurs
• Recommandations suite à un benchmark
Composition/Plan :
• Cible
• Positionnement et offre de valeur
• Caractéristiques
• Politique de prix
• Politique de distribution
• Création
• Stratégie de communication

Business plan
Compte de résultats – compte_resultats.xls
Ce document permet de démontrer la rentabilité du projet et son
impact financier.
Dans quel but l’utiliser :
• Se convaincre de la viabilité du projet, convaincre les financiers
Pré-requis :
• Listes des coûts et revenus associés au projet
Composition/Plan :
• Document composé d’un seul tableau

403
Conduite de projet Web

Bilan prévisionnel – bilan_previsionnel.xls


Ce document est important pour montrer l’incidence de conditions
économiques ou d’événements futurs prévus sur la situation financière
du projet. Indispensable dans le cas d’une création d’entreprise.
Dans quel but l’utiliser :
• Évaluer les biens que possède le projet/l’entreprise
• Évaluer la façon dont à l’avenir la société pourra assurer l’auto-
nomie financière du projet
Pré-requis :
• Compte de résultats
Composition/Plan :
• Document composé d’un seul tableau
Seuil de rentabilité – seuil_rentabilite.xls
Reflète l’ensemble des flux financiers du projet.
Dans quel but l’utiliser :
• Calculer les besoins de financement
Pré-requis :
• Compte de résultats et bilan
Composition/Plan :
• Document composé d’un seul tableau
Plan de financement – plan_financement.xls
Montrer les besoins financiers à court terme.
Dans quel but l’utiliser :
• S’assurer que le projet ne se trouvera pas dans une impasse de
trésorerie pendant la première année
Pré-requis :
• Compte de résultats et bilan
Composition/Plan :
• Document composé d’un seul tableau
Gestion de trésorerie – gestion_tresorerie.xls
Dans quel but l’utiliser :
• Comprendre quel est le seuil/la date à partir duquel le projet sera
rentable
Pré-requis :
• Calcul de la marge sur coûts variables et taux de marge sur coûts
variables

404
Annexe 1 – Contenu du CD-Rom

Composition/Plan :
• Document composé d’un seul tableau

Faisabilité
Étude de faisabilité – etude_faisabilite.rtf
L’étude de faisabilité est un livrable très important qui permet de
choisir la solution la plus adaptée aux besoins de l’entreprise. La
rigueur qu’elle impose permet de justifier le choix en toute objecti-
vité. Le modèle doit être adapté à chaque cas en donnant plus ou
moins d’importance aux différentes parties. L’expression des besoins
est un travail long et fastidieux la première fois que l’on y procède
car elle doit être très précise. Mais on s’aperçoit vite que certains
besoins sont relativement standards et peuvent donc être réutilisés de
projet en projet : gestion des droits utilisateurs, gestion de contenu,
statistiques, etc. L’étude de l’existant est souvent sous-estimée. Car,
si ce n’est pas la partie apportant le plus de valeur ajoutée, c’est pour-
tant souvent la plus longue. Elle nécessite de nombreux entretiens
avec les différents responsables fonctionnels et techniques de l’entre-
prise. Le diagnostic doit bien différencier les écarts de couverture
fonctionnelle en deux catégories : généraux et internes.
Dans quel but l’utiliser :
• Décrire le contexte précis du projet
• S’assurer que le choix de la solution est objectif
• Faire adhérer au choix de la solution
Pré-requis :
• Note de cadrage
• Expression des besoins
• Étude de l’existant
• Diagnostic
• Étude des solutions
Composition/Plan :
• Cadrage du projet
• Expression des besoins
• Étude de l’existant
• Diagnostic
• Présentation des solutions
• Étude des solutions

405
Conduite de projet Web

Expression des besoins – expression_besoins.rtf


L’expression des besoins est un travail long et fastidieux la première
fois car elle doit être très précise. Mais on s’aperçoit vite que certains
besoins sont relativement standards et peuvent donc être réutilisés de
projet en projet : gestion des droits utilisateurs, gestion de contenu,
statistiques, etc. Il est donc recommandé, quand c’est possible, de
décrire les besoins de manière générique mais sans trahir les spécifi-
cités du projet. Une bibliothèque de fonctions de service étant ainsi
constituée, chaque nouvelle expression du besoin est plus rapide !
Dans quel but l’utiliser :
• Décrire précisément les besoins de l’entreprise
Pré-requis :
• Note de cadrage
Composition/Plan :
• Cadrage du projet
• Description des besoins fonctionnels
• Description des besoins éditoriaux
• Description des besoins ergonomiques
• Description des besoins graphiques
• Description des besoins techniques
• Description des besoins organisationnels
Étude de l’existant – etude_existant.rtf
L’étude de l’existant est souvent sous-estimée. Car, si ce n’est pas la
partie apportant le plus de valeur ajoutée, c’est pourtant souvent la
plus longue. Elle nécessite de nombreux entretiens avec les diffé-
rents responsables fonctionnels et techniques de l’entreprise. Les
premières discussions aboutissent presque toujours à une première
vision parcellaire qu’il faut compléter en rencontrant à nouveau ses
interlocuteurs.
Dans quel but l’utiliser :
• Décrire la (les) solution(s) existante(s)
• Décrire l’organisation de l’entreprise
• Décrire l’environnement technique de l’étude
Pré-requis :
• Note de cadrage
Composition/Plan :
• Description fonctionnelle de l’existant

406
Annexe 1 – Contenu du CD-Rom

• Description organisationnelle de l’existant


• Description technique de l’existant
Diagnostic – diagnostic.rtf
Il faut s’assurer, quand on rédige le diagnostic, que les écarts de
couverture fonctionnelle sont bien différenciés en deux catégories.
Les écarts généraux mesurent les absences de couverture fonction-
nelle. Les écarts « internes » mesurent les manques dans la manière
de couvrir un besoin. Par exemple, l’absence d’une fonction d’envoi
de newsletter est un écart général alors que l’impossibilité d’envoyer
la newsletter à plus de 50 utilisateurs à la fois (alors que le besoin est
de pouvoir l’envoyer à au moins 100 utilisateurs à la fois) est un
écart interne.
Dans quel but l’utiliser :
• Évaluer l’écart entre les besoins et l’existant
Pré-requis :
• Expression des besoins
• Étude de l’existant
Composition/Plan :
• Besoins fonctionnels
• Besoins éditoriaux
• Besoins ergonomiques
• Besoins graphiques
• Besoins techniques
• Besoins organisationnels
Présentation des solutions – presentation_solutions.rtf
La présentation des solutions doit être synthétique. Il ne s’agit pas
de lister en détail tout ce que les solutions permettent de faire (ce
peut être une annexe) mais plutôt de faire ressortir leur philosophie.
Ainsi, l’architecture technique et l’organisation doivent être résu-
mées en quelques schémas et tableaux. Le passage du système actuel
au futur système peut être un peu plus détaillé quand il représente
un risque important dans le projet. Les scénarios de mise en œuvre
doivent en revanche être le plus précis possible dans la mesure où la
justesse des plannings et des budgets en dépend.
Dans quel but l’utiliser :
• Présenter formellement les solutions pressenties
• Expliquer les différents scénarios de reprise de l’existant

407
Conduite de projet Web

• Expliquer les différents scénarios de mise en œuvre


• Présenter la charge, le planning et le budget correspondants
Pré-requis :
• Expression des besoins
• Étude de l’existant
• Diagnostic
Composition/Plan :
• Cadrage du projet
• Présentation des solutions techniques
• Présentation des solutions organisationnelles
• Passages du système actuel au futur système
• Scénarios de mise en œuvre
• Charges
• Plannings de mise en œuvre
• Budgets
Étude des solutions – etude_solutions.rtf
Ce document doit être synthétique. Il faut donc favoriser les
tableaux de synthèse, quitte à proposer le détail de l’analyse de la
couverture fonctionnelle en annexe. L’argumentation du choix de la
solution recommandée peut être long à rédiger quand les solutions
proposées ne se démarquent pas fondamentalement.
Dans quel but l’utiliser :
• Argumenter le choix d’une solution
• S’assurer que le choix de la solution est objectif
• Faire adhérer au choix de la solution
Pré-requis :
• Expression des besoins
• Étude de l’existant
• Diagnostic
• Présentation des solutions
Composition/Plan :
• Couverture fonctionnelle
• Évaluation technique
• Évaluation organisationnelle
• Difficultés de mise en œuvre

408
Annexe 1 – Contenu du CD-Rom

Grille de comparaison des solutions –


grille_comparaison_solutions.xls
Le coefficient associé à chaque critère doit être fixé lors de la réunion
de cadrage. En aucun cas, il ne doit être modifié lors de l’analyse des
solutions, le risque encouru étant de fausser l’objectivité du choix.
En effet, la modification d’un seul coefficient peut parfois suffire à
départager deux solutions de même qualité.
Dans quel but l’utiliser :
• Réaliser une analyse complète des solutions
Pré-requis :
• Expression des besoins
• Étude de l’existant
• Diagnostic
• Présentation des solutions
Composition/Plan :
• Document composé d’un seul tableau
Grille d’analyse de la faisabilité – aspects fonctionnels
– grille_faisabilite_fonctionnelle.xls
La grille d’analyse de la couverture fonctionnelle peut être utilisée
pour formaliser le diagnostic fonctionnel. Elle repose sur la liste de
fonctions de service rédigée lors de l’expression des besoins. Cette
grille doit être renseignée en s’appuyant sur un prototype ou en
analysant les versions standards des progiciels pressentis. Il est forte-
ment déconseillé de la renseigner en fonction des informations
marketing des éditeurs et des communautés. En effet, une couver-
ture fonctionnelle annoncée peut en fait ne pas exister (développe-
ments plus longs que prévus, abandon, etc.) ou être proposée d’une
manière telle qu’elle est inutilisable dans le cadre du projet.
Dans quel but l’utiliser :
• Réaliser uniquement l’analyse de la couverture fonctionnelle
Pré-requis :
• Expression des besoins
• Étude de l’existant
• Diagnostic
• Présentation des solutions
Composition/Plan :
• Document composé d’un seul tableau

409
Conduite de projet Web

Grille d’analyse de la faisabilité – aspects techniques et projet


– grille_faisabilite_technique.xls
Cette grille apporte une vision synthétique sur tous les aspects hors
couverture fonctionnelle. Elle est recommandée pour synthétiser les
différentes analyses réalisées par ailleurs.
Dans quel but l’utiliser :
• Analyser les aspects techniques (vision macro)
• Analyser les aspects projet (vision macro)
• Analyser les budgets (vision macro)
Pré-requis :
• Expression des besoins
• Étude de l’existant
• Diagnostic
• Présentation des solutions
Composition/Plan :
• Document composé d’un seul tableau

Appel d’offres
Cahier des charges – cahier_charges.rtf
Le cahier des charges ne doit pas être flou. Idéalement, il est soit très
court et laisse le champ libre aux candidats qui devront définir eux-
mêmes le périmètre de la prestation attendue, soit il est très détaillé
et aucune interprétation n’est possible. La première option a l’avan-
tage de demander un minimum de travail en amont mais complique
considérablement le dépouillement des offres dans la mesure où
aucune base de comparaison n’existe. Elle est donc conseillée sur des
besoins standards ne prêtant pas à des dérives. La seconde option
demande un important travail en amont (sauf si une étude de faisa-
bilité a été menée). Elle facilite en revanche le dépouillement
puisque l’utilisation de grilles de critères et d’un bordereau de prix
est possible.
Dans quel but l’utiliser :
• Rédiger un document formel en vue d’un appel d’offres
Pré-requis :
• Note de cadrage
• Expression des besoins
• Étude de l’existant
• Étude de faisabilité

410
Annexe 1 – Contenu du CD-Rom

Cahier des charges en anglais (specifications) – specifications.rtf


Ce cahier des charges est adapté à des projets de refonte de sites insti-
tutionnels internationaux dynamiques. Il peut cependant être adapté
sans difficultés à tout autre type de projets Web internationaux.
Dans quel but l’utiliser :
• Rédiger un document formel en vue d’un appel d’offres interna-
tional
Pré-requis :
• Note de cadrage
• Expression des besoins
• Étude de l’existant
• Étude de faisabilité
Composition/Plan :
• Context
• Project Organisation
• Project Environment
• Needs Overview
• Functional Needs Per Site
• Basic Needs
• Technical Requirements
• Organizational Requirements
• Usability and Graphical Requirements
• Documents To Be Provided by the Agency
• Presentation Meeting
• Selection Criteria
Bordereau de prix – bordereau_prix.rtf
Cet outil doit être couplé à une grille Excel qui automatisera les
calculs et la consolidation des différentes offres. Pour cela, il faut
d’abord vérifier que les candidats n’ont pas modifié la structure du
document Word. Il suffit ensuite de copier/coller les bordereaux
Word dans autant d’onglets Excel. La consolidation n’est plus
qu’une simple histoire d’addition entre feuilles de calcul.
Dans quel but l’utiliser :
• Simplifier le dépouillement des offres
• Comparer plus facilement les budgets
Pré-requis :
• Présentation des solutions

411
Conduite de projet Web

• Étude de faisabilité
Composition/Plan :
• Document composé d’un seul tableau
Synthèse – grille_synthese.xls
Le coefficient associé à chaque critère doit être fixé lors de la réunion
de cadrage. En aucun cas, il ne doit être modifié lors de l’analyse des
offres, le risque encouru étant de fausser l’objectivité du choix. En
effet, la modification d’un seul coefficient peut parfois suffire à
départager deux offres de même qualité.
Dans quel but l’utiliser :
• Faciliter le dépouillement des offres
• Objectiver le choix du candidat
• Préparer l’argumentation
Pré-requis :
• Offres réceptionnées
Composition/Plan :
• Onglet candidats
• Onglet solutions
• Onglet synthèse
Grille d’analyse des candidats – grille_candidats.xls
Les critères de la grille d’analyse des candidats doivent être ajustés
en fonction de la nature du projet, du secteur d’activité, etc. Les
sous-critères standards peuvent être facilement activés ou désactivés
en utilisant le switch prévu à cet effet. Attention, en supprimant un
sous-critère, le poids de chaque critère diminue d’autant.
Dans quel but l’utiliser :
• Comparer les candidats
Pré-requis :
• Évaluer le risque
Composition/Plan :
• Document composé d’un seul tableau
Grille d’analyse des solutions – grille_solutions.xls
Les critères de la grille d’analyse des solutions doivent être ajustés en
fonction de la nature des besoins. Les sous-critères standards
peuvent être facilement activés ou désactivés en utilisant le switch

412
Annexe 1 – Contenu du CD-Rom

prévu à cet effet. Attention, en supprimant un sous-critère, le poids


de chaque critère diminue d’autant.
Dans quel but l’utiliser :
• Synthétiser l’analyse des différents aspects des offres
Pré-requis :
• Pas de pré-requis
Composition/plan :
• Document composé d’un seul tableau

Conception
Charte éditoriale – charte_editoriale.rtf
Une bonne charte éditoriale est toujours composée de deux parties.
La première synthétise la stratégie et son application concrète au
travers du rubriquage, des gabarits éditoriaux et des axes de catégo-
risation. La seconde concrétise la charte au travers d’exemples
permettant à tout collaborateur de comprendre les différences
d’angle, de style, etc.
Dans quel but l’utiliser :
• Rassembler en un document unique tous les éléments éditoriaux
du site
• Créer un référentiel éditorial
Pré-requis :
• Ligne éditoriale
• Dossier de rubriquage
• Dossier de workflows
Composition/Plan :
• Ligne éditoriale
• Rubriquage
• Gabarits
• Axes de catégorisation du contenu
Ligne éditoriale – ligne_editoriale.rtf
La ligne éditoriale est un court document de une à deux pages au
maximum. Chaque terme employé doit faire sens. Le positionne-
ment, le style et le ton en particulier doivent être rédigés avec
clarté.
Dans quel but l’utiliser :
• Définir la stratégie éditoriale

413
Conduite de projet Web

Pré-requis :
• Note de cadrage
• Note de concept
• Marketing mix
Composition/Plan :
• Cible
• Lectorat
• Positionnement
• Style
• Ton, formats éditoriaux
Dossier de rubriquage – rubriquage.rtf
Le dossier de rubriquage est bien adapté aux sites statiques. Il
rassemble en quelques tableaux tout le contenu du site. Plus la
colonne de contenu sera précise et plus le rubriquage sera réaliste.
Dans le cas d’un site dynamique, une arborescence peut suffire.
Dans quel but l’utiliser :
• Définir précisément le contenu du site
• Évaluer la volumétrie d’articles ou de pages
Pré-requis :
• Ligne éditoriale
Composition/Plan :
• Document composé d’une série de tableau
Dossier de workflows – workflow.rtf
Le nombre de rôles et de processus doit être limité. Un projet Web
comportant plus de 10 rôles et 20 processus peut-être considéré
comme complexe. La description des processus doit être pragma-
tique. Il est indispensable de toujours se demander comment tel ou
tel collaborateur s’y prendrait de manière à ne pas devenir trop théo-
rique. L’utilisation de logigrammes est fortement recommandée.
Dans quel but l’utiliser :
• Mettre en place l’organisation éditoriale
• Formaliser les processus de mise à jour
• Identifier les acteurs des processus
Pré-requis :
• Dossier de rubriquage
• Gabarits éditoriaux

414
Annexe 1 – Contenu du CD-Rom

• Solution organisationnelle présentée dans l’étude de faisabilité


Composition/Plan :
• Synthèse des processus/rôles
• Profils
• Processus
Cinématique – cinematique.rtf
La cinématique se construit en deux temps. Pour commencer, la
maquette fonctionnelle est dessinée dans PowerPoint. Quand elle
donne satisfaction et/ou quand elle a été validée par le panel d’utili-
sateurs, puis validée par la MOA, on réalise des images de chaque
page. Ces images sont insérées dans le modèle. Commence alors un
travail précis de description de chaque composant. Le but est d’être
le plus précis possible pour fournir aux développeurs et aux
graphistes une vision qui soit la plus réaliste possible.
Dans quel but l’utiliser :
• Donner du concret à voir aux utilisateurs du panel
• Définir avec précision les processus
• Définir avec précision les proportions textes/images/formulaires
• Définir avec précisions les règles d’affichage
• Valider le rubriquage
Pré-requis :
• Charte éditoriale
• Dossier de rubriquage
• Expression des besoins
Composition/Plan :
• Identifiants de pages
• Captures d’écran
• Détail de chaque composant
• Commentaires
Charte ergonomique – charte_ergonomique.rtf
Ne pas hésiter à mettre en perspective la charte au moyen de quel-
ques chiffres clés illustrant les problèmes les plus courants (résolu-
tions, plug-in, vie privée, etc.) et les standards de faits (logo en haut
à gauche comme retour à l’accueil, souligné = lien, etc.). Décrire en
détail la structure standard en argumentant pourquoi tel ou tel
choix a été effectué. Plus la charte sera illustrée d’exemples et de
contre-exemples, plus elle sera attractive et compréhensible. Il est

415
Conduite de projet Web

donc important de prendre le temps de trouver des contre-exemples


et s’assurer que le site exemple est conforme aux règles énoncées...
Dans quel but l’utiliser :
• Garantir un niveau minimal d’expérience utilisateur
• Homogénéiser les interfaces des sites de l’entreprise
Pré-requis :
• Cinématique
Composition/Plan :
• Objectifs
• Présentation générale
• Comment lire les règles
• Règles obligatoires
• Règles conseillées
Charte graphique – charte_graphique.ppt
La charte graphique doit être opérationnelle. Elle doit décrire en
détail chaque template (largeur en pourcentage ou pixel, CSS, etc.)
et fournir des fichiers source utilisables : PSD et AI avec calques non
aplatis, code JavaScript commenté, CSS commentées, etc.
Dans quel but l’utiliser :
• Fournir aux prestataires un guide de travail
• Homogénéiser les identités des sites de l’entreprise
• Maîtriser l’image de l’entreprise sur Internet ou intranet
Pré-requis :
• Maquette HTML
Composition/Plan :
• Règle de nommage
• Emplacement des éléments
• Couleurs
• Typographies
• Visuels
• Template
Rapport de test utilisateurs – rapport_test_utilisateur.rtf
Le rapport de tests utilisateurs est le complément idéal à la vidéo et
aux captures d’écrans réalisées pendant les tests. Pour qu’il soit réel-
lement utile, le rapport de test doit décrire avec précision le
problème et son contexte, et si possible illustrer chaque problème

416
Annexe 1 – Contenu du CD-Rom

avec une capture d’écran et un verbatim. Les solutions envisagées


doivent elles aussi être illustrées.
Dans quel but l’utiliser :
• Formaliser les problèmes rencontrés par les utilisateurs lors des
tests
• Assurer un suivi des problèmes (problème/solution sur la même
page)
Pré-requis :
• Tests utilisateurs
Composition/Plan :
• Contexte
• Synthèse
• Titre du problème
• Priorité
• Description du problème
• Description de la solution fonctionnelle
• Description de la solution technique
• Impact technique
• Impact fonctionnel
• Impact graphique
• Charge prestataire
• Charge client
• Risque
Spécifications fonctionnelles – specifications_fonctionnelles.rtf
La première partie (arborescence, rubriquage, workflow, etc.) doit
être synthétique, son rôle étant de donner une vue d’ensemble du
projet. En revanche, la description des fonctions de service attendues
doit être très précise. On peut par exemple intégrer les images de la
cinématique pour illustrer chaque fonction de service.
Dans quel but l’utiliser :
• Briefer un prestataire
• Briefer le chef de projet technique
• Valider le projet auprès de la MOA avant de commencer la réali-
sation
Pré-requis :
• Charte éditoriale
• Charte ergonomique

417
Conduite de projet Web

• Cinématique
• Expression des besoins
Composition/Plan :
• Contexte
• Arborescence générale
• Rubriquage et workflows
• Cinématique
• Fonctions de services
• Contraintes
Spécifications techniques – specifications_techniques.rtf
La première partie (arborescence, rubriquage, workflows, etc.) doit
être synthétique, son rôle étant de donner une vue d’ensemble du
projet. La description des données et des traitements doit reposer
sur des éléments visuels (images du MCD et du MOT) et renvoyer
au MCD, rarement présentable dans une page A4 ! L’architecture
technique, et notamment logicielle, doit être précise : les versions
des logiciels et des matériels sont à préciser.
Dans quel but l’utiliser :
• Briefer un prestataire
• Briefer les développeurs
• Valider le projet auprès de la MOA avant de commencer la réali-
sation
Pré-requis :
• Spécifications fonctionnelles
Composition/Plan :
• Contexte
• Description générale
• Fonctions de service
• Contraintes
• Description des données
• Description des traitements
• Architecture technique
• Règles de codage et conventions de nommage

418
Annexe 1 – Contenu du CD-Rom

Réalisation
Storyboard – storyboard.rtf
Le storyboard sert essentiellement à valider le scénario avec le client.
Chaque page doit donc être validée avant que le travail de création
ne débute.
Dans quel but l’utiliser :
• Préparer la création d’une animation Flash
Pré-requis :
• Scénario
Composition/Plan :
• Image de la scène
• Arrière-plan
• Premier plan
• Effet
• Voix off
• Ambiance
• Bruitage
• Interactivité
Plan de lotissement – plan_lotissement.rtf
Le plan de lotissement peut être utilisé lors de l’étude de faisabilité
ou lors de la préparation de l’appel d’offres comme support de la
réflexion. C’est aussi un outil utile en phase de réalisation pour
répartir le travail entre les équipes. Il apporte de la transparence,
chaque équipe ou prestataire sachant ce que les autres font.
Dans quel but l’utiliser :
• Répartir le travail entre plusieurs prestataires
• Répartir le travail entre plusieurs équipes
• Passer des marchés spécifiques

Pré-requis :
• Cahier des charges
• Scénario de mise en œuvre
• Listing des tâches à réaliser
• Listing des livrables attendus
Composition/Plan :
• Vue d’ensemble

419
Conduite de projet Web

• Nom du lot
• Identifiant du lot
• Lot précédent
• Lot suivant
• Listing des tâches
• Listing des livrables
• Risques
• Date de début
• Date de fin
• Charge allouée
• Équipe en charge du lot
• Responsable de l’équipe et coordonnées
Plan de reprise de l’existant – plan_reprise_existant.rtf
La solution de reprise doit être décrite de manière très concrète :
processus détaillés en cas de reprise manuelle, exemples de codes, etc.
Dans quel but l’utiliser :
• Formaliser la réflexion
• Valider les solutions de reprise avec la MOA
Pré-requis :
• Listing des données à reprendre
• Descriptif de la plate-forme technique cible (architecture appli-
cative et logicielle notamment)
Composition/Plan :
• Nom des données à reprendre
• Identifiant de reprise
• Descriptif des données
• URL
• Volumétrie
• Exemple de données
• Technologie
• Lieu où sont hébergées les données
• SGBD
• Connexions possibles au SGBD
• Responsable des données
• Description de la solution de reprise
• Charge de travail

420
Annexe 1 – Contenu du CD-Rom

• Contributeur(s) pressenti(s)
• Date de début
• Date de fin
• Risque
• Impact organisationnel
Fiche d’anomalie – fiche_anomalie.rtf
Pour être utilisable, la fiche d’anomalie doit impérativement
comporter l’URL (elle est très souvent oubliée), une description et
surtout le contexte dans lequel l’anomalie s’est produite : environ-
nement technique, place dans le processus, etc.
Dans quel but l’utiliser :
• Encadrer un test utilisateurs
• Remonter des bogues en période de garantie
• Remonter des bogues en vitesse de croisière
Pré-requis :
• Note de cadrage
Composition/Plan :
• Document composé d’une série de tableau

Mise en service
Plan de formation – plan_formation.rtf
Il est important de ne pas négliger les aspects matériels (salle,
connexions réseau, droits réseau, hébergement, etc.) car ils peuvent
représenter des obstacles et/ou des coûts non négligeables.
Dans quel but l’utiliser :
• Évaluer l’écart entre les compétences disponibles et celles requises
• Formaliser les formations envisagées
• Évaluer le coût des formations
• Valider le plan de formation avec la hiérarchie
Pré-requis :
• Listing des collaborateurs impliqués par le changement
Composition/Plan :
• Besoin(s) généré(s) par le nouveau système
• Formation(s) envisagée(s)
• Formateurs et key users
• Support(s) de formation

421
Conduite de projet Web

• Salle(s)
• Matériel
• Communication
• Planning
• Budget
Plan de communication – plan_communication.rtf
Pour que le plan de communication soit pertinent, il faut que
l’objectif de communication et la cible soient très clairs. Le but du
document est de synthétiser les grandes lignes du projet, quitte à
proposer en annexes le plan média détaillé.
Dans quel but l’utiliser :
• Formaliser la réflexion
• Évaluer le coût
• Valider le plan avec la hiérarchie
Pré-requis :
• Note de cadrage
Composition/Plan :
• Cibles
• Objectifs
• Promesse
• Ton et ambiance
• Plan média (y compris on-line)
• Référencement et positionnement
• Planning
• Budget

422
Annexe 2
Glossaire

ASP
Application Service Provider ou Active Server Pages. Dans le cas d’Active
Server Pages, il s’agit d’une page HTML qui contient un ou plusieurs
scripts exécutés dynamiquement sur le serveur Web avant que la page ne
soit envoyée au navigateur. Dans le cas d’Application Service Provider, c’est
une application distante accessible et utilisée via un client Web (en général
louée au mois).
CNIL
Commission nationale informatique et libertés. Elle est chargée de veiller
au respect de la vie privée des citoyens français et notamment de leur
assurer un droit de regard et de suppression des fichiers informatiques.
COM+
Component Object Model plus. Version améliorée de COM de Microsoft,
modèle à la base d’OLE, ActiveX et DirectX.
EJB
Enterprise JavaBeans. Composants logiciels écrits en JAVA et situés côté
serveur. Les EJB sont une spécification de Sun.
FTP
File Transfert Protocol, protocole de transmission de fichiers dans les
réseaux TCP/IP. Un serveur FTP permet à celui qui s’y connecte de télé-
charger des fichiers, des programmes, des mises à jours, etc.

423
Conduite de projet Web

GRC
Gestion de la relation client. Ensemble des processus concourant à
la conquête et la fidélisation d’une clientèle. Aussi appelée CRM
(Customer Relationship Management).
HTML
HyperText Markup Language. Langage informatique défini par le
CERN qui repose sur la norme ISO-SGML. Il permet la création
de documents affichables par un navigateur Web grâce à l’insertion
dans le texte de balises structurantes (<table> par exemple) et de
mise en forme (<b>, <u>, <i> par exemple).
HTTP
HyperText Transfer Protocol. Protocole qui permet l’échange de
données entre un serveur Web et un client Web.
J2EE
Serveur d’application basé sur Java disposant d’une machine
virtuelle (JVM) et d’un framework.
LDAP
Lightweight Directory Access Protocol. C’est un protocole de
gestion d’annuaires qui permet à des clients Internet d’accéder auto-
matiquement à des services d’annuaires en ligne sur TCP.
MOA
Maîtrise d’ouvrage. La maîtrise d’ouvrage définit les objectifs et les
exigences du site ou de l’application, valide les solutions proposées,
prépare et pilote la conduite du changement.
MOE
Maîtrise d’œuvre. La maîtrise d’œuvre propose et réalise les solu-
tions.
.NET
Serveur d’application de Microsoft disposant d’une machine
virtuelle (CLR) et d’un framework (.NET framework).
PDF
Portable Document Format. Format de fichier vectoriel qui permet
l’impression et la visualisation via le plug-in Acrobat Reader
(Adobe).

424
Annexe 2 – Glossaire

PHP
À l’origine Personal Home Page ; Hypertext Preprocessor depuis la
version 3. Serveur d’application et langage de programmation Open
Source.
RTF
Rich Text Format. Il s’agit d’un format de texte reconnu par la
plupart des logiciels de traitement de texte. Le RTF permet
d’échanger des textes entre logiciels différents sans perdre (ou
presque) les principaux éléments de formatage (contrairement au
format texte seul).
SGBD/R
Système de gestion de base de données relationnelle. Ce système
repose sur le modèle relationnel pour les traitements de données.
WYSIWYG
What You See Is What You Get. Ce logiciel permet de travailler en
mode « prévisualisation ».
XML
eXtensible Markup Language. C’est une évolution du SGML. Ce
langage permet de définir ses propres balises dans un document
HTML.

425
Index

A authentification 36
agence interactive 189 B
AMOA (Assistance à maîtrise
d’ouvrage) 383, 384 benchmark 113, 117, 129, 132
analyse 115 besoin 165
animation 256, 257 bilan prévisionnel 156-158
annuaire LDAP 29 bordereau de prix 200, 204
appel d’offres 185, 194, 195, 196, brief 199, 201
370, 371 budget 17, 37, 42, 43, 92, 98, 147,
ouvert 195, 196 153, 176, 204, 205, 291, 293
restreint 195, 196 business
architecte 56 model 138, 156
architecture 234 plan 38, 145, 146-148, 150,
à trois niveaux 43 151, 155
applicative 234
logicielle 235 C
matérielle 234, 235 cahier des charges 98, 167, 185,
technique 234 194-196, 198
argumentaire 101 campagne de communication 98,
ASP (Application Service Provider) 290, 293, 295
8, 9, 14, 18, 57 capping 293
Atos 378 catalogue 8, 9, 10, 12, 375, 377, 380
audience 114, 118, 119, 295 CGV (conditions générales de ven-
audit 118 te) 96, 376, 378
de l’existant 118, 129 chaîne de valeur 115
éditorial 120, 122, 124 champion 101
ergonomique 122 charge de travail 61
graphique 124 charte graphique 124, 226, 229-231

427
Conduite de projet Web

check-list 11, 16, 24, 27, 31, 36, hébergement du site Web 88
121, 123, 170, 172 multi-objet 87
chef de projet 50, 52, 54-57, 59 réalisation du site Web 88
choix d’une solution 181 Web 82
Chronopost 379 contrôle
cinématique 221-223 de conformité 84
classes produits 378 de gestion 38, 100
colisage 378 copie stratégie 291
comité couponing 378
de pilotage 51, 52, 383 coûts 95, 96, 97
de projet 51 cross-selling 13
commandes 13
gestion des ~ 13 D
communauté virtuelle 25 data mining 13
communication 290 déclaration préalable 71
compétitivité 28, 37, 92, 152 designer 57, 58, 125
compte de résultat 153, 156, 159 développement 257
prévisionnel 156 diagnostic 173-175
concept 133 diffusion 140
board 224, 225 directeur
concepteur rédacteur 59 artistique 57, 58, 224, 226
conception de création 57, 58
fonctionnelle 212 de projet 54, 57
graphique 224 éditorial 58, 59
technique 233 direction générale 100, 101
conduite du changement 30, 61, documentation 199, 260
99, 102, 176, 268, 269 donnée personnelle 75
connaissance 28 dossier
conseils de rubriquage 212, 216
en AMOA 187 Drupal 275, 277, 383, 384
en architecture 188
consultant 55, 56, 58, 125 E
fonctionnel 55 EAI (Entreprise Application In-
technique 55 tegration) 34
contenu 134, 251 e-business 12
éditorial 252 écart 173
gestion de ~ 17-21, 217 économies 40, 92, 94, 99, 152
graphique 255 écotaxe 378, 379
contexte 112 EII (Entreprise Information In-
contrat tegration) 35

428
Index

élément financier 150 des utilisateurs 13, 32


e-mail prévisionnelle de trésorerie
entrant 17, 19, 20 156, 159, 160
gestion des ~ 17, 20 GRC (gestion de la relation
sortant 23 client) 13
entretien en face à face 242 grille
enveloppe budgétaire 95 d’analyse 114, 204
ergonome 58, 223, 224 de critères 193
ergonomie 223
ERP (Entreprise Resource Plan- H
ning) 13, 15
hébergeurs 190
étude
HTML 45, 231
d’impact 137
de faisabilité 53, 181
de l’existant 169, 175
I
des solutions 177, 180, 181 identification 36
expression des besoins 166, 169, illustrations 255
174 image 29, 98, 124, 226, 293
eZ Publish 275, 383 de l’entreprise 16, 226
indicateur 38, 92-95, 98, 99,
F 295
facteur clé de succès 59, 190 de performance 38
fédérer 25, 28, 54, 100 ingénieur 52, 56, 57
filtrage collaboratif 13 d’études 56
Firefox 275, 277, 280, 283, 286 intégrateurs 189
fonction de service 166 intégration 13, 32, 36, 258
formalité préalable 67 interlocuteur unique 60
formateurs relais 52, 268, 271 intranet 27, 28, 30
formation 61, 268, 269, 271
frais de port 378 J
framework 43
J2EE 381
G Joomla! 383
JUnit 277
gabarit 223, 230
garantie 84 K
gestion
des clients 376 Kelkoo 379
des commandes 376
des membres 26 L
des stocks 376 LAMP 385

429
Conduite de projet Web

LDAP (Lightweight Directory moteur de recherche 32


Access Protocol) 36
ligne éditoriale 120, 136, 212, N
213, 253 nom de domaine 67
lot 258 nomade 31
lotissement 257, 258 notoriété 92, 93, 98, 290, 293
nuage de tags 382
M
Magento 378 O
manuel objectifs
d’exploitation 260 chiffrés 92, 95
utilisateurs 260, 268 quantifiés 36, 142
mapping 116 obligation de résultat 84
maquette HTML 229 offre 130, 136
marché 112, 129, 148 OS Commerce 378
marketing mix 143
Web 133, 134, 138 P
marque 22
Merise 217, 236, 239 paiement 13
Microsoft 381 panier 13
migration 35 moyen 13
mise à jour 215, 216 PAP ( page avec publicité) 293
mise en concurrence simplifiée PAQ (plan d’assurance qualité)
196 198
mise en œuvre 267, 299 parrainage 376
MOA (maîtrise d’ouvrage) 60 périmètre fonctionnel 42
mode de paiement 376 personnalisation 13, 17
modèle piste graphique 226, 228
conceptuel 239-241 plan
conceptuel des données 239 d’assurance qualité 198
conceptuel des traitements de communication 290, 293
240 de financement 156, 159
logique des données 241 de formation 268
opérationnel des traitements média 290, 292, 294
240 PLV (publicité sur lieu de vente)
physique des données 241 295
modélisation 217, 236 point d’accès unique 27
modules 383, 384 points de fidélité 378
MOE (maîtrise d’œuvre) 60 portail 31-34
montée en charge 43, 274 d’entreprise 31, 63

430
Index

positionnement 98, 116, 117, rubriquage 212


131, 132, 143, 150, 299, 312 dossier de 212
Web 131
PowerBoutique 376 S
présentation des solutions 181 sécurité 235
Prestashop 378 Selenium 275-283, 285, 286,
prestataire 186, 190, 192 288, 298, 385
prix 138 Grid 277
procédure 195 IDE 275, 277, 280, 281,
négociée 195, 196, 197 286
processus 29, 32, 35, 171, 178, RC 277
216, 217, 221, 260, 270 service 134, 168
d’achat 7, 12, 136 seuil de rentabilité 156, 160
produit 134 short-list 192, 194, 201
profil 31, 35, 55, 189, 205, 215, site
221 catalogue 6, 12
promotion 142, 375, 377, 378 communautaire 25
propriété 84 de marque 22, 62, 93
institutionnel 16, 17, 120
Q marchand 11-13, 26, 63
questionnaire 127, 242, 243 SOA (Simple Object Access) 43
aux fournisseurs 202 solution 175, 177, 180, 202
packagée 8
R spécifications
RDF (Resources Description fonctionnelles 231, 232
Framework) 18 techniques 241
réalisation 251 SSII (société de service et d’ingé-
recette 273, 288, 289 nierie informatique) 188, 189
recherche à facettes 381 SSO (Single Sign-On) 33, 36
recommandation 117, 125 stocks 158
référencement 88, 98, 299 état des ~ 13
référentiel 8, 9, 11, 20, 185, 194 gestion des ~ 13
documentaire 381 stratégie 150
Remote Control 277 technologique 39
reprise de l’existant 15, 176, 261 suite de gestion commerciale 14,
responsabilité 60, 85 15
risque 151 suivi de commande 376
juridique 88 synergie 104, 105
rôles 60 système de paiement 378

431
Conduite de projet Web

T TVA 378, 379


tables rondes 126, 127, 130,
242, 243
U
taux de clics 295 Ubercart 378
taxonomie éditoriale 21 UML (Unified Modeling
template 224, 229 Language) 217, 236
test 243 UPS 379
d’intégration 259 use case 217
d’usabilité 245
de la maquette 244 V
de montée en charge 274
du concept 243, 244 vente 93
du singe 273 Vignette 383
fonctionnel 274 visibilité 258, 290, 293
unitaire 259 vision 150
utilisateur 242
TestNG 277 W
tests 275-281, 286-288, 298
texte 252 workflow 18, 216, 381
texte riche 381
traduction 253, 254
X
trafic 141, 290, 294, 296 XML 18, 40, 45

432

Vous aimerez peut-être aussi