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.

1. HTML5 ne peut pas interagir avec une webcam

L’article souligne également que ce n’est pas près d’arriver, en raison de problèmes liés au respect de la vie privée. Bien sûr, Flash n’est pas concerné par ce problème, contrairement à HTML5, qui l’est (répétez plusieurs fois cette phrase intérieurement, jusqu’à l’assimiler complètement).

Une des premières inepties que pourrait utiliser votre interlocuteur sera de vous dire qu’une spécification existe à ce sujet. On ne peut donc pas dire que HTML5 ne permet pas d’utiliser la webcam ! FAUX. Rejetez fermement cet argument. Ce document est un document de travail, il n’a donc officiellement aucune existence. Comme CSS 2.1, il n’a pas encore obtenu le précieux statut de Recommandation (au besoin, précisez à votre interlocuteur que CSS 2.1 n’est pas encore une technologie mature). Cet argument constitue l’une des fondations de votre défense, n’hésitez pas à l’utiliser dès que vous êtes à court d’arguments.

Une personne bien informée pourra aller jusqu’à vous citer un exemple d’implémentation, comme celle de Ericsson dans Webkit, en proposant d’associer cette technologie à canvas pour manipuler vos vidéos à la volée. Je vous recommande de rejeter cet argument à l’aide d’un revers de main, une tentative d’explication risquerait de vous embarrasser, voire même de vous faire douter (voyez comme les standards sont vicieux !).

2. La vidéo en HTML5 ne peut pas être utilisée en 3D

Si l’on vous parle des CSS Transforms 2D et 3D, précisez à votre interlocuteur que CSS3 n’est pas HTML5 ! Ha ! L’affirmation est donc vraie : HTML5 ne permet pas d’afficher une vidéo sur un plan 3D. Si votre interlocuteur insiste, ne vous laissez pas tromper par ce genre de démonstration : il y a certainement du Flash quelque part. Si l’on tente de vous prouver que cette démonstration n’utilise que des technologies web ouvertes, expliquez calmement que votre choix de ne pas croire doit être respecté.

Si l’on vous parle de Canvas, WebGL, SVG et autres inepties, vous devrez faire preuve d’imagination : vos interlocuteurs ont tort, mais sauront se montrer convaincants. Le plus simple reste de simuler une allergie au changement, mais vous pouvez également trouver d’autres manières d’esquiver cette discussion gênante. Soyez imaginatif, et n’hésitez pas à laisser vos idées dans les commentaires !

3. HTML5 ne peut pas enregistrer le son de votre microphone

Si votre arrogant compagnon vous ressert, comme pour la webcam, sa soi-disante Media Capture API, la discussion est malheureusement arrivée à son terme. Cassez-lui la gueule.

4. HTML5 ne propose rien pour la vidéoconférence

Absolument rien. Quelques rabats-joie isolés pourraient, à tort, vous faire douter à ce sujet. N’en croyez rien. Posez vos mains sur vos yeux, et répétez tout haut « Flash, c’est l’avenir, HTML5 est mort. » jusqu’à oublier ce à quoi vous pensiez (cette technique est très efficace).

5. HTML5 ne permet pas d’ajouter des éléments au-dessus des vidéos, comme des sous-titres, des informations contextuelles, ou encore des boutons de navigation

Cet exemple peut sembler embarrassant. Des initiatives comme Universal Subtitles existent, et la superposition d’éléments n’est pas vraiment quelque chose de neuf en CSS. Soyons réalistes : vous ne pourrez pas convaincre qui que ce soit sur ce seul exemple. Ne vous attardez pas dessus, passez directement au point suivant.

6. HTML5 ne peut pas enregistrer votre webcam

Comme vous le voyez, la répétition est l’une des clés de notre argumentation. Voici déjà la troisième déclinaison de l’argument de la webcam, mais cette liste n’est qu’un exemple, vous pouvez décliner l’idée à l’infini : est-il possible de changer le monde avec une webcam en HTML5 ? Non. Peut-on réparer une webcam avec HTML5 ? Non ! Une webcam peut-elle tenir une discussion cohérente en HTML5 ? Non, non, NON !

7. HTML5 ne peut pas créer d’applications « desktop »

On essaiera de vous rétorquer que Flash non plus. Si vous parlez d’Adobe Air, on pourra vous rétorquer que cette technologie embarque un moteur Webkit, ce qui permet de se passer de Flash pour n’utiliser que HTML, CSS et JavaScript. On vous parlera des widgets de Mac OS X réalisés en HTML, de Mozilla Prism, de Fluid. On vous dira que cette question n’a pas de sens, car si des initiatives existent, HTML5 n’a pas été conçu pour ça, tout comme Flash. Les défenseurs des standards ouverts n’ont aucune pitié, ils ne vous feront pas de cadeau. Prenez quelques jours de repos pour oublier tout ça.

8. HTML5 ne permet pas d’afficher des vidéos avec des niveaux de transparence

Flash non plus, en fait. Il s’agit d’une particularité du bon vieux codec vidéo VP6, qui peut toujours être utilisé avec Flash. Pas d’inquiétude, votre adversaire n’en saura rien. Mélangez tout : affirmez que Flash permet de faire des vidéos transparentes, voire même qu’il a été conçu pour ça (testez les connaissances de votre interlocuteur pour éviter tout malaise). Expliquez que HTML a été conçu pour structurer des documents, pas pour afficher des vidéos transparentes. Si l’on vous parle de manipulation de flux vidéo en temps réel à l’aide de canvas, faites comprendre à votre interlocuteur que le sujet vous ennuie, et avant même qu’il ne vous réponde, montrez-lui quelques exemples d’images animées de chats.

9. HTML5 ne supporte pas encore le P2P

L’auteur de l’article de l’article d’Activetuts+ nous montre ici qu’il n’est pas dupe : entre l’API Websockets et les autres technologies associées à ce besoin, nous savons déjà que ça va bientôt arriver dans les navigateurs. Et alors ? Ce n’est pas implémenté aujourd’hui, profitez de cette petite avance ! Flash doit être utilisé pour faire du P2P, donc Flash n’est pas mort, donc Flash ne mourra pas. CQFD.

10. HTML5 ne propose pas de mode plein écran

Certes, les navigateurs proposaient du plein écran bien avant Flash, et sans avoir à l’implémenter dans votre application. Mais HTML5 permet-il de passer en plein écran en cliquant sur une petite tortue animée ? Non. Enfin presque non. Toute avancée, même mineure de Flash doit être amplifiée et répétée jusqu’à convaincre.

Derniers rappels

Nous l’avons vu, il est parfois difficile d’expliquer aux non-initiés que HTML5 va mourir, car Flash le surpassera pour toujours, dans tous les domaines. Ne vous laissez pas convaincre. Utilisez de gros titres. Présentez votre point de vue en 10 étapes, ce sera plus impactant. Remplacez vos arguments par de grosses images, comme dans l’article d’Activetuts+. Au besoin, fermez les commentaires de votre blog.

Ne doutez plus. Flash sera toujours là. HTML n’est qu’une mode. Soyez patients, ça va passer.