HTeuMeuLeu

J’ai récemment eu l’angoisse de réaliser le routage d’un e‑mail via Mailchimp. À ma grande surprise, ce service d’envoi d’e‑mail ne propose aucune statistique sur les clients mails utilisés. Mais il indique par contre de surprenantes données sur les fournisseurs de services de messagerie. Ainsi dans l’exemple ci-dessous, je constate que 22 % des destinataires de mon e‑mail avaient une adresse @orange.fr.

J’ai un peu du mal à comprendre l’intérêt de telles statistiques. Mais surtout, j’ai remarqué que ça créait chez certains une incompréhension, interprétant ces données comme les statistiques des webmails utilisés. Avoir une adresse @orange.fr ne signifie pas que je consulte mes mails avec le webmail d’Orange.

Le contre exemple le plus simple concerne l’utilisation d’applications mail. Je peux très bien configurer mon adresse @orange.fr dans l’application Mail sur mon iPad, dans Outlook 2013 sur mon PC, et dans la dernière version de l’application Gmail sur mon téléphone Android.

Ce qui est souvent moins connu, c’est que la plupart des webmails permettent eux aussi de lire des e‑mails d’un autre fournisseur de services de messagerie. C’est le cas par exemple de Gmail, Outlook.com, Yahoo, La Poste, Orange ou SFR. Ainsi, je peux très bien lire les messages de mon adresse Gmail sur le webmail de Yahoo, les messages de mon adresse Orange sur le webmail de SFR, etc.

Il est donc primordial de ne pas confondre client mail et fournisseur de services de messagerie.

Certains webmails et applications mail bloquent l’affichage des images par défaut. Campaign Monitor et Litmus ont déjà des articles très complets expliquant quand cela arrive. Mais je me suis toujours demandé comment les webmails bloquent les images des e-mails quand ils ne les affichent pas par défaut. Je me suis intéressé principalement au blocage des images appelées depuis une balise <img>. Et j’ai identifié deux écoles.

Lire la suite de « Comment les webmails bloquent les images »

Cette semaine est sorti Her Story, un jeu iOS, PC et Mac rappelant la grande époque des FMV. Vous avez accès à une base de données vous permettant de visualiser des vidéos d’interrogatoires d’une femme. Le but est de comprendre son histoire. Vous saisissez un mot, et vous pouvez visualiser les cinq premières vidéos où ce mot est prononcé. À aucun moment on ne vous dira si vous êtes sur la bonne voie ou pas. J’adore la simplicité du concept. Et même si j’étais un peu perdu au tout début, je me suis vite pris au jeu. Et j’ai trouvé que c’était une formidable manière de raconter une histoire. Mon seul reproche est que j’ai eu l’impression d’avoir compris le gros de l’histoire en moins d’une heure.

Tous les webmails ou applications mails ne supportent pas les media queries. Afin de pouvoir adapter la mise en page d’un e‑mail du mobile au desktop, il est important de trouver des solutions techniques ne reposant pas sur leur utilisation. Et ça tombe bien, puisque le module de mise en page en boîte flexible (Flexbox) permet exactement ça. Flexbox se présente alors, en théorie, comme le prétendant parfait pour mettre en page des e‑mails. J’ai fait quelques tests pour vérifier si c’était aussi le cas en pratique.

Le principe de base de Flexbox est d’appliquer des propriétés sur un élément parent qui auront une répercussion sur ses enfants directs. Certaines propriétés s’appliquent alors sur le parent :

• display:flex
• flex-direction
• flex-wrap
• flex-flow
• justify-content
• align-items
• align-content

Et d’autres propriétés s’appliquent sur ses enfants :

• order
• flex-grow
• flex-shrink
• flex-basis
• flex
• align-self

Si vous n’êtes pas familier avec Flexbox, je vous invite à consulter ce guide complet chez CSS-Tricks ou cette présentation chez Alsacréations. Voici un exemple de grille d’images que j’ai utilisé pour faire mes tests.

Si le support de Flexbox dans les navigateurs modernes est plutôt bon, son utilisation nécessite toujours l’utilisation de préfixes -webkit- (pour Safari 8 et moins) ou -ms- (pour IE 10). Ainsi, la principale propriété display:flex s’écrit :

