Duck Conf 2026 – CR – Apprivoiser le legacy en startup

Apprivoiser le legacy en startup : le retour d'expérience de Billy.

Maria Mokbel, founding engineer et tech lead chez Billy, est venue à la Duck Conf 2026 raconter comment son équipe a géré un legacy technique accumulé en seulement 2 ans. Pas de vieux système COBOL ici, juste les conséquences de décisions prises sous pression ou contraintes budgétaires, avec 6 mois de trésorerie et une vision blockchain qui a finalement dû pivoter.

Le contexte : Billy

Billy, c'est une plateforme de billetterie nouvelle génération fondée en 2022 à Paris. Vision initiale : Web3 ticketing avec des billets NFT pour prévenir la fraude. L'équipe tech : 3 développeurs au départ, 8 aujourd'hui.

Le problème classique des startups : 6 mois de trésorerie, besoin de prouver le concept rapidement, pas le temps de faire "bien".

Phase 1 : Le temps court (avril 2022 - février 2024)

Avec 6 mois de runway, l'équipe a pris tous les raccourcis possibles : export CSV pour le scan à l'entrée; apps web jetables customisées par clients; Grafana partagé en externe comme back-office de fortune.

Les choix techniques

Serverless (AWS Lambda) : La promesse était simple : on fait le code, AWS s'occupe du reste. A savoir : scalabilité automatique; paiement à l'usage; pas de complexité opérationnelle; Framework Chalice pour abstraire le packaging et le déploiement.

Microservices : Ils sont nécessaires pour gérer plusieurs blockchains (Tezos, Polygon) avec des stacks différentes (Python, JavaScript, librairies Windows). Ils permettaient aussi de prendre des freelances sur des briques isolées. Résultat : 7 CI/CD pour 3 devs.

Low-code pour le back-office : "On ne veut pas se poser ces questions maintenant, on n'a pas le temps." Drag & drop, API derrière : ça marche !

Blockchain : Il s’agissait d’une décision business, pas technique pour avoir des billets collectionnables, la prévention fraude, le contrôle revente.

Le ROI à court terme

La stratégie a fonctionné :

• Un premier événement 2 mois après le démarrage
• Un Back-office développé en 6 mois
• Des clients prestigieux : Hellfest, Lujipeka
• Une Innovation Produit : premiers sur le marché avec les bundles (billet + produits dérivés type CD)

Cette feature bundles a marqué un tournant pour la boîte: la diversification des revenus pour les artistes, un nouveau canal de vente pour les organisateurs.

Phase 2 : La bascule (mars-mai 2024)

24 mois plus tard, le modèle "6 mois de trésorerie renouvelés 4 fois" finit par montrer ses limites.

Les conséquences

Serverless : Avec les Cold starts, chaque lambda se connecte à la base de données. Le nombre de connexions explose, la base de données crash, ce qui amène une complexité de monitoring/debug.

Chalice : Ce framework est peu maintenu : pas de Swagger automatique, des versions Python obsolètes. Le projet commençait à être déprécié.

Microservices : Il y a 7 pipelines pour 3-4 personnes. Le code pourrit dans des repositories non touchés. Cela engendre une maintenance excessive, surtout avec un écosystème blockchain très dynamique.

Low-code : Il y a beaucoup de code custom, non versionné et testable uniquement en production. Cela génère de nombreux bugs.

Blockchain : Il s’agit d’un écosystème instable avec des pannes fréquentes. A cela s’ajoute une complexité UX impossible à abstraire (latence, transfert de NFT, connexion wallets). De surcroît, des coûts imprévisibles (gas fees sur chaque transaction) rendent impossible le calcule de la marge sur un événement à l'avance.

Les symptômes du legacy

• ~10 bugs critiques/mois
• Temps de dev × 10 (2 jours → 2 semaines)
• Crash du site pour une vente à 15k billets
• Trop d'expérimentations déployées jamais retirées

Breakthrough

L'événement déclencheur qui permet la prise de conscience : une feature apparemment simple. "On veut pouvoir mettre un prix variable sur les billets selon le pack", par exemple un billet seul : 39€; un billet dans un bundle : 30€.

L’équipe estime le développement à : 2 mois. NDLR : nous vous invitons à lire le CR sur les estimations des projets à l'échelle : Bienvenue à Mytholand !.

La prise de conscience se traduit par qu'il faut changer quelque chose : "On ne peut pas prendre 2 mois pour développer une feature après 3 ans de boîte."

Phase 3 : La stratégie (2024-2025)

L'équipe technique se retrouve face à un dilemme familier : continuer avec une architecture qui les freine, ou tout reconstruire en arrêtant de livrer ?

Ils ont refusé ce faux choix et reconstruit leur système sans jamais arrêter de livrer.

Étape 1 : Comprendre où on va

Avant de refactorer, l'équipe s'arrête deux semaines complètes pour des ateliers: "Quels problèmes cherchons-nous à résoudre ?"

Une découverte : Ce qu'ils pensaient être le problème (fraude, contrôle revente) ne concerne que le top 1% des événements. Le vrai problème pour la majorité de leurs clients est de remplir les salles, mobiliser les fans et diversifier les revenus.

