L'optimisation pour le SEO.

Le protocole HTTP.

Une feuille de styles CSS.

Le format PDF.

Le format GIF.

Le format TIFF.

Le référentiel RGAA.

Je n'aime pas beaucoup me répéter. Alors à chaque fois que j'emploie une des expressions ci-dessus, je grince un peu des dents. (Et c'est pire en anglais.)

Je crois que les discussions ont commencé suite à cet excellent article de Brad Frost en janvier dernier sur "L'ère post-PSD" :

Tout au long de ma carrière, j'ai vu des graphistes immensément talentueux perdre une montagne de temps à créer des maquettes complètes de ce à quoi un site web pouvait ressembler. On pousse des pixels, on sue sur des détails, les pages sont imprimées, accrochées sur des murs, et présentées à des clients. Les clients braillent leurs retours, les graphistes exécutent. Ils répètent cette danse jusqu'à ce que tout le monde soit content (ou jusqu'à ce que personne n'en ait plus rien à faire, ce qui arrive plus souvent que vous ne le croiriez). Et seulement à ce moment ces sacro-saintes maquettes sont transmises (ou plutôt balancées) aux développeurs pour les construire.

C'est un processus de plus en plus pathétique qui a de moins en moins de sens dans ce monde et cette époque multi-appareils. Je ne plaide pas pour abandonner complètement Photoshop et faire du design uniquement dans le navigateur (ils sont où déjà les modes de fusion dans les outils de développement de Chrome ?) mais plutôt pour une meilleure compréhension de comment utiliser Photoshop pour du web design moderne.

Je pense que "pathétique" est le bon mot. On vient de passer les vingt dernières années à tenter de faire du print sur le web. Il est temps que ça change.

Afin de palier aux faiblesses techniques de Photoshop, certains prêchent l'utilisation d'autres logiciels, comme Sketch par exemple. C'est déjà un bon premier pas pour s'éloigner du Bitmap de Photoshop vers du vectoriel, plus proche de la nature du web. Mais à chaque fois, la réaction d'une partie de la petite communauté de Directeurs Artistiques sur Twitter est la même : "Comment osez-vous nous imposer un logiciel pour faire du design ? Nous on ne vient pas vous dire dans quel logiciel travailler." C'est touchant, mais c'est pourtant exactement ce qui se passe.

En travaillant sous Photoshop, vous imposez à toute votre chaîne de production d'en faire autant. Parce que le format PSD est une véritable abomination, Adobe s'assure à chaque mise à jour qu'il reste inutilisable de manière fiable sous tout autre logiciel (coucou les dossiers de calques qui sautent dans Pixelmator ou Gimp). Photoshop est aussi un outil particulièrement atroce à utiliser pour de l'intégration. Certains plugins comme CSS Hat ou Slicy (anciennement Layer Cake) tentent de rendre la tâche moins pénible, on est encore loin d'un véritable outil pensé pour de l'intégration. Et même si des logiciels comme Sketch améliorent cette situation, je ne suis pas sûr que remplacer Photoshop par un autre logiciel propriétaire ne soit la solution.

J'aime bien la vision de Ryan Singer abordée lors d'une séance Play by Play sur le prototypage d'interface : "Photoshop est juste un outil — de la même manière qu'un croquis — pour retirer le doute sur une idée."

Que ce soit pour de l'intégration ou du design, j'utilise Photoshop ou Pixelmator comme si j'étais dans une épreuve de Fort Boyard : une fois rentré, mon but est d'en sortir le plus rapidement possible avec la réponse à ce que je suis venu chercher.

Il y a quelques années on faisait des sites complets en Flash. Aujourd'hui on maquette encore des sites complets sous Photoshop. Il est temps que ça change. Comme dans le cas des pré-processeurs, je pense que le problème n'est pas l'outil qu'on utilise, mais ce qu'on en fait. L'après Photoshop n'arrivera qu'une fois qu'on se sera débarrassé de cette vision print du web.

Ceci est ce que Magritte appelle "la trahison des images". Ceci n'est pas un poisson. C'est une image d'un poisson. C'est une représentation visuelle d'un poisson. Si j'avais dessiné ça sur papier, ce serait une plutôt bonne représentation d'un poisson. Si vous ouvriez un livre que vous tombiez sur ce dessin, vous vous diriez "oui, il y a une image d'un poisson dans mon livre". Ça capture toute la "poissonitude" que l'on peut capturer à travers un media papier. Mais ceci n'est pas du papier, c'est un nouveau média. Et dans ce média, c'est une très mauvaise représentation d'un poisson. Ça ne ressemble pas du tout à un poisson.

Les poissons sont tout le temps en train de bouger. Si vous regardez un poisson, il fera surement des aller-retour, il bougera son corps d'avant en arrière, remuant sa queue. Les poissons sont tout le temps en mouvement. Dans un média où nous nous attendons à voir du mouvement là où il y a du mouvement, ceci ne ressemble pas du tout à un poisson vivant. C'est une bonne image pour un poisson mort. Et si vous voulez dessiner un poisson mort, Photoshop est un super outil. Tout ce que vous allez dessiner dans Photoshop sera complètement mort, totalement statique, pas du tout en mouvement.

Mais je ne veux pas dessiner un poisson mort, je veux dessiner un poisson vivant.

Le parallèle avec le web n'est pas trop difficile à faire. Et c'est ainsi qu'il commence à animer son poisson sur son interface faite-maison avec deux iPad reliés en Bluetooth. Les différents concepts d'interface qu'il présente font vraiment toujours autant envie. Surtout, il argumente avec précision pourquoi, d'après lui, taper du code n'est pas adapté pour faire de l'animation.

La deuxième raison pour laquelle je pense que coder est inapproprié pour créer des arts graphiques vient de la relation entre un langage et la compréhension visuelle. Du code, c'est du langage. Nous codons dans des langages de programmation. Nous pensons de manière linguistique lorsque nous codons.

Dans une large mesure, la seule raison pour laquelle des artistes créent des arts graphiques est pour exprimer quelque chose qu'ils ne peuvent pas exprimer avec un langage. Les artistes dessinent parce qu'ils veulent transmettre quelque chose qu'ils ne peuvent pas décrire. Les mots "nuit étoilée" ne décrivent pas "La nuit étoilée".

Si je suis un fervent défenseur de la conception web la plus proche possible d'un navigateur, je suis tout à fait d'accord que du code n'est pas le bon outil pour de la création graphique. Nous sommes dans un état d'esprit différent lorsque nous codons et lorsque nous sommes devant une toile vide sous Photoshop.

Sa conclusion est précise et ambitieuse :

La principale chose que je veux que vous retiriez de cette conférence, c'est de l'insatisfaction.

Je veux que vous rentriez chez vous, que vous ouvriez Photoshop et que vous ressentiez que vous dessinez des poissons morts. Je veux que vous ressentiez à quel point tout ce que vous dessinez est plat, statique et sans vie. Quand vous créez des animations, je veux que vous ressentiez à quel point c'est froid et mort, comment vous ne pouvez pas jouer avec. Je veux que vous ressentiez tout ce qui nous manque, en utilisant ce média pour simuler d'autres médias. En définitive, je veux que vous ayez des standards plus élevés pour ce média.

Je ne peux qu'acquiescer.

Le problème, c'est que j'y connais rien en automobile. J'écoutais attentivement les conseils de mon entourage, mais chacun y allait de sa propre expérience se contre-disant les unes des autres. "Avec les kilomètres que tu vas faire, il te faut un diesel !" "Prends plutôt une essence, c'est moins cher et de toute façon le carburant est quasiment au même prix." "Achète français, ça coûte moins cher à l'entretien." "Achète japonais, ils font les meilleurs moteurs et ça demande moins d'entretien."

Je n'avais pas la moindre idée de ce qui pouvait être important d'avoir dans une voiture, mais j'avais quelques contraintes. Je souhaitais un véhicule pour une utilisation occasionnelle, environ une fois par semaine. Je n'avais pas de budget précis en tête, mais je souhaitais pouvoir payer cash, sans faire de prêt. J'en avais aussi besoin assez rapidement, mais je n'avais pas beaucoup de temps à y consacrer. Et surtout, je devais pouvoir me rendre facilement seul chez le concessionnaire de la voiture de mes rêves. C'est bête, mais quand on n'a pas de voiture, c'est tout de suite très compliqué de se rendre chez des concessionnaires placés à l'extérieur des agglomérations.

Alors j'ai acheté ce petit bolide.

Oui, une Twingo. Je peux désormais me vanter d'avoir une voiture de ministre.

Au début, tout allait bien. Ma Twingo et moi vivions un amour fou. Elle me convenait très bien pour une utilisation hebdomadaire. Et puis petit à petit, j'ai commencé à l'utiliser un peu plus, et à prendre le train moins souvent. Et puis la SNCF a enchaîné les retards, grèves et autres perturbations, et j'en ai eu marre. Et j'ai fini par prendre la route tous les jours, et ne plus jamais prendre le train.

Et là, forcément, la Twingo n'est pas forcément la voiture idéale pour avaler 100 Km d'autoroute par jour. Alors je recherche actuellement une nouvelle voiture. Une voiture plus confortable, dans laquelle je serais prêt à passer deux heures par jour. Et puis bien équipée, où je pourrais facilement relier mon téléphone pour y écouter ma musique, des podcasts, etc. Si j'ai toujours des tas de questions qui me trottent à l'esprit, l'expérience de mon premier achat me permet d'aborder ce deuxième achat beaucoup plus sereinement.

Si je vous parle de tout ça, c'est parce que cette expérience de premier achat a fait écho à celle que peuvent avoir des clients en recherche d'un tout premier site web. Si j'essaie de guider mes prospects en leur expliquant les avantages et inconvénients de telle ou telle solution, j'ai forcément un point de vue biaisé sur la question. Alors si vous êtes entrepreneur, que vous avez besoin d'un site pour votre société, que vous n'y connaissez rien au web, quels seront vos critères d'achat ? Le prix ? Le ressenti des premiers rendez-vous ? La taille de l'agence web ? Le langage serveur ou le CMS utilisé ? Comment faire le tri entre les conseils de vos amis et ceux des différentes agences que vous avez pu rencontrer ?

Je n'ai pas de réponse universelle, mais en me basant sur ma propre expérience d'achat d'un premier véhicule, je conseille aujourd'hui souvent de ne pas dépenser tout son budget. Si vous n'y connaissez rien au web, il y a de fortes chances pour que les besoins que vous imaginez aujourd'hui soient très différents des besoins que vous aurez dans un an, après avoir eu déjà un peu d'expérience dans la mise à jour de votre site.

J'utilise un truc avec mes collègues quand on essaye de décider où manger le midi et quand personne n'a d'idée. Je suggère d'aller au McDonald's.

Quelque chose d'intéressant se produit alors. Tout le monde tombe d'accord sur le fait qu'on ne peut pas aller au McDonald's, et de meilleures suggestions de déjeuners émergent. Magie !

C'est comme si nous avions brisé la glace avec la pire idée possible, et maintenant que la discussion a commencé, les gens deviennent soudainement créatifs. J'appelle ça la théorie du McDonald's : les gens sont inspirés à trouver de bonnes idées pour écarter les mauvaises.

C'est une technique que j'utilise beaucoup au travail. Les projets démarrent de différentes façons. Parfois on vous donne un brief formel. Parfois vous entendez une rumeur de quelque chose qui pourrait arriver et vous commencez à y réfléchir à l'avance. D'autres fois vous avez muri une idée pendant des mois ou des années avant de la partager avec votre équipe. Il n'y a aucun processus défini pour du travail créatif, mais j'en viens à croire que tous les comportements créatifs partagent une chose : le deuxième pas est plus facile que le premier. Toujours.

C'est tout ce que j'aime.

2) Ne me demandez pas de connaître XHTML/HTML4.1/HTML5