display:-webkit-flex;
display:-ms-flexbox;
display:flex;

Certains webmails (comme Gmail ou Outlook.com sur mobile) ne supportant pas les balises <style>, il est de bon usage pour l’intégration d’un e‑mail d’appliquer les styles directement en ligne sur chaque balise avec l’attribut style. Il existe des tas d’outils pour faire ça automatiquement. Et c’est là où j’ai rencontré une première difficulté pour tester. Absolument tous les inliners que j’ai testé ne tiennent pas compte des multiples déclarations de la propriété display et conservent uniquement la dernière. C’est le cas de Premailer, mais aussi des inliners de Mailchimp, Putsmail, Campaign Monitor ou encore Zurb. (Je n’utilise habituellement pas d’inliner automatique, et ce genre de cas particulier, ainsi que le fait que Premailer a actuellement 86 bugs en attente de correction sur Github depuis 2010, me confortent dans mon choix.) Voici la version avec les styles en ligne (ajustés à la main) que j’ai utilisé pour la suite de mes tests.

Et la bonne nouvelle, c’est que toutes les propriétés liées à Flexbox listées plus haut (et toutes leurs valeurs possibles) sont totalement supportées dans le webmails suivants :

• Orange
• SFR
• Free (Zimbra)
• AOL
• La Poste

Cependant, mon exemple de grille d’images ne fonctionne pas pour autant avec La Poste. Mon code HTML ressemble à ça :

<div style="display:flex; flex-wrap:wrap;">
	<a style="flex:1 1 auto;" href="https://flic.kr/p/9sT8ev"><img src="bed2bb71f0.jpg" alt="" /></a>
	<a style="flex:1 1 auto;" href="https://flic.kr/p/npQD9i"><img src="c16031076e.jpg" alt="" /></a>
</div>

Problème : le webmail de La Poste entoure automatiquement chaque <a> par un <span>. Le code HTML précédent est alors transformé en :

<div style="display:flex; flex-wrap:wrap;">
	<span class="Object" id="OBJ_PREFIX_DWT100_com_zimbra_url">
		<a style="flex:1 1 auto;" href="https://flic.kr/p/9sT8ev"><img src="bed2bb71f0.jpg" alt="" /></a>
	</span>
	<span class="Object" id="OBJ_PREFIX_DWT101_com_zimbra_url">
		<a style="flex:1 1 auto;" href="https://flic.kr/p/npQD9i"><img src="c16031076e.jpg" alt="" /></a>
	</span>
</div>

La mise en page en flex ne s’applique alors plus sur les <a> mais sur les <span>. Ce problème peut être contourné en appliquant la propriété flex sur une autre balise qu’un <a>. Mais ça met en lumière un problème potentiel important : la moindre modification de code HTML risque d’avoir des effets secondaires indésirables importants.

Voici maintenant les webmails dans lesquels Flexbox n’est pas supporté :

• Yahoo
• Gmail
• Outlook.com

Yahoo supprime purement et simplement toutes les propriétés liées à Flexbox listées ci-dessus, même la propriété display:flex.

Gmail et Outlook.com suppriment toutes les propriétés liées à Flexbox, sauf la propriété display:flex. Et dans mon exemple, ça pose du coup un gros problème, car la mise en page est quand même activée, mais avec les valeurs par défaut. Ainsi, sans flex-wrap, le retour à la ligne des images ne se fait plus, et le rendu est alors désastreux. Voici par exemple le rendu dans Outlook.com sur Firefox.

Mais Outlook.com a une autre dernière particularité. Il filtre toutes les propriétés liées à Flexbox sauf… celles préfixées par -ms-. Flexbox fonctionne alors très bien dans Outlook.com, mais que sur Internet Explorer 10 ou 11. Voici par exemple le rendu du même e-mail dans Outlook.com sur IE11.

Côté applications, Flexbox fonctionne bien sur Apple Mail (sur OS X ou iOS), l’application Mail d’Android 4.4 et moins, Thunderbird 31 et plus. Voici un exemple de test de mon e-mail sur Email on Acid.

