A chaque fois que l'on démarre une formation, on fait un petit tour de table pour que chacun se présente et nous parle un peu de son expérience. C'est une super occasion de briser la glace et de mettre tout le monde en confiance. Pour moi c'est aussi un bon prétexte pour picorer des bribes d'informations qui me serviront à lancer la conversation par la suite et à rebondir avec mon contenu. Parmi nos pré-requis de formation (et son intitulé) figure la mention "pour développeur Drupal". Oui mais voilà, ça veut dire quoi un développeur Drupal ?

C'est là que les choses se compliquent. Dans chaque société que l'on croise, la fiche de poste du développeur Drupal a un périmètre (très) variable. Je ne suis pas sûr qu'il y ait une bonne réponse parmi tous les cas d'usage mais au final j'ai le sentiment que cela se ressent un peu sur le marché. Les (vrais) développeurs Drupal finissent par être pénalisés car noyés dans la masse. Il en va de même sur la liste des critères de l'expert Drupal.

Regardons cette petite mise en scène qui se déroule il y a 2 ou 3 ans, les deux protagonistes sont Marc, un chef d'agence web et Thomas, un développeur PHP qui a déjà sauvé l'agence plusieurs fois pour des clients clés avec des demandes un peu trop tatillonnes le week-end.

Marc : Hey Thomas, viens me voir une seconde. Tu as vu l'email que je t'ai envoyé il y a cinq minutes ?
Thomas : Hmm, oui ? A propos du site vitrine avec Durpal ?
Marc : Ouais, Drupal, ouais. Le client a demandé à ce que l'on réponde avec et j'aimerais bien que tu te lances dessus pour qu'on se fasse les pieds.
Thomas : OK.

Quelques semaines plus tard, Thomas a réussi à mettre en ligne le projet en un temps record, faisant la fierté de Marc. Nos deux compères se croisent à la machine à café.

Marc : Bravo Thomas pour ta mise en ligne, c'est super. Le client est super content et t'as bien bossé.
Thomas : Merci Marc, content que ça plaise à tout le monde.
Marc : Dis moi, on est entrain de répondre à un plus gros projet avec Sarah d'ici la semaine prochaine et on pense que Drupal fera le job, tu pourras jeter un oeil ? T'es notre expert Drupal maintenant !
Thomas : Je dois mettre en prod MonSuperBoulanger.fr d'ici 10 jours, ça va être compliqué. Il fait quoi votre site ?
Marc : Oh bah les trucs classiques, de la gestion de contenu, un moteur de recherche de ressources, on a de la gestion de groupes et peut être que l'on doit importer les contenus de l'existant.
Thomas : Ah ouais quand même, bon ça devrait le faire alors. J'ai lu que Drupal savait faire ces trucs.

La réponse de l'appel d'offre part, par chance l'agence remporte le projet et voilà Thomas qui par la force des choses enchaine son deuxième projet. D'autres suivront jusqu'à cette fin d'année 2016 où le client historique de la boite souhaite refondre son site. Drupal 8 semble être le candidat idéal pour cette refonte mais Thomas ne connaît pas encore cette nouvelle version. L'esprit éclairé qu'est Marc lui propose alors de participer à la prochaine session de formation à Drupal 8 d'Happyculture.

La session de formation démarre, 4 participants ont répondu présent, Thomas est l'un d'eux et vient son tour de se présenter.

Thomas : Je suis Thomas, 29 ans, développeur Drupal, j'ai commencé Drupal en 2014 et j'ai uniquement fait du Drupal 7. Pour cette formation, j'attends de découvrir les nouveautés de Drupal 8 et de m'imprégner des bonnes pratiques du moment.

Nous y voilà, tous les participants nous racontent plus ou moins la même chose, tout le monde est impatient de découvrir Drupal 8. Lorsque l'on pose quelques questions, ils ont tous fait du développement avec Drupal. Et puis au fur et à mesure que la formation avance, lorsque l'on parle de paramètres de formateurs de champs, de types de champs personnalisés, de contrôleurs dédiés, de handlers de views, de types d'entités personnalisés, de cache etc on se rend compte que très rarement un participant a déjà fait tout (ou une partie de) cela. Alors on s'adapte car l'une des qualités les plus importantes dans la formation c'est la capacité à s'adapter faute de quoi on risquerait de s'emporter. Alors beaucoup de ces participants se présentent comme développeurs mais le sont-ils vraiment ?

