Aucun savoir n’est immuable. Aucune technique n’est pérenne. Aucune pratique n’est parfaite. Le métier d’intégrateur web en particulier est une leçon d’humilité permanente.

Toute bonne pratique doit être discutée. Tout intégrateur doit se remettre en question.

Chaque projet web auquel je contribue est l’occasion d’apprendre des choses qui me servent pour le projet suivant. Chaque nouveau projet me permet d’expérimenter et de perfectionner mon approche du développement front-end. Je n’ai jamais produit deux fois le même code, même sur des sites très similaires. L’évolution technologique est telle que c’est presque impossible.

« Ça dépend. »

Je commence à avoir un peu de bouteille en matière d’intégration. Pourtant, plus les mois passent, plus j’intègre des sites, moins j’ai de certitudes. La seule chose dont je suis sûre, c’est qu’il n’y a pas de vérité absolue en matière d’intégration web. Même si un point particulier est conditionné par un certain nombre de bonnes pratiques, toute la particularité de ce métier subtil peut être résumé en une phrase : « Ça dépend. ».

Ça dépend du profil des utilisateurs du site, ça dépend du budget, ça dépend du planning, ça dépend du design, ça dépend des contraintes de développement, ça dépend des objectifs en terme de performances, de qualité et d’accessibilité, ça dépend des plateformes ciblées, ça dépend de l’expérience, du savoir et de la souplesse de chaque intervenant. Bref, ça dépend.

Prendre une décision dans cette immense champ des possibles ne dépend ni de vous, ni de moi. Aucune décision technique pour le web ne peut être la décision d’un seul individu. Pour pouvoir trancher, il faut s’en remettre aux objectifs du projet et à sa cible. Tout est question de contexte.

Débattre, confronter ses idées et sa pratique à celles des autres n’est pas utile, c’est indispensable. Remettre en question les pratiques appliquées depuis des années est une attitude saine. Rappelle-moi pourquoi on a l’habitude de faire comme ça, déjà ?

Errare humanum est

De même, reconnaître qu’on s’est trompé, qu’on a pris le problème par le mauvais côté, qu’on a mis en place une usine à gaz n’est agréable pour personne. Il faut pourtant en passer par là pour se perfectionner.

Force est de constater qu’une critique nous marque tous plus durablement qu’une louange. La faute à notre orgueil mal placé, je suppose. Pourtant, remettre en question nos habitudes de développement est la base même de l’apprentissage.

Se tromper et s’en rendre compte est la garantie qu’on ne commettra pas la même erreur deux fois.

Quand on nous a dit qu’il fallait séparer le fond et la forme, certains l’ont pris au pied de la lettre, et ont oublié qu’ils avaient le droit d’utiliser des classes pour éviter de répéter des déclarations de style au sein de la même feuille de style, multipliant les sélecteurs, court-circuitant la cascade et alourdissant le fichier CSS. Je l’ai fait.

Quand on nous a dit que les sprites, c’était bien, certains d’entre nous en ont usé et abusé. Certes, toutes tes icônes sont réunies sur un seul et même fichier, mais ton fichier pèse 800ko, dont une bonne moitié n’est jamais utile sur 95% des pages. Je l’ai fait.

Quand on nous a dit que le @extend de Sass était révolutionnaire, certains d’entre nous ont fait du zêle et l’ont utilisé massivement, sans se rendre compte qu’ils généraient ainsi des blocs énormes et court-circuitaient eux aussi la cascade. Ça aussi, je l’ai fait !

Un jour ou l’autre, en dépit de notre expérience, de notre passion et de notre sérieux, nous produisons tous quelque chose de moins bon que d’habitude. (Quand je dis « moins bon », on s’est compris !…)

Pire, dans notre pratique quotidienne, alors que nous sommes convaincus d’avoir bien fait notre travail, nous créons sans le savoir et sans le vouloir des problèmes aux collègues à qui nous passons le relais dans la chaîne de production web.

En tant que web designer, j’ai parfois créé des problèmes d’intégration alors que l’intégration n’avait même pas commencé, simplement en concevant un élément d’interface über compliqué. Le design de cet élément allait-il stimuler l’expérience émotionnelle des utilisateurs du site ? Peut-être. Le design de cet élément allait-il contribuer à exploser les charges prévues pour l’intégration ? Sans doute.