En conclusion, je dirais que Flexbox dans un e-mail pose malheureusement plus de problèmes qu’il n’aide à en résoudre. Je pense que ça peut être intéressant à utiliser, mais uniquement pour des problèmes qui ne peuvent pas être résolus autrement. Par exemple, la propriété order permet de réordonner les éléments, indifféremment de leur ordre dans le code HTML. iOS 9 va enfin supporter les déclarations @supports en CSS. On pourra alors écrire le code suivant :

@supports(order) {
	.block-to-reorder {
		order:1;
	}
}

De quoi faire un peu d’amélioration progressive, en attendant un meilleur support…

J’ai découvert tout récemment qu’il existait une version mobile du webmail d’Orange. Celle-ci semble utiliser le même préfixage de règles CSS que son pendant desktop, avec le même support de propriétés CSS (ce qui est plutôt une bonne nouvelle puisqu’Orange est plutôt permissif de ce côté là).

Cependant, j’ai remarqué un gros problème au niveau de l’interprétation de double tirets dans le code HTML ou CSS. Le webmail mobile d’Orange va systématiquement remplacer toute occurrence de -- (tiret tiret) par - - (tiret espace tiret). Et ça, c’est très pénible, en particulier si comme moi vous appréciez la notation de la méthodologie BEM. Prenons par exemple le code suivant…

