Front-end desi­gner ou inté­gra­teur web ?

On m’a toujours séparé la notion de graphiste web en deux : D’un côté la créa­tion, l’illus­tra­tion. De l’autre le maquet­tage, l’agen­ce­ment, l’er­go­no­mie et les inter­faces.

Côté déve­lop­peur web il y a les back-end pour le code métier et le code serveur, ainsi que les front-end pour le code inter­face.

Inté­gra­teur

Faire du pur HTML/CSS, c’est parfois pris par des déve­lop­peurs front-end, parfois par des graphistes d’in­ter­face. C’est typique­ment ce qu’est l’inté­gra­teur web. Le métier a pris une forte spécia­li­sa­tion depuis 10 ans. Il faut bosser dans un envi­ron­ne­ment très hété­ro­gène, avoir des notions d’er­go­no­mie, beau­coup de connais­sances sur les navi­ga­teurs, y compris tech­nique, faire face à des tech­no­lo­gies en pleine évolu­tion, consi­dé­rer les perfor­mances, etc.

Je lis les tenta­tives de nommage de desi­gner front-end suite aux inter­ro­ga­tions de STPo. J’avoue avoir un peu de mal parce que ce que j’en lis ressemble quasi­ment parfai­te­ment à ce que j’au­rais nommé inté­gra­teur.

Has-been ?

Si je devais envoyer une pique, j’ai l’im­pres­sion qu’il y a un petit complexe face aux nouveaux front-end deve­lo­per, c’est à dire ceux qui font de l’ap­pli­ca­tif JS avec une compé­tence HTML/CSS/HTTP (et déjà, vous notez qu’on manque d’un terme vu que le déve­lop­peur PHP on l’ap­pe­lait déjà front-end deve­lo­per dans pas mal de boites, par oppo­si­tion à celui qui gère le code métier dans des serveurs dans inter­face client).

Oui il y a une demande de ces nouveaux front-end deve­lo­per, et ça fait perdre un peu de contrats aux inté­gra­teurs qui ne couvrent pas cet aspect. Mais si vous accep­tez de délais­ser ce terme en le quali­fiant de has-been, c’est vous-même qui reti­rez de la valeur au métier. Il faudrait le renfor­cer, commu­niquer dessus, montrer la valeur… D’au­tant que trop de front-end deve­lo­per sont juste­ment du coup plus faibles en inté­gra­tion, à connaitre le support de tous les navi­ga­teurs, les bugs louches de CSS, la compa­ti­bi­lité qui ne se résume pas à la dernière version de Chrome, etc.

N’ou­bliez pas que c’est comme ça qu’on a créé ce terme dans le web il y a moins de 10 ans. Avant il y avait les webmas­ter d’un côté, et les déve­lop­peurs de l’autre. Le terme d’in­té­gra­teur on l’a juste­ment à l’époque imposé comme l’ex­pert qui savait faire ce code HTML/CSS avec un peu de javas­cript si besoin, et soit une tendance graphiste soit une tendance avec un peu de PHP, souvent les deux.

Tenter un nouveau terme juste pour rajeu­nir l’image, c’est pour moi une vision non seule­ment très court terme, mais aussi défen­sive en aban­don­nant la valeur au lieu de la renfor­cer à valo­ri­ser le métier.

Desi­gner

Reste la ques­tion de l’an­glais, où le terme d’in­té­gra­teur web ne semble pas exis­ter. Propo­ser un terme autre que front-end deve­lo­per peut avoir du sens, mais je ne suis pas convaincu qu’il faille cher­cher dans une spécia­li­sa­tion de desi­gner.

Je sais que les gens qui parti­cipent à la discus­sion en lien sont quasi­ment tous graphistes *et* inté­gra­teurs. Pour autant, quitte à parler spécia­li­sa­tion des métiers et valo­ri­sa­tion de celui d’in­té­gra­teur, j’au­rais aimé un terme qui regroupe tous les inté­gra­teurs plutôt que de mettre ceux qui débordent côté graphisme dans la case maitresse desi­gner et ceux qui débordent côté program­ma­tion dans la case maitresse deve­lo­per.

C’est oublier ceux qui sont au milieu et croire que fina­le­ment le métier inter­mé­diaire n’existe pas en soi. Bref, aller là aussi à l’en­contre de la valo­ri­sa­tion du métier spéci­fique d’in­té­gra­teur, en le relé­guant comme une cartouche secon­daire d’un graphiste ou d’un déve­lop­peur.