Quels profils pour une équipe

Selon moi il y a 3 métiers dans l'écosystème Drupal. Je serai ravi d'en débattre avec vous si votre avis diffère.

Profil 1 : le thémeur

C'est à mon avis, le profil le plus rare sur le marché Drupal. Il s'agit d'une personne qui fait traditionnellement de l'intégration (ou du dév front-end si l'on veut être à la mode) et qui comprend le PHP pour extraire ses variables afin de les faire remonter dans ses .tpl.php si l'on parle de Drupal 7 ou dans les .html.twig si l'on parle de Drupal 8. Sa compétence première c'est l'intégration et le développement n'est pas sa priorité mais elle y porte un intérêt relatif pour comprendre ce qu'il est possible de faire. En cas de besoin, l'équipe aide cette personne à faire ce dont elle a besoin côté PHP.

Table avec des éléments créatifs éparpillés

Profil 2 : le développeur

Le vrai développeur est celui qui va s'appuyer sur les mécanismes d'extensibilité de Drupal pour créer des nouvelles briques si besoin, faire le modèle de données de son projet, concevoir l'application et faire les choix d'architecture. Il va tordre Drupal pour créer les nouveaux modules et modifier les existants afin de faire en sorte que Drupal s'adapte aux demandes du client, on parle aussi souvent de l'écriture de glue code. C'est lui qui est impliqué sur les composants "bas niveau" du site et qui maîtrise les APIs de Drupal.

Photo d'un clavier

Profil 3 : le site builder

Compétence peu répandue, peut être spécifique aux agences Drupal. Le profil de site builder est un profil qui connait extrêmement bien les options avancées, voire cachées, des modules contribués. Il sait quel module utiliser pour quelle situation, il s'appuie sur le travail du développeur pour mettre en oeuvre les nouvelles options exposées par les développeurs. Son arme principale : sa souris. Il clic à tout va à travers les nombreux écrans de Drupal. Si le développeur n'est pas disponible, il finira très souvent par trouver un module qui fait 80% de la fonctionnalité demandée.

Tour Jenga en gros plan

La complémentarité de ces trois profils vous donne une équipe technique robuste et capable de faire efficacement des sites avec Drupal. Hormis le développeur, les deux autres profils cités sont nécessaires et recherchés, n'ayez pas peur de vous revendiquer comme l'un d'entre eux si tel est le cas, vous vous ouvrirez certainement des portes. Beaucoup de personnes rentrent dans le monde de Drupal par le monde du site building (pour ne plus en sortir, rire machiavélique).

Et l'expert Drupal dans tout ça ?

Beaucoup de "développeurs Drupal" que l'on rencontre sont des personnes qui écrivent le glue code mais qui ne vont guère au-delà sans avoir trifouillé les entrailles de Drupal. C'est pour cela que le titre de "développeur drupal" paraît toujours ambitieux lorsque l'on creuse un peu plus. Concernant le titre d'expert Drupal, là... 

Que les choses soient claires, un expert, c'est quelqu'un qui maîtrise son sujet. S'il n'a pas une connaissance avancée du fonctionnement du coeur, de la gestion des performances et de la montée en charge, de comment faire un site multilingue, des mécanismes d'extensibilité, de l'inter-connexion avec des systèmes tiers, d'un peu de sécurité et qu'il n'a pas mélangé cela au cours de plusieurs dizaines de projets. Je pense que le titre d'expert Drupal est usurpé. L'Expert Drupal n'est pas un titre que l'on attribue à celui qui a le plus de projets dans les pattes et qui existe obligatoirement dans une société. Il est tout à fait possible que vous n'en ayez pas à la maison et par respect pour le poste, vous feriez mieux d'en avoir conscience. Si tout le monde s'autoproclame expert, qui l'est vraiment ? Et comment les clients peuvent-ils faire le tri ? Les certifications sont une piste de réponse possible. En attendant, essayons tous d'appeler un chat, un chat.

Commentaires

[#] elv (non vérifié) • mer 09/11/2016 - 11:53

Ma longue expérience de thémeur (expert, donc ;) m'a conduit à considérer le site-builder comme un danger dans un projet Drupal. Ce que j'entends trop souvent c'est…
— Site-builders : Bon on a fait 90% du job en configurant et assemblant des modules, reste l'aspect visuel. Ça devrait pas être long, c'est "juste du theming™".
— Thémeur : T_T

Le problème c'est que l'assemblage de modules aboutit à un code html/css hétéroclite, chaque morceau est conçu différemment, et il devient extrêmement difficile d'obtenir un résultat homogène et conforme aux attentes. Cela demande beaucoup de travail en plus, et les 10% restant qui étaient en réalité déjà plus proches de 50%, se transforment en 162% à cause de ce site-building à la truelle.
Exemple tout récent, un header site-buildé avec des menus, champs de recherche, module de réseaux sociaux, blocs personnalisés et sélecteur de langue ; qui a nécessité de surcharger au bas mot 25 templates twig pour respecter les maquettes. Un header custom avec markup sur mesure aurait demandé 3 fois moins de travail et serait plus simple à maintenir.

Souvent le développeur va justement mettre le holà et faire du custom quand cela se justifie, mais dans le monde des agences la possibilité apparente de pouvoir sauter une étape et se passer d'un poste coûteux est trop tentante.

Je verrais bien un diction drupalien :
« Mieux vaut un module custom bien pensés, que combiner une pelletée de contribués. »

[#] dom18fr (non vérifié) • mer 09/11/2016 - 17:02

C'est le genre de scénario qui peuvent être évités en s'assurant qu'un développeur experimenté, pour ne pas dire un expert "drive" le site building. En effet le choix des modules contrib utilisés doit se faire de manière éclairé. La communauté Drupal est riche de module contrib, c'est une très bonne chose, mais en dépit des efforts faits pour assurer la cohérence, la qualité et l'interopérabilité des modules entre eux, certains ne devraient pas être utilisés dans certains cas. Il ne suffit pas qu'un module fasse a peu près ce que l'on veut pour en faire un bon choix. Certains modules réinventent un peu la roue ou à l'inverse bypass ou appauvrissent des éléments de flexibilité présents dans les fonctionnement natifs du core.
En choisissant bien les modules, on peut avoir des assemblages même de nombreux modules, qui restent très cohérents parce qu'ils s'appuient tous sur des mécanismes bas niveau du core.

En réponse à par elv (non vérifié)

[#] Artusamak • mer 09/11/2016 - 12:06

C'est là qu'il devient important d'un point de vue pilotage de regarder les choses dans leur ensemble. Comme tu le dis, si on passe 1,2 fois plus de temps à faire du contrib auquel il faut ajouter le théming par dessus, pourquoi continuer dans ce sens ?

Le vécu d'une équipe doit permettre d'identifier ces cas d'usage et de faire opter pour du custom sur ton exemple d'en-tête la fois suivante ou de remonter la chaîne pour discuter aussi avec le DA en lui disant pour la prochaine fois voilà les contraintes à respecter pour que tout le monde gagne du temps. C'est une question d'intelligence collective.

Si pour chaque projet, l'équipe est différente et on repart de zéro en terme de connaissance globale, il y a clairement un raté. D'où l'importance de faire parler les métiers entre eux et de transmettre un savoir collectif d'une mission à une autre.

[#] GaëlG (non vérifié) • mer 14/12/2016 - 10:53

Pour éviter les problèmes du type "trop de contrib" ou "trop de custom", il faut peut-être dégager un quatrième "métier", ce que dom18fr appelle le "développeur expérimenté qui drive le site building".
Pour moi, ce n'est ni du développement même si ça nécessite de bien connaître le développement, ni du site building même si ça nécessite de bien connaître le site building. C'est un travail technique mais de conception, pas de production. On peut l'appeler "architecte". Il y avait un article dans Drupal Watchdog qui parlait aussi de "content strategist" : ça décrit bien l'une des problématiques centrales de ce métier mais ce n'est pas la seule.
Bien sûr, un architecte a probablement été et est parfois encore site builder et développeur. C'est peut-être ce profil qui se rapproche le plus de "l'expert Drupal" décrit à la fin du post.

Ajouter un commentaire

Restricted HTML

  • Balises HTML autorisées : <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
  • Les adresses de pages web et les adresses courriel se transforment en liens automatiquement.
By submitting this form, you accept the Mollom privacy policy.