Accueil / Articles / HTML / CSS / N’est pas webmaster qui veut !

N’est pas webmaster qui veut !

Une fois n’est pas coutume, un petit article pour pousser une gueulante contre une « webmaster » dont l’incompétence force le respect.

Il y a quelques semaines, une future cliente me contacte par mail en m’expliquant ses problèmes et me demandant ce que je peux faire pour l’aider.

En gros, elle était en train de mettre en place une boutique PrestaShop et avait fait pour celà appel à une webmaster. Parmi les demandes de la cliente, il y avait la volonté d’utiliser un thème particulier (payant à 120 €), mais qui n’existait qu’en version 1.3 (la boutique étant en version 1.4).
La webmaster lui avait dit qu’elle recréerait ce thème en version 1.4 en partant d’un autre thème.
Mais au bout de 2 mois au lieu d’1 semaine initialement prévue, le site n’était toujours pas fini.

La cliente voulait donc savoir comment s’en sortir pour ouvrir le site au plus tôt.
Je lui ai répondu à l’époque que vu le tarif du thème en version 1.3 et le coût horaire (le mien en l’occurence), il était plus intéressant d’acheter le thème 1.3 et de l’adapter en 1.4, ce qui ne nécessitait pas de changements trop profonds, plutôt que de s’obstiner à créer le thème en partant presque de zéro. Voyant quelques erreurs basiques dans le code HTML du thème, j’ai tout de même donné des pistes à ma cliente pour qu’elle les donne à sa webmaster.

Quelques semaines ont passé, puis j’ai été recontacté pour fignoler un peu le site, et m’occuper des premières actions de référencement.

Et là, j’ai vu l’étendue des dégâts ! La webmaster devait à l’origine s’occuper de tout : création du thème, référencement.

Quelques minutes d’examen du site m’ont pourtant permis de relever plusieurs points noirs.
Beaucoup d’erreurs de code HTML, qui rendaient les pages non valides W3C. Ces erreurs étaient entre autres :
– des balises <br> non auto-fermées, ce qui est la base du XHTML
– des balises <img> non auto-fermées et sans alt
– des boutons alignés à droite de l’écran en insérant 111 espaces &nbsp; devant !!!
– …

Réponse de la webmaster au sujet des erreurs de validation : « c’est pas important ! ». Bah tiens…

La fiche produit présente, à coté de la photo de l’article, deux colonnes de couleurs différentes. Mais toute cette zone a été conçue avec une seule et même div. Les zones dans la colonne de droite sont positionnées à grands coups de margin dans tous les sens. Mais par exemple, si la description courte du produit (dans la colonne de gauche) s’allonge, ça décale d’autant en hauteur tous les éléments dans la colonne de droite.
A la demande de la cliente, j’ai voulu depuis changer la police de caractères du site ! Grave erreur, ça fout toute la mise en forme en l’air.
Pour réparer tout celà, il va me falloir reprendre sur le fond la structure même du site.

Le désir de la cliente d’avoir une petit flèche à coté des items dans le menu (module JBX Menu) a été la cause d’une autre connerie sans nom : la webmaster a directement modifié le fichier cache généré par ce module. Evidemment, quand on modifie la configuration du menu via l’administration, le cache est regénéré… et les modifications apportées manuellement perdues !!!

Autre connerie grotesque de la « webmaster » montrant qu’elle ne connait pas PrestaShop, sur lequel elle travaille pourtant : dans la colonne de droite se trouvaient 3 blocs (« informations », « newsletter » et « réseaux sociaux »). Ces 3 modules n’avaient pas été installés ou greffés dans cet ordre. Comment faire donc pour obtenir ce qu’on désire ? On va dans le backoffice PrestaShop, et on joue avec la position des modules par simple drag & drop. Et bien non, cette tâche a encore utilisé des margin-top dans tous les sens pour positionner tel module plus haut que tel autre !!!

Concernant le référencement, ce qu’elle était sensée avoir fait pour le site était aussi dramatique : dans les meta descriptions des produits, des phrases très génériques concernant la boutique (et non le produit).
Le site devant également être en anglais, il devait suffire de cliquer sur un bouton dans PrestaShop pour avoir le site en anglais. Harry Potter, sors de ce corps !

Parmi les autres faits marquants :
– l’absence de fichier robots.txt à la racine (là pourtant, il n’y a qu’un clic à faire pour le générer)
– l’absence de sitemap.xml à soumettre à Google (le B-A-BA !)
– pas de redirection du nom de domaine sans le www vers le site avec le www (merci le duplicate content).

Cette « webmaster » a pignon sur rue. Elle sévit depuis au moins 2004, et a probablement pourri un certain nombre de sites de ses clients. Son propre site (« son site à elle » est plus approprié) étant lui-même truffé des mêmes erreurs, j’en déduis donc que ce n’est pas intentionnellement qu’elle ne fait pas son travail correctement, mais que c’est juste de profondes lacunes des technologies du web qui font d’elles une incompétente notable, à défaut de notoire.

Voir aussi

PrestaShop version 1.7

La dernière version majeure de PrestaShop est sortie le 7 novembre 2016. La grande nouveauté …

4 commentaires

  1. Salut,

    Souvent je tombe sur des gens étant intervenu pour faire un design personnalisé sur Prestashop mais qui ne connaissent ni Prestashop, ni Smarty, ce qui provoque des erreurs importante et difficiles à corriger sans tout reprendre.

    Comme les traduction inscrite en dur car ils ne savent utiliser les traduction de Prestashop. L’utilisation de modification de code importantes en retirant des id bloquant alors les javascipt ou encore des intégrations de codes identiques sur plusieurs pages car ils ne savent pas faire un module.

    Il y a des centaines d’intervenant sur la solution Prestashop car abordable au premier abord mais elle demande tout de même de savoir s’en servir au quotidien pour en comprendre le réel fonctionnement. C’est bien dommage car après il est difficile de prendre des projets mal fait. Et surtout les gens en sont pas près à remettre de l’argent sur la tale après le vol caractéristique de certains « webmaster »

  2. Je n’ai jamais dit que c’était important pour le visiteur ! mais le jour où Google n’indexera pas ton site parce que la présence d’erreurs bloquantes fera que le code ne sera pas parsé jusqu’au bout, tu te diras « bah tiens, si le code avait été valide, je n’aurais pas eu ce problème ». D’une manière générale, la validité du code (X)HTML est le seul moyen d’être sûr que le site sera compris par tout le monde (visiteurs, moteurs de recherches, robots en tout genre).
    Maintenant je le répète, pour l’affichage ce n’est pas forcément primordial. Un peu comme le fait que j’ai pu comprendre ton message correctement malgré les 13 fautes 😉

  3. Bonjour,
    Je suis tomber sur ton site par hasard et je tenait a dire 2-3 choses
    Je suis une formation d’ informatique plutôt général et franchement les designer qui se prennent pour Michel-Ange parce que leur code ne comporte pas d’erreur, ça me fait bien rire : le jour ou tu verra un internaute vérifier si ton code source est valide avant d’acheter ton produit …
    Cependant je suis d’accord avec le faite que beaucoup de personnes pense qu’il suffi de lire le site du 0 pour pouvoir se dire designer et au final font des truc ni fait ni a faire.

  4. Bravo pour cette belle analyse
    mais je pense aux centaines d’autres dans ce même cas…
    car ce n’est pas un cas isolé…

    bonne journée

    Dominique

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *