Le Maine Libre sur Drupal

La documentation Drupal 6 n'est plus maintenue et en cours de dépublication.

Le Maine Libre est un journal Sarthois avec une diffusion quotidienne de 47.688 exemplaires en semaine et 25 473 exemplaires le dimanche. Il est composé de 3 éditions locales. Sa rédaction principale se trouve au Mans et il possède un réseau de 8 Rédactions locales : La Flèche, Sablé-sur-Sarthe, La Ferté-Bernard, Château-du-Loir, Coulaines, Mamers, Arnage et Écommoy.

Premier site Internet

Nous avons créé le premier site web http://www.lemainelibre.fr en mars 2010. Pour son développement, nous avons utilisé une refonte d’un framework maison développé par une société sœur du groupe Ouest-France, Ouest-France Multimédia.

Notre framework maison ressemble de façon très modeste à Zend Framework, Framework dont il utilise d’ailleurs plusieurs fonctions. Le temps de développement du site a été assez important, nous avons passé 9 mois à 2 développeurs pour sortir la première ébauche du site et nous avons depuis, effectué une maintenance corrective et adaptative pour continuer à faire vivre le site. Cette évaluation ne tient pas compte du travail de studio.

Nouveau CMS

En décembre 2010, OF Multimédia a arrêté la maintenance de son framework et nous étions confrontés alors à 3 alternatives :
Reprendre ce framework et continuer à le maintenir et à le faire évoluer
Utiliser un framework standard tel que Zend et/ou symfony
Utiliser un CMS

Nous avons sollicité la société Smile pour nous aider à définir la meilleure solution à notre besoin et très vite, il est apparu que 2 CMS pouvaient répondre :
EzPublish
Drupal

Nous avons fait le choix de Drupal pour plusieurs raisons :
La politique moins « open source” de EzPublish nous a fait poser quelques questions
Le nombre de référence de site similaire au nôtre et tournant actuellement sur Drupal
La richesse et la réactivité de la communauté, son catalogue de Module, la documentation existante (livres, forums…)
La simplicité de mise en œuvre que nous avions déjà pu entrevoir

Ce choix était important parce que notre besoin n’est pas uniquement de basculer le site du Maine Libre mais surtout de se servir de ce CMS pour revoir l’ensemble de nos sites éditoriaux, http://www.courrierdelouest.fr http://www.presseocean.fr et http://www.ouest-france.fr

Nous avons également comme objectif clairement défini de pouvoir mettre en place rapidement des « petits sites” sur des opérations ponctuelles (élections, tour de France, 24 heures du Mans, Festival de l’été). Il faut que la mise en œuvre d’un nouveau site soit la plus simple possible.

Le site actuel du Maine Libre se situe en moyenne entre 6000 et 8000 visites par jour.

Mise en place de l’équipe projet

Le projet Maine Libre sur Drupal a clairement été pour nous une opération laboratoire du point de vue technique mais également du point de vue organisationnel. Nous avons créé une équipe pluridisciplinaire entièrement dédiée au projet. Nous avons également fait appel à la société Linagora pour la définition de l’architecture technique, pour la problématique de gestion du cache et également pour un transfert de compétence sur les bonnes pratiques de développement Drupal.

L’équipe était composée de :
Pour la partie environnement technique nous avions 2 ingénieurs système : Cyrille Le Haies et Sébastien Messager.
Développement et paramétrage Drupal : jacques Pressigout, Florent Hasbroucq et Moez Dhoubi.
Régis Bayer du studio pour la partie graphisme et intégration du thème Drupal.

Et enfin moi-même, Olivier Lemoigne pour la Gestion de projet

Infrastructure technique et logicielle
Nous avons fait le choix d’une distribution Pressflow 6.22 pour un objectif de performance. Autrement, le reste de la suite logiciel est classique :
Serveur Apache 2.2
Base Mysql 5.1
PHP 5.2.17

Pour utiliser le moteur de recherche solr, nous avons installé un serveur Tomcat 6.

Pour alimenter en données le site du Maine Libre, nous nous appuyons sur différents contenus :
Articles, sondage, galeries photos, dossiers uniquement créé pour le web
Articles et photos du papier envoyé vers le web
Flux d’information AFP
Flux d’information météo, les unes en PDF, les affichettes

