Ça Monte En Bas

Présentation du projet

Ça Monte En Bas est un projet réalisé dans le cadre de mon cursus à l’ESIEA, en réponse aux besoins exprimés par une association implantée dans les quartiers de la ville basse de Montauban. Active dans l’organisation d’événements de proximité, cette structure associative cherche à dynamiser la vie locale en créant des moments de convivialité ouverts à tous, comme des vide-greniers ou des marchés solidaires.

Avec la croissance progressive de ses activités, l’association faisait face à des difficultés d’organisation, notamment dans la gestion des inscriptions et le suivi logistique des participants. Le projet est donc né de la volonté de moderniser ces processus, en apportant une solution numérique simple, adaptée à un contexte associatif, et pensée pour faciliter le quotidien des bénévoles.

Conçu avec et pour les acteurs du terrain, Ça Monte En Bas vise à rendre la gestion des événements plus fluide, plus fiable, et moins chronophage. L’outil imaginé devait permettre de centraliser les informations essentielles, automatiser les réservations, et offrir une vision claire de l’état d’avancement de chaque événement. Au-delà de l’aspect technique, le projet s’inscrit dans une démarche citoyenne et solidaire, en mettant le numérique au service de l’engagement local.

Objectifs

Le projet de Ça Monte En Bas visait à répondre aux difficultés logistiques rencontrées par l’association dans la gestion de ses événements, en particulier lors de l’organisation de vide-greniers. L’objectif principal était de concevoir un outil numérique simple et accessible, permettant de centraliser les inscriptions des participants, d’en assurer le suivi, et de fluidifier l’ensemble du processus de réservation.

Au-delà de la simplification des démarches, l’application devait améliorer la traçabilité des données, réduire les erreurs de traitement et renforcer la réactivité de l’équipe en charge de l’organisation. Elle devait également s’adapter à la réalité d’un cadre associatif, en proposant une solution fonctionnelle, sans exiger de ressources importantes ou de compétences techniques avancées.

Ce projet portait aussi une ambition plus large : montrer que le numérique peut servir de tremplin pour les initiatives locales. En dotant une petite structure d’un outil sur mesure, pensé pour son fonctionnement réel, nous souhaitions démontrer qu’il est possible d’allier simplicité d’usage, efficacité et utilité sociale.

Enjeux de la réalisation

L’un des principaux enjeux du projet résidait dans la capacité à traduire un fonctionnement associatif souvent informel en un processus numérique structuré, sans alourdir l’expérience utilisateur. Il s’agissait de construire une application capable d’accompagner les organisateurs dans leur quotidien, en apportant une vraie valeur ajoutée tout en restant intuitive et facilement appropriable.

Un autre enjeu fort tenait à la gestion du plan d’implantation des événements, fourni par l’association.

Plan - Place Lalaque

Ce plan, représentant l’ensemble des emplacements disponibles, devait être fidèlement retranscrit dans l’interface, avec une logique de sélection et de visualisation claire. La représentation cartographique dynamique devenait ainsi le cœur de l’expérience utilisateur, autant pour les participants que pour les administrateurs.

Enfin, le projet imposait une approche modulaire et évolutive. Il fallait penser l’outil comme un socle pérenne, capable d’être réutilisé pour plusieurs événements, avec des besoins spécifiques à chaque édition. Cela impliquait une grande rigueur dans la structuration des données et une interface flexible, capable d’accueillir de nouveaux usages à mesure que l’association affinerait son organisation.

Risques et contraintes

Le projet s’inscrivait dans un contexte associatif, avec ses spécificités et ses contraintes propres. L’une des premières limitations concernait la disponibilité des interlocuteurs. L’association étant composée de bénévoles, souvent impliqués sur plusieurs fronts, les échanges étaient parfois espacés ou réalisés en dehors des horaires habituels, rendant la collecte des besoins plus progressive et fragmentée.

Un autre défi résidait dans la diversité du public utilisateur. L’application devait pouvoir être utilisée aussi bien par des personnes peu à l’aise avec les outils numériques que par des administrateurs aguerris à la gestion des événements. Cela imposait une attention particulière à l’ergonomie, à la lisibilité des informations, et à la clarté des actions disponibles à l’écran.