<style>
	.button--primary { color:#fff; background:#333; }
</style>
<a class="button--primary" href="http://www.hteumeuleu.fr/">Mon blog</a>

…sera transformé par le webmail mobile d’Orange en…

<style>
	.button- -primary { color:#fff; background:#333; }
</style>
<a class="button- -primary" href="http://www.hteumeuleu.fr/">Mon blog</a>

La règle CSS .button- -primary n’a alors plus aucun sens, et ses styles sont ignorés par le navigateur. La solution est alors de ne jamais utiliser de double tirets dans un nom de classe HTML ou une règle CSS. Soit.

Mais ce problème touche également les commentaires HTML. Ainsi le commentaire suivant…

<!-- Ceci est un commentaire HTML -->

…sera transformé par le webmail mobile d’Orange en…

<!--- - Ceci est un commentaire HTML - --->

Par chance, les balises ouvrantes et fermantes du commentaire HTML sont quand même conservés. Mais ça se gâte si on utilise un commentaire conditionnel, par exemple pour cibler certaines versions d’Outlook. Ainsi le commentaire conditionnel suivant…

<!--[if gte mso 9]>Du contenu visible uniquement sur Outlook.<![endif]-->

…sera transformé par le webmail mobile d’Orange en…

<!--- -[if gte mso 9]-->Du contenu visible uniquement sur Outlook.<!--[endif]- --->

Le commentaire est ici carrément réécrit, avec une fermeture avec le [if gte mso 9], et une réouverture avant le [endif]. Ainsi, le contenu à l’intérieur du commentaire conditionnel, censé s’afficher uniquement sur Outlook, sera visible sur le webmail mobile d’Orange. Je n’ai alors malheureusement pas d’autre solution que de ne pas utiliser de commentaire conditionnel. Ou alors de choisir de ne pas supporter ce webmail mobile.

En février dernier, Aaron Gustafson expliquait sur son blog que les variables CSS sont une mauvaise idée. Ses principaux arguments sont que le support est pour l’instant mauvais et que la syntaxe est atroce. Et il n’a pas totalement tort. Les variables CSS ne fonctionnent pour le moment que sur Firefox. Et voici à quoi ressemble la déclaration et l’utilisation d’une variable en CSS.

body {
	--main-color: #333;
}

h1 {
	color: var(--main-color);
}

Si vous êtes habitué à la syntaxe habituelle des pré-processeurs, c’est sûr que la syntaxe à base de double tirets et la fonction var() sont plutôt rebutantes. Et pourtant, ces derniers mois, je suis tombé sur plusieurs intégrations qui m’ont fait dire à chaque fois : vivement les variables CSS !

Lire la suite de « Vivement les variables CSS ! »

La série d’articles « Dear Design Student » de Mule Design Studio est vraiment intéressante. Le dernier article en date, « Working  With Aluminium », l’est encore plus :

N’importe quelle discipline de design a une composante technique. Les designers graphiques ont besoin de l’imprimerie, les designers industriels ont besoin d’ingénierie, et les designers numériques ont besoin de code. Les designs élégants et efficaces prennent en compte les propriétés et limites de leurs matériaux. Les designers qui font de l’excellent travail étudient leurs matériaux pour comprendre les contraintes auxquelles ils répondent.

Allez regarder une vidéo de Jony Ive qui parle d’aluminium. Il adore clairement ce truc. Il a passé des heures à y penser et à expérimenter avec. Je parie que certains soirs il rentre chez lui et fait tomber des copeaux de métal en secouant son t-shirt. Personne ne lui dit que son enthousiasme pour la métallurgie implique qu’il devrait enfiler une combinaison et opérer un routeur CNC à l’usine. Il apprend ce qu’il doit apprendre pour obtenir le maximum de ses matériaux, et la qualité de son travail reflète ce soin et cette attention.

Cela devrait être votre attitude vis à vis du code en tant que designer. Apprenez tout ce que vous pouvez, et appliquez le constamment dans le but d’améliorer vos designs. Vous ne devez pas être un développeur pour y trouver un intérêt et y acquérir en compétences. Parfois avoir suffisamment de connaissances pour poser les bonnes questions est tout ce dont vous avez besoin. C’est votre responsabilité d’être impliqué dans la globalité du processus de design par tous les moyens possibles.

Cette année, Litmus organise des concours communautaires visant à présenter des concepts d’e-mails un peu plus originaux que de trucs tout en tableaux. Le second concours vient de se terminer, et avait pour but de présenter une navigation créative au sein d’un e-mail. Pour participer, j’ai eu envie de porter cet effet de menu gluant créé par Lucas Bebber (et détaillé chez Codrops).

C’est un exemple particulièrement intéressant car cet effet nécessite à la fois l’utilisation d’un filtre SVG pour l’effet gluant à proprement parler, de transitions et transformations CSS pour faire bouger les éléments, et d’une interaction sans JavaScript. J’ai appris plein de choses en m’essayant à cet exercice. Voici le résultat final de ma participation et quelques détails sur le fonctionnement de tout ça.

Lire la suite de « Un e-mail interactif avec filtre SVG et transitions CSS »

Le CommitStrip du jour fait mouche :

Juger de ce qui est simple ou compliqué est très relatif. Par exemple je connais certains développeurs qui sont tellement à l’aise avec Vim qu’ils trouvent ça simple. La dernière fois que j’ai lancé Vim, je suis resté bloqué sans savoir quoi faire devant le premier écran et j’ai du chercher un tutoriel pour m’expliquer comment quitter la commande. Pourtant quand je lis Harry Roberts, j’ai vraiment l’impression que c’est simple.

L’exemple de Commit Strip m’a rappelé une autre bande dessinée, mais cette fois-ci de Penny Arcade, lors de la sortie du Fire Phone d’Amazon :

Le nouveau « Fire Phone » a une partie de son UI qui s’appelle « l’enchanteur ». Je ne pense pas que vous puissiez faire ça. Si je vois quelque chose d’enchanteur, j’en suis enchanté. Sans que vous n’ayez à me le dire. Je le sais immédiatement.

Dès que vous l’appelez ainsi, je suis mal à l’aise. Tout le truc devient vraiment suspect.

En décembre dernier, avec mes collègues, on a relancé Cher Papa Noël pour la quatrième année consécutive. Précédemment, l’accroche principale du site était :

Créez et partagez simplement vos listes d’idées de cadeaux de Noël.

Pour cette année, on a supprimé le « simplement ». D’une part, parce que ça rend la phrase plus simple. Mais surtout parce qu’en faisant tester le site, on s’est rendu compte que le site n’était pas si simple. Le site permet de créer des listes d’idées de cadeaux en y collant les URL de produits que vous avez copié ailleurs sur le web. Copier, coller, bim. Sauf qu’en faisant tester le site par nos proches, on s’est rendu compte que pour certains (moins familiers avec l’utilisation d’un ordinateur et du Web en général), un copier-coller et une URL, c’est déjà très compliqué. 

Alors on a supprimé le « simplement ». Ce n’est pas à nous de juger si le site est simple ou pas.

L’année dernière, Chris Coyier avait publié un article sur les mots à bannir dans l’écrit éducatif.

Je ne suis pas diplômé en Anglais, mais en tant qu’auteur et consommateur de tonnes d’écrits (principalement techniques) éducatifs, je remarque un certain nombre de mots et phrases qui reviennent souvent et n’ajoutent rien du tout à l’écriture. En réalité, ils peuvent même lui nuire.

« Évidemment », « simplement », « bien sûr », « clairement », « juste » ou « facile » font partie de la liste. Je suis probablement coupable d’utiliser ces expressions beaucoup trop souvent. Mais désormais, à chaque fois que je me surprends à employer l’un de ces termes dans un e-mail à un client ou dans un article, je reprends ma phrase et je la simplifie.

Essayez, vous aussi. Vous verrez, c’est facile.

C’est la nouvelle de la semaine rapportée par FreshInbox : Yahoo supporte désormais officiellement les media queries. Précédemment, Yahoo filtrait les media queries, et les filtrait mal. Ainsi le code suivant…

@media only screen and (max-width:600px) {
	.box { width:auto; } 
	.box-title { font-size:1.25em; }
}

… était transformé en :

_filtered #yiv6851014585 {
}
	#yiv6851014585 .yiv6851014585box-title { font-size:1.25em; }
}