En complément de ce contenu stocké dans la base de données Drupal, nous avons également d’autres contenus affichés sur le site comme le cinéma et les événements loisirs mais ce contenu est accessible via des webservices, il ne fait pas physiquement parti du contenu du site.

Taxonomie
Avec 6 mois d’expérience sur Drupal, j’ai compris que l’élément essentiel, structurant, sur lequel il ne faut pas se louper dès le départ, c’est la taxonomie. C’est la taxonomie qui va permettre de structurer le site.

Nous avons défini 4 vocabulaires :
Destinations : c’est la taxonomie qui va nous servir à organiser les pages de notre site. Elle correspond aux différentes entrées du menu principal. (Les différentes locales, Le Mans FC, Loisirs,…). Cette taxo est obligatoire pour les articles et les galeries photos, on peut en choisir plusieurs (si je décide par exemple de publier mon article en page sport et en page Le Mans).
Localisation : communes, département, régions et pays. Obligatoire pour les articles et les galeries photo. C’est le lieu où se passe l’information. C’est sur cette taxo que notre régie publicitaire va s’appuyer pour commercialiser de la publicité.
Rubrique : c’est le « de quoi ça parle” de l’article.
Sujet : taxo facultative, laissé à la discrétion du webmaster pour lui permettre de regrouper des articles sur le même sujet.

Type de contenu

Très classiquement, nous avons utilisé CCK et tous ses dérivés pour définir nos différents types de contenu :
Article
Article reprise (type d’article particulier pour reprendre l’existant)
Dossier (type book, pour agréger des nodes sur un sujet commun)
Galerie Photo
La une (la une en PDF du journal)
Quizz
Sondage
Article AFP
Jeux

Détail du type de contenu article

L’article est le contenu essentiel d’un site d’information. Un article est composé d’un titre, d’un texte, d’une ou plusieurs photos, d’une ou plusieurs vidéos, d’un ou plusieurs liens. Les différents modules nécessaires à la gestion d’un article sont les suivants :
CCK obligatoirement. On comprend son intégration dans Drupal 7.
abuse : le « signaler un abus” dans les commentaires
addthis : barre de partage média sociaux
Better format : permet de choisir très précisément l’éditeur de texte suivant le profil et suivant le type de contenu. En clair nous avions besoin d’un éditeur wysiwyg pour les rédacteurs et juste d’un textarea pour les internautes pour déposer des commentaires.
Feedburner : pour utiliser les services de FeedBurner pour suivre les abonnements aux flux RSS
scheduler : certains articles sont programmés pour n’être publiés qu’à partir d’une certaine heure
ImageField Zip/HTML5 : nous avons eu beaucoup de souci pour trouver un moyen simple d’uploader plusieurs images en une seule action. Nous avons utilisé dans un premier temps le module FUpload mais il procède à l’importation des photos en 2 étapes : on sélectionne les photos, on enregistre l’article et ensuite on remplit les champs crédit et légendes des photos. Ce fonctionnement nous parait peu naturel, nous lui avons préféré ImageField qui répond bien au besoin, au bémol prêt qu’il ne fonctionne pas sur IE…
wysiwyg, wysiwyg spellchecker. Dans un premier temps nous avons utilisé wysiwyg en collaboration avec l’éditeur javascript ckeditor. Cela fonctionnait parfaitement sauf que nous n’avons pas trouvé de solution satisfaisant au niveau du correcteur orthographique. Nous avons ensuite basculé vers l’éditeur tinyMCE et en installant le module wyiwyg spellchecker, nous avons maintenant un correcteur relativement correct. Le module de correcteur est paramétrable et permet de choisir 3 moteurs de correction : google, aspell (open source) et pspell (extension PHP). Après avoir testé les 3, nous avons finalement constaté que google était finalement le plus efficace.
imagecache, imageAPIGD2 et imagecanvas actions pour retailler les photos, appliquer un watermark.
Embed inline Media pour embarquer des vidéos (code Embed ou url) dans un article

Pour afficher les articles sur notre site, le menu principal se base sur la taxonomie destination.

Pour d’autres pages et pour les blocs d’affichage nous avons utilisé le module views.
Nous utilisons le module Feature pour encapsuler le paramétrage de nos types de contenus et de nos vues pour ensuite exporter ce paramétrage sur l’environnement de production

Et pour finir, la construction des différents formulaires a été réalisé avec le module
webform.