Les balises sont définies en HTML. A moins que vous n'ayez besoin d'un balisage pouvant être parsé en XML pour une raison ou une autre, me demande de connaître XHTML revient à dire : "je spamme de mots-clés pour être sûr de dégoter la bonne personne".

Une meilleure façon de le dire serait : "Nous nous attendons à ce que vous connaissiez HTML, à utiliser ses balises de manière efficace, et d'avoir une bonne compréhension de la sémantique derrière chaque balise".

Protip : ne laissez personne vous dire qu'il connaît HTML5 si tout ce qu'il sait se limite à l'utilisation du doctype.

Il y a quelques jours, j'ai aussi vu passé ce tweet de Benoît Meunier citant une interview de Judy Ramey (elle même citant Danny Hillis) :

Les choses qu'on appelle « technologies » sont les choses qui ne fonctionnent pas encore. Personne ne parle de la technologie d'interrupteurs d'éclairage.

Si j'évite au maximum de parler de "HTML5" ou de "CSS3" avec mes clients, je plaide coupable d'une utilisation parfois abusive de certains termes un peu fourre-tout. Par contre, je me rends compte que plus le temps passe, moins j'utilise ces termes pour désigner les choses "qui fonctionnent".

Box-shadow ? C'est du CSS. Les animations et transitions ? Du CSS. Les filtres et shaders ? Du CSS3 !