Yahoo prenait le contenu entre la première accolade ouvrante d’une media query et la première accolade fermante (correspondant à la première règle), et filtrait le tout. Les autres règles contenues dans la media query se trouvait alors appliquée quelque soit le medium. On utilisait alors des sélecteurs d’attributs dans les media queries pour éviter que les règles ne s’appliquent. Tout ça, c’est désormais terminé.

Et cette correction ne vient pas de nulle part. Il y a tout juste un mois, Justin Khoo a remonté le bug sur la plate-forme dédiée de Yahoo. Et en un mois seulement, Yahoo a fait la correction. C’est très encourageant de voir que Yahoo est prêt à faire ce genre de corrections.

L’autre bonne nouvelle, c’est que cette modification s’applique pour toutes les versions de Yahoo, soit le webmail desktop, mais aussi les applications iOS ou Android.

Tout n’est cependant pas tout rose. Yahoo ne supporte que les media queries basées sur min-width, max-width, min-height ou max-height. Les media queries basées sur min-device-width, min-device-height, max-device-width, max-device-height, -webkit-min-device-pixel-ratio ou même print seront filtrées.

Ainsi le code suivant…

@media only screen and (max-device-width:600px) {
	.box { width:auto; } 
}

… est transformé en :

@media screen and ( _filtered_a ) {
	#yiv6851014585 .yiv6851014585box { width:auto; } 
}

Un autre bug survient dès que l’on imbrique des media queries les unes dans les autres. Ainsi le code suivant…