backoffice
Dans notre ancienne architecture, les journalistes avaient accès à un backoffice développé en interne et un des points clés de notre bascule Drupal, a été la capacité à basculer sur le back-office Drupal sans douleur.

Après quelques semaines sur RootCandy comme thème d’administration, nous lui avons finalement préféré Seven, plus simple et plus clair.

Nous avons cependant été confrontés à un problème assez épineux de gestion de la sécurité entre nos différents utilisateurs :

un journaliste est affecté à une Rédaction et il ne doit voir, par défaut, que les articles publiés sur cette rédaction. Drupal est très complet pour gérer des droits sur des fonctionnalités entre différents profils utilisateurs mais il est très frustre dans la gestion des droits sur les données elle-même. Par exemple, je n’ai pas trouvé de module permettant de filtrer des termes de taxonomie suivant le profil de l’utilisateur.

Au final, nous avons créé notre propre module “Dashboard” qui permet d’associer dans la base de données le lien entre un journaliste et sa rédaction et ensuite, le lien entre cette rédaction et les termes de taxonomie « autorisée”.

Le second problème que nous avons rencontré concerne le module d’affichage par défaut du contenu

Par défaut il est vraiment sommaire, le module CMF est plus riche mais trop compliqué pour un utilisateur non aguerri ; Nous avons ajouté à notre dashboard, en fonction du profil du journaliste, son espace de travail complet.

Ce dahsboard permet à chaque journaliste, directement à partir de la une du site, de créer du contenu, gérer les commentaires et visualiser le contenu de son périmètre rédactionnel.

au final, le module content management filter et administration menu n’est utile qu’au webmaster et à notre équipe support

Moteur de recherche

Dans un souci de performance et de pertinence des recherches, nous utilisons le moteur solr couplé aux modules suivants
Apache Solr autocomplete
Apache solr framework
Apache solr node access
Apache solr search

Le moteur solr est vraiment très puissant mais on sent que pour profiter pleinement de ses possibilités, une vraie formation solr est à prévoir. Je suis notamment assez dubitatif sur les suggestions d’article que propose le bloc solr “sur le même sujet”.

Cache et performance
Le point crucial d’un site d’actualité est la gestion du cache. La sempiternelle question est comment jongler entre un site le plus statique possible pour que les pages soient le plus souvent en cache et la réactivité la plus immédiate en fonction de l’actualité.

Le point très positif de nos sites est que nous avons très peu de personne connectée et l’essentiel du trafic provient d’internaute anonyme.

Au niveau drupal, nous avons utilisé un memcache pour soulager la base de données drupal du contenu à conserver en cache.

Pour le front Internet, nous utilisons Varnish comme proxy avec les modules suivants
MemCache Admin
Cache expiration
Purge
Cookie cache bypass
path alias Cache

Nous avons opté pour un mode de cache « External” avec la règle suivante :
Par défaut, la durée de vie de nos pages en cache est de 3 h.
Quand une node est publiée sur le site web, l’url de cette node, les urls des taxonomies de cette node, la une si cette node est publiée sur la une sont envoyés au varnish pour lui signifier que ces urls sont maintenant obsolètes.

Au final nous avons 2 notions de cache :
Un cache implicite ou cache délai qui signifie que toutes les pages ont une durée de vie maximale de 3 h.
Un cache explicite qui permet au journaliste de mettre a jour les pages dans lequel apparaît l’article qu’il vient de publier.

De plus, nous avons défini un raccourci clavier qui permet au webmaster d’invalider une page directement à partir de son navigateur.

Nous avons eu quelques surprises avec notre système de cache lors de la mise en production et notamment sur le bloc sondage du jour. En effet, ce bloc était bien mis en cache ce qui signifiait qu’un seul internaute toutes les 3 heures pouvait participer au sondage.

Nous avons résolu ce problème en utilisant les modules
AJAX Block
Ajax Poll

Le sondage apparaît maintenant de façon asynchrone et interroge le serveur par une requête AJAX non cachée.

SEO et référencement

Notre framework précédent présentait de grosse lacune sur ce point et notamment sur la réécriture d’url. En utilisant le module pathauto nous avons maintenant une url réellement optimisée pour les moteurs de recherche et surtout unique et non modifiable. Ce module est un incontournable.

