Comment une petite équipe fait tourner ses propres produits SaaS

Chez Tadata, nous conseillons nos clients sur leurs plateformes cloud, et nous exploitons aussi nos propres produits : memo, l'application de notes PDF, et les autres applications réunies sur waiyers.com. Cet article décrit une architecture qu'une petite équipe peut réellement opérer, et les leçons qui nous ont coûté du temps ou de l'argent.

La pile en un coup d'œil

Un cluster, plusieurs produits

Tout tourne dans un seul cluster EKS, avec un namespace par produit et par environnement. Un plan de contrôle managé est facturé à l'heure par cluster, et chaque cluster apporte ses propres add-ons, mises à jour et supervision. Pour une petite équipe, un deuxième cluster double le travail d'exploitation bien avant d'apporter le moindre bénéfice.

L'isolation repose sur les namespaces, les network policies, les quotas de ressources et des comptes de service distincts aux droits cloud restreints. Voir Patterns Kubernetes pour les briques de base.

GitOps avec Helm et Argo CD

Chaque service a son chart Helm ; chaque environnement a son fichier de valeurs. Argo CD surveille le dépôt Git et applique les changements. Personne ne lance kubectl apply sur la test ou la prod.

Plus de détails dans Patterns GitOps.

Le local d'abord : Skaffold sur k3s

Les développeurs font tourner toute la pile sur leur portable avec k3s (un Kubernetes léger) et Skaffold, qui construit les images, déploie les mêmes charts Helm avec des valeurs locales et synchronise les modifications de code dans les pods en cours d'exécution. Les paquets Python partagés sont montés dans les pods pendant le développement : une modification de bibliothèque est visible immédiatement, sans publier de nouvelle version.

L'avantage : « ça marche sur ma machine » signifie « ça marche avec les mêmes manifestes qu'en production ». Le prix : une installation plus lourde qu'un docker compose, que nous acceptons parce que les charts sont testés tous les jours.

CI/CD : deux règles

Les images sont construites une fois puis promues, jamais reconstruites par environnement. Une mise en production est un acte délibéré (un tag), pas un effet de bord d'un merge. Détails dans Bonnes pratiques CI/CD.

Connexion : OIDC partout

Tous les produits utilisent Zitadel comme fournisseur OIDC, avec Google comme fournisseur d'identité en amont. Chaque application est un client OIDC standard ; aucune ne stocke de mot de passe. Ajouter un produit, c'est enregistrer un client, pas développer une page de connexion. Les organisations Zitadel correspondent naturellement aux équipes des applications collaboratives.

Backends et paquets

Les backends sont en Python : FastAPI pour les API HTTP utilisées par les applications web et mobiles, gRPC pour les appels entre services lorsque les contrats typés et le streaming comptent. La logique métier vit dans des paquets versionnés publiés dans un registre privé (AWS CodeArtifact), pour Python et npm. Les services sont minces : ils importent des paquets, câblent la configuration et exposent des endpoints.

Les leçons

1. Garder un seul cluster

Voir plus haut. Ne scinder que lorsqu'une contrainte forte (conformité, locataire bruyant, région) l'impose.

2. Des environnements peu coûteux au repos

Un environnement de test allumé en permanence coûte presque autant que la production. Le nôtre est conçu pour être détruit puis recréé à partir de Terraform et de Git quand personne ne teste. Les vraies économies ne portaient pas que sur les nœuds :

Gardez ce qui est long à recréer et coûte peu (DNS, secrets, registres d'images) ; détruisez ce qui se recrée vite et coûte cher.

3. Les secrets vivent dans un gestionnaire de secrets

Les secrets sont stockés dans un gestionnaire de secrets managé et synchronisés dans le cluster. Ils ne passent jamais par Git, les images ou les logs de CI. Un code d'infrastructure qui écrit des secrets ne doit jamais être appliqué sans ses valeurs d'entrée, sous peine d'écraser les vrais secrets par des valeurs vides : une erreur facile à commettre une fois. Voir Gestion des secrets.

4. Suivre le coût par produit dès le premier jour

OpenCost répartit le coût du cluster par namespace, donc par produit et par environnement. « La facture AWS a augmenté » devient « la test du produit X a doublé ses demandes de mémoire la semaine dernière ». Complétez avec les tags de facturation cloud pour ce qui vit hors du cluster. Notre comparateur de prix cloud aide à vérifier si une ligne reste dans la norme.

5. Construire une plateforme, mais petite

Une petite équipe n'a pas besoin d'une plateforme interne complète. Il lui faut une voie balisée : un modèle de chart, un workflow de CI, une façon de se connecter, une façon de publier un paquet. Voir Platform Engineering.

Ce que nous referions