7 points clés pour réussir la refonte d'un site
le 7 Juin 2007, par Stéphane
Plus compliquée qu'une simple création, la refonte de site demande une préparation minutieuse et un cahier des charges très précis. Revue de détails des bonnes pratiques pour réussir à coup sûr.
Selon une étude réalisée par Borland, 72% des problèmes rencontrés lors des développements d’un site sont dus à une mauvaise expression des besoins. A cette occasion, le travail d’expression du besoin est souvent sous-évalué car « il suffit de s’appuyer sur l’existant ». Cette logique est tout simplement absurde puisqu’une refonte s’accompagne presque toujours d’une mise à niveau technologique qui implique, au minimum, l’utilisation d’un nouveau progiciel de gestion de contenu. Ce dernier influe fortement sur la façon de décrire l’existant, sans compter la mise à niveau ou la création des workflows. Ainsi, on passe souvent de pages statiques produites avec un éditeur HTML à la génération dynamique de pages via un formulaire de saisie et des modèles graphiques.
Ne pas sous-estimer l’importance de l’existant
OK, alors comment faire ? La première étape consiste à décrire l’existant le plus précisément possible. Ce travail sera utile lors de l’appel d’offres. Il permettra aux candidats qui ne connaissent pas l’entreprise d’appréhender avec clarté le chemin à parcourir entre l’existant et le futur site. Le tableau ci-dessous résume les principales informations à obtenir. Cette étape est aussi l’occasion de récupérer les différents fichiers sources qui seront nécessaires au cas où le prestataire actuel ne serait pas retenu : fichiers Photoshop multi calques non aplatis pour l’interface graphique, export des bases de données, informations relatives à la sécurité (identifiants, mots de passe, URL…), etc.
Adapter sa vision aux contraintes techniques
La deuxième étape consiste à imaginer le futur site et à le décrire en tenant compte des contraintes des technologies utilisées. Ainsi, si un rubriquage, une arborescence et une cinématique sont indispensables, ils ne suffisent pas. Dans le cas d’un site fortement éditorial, la description des gabarits éditoriaux est essentielle. Elle doit être réalisée en utilisant la logique et le vocabulaire de l’outil qui sera utilisé, à défaut, en ayant recours à un vocabulaire standard. Le même travail doit bien sûr être effectué avec les workflows en utilisant, par exemple, des logigrammes. Dans le cas d’un site fortement transactionnel, c’est la formalisation des processus qui doit retenir toute l’attention. Une fois encore, ce travail doit tenir compte des contraintes liées à l’outil utilisé.Se poser les bonnes questions
La troisième étape consiste à identifier les évolutions fonctionnelles, organisationnelles, graphiques… entre l’existant et le futur site. Cette étape est un facteur clé de succès dans la mesure où elle permet de formaliser le besoin réel avec précision. S’agit-il d’une refonte ergonomique et graphique ? D’un re-développement total dans une nouvelle technologie mais avec un fonctionnel identique ? De la factorisation de composants métiers ? etc. L’idéal est de décrire le besoin en une phrase en utilisant le principe du EST/N’EST PAS.
Evaluer la faisabilité
Une fois les besoins réels identifiés, reste à savoir si la vision du projet est réaliste et surtout quel sera le meilleur scénario de reprise de l’existant (contenu stocker en base de données, comptes utilisateurs, etc.). Le moyen le plus sûr pour y parvenir est de réaliser une mini-étude de faisabilité pour chaque « point dur » du projet (factorisation de composants entre sites quand la refonte s’applique à une constellation, fonctions de services spécifiques quand il s’agit d’un seul site, etc.). A ce stade, le recours à un consultant spécialisé -consultants de l’éditeur, architecte d’un cabinet ou d’une SSII par exemple- est quasiment indispensable quand la technologie est propriétaire.
Préparer avec soin la reprise des contenus
En parallèle, une attention particulière doit être portée à la reprise du contenu. Où se trouve-t-il ? Sous quelle forme est-il stocké ? Une reprise automatique est-elle envisageable ? Existe-t-il un écart important entre le rubriquage actuel et celui du futur site ? Si oui, qui écrit/réécrit quoi ? En utilisant quel outil ? etc. Les réponses à ces nombreuses questions orienteront fortement la démarche globale du projet. Elles posent en premier lieu la question de la nouvelle organisation. Celle-ci dépend directement de la volumétrie (une projection du rubriquage sur un an), des fonctionnalités de l’outil de gestion de contenu et des compétences disponibles dans l’entreprise. Elle demande souvent du temps pour être opérationnel : recrutements internes/externes, découverte du projet, formation, période de « rodage », etc.
Ne pas oublier le problème des comptes utilisateurs
Enfin, la migration des comptes utilisateurs ne doit pas être oubliée. Elle aussi peut s’avérer difficile, quand on passe, par exemple, d’un système « manuel » d’attribution des droits à une infrastructure de single sign on. Une fois de plus, une mini-étude de faisabilité doit valider un scénario avant que le cahier des charges ne soit rédigé.
Rédiger le cahier des charges quand tous les choix sont validés
Evident ! Pourtant de nombreux projets sont retardés ou annulés après leur lancement parce que l’implication des choix éditoriaux, fonctionnels, organisationnels et techniques n’a pas été suffisamment assimilée avant la prise de décision. L’un des point essentiel est donc de s’assurer que le comité de pilotage à conscience des actions qui devront être menées pour mettre en place la nouvelle organisation. Car la direction devra parfois expliquer à des collaborateurs que leur rôle va évoluer sans alternative possible… Dans le même ordre d’idées, quand une nouvelle technologie est utilisée, il n’est jamais inutile de rappeler le calcul du ROI qui a présidé au choix de sorte que la répartition budgétaire soit comprise… et effective !
Au final, la refonte d’un site doit être appréhendée avec encore plus de rigueur qu’un projet de création « from scratch ». Car les pièges sont beaucoup plus nombreux alors même que le projet paraît plus facile.
Article paru sur www.zdnet.fr, Stéphane Bordage