C'est très subjectif. Mais j'ai l'impression que dans le langage courant, HTML et CSS désignent tout ce qui fonctionne, alors que HTML5 et CSS3 désignent ce qui ne fonctionne pas encore.

<!--[if IE 10]><html class="ie10"><![endif]-->
<!--[if IE 9]><html class="ie9"><![endif]-->
<!--[if IE 8]><html class="ie8"><![endif]-->
<!--[if IE 7]><html class="ie7"><![endif]-->
<!--[if !IE]>--><html><!--<![endif]-->

-webkit-border-radius:5px;
-moz-border-radius:5px;
-o-border-radius:5px;
-ms-border-radius:5px;
border-radius:5px;

Bon, à part le côté répétitif lourdingue, vous ne voyez pas ?

Ils contiennent tous les deux une licorne, une créature légendaire, inspirée du mélange d'autres créatures, elles, bien vivantes.

Dans le premier exemple, la ligne <!--[if IE 10]><html class="ie10"><![endif]--> n'a jamais existé. Microsoft a abandonné le support des commentaires conditionnels dans Internet Explorer 10, et ce dès la deuxième Platform Preview.

Dans le deuxième exemple, les lignes -o-border-radius:5px; et -ms-border-radius:5px; n'ont elles non plus jamais existé. Microsoft et Opera ont tous les deux supporté la propriété sans préfixe.