Par ailleurs, la représentation graphique des emplacements, cœur du système de réservation, soulevait des contraintes techniques importantes. Il fallait garantir une compatibilité avec différents supports, tout en permettant une interaction fluide et précise (sélection de zones, affichage dynamique des informations, gestion des états de réservation, etc.). La moindre approximation dans le positionnement des éléments ou dans la logique de validation pouvait engendrer des conflits de réservation ou des erreurs difficiles à corriger à posteriori.

Un autre risque identifié, plus structurel, concernait l’évolution potentielle du plan physique de l’événement. Bien que l’application permette déjà l’activation ou la désactivation dynamique des emplacements, elle repose sur une représentation figée du plan initial fourni par l’association. Or, dans un contexte réel, la configuration des lieux peut changer d’une année à l’autre (modification du terrain, accès restreints, travaux, etc.). L’absence de mécanisme permettant une reconfiguration complète du plan dans l’outil pourrait à terme limiter sa pérennité ou nécessiter une intervention technique pour toute mise à jour majeure. Ce point soulève un besoin futur d’éditabilité avancée du plan, ou d’intégration d’un système plus souple de modélisation des emplacements.

Enfin, la temporalité du projet représentait un enjeu majeur. Le développement devait être mené à bien dans un délai de six mois, encadré par le calendrier scolaire. Ce rythme soutenu exigeait une organisation rigoureuse, tout en assurant la stabilité de l’application, son maintien en conditions opérationnelles, et sa remise aux membres de l’association dans un état pleinement exploitable.

Ma position dans le projet

Sur ce projet, j’ai assuré le rôle de chef de projet tout en participant activement au développement, au sein d’une équipe de quatre étudiants. Cette double casquette m’a permis de coordonner l’ensemble des étapes de la réalisation, tout en contribuant directement à la conception et à l’implémentation des fonctionnalités clés. Mon objectif était d'assurer à la fois le bon déroulement du projet et sa cohérence technique, dans un esprit collaboratif et avec une attention constante portée aux besoins exprimés par l’association.

En tant que chef de projet, j’ai assuré la planification des différentes phases du développement, la répartition des tâches au sein de l’équipe, et le suivi régulier de l’avancement. J’ai également été l’interlocuteur principal de l’association, en charge de recueillir les besoins, d’assurer leur traduction fonctionnelle, et de veiller à ce que chaque retour soit intégré dans une démarche itérative et structurée.

En parallèle, j’ai pris en charge le développement de plusieurs fonctionnalités clés, en particulier autour de la gestion des utilisateurs, du système de réservation, et de l’interface d’administration. Cette implication directe dans le code m’a permis de conserver une vision technique précise du projet et de garantir la cohérence entre les orientations stratégiques et les choix de développement.

Mise en œuvre

Information

Avant d’aborder cette réalisation, il est important de souligner qu’elle m’a permis d’approfondir et de mettre en pratique plusieurs compétences techniques et humaines. Certaines d’entre elles sont détaillées dans d’autres sections de ce portfolio. Si certaines explications vous semblent trop succinctes, je vous invite à vous y référer pour une meilleure compréhension.

Première tâche - Maquettage

Le maquettage a constitué une étape clé dans la conception de l’application. Réalisé sur Figma, il a permis de poser les bases fonctionnelles et graphiques du projet, tout en facilitant la coordination des tâches entre les membres de l’équipe. En tant que chef de projet, j’ai assuré la supervision globale de cette phase, tout en contribuant directement à la réalisation des écrans et à la structuration des parcours utilisateurs. Ce travail d’équipe nous a permis de traduire les besoins exprimés par l’association en une interface claire, accessible et fidèle à leurs usages.

Interface utilisateur

