Aller au contenu
2 min de lecture Keyson

Construire un SaaS full stack en lead tech

Retour sur les choix techniques de Cercly — de l'environnement de dev à la prod, en passant par l'archi micro-services, le mobile et l'accélération par l'IA.

  • Architecture
  • Engineering
  • DevOps
  • SaaS

Piloter l’intégralité d’une stack technique — du design à la production — est un exercice de coordination autant que de compétence. Cercly, notre plateforme SaaS de gestion d’associations, en est l’illustration concrète.

Les choix de stack

Le cœur métier repose sur Sylius en mode headless, exposé via API Platform. Sylius apporte une base solide pour les ressources e-commerce (adhésions, paiements, catalogue) sans partir de zéro. API Platform structure l’exposition REST de façon typée et documentée nativement. Symfony tient le tout : injection de dépendances, Messenger pour les traitements asynchrones, FrankenPHP en serveur.

Le plan opérateur est traité séparément avec NestJS — architecture modulaire, typage fort, cycle de déploiement indépendant. Entre les frontends et les APIs, des BFFs NestJS dédiés à chaque interface. Ce pattern isole chaque client des évolutions API, centralise la gestion de session et allège les frontends.

Les interfaces sont en Next.js App Router — un portail public, un dashboard association, un dashboard opérateur, chacun avec son propre cycle de release. Une app mobile iOS/Android avec Expo complète le dispositif. L’ensemble des interfaces partage un design system commun construit sur TailwindCSS, ce qui garantit la cohérence visuelle sans duplication.

L’architecture event-driven là où ça compte

Certaines parties du système — notifications, paiements Mollie, synchronisations inter-domaines — passent par RabbitMQ. Le choix est délibérément ciblé : on n’event-drive pas tout, on event-drive ce qui doit être découplé et resilient. Le reste reste synchrone et lisible.

L’infra comme partie du produit

L’environnement de développement local tourne sur Docker Compose avec Traefik, des domaines .local par service, et un Makefile qui clone tous les repos et démarre l’environnement en une commande. Zéro friction pour onboarder.

Le staging et la production sont gérés en GitOps : Terraform pour l’infra AWS, GitLab CI pour chaque repo — lint, tests unitaires et e2e (PHPUnit, Behat, Jest, Playwright), build Docker, push ECR, déploiement via SSM. Chaque merge sur la branche concernée déclenche la chaîne. L’accès à la prod ne passe jamais par SSH direct.

L’IA comme levier d’exécution

Claude et ChatGPT sont intégrés dans la boucle de développement quotidienne — pas pour remplacer les décisions d’architecture, mais pour accélérer l’exécution une fois ces décisions prises. Génération de code boilerplate, debugging, rédaction de specs, revue de configuration. Sur certains sujets, le gain est réel et mesurable.

La vraie difficulté n’est pas de maîtriser chaque technologie individuellement. C’est de tenir la cohérence de l’ensemble sur la durée, quand chaque couche évolue à son propre rythme.

Continuer la lecture

Quelques articles relies pour renforcer le maillage interne et prolonger les sujets techniques voisins.

7 min

RabbitMQ dans une plateforme SaaS : où le mettre, et pourquoi

Quand utiliser RabbitMQ dans une plateforme SaaS, quels flux lui confier, et comment s'en servir pour découpler le provisioning, les notifications et certains traitements métier sans event-driver tout le système.

  • Integrations
  • Engineering
  • Architecture
Lire la note