Blog

Ici nous vous tenons informés des prochains événements de la communauté Drupal et de notre veille !

Portrait de Jean Fenouil, Chef de projet technique

emeline.peysson
14/06/2019
Après de nombreuses années d’expérience en tant que développeur Drupal et Symfony 2 sur des projets d’envergure, Jean a rejoint l’aventure Axess Open Web Services en 2016. Il est aujourd’hui Chef de projet technique. Focus sur ce métier passionnant !
Jean-Fenouil

Après de nombreuses années d’expérience en tant que développeur Drupal et Symfony 2 sur des projets d’envergure, Jean a rejoint l’aventure Axess Open Web Services en 2016. Il est aujourd’hui Chef de projet technique. Focus sur ce métier passionnant.

Axess Groupe : Que préfères-tu dans ton métier ?
Jean Fenouil : Je pense que c’est la partie relationnelle.
Quand tu es Chef de projet, tu es avant tout une interface entre le client, les architectes et les développeurs, l’objectif étant de trouver des solutions et des compromis pour chacun.

A.G : Quelles est la plus grande difficulté du poste selon toi ?
J.F : Le nombre de projets simultanés est parfois important et il est délicat de statuer sur des compromis entre les difficultés de réalisation et ce que veut le client.
Il faut aussi savoir gérer d’éventuels retards, s’organiser en conséquence et reprioriser ses tâches.

A.G : Il faut donc être agile…
J.F : Exactement. Et ne pas avoir peur d’être interrompu régulièrement !

A.G : Un conseil pour ceux qui souhaiteraient devenir Chef de projet ?
J.F : Il faut être curieux de son métier, avoir un bon relationnel et savoir être agréable. Si tu as toutes ces qualités, il n’y a pas de raison que ça se passe mal.

A.G : Un autre conseil ?
J.F : Ne pas s’imaginer qu’il faut d’abord être développeur avant d’être Chef de projet. Ce sont des métiers différents. La continuité de développeur serait plutôt d’être architecte.

A.G : Pourtant, tu as pris une voie différente…
J.F : C’est vrai et c’est un véritable « plus » dans mon quotidien, surtout chez Axess Open Web Services.
Ma culture technique me permet aujourd’hui de savoir évaluer les temps et de mieux guider mes équipes. Je peux aussi faire d’éventuelles vérifications et prendre des décisions rapidement si les développeurs ne sont pas disponibles quand j’en ai besoin.

A.G : A quoi ressemble ta journée type ?
J.F : C’est travailler sur plusieurs projets en simultané, entre 3 et 4 généralement. Des projets qui demandent souvent soit de la technique, soit de la maintenance.
Je gère également les plannings, assure parfois une réunion en interne et reçois ou passe quelques appels téléphoniques à mes clients.

A.G : Et pour ça, quels outils de travail utilises-tu ?
J.F : Redmine pour la gestion des tickets, PHPStorm pour le développement, TeamGantt et Excel pour les plannings.
J’utilise également ma boite mail et les sites web de mes clients bien entendu.
Enfin, Toggl m’accompagne tout au long de la journée et m’indique le temps passé sur chacune de mes tâches.

A.G : Et sinon, pourquoi avoir décidé de rejoindre Axess Open Web Services ?
J.F : C’est déjà pour pouvoir travailler sur de beaux projets. Des projets majoritairement institutionnels et qui portent de belles valeurs.
La seconde raison concerne la société en elle-même et sa taille humaine. Chez Axess Open Web Services, tu connais tes collègues et il existe un rapport de confiance avec ta direction. La taille de l’entreprise te permet également de voir directement l’impact des actions que tu mènes et évite beaucoup d’inerties.

A.G : Si tu devais me citer le plus beau projet auquel tu ais participé chez Axess Open Web Services, ce serait lequel ?
J.F : C’est un des premiers projets sur lequel j’ai travaillé quand je suis arrivé : celui de La Cité de l’architecture et du patrimoine.
C’est un site agréable, efficace et sans trop de complexité. Sans compter que les clients sont exemplaires et humains. Ils ont des demandes réalisables et savent écouter nos conseils.

A.G : C’est la fin de cet interview. Tu aimerais ajouter une dernière chose ?
J.F : Oui. Ne pas oublier qu’être Chef de projet, c’est avant tout être humain !
Je pense que le terme « Chef » n’a pas lieu d’être. Je dirais plutôt que je suis un « facilitateur » d’échanges entre les équipes et le client.

Retour sur le DrupalCamp Paris 2019

Nono
21/02/2019
Les 15/16/17 février 2019 s’est déroulé le Drupal Camp Paris et l’ équipe AOWS était bien sur de la partie.
Photo de la Tour Eiffel au coucher du soleil

Les 15/16/17 février 2019 s’est déroulé le Drupal Camp Paris et l’ équipe AOWS était bien sur de la partie.

