Depuis huit ans, France Télévisions a amorcé sa mue numérique en industrialisant son développement web. Plus de 300 sites étaient gérés sous autant d'implémentations du CMS Spip mais à chaque fois dans des versions très personnalisées, même au niveau de l'interface d'administration. « L'ensemble était devenu une véritable usine à gaz » s'est souvenu Léo Poiroux, chef de projet technique chez France Télévisions, qui témoignait sur la manifestation AgoraCMS le 15 mai 2013. Même le passage d'un service éditorial à un autre posait des problèmes aux journalistes qui devaient se reformer à l'outil et aux astuces mises en places dans telle ou telle implémentation (par exemple l'usage détourné d'un champ comme le chapeau pour mettre la mention d'un intervenant).

Un développement orienté métier

Pour optimiser l'exploitation des sites web, y compris événementiels et temporaires, mais aussi pour faciliter le travail quotidien des équipes éditoriales, France Télévisions a choisi de remplacer ses 300 implémentations de Spip par 3 usines à sites sous le CMS Drupal. Le processus de publication a ainsi pu être refondu pour le rendre plus fluide. « Nous nous sommes focalisés sur les processus métier en évitant de toujours réinventer la roue » a souligné Léo Poiroux.

L'équipe web a employé au maximum la méthode agile lorsqu'un développement s'avérait malgré tout nécessaire. Ces techniques associent en général les responsables métier et technique mais pas obligatoirement. Par exemple, la méthode Dojo, assez originale, consiste à placer plusieurs développeurs autour d'un seul PC muni d'un vidéoprojecteur à la place d'un écran. Chaque participant code durant quelques minutes avec les commentaires des autres participants puis cède sa place à un autre participant. Le but est de développer une fonctionnalité en une heure.

Les développements sont mutualisés

L'entreprise publique audiovisuelle ne créé donc désormais plus de modules que lorsque c'est strictement nécessaire, préférant récupérer des modules créés par la communauté mondiale Drupal, quitte à contribuer à leur évolution, bien entendu. Et lorsqu'une création de module s'avère nécessaire, ce développement est mutualisé entre tous les services. Léo Poiroux a pris pour exemple le cas du gestionnaire de cache pour les articles chauds, module développé par le service des sports mais récupéré ensuite par les autres services.

L'architecture a connu des périodes de tests de montées en charge dans des périodes de forte fréquentation, par exemple les jeux olympiques ou les soirées électorales. Et aucun incident n'a été à déplorer.

Le problème du cache face à l'interactivité

Ceci dit, l'absorption de la montée en charge se fait aussi par un recours massif aux CDN (Content Delivery Networks). Et les mises en cache des contenus gênent évidemment l'interactivité puisque les pages mises en cache sont par définition fixes. Un module développé en interne permet d'outrepasser la difficulté en dérivant la partie interactive vers des serveurs hors cache. A l'inverse, la génération de sites à partir de modèles dans l'usine à sites se déroule grâce au module communautaire Drush. Ce module permet de piloter Drupal en lignes de commande et de créer des procédures de type batch associant les commandes.