Ces deux semaines ont permis de prendre du recul et de redéfinir la vision.

Cela amène un pivot produit : développer une Boutique événementielle en marque blanche, très customisable pour la vente de billets et d’autres produits.

C'est aussi l'occasion de réaliser un audit technique :

• Il y a trop d'unités de déploiement : le code diverge, les livraisons deviennent imprévisibles
• Un Vendor lock-in avec des frameworks obsolètes
• Des performances de base de donnée en chute
• Une DX (expérience développeurs) mauvaise : onboarding long, environnement local non reproductible, manque d'outillage moderne
• Des features zombies à maintenir ralentissent les équipes
• Un manque de standardisation (chacun son périmètre sans conventions communes) rend la maintenance trop lourde

Étape 2 : Reprendre le contrôle du flux

A. Unship : Retirer le superflu

L'équipe décide de retirer avant d'ajouter.

Première décision difficile : virer toute la composante mobile. Pour la marque blanche, personne ne va télécharger une application propriétaire.

Deuxième décision encore plus difficile : supprimer toute la blockchain, ce qui correspond à la fois aux convictions des fondateurs et à l’équivalent de 2 ans de travail.

La discussion avec les fondateurs s’est déroulée de cette manière : "Voilà le coût de maintenir ça" (chaque feature doit s'interfacer, maintenir les services, gérer l'instabilité) "versus le coût de tout killer et de rebuild plus tard si vraiment besoin."

Le calcul est transparent et la décision rationnelle.

B. Simplifier la CI/CD

Puis ils simplifient.

De 7 CI/CD, Billy passe à 1 pipeline, 1 artefact, plusieurs points d'entrée.

• Sept pipelines CI/CD → une seule
• Une seule codebase, plusieurs points d'entrée (API, workers, webhooks)
• Abandon de Chalice pour des images Docker (qui facilite la portabilité)

C. Construire des capabilities

Cela se traduit par un outillage de base qu'ils n'avaient jamais eu le temps de faire :

• Migrations de base de données versionnées
• ADRs (Architecture Decision Records) systématiques
• Tooling moderne : uv, ruff, mypy*,* pre-commit hooks
• Typage complet du code Python

D. Reproductibilité

Cela se traduit par:

• Un environnement local reproductible
• Des tests de charge à la demande

E. Résoudre les perfs DB

Avec le scaling des Lambda, les connexions en base de données explosaient et la saturait

Pour résoudre ce problème, des solutions sont trouvées :

1. Un RDS Proxy : il reçoit les demandes de connexion, les gère avec un pool, et les redistribue. Ex : 4000 demandes → 2500 connexions effectives.
2. Un Connection manager : Chaque lambda utilise une seule connexion. "Voilà la connexion, tu l'utilises, tu me la rends."

Étape 3 : Repenser l'architecture

“Excessive complexity is nature’s punishment for organizations that are unable to make decisions.” - Gregor’s Law

Voici un exemple de complexité métier : le bundle.

Un bundle ce n'est pas juste "un pack de produits". C'est :

• Dans le catalogue → définir l'offre (un billet, un CD, une casquette par exemple)
• Dans l'inventaire → 2 inventaires différents
• Dans le pricing → des prix différents redistribués à des fournisseurs
• Dans le canal de vente → un ensemble d'articles expédiés ensemble

C’est donc bien trop complexe pour un modèle universel.

La solution : un découpage en bounded contexts (catalogue, inventaire, pricing, canal de vente). Celà réduit la responsabilité et la complexité de chaque contexte, au dépend d’un nouveau type de complexité : la relation entre les différents contextes.

Cette méthode est tirée du Domain Driven Design : une approche méthodologique de conception logicielle qui privilégie la modélisation des systèmes en fonction de la complexité des domaines métiers. Elle est particulièrement adaptée aux projets de développement logiciel complexes, car elle permet d'aligner étroitement la structure du code avec les besoins réels de l'organisation.

Pour en savoir plus sur le Domain-Driven Design :

• Duck conf 2026 - Moderniser un legacy conséquent sans y perdre ses plumes. Et si le code n'était pas le problème ?
• Formation Domain-Driven Design - Acquérir les pratiques d’une conception logicielle orientée métier
• Formation "Concevoir des produits alignés sur le métier avec le DDD”

Le choix d’architecture : le passage au “modular monolith” pour oublier les microservices.

Cette architecture permet de garder des concepts familiers pour l'équipe (Lambda, etc.) et d’introduire la complexité progressivement. "Sinon l'équipe ne gère pas".

D'ailleurs, chez OCTO Technology, on recommande le modular monolith par défaut dans Culture API : même si les microservices sont tentants, nous préférons nous orienter d’abord vers les Monolithes Modulaires. En structurant le code en modules internes bien isolés, cette architecture combine la simplicité du déploiement en un seul bloc avec une maintenabilité accrue. Faciles à déployer et à faire évoluer, ces monolithes constituent un excellent choix initial pour les projets, évitant la complexité prématurée des microservices tout en laissant la porte ouverte à une transition future.

