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

On ne peut les blamer, depuis tant d’année les intégrateurs vivent dans la honte de ne pas avoir « développeur » dans leur titre ainsi que sur leurs cartes de visite, et nos bon vieux amis développeurs de site internet orienté back-office n’ont pas manqué de nous le faire remarquer.

Enfin l’occasion se présente à nous de pouvoir prendre notre revanche sur le reste du monde.

Un peu d’histoire

Après tout, les choses changent, nous aussi (ce n’est pas sale) et comme notre ami de l’intégration française, monsieur Eric Le Bihan me l’a souvent rappelé lorsque je servais à ses côtés ainsi que sous ses ordres: il existait avant notre ère un poste de monteur HTML (une sorte de baltringue des temps modernes donc).

Par simple définition et compréhension de la langue française, on peut d’ores et déjà comprendre qu’il fut un temps où le monteur HTML se limitait à monter des squelettes HTML alors que l’intégrateur se devait d’intégrer (bien joué Sherlock) plusieurs éléments à des pages qu’il montait, et bien souvent, lorsque le développement du site était optimal, il se devait de tout intégrer sur la plateforme de développement même, reliant ainsi diverses technologies entre elles.
Car oui ne l’oublions pas: l’intégrateur est un jongleur de technologies.
Et bien souvent, il est la personne entre toutes les autres, celui qui reliera le pôle produit au pôle développement.

Bref, le monteur se contente de monter. L’intégrateur intègre (et avec intégrité qui plus est). Pas la peine d’avoir fait Normal Sup.
Certes, vous me direz que c’est le même métier mais si on y regarde de plus près, ce n’est pas exactement la même définition.

Mais à quel moment est-il précisément devenu développeur Front-end ?

Un peu de sémantique

Car pour bien comprendre un ensemble de mot, il est bon de les prendre un par un puis de les confronter.

Développeur

Celui qui conçoit, effectue l’analyse et écrit le code d’un logiciel.

Front-end

Front venant de l’anglais et signifiant « premier plan », ce premier plan étant la … BREF, « interface »

Donc, développeur Front-end signifierait « développeur d’interface » ?
« Mais c’est bien sûr. Maintenant que vous me le dites » ! »

Et là tout de suite, vous vous dites que c’est pas demain la veille que vous aller réussir à draguer avec ce titre et qu’il faudra continuer d’essuyer les bars en prétendant être « éleveur de dauphin », une profession souvent mésestimée qui aura certainement le mérite de soulever plusieurs questions lors de vos soirées mondaines.

De la différence… ou pas

Il y a bien sûr des intégrateurs qui, dans le cadre de leur travail, ont pu se rendre compte que les tâches qu’ils effectuaient depuis des années s’apparentaient à du développement d’interface.

Mais en-est-il exactement pareil pour tout le monde ?
Est-ce que tous les intégrateurs peuvent prétendre à cette appellation, cette spécialité qui, une fois définie, prend bien tout son sens, toute sa particularité ?

Et c’est là que comme tout bon petit malin je vous répondrai: ça dépend.

Et j’exemplerai le tout avec l’exemple de ces nouveaux sites fabuleux qui réagissent au scroll de notre bonne vieille molette.
Ne me dites pas que vous l’aviez raté, c’est la grosse mode depuis un an et on n’a pas fini d’en voir à la pelle de ces « parallaxes » … ou encore tous ces petits portfolios qui tendent à se comporter comme un bon vieux site en flash super bien animé, le tout en HTML5 (/TROLL) couplé à j…Query.

Si je peux me permettre: un parallax n’est pas juste un effet au scroll, mais un effet bien particulier, qui mélange plusieurs plans qui ne se déplaceraient pas à la même vitesse durant le déplacement de l’oeil (du scroll donc), créant une impression de profondeur.

Et je m’offusque qu’on parle de développement Front-end pour ces sites. Oui monsieur, car cela n’est pas du développement d’interface mais bel et bien de l’animation d’interface.

« Animateur HTML » pardi !

Oui, vous me lisez bien et je vous vois tous lever un doigt accusateur dans ma direction: BOOOOOUUUUH. Qu’à cela ne tienne, je fais fis de vos railleries.

Si nous réfléchissons bien, nous sommes tous des intégrateurs mais nous avons aussi nos spécialités, par conséquent certains deviennent développeurs d’interfaces, d’autres des développeurs javascript , d’autres s’orientent vers l’accessibilité et certains même repartent vers le design pur forts de leur expérience d’intégrateur.

