TDKSOFT Backend Platform

Contexte

Les applications clientes de TDKSOFT ont toutes besoin des mêmes briques : authentification, base de données, stockage de fichiers, messagerie. Les recréer pour chaque projet, ou dépendre d'un service cloud tiers, coûte cher et crée des incidents.

Problème et contraintes

• Une application cliente ne doit connaître qu'une URL, un identifiant de projet et des clés, jamais la topologie interne.
• Une isolation forte entre clients.
• Des composants open source, hébergeables sur notre propre infrastructure.

Décisions d'architecture et compromis

Dix décisions d'architecture, une par brique :

• Une base de données par projet : isolation plus forte qu'un schéma partagé, au prix de davantage de bases à opérer.
• Plan de contrôle en Java/Spring à architecture hexagonale.
• Keycloak pour l'identité, PostgREST pour l'API de données, SeaweedFS pour le stockage objet, NATS JetStream pour la messagerie, APISIX comme passerelle.
• Infrastructure décrite en code : OpenTofu, Ansible, Helm et Argo CD ; secrets chiffrés avec SOPS et age.

Sécurité et livraison

• Livraison par phases avec validation humaine à chaque étape : 10 rapports de phase versionnés dans le dépôt.
• CI GitHub Actions, chart Helm du plan de contrôle, secrets jamais en clair dans Git.

Résultats et état actuel

• Premier déploiement réel effectué (phase 9) ; la plateforme n'a pas encore d'application cliente en production.
• 66 fichiers de tests dans le dépôt.