Nous avons commencé par concevoir les maquettes du parcours utilisateur. L’objectif était d’offrir une expérience fluide pour les adhérents de l’association, en leur permettant de réserver un ou plusieurs emplacements en quelques étapes simples. Chaque interaction a été pensée pour être intuitive : sélection de l’événement, choix des emplacements sur une carte, ajout d’options (tables, véhicules), puis validation de la commande.

Maquette - Sélection d'un événement

Maquette - Interface principale de réservation

Maquette - Récapitulatif de la réservation

Un soin particulier a été apporté à l’espace personnel, permettant à chaque utilisateur de suivre ses réservations, de consulter leur statut (en attente, modifiée, validée, expirée, etc.), et de recevoir les notifications associées. Cette centralisation des informations visait à offrir un suivi complet et autonome.

Maquette - Espace personnel

Maquette - Récapitulatif des réservations

Les échanges réguliers avec notre interlocuteur associatif nous ont permis de faire évoluer progressivement les écrans, notamment pour mieux refléter certaines situations spécifiques (ex : refus d’une demande, modification de dernière minute, etc.). Cette démarche itérative nous a permis de garantir une solution au plus près des usages réels.

Interface administrateur

En parallèle, nous avons conçu une interface dédiée aux membres de l’association chargés de gérer les événements. L’objectif était de leur fournir une interface claire, complète mais non surchargée, leur permettant de gérer facilement les prestations tout au long de leur cycle de vie.

Maquette - Panel administrateur

Cette interface donnait accès à plusieurs modules :

• Création d’événements, avec la possibilité de s’appuyer sur des plans préexistants (templates) ou d’en créer de nouveaux grâce à un éditeur graphique.
• Gestion des plans d’emplacement, avec une interface visuelle permettant de sélectionner, modifier ou désactiver des zones et de paramétrer leurs caractéristiques.
• Suivi des réservations, pour traiter les demandes en attente, proposer des alternatives et valider les choix des utilisateurs.
• Suivi des paiements, avec un système de relance et de vérification des statuts.
• Gestion des utilisateurs, incluant la modification des droits et la suppression de comptes si nécessaire.

Maquette - Éditeur d’événement (création / modification de plan)

Maquette - Gestion des réservations

Maquette - Gestion des paiements

Maquette - Liste des utilisateurs

La cohérence visuelle entre l’interface utilisateur et le panel administrateur a été un axe de travail important, afin d’assurer une homogénéité graphique tout en différenciant clairement les rôles et fonctionnalités de chaque espace.

Deuxième tâche - Back-end

L’implémentation du back-end a été un pilier fondamental dans la conception de l’application. Basé sur Java avec Jakarta EE, le projet s’appuyait sur EclipseLink JPA pour la gestion de la persistance. Ce choix technique permettait une approche code-first, dans laquelle le modèle de données est défini par des classes Java, traduites automatiquement en tables relationnelles via l’ORM. Cette méthode offrait à l’équipe un contrôle précis sur la structure des données, tout en favorisant une meilleure évolutivité et une plus grande lisibilité.

En tant que chef de projet, j’ai pris en charge cette partie du développement de manière autonome, notamment en concevant et en implémentant toute la logique liée à la gestion des réservations. Cette autonomie s’est inscrite dans une organisation rigoureuse et une gestion proactive des responsabilités, contribuant à la fluidité des processus collectifs et à la cohérence de l’ensemble du projet.

Modélisation des entités et relations

La première étape a consisté à modéliser l’ensemble des entités représentant les concepts clés de l’application. Chaque classe Java correspondait à une table, et les relations entre objets (utilisateur, événement, réservation, emplacement, etc.) étaient exprimées de manière explicite via des annotations JPA. Ce travail a permis de traduire fidèlement la logique métier en structure relationnelle, en intégrant les dépendances entre entités. Par exemple, une réservation est liée à un utilisateur et à un événement, et peut référencer plusieurs emplacements.

Structure de table - Réservations

@Entity
@Table(name = "reservations")
public class Reservation {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @ManyToOne
    private Utilisateur utilisateur;

    @ManyToOne
    private Evenement evenement;

    @OneToMany(mappedBy = "reservation")
    private List<Emplacement> emplacements;

    private String statut;
    private Date dateReservation;
}

