Quels sont les « entrants » nécessaires pour lancer un projet front-end ?

Derrière cette simple question, il s’agit de faciliter le travail des chefs de projets, mais aussi de tous les corps de métiers qui sont amenés à travailler avec nous autres intégrateurs.

Après avoir réuni quelques éléments de réponse personnels, j’ai posé cette question sur Twitter afin d’obtenir un regard extérieur (encore merci aux nombreux participants). J’ai dû faire des choix, pour en limiter la taille et aller à ce qui me semble essentiel ; mais même si cette checklist n’est pas parfaite, vous avez là une base de travail que j’espère néanmoins très complète.

Notre métier est fait de choix techniques : il nous faut des contextes précis pour y apporter des réponses adaptées. Cette liste permet de mieux les définir.

Bloquant

Informations fournies par le chef de projet

Contexte projets précis. (Qui est le client ? Y a-t-il un site existant ? Quels seront les intervenants sur le projet ? Quel est le budget ? Quelle cible ? Quelle durée de développement ? Etc.)

C’est important pour éviter de faire de la sur-qualité, pour comprendre les enjeux, pour adapter les contraintes ou pour se sentir impliqué…

Informations fournies par la partie design

Maquettes graphiques validées. (Avec éventuellement des prototypes et/ou des wireframes.)

Les maquettes graphiques permettent de se projeter avant de lancer les phases plus techniques de réalisation. C’est une manière de simuler le résultat final sans engager tout le processus.
Si les maquettes ne sont pas validées, le processus sera déjà engagé et les modifications techniques se révèleront plus lourdes.

Sources des polices non web utilisées.

Les polices sont parfois payantes et doivent également être testées avant de les adopter. Elles sont fournies normalement pour un usage « web » clefs en main.
Si ce n’est pas le cas, il faudra se pencher sur les problématiques de licence et de conversion, ce qui demande plus de temps et de nombreux aller-retours.

Animations complexes ? Préciser les déroulements et les timings.

Les animations complexes demandent bien souvent une structure et un code très spécifiques. Ainsi, il faut définir très tôt leurs comportements car il sera très difficile d’en changer en cours de route.

Liste des formats et ratios des images contribuées.

Les images contribuées ou issues d’une base de donnée existante seront plus difficilement déclinables en différents formats, et encore moins en différents ratios. Il est important d’identifier quels seront les formats courants pour faciliter le travail de développement en aval et s’assurer de la bonne homogénéité de l’ensemble.

Planche de composants graphique avec états survolés, activés, désactivés ; palette de couleurs…

Même si les maquettes sont statiques dans un premier temps et aident le client à se projeter, elles servent ensuite de référence pour les intégrateurs. De nombreux états et comportements doivent alors être définis précisément pour bien s’entendre sur le résultat attendu.

Informations fournies par le client

Cible navigateurs. (Bureau, tablettes et mobiles. Indiquer s’il n’est pas possible de mettre en place une dégradation élégante et une amélioration progressive.)

Les choix techniques associés à l’intégration des maquettes se feront en fonction du parc navigateur défini. Plus ce parc est moderne, plus des techniques avancées pourront être mises en place, au profit d’une bonne maintenabilité et de meilleures performances notamment.

Niveau d’accessibilité demandé ? (En précisant si ça entre dans le cadre d’une labellisation.)

Bien que les bonnes pratiques du métier soient généralement appliquées, une contrainte forte en accessibilité changera l’approche technique des choses, il est important de le prévoir (avant même la partie design, cette contrainte va impacter tout les intervenants du projet).

Multilingue ? (En précisant s’il y a du RTL ou des langues asiatiques le cas échéant.)

Là encore, bien qu’il soit d’usage de toujours anticiper sur la longueur des contenus, il sera intéressant d’y porter une attention particulière sur les sites multilingue. Dans le cadre des intégrations RTL ou dans des langues asiatiques, de nouvelles contraintes viennent s’ajouter sur la conception ; mieux vaut anticiper les choses.
Quelle méthode de positionnement préférer quand la maquette doit pouvoir s’inverser verticalement, ou quelles polices utiliser pour les langues asiatiques ?

HiDPI ?

Intégrer pour des écrans à haute densité de pixels demande des sources adaptées (soit des maquettes entières, soit des planches de composants). Il faut également faire des choix entre images matricielles et images vectorielles. Les techniques employées seront ensuite très différentes.

RWD ? (Indiquer si le site sera fluide et/ou s’il y a des paliers.)

