Lab · Proof technique
Kestrelia
Plateforme SaaS de veille tarifaire aérienne. L'utilisateur définit ses critères au détail près — route, budget, compagnies, horaires, escales, bagages — et reçoit une alerte quand le marché les rencontre. Le produit le plus personnalisable de sa catégorie, et le banc d'essai des patterns que je livre en mandat.
- Statut
- En production
- Type
- SaaS B2C
- Marché
- Amérique du Nord
- Rôle
- Produit + proof
Le problème
Les outils de veille vols décident à votre place.
Hopper est une agence de voyage doublée d'un produit financier : son intérêt est que vous réserviez chez lui. Google Flights et Skyscanner affichent ce qui est en ligne à l'instant, sans surveiller pour vous. Les infolettres de deals envoient à tout le monde la même offre, sans égard à votre aéroport de départ ni à vos contraintes.
Kestrelia prend le parti inverse : un outil de surveillance qui n'encaisse rien sur la réservation, dont la seule valeur est la précision du filtre. Le lancement cible l'Amérique du Nord — Montréal, Toronto, Vancouver, New York, Los Angeles, Chicago — là où les routes transatlantiques rendent l'écart de prix le plus visible.
Stack technique
Hexagonale, asynchrone, sans dépendance captive.
Architecture
NestJS hexagonal + Angular 19
API NestJS découpée en domaine, application et infrastructure : la logique métier ne connaît ni Prisma, ni Stripe, ni le fournisseur de vols. Application Angular 19 en composants standalone et Signals. Monorepo Turborepo + pnpm, PostgreSQL via Prisma, Biome, Vitest et Playwright.
Traitement asynchrone
Workers autonomes BullMQ + Redis
Le scan des routes et le matching d'alertes tournent dans des
workers séparés de l'API, dimensionnables indépendamment. Cache
Redis à TTL adaptatif — 30 minutes en régime normal, 10 minutes
lorsqu'un prix approche à moins de 10 % du seuil d'une alerte.
Protection anti-stampede par verrou SETNX et
déduplication des requêtes en vol ; toute panne Redis retombe en
appel direct au fournisseur plutôt que d'échouer.
Agrégation multi-fournisseurs
Un port, trois adaptateurs
Duffel, Amadeus et FlightAPI implémentent la même interface de recherche. Duffel seul est actif au lancement — les autres restent câblés derrière un drapeau de fonctionnalité, pour limiter le coût d'API et la surface de bogue. Ajouter ou retirer un fournisseur ne touche qu'une ligne d'injection. C'est le pattern de résilience multi-fournisseurs que je livre en mandat.
Infrastructure
AWS décrit en Terraform
API et workers sur ECS Fargate, site de prélancement sur S3 et CloudFront, PostgreSQL sur RDS, Redis sur ElastiCache, secrets dans Secrets Manager. Livraison continue par GitHub Actions en OIDC, sans clé d'accès longue durée stockée quelque part.
Ce que ça démontre
L'architecture a déjà survécu à un changement d'hébergeur complet.
En mai 2026, Kestrelia a quitté Railway et Vercel pour une infrastructure AWS décrite en Terraform. La migration n'a touché que la couche infrastructure : aucun changement dans le domaine, aucun dans les cas d'usage. C'est précisément ce que l'architecture hexagonale est censée garantir, et c'est rarement vérifié en conditions réelles.
Un prospect qui demande si je sais tenir des traitements asynchrones à volume, encaisser la panne d'un fournisseur tiers sans interrompre le service, ou décrire une infrastructure de production en code — la réponse est ce dépôt, pas une diapositive.
Vous voulez ces patterns dans votre stack ?
Traitement asynchrone, résilience multi-fournisseurs, architecture qui survit à un changement d'infrastructure. C'est exactement ce que je construis en Plateforme 90 : votre application métier ou votre produit SaaS en production en 90 jours, avec le même niveau d'exigence.