Ce modèle reflète la structure d’une réservation, associée à un utilisateur, un événement et plusieurs emplacements, tout en intégrant les informations essentielles comme le statut et la date de réservation.

Les contraintes métiers ont également été intégrées dans le modèle, comme l’unicité d’un emplacement sur un événement donné, ou les restrictions liées à la présence d’un véhicule ou à la location de table.

Organisation de l’accès aux données

Les opérations de lecture, d’écriture, de mise à jour ou de suppression étaient regroupées dans des DAO (Data Access Object), chargés d’encapsuler la logique d’accès aux entités. Ces classes centralisaient les interactions avec la base de données, que ce soit via des requêtes JPA classiques ou des requêtes dynamiques. Le ReservationDAO, par exemple, permettait d’extraire toutes les demandes liées à un utilisateur, ou de filtrer les réservations selon leur statut.

Accès aux entités - ReservationDAO

import jakarta.ejb.Stateless;
import jakarta.persistence.EntityManager;
import jakarta.persistence.PersistenceContext;
import jakarta.persistence.TypedQuery;
import java.util.List;

@Stateless
public class ReservationDAO {

    @PersistenceContext(unitName = "defaultPU")
    private EntityManager em;

    public void save(Reservation reservation) {
        if (reservation.getId() == null) {
            em.persist(reservation);
        } else {
            em.merge(reservation);
        }
    }

    public void delete(Long id) {
        Reservation r = em.find(Reservation.class, id);
        if (r != null) em.remove(r);
    }

    public Reservation find(Long id) {
        return em.find(Reservation.class, id);
    }

    public List<Reservation> findAll() {
        return em.createQuery("FROM Reservation ORDER BY dateReservation DESC", Reservation.class)
                 .getResultList();
    }

    public List<Reservation> findByUtilisateur(Long userId) {
        return em.createQuery("FROM Reservation r WHERE r.utilisateur.id = :id", Reservation.class)
                 .setParameter("id", userId)
                 .getResultList();
    }

    public List<Reservation> findByStatut(String statut) {
        return em.createQuery("FROM Reservation r WHERE r.statut = :statut", Reservation.class)
                 .setParameter("statut", statut)
                 .getResultList();
    }
}

Le DAO centralise les requêtes de lecture et d’écriture sur les entités Reservation, facilitant leur réutilisation et la séparation entre les couches métier et persistance. Les méthodes findByUtilisateur et findByStatut illustrent l’usage de filtres personnalisés via JPA.

Cette organisation par couche assurait une séparation nette entre la logique métier et la logique d’accès aux données. Elle permettait également de faciliter les tests unitaires et la réutilisabilité du code dans d’autres contextes.

Exposition des services via des routes REST

Afin de rendre ces données accessibles au front-end, nous avons conçu des contrôleurs REST, exposant des endpoints structurés et cohérents. Ces routes répondaient aux différentes actions possibles pour chaque type d’utilisateur. Par exemple, un utilisateur pouvait créer une réservation,consulter son historique ou suivre l’état d’une demande en attente. De son côté, un administrateur pouvait parcourir la liste des réservations en attente, modifier leur statut ou supprimer un compte utilisateur.

Les contrôleurs étaient annotés avec @Path, @POST, @GET et les autres annotations propres à Jakarta EE, permettant une gestion claire des verbes HTTP et des paramètres. Voici un extrait simplifié d’un contrôleur pour les réservations :

Route API - Réservations

@Path("/reservations")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class ReservationController {

    @Inject
    private ReservationDAO reservationDAO;

    @POST
    public Response creerReservation(Reservation reservation) {
        reservationDAO.creer(reservation);
        return Response.status(Response.Status.CREATED).build();
    }

    @GET
    @Path("/{id}")
    public Reservation getReservation(@PathParam("id") Long id) {
        return reservationDAO.findById(id);
    }
}

Ce contrôleur expose des routes REST pour créer ou récupérer une réservation. Il s’appuie sur les annotations Jakarta EE pour lier les routes aux verbes HTTP, tout en déléguant la logique métier au DAO.