Évidement, un travail plus conséquent est à prévoir quand le site doit s’adapter à une grande variété de tailles d‘écrans.
D’un point de vue technique, penser une interface en fluide ou avec des paliers pourra complètement changer l’approche technique. Il est préférable d’avoir cette information dès le départ.

Version imprimée à prévoir ?

Cette partie peut impacter légèrement les plannings et est pourtant souvent oubliée. Les difficultés techniques associées imposent parfois de bien échanger sur le sujet si la demande est précise.

Informations fournies par le client ou la partie développement

From scratch ? (Ou sinon préciser le contexte de l’existant.)

Il sera toujours plus facile de partir sur des bases saines. Hériter d’un existant demande de bien le définir pour mieux l’appréhender.

Contraintes de production ? (Par exemple des bibliothèques imposées, des plugins ou une architecture particulière…)

Il peut arriver que des clients imposent l’utilisation d’outils spécifiques. Il faudra alors maîtriser cette contrainte supplémentaire et sans doute adapter ses processus en fonction.

Contraintes projet spécifiques ? (Par exemple les performances…)

Définir un (ou des) axe(s) de travail permettra de savoir où porter son attention et à être en phase avec les attentes du client.

Informations fournies par la partie développement

Contraintes en développement ? (Par exemple un CMS qui demande du code spécifique, un framework… Fournir les templates adaptés si besoin.)

Il n’est pas toujours possible pendant la phase de développement d’adapter certaines structures imposées par les outils. Aussi, si cela est possible, il est intéressant de communiquer la contrainte aux intégrateurs, qui tacheront alors de contourner le problème différemment.

Format d’échange des données avec les développeurs le cas échéant.

Il sera nécessaire de bien s’entendre sur les formats de données échangées avec les développeurs, pour là encore gagner du temps et éviter des incompréhensions.

Informations fournies par le client ou la partie SEO

Contraintes SEO ? (Par exemple la présence d’un sitemap ou d’une hiérarchisation particulière de l’information, mise en place de microformats ou microdata…)

Il arrive que des contraintes SEO ne soient pas en adéquation avec les bonnes pratiques du métier. Il faut pouvoir l’anticiper pour trouver un compromis, ou simplement ne pas oublier de coder la demande.

Utile

Informations fournies par la partie design

Grille verticale et/ou horizontale.

Intégrer avec des grilles permet d’assurer un meilleur respect du design, tout en facilitant l’étape d’intégration.
Les grilles permettent aussi d’assurer facilement une cohérence graphique tout au long de la vie du projet.

Échelles typographiques.

Les échelles typographiques peuvent être automatisées au niveau code, cette donnée doit être partagée pour qu’elle soit reprise.

Informations fournies par le client ou par la partie design

Contenus types.

Les véritables contenus permettent de mieux appréhender les comportements des maquettes. Il est aussi plus facile d’en contrôler la bonne lisibilité et également d’y apporter les détails sémantiques et micro-typographiques nécessaires.

Informations fournies par le client

Statistiques de navigation du site existant s’il en existe.

Avec ses statistiques, le parc navigateur défini plus haut peut être ajusté plus finement. Les statistiques apportent également un axe supplémentaire sur les questions de contexte projet.

Points d’attention

Informations fournies par la partie design

• Design des messages d’erreurs sur les interactions (formulaires, AJAX…)
• Design des pages d’erreurs. (Erreur 404…)
• Design des e-mails éventuels ? (Avec des contraintes et des besoins dédiés.)
• Design de la favicon et de ses variantes mobiles.
• Design pour les chargements dynamiques (les loaders).
• Design du message relatif aux cookies.
• Design de la page mentions légales si nécessaire.

Ces points sont très souvent oubliés lors de la phase de design. Pourtant ils sont presque toujours nécessaires, et mènent inévitablement à un nouvelle itération.

À vous

Peut-être serait-il intéressant de voir cette procédure copiée à d’autres corps de métiers ? Peut-être qu’il s’agit là d’un travers au travail en silos ? Peut-être qu’il manque quelque chose d’essentiel à cette liste ?

Je serais très heureux de lire vos commentaires.

• Cette cheklist est également disponible sur Trello.
• Et également au format markdown.

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.

Premier réflexe : forcer le http:// en https://

Pour contourner ce filtrage, l’astuce consistant à remplacer http:// par https:// pour accéder à ces trois sites avait cependant circulé rapidement, permettant au salarié informé de les consulter avec modération en dépit du filtrage.

