OnParty — Construire un système de parrainage complet sur une plateforme événementielle en production
OnParty est une plateforme de découverte et de gestion d’événements utilisée par plus de 40 000 personnes dans 8 villes internationales (Paris, Londres, Milan, Dubai, Ibiza…). J’intègre l’équipe de développement sur un scope full-stack : app iOS, web app Next.js, backend Cloud Functions, et infrastructure de données Firestore. Durée de la mission : 3 mois.
Le contexte
Le projet a été développé rapidement par plusieurs développeurs avec des conventions différentes. Côté iOS : des fichiers à 1 600 lignes qui gèrent tout à la fois, du code dupliqué, un point central qui gère l’intégralité de l’état de l’app — impossible à tester ou à faire évoluer proprement. Côté backend : aucun modèle de données formalisé, chaque développeur interprétait la structure Firestore à sa façon. Des dates stockées dans trois formats différents, des statuts codés en chiffres au lieu de libellés lisibles, pas de convention de nommage.
L’app fonctionne — 40 000 utilisateurs, 150 partenaires, des transactions réelles. Mais le code freine l’évolution du produit. Mon rôle : livrer de nouvelles fonctionnalités métier tout en structurant ce qui ne l’était pas.
Ce que j’ai livré
Le système de parrainage — le chantier principal
Les organisateurs d’événements travaillent avec des RP (relations publiques) qui font la promotion de leurs soirées. Avant mon intervention, il n’y avait aucun moyen de savoir combien de billets chaque RP vendait réellement. L’organisateur payait ses RP à l’aveugle.
J’ai conçu et développé un système de liens affiliés complet, de bout en bout. Ce système traverse toutes les couches de la plateforme :
Côté web — j’ai créé le dashboard partenaires intégralement : 5 pages, 11 composants, 6 hooks React. L’organisateur génère un lien unique pour chaque RP, suit en temps réel les conversions (réservations attribuées, chiffre d’affaires généré, tickets scannés à l’entrée), et gère ses partenaires depuis une interface dédiée avec deux onglets — liens affiliés et contacts RP.
Côté app iOS — j’ai intégré le tracking affilié dans le système de deeplinks existant. Quand un utilisateur clique sur un lien partagé par un RP, l’app s’ouvre directement sur la page de l’événement avec le tracking activé en arrière-plan. L’utilisateur réserve normalement — la conversion est attribuée automatiquement au bon RP sans qu’il ne voie quoi que ce soit.
Côté backend — j’ai créé les Cloud Functions qui mettent à jour les métriques automatiquement : quand une réservation est confirmée, le nombre de conversions, le chiffre d’affaires et les scans sont incrémentés en temps réel sur le lien affilié concerné.
Ce chantier a représenté environ 30 commits sur un mois, avec une refonte en cours de route quand le périmètre a évolué pour inclure la gestion des contacts RP en plus des simples liens de tracking.
La structuration des données
Il n’existait aucun modèle de données formalisé. Chaque développeur devinait la structure des documents Firestore et créait ses propres types dans chaque fichier. J’ai créé un layer complet de 15+ interfaces TypeScript — utilisateurs, événements, réservations, tickets, factures, notifications, messages, artistes — qui formalise l’intégralité de la structure de données. Les développeurs de l’équipe ne naviguent plus à l’aveugle.
En parallèle, j’ai normalisé les données en production : conversion des dates vers un format unique, passage des statuts numériques à des libellés lisibles, harmonisation des noms de champs. J’ai aussi créé plus de 500 lignes de fonctions utilitaires pour les opérations Firestore courantes — éliminant la duplication de requêtes dans chaque composant.
La compression des médias
Les photos uploadées par les utilisateurs partaient en pleine résolution — 3 à 8 MB par image iPhone. J’ai mis en place un système de compression adapté au contexte : un avatar est compressé à 50 KB, une cover d’événement à 500 KB max. Réduction de 10x à 100x sur le poids des images, temps d’upload divisés proportionnellement — surtout perceptible sur réseau mobile.
Le nettoyage du code iOS
Chaque fichier que je touchais, je l’améliorais. Les développeurs précédents avaient créé des classes identiques dans chaque fichier — la même structure redéfinie différemment d’un écran à l’autre. J’ai unifié ces structures pour que l’app utilise les mêmes modèles de données, en cohérence avec la nouvelle structure Firestore.
Le résultat
En 3 mois, sur un scope full-stack (iOS, web Next.js, backend, infrastructure données) :
- Système de parrainage complet : de la génération du lien au dashboard de suivi en temps réel, en passant par le tracking automatique des conversions sur toute la chaîne
- 15+ modèles de données TypeScript créés — structuration de l'intégralité du schéma Firestore
- Normalisation de la base de données en production sans interruption
- Compression des médias : réduction de 10x à 100x du poids des images
- 12 000+ lignes de code ajoutées, 100+ fichiers touchés
- Code iOS uniformisé sur les structures de données partagées
L’app opère dans 8 villes internationales avec plus de 40 000 utilisateurs et 150 partenaires. Elle a fait l’objet d’une levée de fonds d’1M€.
Ce que ce projet montre
Intégrer une équipe existante sur une plateforme en production de cette taille et livrer un système métier complet en 3 mois demande une capacité d’adaptation rapide — comprendre le code de 5 autres développeurs, chacun avec ses conventions, et y injecter quelque chose de propre qui s’intègre sans rien casser.
La particularité de cette mission : le travail simultané sur 4 couches techniques (app iOS, web Next.js, backend Cloud Functions, infrastructure Firestore). Le système de parrainage ne pouvait pas être découpé en tâches isolées — chaque couche dépendait des autres. C’est le type de projet où la polyvalence technique n’est pas un bonus, c’est ce qui permet de livrer.