Alors, pour tous les animateurs qui me liront, je vous le dis messieurs, et mesdames, : je n’ai pas la patience ni le courage nécessaire à créer ce genre de comportement donc je ne vous juge en nul point et vous salue même pour votre patience (sisi), je ne cherche qu’à rétablir un bon ordre des choses entre plusieurs spécialités qui mériteraient de devenir des titres à part entière car selon moi, l’intégrateur a encore de longs jours devant lui tant qu’il n’aura pas pris exactement conscience de ce qu’il fait et à quel degré il s’implique dans son devoir d’intégrateur et beaucoup travaillant en agence réalisent encore du (très bon même) travail d’intégrateur quand certains sont de magnifiques animateurs HTML et d’autres sont de très compétents développeurs d’interfaces.

Et on peut même le sentir, que certains ont déjà prévu ces changements, n’avons-nous pas, chez les intégristes, posté une note sur Adobe Edge ?

Soyez donc fiers de vos compétences et ne tombez pas dans le piège de mettre à jour le titre de votre C.V., respectons les spécialités de chacun et apprenons à nos chers collègues (une fois de plus) l’utilité de la bonne appellation. Au final, le seul titre que toute personne normalement constituée se doit d’obtenir dans une vie, c’est bel et bien celui de « Chevalier de l’ Internet ».

J’espère donc que beaucoup partageront mon avis, que beaucoup d’autres ne le partageront pas et viendront amener leur petite brique (ou leur grand troll) à cet édifice, cette tâche qui nous incombe: savoir définir et, enfin, professionnaliser, que dis-je, assumer nos métiers.

Mon mot de la fin

Ce n’est pas pour nous brosser dans le sens du poil mais ce qui est formidable avec nos métiers issus de « l’intégration française », c’est que pouvons être au four et au moulin puisque nous sommes constamment à mi-chemin entre les deux, essayant de faire communiquer le meunier et le boulanger, aidant à la réalisation d’un produit fini, répondant à plusieurs normes de qualité, mettant notre nez chez l’un et l’autre, amenant nos recommandations à droite et à gauche sur divers sujets tels que, et pour n’en citer que quelques-uns: la typographie, la sémantique, les bonnes pratiques et l’accessibilité.

Alors, il me vient l’idée qu’il est finalement inutile de rajouter des mots pompeux lors de notre recherche d’emploi pour se justifier de faire ce qu’on fait. Non, il n’y a pas de ninja du CSS, de samouraï du jQuery, ni d’ Intégrateur++ mais bien des intégrateurs qui se spécialisent, apprennent, testent et veillent.

Et par conséquent, nous ne sommes pas tous des développeurs d’interface, des animateurs et des intégrateurs confirmés, l’artisan en chacun de nous le sait.

Moi qui assistais à cette grand messe pour la première fois, j’ai adoré :

• D’une part parce que les conférences te donnent du grain à moudre intellectuellement : méthodes différentes, nouveaux outils, interlocuteurs balèzes, tu en sors forcément grandi(e) ;
• D’autre part, parce que sortir de ton train-train quotidien pour te mêler à d’autres professionnels passionnés te fait réaliser à quel point ce métier est cool : Chaque jour au boulot on geint, on déteste, on maudit. Et chaque année on vient à #parisweb et on repart avec un smile jusqu’aux oreilles…, dixit Christophe, que je plussoie ;
• Enfin, parce qu’un évènement comme Paris Web permet de « ressentir une vibe » particulière, où les conférences et les discussions qui s’en suivent – on et off – mettent en lumière des questionnements et des débats d’actualité. En un sens, ça permet de prendre la température du milieu, et de se positionner soi-même par rapport à tout ça.

Un questionnement sur le métier de web designer

A cet égard, la conférence qu’a donnée Francis a été révélatrice. Intitulée « CSS3 / Photoshop : quel avenir pour le métier de web designer ? », cette conférence reprenait un débat initialement provoqué par un tweet d’Elliot Jay Stocks, que Francis avait d’ailleurs relayé et discuté sur son propre blog en février dernier. Le débat n’est donc pas nouveau.

La présentation de Francis était chouette. Mais c’est surtout le débat qui l’a suivie qui fut un des points d’orgue de Paris Web. A tel point que les questions soulevées à ce moment-là ont largement alimenté la « Conférence dont vous êtes le héros » du lendemain, sorte de grand débat public clôturant les deux jours de conférences PW.

Résumons donc le débat en question via l’opposition des deux paradigmes* principaux :

