Passer au contenu

Salauds de clients !

Votre CMS préféré est le fruit d’efforts incessants de ses développeurs en vue d’une conformité optimale aux standards du web ?Vous-même, vous passez des nuits à…

Votre CMS préféré est le fruit d’efforts incessants de ses développeurs en vue d’une conformité optimale aux standards du web ?
Vous-même, vous passez des nuits à peaufiner votre code et à ajouter encore des lignes et des lignes à cette feuille de style pour que rien ne soit laissé au hasard, que chaque image ait sa balise alternative, que chaque lien ait son titre, que cette superbe mise en page fasse fi du moindre tableau au profit d’une succession de DIV bien ordonnées ?

Arrêtez de vous casser le cul prendre la tête, il se pourrait que tout cela soit peine perdue.
Et pour cause, le jour tant attendu de la mise en production du site, et de la remise des clés au client pour qu’il puisse faire enfin vrombir tout seul comme un grand son magnifique back-end de gestion de contenu flambant neuf, il y a de grandes chances pour que tous vos efforts soient réduits à néant.
Et pour cause : dès la formation vous allez lui apprendre le B.A-BA de la mise en page, et la première chose qu’il va falloir lui indiquer sera par exemple un truc du style comment faire une présentation de texte en deux colonnes (si si, il va vous demander ça).

A partir de là vous êtes cuit : pas d’autre moyen que lui montrer comment insérer un tableau avec des bordures invisibles dans la page, puis d’imbriquer d’autres tableaux dans celui-ci… Vous m’avez compris : tout votre code propre est mis à mal par de la purée de balises, et vous ne pouvez pas faire autrement (bon courage si vous voulez apprendre la mise en page en DIV à vos clients, quand à l’application WYSIWYG visuelle de calques – en tout cas dans Joomla par exemple – ça marche pas, les différences d’affichage étant trop importantes selon les navigateurs).
Et je ne vous parle pas des images que le client posera dans ses pages sans balise ALT, et des retours charriots approximatifs et des…

Je sais, tout cela est bien technique, mais je crois que c’est la réalité : un site conforme aux standards et accessible au départ (ce qui constiture déjà une gageure, voire un défi impossible à relever en totalité) sera probablement très rapidement dégradé au fil de ses mises à jour par le client final, qui bien sûr n’est absolument pas à blâmer, chacun son métier.

Alors, la conformité aux standards côté client, vous en pensez quoi ? Bataille perdue d’avance ou défi excitant à relever ? Des solutions ?

📍 Pour ne manquer aucune actualité de Presse-citron, suivez-nous sur Google Actualités et WhatsApp.