D’ailleurs, l’extension Firefox HTTPS Everywhere permet d’automatiser tout ça : elle force le https:// sur une sélection de sites web, à la base pour crypter au maximum les échanges de données. A l’usage, cette extension permet, aussi, de passer outre un proxy comme Websense.

Mais cette astuce ne fonctionnait pas dans certaines applications, comme dans Spotify, qui semble appeller les avatars depuis Facebook en http://,/ ou dans Tweetdeck, qui ne réussit pas à agréger l’activité Facebook à cause de ce même protocole. Au niveau du Web, cela ne fonctionne que pour les sites gérant effectivement le protocole HTTP Secure, ce qui n’est pas toujours le cas.

Contre-attaque

Mais cette accalmie fut de courte durée : ma boîte décida rapidement d’étendre ce filtrage à tout un ensemble de sites et de blogs, selon des critères plus ou moins obscurs. Et ces sites et ces blogs-là n’ont pas forcément d’accès https://,/ ils devenaient donc définitivement inaccessibles sur notre lieu de travail.

Lorsqu’il s’agit de sites à contenu répréhensible ou illicite, quoi de plus normal que de les filtrer ? Mais lorsque le filtrage touche des blogs ou des réseaux sociaux qui nous permettent de faire de la veille, c’est tout de suite plus problématique.

On pourrait longtemps débattre de la légitimité des catégories établies par un outil comme Websense : ainsi, un article rigolo sur AcidCow qui a buzzé aujourd’hui, a été bloqué parce qu’il serait de mauvais goût (« tasteless »).

Filtrage de AcidCow par Websense

Bon, après tout, c’est peut-être effectivement très mal de vouloir lire cet article pour se détendre pendant sa pause déjeuner pro. Mais intellectuellement, cela me gêne que mon entreprise décide à ma place de ce qui est convenable ou de ce qui ne l’est pas.

Le filtrage Internet pénalise-t-il l’entreprise ?

Cette bienpensance imposée mise à part, le filtrage d’Internet devient plus problématique lorsqu’il court-circuite la veille et la recherche d’information technique. Par exemple, si j’essaie d’accéder à un lien comme 100% Height and 100% Width Flash Embed with jQuery and swfObject, que Google me suggère en réponse à une recherche intitulé « jquery height bug », je ne peux pas y accéder non plus :

Filtrage de Hubpages par Websense

C’est quand même plus embêtant que le blocage d’AcidCow. Google est notre ami, nous devrions pouvoir accéder aux ressources qu’il référence comme à une grande bibliothèque géante.

Mettons ça sur le compte des faux positifs. Le filtrage Internet d’un réseau d’entreprise se défend en terme de confidentialité et de productivité. (Après tout, j’en connais certains qui ont suivi tout Secret Story discrètos sur leur ordinateur professionnel l’été dernier.)

De là à bloquer à l’aveugle des ressources qui peuvent s’avérer utiles – regarder les vidéos Paris Web sur Dailymotion, par exemple -, l’angle n’est plus tout à fait le même. Dans une entreprise où tous les efforts sont dirigés vers l’efficacité technique et commerciale d’un site e-commerce, pouvoir accéder aux ressources de première main, qui font l’actualité technologique de nos métiers, est primordial.

Le filtrage par catégorie doit proposer une bonne granularité sans rentrer trop dans les détails, au risque de générer de nombreux faux positifs, comme le montre l’exemple plus haut.

Par ailleurs, le filtrage d’Internet est un non-sens total pour les métiers techniques du web : en effet, on doit pouvoir accéder à tous les codes sources, pour pouvoir décortiquer telle ou telle interface, s’en inspirer, et en assimiler les bonnes pratiques – même de Facebook, même de Youtube.

Enfin, je ne suis pas convaincue du tout que cela fasse gagner du temps à l’entreprise : en effet, le problème des Proxys à la con, c’est que les gens passent leur temps à essayer de les contourner. Et comme tout le monde y va de sa petite solution, au final cela peut poser d’autres problèmes de sécurité sur le réseau de la boîte…

Pour continuer la réflexion

• L’article sur le filtrage d’Internet, sur Wikipedia ;
• Internet bloqué au travail : les solutions pour surfer sur les sites non autorisés en entreprise
• Filtrage d’Internet : le cadre juridique se précise ;
• Filtrage et Internet au bureau : Enjeux et cadre juridique (PDF) – une ressource très intéressante, qui éclaire notamment les responsabilités de l’utilisateur lorsqu’il accède à Internet dans le cadre de l’entreprise.

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 !