Le dernier billet publié sur Les Intégristes parlait d’humilité et de bienveillance à l’égard de nos pairs.

Être bienveillant implique de soutenir nos collègues, d’être indulgent à leur égard, mais cela n’exclut pas d’avoir le courage de leur parler avec honnêteté en cas de problème.

C’est en écoutant des confrères et consœurs travailleurs du web me parler de leurs frustrations au quotidien, qui par email, qui sur Twitter, qui pendant Paris Web, que j’ai eu envie d’écrire sur la relation singulière entre intégrateurs et chefs de projet – une relation ô combien essentielle, sur laquelle on trouve pourtant bien peu de littérature.

Derrière ce billet, il y a un constat : en 2014, j’ai été témoin d’une irritation sourde et croissante chez mes pairs, irritation souvent provoquée par des gestions de projet catastrophiques.

À l’incompatibilité supposée entre intégrateurs et designers a succédé, semble-t-il, la lassitude de certains d’entre nous à l’égard de certains chefs de projet avec qui nous collaborons au quotidien. C’est un ressenti que j’ai perçu de façon assez globale, mais que j’ai trouvé particulièrement exacerbé auprès de mes confrères et consœurs travaillant en agence.

Certes, il est toujours plus facile de voir la paille dans l’œil du voisin que la poutre qui est dans le sien.

J’ai conscience que pointer du doigt les mauvaises habitudes de mes pairs est, sinon politiquement incorrect, du moins délicat. C’est pourquoi je me suis essayée à une forme d’écriture plus légère que d’habitude, sous forme de conte de Noël, ceci afin de provoquer une prise de recul salvatrice.

J’espère de tout cœur que cette prise de risque donnera lieu à des débats enrichissants pour nous tous.

Il était une fois…

Il était une fois, dans un pays très, très lointain, une petite agence web.

Cette petite agence web réussissait toujours à décrocher les projets les plus excitants et les plus valorisants.

Ses clients étaient tous éduqués, sages et riches.

Pour ne rien gâcher, ses locaux rutilants et faciles d’accès se trouvaient à deux pas de la meilleure boulangerie du pays.

C’est dans cette petite agence web que travaillaient main dans la main les Ergonomes, les Designers, les Intégrateurs, les Développeurs, les Commerciaux et les Managers :

• Les Ergonomes avaient toujours le budget nécessaire pour réaliser des tests utilisateurs ;
• Les Designers bénéficiaient à chaque fois d’au moins huit jours pour préparer les avant-ventes ;
• Les Intégrateurs convainquaient à tous les coups leurs interlocuteurs des bienfaits de l’accessibilité ;
• Les Développeurs avaient toujours à leur portée des spécifications complètes et finement rédigées ;
• Les Managers suivaient les plannings à la perfection. Réactifs, c’était des forces positives sur lesquelles on pouvait compter en cas de coup dur ;
• Les Commerciaux quant à eux réussissaient toujours à négocier plus de charges pour que les Ergonomes, les Designers, les Intégrateurs et les Développeurs puissent travailler sereinement, sans pression.

C’est aussi dans cette petite agence qu’officiaient des professionnels réputés : les Chefs de projet idéaux. Ceux-ci orchestraient tous les projets de la petite agence avec flair et doigté.

Que soient narrés aujourd’hui quelques-uns de leurs hauts faits, à travers le prisme de leurs interactions constantes avec les Intégristes Intégrateurs.

Chiffrage et planification

Avant toute chose, les Chefs de projet idéaux pensaient à mettre les Intégrateurs dans la boucle, non seulement pour valider la faisabilité du projet côté front-end et pour macro-chiffrer la charge en intégration, mais également pour lister avec eux tous les éléments dont ils auraient besoin pour commencer à travailler sereinement.

Quand ils savaient qu’un apprenti prendrait part à un projet complexe, les Chefs de projet idéaux veillaient à solliciter un Intégrateur senior afin d’estimer la charge en fonction de ce paramètre.

Les Chefs de projet idéaux faisaient tout leur possible pour éviter que les Intégrateurs soient envoyés du jour au lendemain dans une régie obscure. En effet, les Intégrateurs travaillaient mieux dans un contexte connu. Les régies sont bien souvent synonymes, au mieux, de webmastering désagréable, au pire, de gestion d’urgence, là où une organisation rigoureuse devrait pouvoir éviter ça.