Bien que certains dans l'équipe aient arrêté de compter le nombre de DrupalCamps auxquels ils ont participé, c'était pour moi le 1er (après une petite Drupal Europe à Darmstadt).

Un DrupalCamp, c’est l’occasion de voir où en est l’état de l’art dans la communauté, et j’ai pu assister à 5 présentations business (dont deux des nôtres),

Les projets présentés représentent assez bien le coeur de cible de Drupal, à savoir :

  • des projets ambitieux,
  • avec des processus métiers complexes, nécessitant des adaptations custom.
  • souvent multisites, et/ou multilingues.

Et en la matière, nous n'avons pas à rougir des dernières réalisations que nous avons pu sortir .

Et c’est bien sûr l’occasion de pouvoir assister à des conférences s’adressant aux développeurs, et d’apprendre énormément. Pour les curieux qui seraient intéressés par un bref résumé des conférences, un framapad de prises de notes collaboratives existe : https://paris2019.drupal.fr/programme/prise-de-notes-collaboratives

Je recommande d’ailleurs la lecture du compte rendu de deux présentations pour ceux qui sont comme moi en train de progresser dans Drupal :

  • Audit de sécurité d'un site Drupal
  • Drupal 8 - Best practices

Mais s’il ne devait en rester qu’une, LA présentation que je retiendrai c’est celle de Floris Moriceau

https://paris2019.drupal.fr/programme/sessions/economiser-du-temps-dintegration-dans-vos-projets-drupal

Une histoire tragique d’intégration d’un site drupal qui tourne mal, inspiré de faits réels.

  • Des maquettes construites sous photoshop et pas du tout conçues pour être responsives (colonnage plus qu'hasardeux).
  • Maquettes qui seront ensuite validées par le client, sans que l’équipe technique n'ait son mot à dire.
  • Et en plus qui seront validées, alors que le périmètre fonctionnel (ce qui sera développé) sera différent (X features en moins).
  • L'UX designeur n'a aucune connaissance des contraintes technique du CMS. Parmi les nombreuses conséquences que cela va engendrer, il y a notamment la prise en compte du principe des "régions" d'un thème, et suivant l'affichage mobile ou desktop, d'essayer d'afficher les informations aux même endroits (un block en sidebar, qui se retrouverait dans le header par exemple).
  • En plus d'être affichées dans des endroits différents, les informations en mobile sont différentes de celles en desktop, sans raison particulière.
  • Et les maquettes pour mobiles arriveront quand on est déjà en train de faire l'intégration. Bref le site est "mobile-last".
  • Des créa de pages de contenu avec un lorem ipsum qui ne dépasse jamais.
  • Les fonts, sur psd chargées en 6 variantes, en vrai c'est pas terrible.
  • Un thème de base  bien connu est choisi sans que le themeur ait son mot à dire (par exemple le tristement célèbre thème boostrap drupal). Thème de base qui sera très difficile à surcharger et rallongera considérablement le temps d'intégration, plutôt que de partir ex-nihilo.
  • Les maquettes en psd sont ensuite recréées directement en page html/css. Et c'est aux devs à faire rentrer ensuite le "vrai" site dans l'intégration. D'après Floris, c'est à minima rallonger le temps d'intégration par 1.5. D'après moi, et pour l'avoir vécu, c'est plutôt multiplié par 3.
  • Le multilingue => Pas de maquettes en plusieurs langues. Alors que certaines polices d’écriture n'ont pas des caractères spéciaux, que certaines langues sont plus verbeuses et peuvent casser la navigation. Et que certaines langues se lisent de droite à gauche. Vous vous rendrez compte de tout ceci pendant la recette évidemment.
  • En pleine recette avant livraison, un audit SEO met en évidence une hiérarchie de titrage calamiteuse (conditionnelle suivant les pages, et incohérente en général). Mais le site est déjà developpé et intégré, et la charge prévue a depuis longtemps été dépassée.
  • Afin de répondre aux diverses contraintes évoqués plus haut, vous avez (ab)user de hooks, de preprocess, de scripts JS custom, etc. C'est un peu comme faire de la chirurgie (pas très) esthétique et de découper une personne pour la faire rentrer dans une taille donnée d'habits.
  • La conséquence directe de ce découpage bizarroïde, c'est que le site est devenu lent.

J’abonde en tout cas dans le sens de la conclusion :

"Il faut qu’il y ai un échange permanent entre le designer et le themer Drupal AVANT la validation des maquettes par le client. Cela n'empêchera en rien à ce que les maquettes vendent du rêve, de l'émotion, de racontez une user story dynamique et authentique , etc."

Et ca tombe bien, cette année nous allons ouvrir le recrutement pour un thémeur et un UX designer, afin d’internaliser ces compétences et d’avoir une meilleure synergie avec les « devs ».