S’il est sain de créer des termes pour des spécia­li­sa­tions, ne créons pas des termes pour décrire ceux qui sont à la fois sur deux ou trois spécia­li­sa­tions précises, sinon on ne s’en sortira jamais et on ne fera que divi­ser. Si vous couvrez plusieurs cases – ce qui est non seule­ment très bien mais carré­ment souhaité – dites simple­ment que vous êtes inté­gra­teur et graphiste d’in­ter­faces, ou inté­gra­teur et déve­lop­peur front, ou encore autre chose. Cumu­lez, ne divi­sez pas.

front-end

Indé­pen­dam­ment de tout ça, même si on veut clas­ser les inté­gra­teur dans les desi­gner (qui en anglais ne recoupe pas que la notion de graphisme au sens français, je le conçois), je ne comprends pas le quali­fi­ca­tif de front-end ici. Pour le déve­lop­pe­ment il y a du back et du front, mais sauf erreur de ma part le desi­gner s’oc­cupe toujours du front – et ce qu’il fasse de l’in­té­gra­tion tech­nique, de la concep­tion d’in­ter­face ou de l’illus­tra­tion/créa­tion.

Inter­face desi­gner m’au­rait déjà moins choqué mais je crois que c’est déjà occupé par un poste moins tech­nique. Je n’ai pas mieux à propo­ser mais front-end desi­gner ne me semble rien vouloir dire.

Je m’amuse de voir que pour une fois, nous avons foison de termes spécia­li­sés en français alors que les anglais n’ont qu’une poignée de termes très géné­riques.

Et moi ?

J’ai toujours eu du mal à me mettre dans une seule case, et j’es­père qu’il en va de même pour beau­coup de gens dans le web. Même quand je ne faisais que de la tech­nique, je n’ai jamais su si j’étais déve­lop­peur ou inté­gra­teur.

J’étais les deux. Certai­ne­ment pas « simple­ment front-end deve­lo­per » dans le sens « inté­gra­teur qui déve­loppe », parce que j’ai toujours vu inté­gra­teur comme une casquette à part entière, qui demande une exper­tise gigan­tesque qui éclipse large­ment le côté « qui déve­loppe ».

Bref, je ne me retrouve certai­ne­ment pas dans cette sépa­ra­tion des graphistes d’un côté et des déve­lop­peurs de l’autre, en éclip­sant les inté­gra­teurs au milieu. Très dommage.


Publié

dans

par

Étiquettes :

Commentaires