Pourtant, je tire ces exemples de code légendaire de sites récents, codés par de vrais intégrateurs, dans la vraie vie. Le premier exemple est un bon rappel que dans le métier d'intégrateur, la veille fait partie intégrante de notre travail. Et le deuxième exemple est un bon rappel qu'il n'y a jamais de bonne pratique universelle (et, non, désolé, ajouter tous les préfixes possibles pour toutes les propriétés ça n'a jamais vraiment été une bonne idée).

Le mois dernier, Marie Guillaumet a écrit un excellent article chez Les Intégristes intitulé L'intégration web, cette leçon d'humilité. (Si vous ne l'avez pas encore lu, vraiment, allez-y.) Ce paragraphe a particulièrement retenu mon attention :

Le problème, ces dernières années, c’est que tout ce qui se dit sur la Toile à propos des méthodes de développement front-end est relayé sur Twitter et a tendance à être pris pour argent comptant. À chaque jour son nouveau messie. Pour peu que le messie en question ait beaucoup de followers, peu de voix s’élèveront alors pour remettre sa parole divine en question : « Si lui, si elle le dit, c’est qu’ils doivent avoir raison ! ».

Le mois dernier également, Christophe Andrieu a publié une réponse, elle aussi pleine de bon sens (même si je ne suis pas d'accord avec tout), à mon article sur la cible, intitulée Intégrateur dans la vraie vie. Là encore, un commentaire de Kaelig a résonné en moi :

Pour avoir été à la conférence “Responsive Day Out” il y a un mois à Brighton, où les Jeremy Keith et autres gourous du web “bien fait et responsive” parlaient de leur expérience, j’avoue qu’à la fin de la journée je commençais à en avoir assez des beaux discours qui se rapportaient à dire “si votre contenu n’est pas accessible sous Lynx, allez vous faire en…er, vous êtes juste mauvais”.

N’oubliez jamais que ces gens sont ceux qui crient le plus fort dans une foule de développeurs, pas forcément ceux qui sont les plus pertinents. D’ailleurs nombre d’entre eux n’ont jamais participé à des projets d’envergure, ou encore cachent qu’ils acceptent aussi des boulots alimentaires afin de ne pas écorner leur image d’experts.

Je ne peux pas m'empêcher de me sentir visé quand on parle de "beaucoup de followers" ou de "ceux qui crient le plus fort".

J'ai actuellement 5469 followers sur Twitter. Ce chiffre me fait bouillir la cervelle quand j'y pense. Bien sûr, ce n'est rien à côté des trente-six millions de followers de la directrice de création de Polaroid. Mais pour un compte personnel d'intégrateur, où je parle quasiment exclusivement d'intégration, parti de zéro il y a tout juste trois ans, ça me laisse abasourdi.

Du coup, ça donne de l'écho à tout ce que je dis. Le moindre de mes articles fera plusieurs centaines voire plusieurs milliers de vues, même le plus débile (2807 vues depuis sa parution). Et puis j'ai des avis tranchés. J'écris sur des sujets qui me passionnent, des sujets qui me prennent aux tripes, des sujets qui me font réagir de manière viscérale.

En combinant les deux paragraphes précédents, je comprends que je puisse passer pour un "ayatollah" (ou pour Abraham Simpson).

Hier, je suis tombé sur cet article, "There is No Right Way to Develop Software", dénonçant les gourous prétendant que leur façon de travailler est la seule et unique façon véritable de travailler. Et puis une recherche sur l'avant-dernière phrase de cet article, "Strong opinions, weakly held" m'a mené à ce fantastique article du même nom de Jeff Atwood en 2008. Il répond à certaines critiques vis-à-vis de son blog et de sa supposée autorité. Il commence par reprendre deux slides d'introduction d'une conférence.

Qu'est-ce que j'ai fait ?

Je n'ai pas de société.
Je n'ai pas participé au lancement d'une startup importante.
Je n'ai pas créé un framework ou un standard.
Je n'ai pas gagné beaucoup d'argent.

RIEN.

Il n'y absolument aucune raison pour laquelle vous devriez m'écouter.

Mais d'une manière ou d'une autre, j'ai 75 000 abonnés à mon flux RSS et plus de 50 000 pages vues par jour.

C'est un mystère pour moi, également.

Puis il enchaine :

L'autorité dans notre domaine est une chose étrange. L'autorité perçue l'est encore plus.

Je me suis toujours vu comme rien de plus qu'un amateur débutant à la recherche d'illuminations. Ce blog est ma tentative d'inviter d'autres personnes à faire ce voyage. C'est devenu un voyage assez populaire au passage, ce qui a subtilement altéré la nature du voyage et ma façon de l'aborder, mais le but reste le même.

Ça me trouble considérablement d'entendre que des gens me voient comme un expert ou une autorité, et non pas un camarade amateur.

Je n'aurais pas pu mieux décrire mon ressenti.

Tout ceci m'amène au titre de cet article, et à un autre excellent article lu le mois dernier, intitulé "Your Dogma is Bullshit".

Chacune de nos perspectives se développe au cours du temps à travers les expériences de nos propres vies. La probabilité pour que les expériences d'une personne correspondent à celles d'une autre personne est quasiment nulle. Donc quelles garanties vous avez quand je dis "vous ne devriez pas utiliser Bootstrap" que j'y regarde de votre perspective ? Aucune, non ?

Même si je faisais de mon mieux pour voir de votre point de vue, le fait que nous ayons tous les deux suivis des chemins très différents — même si nous sommes arrivés au même point — signifie que je ne serais jamais capable de me mettre à votre place et de voir les choses comme vous les voyez. Sans comprendre le contexte, il n'y a aucun moyen pour moi d'avoir une telle prétention, peu importe à quel point j'essaye.

Donc si je ne peux pas prétendre savoir ce qu'il y a de mieux pour vous — et vous pour moi — comment savez-vous que ce que je raconte en ce moment même ce n'est pas de la foutaise également ? Je veux dire, j'ai commencé par une déclaration très large, comment savez-vous que j'ai raison ? Malheureusement vous ne pouvez pas le savoir. Et ce simple fait approuve ma déclaration — ou l'inverse, c'est à vous de décider. La totalité de cet article est un débat digne de l'oeuf ou la poule. Il n'y a aucun moyen pour qui que ce soit de prétendre qu'il est ou pas correct si ce n'est pour soi-même. Et c'est ça qui est génial !

Maintenant que vous remettez en cause mon dogme (et aussi peut-être ma santé mentale), vous commencerez à remettre en question les dogmes de tout le monde également, y compris les vôtres. Donc quand vous croyez que quelque chose est le meilleur — ou le pire — vous vous demandez, "comparé à quoi ?". Comparé à vos propres expériences ? Aux miennes ? Et pourquoi pas comparé aux expériences de la prochaine personne que vous allez croiser ? Ou de la dernière personne que vous avez croisé ? Il n'y a aucun moyen de savoir, donc il n'y a aucun moyen de définir absolument ce qui est le meilleur, le pire, ou n'importe quoi entre les deux.

Est-ce que vous devez arrêter de faire des ombres portées dans tous vos designs ? Est-ce que vous devez arrêter d'utiliser Photoshop pour faire du web ? Est-ce que vous devez bannir tout texte en haut de casse ?

Peu importe. Ça dépend. Du projet, du contexte, de votre personnalité. Ces questions n'attendent pas une Vérité en réponse. Et ceux qui les posent n'ont probablement pas la prétention de la détenir.

La froideur du support numérique, et la nature souvent passionnée de nos métiers, fait qu'on est amené à réagir de manière viscérale. Mais ne vous trompez pas : si vous dénoncez ce que vous percevez comme un dogme par des conclusions tirées de vos propres expériences, vous serez à votre tour perçu comme un ayatollah.

Il y a deux ans, lors de l'affaire DSK, je me souviens avoir entendu un journaliste faire la déclaration suivante :

Dans un procés, il y a toujours trois parties : l'accusation, la défense, et la Vérité.

Je suis heureux d'avoir un blog personnel où je peux m'exprimer librement. Je ne prétends pas énoncer la Vérité. Mais juste à défendre les points de vues nés de mes propres expériences. Certains ressentiront ça comme des accusations. Je ne m'attends pas à faire l'unanimité. Mais si d'autres trouvent dans mes propos un écho à certaines de leurs expériences, et que ça leur permet d'avancer, alors je suis flatté d'y participer.

Les matériaux du web se rangent bien en trois catégories.

1. La base : HTTP, URL et HTML
2. Le style : CSS
3. La décoration : "raster graphics" (du graphisme à base de pixels)

Ce n'est pas la première fois que je parle de matériau du web, mais je pense que cette notion est particulièrement importante. J'avais bien aimé la conférence de John Gruber, Apple and the Open Web, qui décrivait les fondamentaux du web comme "les deux HT : HTTP et HTML". Mais la description me semble plus complète et bien répartie.

Il continue ensuite en décrivant chacun de ces matériaux et ce qu'il considère comme une utilisation honnête. Il est parfois un chouilla extrémiste sur certains sujets (tu sais que c'est extrémiste quand même moi je dis que c'est extrémiste), comme lorsqu'il dit "qu'un effet de lumière comme une ombre portée est malhonnête [...] car il n'y a pas de source de lumière dans un écran numérique qui induit cet effet". Mais il utilise l'exemple d'une brosse à chiotte pour compenser (tu sais que c'est un bon article quand on cite en exemple de design une brosse à chiotte). J'ai particulièrement retenu ce passage sur "la base" (où il cite un autre excellent article de septembre dernier chez A List Apart) :

L'article de Paul Robert Lloyd, The Web Aesthetic, pose la base.

Le web pourrait presque être considéré comme un matériau composite, constitué de HTTP (le "comment"), des URL (le "où"), et de HTML (le "quoi"). Omettez n'importe lequel de ces ingrédients et vous n'êtes plus en train de faire du web.

Faites ce que vous voulez par dessus, mais si ces protocoles n'existent pas, ce n'est pas du web. Ce n'est pas honnête.

Par exemple, un site en Flash qui n'a pas ces matériaux fondamentaux ne se chargera pas sur de nombreux appareils populaires. Puisque des URL honnêtes pour chaque page n'existent pas en Flash, ce sont vraiment des pages malhonnêtes qui sont difficiles à lier, pas partageables de manière prévisible, et difficiles à naviguer à cause du bouton précédent du navigateur qui peut produire des résultats inattendus. Certains robots de recherche peuvent indexer du contenu en Flash, mais comme ce n'est pas livré avec du HTML honnête, des tas de problèmes de SEO, d'accessibilité et de maintenance font surface. Ce n'est pas un secret que des interactions pauvrement prévues peuvent être malhonnêtes pour exactement les mêmes raisons.

Le concept important décrit ici, c'est de construire son site "par dessus" cette couche de matériau. L'inverse, ce serait de concevoir son site indépendamment de ces matériaux, par exemple dans Photoshop, et de construire son site par dessus cette couche fictive.

Et tout cela m'amène à vous inviter à lire un autre excellent article, publié il y a plus d'un an par Nicolas Hoffmann, qui parle Du web au naturel, du web « bio » :

Il est une chose dont j'ai l'intime conviction en matière de développement et d'intégration web, c'est qu'il faut rester le plus proche possible du fonctionnement naturel des divers éléments ainsi que de la simplicité.

J'ai la même conviction, que ce soit du chargement d'une page à des faux contrôles de formulaires. Concevoir un site autour de son design, chercher à tout prix à avoir le contrôle de son design sur le web, ce n'est pas faire preuve d'intelligence. C'est montrer qu'on n'a rien compris au web.

Le web est une plate-forme stupide, dans le sens où vous pouvez faire tout et n'importe quoi. Essayez de faire une application de 3 Go sur iOS, et Apple vous remettra dans "le droit chemin". Essayez de faire une page web de 65 Mo, et personne ne viendra vous en empêcher. Encore une fois, la maxime "Juste parce que vous pouvez le faire ne signifie pas que vous devez le faire" est à garder à l'esprit. En particulier à l'approche de ce que j'appelle le troisième âge du web.

Puis ce week-end, j'ai lu le guide sur l'intégration d'email marketing chez Mailchimp. Je suis resté scotché devant ce paragraphe (page 35 dans la version PDF) :

Si possible, testez vos e-mails lors de leur envoi avec différents FAI. Différents serveurs d'e-mails altérerons votre message avant qu'il n'arrive dans la boîte de réception de votre destinataire. Par exemple, certains FAI utilisent des serveurs d'e-mails qui retireront tout contenu sous une ligne dans votre e-mail qui commence par un point (on sait, c'est bizarre). Nous avons été surpris de voir à quel point un e-mail pouvait avoir un rendu différent sous Outlook 2003, mais reçu via Comcast, Bellsouth et Earthlink.

"Pfiou", me suis-je dit. J'ai bien de la chance de ne jamais avoir rencontré ce genre de problème.

Et puis c'est arrivé. Hier. Un e-mail, tout ce qu'il y a de plus classique, intégré par mes soins, livré dans les temps. Et une heure plus tard, un mail de retour du client. "Mon collègue a un rendu bizarre sur son téléphone", avec une capture d'écran de l'application Mail sous iOS, et effectivement un rendu étrange. Différentes images, censées être sur fond blanc avec du texte dessus, ont une couleur de fond différente.

"Impossible", me suis-je dit. Je revérifie tout de mon côté. Mes tranches, mes images, mon code. Rien. Je regarde la capture d'écran qui prouve pourtant bien l'existence d'un problème. Et puis je m'arrête sur la barre de statut d'iOS, qui indique fièrement : "Orange 3G".

"Non", me suis-je dit. Ça ne peut quand même pas être ça. Je teste alors sur mon iPhone, chez SFR, en 3G. Rien. J'envoie l'e-mail à tous mes collègues afin de tester sur différents appareils et différentes connexions. Et là, ça y est, miracle, le bug est apparu. Et effectivement, sur une connexion Orange, en 3G, les images sont dégradées.

J'ai donc fait ce que toute personne saine d'esprit ferait dans ce cas là : un tableau avec pleins d'images de différentes tonalités de gris dans différents formats (JPG à 100%, GIF, PNG 8 bits, et un simple background HTML comme témoin). J'ai testé, via la connexion partagée de mon collègue depuis son iPhone sur mon Macbook ou sur mon iPhone.

Et le résultat est sans appel.

Les trois formats d'images sont recompressés. Mais le GIF est recompressé de manière absolument horrible, à tel point que ça saute aux yeux. Même le blanc n'est plus blanc.

J'ai fait différents tests sur des images GIF, dans différents modes d'enregistrement, avec une palette de couleurs plus ou moins élevée, pour essayer de comprendre ce qui déclenchait cette recompression. Et je n'ai pas la réponse.

D'après mes tests, ça ne dépend pas :

• De la dimension des images. Certaines images plus grandes que d'autres n'ont pas eu d'effet visible lors de la recompression par Orange.
• Du poids des images. Certaines images de 3 Ko ont été sauvagement recompressées alors que pas d'autres de 8 Ko.
• De la palette de couleurs. Certaines images forcées à une palette de 16 couleurs sont encore recompressées de manière visibles. D'autres avec 32 couleurs, pas.

Je pense que le principal coupable est donc l'outil de compression GIF utilisé par Orange, et qu'il n'y a pas malheureusement pas grand chose à faire pour éviter ça. Le problème semble connu puisqu'il avait déjà été remonté dans un article de 2011.

Une solution consisterait alors à utiliser le format PNG (8 ou 24 bits) plutôt que du GIF. Sauf que malheureusement d'anciens logiciels mails, comme Lotus Notes 6 et 7, ne supportent pas du tout le format PNG et affichent des images cassées à la place.

Je n'ai pu faire des tests que chez SFR et Orange (Sosh). Mais si vous souhaitez savoir si votre opérateur compresse comme un sagouin les images à votre place, je vous invite à tester cette page et à partager vos captures d'écran dans les commentaires.