Lorsque Ergonomes et Designers prenaient du retard dans la conception du projet, les Chefs de projet idéaux rassuraient les Intégrateurs en leur confirmant que la date butoir glissait également pour eux.

Enfin, les Chefs de projet idéaux étaient bien organisés, et briefaient les Intégrateurs avant qu’ils ne commencent à travailler.

Qualité du projet

Les Chefs de projet idéaux avaient le cran de parler avec franchise des diverses contraintes à leurs Clients. Ils savaient que, s’ils y manquaient, le projet hériterait d’exigences supplémentaires pour le moins coûteuses.

Les Chefs de projet idéaux avaient à cœur la qualité des projets qui passaient entre leurs mains. Ils ne demandaient pas aux Intégrateurs de mettre en place des mauvaises pratiques par simple peur de devoir dire « non » aux Clients. Par exemple, les Chefs de projet idéaux savaient qu’il était important de former les contributeurs au sous-titrage des vidéos.

Car, oui, les Chefs de projet idéaux accordaient de l’importance à l’accessibilité. Ils savaient que l’accessibilité du web ne concernaient pas uniquement les personnes en situation de handicap, mais qu’elle bénéficiait à tous, et que, si elle était prévue dès la genèse du projet, il serait plus facile de la mettre en œuvre.

En début de projet, les Chefs de projet idéaux prenaient soin d’annoncer aux Intégrateurs que le site devait être responsive, multilingue, optimisé « retina » et/ou compatible avec Internet Explorer 6.

Et, lorsque les Intégrateurs leur demandaient la liste complète des navigateurs avec lesquels le projet devait être compatible, les Chefs de projet idéaux la leur fournissaient facilement.

Les Chefs de projet idéaux prenaient soin de rassembler tous les entrants nécessaires à la bonne exécution des tâches, notamment les maquettes graphiques validées.

Tout affables qu’ils étaient, les Chefs de projet idéaux savaient argumenter face aux demandes parfois surprenantes des Clients.

Recette et maintenance

Les Chefs de projet idéaux apprirent un jour que le Chef de projet d’une autre petite agence web avait recetté un site 48 heures à peine avant la livraison, alors qu’il avait eu plusieurs mois pour le faire au fil de l’eau. Quand ils entendirent cela, les Chefs de projet idéaux éclatèrent d’un rire tonitruant mais noble, que l’on entendit jusqu’au Mont Fuji et au-delà.

Les Chefs de projet idéaux connaissaient très bien la différence entre ce qui relevait du design, du front-end et du back-end. Ils savaient aussi identifier les zones contribuables d’un site. Ainsi, les Chefs de projet idéaux étaient toujours à l’aise pour qualifier les tickets qui passaient entre leurs mains.

De même, les Chefs de projet idéaux assignaient un nombre raisonnable de tickets à une même personne, prenant en compte son degré de connaissance du projet et la difficulté des tâches attendues.

Les Chefs de projet idéaux évitaient aussi d’assigner aux Intégrateurs un ticket concernant, au choix :

• un bug déjà soulevé à plusieurs reprises,
• une anomalie repérée dans un navigateur hors périmètre,
• un problème de contribution,
• une erreur de traduction,
• une demande d’évolution,
• ou encore une majuscule manquante dans un texte, et ce sur 15 gabarits.

Par ailleurs, dans le cadre d’un projet responsive, les Chefs de projet idéaux prenaient soin de rédiger un rapport de bug complet, qui précisait la résolution et le périphérique sur lesquels apparaissaient les anomalies.

Diplomatie et confiance

Les Chefs de projet idéaux gardaient la tête froide. Ils savaient que leur rôle est essentiel pour mener les projets à bien, en particulier pour synchroniser les efforts des différents corps de métiers, et pour arbitrer en cas d’imprévu.

Si, d’aventure, un Intégrateur leur faisait part de ses inquiétudes, les Chefs de projet idéaux prenaient le temps de lui répondre, soit pour le rassurer, soit pour lui montrer qu’ils avaient bien pris en compte ses recommandations ou ses alertes.

Les Chefs de projet idéaux faisaient confiance aux équipes techniques et graphiques. Ils communiquaient suffisamment au quotidien pour que les premiers ne ressentent pas le besoin de devoir soumettre les autres à la question, jour après jour, pour savoir où ils en étaient.