La stratégie de migration : "Double run"

Impossible de dire aux fondateurs "on arrête tout pendant qu'on reconstruit". Il faut y aller progressivement, avec une mise en production rapide et du feedback régulier.

Aussi la solution reprend ces actions :

• Garder le legacy pendant toute la reconstruction
• Mettre le nouveau système en production rapidement
• Faire en sorte d’avoir un MVP scalable dès le jour 1
• Créer par petites tranches pour des usages clients réels
• Définir une migration progressive
• Prévoir la décommission du legacy à la fin

Qui amènent plusieurs bénéfices :

• Inclure les fondateurs dans le processus,
• Des feedbacks réels immédiats,
• Pas de tunnel de 6-12 mois sans livraison.

Bonus : IA

L’objectif derrière est de : "Réduire l'ambiguïté. L'ajout de toute feature doit être mécanique. Moins un agent doit interpréter, plus il est fiable."

L’utilisation généralisée de Claude Code est rendue possible par les “capabilities” ajoutée par l’équipe : typage, ADRs, conventions, pre-commit, scripts de migrations de base de donnée, tests de charges à la demande…

Pour aller plus loin :

• IA et legacy : du prompt au cadre de travail, retour sur une expérimentation terrain
• Moderniser un legacy conséquent sans y perdre ses plumes - Partie I

Les résultats (après 12 mois)

Chiffres

• 4 nouveaux membres dans l'équipe sans baisse de vélocité
• 5 000 RPS (requêtes par seconde) là où l'application crashait à 15 000 billets.
• 1 Event store auditable
• Première vente sur nouveau système après 6 mois
• 100 000 billets vendus depuis 1 an
• Environ 20 déploiements/mois avec lead time de **12 heures **
• 1 API ouverte aux développeurs externes
• L’IA est généralisée sans dégradation de stabilité
• 0 bug critique le mois dernier (versus 10/mois avant)

Les leçons

1. Les raccourcis étaient nécessaires

Avec 6 mois de trésorerie, Billy n’avait pas d'autre choix. "Nous avons fait de notre mieux avec les moyens du bord." Les raccourcis étaient la bonne décision à ce moment-là.

2. Savoir reconnaître le moment décisif

Chaque levée de fonds est une opportunité de prendre du recul. Il faut savoir quand il est temps de changer de cap. Le gros problème d’une feature simple demandant 2 mois de développement a forcé la prise de conscience.

3. Stack moderne ≠ baguette magique

Les Serverless, blockchain, IA restent des outils, pas des solutions magiques. Il faut construire les “capabilities” de base : scripts de migrations de base de données, typage, documentation, tests.

4. Une architecture simple gagne même avec un domaine complexe

Il n’est pas nécessaire d’utiliser des microservices pour tout: un Monolithe modulaire est suffisant. La complexité du métier ne rime pas avec complexité d’architecture.

5. Aucune fonctionnalité n'est gratuite

En effet, la maintenance est un coût caché. Savoir dire non, savoir retirer. Les features zombies coûtent cher (par exemple maintenir un gros système de blockchain). Renoncer à certaines est parfois la meilleure option.

6. L’Alignement des équipes est supérieur aux choix des Outils

La tech aide, mais c'est la dynamique d'équipe entre les devs et avec les fondateurs qui fait la différence.

Organisation d'équipe et loi de Conway

Avant (3 personnes) :

• Un dev dédié au mobile
• Des freelances mobilisés uniquement sur la blockchain
• Maria Mokbel à la fois sur le back et le front

En résumé, chacun son périmètre isolé et ses microservices

Problèmes créés :

• SPOFs (Single Point of Failure) : si quelqu'un absent, tout est bloqué
• Il n’y a pas de standards
• Il est difficile de débugger (personne ne connaît toutes les briques)

Après :

• 1 équipe de 8
• 2 personnes sachantes minimum sur chaque partie
• 1 artefact → 1 équipe (respect de la loi de Conway)

Conclusion

Ce qui m'a marqué dans ce talk, c'est le pragmatisme sans bullshit. Maria assume complètement les raccourcis pris au début : ils étaient nécessaires. Elle assume aussi la décision de tuer 2 ans de travail blockchain après un calcul transparent du coût de maintenance.

Le pattern "double run" est sous-estimé. Trop de boîtes tentent le big bang rewrite et se retrouvent dans un tunnel de 6-12 mois sans feedback. Ici, le nouveau système est en prod rapidement, la migration progressive, et la décommission est réalisée dès que le nouveau système est prêt.

Le passage de 10 bugs critiques/mois à 0, de crash à 15k billets à 5k RPS stable, de 2 mois pour une feature simple à 12h de lead time est impressionnant.

La vraie leçon : le legacy c'est pas une fatalité en startup, mais il faut savoir reconnaître le moment où il faut changer de cap. La levée de fonds leur a donné cette opportunité. Ils l'ont saisie.

Liens :

• Billy : https://www.billyapp.live/fr
• Maria Mokbel : LinkedIn