ArtiConnect

Le problème hérité

Tout reposait sur deux apps Flutter qui lisaient et écrivaient Firebase en direct, sans aucune couche serveur, déjà déployées sur les stores, donc impossibles à mettre à jour de force.

• Toute la logique métier (réservation, disponibilités, zones, CRM) piégée côté client et dupliquée entre les deux apps.
• Rétro-compatibilité non-négociable : l’API doit écrire les données dans le format exact attendu par Flutter, bugs hérités compris.
• ~42 500 lignes de Dart, du code mort, une UX dégradée. Mais une traction et une conversion bien réelles à préserver.

La stratégie : moderniser sans big-bang

Plutôt qu’un rewrite risqué, un plan product-first en Strangler Fig : rapatrier le métier hors des apps, étape par étape, derrière une API testée et observable.

• Reverse-engineering des deux apps Flutter (diagrammes de classes générés, code-doc) pour en extraire le cahier des charges de l’API, et ne migrer que les features réellement câblées.
• Conserver Firebase, différer PostgreSQL : décision datée et réversible. L’architecture hexagonale permet de basculer plus tard en changeant une seule ligne, le jour où le coût le justifie.
• Auth Firebase conservée via un échange de tokens : mobile en Bearer, web en cookie HttpOnly posé par un BFF Next.js.

Une API Rust qui centralise tout le métier

Le socle unique sur lequel le web et le mobile se branchent : Axum en architecture hexagonale, dont la pureté du domaine est imposée par un test d’architecture qui casse la compilation à la moindre violation.

• 94 endpoints : profils, services, disponibilités, CRM pro, cycle de vie complet des rendez-vous, abonnements Stripe, dashboard analytics (acquisition / conversion / rétention).
• 25 ports repository, 14 implémentations Firestore, 15 intégrations externes (Stripe Connect, RevenueCat, Twilio, Brevo, PostHog, SIRET…).
• Typage end-to-end via OpenAPI code-first : web et mobile consomment le même contrat (types + SDK + schémas Zod générés) ; la CI casse le build si le spec est périmé.

Plateforme web Next.js, double surface

~63 000 lignes, 74 pages : une surface particulier et une surface pro, entièrement typées via le contrat de l’API.

• Particulier : recherche d’artisans (Google Maps), wizard de réservation multi-étapes, compte, avis, blog.
• Pro : calendrier (FullCalendar), CRM clients, onboarding, prestations, zones de service, intervenants, plus un panneau d’admin (modération, analytics).
• Stripe côté web, i18n, et Sentry en tracing distribué jusqu’à l’API Rust.

Monorepo & apps mobiles React Native

Migration vers un monorepo pnpm + Turborepo avec du code partagé web ↔ mobile, pour réduire à zéro le coût marginal d’une nouvelle surface.

• 5 packages partagés : client API / SDK / Zod (source unique de vérité), logique domaine, couche data (TanStack Query + cache chiffré + outbox), tokens de design.
• Refonte des apps mobiles en React Native / Expo sur ce socle typé, avec routing, design system, couche data et enforcement d’architecture partagés avec le web : un seul contrat d’API pour toutes les surfaces.

Infrastructure & production

Du code en production sur l’API et le web, avec l’infrastructure et l’outillage qui vont avec, montés de A à Z.

• Tout l’hébergement provisionné par mes soins : Kubernetes managé sur Scaleway (haute disponibilité + auto-scaling) pour l’API, Vercel pour le web.
• CI multi-gate : fraîcheur du spec OpenAPI, anti-régression du nombre de tests, complétude des variables d’environnement (née d’un vrai postmortem).
• Déploiements Helm / Kubernetes atomiques (rollback documenté), images Docker distroless non-root.
• Observabilité : OpenTelemetry côté API, Sentry tracé du navigateur jusqu’au Rust, PostHog consent-aware, rate-limiting. 41 ADR et 2 postmortems écrits.

Stack technique