Un dimanche, un peu après minuit, une de nos applications est tombée en panne. Pas d'alerte, pas de notification, rien. Aucun outil ne surveillait le service en continu : on l'a appris le lendemain matin, grâce au message d'un utilisateur, pas grâce à notre propre système.
Ce genre de moment, on ne le vit jamais deux fois de la même façon. La première fois, on corrige le bug. La deuxième, on se pose une question plus profonde : est-ce que le problème, c'est vraiment ce bug précis, ou la façon dont on construit nos produits en général ?
Chez Kolixia, ça a été le déclic. Et ça a changé la manière dont on lance chacun de nos produits.
Le problème d'une infrastructure « par projet »
Avant, chaque nouveau produit repartait de zéro : un nouvel hébergement à configurer, une nouvelle base de données à installer, un nouveau certificat de sécurité à mettre en place, et, le plus souvent, aucune surveillance en continu tant qu'on n'avait pas pris le temps d'en ajouter une, projet par projet.
Sur le papier, ça fonctionne : chaque application est indépendante, isolée, personne ne dépend de personne. Dans les faits, ça veut dire qu'on refait le même travail à chaque lancement, qu'on prend les mêmes risques de sécurité à chaque fois qu'on doit y repenser soi-même, et surtout qu'on découvre les problèmes après coup, souvent grâce aux personnes qui utilisent le produit, comme cette nuit-là.
Ce n'est pas une question de compétence. C'est une question de structure : traiter chaque projet comme une île isolée, ça marche pour un seul produit. Ça devient intenable dès qu'on en fait tourner plusieurs en même temps, en continuant à en ajouter de nouveaux.
Un socle commun, pas une infrastructure par produit
La décision qu'on a prise chez Kolixia a été simple à formuler, plus structurante à assumer : arrêter de construire une infrastructure par produit, et construire un socle technique commun sur lequel chaque produit vient se brancher.
Concrètement, tout repose sur un serveur unique organisé en trois grands piliers qui communiquent entre eux, plus une couche applicative où vivent nos produits.
Le pilier routing est la porte d'entrée : tout le trafic qui arrive de l'extérieur passe par lui avant d'être redirigé vers le bon produit, avec la sécurité (chiffrement SSL) gérée à un seul endroit plutôt que reconfigurée à chaque lancement.
Le pilier data centralise le stockage : les bases de données et le cache de tous nos produits vivent ici, avec une seule façon de les sauvegarder, de les sécuriser et de les faire évoluer, au lieu d'une configuration différente pour chaque application.
Le pilier monitoring surveille l'ensemble en continu : c'est précisément ce qui manquait ce fameux dimanche soir. Aujourd'hui, une panne, un ralentissement ou une anomalie déclenche une alerte automatique, et on est prévenus avant nos utilisateurs, pas après.
Au-dessus de ces trois piliers, nos produits (Woryu, Watcher, Space, Tickety) tournent chacun de leur côté, mais s'appuient tous sur la même base déjà éprouvée.
Pour les curieux : derrière ces trois mots (routing, data, monitoring), il y a de vrais outils, choisis pour ce qu'ils font de mieux. Traefik dirige le trafic vers le bon produit et gère nos certificats de sécurité. Postgres, Redis et Neo4j stockent et mettent en cache les données de chaque application. Et une dizaine d'outils de surveillance (Prometheus, Grafana, Loki...) travaillent ensemble pour qu'on ait, à tout moment, une vue d'ensemble de ce qui se passe sur nos serveurs, et pas seulement quand quelque chose casse.
Ce que ça change concrètement
Le bénéfice le plus visible, c'est la rapidité : lancer un nouveau produit ne demande plus de reconstruire une infrastructure entière. Il vient simplement se brancher sur un socle qui existe déjà, qui est déjà sécurisé, et qui est déjà surveillé. Le prochain produit qu'on lancera prendra une fraction du temps qu'a pris le tout premier.
Mais le bénéfice le plus important, c'est pour les personnes qui utilisent nos produits au quotidien. Une infrastructure mutualisée et surveillée en continu, ça veut dire :
- des incidents détectés en quelques minutes plutôt qu'en quelques heures, ou en attendant qu'un utilisateur nous signale le problème ;
- une sécurité gérée de façon cohérente sur l'ensemble de nos produits, plutôt que renforcée produit par produit, au gré du temps disponible ;
- une fiabilité qui s'améliore avec chaque nouveau produit, puisque chacun profite des ajustements faits sur les précédents, au lieu de repartir avec les mêmes angles morts.
Autrement dit : ce n'est pas un choix technique qui reste dans nos coulisses. C'est une décision qui se traduit directement par moins d'interruptions de service, une détection plus rapide des problèmes, et une base plus solide pour chaque nouveau produit qu'on construit.
Une preuve plutôt qu'une promesse
Aujourd'hui, plus de trois produits tournent déjà sur ce socle commun (Woryu, Watcher, Space et Tickety), chacun avec ses propres besoins, tous surveillés et sécurisés de la même façon. Ce n'est pas une architecture théorique : c'est ce qui fait tourner nos produits en ce moment même, à chaque instant où vous les utilisez.
Et cette base n'est pas figée. Chaque nouveau produit qui s'y branche l'éprouve un peu plus, et chaque ajustement qu'on y apporte profite immédiatement à tous les produits déjà en place, pas seulement au dernier arrivé. C'est ce qui nous permet de dire que notre prochain produit sera plus fiable dès son premier jour que ne l'était le tout premier.
Et on ne compte pas s'arrêter là. Dans les prochaines semaines, on va présenter publiquement chaque brique de cette infrastructure en détail : les décisions qu'on a prises, les compromis qu'on a acceptés, et les ajustements en cours pour la renforcer encore. Parce qu'on pense qu'un produit fiable, c'est aussi un produit dont on peut expliquer les fondations sans rien cacher.
Vous êtes curieux de la stack technique derrière un des produits que vous utilisez ? Dites-le-nous, c'est aussi comme ça qu'on choisit les prochains sujets à détailler.