On dit toujours les cordonniers plus mal chaussés que leurs concitoyens. Je jugez donc pas ce qui suit à l’aune de ce site, peut être aurai-je un jour le temps d’en faire quelque chose d’acceptable. Et puis de toute manière, un blog se lit via son flux XML, pas directement.

Je réalise des sites web depuis le milieu de l’été 1996, et j’ai fini un peu par hasard par en faire mon métier. Durant des années, je crus la réfection d’un site ou d’une application moins difficile et coûteuse en terme de travail, de temps, et d’aspirine qu’un départ de zéro : la tâche ayant été préalablement accomplie par d’autres, il me suffirait simplement de réutiliser l’existant sans trop réfléchir.

Grave erreur, toutes mes tentatives dans le domaine se soldèrent en catastrophe, jusqu’à ce qu’une série d’échecs cuisants et humiliants me poussent à changer mon fusil d’épaule et à adopter une autre méthode.

1. N’oubliez jamais la cible du site.

Il est nécessaire de se poser les bonnes questions dès le départ sous peine de devoir tout recommencer à la fin.

  • Quel est le commanditaire du site ?
  • Quelle image donne-t-il de lui hors ligne ?
  • Quels sont ses clients habituels ?
  • Quelles sont les cibles marketing visées par la refonte ?

Ce premier questionnement devrait vous permettre d’aborder sereinement la partie fonctionnelle : il est toujours plus aisé de savoir ce qu’on veut proposer si on sait à l’avance qui va s’en servir. Cela permet de supprimer certaines fonctionnalités non utilisées ou inadéquate du site actuel pour le recentrer vers son véritable objectif.

Cela permettra aussi de définir un visuel adapté à l’image de marque du client, surtout si celui-ci ne possède pas encore de charte graphique en ligne – ça existe encore : un vendeur de survêtements en ligne n’aura pas les mêmes besoins visuels et ergonomiques qu’une banque de patrimoine ou une collectivité locale.

2. Étudiez l’existant.

Tout comme il serait une erreur de récupérer l’existant tel quel, aussi bien en terme de fonctionnalités, d’arborescence que de contenu, il ne faut pas non plus tomber dans l’excès inverse et tout jeter à la poubelle : les utilisateurs habituels doivent profiter des nouveautés offertes sans toutefois perdre leurs marques.

Là aussi, il convient de se poser quelques questions.

  • Les rubriques actuelles correspondent-elles aux objectifs définis ?
  • Le contenu actuel est-il pertinent ? Correspond-t-il à l’image de la nouvelle charte ?
  • Le ton employé correspond-il aux nouveaux besoins ?
  • Les informations diffusées sont elles toujours pertinentes ?
  • L’arborescence actuelle peut-elle être conservée ? améliorée ?

Il convient ensuite de séparer l’existant en quatre groupes :

  1. Ce qui peut être conservé tel quel.
  2. Ce qui peut être amélioré.
  3. Ce qui doit être remplacé.
  4. Ce qui doit être supprimé.

3. Développez selon les standards du web.

On ne le dira jamais assez, conformez vous aux standards du web ! Il ne s’agit pas tant d’une croisade en faveur des “bonnes pratiques” de développement que d’une question de bon sens.

Utiliser le couple XHTML + CSS vous permettra de proposer des documents plus légers et d’optimiser ainsi les performances de votre site.

Abandonner les designs en tableaux, séparer la structure de l’apparence en retirant le style des balises HTML, et cesser d’utiliser des éléments dépréciés rendront votre site beaucoup plus rapide à développer et plus simple à maintenir.

Proposer un site valide, c’est 90% du travail pour rendre votre site accessible aux handicapés, notamment visuels.

Enfin, proposer un site syntaxiquement et structurellement conforme aux standards permet une indexation beaucoup plus efficace de la part des moteurs de recherche.

4. Définissez vous des objectifs précis et quantifiables.

Une des raisons pour lesquelles j’aime l’Extreme Programming vient du découpage du travail en modules les plus indépendants possibles et rapides à réaliser. Il en va de même de la refonte d’un site : il n’est pas toujours nécessaire d’attaquer tous les chantiers à la fois, au contraire.

Modifier simplement la structure, ou une partie de la structure du site, le contenu de l’une ou l’autre section, la feuille de style… permet de se fixer des objectifs à court terme, réalisables, et livrables rapidement, sans risque les dépassements de délais ou de budgets qui laissent le client avec un travail inachevé, impubliable, ou avec des zones entières inutilisables, pleines de fautes, ou vides, laissant le visiteur buter sur la néfaste bannière en construction, sooooo web 1.0.

5. Définissez vous votre protocole de travail en fonction du projet.

N’oubliez jamais ceci : quelle que soit votre expérience, aucun projet n’est parfaitement identique au précédent. Il est fondamental de vous définir un protocole de travail adapté aux exigences du moment, que vous soyez seul ou en équipe.

Bien que je m’adapte au projet en cours, j’ai toujours tenté de me conformer aux quatre éléments suivants :

  1. Utiliser un système de gestion de version (CVS ou Subversion), encore plus si vous travaillez en groupe.
  2. Diviser le travail en un maximum de modules indépendants les uns des autres.
  3. Publier une version utilisable du site ou de l’application une à deux fois par jour afin de permettre au client de le tester et éventuellement de constater les erreurs de conception avant qu’il ne soit trop tard.
  4. Une réunion au moins en début de semaine pour faire le point, et aussi souvent que nécessaire pour rectifier les erreurs de conception ou de réalisation.

6. Favorisez l’indexation par les moteurs de recherche.