Chaque route a été pensée pour répondre aux besoins spécifiques de l’interface utilisateur ou administrateur. Des vérifications complémentaires ont été ajoutées côté back-end pour sécuriser les accès, valider les droits des utilisateurs ou contrôler la cohérence des informations reçues.

Interaction avec la base de données et génération automatique

Grâce à l’approche code-first, la structure de la base de données se construisait automatiquement en fonction des entitésJava. Cette génération automatique évitait de devoir maintenir manuellement un script SQL et garantissait une parfaite synchronisation entre le modèle objet et le modèle relationnel. Les relations comme @OneToMany, @ManyToOne ou encore les clés étrangères étaient interprétées par EclipseLink, qui créait les jointures et les contraintes nécessaires dans le schéma.

Chaque mise à jour du modèle, comme l’ajout d’un nouveau champ ou d’une nouvelle entité (par exemple, la gestion des statuts de commande ou des options de location de table), se traduisait directement dans la base au redémarrage de l’application, facilitant les itérations rapides pendant le développement.

Gestion des statuts et logique métier

Un point important dans la logique back-end était la gestion des statuts d’une réservation. Chaque réservation pouvait passer par différents états : en attente, modifiée, en attente de paiement, validée, expirée. Ces transitions étaient pilotées à la fois par les actions des utilisateurs et les décisions des administrateurs.

Cette logique a été codifiée dans des services métier, permettant d'encapsuler les règles spécifiques de transition d’un statut à un autre. Elle permettait également de déclencher des actions automatiques, comme l’envoi de mails de notification ou l’expiration automatique d’une réservation la veille de l’événement.

Troisième tâche - Front-end

L’application a été développée avec Angular, un framework Web moderne basé sur TypeScript, qui fait partie intégrante des technologies Web actuelles. Ce choix nous a permis d’adopter une architecture modulaire, favorisant une séparation claire des responsabilités, une réutilisabilité du code, et une évolutivité naturelle de l’application.

L’objectif principal était d’offrir une expérience claire et accessible, aussi bien pour les adhérents souhaitant réserver un emplacement que pour les membres de l’association chargés d’organiser l’événement.

Durant cette phase, j’ai été confronté à plusieurs situations complexes, notamment dans l’intégration de composants Angular et la gestion de leur communication dans l’application. Pour y faire face, j’ai régulièrement eu recours à des forums anglophones, ce qui m’a permis de formuler des questions précises, de comprendre les solutions proposées et d’implémenter des corrections efficaces.

Architecture de l’interface

L’application est structurée autour de plusieurs écrans fonctionnels pensés pour répondre aux besoins spécifiques des utilisateurs :

• Un parcours de réservation permettant de sélectionner un événement, de choisir un ou plusieurs emplacements sur le plan, et d’ajouter des options comme des tables ou une place de stationnement.
• Un espace personnel regroupant les informations de compte, l’historique des réservations, et les messages importants.
• Une interface administrateur, offrant un accès centralisé aux événements, utilisateurs, paiements, demandes et cartes d’emplacements.

Définition des composants Angular

Chaque fonctionnalité majeure a été implémentée sous forme de composants Angular distincts. Cette approche a permis de maintenir une structure claire du front-end et de favoriser la réutilisabilité du code.

Par exemple, le composant CarteReservationComponent est responsable de l’affichage de la carte interactive, avec les emplacements réservables positionnés dynamiquement selon leurs coordonnées.

Composant - CarteReservationComponent

<div
  *ngFor="let emplacement of emplacements"
  class="emplacement"
  [style.left.px]="emplacement.x"
  [style.top.px]="emplacement.y"
  [class.selectionne]="isSelected(emplacement)"
  (click)="selectionner(emplacement)">
</div>

Chaque div représente un emplacement, placé sur la carte en fonction de ses coordonnées. Lorsqu’un utilisateur clique, l’élément est sélectionné visuellement grâce à une classe CSS dédiée.

Chaque interaction avec la carte émettait des événements vers le parent pour mettre à jour l’état global de la commande.