• Francis propose une vision pluridisciplinaire du métier de web designer, s’inscrivant ainsi dans la lignée d’Elliot Jay Stocks, donc, ou d’un Mike Kus (lead designer chez Carsonified). Le web designer devrait savoir coder en HTML/CSS, au moins pour être capable de fournir des maquettes dynamiques, histoire de tester lui-même l’intégration de son mock-up Photoshop. Plus généralement, le web designer devrait se tenir au courant des innovations CSS, afin de connaître les possibilités techniques au moment de l’intégration ;
• A l’opposé, un certain nombre de web designers – dont la figure de proue fut sans aucun doute Julien Dubedout (oui, le Julien de Marie et Julien) – nient en bloc cette théorie. Pour eux, le cœur de métier du web designer réside dans la conception, et l’arrivée de CSS3 ne change rien à cela. Web designer est un métier en soi, pas besoin de déborder sur l’intégration pour être un bon web designer. Les intégrateurs qui rechignent à intégrer des maquettes un peu trop complexes seraient des « fainéants ». Pis, une dame dans l’assistance assura même qu’un web designer sachant intégrer est forcément un mauvais web designer. Mais là c’est du troll alors on oublie.

Parallèlement à tout ça, du côté des Intégristes, on fantasmait en imaginant que la prochaine version de Photoshop intègrera CSS3 directement, en générant, par exemple, des ombres portées telles qu’elles sont générées avec un box-shadow, afin de limiter les différences entre la maquette et l’intégration qui en est faite. On pourrait même imaginer que le logiciel génère automatiquement un fichier HTML/CSS avec les lignes de CSS ad hoc, avec les bons réglages et tout, en fonction des effets CSS sélectionnés pendant la conception, ce qui limiterait finalement les décalages entre d’une part la maquette et d’autre part l’intégration qui en est faite.

Mais, pour excitante que soit cette idée, finalement ce n’est pas ça le plus important. Qu’on pense que le web designer doive sinon intégrer lui-même ses maquettes, au moins faire de la veille et se tenir au courant des innovations CSS, ou qu’on pense que son métier est strictement limité à la conception graphique, le fond du problème n’est pas là.

Pour une vision ouverte des métiers Web

Le plus important, ça a été de voir à quel point l’ego des différents intervenants a pris de la place pendant ces débats. Le véritable problème, c’est que nous autres Français avons énormément de mal à penser en dehors de la boîte, et que nous continuons, à travers ce genre de discours, à perpétuer un système de petites cases hermétiques, desquelles il semble difficile et, pire, mal vu de sortir.

La mentalité française aime les limites, les barrières, la théorie. Elle aime beaucoup moins l’empirisme, les faits concrets, l’acceptation que quelque chose puisse évoluer. Si vous êtes salarié(e), comme moi, votre contrat définit point à point ce que vous êtes censé(e) faire au sein de votre entreprise. Pourtant, nous savons bien vous et moi qu’en tant que professionnels du Web, nous en faisons forcément plus – ce « plus » regroupant un ensemble de tâches pas forcément descriptibles ou quantifiables dans un contrat.

L’idée est de remettre en question le discours selon lequel il n’y aurait qu’une seule acceptation possible d’un métier donné.

Prenez le métier d’intégrateur web, par exemple. Personne n’a évoqué le sujet sous cet angle-là, pendant Paris Web, et pourtant : ce métier a dépassé depuis longtemps le simple découpage HTML/CSS d’une maquette, et a évolué vers une compétence « interface utilisateur » plus vaste. Le métier d’intégrateur web regroupe bien sûr toujours la découpe de maquettes et l’écriture de HTML et de CSS, mais il requiert aussi des compétences en Javascript, ainsi que des notions d’ergonomie, de typographie et de SEO. Selon l’expérience de l’intégrateur, celui-ci peut être amené à participer à l’élaboration de spécifications fonctionnelles, à manager et à gérer des projets, à concevoir des fonctionnalités AJAX avancées. Affirmer que tous les intégrateurs web font toutes ces tâches serait un mensonge. Affirmer que toutes ces tâches ne relèvent pas du métier d’intégrateur aussi.

Au sein de notre Pôle, par exemple, nous avons revendiqué depuis quelques temps la gestion intégrale de Javascript et donc d’AJAX, alors qu’avant, c’était les développeurs qui s’en chargeaient. Les intégrateurs web ne se contentent plus seulement de traiter l’apparence d’un site web, mais ils sont aussi en charge de son fonctionnement front-end, ce qui fait appel à des connaissances que l’on considérait jusqu’à présent plutôt du ressort des équipes de développement. Cela explique d’ailleurs que l’expression « intégrateur web » cède peu à peu sa place à « développeur front-end », comme chez les anglo-saxons, où l’on parle tantôt de « front-end web developer » ou de « web designer », dans un sens plus riche et plus technique que ce que le terme implique en France (design et créa stricto sensu).

A l’instar du web designer censé connaître HTML/CSS, est-ce que l’intégrateur web doit avoir a minima quelques notions de Javascript, de Smarty et de PHP ? Oui.

De même, est-il du ressort de l’intégrateur d’apporter de menues modifications sur des maquettes graphiques pour faciliter la découpe d’images et l’écriture des propriétés des différentes boxes d’un design web ? Selon moi, oui.