Conjointement, nous utilisons le module Global Redirect qui permet de recherche l’alias d’un node et renvoie toujours l’alias au lien du node.

Pour finir au niveau du SEO, nous utilisons le module XML Sitemap pour proposer un sitemap automatique à Google.

Pour le suivi de nos pages, nous utilisons le module Google Analytics et nous avons développé notre propre module Xiti ;

Exploitation courante du site

Quelques modules bien utiles pour faciliter les tâches de maintenance.
backup and migrate : nous avons programmé un backup quotidien de la base. Ce module nous a également permi d’initialiser les environnements de production à partir de l’environnement de qualification en procédant à un backup/restore.
db maintenance : ce module exécute régulièrement des taches d’update statistics sur la base de données
Elysia Cron : Par défaut, le crontab de notre serveur Unix exécute le cron Drupal toutes les 2 minutes. Vous n’avez pas forcément besoin toutes les 2 minutes de recalculer votre sitemap ! ce module permet de régler plus finement la périodicité des différentes tâches exécutées par le cron Drupal

Et pour finir, quelques modules bien utiles
Login Toboggan pour permettre à l’internaute de se connecter soit par son email, soit par son nom.
IE optimizer : nous avons beaucoup de fichier CSS et IE n’arrivait pas à tout importer. Ce module permet le compactage des CSS en un seul fichier.
Migrate : Pour importer des données dans les tables de la taxonomie et dans les nodes articles, dans un premier temps, nous avons utilisé node import. C’est graphique, c’est simple mais c’est très, très lent. Migrate est un peu plus long à comprendre et à configurer mais ensuite c’est le grand bonheur. Par contre, toujours importer au préalable ses données dans une table de la base, je n’ai pas réussi à faire fonctionner migrate à partir d’un fichier texte
Features et Features extra ; pour exporter/importer du paramétrage des environnements de développement vers la production.
MimeMail : pour l’envoi de courriel au format HTML
Localisation update : pour mettre à jour automatique les traductions des modules

Nos développements spécifiques
Au final, nous aurons développer 3 sortes de modules :
des modules Features pour encapsuler du paramétrage de type de contenu et de vues. Ce n’est pas vraiment du développement, c’est plutôt du « packaging”.
Des modules pour customiser le backoffice de drupal pour faciliter le travail de nos journalistes
Des modules sur des fonctionnalités liées à notre métier.

Au final, si on reste sur cette dernière catégorie de module, nous n’avons pas eu tellement de développement :
Un bloc Agenda qui présente différentes données métiers dans une carte google et sous forme de liste
Un module pour importer les articles de notre outil print vers drupal
un bloc article les plus lus qui se base sur les statistiques Google Analytics au lieu du bloc Drupal par défaut qui se base sur les statistiques Drupal.
un module pour gérer notre publicité OAS AdServer
un module de jeux de tirage
un module dahsboard pour offrir à nos journalistes un tableau de bord unique pour créer/modifier du contenu
un module pour présenter la météo suivant la page locale
un module cinéma qui présente les films et les salles du département
un module affichette et Une PDF pour importer ces contenus externes dans la base
un module Xiti pour enregistrer nos statistiques d’audience

Au final nos impressions sur Drupal ?

Si on réalise un site « classique” avec les fonctionnalités standards d’un site d’actualité, la boîte à outils drupal doit permettre de répondre à la plupart des besoins.

Le développement ne concerne que l’optimisation du backoffice et la création de fonctionnalité vraiment propre à son domaine d’activité.

Nous avons passé beaucoup de temps pour intégrer le site Drupal aux systèmes d’information existant, il n’est pas toujours très facile de faire communiquer Drupal en direct avec des bases externes. A refaire, nous utiliserions beaucoup plus le module migrate que nous avons découvert très tard.

Et la suite ?

Nous allons essayer maintenant de poursuivre dans la réactivité et la multiplication de sites dédiés à un événement, à une actualité particulière. Dans ce type de site le développement sera réduit à son minimum alors que par contre le travail de studio et d’intégration graphique risque d’être assez élevé.

Nous allons également travaillé pour avoir une procédure de création automatique de site « a minima” avec des fonctionnalités de base. Je n’ai pas encore trouvé la meilleure solution pour ce « kit de démarrage”, drush, fichier profile, backup de base de données…

Version de Drupal : 

Commentaires