[replay] – No Code Loves Culture #5 : gérer la répartition des réservations de vos groupes… facilement

Le « No code » ? Tout est dans le titre : il s’agit de créer et de déployer des logiciels sans écrire de code informatique, grâce à l’utilisation de plateformes de développement.

Pour ce live « No Code Love Culture » du 23 mai 2025, nous avons créé une application de gestion des réservations des groupes. Ce live a été imaginé à partir d’un besoin exprimé par l’équipe du Bateau feu, scène nationale de Dunkerque.

Replay

Cadre du projet

Elsa Lanthier, chargée des relations avec les publics au Bateau Feu scène nationale de Dunkerque nous a décrit l’outil actuellement utilisé pour gérer les réservations de groupe : un tableau Excel simple. Cet outil sert à rentrer toutes les réservations de groupe dès septembre et à gérer leur avancement tout au long de la saison (rentrée en billetterie, réglée). Le tableau contient les spectacles, la répartition de la jauge par secteur (groupes globaux, scolaire, social et médico-social), les champs classiques de réservation, un système de filtre et un code couleur pour le suivi avec la billetterie.

Le processus implique la réception de fiches de réservation manuelles (souvent durant l’été et en septembre). Ces fiches sont triées et les réservations sont rentrées manuellement dans le grand tableau Excel. La validation des choix se fait fin septembre/début octobre.

Le principal point de friction ou « partie la plus fun » est la phase d’arbitrage qui a lieu en septembre. Pendant l’arbitrage, l’équipe (composée de trois personnes se partageant les secteurs scolaire et social/médico-social) répartit au mieux les groupes. Après avoir rentré tous les vœux initiaux, ils arbitrent pour résoudre les conflits sur certaines propositions, notamment au niveau des jauges. L’arbitrage n’est pas fait par ordre d’arrivée, mais dans un souci de justice pour que chaque structure obtienne au moins un vœu.

Les problèmes rencontrés avec l’outil Excel actuel durant cette phase d’arbitrage sont multiples :

• L’outil n’est pas très visuel et pas très pratique.
• Cela nécessite de jongler entre les fiches de réservation papier annotées et le tableau Excel.
• Quand une réservation pose problème sur une représentation (par exemple, si un groupe est flexible sur la date mais que la jauge coince), il faut déplacer ce groupe sur d’autres représentations, ce qui crée un « grand bazar ».
• Il est nécessaire de pouvoir déplacer les réservations (d’une représentation à une autre si le quota coince).
• Il est crucial de toujours garder le vœu initial en mémoire pour ne pas l’oublier ou le perdre en cours de route.
• Il faut pouvoir revenir en arrière si une nouvelle proposition ne convient pas au groupe.
• Il est souhaité de visualiser le nombre de réservations accordées à un groupe/établissement : celles qui étaient des vœux initiaux, et celles qui ont été accordées mais déplacées.
• Un outil plus visuel et plus ergonomique pour la gestion de l’arbitrage est l’idéal.

Deux conditions importantes sont posées par Elsa pour la solution :

• Les réservations doivent toujours être rentrées manuellement.
• L’arbitrage ne doit pas être automatisé, car il dépend de la connaissance des groupes et de la saison.

Solution proposée

Face à ce besoin partagé par de nombreuses structures culturelles (avec des problèmes de temps, d’allers-retours et de risques d’erreurs), nous avons cadré le projet pour répondre spécifiquement aux points de friction exprimés par Elsa. Le principe des lives « No-code loves culture » est justement de développer et présenter des solutions no-code pour des besoins spécifiques de structures culturelles, en cadrant ce qui est réalisable.

Le cadrage du projet pour cet outil d’arbitrage des réservations groupe s’est articulé autour des points suivants, en se basant uniquement sur le besoin exprimé :

• Identifier les représentations où « ça coince » (où il y a des problèmes de jauge par secteur).
• Identifier les réservations à conserver et celles qui peuvent être substituées en fonction de différents critères, notamment par rapport aux vœux initiaux et aux contraintes particulières des groupes.
• Offrir la possibilité de tester des options alternatives et de faire des allers-retours. Il est impératif de ne jamais perdre l’historique et surtout de ne jamais perdre le vœu initial.
• Visualiser les différents critères lors de la proposition d’alternatives : contraintes de la structure (contingents), contraintes du spectacle (accessibilité, âge), contraintes des groupes/établissements (âge des publics, publics spécifiques).
• Avoir la possibilité de partager ces propositions (aux relais, en interne) et d’assurer un suivi.

Présentation de l’application développée sur Airtable