6 réponses à “Front-end desi­gner ou inté­gra­teur web ?”

  1. Avatar de Nico

    Pour ma part, je me présente clairement comme étant développeur front-end (même si je ne fais pas à proprement parler d’applicatif JS comme de l’Angular et consorts). Ce terme générique fonctionne bien (ça dit clairement que j’en fais bien + que l’intégrateur historique), on a déjà eu ce débat sur Openweb y a 2 ans et demi dans http://openweb.eu.org/articles/integrateur-au-developpeur-front-end-un-maillon-essentiel-qualite-web et c’est tranché pour ma part.

    C’est périodique ce bon vieux marronnier/crise identitaire. :)

  2. Avatar de Victor Brito

    Je me permets de republier le commentaire que j’ai laissé sur le blog de STPo à ce sujet.

    Intégrateur, développeur front-end, designer front-end… ces querelles de taxonomie et d’intitulés relèvent de la masturbation intellectuelle. Pour ma part, je ne fais pas de distinction « sémantique » entre un intégrateur et un développeur front-end, en ce sens que ces deux appellations couvrent une même réalité.

    S’il y a deux questions centrales, elles ne concernent pas l’appellation à donner au métier de bon nombre de commentateurs , mais la reconnaissance d’un tel profil, d’une part, et le périmètre technique, d’autre part.

    En ce qui concerne la première question centrale, si le métier d’intégrateur / développeur front-end est reconnu comme un métier à part entière, avec les honneurs dus à son rang, dans les pays anglo-saxons (c’est, du moins, l’impression que j’en ai quand j’écoute les conférences d’un Kaelig Deloumeau-Prigent ou que je contemple le travail qu’a pu pondre ce même Kaelig pour BBC News ou le Guardian), il souffre encore d’un manque de reconnaissance dans nos contrées. Même si ça peut bouger favorablement çà et là (je ne doute pas un instant, par exemple, que Nicolas soit reconnu à sa juste valeur dans l’agence où il travaille, même s’il est vrai que son agence est suisse et qu’il est « le Suisse-allemand de la qualité Web » ;) ), combien de fois pouvons-nous constater que le travail livré par un développeur front-end n’a pas été respecté par le développeur back-end (par exemple, des gabarits HTML statiques et valides selon le doctype employé cessant de réussir le test du validateur du W3C une fois le site mis en production) ? Combien de fois pouvons-nous constater que la propreté du code livré par un développeur front-end se retrouve salie par un développeur back-end ou par ceux qui sont chargés de la maintenance ? Combien de fois pouvons-nous tomber sur des agences ou des SSII qui ne veulent pas lâcher les sous quand il s’agit de rémunérer à sa juste valeur un développeur front-end, qu’il soit salarié ou prestataire ? Combien de fois tombons-nous sur des offres de poste ou de mission de développement front-end qui ne jurent que par des frameworks CSS comme Bootstrap (pour ma part, je ne porte absolument pas les frameworks CSS dans mon cœur, surtout les frameworks tendant à l’usine à gaz) ?

    Cette dernière interrogation m’amène à la seconde question centrale. Pour ma part, j’attends d’un intégrateur / développeur front-end qu’il soit capable non seulement de coder du HTML sans éditeur WYSIWYG, mais aussi de savoir coder des CSS sans recourir à un préprocesseur (même si l’utilisation d’un préprocesseur facilite grandement la productivité et la maintenance des projets Web pour la partie CSS, et c’est un grand fan de Sass qui parle), de savoir monter des gabarits HTML sans utiliser de framework (je parie qu’on peut facilement tomber sur des CV qui annoncent une grande maîtrise du HTML et de CSS, mais qui proviennent de profils qui ne savent pas coder autrement qu’en utilisant Bootstrap), de savoir coder en JavaScript sans recourir à une bibliothèque JavaScript (et, lorsqu’il en utilise, de savoir ne pas se ruer sur le premier plug-in jQuery venu). À propos de JavaScript, vu que j’estime qu’un intégrateur / développeur front-end est, à la base, destiné à intervenir sur des pages Web classiques (ou des gabarits d’emails en HTML), je n’attends pas de ce dernier qu’il cherche obligatoirement à maîtriser Angular, Backbone ou tout autre framework JavaScript ni Node.js, auquel cas je préfère qu’on emploie les termes de développeur Angular, développeur Backbone, développeur Node.js… Quant aux outils, à la rigueur, on s’en fiche : ce n’est pas l’outil qui fait le développeur et on ne peut se permettre de mettre en ban un intégrateur / développeur front-end parce qu’il n’utilise pas tel éditeur de code, qu’il ne met pas en place des tests unitaires ou qu’il n’utilise pas Grunt, Gulp ou tout autre outil plus ou moins à la mode qui vous passe par la tête.

    En ce qui me concerne, je me sens développeur : quand je fais de l’intégration HTML / CSS, je fais du développement. Certes, il n’y a pas de MVC dans les parages ; mais, c’est du développement au même titre que du développement PHP, du développement Ruby ou du développement Java, et du développement qui a son lot de spécificités, d’épreuves, de débogages, de difficultés parfois, en un mot de connaissances précises, voire pointues. Autrement dit, si c’était aussi facile et aussi négligeable et si ça ne valait pas la peine de se battre pour sa reconnaissance, des gens comme Nicolas ou moi auraient changé de métier depuis longtemps.

    En revanche, je ne me sens pas designer : je ne fais pas de créa et, même si je peux être amené à critiquer la faisabilité de l’intégration d’une maquette sous Photoshop, Fireworks ou Illustrator ou à être force de proposition à l’égard du travail des métiers de la créa (dans une perspective constructive et dans le respect de ces métiers, cela s’entend), quand j’utilise mes mains, c’est pour manier les touches du clavier, pas pour manipuler un stylet sur une tablette graphique.

    En résumé, à partir du moment où les cordes à son arc comportent le HTML, les CSS et le JavaScript, et à haute dose, on est intégrateur ou développeur front-end, les deux appellations étant équivalentes. Et, à partir du moment où l’on touche aussi, par exemple, à Angular, à Node.js, aux performances, à l’accessibilité, à la qualité Web, à l’ergonomie ou à la créa, on devient un profil polyvalent.

  3. Avatar de Boris

    Ah, le marronnier…

    Sud Web est l’événement que je préfère dans l’année, notamment à cause de sa devise : savoir-faire et faire savoir.
    Faire savoir ses savoir-faire, ce n’est pas trouvé un mot-valise pour les mettre dedans. C’est discuter avec les gens, faire des rencontres (un entretien d’embauche peut être une rencontre), écouter les autres et prendre la parole pour expliquer son travail.

    Je ne vois pas l’intérêt de chercher des noms de métiers. Surtout qu’à chaque fois, ça finit en eau de boudin avec les uns qui « pensent que un Machine, ça doit savoir faire ci ou ça alors qu’un Truc, c’est complètement différent ». Ah bon ? Et si moi j’en envie de faire les deux ? Et si j’en fais qu’un mais que je veux faire l’autre ? Et si je n’en fais qu’un, mais mal, parce que je manque d’expérience, et que je ne le sais même pas… du coup mon métier n’a pas de nom ? On n’en sort pas.

    Parlons plutôt de ce que nous faisons et de ce que nous savons. C’est beaucoup plus intéressant et c’est souvent l’occasion de prendre un café :)

    1. Avatar de Éric
      Éric

      Bah, pour discuter, avoir des termes communs aide bien quand même. Il ne s’agit que de ça.
      Sans compter que les deux questions aux travers des âges sont globalement « qui suis-je » et « où vais-je ». Pas anormal qu’on se pose au moins la première, c’est même plutôt sain.

      Plus basiquement, pour ceux qui travaillent en service ou à leur compte, c’est assez important de pouvoir mettre des termes et se présenter clairement sans avoir à détailler le travail de tous les jours.

      Après nommer les choses a toujours été difficile, presque plus qu’invalider les caches ;)

  4. Avatar de Véro Lapierre
    Véro Lapierre

    Merci Eric.
    Tu viens d’exprimer beaucoup mieux que je ne l’aurais fait, le fond de ma pensée, et mon sentiment face à tout cela.
    Quand je regarde le pad de Marie, j’ai l’impression de faire souvent le métier dont elle parle et pour lequel il manque à priori un terme adéquat, plus que celui de dev front. Pourtant mon intitulé c’est généralement intégrateur. Mais qu’est-ce-que ça veut dire vraiment ?
    Je travaille en ce moment sur un projet ou j’ai fait toute l’architecture de contenu, du conseil de toute sorte, les mockups en collaboration avec la graphiste, étudié les déclinaisons possibles, les possibilité d’évolution du site en même temps que l’activité etc. Et je vais faire l’intégration ensuite.
    C’est un exemple, parmi tant d’autres.
    Ma dernière mission c’était de l’intégration, html / css / jquery .
    Le plus accessible et de qualité possible. Livraison de fichiers statiques et terminé !
    Mais c’est bien la même personne, j’ai mis a profit du savoir et des connaissances dans les deux cas, mais pas de la même façon.
    Je ne fais pas d’applicatif JS et oui, dans ce cas ce sont d’autres développeurs qui font le travail, mais il ne me le pique pas, pas plus que ceux qui font du c+ ou du php de haut vol.
    Il m’arrive très souvent de faire du templating direct dans plusieurs CMS, mais certains classent cela dans le dev back.
    Comment s’y retrouver?
    Et oui il m’arrive de faire du design, au sens UX/UI du terme, mais je ne sais pas forcément comment rendre l’interface cohérente et agréable graphiquement parlant. C’est un autre boulot, celui du graphiste ?
    Je ne suis plus sure de rien, la seule chose que je sais c’est que lorsque l’on me propose quelque chose, je dis oui ou non en fonction de mes compétences et de mes envies mais pas en fonction d’un titre à la définition fluctuante.
    Je crois que moi aussi j’ai du mal avec la case unique, et jusqu’à mieux je reste intégratrice à contre courant :)

  5. Avatar de JeanJean

    Bonjour et merci pour l’article.

    Du coup je suis un peu en dehors du coup, vu que j’ai tendance à me présenter aujourd’hui comme Front Developer… Au final quel est le terme le plus exact, surtout de l’autre côté de l’atlantique ?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *