Tall3 : SaaS multi-tenant pour concessionnaires automobiles

Aperçu

Tall3 est une plateforme SaaS multi-tenant pour concessionnaires et showrooms automobiles en Arabie saoudite, chacun disposant de sa propre vitrine sur la plateforme. Le backend est une application Laravel qui utilise stancl/tenancy pour le multi-tenant, associée à un frontend Next.js.

J’ai travaillé sur Tall3 comme développeur backend freelance pendant environ deux mois, sur une plateforme de production existante que je n’ai pas construite de zéro. Mon travail a couvert le développement d’API REST, des fonctionnalités propres aux tenants, une intégration WhatsApp auto-hébergée et le backend permettant aux tenants de connecter leur propre nom de domaine à leur vitrine.

Principales contributions techniques

• Domaines personnalisés des tenants (Cloudflare for SaaS) : conception et construction du backend permettant de connecter le domaine propre d’un tenant à sa vitrine, en coordonnant l’achat du domaine via la passerelle de paiement N-Genius, les produits Cloudflare Registrar et SSL for SaaS, l’interrogation asynchrone des statuts et un CORS dynamique par domaine. Détaillé plus bas.
• Intégration WhatsApp (auto-hébergée, Evolution API) : après avoir évalué l’API WhatsApp Business officielle et l’avoir écartée, mise en place de la connectivité WhatsApp sur une passerelle auto-hébergée : connexion de compte par QR code, gestion de sessions pour plusieurs numéros, notifications transactionnelles propres à chaque tenant (confirmations de commande, OTP) et moteur de campagnes marketing avec import de destinataires CSV, messages à modèles, envoi cadencé et suivi en direct de l’avancement et des échecs.
• Travail backend sur la plateforme : développement et maintenance d’API REST et de fonctionnalités propres aux tenants sur le code existant, intégration de l’API Gemini pour des fonctions assistées par IA, création d’outils aidant les nouveaux tenants à migrer leurs données depuis des plateformes concurrentes, et travail sur le cache Redis et des correctifs de performance.

Domaines personnalisés des tenants

La partie la plus complexe du travail backend sur Tall3 : permettre à un tenant d’acheter un vrai nom de domaine et de lui faire servir instantanément sa vitrine existante. theirbrand.com affiche le même site que sa page habituelle tall3.com/cars/{tenantId}, avec un certificat SSL fonctionnel et sans aucun travail DNS manuel de la part de qui que ce soit.

Le flux coordonne une passerelle de paiement, deux produits Cloudflare distincts, ainsi que le backend Laravel et le frontend Next.js :

1. Un tenant recherche et choisit un domaine ; le backend crée une session de paiement auprès de N-Genius, la passerelle de paiement de la plateforme, et le tenant est redirigé vers une page de paiement hébergée pour régler.
2. Une fois le paiement confirmé, le backend enregistre le domaine via l’API Registrar de Cloudflare. C’est une opération asynchrone : une tâche planifiée l’interroge donc jusqu’à son achèvement.
3. L’enregistrement crée automatiquement une nouvelle zone DNS ; le backend y injecte les enregistrements qui pointent vers l’infrastructure de Tall3.
4. Le domaine est ensuite enregistré comme « custom hostname » Cloudflare sur la zone propre de Tall3 : c’est l’étape qui lui procure réellement un certificat, également asynchrone et interrogée.
5. Une fois actif, le trafic du nouveau domaine est terminé à la périphérie de Cloudflare et transféré vers une origine de secours partagée qui exécute le frontend Next.js, un serveur sans configuration propre à un domaine.
6. Comme la configuration multi-tenant existante de la plateforme ne résout que ses propres sous-domaines, le frontend appelle un point d’accès dédié du backend pour associer le nom d’hôte inconnu à un tenant, puis affiche la vitrine de ce tenant.
7. Comme cette vitrine s’exécute désormais sur un domaine extérieur à Tall3, le backend autorise dynamiquement le CORS pour celui-ci, en le vérifiant dans la table des domaines actifs et payés plutôt qu’avec un joker.

Aucun des points d’accès asynchrones de Cloudflare n’envoie de webhook : rien ne prévient donc le backend lorsqu’un enregistrement ou un certificat est terminé. Un job en arrière-plan interroge les deux chaque minute, avec un backoff exponentiel plafonné, et écrit chaque résultat dans une machine à états tenant_domains.status (pending_payment → registering → registered_pending_dns → configuring_dns → provisioning_ssl → active, avec des branches failed/action_required). Il reprend correctement là où un domaine en était resté, même si l’application a redémarré depuis la dernière vérification.

Stack technique

Plateforme en ligne

Découvrir la plateforme : tall3.com

Tall3 est une plateforme propriétaire à laquelle j’ai contribué en tant que freelance. Cette étude de cas décrit mes contributions sans divulguer de code confidentiel, d’identifiants ni de données de tenants.