Un système de gestion d’événements évolutif pour le Museum für Gestaltung

Chez Liip, nous accompagnons régulièrement des client·e·s aux besoins complexes en matière de gestion de contenu. Un exemple récent est la réalisation du nouveau site web du Museum für Gestaltung de Zurich, le principal musée suisse du design, reconnu pour la richesse et la diversité de son programme public. L’un des points centraux du projet était la mise en place d’un système de gestion d’événements à la fois flexible et puissant, capable de répondre à une grande variété de formats et d’exigences.

Comprendre les besoins

En plus de ses expositions permanentes et temporaires, le Museum für Gestaltung Zurich propose un large éventail d’événements: visites guidées, sorties scolaires, ateliers de plusieurs jours, mais aussi concerts ou projections ponctuelles. Ces activités se déroulent sur trois sites différents et s’adressent à des publics variés : visiteur·euse·s individuel·le·s, familles, groupes d’ami·e·s ou classes scolaires. Certains événements sont gratuits, d’autres requièrent une inscription payante, et beaucoup sont proposés en plusieurs langues.

Pour gérer cette diversité, le musée avait besoin d’un système capable de prendre en charge:

• des événements récurrents avec des plannings complexes
• des durées très variables (de la visite de deux heures à l’atelier de plusieurs jours)
• plusieurs lieux en parallèle
• la segmentation et le ciblage précis des publics
• la définition de limites de participant·e·s (minimum et maximum)
• une communication automatisée avec les visiteur·euse·s (par exemple, des rappels)

En résumé, il ne s’agissait pas seulement d’afficher une liste d’événements et un calendrier, mais de concevoir un véritable système de gestion événementielle, à la fois flexible et évolutif.

Évaluer les solutions Drupal

Avec Drupal, la devise est «il y a un module pour ça». Avec plus de 53 000 modules disponibles, il était logique de commencer par là.
Après avoir étudié plusieurs options, nous avons identifié le module Recurring Events comme point de départ le plus intéressant.

Pourquoi Recurring Events?

Avantages:

• C’est le module le plus complet pour gérer des événements dans Drupal.
• Il propose par défaut une riche palette de fonctionnalités, qui dans certains cas dépassaient même nos besoins.

Inconvénients:

• L’ensemble des exigences du musée n’était pas couvert.
• Certaines fonctionnalités existantes ne correspondaient pas aux cas d’usage et devaient être adaptées.

Identifier les lacunes

Le module Recurring Events répondait déjà à une partie de nos besoins, mais pas à tous. C’est une difficulté fréquente en développement logiciel : les solutions existantes couvrent souvent une grande partie du chemin, mais rarement l’ensemble des exigences spécifiques.

Pour le Museum für Gestaltung, plusieurs fonctionnalités essentielles manquaient encore :

Gestion multilingue

Au-delà des trois langues nationales, le musée propose régulièrement des événements en anglais pour les visiteur·euse·s internationaux·ales. Il était donc indispensable que le contenu et les processus d’inscription soient entièrement gérables en plusieurs langues.

Inscriptions de groupe

la majorité des visites s’effectue en groupe (familles, ami·e·s, classes ou groupes guidés). Le système devait permettre l’inscription d’un groupe entier, et basculer automatiquement sur liste d’attente si la capacité restante était insuffisante.

Capacité par défaut selon le type d’événement

certains formats, comme les visites guidées, reviennent fréquemment avec une capacité fixe. Pouvoir définir une valeur standard aurait simplifié la saisie et réduit le risque d’erreurs.

Dates d’événement verrouillées

Une fois un événement publié et visible, ses dates ne devaient plus pouvoir être modifiées ou supprimées. Cette restriction garantissait la clarté et évitait toute confusion pour le public.

Communication par e-mail adaptée

Selon le type d’inscription (groupe privé ou classe scolaire), différentes équipes étaient responsables du suivi. Le système devait donc permettre l’utilisation de modèles d’e-mails distincts pour assurer une communication cohérente et ciblée.

Choisir la bonne approche

Une fois les besoins clairement définis, restait à répondre à une question centrale: fallait-il développer une solution entièrement sur mesure, ou bien étendre l’existant ?

Après analyse, quatre pistes se sont dégagées :

Option 1: Développer une solution custom

Cela nous donnerait un contrôle et une flexibilité totale.

Avantages:

• Une solution parfaitement adaptée aux besoins du musée, sans aucun compromis.

Inconvénients:

• Un coût initial élevé.
• Risque de réinventer des fonctionnalités déjà couvertes par des modules existants.

Option 2: Forker le module Recurring Events

Il s'agit d'une approche pragmatique, en particulier à court terme, mais difficile à maintenir à long terme.

Avantages:

• Possibilité d’adapter le module à l’ensemble des besoins spécifiques.
• Mise en œuvre rapide au départ.

Inconvénients:

• Charge de maintenance importante à long terme.
• Risques de conflits avec les futures évolutions du module.
• Les améliorations resteraient internes et ne bénéficieraient pas à la communauté.

Option 3: Étendre le module avec du code custom

Utilisez le module tel quel et développez les fonctionnalités manquantes à l'aide des API Drupal, qui sont conçues pour adapter les fonctionnalités existantes aux besoins spécifiques d'un projet.

Avantages:

• Réutilisation des fonctionnalités existantes.
• Séparation claire entre le code communautaire et la logique spécifique au projet.

Inconvénients:

• Maintenance continue nécessaire pour le code custom.
• Risques de conflits si le module évolue.
• Les ajouts pourraient être utiles à d’autres, mais resteraient isolés.

Option 4: Contribuer directement au module Recurring Events

Collaborez avec les responsables de la maintenance du module afin d'intégrer directement les nouvelles fonctionnalités dans le module.

Avantages:

• Alignement avec la philosophie open source de Drupal.
• Compatibilité et support communautaire assurés sur le long terme.
• Relecture et amélioration des fonctionnalités par d’autres développeur·euse·s expérimenté·e·s.
• Réduction de la maintenance pour notre équipe à terme.

Inconvénients:

• Exigences élevées en matière de qualité de code et de documentation.
• Risque que certaines contributions soient refusées ou prennent du temps à être validées.
• Nécessité d’une coordination et d’une communication accrues pendant le développement.

Une collaboration réussie

Nous avons finalement retenu l’option 4: collaborer étroitement avec les mainteneur·euse·s du module Recurring Events afin d’y intégrer les fonctionnalités manquantes. Pendant plusieurs mois, nous avons participé activement à l’issue queue, contribué du code, relu des patches et affiné des solutions en dialogue constant avec la communauté. Cette collaboration a conduit à l’intégration de l’un·e de nos développeur·euse·s comme co-mainteneur·euse officiel·le du module.
Le résultat est un véritable succès: nous avons livré un système de gestion d’événements puissant, flexible et parfaitement adapté aux besoins du musée, tout en restant fidèle aux principes de l’open source. Plusieurs de nos contributions font désormais partie des dernières versions du module, et d’autres améliorations sont déjà en cours de développement.
Chez Liip, nous croyons fermement qu’il ne suffit pas d’utiliser des outils: il faut aussi les renforcer et les partager. Nous le faisons non seulement pour nos client·e·s, mais aussi pour l’ensemble de la communauté open source Drupal.
Si tu veux participer à l’amélioration de la gestion d’événements dans Drupal, rejoins la discussion avec nous dans l’issue queue du module Recurring Events.