La solution développée s’appuie sur Airtable, présenté comme un outil de gestion de base de données relationnelles en ligne. Il combine l’aspect tableur (lignes, colonnes, calculs) avec la puissance des relations de base de données et des interfaces visuelles. Bien qu’il y ait une version gratuite, la complexité et le volume de données requis pour ce projet nécessitent un compte payant (~20€/mois).

Le choix d’Airtable se justifie par sa facilité de prise en main (proche d’Excel pour les tables), ses possibilités d’automatisation visuelles, et surtout la capacité de créer des interfaces visuelles pour visualiser données, alertes et couleurs, permettant de manipuler les informations autrement qu’en simple tableur.

La conception de la solution repose sur une structure de données relationnelle composée de plusieurs tables liées entre elles :

• Spectacles : Informations sur les œuvres, critères (accessibilité, âge, niveau), valeurs de contingent.
• Représentations : Liées aux spectacles, listant les différentes dates, intégrant des champs de formule pour des calculs et des visualisations d’alerte (pastilles de couleur) pour identifier les problèmes de remplissage des contingents (scolaire, médico-social).
• Réservations : Le « cœur du réacteur », liant représentations, établissements et groupes. Chaque réservation contient des informations comme le nom du groupe, l’effectif, le secteur, mais surtout l’indication si c’est un vœu initial. Elle enregistre également des actions (substituer, verrouiller, abandonner) et des états (en cours, en attente, validée, transmise en billetterie, substituée, abandonnée). La table est liée à elle-même pour conserver l’historique et permettre de revenir en arrière.

L’outil répond aux besoins exprimés grâce à ces fonctionnalités :

• L’identification des problèmes est rendue très visuelle grâce aux alertes (pastilles de couleur) au niveau des représentations, montrant où les contingents sont dépassés.
• Les interfaces visuelles permettent de naviguer par spectacle, puis de voir les représentations avec leurs alertes et la liste des réservations associées, facilitant l’arbitrage.
• Les actions (substituer, abandonner) et les automatisations associées permettent de tester des options alternatives. Substituer une réservation crée une nouvelle entrée (la proposition alternative) tout en marquant l’originale comme substituée, conservant l’historique. Abandonner une réservation permet de revenir à l’état précédent.
• Le champ « vœu initial » est central et géré par le système pour ne jamais perdre cette information. Une réservation marquée comme vœu initial ne peut pas être abandonnée pour revenir en arrière (car c’est le point de départ).
• La structure des données permet de visualiser les critères (âge, niveau, places disponibles) lors de la recherche d’une représentation alternative pour un groupe déplacé.
• La possibilité d’avoir différentes vues (« onglets ») filtrées par l’état de la réservation permet de suivre l’avancement du traitement (validées, en attente, à pourvoir, etc.). Ces vues peuvent être personnalisées.
• Les effectifs des groupes peuvent être ajustés dans les réservations, et l’outil calcule automatiquement l’impact sur les jauges des représentations.

Concernant les conditions spécifiques du Bateau feu :

• L’outil est conçu pour que la saisie initiale reste manuelle, respectant ainsi le besoin du Bateaufeu.
• L’arbitrage lui-même n’est pas automatisé. L’outil facilite le processus en offrant visualisation et manipulation, mais les décisions de déplacement ou de substitution sont prises manuellement par l’équipe, conservant ainsi la connaissance métier et l’approche non-IA souhaitée.

La solution permet également des fonctionnalités de collaboration (commentaires, historique), d’export (CSV pour la billetterie, PDF en imprimant), et la structure de données permet d’envisager la création de tableaux de bord et de statistiques (reporting sur les effectifs, les états de réservation, etc.), bien que cela n’ait pas été intégré initialement car non demandé.

À propos des lives « No code loves culture »

Ces lives sont des rendez-vous en ligne qui explorent les possibilités offertes par le no-code avec un focus sur le secteur culturel. Lors de ces live on explore les outils no-code avec un processus de « build in public » où l’application est construite en direct avec des commentaires et des explications.

Ces lives sont des rendez-vous en ligne qui explorent les possibilités offertes par le no-code avec un focus sur le secteur culturel. Lors de ces live on explore les outils no-code avec un processus de « build in public » où l’application est construite en direct avec des commentaires et des explications.

Ces lives sont des rendez-vous en ligne qui explorent les possibilités offertes par le no-code avec un focus sur le secteur culturel. Lors de ces live on explore les outils no-code avec un processus de « build in public » où l’application est construite en direct avec des commentaires et des explications.

Vous êtes invité.e à exprimer vos idées, problématiques, projets… Ils pourraient bien être le sujet d’un de nos prochains live !

Contactez-nous pour en savoir plus sur le no-code et/ou pour aborder un sujet en lien avec votre structure lors d’un prochain live.