Des composants dédiés comme BadgeStatutComponent (affichage du statut d’une réservation), CommandeCardComponent (présentation d’une réservation dans l’espace perso) ou encore EvenementFormComponent (création/modification d’un événement côté admin) ont également été créés pour structurer les interfaces tout en garantissant leur cohérence visuelle.

Interaction et formulaires utilisateurs

Les formulaires Angular sont utilisés pour gérer les saisies utilisateurs (demandes de réservation, modification de profil, etc.). Ces formulaires sont connectés aux services via HttpClient, permettant une communication fluide avec le back-end.

Appel API - POST Réservations

this.http.post('/api/reservations', this.reservationForm.value).subscribe(...);

Les données du formulaire sont envoyées sous forme JSON vers l’API. Le front-end attend ensuite une réponse du serveur pour confirmer ou corriger la demande.

Les retours du serveur permettaient de mettre à jour dynamiquement les statuts et de déclencher l’envoi de notifications, tout en assurant une réponse fluide dans l’interface.

Vue d’ensemble du panel administrateur

L’interface administrateur repose sur un tableau de bord modulaire, conçu pour offrir aux responsables associatifs une vision claire de l’activité liée aux événements. Ce panel regroupe plusieurs fonctionnalités essentielles à la gestion du vide-greniers : le suivi des réservations, la relance des paiements, la gestion des utilisateurs, ou encore la configuration des zones tarifaires.

Chaque fonctionnalité repose sur un composant Angular dédié, garantissant une organisation claire du code, une réutilisabilité accrue et une meilleure expérience utilisateur. Ce découpage permet également de faire évoluer l’interface sans remettre en cause l’ensemble du système.

Un exemple typique est la carte de résumé statistique, affichant le nombre d’emplacements loués ou de clients n’ayant pas encore payé. Chaque carte est construite autour d’un composant Angular générique, stylisé selon les données reçues.

Composant - Carte statistique

<app-stat-card
  [icon]="'location_on'"
  [value]="nombreEmplacementsLoues"
  [label]="'Emplacement(s) loué(s)'"
  [color]="'#69C9FF'">
</app-stat-card>

Ce composant affiche dynamiquement le nombre total d’emplacements loués sur les événements actifs. La couleur #69C9FF correspond à l’identité visuelle de la carte dédiée, et la valeur est récupérée via un appel au service de réservation pour refléter en temps réel l'état du système.

Gestion administrative des événements

L’interface admin regroupait plusieurs modules fonctionnels, chacun piloté par son propre composant. La gestion des événements permettait par exemple de créer une nouvelle date via un formulaire et d’y associer une carte, soit à partir d’un plan existant (template), soit en construisant un plan personnalisé via un éditeur embarqué.

L’éditeur de plan utilisait une grille dynamique où chaque emplacement pouvait être fusionné ou supprimé à la souris. Cette fonctionnalité reposait sur la gestion du DOM via Angular et une logique métier embarquée côté TypeScript.

Composant - Application logique métier

<app-editeur-plan
  [plan]="planCourant"
  (update)="onPlanUpdate($event)">
</app-editeur-plan>

Ce composant permet la modification graphique du plan d’emplacements en temps réel. Les interactions utilisateur (ajout, fusion, suppression) déclenchent une mise à jour automatique du modèle côté TypeScript.

Résultat

La mise en ligne de l’application a marqué un tournant significatif dans l’organisation des événements de l’association. Grâce à la nouvelle plateforme, les réservations sont désormais centralisées, tracées, et beaucoup plus simples à gérer pour les membres de l’équipe. Les erreurs liées à la saisie manuelle ou aux oublis ont été largement réduites, et la gestion des demandes est devenue plus fluide grâce aux interfaces dédiées aux utilisateurs et aux administrateurs.

L’interface cartographique a permis une meilleure visualisation des emplacements, facilitant à la fois le choix des participants et le suivi des zones occupées par les organisateurs. De leur côté, les utilisateurs bénéficient d’un espace personnel clair, dans lequel ils peuvent suivre l’évolution de leur réservation, échanger avec l’équipe de l’association et recevoir des notifications automatiques à chaque étape.