Opera One - Navigateur web boosté à l’IA
Opera One - Navigateur web boosté à l’IA
Par : Opera
23 commentaires
23 commentaires
  1. Ce qui est bien avec moi, j’ai que j’ai directement appris à codé en DIV + CSS. Je suis incapable de faire la même page tout en tableaux…..

  2. A mon humble avis bataille perdue d’avance.
    Pourquoi ?

    Eh bien tout simplement car le client s’il il n’a pas cette sensibilité aux standard, il n’en a rien a faire de les respecter. Ce qu’il veut c’est un truc facile qui ne lui prend pas la tête et surtout rapide.
    Alors dans ce contexte je ne vois pas comment gagner cette fameuse bataille …

    enfin ce n’est que mon point de vue

  3. @Oyinko

    Moi pas, mais j’ai compris l’intérêt des standard dans la production web ce qui sera rarement le cas des clients car pour eux il va falloir "tout ré apprendre" et ils n’ont pas le temps 😉

    Effectivement la solution seraient qu’ils aient directement appris cette méthode

  4. Si ton client est sensibilisé aux questions de qualité et d’accessibilité, tu peux lui fournir des modèles, c’est ce que je fais avec les miens.
    Si il s’en fout comme de sa première chaussette, tu peux au pire le sensibiliser un poil au niveau de t formation à l’interface de édaction, mai à part ça…

  5. Sur SPIP, pas de wysiwyg, le client saisi du texte et des raccourçis typographiques pour la mise en forme. Cela nécessite un tout petit apprentissage de sa part mais le code produit est obligatoirement conforme. Après s’il veut des mises en pages plus spécifiques, on passe soit par un nouveau gabarit associé, ou bien depuis peu par des "modèles", qui sont en fait des "morceaux" de gabarits codés à l’avance et réutilisables dans le texte, ainsi le client ne peut pas faire sa soupe de tags. Concernant les images, s’il est sensible aux notions de bon référencement (ils le sont tous de plus en plus), alors le nommage se fera plus naturellement.
    En fait, il ne faut pas le convaincre d’aimer les standards, il faut le convaincre que les robots des moteurs, leurs premiers visiteurs, les adorent!

  6. De toute façon, il va sûrement ajouter des images qui pèsent des tonnes, ou alors ces maudits gifs qui clignotent et qui tournent dans tous les sens et trouvera cela très joli…

  7. Ce n’est tout simplement pas au client à s’adapter à la technique … la technique doit s’adapter à lui.

    Facile à dire, évidemment. Ce qu’il faut c’est un éditeur wysiwyg qui sors du code standard. Ou mieux, sémantique. Déjà une vraie fonctionnalité de "conversion" d’un copier/coller Word, nous aiderait énormément !
    C’est dire le chemin encore à parcourir !

  8. L’editeur wysiwyg conforme aux standards … ca a l’air beau de loin , pour du texte ok mais quand il sortira la mise en page 2 voir 3 colonnes ( fixes ou pas ) moi je suis preneur !!
    Enfin, en attendant il ne faut pas perdre de bonnes habitudes, en attendant que les autres les prennent !!

  9. Je pense que c’est aux éditeurs de logiciel à faire un effort (Microsoft par exemple) pour que les standards soient vraiment standards.

    Si le rendu était identique dans tous les navigateurs je ne pense pas qu’on aurait ce genre de discussion.

    Le laissé allé des années précédentes montre ses limites, il faut que ça change à la base pour qu’au final l’utilisateur y trouve son compte.

    Sinon pour ma part je rencontre les mêmes problèmes que toi avec mes clients et je n’ai toujours pas trouvé de vraie solution.

  10. Pour ma part j’utilise un CMS codé de mes petites mains, avec pour la gestion des pages une interface wysywyg basé sur TinyMCE (tinymce.moxiecode.com).

    L’avantage de ce wysywyg est qu’il est facilement modifiable avec quelques notions de javascript. On peut alors tout à fait enlver les options de tableau.

    Par la suite il suffit de penser une feuille de style correctement :

    – Gérer les balise h1
    – prévoir une classe de div sur deux colonnes
    – prévoir une classe de div sur 3 colonnes
    – …

    Au final, on arrive a donner une interface wysywg tres simple ou le mec n’as qu’a dessiner ses div et utiliser la feuille de style mise à disposition.

    Le code reste un peu "pourri" par les attributs style="…" (mon systeme s’appuyant sur des classes, les div dessinés ont alors des propriétés uniques comme la taille par ex), mais le code reste relativement et dans 90% des cas valide 🙂

    Pour info, la librairie Yahoo UI propose d’excellentes base pour gérer le dragndrop et ce genre de chose, il devient alors relativement aisé de gérer une interface wysywyg a base de div/css 🙂

    Pour ma part ce qui me tue le plus niveau intégration "valide" c’est se faire chier à ce que tout fonctionne sur tout les navigateurs, et tomber sur LE client qui n’a pas le navigateur a jour, et qui refuse de le mettre à jour 🙂

    Chacun ses petits tracas…

  11. Vouloir prémâcher le travail au client, c’est une bonne intention et c’est souvent demandé. Mais on sait qu’un site n’est pas malléable à souhait, en tous cas pas depuis un CMS. A un moment donné, le client souhaitera une mise en page non prévue (car non demandée dans le brief…) et là, ça peut foutre en l’air votre travail. Le client, lui, ne comprendra pas pourquoi c’est plus long à faire et comparera même ça avec une mise en page sous Word : "il suffit de faire ça… y’a qu’à mettre ça ici…" (du vécu)

    De toute façon, sauf cas rares, on sait que lorsqu’on livre un site, le code est propre, les pages sont équilibrées, les répertoires sont clairement nommés et pas trop nombreux… Mais revenez dans 6 mois et vous verrez la différence.

    C’est pour toutes ces raisons (entre autres) que je me dis aussi que les webmasters ont (heureusement) encore un bel avenir devant eux.

  12. Tout ca pour dire que faut y aller les mecs, faut miniser tant que possible l’impact du client sur le site -> Vendons de la mise à jour.

    L’analogie avec la maison est a mon avis un exemple. Tu construis une maison pour un particulier. S’il a des gouts de chiotte, il va te foutre les volets bleu fluo, il va te sortir une déco qui tient pas la route, et toi, avec tes yeux de pro, tu pleures.
    Donc au meme titre qu’il y a des pro qui assure l’amenagement/entretien/renovation d’une baraque, ce doit etre des pro qui font le contenu d’un site.

    Bref, vendez du service de mise à jour, ca rapporte et c’est votre taf…

  13. Je suis d’accord, surtout pour les "petits" client de facturer de la prestation de contenu/mise à jour.

    Cela dit certains clients (avec en général un bon budget) impose dans le cahier des charges un CMS, d’une part pour avoir un minimum de contrôle sur le site, et d’autre part pour davantage de réactivité sur les mises à jours (normal).

    PS: C’est quoi ce captcha de merde :
    quel est le deuxième caractère du mot "m5*FLes_I2Zh" ?

    haha 🙂

  14. Et si la solution était un contrat de type cadre avec le client pour lui permettre de s’affranchir de toute la gestion de contenu internet ?
    Un coup de FlySpray (entre autres) pour le suivi, une personne dédiée au webmastering de plusieurs clients et le tour est joué : plus de coup de fil intempestif genre "c’est inadmissible, j’ai enlevé tous les mots entourés par des supérieurs / inférieurs comme me l’ dit mon cousin et plus rien de marche ! c’est inadmissible !"…
    C’est un alternative que nous avons mis en place pour des gros clients comme un célèbre constructeur automobile français (non, non, pas celui-là, l’autre…)

  15. Houlaaaa je devais encore faire une crise de doigtspalmite hier soir quand j’ai écris mon premier message.

    Tout ça pour dire qu’il y’a de bonnes idées que je m’empresse de noter dans tout ce qui vient d’être dit.

    Je vais m’essayer à une petite réflexion.
    N’est-ce pas à nous, professionnels, de mettre en place des protocoles d’utilisation et ce, dés l’origine du projet.

    Nous sommes bridés actuellement par les technologies de rendu, et même si il y’a des moyens de "biaiser", à nous d’expliquer au client, ce que cela peut apporter de négatif, ensuite à lui de faire son choix.

    Si il veut pouvoir faire des mises en page "complexes", formons le. L’autonomie est un des maîtres mots actuels des demandes de projets web, à nous d’étudier si cette autonomie doit se faire au travers d’outils ou de compétences ajoutées.

    Notre métier est encore jeune et vérolé par de mauvais principes véhiculés mais également par un manque de réelle chaîne de contrôle comme on peut en trouver dans le milieu du print.

    Les "clients" à force de surfacturation pour cause de retouche et d’engueulades de la part des imprimeurs, ont fini par comprendre que faire un document correct pour l’imprimerie demande certaines compétences, ça se ressent au niveau des demandes de formations aux outils de la PAO pour comprendre les "bonnes pratiques".

    De l’autre côté, hormis celles intégrées à des projets complets, il y’a peu de demandes de formation "solo" dans la création web, les gens pensant, comme "on" leur répète depuis des années que ce n’est pas bien compliqué.

    Tant que la profession "web" ne se dotera pas de réels contrôles qualité, en attendant l’émergence de technologies vraiment efficaces, nous serons confrontés à ce genre de problèmes.

    Pour l’instant, je reste persuadé que nos meilleurs armes sont le conseil et la formation, mais pour cela il faudra dépasser le stade de la "peur du client perdu" parce qu’il ne veut en faire qu’à son idée.

    Boudiou!! C’est qui le professionnel ici? 😉

  16. je confirme l’avis de Pierrot sur Spip. Je vois clairement des différences entre nos clients Joomla et Spip. Spip ça ne bouge pas, ça reste carré, on peut structurer l’affichage plus facilement. Et frachement les clients apprenent très vite les 5 raccourcis typos dont ils ont beoins plus ceux que l’on a pu rajouter spécialement (afficher une icône "coup de coeur" par exemple).

    Avec du Joomla on se retrouve avec du n’importe quoi en quelques semaines, du code de pire en pire, des choses qui ne se tiennent plus et souvent la réparation passe par un nettoyage dans dreamweaver.

    Le mix est peut être entre les deux un peu comme l’éditeur intégré à WordPress. Un wysiwyg qui n’a que la base : gras, italique, indentation, listes… manque juste les niveaux de titres. C’est graphique sans laisser trop de libertés et dans l’ensemble ça bouge beaucoup beaucoup moins.

  17. J’attendais depuis un petit moment un billet de ce type… je comprends bien le problème. Chez nous (COM2B Networks, une agence bruxelloise de communication interactive), tous ces problèmes ont été résolus grâce à l’adoption de NECTIL, un CMS/CMF tout en flash hyper évolué qui nous fait gagner genre 50% de temps de production (sans exagérer). Tant au niveau de la conception d’un site (ou de n’importe quel autre type de média, en fait…) qu’au niveau de la formation/apprentissage du client, tout est rapide, intuitif, souple, intégré et bigrement impressionnant d’efficacité. J’arrête ici les louanges… allez voir par vous-même sur http://www.nectil.com.

  18. Le web est un média, et un medium, limité et particulier. Tous ont leur limitation… pas de mouvement ou d’animation à l’écrit par exemple. Pourquoi le web serait-il différent ?

    C’est au client de s’adapter au média. Et c’est au fournisseur (vous, nous) de le former, de lui faire comprendre ces limitations.

Laisser un commentaire

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