La principale raison pour laquelle votre client vous a commandé un site web, c’est pour accroître sa visibilité et ainsi son chiffre d’affaire, alors ne le décevez pas ! L’ergonomie, le contenu et l’achat de mots clés ne sont pas les seuls éléments à prendre en compte afin d’accroître le trafic en provenance des moteurs de recherche.

Parmi les éléments à prendre en compte :

Respectez la sémantique structurelle dans le code HTML : utilisez les balises de header pour les titres et les balises de paragraphe pour le contenu. Évitez les tableaux imbriqués qui risquent de casser la structure de l’information, mais utilisez les de manière pertinente, par exemple pour afficher le contenu d’une feuille de calcul.

Évitez les frames, les images titres sans éléments alternatifs et les introductions en flash. Aucun d’entre eux n’est pris en compte par les outils d’indexation. Si vous affichez du contenu multimédia, assurez vous que le contenu alternatif soit pertinent et qu’une description externe vienne le compléter.

Utilisez des liens permanent pertinents. http://mabanque.com/mon-compte est bien plus compréhensible que http://mabanque.com/?rubrique=1 non ?

Enfin, utilisez des Microformats, ce sont des outils de data mining, ce serait dommage de ne pas en profiter non ?.

7. Faites des tests d’utilisabilité dès le départ.

Il parait qu’employer les stéréotypes les plus gros est parfois salutaire : un développeur n’envisage pas un site de la même manière qu’un graphiste, un entrepreneur ou un directeur commercial. Et aucun d’entre eux ne le verra de la même moyenne que le fameux “internaute moyen”.

Faites faire des tests d’utilisabilité dès le début des développements : inutile d’attendre six mois pour vous rendre compte qu’un site ou une application est tout simplement inutilisable par ceux à qui elle est destinée.

La remarque est encore plus vraie lorsqu’il s’agit de la refonte d’une application métier : autant il est possible de connaître à peu près les habitudes des gens sur un site de vente en ligne, autant les (mauvaises) habitudes et les contraintes métier sont elles difficiles à deviner.

8. Apprenez à dire non.

Note : ce conseil vaut aussi dans le cadre d’un projet démarré de zéro.

Il est parfois difficile de dire non à un client qui vient gentiment demander une nouvelle fonctionnalité, ou un “petit changement de rien du tout”, surtout si vous travaillez en régie.

Si la requête tombe sous le sens, il se peut que la conception soit à revoir. Si le client change d’avis toutes les heures, sachez être ferme, surtout face aux demandes informelles : en cas de retard de livraison, vous serez le seul fautif.

Sachez faire preuve de diplomatie : expliquez poliment que vous comprenez parfaitement la demande du client, et que vous serez ravi de la mettre en oeuvre, mais que toute évolution dans le cahier des charges doit être quotée, étudiée – il ne manquerait plus que cela casse une application qui a coûté si cher – approuvée et surtout budgetée avant de pouvoir aller de l’avant. Les clients sont généralement très sensibles à des expressions comme “dépassement de budget” ou “réévaluation”, et vous devriez pouvoir vous en tirer par une attitude bêtement procédurière qui devrait vous mettre à l’abri des retards, des régressions et des exigences les plus déraisonnable, sauf face à des champions de la mauvaise foi.

Et si vous pouvez le faire, et que ça vous amuse, acceptez une fois de temps en temps. Mais n’oubliez jamais votre objectif principal.

9. Apprenez à travailler en dépit du bon sens.

Dans le meilleur des mondes possibles, les projets informatiques seraient pilotés par des gens capables de comprendre les enjeux métiers, marketing, techniques et fonctionnels des sites qu’ils veulent faire développer. Les équipes du client et de la réalisation seraient composées d’adultes intelligents, parlant le même langage, et souhaitant avancer dans la même direction dans la joie et l’allégresse.

Dieu merci, la réalité ressemble à tout, sauf à ça, sinon on s’ennuierait ferme en réunion.

Dans le meilleur des cas, vous aurez la chance de tomber sur un client qui sait à peu près où il veut aller, mais qui a besoin de vous pour lui expliquer et l’y emmener. Il devrait donc accepter vos recommandations, propositions et idées tant que :

  1. Ça va dans le sens de ce qu’il veut faire sans avoir à le faire travailler.
  2. Ça lui coûte le moins cher possible.

Malheureusement, vous risquez aussi de tomber sur des clients souhaitant travailler en dépit du bon sens et des pratiques habituellement constatées sur le net.

On notera quelques exemples tirés de la vie réelle :

  • Le client qui souhaite remplacer sa page d’accueil par un lien avec sa photo, et un texte en rouge sur fond noir en Arial Black 32 pixels.
  • Le client exige un layout en tableaux parce que son développeur interne ne sait rien faire d’autre.
  • Le client veut afficher les 1200 produits du site sur une même page au lieu d’utiliser la magnifique arborescence que vous lui avez préparée. Encore un qui a mal compris la règle – erronée à la base – des trois clics.
  • Le client trouve votre charte graphique trop austère et souhaite remplacer toute votre navigation par des gifs animés.
  • …*
    *remplacez les pointillés par un exemple tiré de votre expérience.

Dans ce cas, tentez de négocier, mais ne dite jamais “jamais”. Le client n’est pas pervers pour le plaisir de l’être, et chacune des idées les plus saugrenues a certainement – à ses yeux – un fondement tout à fait rationnel. Alors, je craquez pas, et rappelez vous que le client se trouve toujours du bon côté du portefeuille.

10. Ne prenez pas ce billet au pied de la lettre.

Comme je vous l’ai dit plus haut, chaque projet est unique, alors sachez adapter les outils qui vous sont offerts à la situation actuelle.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: