Deutsch
English
Italiano
Español
Chez Infomaniak, l’innovation ne consiste pas seulement à créer de nouveaux produits performants, mais à les rendre plus efficaces, plus durables et plus responsables. Dans cet article, nos ingénieurs Matthieu et Tristan racontent comment ils ont repensé Custom Brand, une fonctionnalité de kSuite qui permet aux entreprises d’utiliser leurs outils de collaboration en ligne (Messagerie instantanée, Drive, Mail, Calendrier, etc.) avec leur propre domaine et identité visuelle. Grâce à Go, Kubernetes et une approche d’écoconception, le service est passé de 2 855 pods à seulement 2, tout en devenant plus fiable, plus évolutif et plus durable.
Par Tristan Smagghe (Software Engineer) et Matthieu Mabillard (Engineering Manager), chez Infomaniak.
Pourquoi changer ?
Au départ, il s’agissait d’un nouveau service, lancé avec très peu d’utilisateurs. L’objectif : proposer un moyen simple de personnaliser les applications kSuite avec son propre domaine (ksuite.son-domaine.com au lieu de ksuite.infomaniak.com).
L’architecture choisie était volontairement simple : un client = un pod Kubernetes, avec un serveur Apache chargé de réécrire les adresses et de faire le lien entre les domaines clients et les applications kSuite.
Ce modèle a bien fonctionné au début, mais avec l’adoption rapide de cette possibilité de personnalisation par les entreprises, des limites sont apparues :
- Des milliers de pods à maintenir
- Des ressources CPU et RAM réservées énormes sans être utilisées
- Un monitoring saturé, au point d’être fortement perturbé
- Une équipe d’astreinte régulièrement réveillée la nuit
Autrement dit, ce qui semblait robuste au début est devenu un frein à l’échelle.
La nouvelle approche : mutualiser, simplifier et moderniser
L’idée centrale de la refonte a été simple : mutualiser ce qui était dupliqué. Au lieu d’un pod Kubernetes par client, quelques pods suffisent désormais à gérer des centaines d’instances personnalisées.
Pour y parvenir, nous avons réécrit le système en Go, un langage conçu pour la performance et la concurrence. Chaque pod agit désormais comme un reverse proxy intelligent, capable de router dynamiquement les requêtes selon le trafic et de s’ajuster automatiquement à la charge.
L’infrastructure n’est plus figée : elle s’auto-adapte. En période creuse, quelques pods suffisent ; lors des pics d’activité, Kubernetes en déploie davantage, puis les libère. Cette élasticité permet d’utiliser juste ce qu’il faut de ressources, au bon moment.
Autre changement majeur : la configuration et la gestion des certificats SSL/TLS ont été centralisées. Cela simplifie l’administration, améliore la sécurité et facilite les mises à jour.
« Nous sommes passés d’un système rigide et coûteux à un modèle agile, scalable et sobre, » résume Matthieu Mabillard, Engineering Manager chez Infomaniak.
Les résultats parlent d’eux-mêmes
Au-delà de la réduction impressionnante des ressources, la refonte a permis un véritable gain opérationnel. Même si les requêtes ne sont pas traitées plus vite qu’avant, nous avons gagné en performance sur les opérations de maintenance, les déploiements et la capacité à faire évoluer le service sans risque.
Suivi Grafana du nombre de pods requis en temps réel suite à la migration
- Pods Kubernetes : de 2 855 à ~2 en moyenne ( -99,93%)
- RAM réservée : de 748 GB à ~2 GB ( -99,73%)
- CPU réservés : de 28,55 à ~0,2 ( -99,30%)
- Monitoring rétabli et fiabilisé
- Compatibilité multi-clusters et préparation multi-datacenters
Ces gains d’efficacité ne se limitent pas aux performances. Ils permettent de réallouer les ressources vers d’autres projets stratégiques, tout en réduisant significativement l’empreinte carbone globale de l’infrastructure.
Un impact direct sur l’écologie et la fiabilité
Moins de serveurs, moins de chaleur dégagée, moins d’énergie consommée. Au-delà des chiffres, c’est une vraie démarche d’écoconception : réfléchir à la consommation dès la conception du service.
Avant la refonte, le monitoring ne pouvait plus suivre. Aujourd’hui, nous disposons d’une vision claire de chaque requête : combien de ressources sont utilisées, quelles briques consomment le plus, et où agir pour continuer à progresser.
Cette visibilité nous permet d’ajuster en continu et d’anticiper les besoins, sans jamais compromettre la stabilité.
Une migration totalement transparente
La migration a été réalisée progressivement, en commençant par nos propres services internes. Grâce à une approche en canary, le basculement a été transparent : aucune interruption notable et pas de perte de performance côté utilisateurs.
En une semaine, l’ensemble du service est passé sur la nouvelle architecture, avec seulement un incident mineur rapidement corrigé. Le résultat : une refonte invisible pour les utilisateurs, mais spectaculaire pour les équipes techniques.
5 conseils pour éviter la dette technique
Moins de serveurs, moins de chaleur dégagée, moins d’énergie consommée. Au-delà des chiffres, c’est une vraie démarche d’écoconception : réfléchir à la consommation dès la conception du service.
Cette refonte met en lumière plusieurs bonnes pratiques :
1. Mutualiser ce qui peut l’être
Le scaling horizontal n’est pas un problème en soi : il doit simplement être conçu intelligemment. Dans l’ancienne architecture, chaque client était isolé dans son propre pod. Dans la nouvelle version, le scaling horizontal est toujours là, mais les clients partagent désormais les ressources, ce qui permet de scaler beaucoup plus efficacement.
2. Ne pas sur-concevoir au lancement
Mais prévoir une trajectoire d’évolution. L’écoconception est souvent la conséquence logique d’une bonne architecture, pas un effort séparé.
3. Choisir la bonne technologie pour le bon usage
Apache/PHP était logique pour démarrer rapidement, mais Go s’est révélé beaucoup plus efficace à l’échelle dans ce contexte.
4. Centraliser la configuration et le monitoring
Pour éviter de piloter à l’aveugle. Impossible d’optimiser sans comprendre ce qui se passe réellement.
5. Favoriser les migrations progressives
Canary, feature flags et déploiements incrémentaux réduisent les risques et accélèrent l’apprentissage.
Une aventure humaine et un tournant culturel
Ce projet a aussi une dimension humaine forte. Il a été confié à Tristan Smagghe, alors stagiaire. Guidé par Matthieu et les équipes, il a conduit cette refonte de bout en bout. Embauché depuis, il travaille aujourd’hui sur notre nouvelle plateforme d’hébergement basée sur Node.js et Go, qui servira de socle à la future offre WordPress optimisée d’Infomaniak.
« Ce projet montre qu’un stagiaire bien encadré peut avoir un vrai impact. Chez Infomaniak, on ne donne pas des maquettes à tester, mais des infrastructures à faire évoluer, » souligne Matthieu Mabillard.
Cette transformation s’inscrit aussi dans un changement culturel plus large. Historiquement centrés sur Laravel/PHP et Angular, nous avons aujourd’hui la taille et les compétences pour utiliser le bon langage pour le bon usage : Go pour le cloud, Node.js pour le temps réel et PHP qui reste un langage stratégique, fiable et mature.
Cette approche nous permet d’aligner nos ambitions techniques avec nos valeurs : efficacité, durabilité et souveraineté.
Conclusion
Diviser par cent l’empreinte d’une infrastructure sans sacrifier la performance n’a rien d’un miracle : c’est le résultat d’une architecture repensée, d’une équipe impliquée et d’une vision à long terme. C’est aussi une preuve que l’écoconception n’est pas un compromis, mais une source d’innovation.
Cette refonte nous permet de poursuivre notre mission : construire un cloud européen éthique, performant et respectueux de l’environnement.
En savoir plus
Photo Collect garantit sa souveraineté numérique avec le Public Cloud d’Infomaniak
vendredi 31 octobre 2025