@media only screen and (min-width:320px) {
	@media only screen and (max-width:480px) {
		.box { background:#001F3F; }
	}

	.box { background:#FF851B; }
}

… est transformé en :

@media screen and (min-width:320px) {
	@media screen and (max-width:480px)
	#yiv6851014585 .yiv6851014585box { background:#001F3F; }
}

#yiv6851014585 .yiv6851014585box { background:#FF851B; }
#yiv6851014585

Alors très clairement, je n’écris jamais de media queries comme cela (et j’ai du mal à imaginer des cas où ce serait indispensable de l’écrire comme ça). Mais cela pourrait devenir courant avec l’arrivée future de la spécification des Media Queries niveau 4.

Bravo quand même à Yahoo d’avancer dans la bonne direction. J’espère que ceci est le premier pas d’une longue marche.

En refaisant des tests sur le webmail mobile de La Poste, je suis tombé par hasard sur un nouveau bug. Par défaut, le webmail mobile de La Poste remplace la balise <body> d’un e-mail par un <div class="tag_body">. C’est une pratique plutôt courante chez les webmails. Jusqu’ici tout va bien.

Afin d’ajuster les styles appliqués sur la balise <body>, le webmail de La Poste remplace aussi les sélecteurs body { } par div.tag_body { }. Jusqu’ici tout va bien.

Mais si la moindre de vos classes a le malheur de contenir le mot body isolé, alors elle sera également affectée par ce remplacement dans les styles. Ainsi un sélecteur .media-body sera transformé en .media-div.tag_body. Curieusement, cette transformation ne s’applique pas si le terme body est inclus dans un mot.

Ainsi le code suivant…

.body {  }
.media-body {  }
.everybody {  }

… est transformé en :

.wrapper_h8uftw div.tag_body {  }
.wrapper_h8uftw .media-div.tag_body {  }
.wrapper_h8uftw .everybody {  }

Afin d’éviter ce problème, je n’ai pas trouvé d’autre solution que d’éviter d’utiliser toute classe contenant le mot body.

Cette semaine je suis tombé sur une fonctionnalité bien particulière du webmail mobile de La Poste. Quasiment chaque lien vers Youtube ou Dailymotion est complété par l’ajout d’un lecteur intégré. Dans l’exemple suivant, j’ai mis un lien vers une vidéo Youtube, et un lien vers une recherche Youtube.

Ainsi, le code suivant…

<a href="http://www.youtube.com/watch?v=i6ft4GcaNPE">Un Zombie Dingo</a> sur <a href="http://www.youtube.com/user/WaltDisneyStudiosFR/search?query=Mickey+Mouse+Episode+int%C3%A9gral">Youtube</a>

… est transformé en :

<object width="250" height="200">
	<param name="movie" value="http://www.youtube.com/v/www.youtube.com&hl=fr&fs=1&rel=0">
	<param name="allowFullScreen" value="true">
	<param name="allowscriptaccess" value="always">
	<param name="wmode" value="transparent">
	<embed src="http://www.youtube.com/v/i6ft4GcaNPE&hl=fr&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="250" height="200">
</object>
<br>
<a href="http://www.youtube.com/watch?v=i6ft4GcaNPE" target="_blank" class="ui-link">Un Zombie Dingo</a> sur 
<object width="250" height="200">
	<param name="movie" value="http://www.youtube.com/v/www.youtube.com&hl=fr&fs=1&rel=0">
	<param name="allowFullScreen" value="true">
	<param name="allowscriptaccess" value="always">
	<param name="wmode" value="transparent">
	<embed src="http://www.youtube.com/v/user/WaltDisneyStudiosFR/search?query=Mickey+Mouse+Episode+int%C3%A9gral&hl=fr&fs=1&rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" wmode="transparent" width="250" height="200">
</object>
<br>
<a href="http://www.youtube.com/user/WaltDisneyStudiosFR/search?query=Mickey+Mouse+Episode+int%C3%A9gral" target="_blank" class="ui-link">Youtube</a>

Cette fonctionnalité part d’un bon sentiment. Mais dans la pratique, son implémentation est une véritable catastrophe. Et ça pose un certain nombre de problèmes :

1. Chaque balise <a> est directement précédée par l’insertion d’une balise <object> et d’un <br>. La mise en page de votre e-mail risque d’être déformée à cause de ça, que ce soit parce que vous avez mis un lien sur du texte ou autour d’une image.
2. Un lecteur est intégré même pour les liens qui ne correspondent pas à des vidéos (par exemple une page d’utilisateur, une page de recherche, ou n’importe quelle page statique de Youtube ou Dailymotion). Dans ce cas, rien ne fonctionne, et on se retrouve avec une zone vide à l’écran.
3. Le lecteur intégré utilise Flash. Pour un webmail sur mobile. J’aimerais bien rencontrer celui qui a eu cette idée de génie. Youtube parvient à renvoyer une version HTML5 de la vidéo à travers la balise <embed>. Mais pour Dailymotion, rien ne fonctionne si vous n’avez pas Flash Player installé.
4. Si vous avez Flash Player installé, le lecteur Youtube ne fonctionnera pas car l’URL en valeur du paramètre movie est erronée. (On a alors une balise <param name="movie" value="http://www.youtube.com/v/www.youtube.com">).

Je suis vraiment émerveillé par autant d’erreurs qui montrent que tout ceci n’a jamais du être testé une seule fois par la moindre personne chez La Poste.

Heureusement, je me suis rendu compte qu’on pouvait facilement éviter l’ajout du lecteur intégré. Pour cela, il suffit de préciser tous les liens vers Youtube et Dailymotion avec un protocole https, et non en http.

Je suppose que les développeurs du webmail n’ont même pas pris la peine d’écrire une regex permettant de gérer les deux cas. Et c’est tant mieux. Paradoxalement, leur incompétence (pour créer un tel filtre) nous sauve de leur incompétence (pour intégrer un lecteur vidéo).

Il y a 5 ans, le 24 février 2010 à 15h53, je publiais mon premier tweet. Je suis plutôt mauvais pour fêter les anniversaires, mais celui-ci me tient à cœur. Des paroles de la chanson Wooden Nickles de Eels me sont revenues en tête aujourd’hui, et elles illustrent parfaitement mon état d’esprit :

thinking how things have turned out
i never would’ve guessed it this way

Mon compte Twitter a atteint les 10 000 abonnés la semaine dernière. C’est fou. Presque absurde, même. Je tweete. J’écris des articles. Je monte des projets. Je donne des conférences. Je vais bientôt me lancer dans de la formation.

C’est fou. Je n’aurais jamais pu m’imaginer faire tout ça. Je n’ai aucune idée de combien de temps je continuerais tout ça. Je n’ai aucune idée d’où tout ça va m’amener (si ça m’amène quelque part un jour). Mais je vais essayer de continuer de faire ce qui me plaît.

Merci à tous mes lecteurs et abonnés de m’accompagner dans cette étrange aventure.

Des discussions intéressantes ont émergé récemment sur la pertinence de la dénomination du métier d’intégrateur à travers des articles comme « Je ne suis pas développeur » (par STPo), « Front-end designer ou intégrateur ? » (par Éric Daspet) ou dans un document collaboratif (lancé par Marie Guillaumet).

J’ai un attachement personnel déraisonné pour le nom d’intégrateur. Mais à chaque fois que je lis des discussions sémantiques sur des termes de nos métiers, je ne peux pas m’empêcher de repenser à ces sages paroles de Richard Feynman.

Un lundi, quand nos pères étaient au travail, nous autres enfants jouions dans un champ. Et l’un des enfants m’a dit : « Tu vois cet oiseau ? Quelle espèce d’oiseau est-ce que c’est ? » Et j’ai dit que je n’avais pas la moindre idée de quelle espèce d’oiseau il pouvait s’agir. Et il dit : « C’est une grive à gorge brune. Ton père ne t’apprend rien du tout ! » Mais c’était tout le contraire.

Il m’avait déjà tout appris. « Tu vois cet oiseau ? » me disait-il. « C’est une fauvette de Spencer » (il ne connaissait pas le vrai nom). « Et bien, en italien, c’est une Chutto Lapittida. En portugais, c’est un Bom da Peida. En chinois, c’est un Chung-long-tah, et en japonais, c’est un Katano tekeda. Tu peux apprendre le nom de cet oiseau dans toutes les langues du monde, mais quand tu auras fini, tu ne connaîtras absolument rien de cet oiseau. Tu en sauras seulement plus sur les humains à différents endroits, et comment ils nomment cet oiseau. Alors regardons cet oiseau et voyons ce qu’il fait — c’est ça qui compte. »

J’ai appris très tôt la différence entre savoir le nom de quelque chose et savoir quelque chose.

Je me fiche pas mal que mes collègues ou clients me désignent comme intégrateur, développeur front-end, monteur HTML ou développeur guichet. L’important, c’est qu’ils comprennent ce que je fais, là où mon métier commence, et là où il s’arrête. Et ça peut très bien varier d’un client à un autre, ou d’un projet à un autre.