Les Chefs de projet idéaux avaient la même considération pour HTML et CSS que pour n’importe quelle autre technologie web. Ils savaient que ces langages en apparence simples cachent des problématiques complexes.

Après une mise en production, les Chefs de projet idéaux citaient et remerciaient, dans les communications associées, tous les collègues ayant pris part au projet.

Lorsque les Intégrateurs terminaient un projet plus tôt que prévu, les Chefs de projet les incitaient à peaufiner le résultat, ou à rédiger un retour d’expérience lorsque le sujet était intéressant, ceci afin d’améliorer la qualité et de favoriser la capitalisation des connaissances.

Les Chefs de projet idéaux savaient créer un esprit d’équipe stimulant pour que chacun puisse, en toute confiance, donner le meilleur de lui-même.

Enfin, les Chefs de projet idéaux considéraient les contraintes de chaque intervenant avec impartialité. Ils étaient attentifs aux besoins de chacun, et savaient faire preuve d’écoute.

Épilogue

Le monde du travail n’est pas un conte de fées.

Derrière sa forme humoristique, ce billet a pour but d’attirer l’attention sur les éléments stratégiques d’une collaboration efficace entre chefs de projet et intégrateurs.

Les chefs de projet ont une grande part de responsabilité dans le succès (ou l’échec) des projets qu’ils gèrent, mais tout ne repose pas sur leurs épaules. Ils font souvent face à des clients qui n’y connaissent rien, persuadés que créer des sites web est facile et que ça ne coûte pas un rond.

Les chefs de projet doivent souvent réaliser un nombre de tâches indéfinies, qui fluctuent en fonction du milieu dans lequel ils évoluent (agence, annonceur) et surtout du client.

Quant à nous, nous ne sommes pas à la place de nos collègues. Nous ne percevons leur travail qu’à travers nos propres problématiques métier, notre sensibilité ainsi que nos a priori, parfois influencés par les tensions passagères que provoquent parfois les projets ambitieux.

C’est pourquoi nous manquons souvent de recul pour comprendre les contraintes particulières auxquelles les chefs de projet font face, ainsi que les décisions qu’ils sont amenés à prendre, d’autant plus lorsque la communication entre eux et nous est insuffisante.

Ensemble, il est sans doute possible d’améliorer les choses.

En tant qu’intégrateurs, nous avons souvent l’occasion de partager notre expérience professionnelle, que ça soit par tweet, par blog ou par conférence interposés.

Nous participons à l’effort collectif de documentation et de communication, peut-être parce que l’intégration web est toujours, fin 2014, une discipline mouvante, difficile à aborder et à définir.

Donner à voir notre quotidien professionnel fournit – espérons-le – des clés à nos interlocuteurs pour mieux comprendre notre métier et ses particularités.

Or, on n’entend que trop rarement les chefs de projet parler de leur métier et de leurs contraintes spécifiques, alors qu’il s’agit d’un métier tout aussi singulier et stratégique.

Une gestion de projet de qualité est cruciale à la réussite des projets web dont nous partageons la responsabilité et, pourtant, il me semble que les chefs de projet communiquent encore assez peu sur le web.

Les chefs de projet pourraient par exemple donner davantage à voir leur quotidien, leurs méthodes, leurs outils et leurs contraintes, quel que soit leur nombre d’années d’expérience, leur statut ou le type de structure pour laquelle ils travaillent, afin qu’eux et nous puissions mieux travailler ensemble.

J’adorerais aussi lire des retours d’expérience rédigés à quatre mains, par un chef de projet et par un intégrateur, tout comme j’adorerais les voir sur scène ensemble pour nous raconter comment ils ont réussi, jour après jour, à améliorer leur collaboration.

Mais cette collaboration renouvelée pourrait sans doute prendre d’autres formes encore…

Maintenant, c’est à vous : connaissez-vous un∙e Chef de projet idéal∙e ? Quelles sont les caractéristiques de vos chefs de projet préférés ? Racontez-moi une belle histoire, soit dans un commentaire, soit sur Twitter, en mentionnant @lesintegristes.

Et, d’avance, belles fêtes de fin d’année à tous !

Merci à Anne, Corinne, Damien, Delphine, Élodie, Éric, Florian, Fred, JP, Julien, Matthieu, Mehdi, Olivier, Pierre, Samuel et Vincent pour leur relecture et leurs conseils avisés.

Et merci à ma maman, Claire Guillaumet, pour ses illustrations.

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

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 !