Posez ces questions à différents intégrateurs, vous obtiendrez sans doute des réponses différentes. Ça tombe bien, c’est pile ce que j’essaie de démontrer : un métier Web ne relève pas, par définition, d’une science exacte ou figée. S’offusquer qu’on puisse envisager tel métier sous un angle différent du sien me met donc la puce à l’oreille.

Chaque professionnel du Web est libre d’apporter ce qu’il veut dans son poste. Si un web designer suit de très près HTML5, amen ! Si un développeur web est passionné de SEO, amen ! Si un intégrateur se découvre une passion pour AJAX, amen !

Le Web est une grande planète d’où l’innovation émerge chaque semaine. Les professionnels du Web sont quant à eux des « mutants », ayant plusieurs cordes à leur arc. La curiosité me semble être une des qualités essentielles pour évoluer dans ce domaine, et les outils me semblent secondaires. Je rejoins totalement Matthieu Mingasson lorsqu’il dit qu’il est maladroit de tout miser sur une technologie en particulier : ainsi, se décrire comme « spécialiste WordPress » est peut-être à la mode en 2010, mais qui sait si d’ici deux ans, WordPress n’aura pas disparu au profit d’un autre outil, plus performant ? Aucune technologie n’est pérenne. Il n’empêche qu’en 2010, c’est un atout de connaître WordPress sur le bout des doigts, comme c’est un atout pour un web designer de connaître CSS3. L’idée est d’être curieux et de prendre le temps de le rester, afin de faire son métier le mieux possible et de la manière la plus épanouissante possible.

Pour le web design comme pour tout métier créatif, la technique joue un rôle majeur dans la conception, tout en n’étant qu’un outil. Si mes souvenirs sont bons, c’est encore Mingasson qui rappelait qu’un graphiste print, par exemple, connaît la façon dont est fabriqué l’objet qu’il conçoit numériquement : grammage, vernis, reliure, etc. De même, il semble assez logique qu’un web designer s’intéresse à CSS et à l’évolution de cet outil, pour savoir comment sa créa va évoluer une fois intégrée. Cependant, amis web designers, rassurez-vous : personne ne vous demande de concevoir toutes vos interfaces directement dans votre navigateur !

Le Web libre, un travail d’équipe

Finalement, chacun est libre de travailler avec les outils qui lui sont agréables. Je comprends les créatifs que le code fait frémir. Cela doit à peu près équivaloir à l’angoisse que provoque chez moi la perspective de devoir écrire de l’AJAX. Mais, soyons honnête : on a souvent peur de ce qu’on ne connaît pas, ou mal. Le tâtonnement me semble être une caractéristique fondamentale des métiers techniques, car c’est une terre en perpétuelle mouvement. Ce n’est pas une science exacte, c’est du Web. Ce n’est pas un diplôme, c’est une vocation. Et aucun apprentissage ne me semble insurmontable. CSS, par exemple, bon, c’est quand même pas la mer à boire.

Apprendre les contraintes (ah non pardon, les « spécificités ») du métier d’intégrateur ne peut qu’aider à mieux designer, et bien sûr je ne parle pas de créativité – les web designers sont les meilleurs pour ça. A chacun son métier ! S’offusquer qu’on puisse penser que les web designers devraient avoir des notions rudimentaires de HTML et CSS me surprend.

L’amélioration du Web est un travail d’équipe – et ça on n’en a pas trop entendu parler, pendant les débats. C’est pour ça que j’ai parlé d’ego plus haut, c’était très auto-centré tout ça. Ce n’est pas telle équipe d’un côté, telle équipe de l’autre, à chacun ses contraintes et démerde-toi, ah non je ne veux pas entendre parler des spécificités de ton boulot, c’est ton problème. En tout cas, ce n’est pas ma vision des choses, mais je conçois qu’on puisse penser comme ça : on est Français après tout.

Au quotidien, nous autres Intégristes essayons de sensibiliser nos collègues web designers à l’utilisation des grilles, par exemple, pas parce que nous sommes « flemmards » (sic) et que nous en avons marre de devoir spécifier cinquante types de marges différentes (quoi que), mais parce que nous sommes convaincus que la qualité de l’interface n’en sera que meilleure. De même, nous prêtons une oreille à nos collègues développeurs lorsqu’une de nos intégrations leur pose souci ; dans un cas comme l’autre, personne n’accepte systématiquement de remettre son travail en question, après tout chacun sa spécialité. Mais l’essentiel, c’est de communiquer et de prendre conscience des spécificités des autres équipes, afin de fluidifier le workflow et de fournir, in fine, des sites qui « roxent des roukys ».

* oui, vous avez bien lu, j’ai placé « paradigme » dans mon premier article pour Les Intégristes. Histoire de marquer le coup !