Application de gestion d'événement pour une collectivité

Une application de gestion d’événement, dans une collectivité, travaille pour les équipes plutôt que pour le public : elle confie chaque tâche de montage à une personne, suit le matériel municipal d’une manifestation à l’autre, prévient chaque équipe de ce qui la concerne et remonte les signalements du terrain. Elle doit tenir sans réseau et rester accessible aux agents.

Ni billetterie ni fil d’actualité : un outil pour les équipes

Les logiciels de gestion événementielle pensés pour les entreprises tournent autour du participant : inscription, paiement, badge, programme, mise en relation des invités. Une fête communale, un forum des associations ou une commémoration n’ont presque rien de tout cela. L’entrée est libre, personne ne s’inscrit, et la difficulté se situe en coulisses.

Trois traits séparent l’outil d’une commune de celui d’une agence événementielle :

• plusieurs statuts sur le même événement : agents des services techniques, chef d’équipe, élu de permanence, bénévoles du comité des fêtes, prestataire son ou chapiteau ;
• un matériel municipal qui circule toute la saison, des barrières au podium, et que deux manifestations de la même semaine se disputent parfois ;
• une organisation qui revient chaque année, sur les mêmes lieux, avec des équipes qui changent en partie.

Une application d’information des habitants publie l’agenda, les alertes et les actualités pour les administrés : elle parle vers l’extérieur. Dans la commune, l’application interne des agents distribue le travail, trace le matériel et fait remonter les problèmes. Les deux peuvent coexister sans partager ni les utilisateurs, ni les droits, ni les données. Un outil conçu pour annoncer le marché de Noël aux habitants ne sait pas dire qui a rapporté les tréteaux au centre technique.

Les fonctions d’une application de gestion d’événement le jour J

Le jour J, quatre fonctions font le gros du travail.

Une tâche, un nom, une échéance, un lieu

Une tâche confiée à « l’équipe technique » n’appartient à personne. Une tâche utile porte un nom, une heure limite et un emplacement sur le plan. Exemple : le podium de la place, à monter avant l’arrivée de la sonorisation. Le chef d’équipe l’attribue à un agent nommé, et le prestataire voit le statut passer à « terminé » sans passer un appel.

Le matériel partagé, suivi comme un stock

Groupe électrogène, grilles d’exposition, tentes pliantes, rallonges : le matériel mutualisé passe d’un événement à l’autre. L’application en tient l’inventaire avec trois informations par objet : où il se trouve, dans quel état, et qui l’a sorti. Le groupe électrogène prêté au vide-greniers du samedi doit revenir au centre technique pour le cross du dimanche ? La sortie au nom d’un agent, avec sa date de retour, évite les appels du dimanche matin. Un état « à réparer » avec photo évite de renvoyer une tente au mât tordu.

Des messages adressés à une équipe

Un message envoyé à tous les intervenants finit vite ignoré. L’outil raisonne par équipes : balisage, buvette, sécurité, accueil, technique. Quand le parcours de la course à pied doit être balisé sur une portion supplémentaire le long du stade, seuls l’équipe de balisage et les signaleurs du secteur reçoivent la consigne, portion repérée sur la carte. La logique rejoint celle du tri des notifications sur smartphone : une alerte qui ne demande rien à celui qui la reçoit affaiblit toutes les autres.

Un signalement avec photo et position

Face à l’imprévu, un formulaire de signalement court, quelques champs et une photo, horodaté et placé sur le plan, vaut mieux qu’un appel passé dans le bruit. Une grille d’avaloir manquante sur le parcours, un banc descellé dans la zone de restauration, une porte de secours encombrée dans la salle : chaque signalement part vers l’équipe compétente, change de statut quand quelqu’un le prend en charge, puis reste dans l’historique.

Ces quatre briques prennent leur vraie mesure quand elles s’enchaînent sur une manifestation complète, de la préparation au bilan. Pour les voir appliquées à la logistique des fêtes locales, des marchés et des commémorations d’une mairie, le guide dédié à l’application mobile pour collectivité passe en revue la planification des tâches, le suivi du matériel partagé, les alertes aux équipes, les formulaires de terrain et la mémoire que chaque édition laisse à la suivante.

Sur le terrain, ces fonctions réclament encore autre chose à l’outil : continuer de répondre quand le réseau faiblit, quand la batterie baisse et quand chaque intervenant arrive avec un téléphone différent.

Place, gymnase, bord de stade : les contraintes techniques

Les qualités d’un outil de terrain se jugent là où il sert : une place entourée de façades épaisses, un gymnase en béton, un bord de stade loin de toute antenne.

Travailler hors connexion

L’application enregistre chaque action sur le téléphone, puis l’envoie dès que le réseau revient. Une tâche cochée hors connexion reste cochée, et une photo de signalement attend dans une file d’envoi au lieu de se perdre. Deux détails comptent : un indicateur de dernière synchronisation, et des photos compressées pour ménager une connexion faible.

Trancher les conflits de synchronisation

Deux agents modifient la même tâche sans réseau : l’un la déclare terminée, l’autre y signale un problème. La règle « la dernière modification l’emporte » efface alors en silence l’une des deux informations. Préférez un historique des modifications avec leur auteur, et des contradictions soumises au chef d’équipe.

Tenir une journée sur batterie

Une fête dure du montage du matin au démontage du soir. D’après l’assistance Apple, le mode Économie d’énergie de l’iPhone désactive l’actualisation en arrière-plan ; selon l’aide Android de Google, l’économiseur de batterie limite ou désactive les activités en arrière-plan. L’application doit donc se synchroniser à l’ouverture et offrir un bouton de synchronisation manuelle.

