À retenir

  • Edixos a fait tourner Kubernetes 1.2 en production dès 2015, avec les Third Party Resources — les ancêtres des CRD — bien avant la démocratisation du Kubernetes managé.
  • Notre force est la couche plateforme : contrôleurs Go sur mesure, GitOps et Crossplane qui font de Kubernetes un control plane self-service piloté par API.
  • Des systèmes réels, pas des slides : plus de 1 000 applications migrées pour un leader automobile, plus de 150 CRD pour un PaaS sur mesure, plus des plateformes de ville intelligente et de gestion de l’eau.

Introduction

Certains outils transforment durablement notre manière de concevoir l’infrastructure. Pour Edixos, cet outil s’appelle Kubernetes — et notre histoire commence en 2015, à une époque où l’orchestration de conteneurs n’en était qu’à ses balbutiements. Une décennie d’essais, d’échecs et de systèmes de production livrés a posé les fondations de l’entreprise que nous sommes aujourd’hui.

Nous ne sommes pas une énième société de conseil qui loue des slides. Nous sommes des praticiens qui font tourner Kubernetes en production depuis la version 1.2, qui ont écrit les contrôleurs et opéré les clusters à 3 heures du matin. Cet article vous emmène dans les coulisses : de notre premier nœud master aux plateformes qui font aujourd’hui tourner des milliers d’applications.

Comment Edixos a-t-il débuté avec Kubernetes ?

Tout commence en 2015 avec kubeup.sh et Kubernetes 1.2 en production — un pari audacieux à un moment où presque personne ne faisait tourner des conteneurs à grande échelle. Nous utilisions les Third Party Resources (TPR), ancêtres des CRD, installions les clusters sur AWS avec kops, et avons migré une plateforme SaaS vers cette nouvelle architecture.

Je me souviens encore de ce moment comme si c’était hier : lancer le script kubeup.sh, retenir mon souffle quelques secondes… et voir apparaître notre premier nœud master. Ce n’était pas juste un succès technique. C’était un instant fondateur.

Pour automatiser la création d’environnements, nous avons même développé notre propre contrôleur Kubernetes en Python. C’était artisanal, exigeant… mais incroyablement formateur. En 2016, je me suis lancé dans le conseil Kubernetes, en accompagnant de grandes entreprises en France — du bare-metal aux services managés. Chaque mission a enrichi l’expertise sur laquelle Edixos est bâti.

Ce qui rend Edixos différent

Nous ne nous contentons pas de promettre l’excellence — nous la construisons au quotidien, ligne par ligne, cluster après cluster. Notre expérience vient du terrain : environnements complexes, urgences en production, architectures multi-cloud exigeantes. Ce qui nous distingue, c’est notre capacité à transformer les problématiques complexes en solutions élégantes, durables et maintenables — automatiser vos environnements Kubernetes, concevoir des contrôleurs sur mesure, industrialiser vos pratiques GitOps, toujours avec une obsession pour l’impact.

Travailler avec Edixos, c’est s’entourer de praticiens aguerris et passionnés — des ingénieurs qui écrivent du code de production, pas des PowerPoints, et qui font monter vos équipes en compétence au passage.

Des missions concrètes, pas des PowerPoints

Chez Edixos, nous écrivons des lignes de code, des manifestes Kubernetes, des API robustes et des contrôleurs sur mesure — pas des slides. Chaque mission est un vrai défi technique et un problème métier complexe. Voici quelques-unes des aventures qui ont forgé notre réputation.

🚗 Une révolution cloud pour l’automobile française

Pour un grand constructeur français, nous avons orchestré la migration de plus de 1 000 applications vers le cloud public. Kubernetes en est devenu la colonne vertébrale, avec un control plane centralisé Crossplane et KRM et des contrôleurs custom multi-tenant écrits par nos soins. Résultat : les équipes accèdent à l’infrastructure comme à un service, via des CRD — avec traçabilité, RBAC et gouvernance intégrée, sans aucune friction.

🌐 Une Platform-as-a-Service Kubernetes-first

Inspirés par les modèles KRM et GitOps, nous avons conçu pour un client un PaaS sur mesure basé sur Kubernetes. Au programme :

  • Une API REST et gRPC exposée en self-service
  • Plus de 150 CRD personnalisées
  • Des contrôleurs Go maison automatisant la création de clusters, de workloads et de services managés
  • Un système de reporting automatique, de policy enforcement et de FinOps intégré