Au-delà des gains d’efficacité, le projet a également renforcé la relation de confiance entre l’association et ses adhérents, en offrant une expérience plus transparente, plus lisible et plus réactive. L’équipe organisatrice a exprimé sa satisfaction quant à l’ergonomie de l’outil et à sa capacité à s’adapter à différentes éditions d’événements, y compris avec des configurations d’emplacement variables d’une année sur l’autre.

Enfin, ce projet a également donné à notre équipe une grande satisfaction personnelle. Voir l’outil utilisé sur le terrain, constater son adoption par les membres de l’association et recevoir des retours positifs a renforcé notre sentiment d’utilité. Il a confirmé l’impact concret que peut avoir un outil numérique bien conçu lorsqu’il répond à des besoins réels et locaux.

Avenir du projet

L’application a posé des bases solides pour la modernisation des pratiques de l’association, mais plusieurs axes d’évolution sont déjà envisagés pour accompagner sa montée en puissance. L’un des chantiers potentiels concerne l’amélioration de la gestion des paiements, avec l’intégration d’une plateforme de paiement en ligne, afin de faciliter le règlement des réservations directement depuis l’espace utilisateur, sans intervention manuelle de l’association.

Par ailleurs, un axe d’amélioration prioritaire concerne la gestion du plan d’implantation. Actuellement basé sur une représentation fixe, le système gagnerait à intégrer une fonctionnalité d’édition dynamique du plan, permettant de modifier facilement la forme, la disposition et le nombre d’emplacements. Cette évolution répondrait à un besoin concret de flexibilité, notamment en cas de réaménagement physique du terrain d’accueil, ou de changement de configuration d’un événement à l’autre. À court terme, une interface dédiée à la reconfiguration graphique des zones pourrait être développée, avec un système d’ancrage et de paramétrage visuel, facilitant la prise en main par les administrateurs, sans passer par une refonte technique.

Du côté de l’interface administrateur, certaines évolutions pourraient venir enrichir l’outil : statistiques d’utilisation, rapport d’événements, ou encore gestion avancée des zones tarifaires, pour offrir plus de souplesse dans l’organisation de plans complexes. Ces fonctionnalités permettraient à l’association de mieux analyser les tendances et d’optimiser l’organisation de ses futures éditions.

Enfin, à plus long terme, une ouverture du projet vers d’autres structures associatives pourrait être envisagée. En effet, les problématiques rencontrées par Ça Monte En Bas ne sont pas isolées, et une version généralisable de l’application pourrait répondre aux besoins d’autres acteurs locaux confrontés aux mêmes enjeux de réservation, de logistique et de communication.

Retour sur expérience

Ce projet a été particulièrement enrichissant, tant sur le plan humain que technique. Endosser le rôle de chef de projet tout en contribuant au développement m’a permis de renforcer ma capacité à organiser une équipe, à prendre des décisions structurantes, et à assurer une continuité entre la vision globale du projet et sa réalisation concrète. J’ai pu affiner mes compétences en Gestion de projet tout en consolidant ma maîtrise du développement Web, notamment dans un environnement en équipe restreinte où la coordination et la réactivité sont essentielles.

Ce qui m’a particulièrement marqué, c’est la dimension très ancrée dans la réalité du terrain. Le fait de travailler pour une association locale, avec des besoins concrets et une vraie attente vis-à-vis de l’outil, donnait du sens à chaque décision prise. L’ensemble de l’équipe projet s’est mobilisé avec un fort engagement, et la relation de confiance établie avec l’association nous a permis de faire évoluer l’application dans une logique de co-construction. Cette expérience m’a conforté dans mon envie de travailler sur des projets à impact réel, au service d’utilisateurs finaux bien identifiés, et de continuer à combiner responsabilités organisationnelles et développement technique dans mes futurs projets.

Compétences liées

Technologie Web - Frameworks - Base de données - Maquettage - Autonomie - Travail en équipe - Gestion de projet - Anglais