En tant qu’intégratrice, j’ai parfois créé des problèmes de développement avant même que le développement ait commencé. Quand j’en prends conscience, je jure mes grands dieux de ne plus commettre la même erreur. Et puis, le temps passe, et j’en commets d’autres.

Mais comment éviter ces effets de bord ? La vérité est là, tapie dans l’ombre, et elle nous observe de toute sa majesté, un sourire aux lèvres : nous ne le pouvons pas. Nous allons nous tromper, et nous devons nous tromper, afin de nous améliorer nous-mêmes, de partager nos retours d’expérience et d’éviter à nos condisciples de commettre les mêmes erreurs que nous.

Garder pour soi ce type de conclusions serait une grave erreur. Certains d’entre vous se disent peut-être que « c’est trop la honte » d’admettre de s’être trompé, que les autres vous montreront du doigt et se moqueront de vous. Encore cette histoire d’orgueil mal placé !

Dans les faits, nous sommes tous friands des histoires qui ont mal commencé mais qui finissent bien. Entre nous, quiconque admet s’être trompé, en démontrant ce qui n’allait pas et en proposant une solution, gagne le respect de ses pairs. De base, comme ça, simplement grâce à cette preuve d’humilité – humilité qui nous manque tant.

Car écrire un énième article sur les bonnes pratiques déjà connues, au fond, a une utilité limitée. Quid de tous les cas dont personne ne parle, des sources d’erreur et de confusion, des pièges à éviter, ou encore des leçons apprises à la lumière de la relecture de notre propre code, six mois après ? (« Par la barbe de Merlin, moi, j’ai écrit ça ?! »)

Il y a deux façons de considérer une erreur :

1. soit comme un échec personnel (coucou l’égo démesuré !) ;
2. soit comme une occasion de rebondir et de s’améliorer.

Pour embarrassants que soient ces moments de prise de conscience, s’ils peuvent être la source d’un coup de main donné à toute l’assemblée des experts front, c’est une jolie façon de transformer un vulgaire caillou en or.

À chaque jour son nouveau messie

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 ! ».

Pire, puisque les moteurs de recherche accordent de l’importance aux réseaux sociaux, ces billets messianiques, très partagés, remontent assez haut dans les résultats de recherche. En conséquence de quoi, grand est le risque de faire aveuglément confiance à ces articles, simplement parce que comme ils arrivent en premier dans Google, ils doivent être les plus pertinents.

C’est là tout l’art délicat de faire de la veille : il faut trier le bon grain de l’ivraie, et même parmi les bons grains, il faut expérimenter, encore et toujours, et ne jamais cesser de poser des questions, comme les enfants : « Pourquoi ? Mais pourquoi ? ».

Ajoutons à tout cela que le développement front-end est en train de vivre une révolution avec, entre autres, d’un côté les problématiques apportées par le responsive web design et de l’autre, l’utilisation des préprocesseurs CSS qui permettent une organisation plus modulaire de notre métier.

Les projets web que nous intégrons, vous et moi, sont devenus énormes : l’intégration web n’est plus l’apanage de quelques boîtes innovantes, de quelques geeks intégristes qui se pignolent sur les spécifications du W3C. Non, l’intégration web est devenue un pilier stratégique pour le web actuel. Paradoxalement, les contours de ce métier n’ont jamais été aussi flous.

On constate des différences de niveau importantes entre les professionnels qui exercent ce métier, à tel point qu’on en vient à se demander si tous les intégrateurs web et développeurs web front-end font réellement le même métier. Le développement web côté client est encore plus expérimental aujourd’hui qu’il ne l’a jamais été.

Le simple fait d’hésiter constamment entre l’appellation « intégrateur web » ou « développeur web front-end » participe à ce trouble généralisé. Et que dire de ceux, de plus en plus nombreux, qui non contents de faire de l’intégration, font aussi du web design ? Et encore, je ne parle que du profil atypique que je connais le mieux ; il en existe pleins d’autres.

En plus du socle technique à la base de notre métier (sémantique, feuilles de styles, accessibilité, bonnes pratiques, interactions), les notions d’ergonomie, de référencement, de performances, de marketing et même de droit jouent un rôle important dans notre activité, sans qu’il soit pour autant possible de les quantifier, ni qu’un seul individu puisse exceller dans toutes. Nous avons tous notre spécialité.