Ce n’est pas un produit en boîte. C’est une plateforme vivante, pensée pour la scalabilité, le contrôle et l’autonomie des équipes.

🏙️ Kubernetes au service des villes intelligentes

Pour un acteur du secteur public, nous avons mis en place une plateforme Kubernetes hébergeant des briques critiques : services web, bases de données, brokers Kafka, collecteurs de données urbaines. Chaque microservice, chaque pipeline temps réel y est orchestré de façon résiliente. Ce n’était pas juste un « cluster » : c’était une ville numérique opérée en continu.

💧 L’innovation au fil de l’eau

Grâce à Kubernetes et Kafka, nous avons construit une solution temps réel de monitoring de la consommation d’eau pour un opérateur local : détection de fuites, dashboards en direct, stockage optimisé. La preuve que cloud native et durabilité peuvent aller de pair.

Ces projets le montrent : chez Edixos, nous construisons des plateformes cloud native avec une exigence d’ingénieur. Si vous cherchez un partenaire qui connaît vraiment l’API Machinery, les contrôleurs et le GitOps — et qui parle YAML et Go mieux que PowerPoint — vous êtes au bon endroit.

Conclusion

Le cloud native est un domaine d’exécution, pas de théorie. Chez Edixos, nous ne vendons pas des promesses : nous livrons des architectures qui tournent, des pipelines qui déploient, des plateformes qui évoluent et des API qui simplifient. Ce que nous construisons est pensé pour durer, pour scaler, et pour servir vos équipes.

Et si la documentation officielle ne suffit pas, c’est probablement qu’il faut l’écrire nous-mêmes — en Go, avec des tests, et un controller-runtime bien solide. Que vous souhaitiez industrialiser vos pratiques GitOps, créer des CRD sur mesure, monter un PaaS d’entreprise ou adopter Crossplane pour l’infra-as-code, nos ingénieurs sont déjà passés par là. Et ils y sont encore.

Envie de voir comment ces plateformes fonctionnent vraiment sous le capot ? Lisez pourquoi Terraform ne suffit pas pour le Platform Engineering et comment Kubernetes + CRD offrent un vrai self-service.

Parlons de vos défis Kubernetes avancés

Vous cherchez à automatiser vos opérations, modéliser vos processus métier ou industrialiser vos déploiements sur Kubernetes ? Discutons de vos enjeux et voyons comment l’API Machinery peut vous apporter vitesse, fiabilité et scalabilité.

Réponses directes

Questions fréquentes

Depuis quand Edixos travaille-t-il avec Kubernetes ?

Le fondateur d'Edixos a fait tourner Kubernetes 1.2 en production dès 2015, en s'appuyant sur les Third Party Resources (les ancêtres des CRD) et en installant les clusters sur AWS avec kops. Cette décennie d'expérience terrain précède la plupart des offres Kubernetes managées et fonde notre pratique du platform engineering.

Qu'est-ce qu'un contrôleur Kubernetes sur mesure et pourquoi est-ce important ?

Un contrôleur sur mesure est du code qui observe des Custom Resources et réconcilie en continu l'infrastructure réelle avec l'état déclaré. Il transforme Kubernetes en plateforme pilotée par API : les équipes demandent bases de données, clusters ou workloads via un YAML plutôt qu'un ticket, avec RBAC et gouvernance intégrés.

Edixos déploie-t-il seulement des clusters Kubernetes ou construit-il des plateformes ?

Les deux, mais la valeur est dans la couche plateforme. Edixos écrit des contrôleurs sur mesure, intègre Crossplane et Config Connector, et expose l'infrastructure en API self-service (REST, gRPC, SDK) — afin que les équipes se servent sans friction pendant que la SRE et la sécurité gardent la gouvernance centrale.

Pour quels secteurs Edixos a-t-il construit des plateformes Kubernetes ?

Edixos a livré des plateformes cloud native dans l'automobile (migration de plus de 1 000 applications vers le cloud public), le secteur public (services de ville intelligente sur Kubernetes) et les utilities (monitoring temps réel de la consommation d'eau avec Kafka), entre autres — chacune un système de production, pas une preuve de concept.