Spécifier pour Drupal : méthode, plan, outils

Pourquoi spécifier pour Drupal ?

Drupal est un outil de gestion de contenu basé sur quelques principes importants :

• des contenus typés, constitués de champs,
• des taxonomies pour classer les contenus,
• des menus, a priori, dissociés des contenus,
• des utilisateurs ayant des rôles (ensembles de droits).

Cette apparente simplicité cache une infinité de manières d'implémenter un besoin fonctionnel. Pour s'en convaincre, il suffit de faire un tour sur la page listant les 14000 modules disponibles via la communauté.

Le choix de tel ou tel module peut avoir un très fort impact sur la maintenabilité du projet et sur son évolutivité. Par exemple, choisir Panels plutôt que le système de bloc "standard" donnera une plus grande souplesse mais induira des coûts supplémentaires liés à la complexité de la solution.

Spécifier pour Drupal consiste à avoir conscience de ces choix et en tenir compte dans la manière de spécifier le besoin.

Soit vous êtes un expert de Drupal, soit il faudra spécifier avec votre chef de projet technique à côté de vous. Et c'est là tout l'intérêt de la démarche : les spécifications sont l'occasion de valider la faisabilité au fur et à mesure et de réaliser des choix d''architecture partagés par tous.

La méthode

Contenus

A priori, à ce stade du projet vous disposez de wireframes ou de PSDs validés. L'objectif de l'étape de spécification est de les faire rentrer dans l'outil de la manière la plus standard possible. Il va donc falloir traduire des écrans en entités Drupal.

Hors, dans certains cas, un bloc sera géré avec un type de contenu dédié ordonné par une nodequeue, alors que dans d'autres cas, ce sera juste un asset remonté automatiquement par une vue. Vous ne voyez pas la différence ? Repartez à l'étape Je me familiarise avec Drupal !

En général, ce premier travail de traduction est fait avant les ateliers client, ces derniers permettant surtout d'affiner les règles de gestion.

Attention, cette étape est très importante. Car c'est à cette occasion que l'on commence à figer des principes d'architecture qui auront un fort impact sur le quotidien des contributeurs.

Nous détaillerons ce point dans un prochain article.

Services

Spécifier les services demande un travail préparatoire similaire mais souvent plus long car il faut tester plusieurs modules, prototyper, discuter avec l'équipe de développement afin de se faire une opinion sur la meilleure manière d'implémenter le service en respectant le Drupal way. Cette étape est, elle aussi, très importante.

Nous détaillerons ce point dans un prochain article.

Contribution

Enfin, des ateliers permettront de comprendre comment est organisé la contribution, comment sont répartis les principaux rôles, quelles sont les étapes de workflow...

La langue

Les projets Drupal étant souvent plus "gros" que la moyenne, le recours à des équipes en offshore / nearshore est fréquent. C'est pourquoi nous spécifions toujours en anglais afin de garantir la meilleure appropriation possible quelque soit la nationalité des développeurs.

C'est aussi un bon moyen de rester cohérent lors du paramétrage des noms machine, notamment des champs. En effet, beaucoup de préfixes du genre "field_" sont utilisés, ce qui donne vite du franglais comme, par exemple, field_dossiers_lies.

L'utilisation de l'anglais permet d'éviter ça.

Le plan

Nos spécifications orientées Drupal reprennent toujours les mêmes chapitres :

• Overview Sitemap,
• Content types,
• Assets,
• Field collections,
• Taxonomies,
• Nodequeues,
• Services,
• Templates,
• SEO / Social sharing / Analytics,
• Contribution,
• Technical architecture.

On peut aussi ajouter, selon les cas :

• Imports,
• Exports,
• ...

Ce plan sera détaillé dans les prochains articles.

En général, nous spécifions dans l'ordre du plan : d'abord les content types / asset / fiels collections / taxonomies, puis les templates / nodequeues, puis les services / templates et enfin les autres chapitres. Le chapitre contribution tient une place à part et fait souvent l'objet d'ateliers spécifiques une fois tout le reste spécifié.

Bien sur, si le projet est découpé en lots, la même démarche est répétée pour chaque lot.

Il arrivent que ce plan type ne soit pas adapté : cas de certains projets e-commerce ou de sites très créatifs. Dans ce cas, le plan des spécifications s'adapte aux particularités du projet. Mais c'est rare.

Les outils

Je suis un ardent défenseur de Microsoft Word. L'outil n'est pas sans défauts mais je n'ai pas encore trouvé mieux.

Ces principaux avantages dans le cadre des spécifications :

• Aide à figer le document (les spécifications évoluent mais certaines versions "figées" correspondent à des étapes plus ou moins contractuelles) ;
• Maintenable si les styles et les cross-references sont utilisés massivement.

Ces principaux inconvénients dans le cadre des spécifications :

• Les développeurs n'aiment pas Word ;
• Pas collaboratif (par rapport à Google Docs par exemple).

Les bonnes pratiques à respecter :

• Toujours utiliser le même plan et s'y tenir (cela facilite l'appropriation des autres acteurs après plusieurs projets) ;
• Utiliser massivement les styles automatiques ;
• Utiliser massivement les cross-references ;
• Optimiser les images (selon mon expérience, une spécification standard de 300 / 400 pages ne doit pas peser plus de 15 Mo).

La seule alternative, à part Open Office bien sûr, est Google Docs. Il apporte un mix intéressant de formats (Doc, Sheet, Presentation), est fortement collaboratif et simple à prendre en main.

Mais je n'ai jamais réussi à dépasser 30 à 50 pages sans que les temps de chargement soient pénalisant. Et du fait du découpage en plusieurs fichiers, on peut oublier les cross-references... ce qui n'aide pas à maintenir la cohérence d'ensemble...

La première chose à faire

La première chose à faire est de créer une structure dans Word. Cette structure reprend notre plan du site. Cette étape est importante car, lors de la rédaction des spécifications, nous allons créer des cross-references dans tous les sens. Commencer avec une structure vide mais listant toutes les entités Drupal manipulées nous fera gagner du temps.

Ressources

• Drupal.org