La perplexité que nous ressentons lorsque vient le moment de choisir comment décrire notre métier et sous quel titre nous vendre n’est pourtant rien à côté de la grande confusion qui règne dans les discours des recruteurs IT. Les annonces de recrutement trop vagues et en même temps trop précises, les intitulés de poste qui ne prennent pas en compte les profils de moutons à cinq pattes, et les évolutions de carrière délicates – tout cela ne fait qu’ajouter un grosse louche de flou artistique sur une profession en pleine mutation. Déjà qu’on avait du mal à expliquer le métier d’intégrateur à nos proches…

Dans ce contexte troublé, comment aurait-on la maturité nécessaire pour affirmer: « Il faut faire comme ça » ? Les guéguerres sur Twitter, les vendettas par messages privés et les trolls auxquels nous avons fini par nous habituer prouvent bien que les choses ne sont pas claires. Même les intégrateurs expérimentés se prennent la tête sur les nouvelles problématiques – écrans haute définition, performances sur mobile, animations, SVG, préprocesseurs, typographie, etc.

D’autant plus que le parc informatique n’est pas mûr, lui non plus. Les spécifications de HTML5 et de CSS3 sont encore en cours de rédaction. Et, en dépit des petits malins qui codent uniquement pour Webkit et nous narguent avec un « c’est facile, regarde ! », la grande majorité d’entre nous devons assurer une interopérabilité optimale des sites que nous développons.

Je ne suis sûre de rien

Dans ce contexte, camper sur les certitudes que nous avions acquises dès 2003 avec la révolution réprésentée par CSS Zen Garden me paraît dangereux pour notre pratique actuelle.

Aujourd’hui, nous avançons, petit à petit, en continuant à expérimenter massivement. Le web est encore, en 2013, notre terrain de jeu favori. Chaque jour apporte son lot de découvertes, d’interrogations et de débats enflammés. Nous faisons, en quelque sorte, de la recherche sur la meilleure façon de procéder en fonction d’une contrainte donnée.

Mais tout ce que nous apprenons en ce moment risque d’évoluer, jetant aux oubliettes les méthodes et les bonnes pratiques que nous sommes justement en train de théoriser. Les discours consistant à dire qu’on a toujours fait comme ça, qu’on ne parlait pas de ces contraintes-là à l’époque ou encore que Eric Meyer a écrit un article en 2001 sur le sujet et que, par conséquent, ce qu’il y a écrit est vrai pour la postérité – tous ces discours-là sont surannés.

De même que les tutoriaux qui font leur apparition dès qu’un nouveau « buzz word » pointe le bout de son nez (par exemple, retina). Aujourd’hui, personne ne peut affirmer avoir trouvé la solution ultime qui répondra à tous les cas d’usage et à toutes les contraintes web. L’intégration web, c’est une délicate alchimie. On partage quelques astuces, on fait chauffer les alambics, mais aucun d’entre nous ne détient la formule magique – illusoire… – qui fonctionnerait à tous les coups !

C’est pourquoi je vois l’intégration web comme une leçon d’humilité permanente. C’est un métier dans lequel le concept d’obsolescence programmée fait sens : chaque jour, nous produisons des fichiers qui seront obsolètes quelques semaines plus tard. Chaque sortie de site est accompagnée par son lot de regrets et de pis-allers. « On verra plus tard si on a le temps. » Et puis, au final, on ne l’a jamais, ce temps. Il faut l’accepter.

Et quand vient notre tour de juger le travail de nos pairs, ne perdons pas de vue que nous ne connaissons pas les contraintes avec lesquelles ils ont dû jongler. Critiquons, mais de façon bienveillante. Soyons amicaux et respectueux les uns envers les autres. Après tout, nous ne savons pas ce par quoi un collègue intégrateur est passé pour aboutir à ce résultat-là – contraintes, planning, pressions…

Une seule certitude demeure, néanmoins : il devient urgent de mettre notre orgueil de côté, de rester humbles par rapport à une discipline fondamentalement mouvante et surtout, d’assumer nos erreurs.

Personne n’a la science infuse. Ni vous, ni moi.

Tout ce que je sais, c’est que je ne sais rien.

– Socrate