Flotte de la commune ou téléphones personnels

Certains agents reçoivent un téléphone géré par la collectivité ; les bénévoles viennent avec le leur, de modèles très variés. Pour l’usage professionnel d’un appareil personnel, la CNIL recommande une « bulle de sécurité » qui cloisonne la partie professionnelle, et rappelle que l’employeur ne peut pas accéder aux éléments de vie privée de l’espace personnel. Un outil qui réclame les contacts ou la galerie photo d’un bénévole va à l’encontre de cette logique.

Qui voit quoi : rôles, droits et données personnelles

Tous les intervenants n’ont pas à voir les mêmes choses. Le découpage des droits d’accès suit en général cinq rôles :

• l’agent voit ses tâches, le matériel qu’il a sorti et le formulaire de signalement ;
• le chef d’équipe attribue, réattribue et valide le travail de son équipe ;
• l’élu de permanence dispose d’une vue d’ensemble et reçoit les signalements graves, sans toucher aux plannings ;
• le bénévole invité accède pour la journée à ses missions et au point de rendez-vous ;
• le prestataire voit sa zone, ses créneaux d’accès au site et son interlocuteur à la mairie.

Côté données, deux articles du RGPD guident les choix. L’article 5 exige des données « adéquates, pertinentes et limitées à ce qui est nécessaire » au regard de la finalité, conservées pendant une durée qui n’excède pas ce besoin. L’article 25 ajoute que, par défaut, seules les données nécessaires sont traitées, qu’il s’agisse de leur quantité, de leur durée de conservation ou du nombre de personnes qui y accèdent.

La CNIL précise que le responsable du traitement fixe la durée de conservation selon l’objectif poursuivi. Organisme public, la commune doit aussi désigner un délégué à la protection des données, au titre de l’article 37 du RGPD : son avis sur l’outil se recueille avant le premier événement, et le traitement entre au registre.

Reste la localisation : le signalement porte la position de l’incident, jamais celle de l’agent en continu. Dans sa fiche sur la géolocalisation des véhicules de salariés, la CNIL écarte le contrôle permanent d’un employé et la collecte hors du temps de travail.

Outil interne, obligation d’accessibilité quand même

L’article 47 de la loi du 11 février 2005 impose l’accessibilité des services de communication au public en ligne des personnes morales de droit public, et précise qu’elle concerne notamment les sites internet, les intranets, les extranets, les applications mobiles et les progiciels. L’outil des agents entre donc dans le champ, sauf charge disproportionnée, exception prévue par le texte.

Le même article prévoit une déclaration d’accessibilité et un schéma pluriannuel de trois ans au plus, décliné en plans d’actions annuels. Le contrôle repose sur le RGAA, publié par la direction interministérielle du numérique, aujourd’hui en version 4.1.2. Critères et publications sont détaillés dans notre article sur les règles d’accessibilité numérique d’une application.

Pour un outil de terrain, l’obligation d’accessibilité se traduit très concrètement :

• un statut de tâche lisible autrement que par la couleur, pour le chef d’équipe qui distingue mal le rouge du vert ;
• des zones tactiles assez larges pour un doigt ganté ;
• des boutons restitués correctement par le lecteur d’écran d’un agent malvoyant ;
• un contraste qui reste lisible en plein soleil.

Natif, PWA ou service prêt à l’emploi : ce que change chaque voie

Trois questions comptent pour une commune : comment l’outil arrive sur des téléphones disparates, comment il se met à jour, et s’il passe par un magasin d’applications. Le comparatif général entre natif, hybride et PWA pose les bases.

L’application native, distribuée en privé

Le natif exploite pleinement l’appareil photo, la localisation et le stockage local. Pour un usage interne, les magasins prévoient une diffusion privée : selon l’aide de Google Play d’entreprise, une application limitée à des organisations n’est disponible que pour elles ; chez Apple, une app personnalisée passe la revue d’Apple, puis n’apparaît que pour les organisations désignées. Ce canal convient à la flotte gérée de la commune, moins au téléphone d’un bénévole venu pour une journée.

La progressive web app, ouverte par un lien

Une PWA s’ouvre depuis un lien, s’installe sur l’écran d’accueil et garde en cache ce qu’elle a déjà chargé. Bénévoles et prestataires y accèdent sans magasin, et chaque mise à jour touche tout le monde en même temps. Ses limites : un stockage local géré par le navigateur, et un accès aux fonctions avancées du téléphone qui varie selon le système. Le service worker et le mode hors ligne sont détaillés dans notre article sur la progressive web app.

Le service en ligne prêt à l’emploi

Un service déjà développé se configure sans développement, et son éditeur assure les mises à jour. À vérifier : le mode hors connexion fonctionne-t-il vraiment, les données s’exportent-elles dans un format ouvert, où sont-elles hébergées ? Le fournisseur agit comme sous-traitant au sens du RGPD, un point que la CNIL range parmi les étapes de mise en conformité des collectivités.

Repartir du dernier événement avant de comparer des outils

Le meilleur banc d’essai, c’est la dernière manifestation. Avec le chef d’équipe des services techniques, notez :

• chaque tâche réalisée, qui s’en est chargé et pour quelle heure ;
• le matériel sorti du centre technique, et celui revenu en retard ou abîmé ;
• les messages arrivés aux mauvaises personnes, ou jamais arrivés ;
• les endroits du site où le réseau a manqué ;
• les intervenants extérieurs qui auraient eu besoin d’un accès.

Cette liste devient la grille de test de toute application de gestion d’événement : faites rejouer à chaque outil cette journée réelle, coupure de réseau comprise, avec un agent, un bénévole et un prestataire.