DockAir - Équipe SOCLE, 2026-2027
Le socle invisible d'une compagnie aérienne.
DockAir est un projet d'école EPITA d'un an, qui simule le système d'information d'une compagnie aérienne façon Air France-KLM, avec une cinquantaine d'étudiants répartis en urbanistes, développeurs applicatifs, DevOps, leads et une équipe BI. Je dirige l'équipe SOCLE : cinq personnes responsables de la plateforme sur laquelle tout le monde construit.
Mon travail, ce n'est pas d'écrire du code applicatif. C'est de comprendre le besoin de chaque autre équipe, de le traduire en une vraie architecture, puis de la construire et de la livrer sous forme de catalogue de services en self-service, en coordination étroite avec l'équipe DevOps qui branche ensuite les équipes applicatives dessus.
Mission & Périmètre
Une seule plateforme, du premier commit à la production.
Le périmètre était volontairement large : fournir toute la plateforme d'exécution, de la couche physique (VMs, stockage, réseau) aux middlewares (serveurs web/applicatifs, bases de données), et les deux services d'intégration par lesquels les applications ont exclusivement le droit de communiquer : des APIs HTTP synchrones et de la messagerie asynchrone pub/sub.
Il fallait aussi un moteur de simulation temporelle complet, pour que cinq jours d'activité aérienne, réservations, vols, enregistrements, se déroulent en quinze minutes réelles, ainsi qu'un simulateur d'acteurs externes pour incarner les passagers, les aéroports et le réseau IATA.
Contraintes structurantes du cahier des charges : deux environnements strictement isolés, une production accessible uniquement par l'équipe SOCLE, des déploiements entièrement automatisés, de la haute disponibilité, et une plateforme capable de se reconstruire entièrement après un incident majeur sans perdre les données applicatives.
Architecture technique
Kubernetes sur un OS immuable, zero-trust par défaut.
Le cluster tourne sur Talos Linux au-dessus de VMs OpenStack : pas de shell, pas de SSH, pas de gestionnaire de paquets, un OS administré uniquement via une API authentifiée. Cilium remplace entièrement kube-proxy et impose le default-deny au niveau réseau, en eBPF plutôt qu'en iptables.
Envoy Gateway est l'unique porte d'entrée de la plateforme : chaque appel HTTP, externe ou inter-applicatif, y transite, avec le déchargement du TLS et de l'authentification OIDC pour que le code applicatif n'ait jamais à s'en soucier. Tout est déployé via ArgoCD en mode pull, et chaque application reçoit son propre cluster CloudNativePG et son propre vhost RabbitMQ, jamais de base partagée.
Les secrets ne sont jamais manipulés à la main : une architecture Vault en hub-and-spoke les injecte directement dans les pods. La production doit survivre à une perte totale, donc chaque WAL est streamé en continu vers du stockage objet, ce qui permet de reconstruire tout le cluster et de restaurer chaque base à la seconde exacte précédant le crash.
Le catalogue de services
Voir tous
Runtime & Déploiement
Un chart Helm standardisé et un modèle namespace par app et par environnement, synchronisé par ArgoCD.
Livraison GitOps
Zéro accès en écriture au cluster pour les humains : tout changement passe par une Merge Request et la réconciliation pull d'ArgoCD.
Source de vérité & CI/CD
GitLab auto-hébergé pilote toute l'arborescence des groupes, le RBAC et les templates de pipelines via Terraform.
Choix & Trade-offs
Chaque choix ici est un trade-off, pas une best practice.
- Envoy Gateway comme point d'entrée unique de la plateforme plutôt qu'un ingress par appli : toute la sécurité et l'observabilité HTTP tient en un seul endroit, mais toute la plateforme dépend de sa disponibilité, donc il tourne en multi-réplicas derrière une VIP partagée.
- Full GitOps (ArgoCD en pull, tags immuables, zéro accès en écriture même pour SOCLE) plutôt qu'un déploiement manuel : chaque version et chaque rollback ne sont qu'un revert Git, au prix de quelques minutes de latence en plus face à un kubectl apply direct.
- Vault en Hub-and-Spoke (un root vault hors cluster, un tenant vault par environnement) plutôt qu'un vault unique partagé : plus de pièces à opérer, mais un token de staging qui fuite ne peut jamais atteindre les secrets de prod.
Organisation & Feuille de route
Diriger cinq personnes, répondre à quarante-cinq autres.
Diriger l'équipe SOCLE n'a pas voulu dire prendre du recul sur l'infrastructure : je suis celui qui la connaît le mieux dans l'équipe, et je suis resté directement impliqué dedans, à écrire les YAML, à trancher sur l'architecture, à construire la plateforme aux côtés du reste de l'équipe. Tout notre travail est suivi sur un Kanban partagé (Linear), et une bonne partie se joue dans une boucle de feedback étroite avec l'équipe DevOps, puisque ce sont eux qui construisent réellement sur ce qu'on livre.
L'autre moitié du rôle, c'était le mentorat. Quand un membre de l'équipe avait besoin de monter en compétence sur un sujet, je préférais lui donner des ressources et une vraie mission plutôt qu'une réponse toute faite, puis qu'on reprenne ça ensemble en one-on-one : son premier jet, mes questions, et une solution qu'on trouvait ensemble, souvent meilleure que ce que j'aurais écrit seul. 1+1=3.
Le premier semestre s'est terminé dans les temps fin juillet 2026 : environnement de staging en ligne, premier catalogue de services livré, déploiement complet démontré de bout en bout. Le second semestre (septembre 2026 - janvier 2027) consiste à onboarder pour de bon les équipes applicatives, à durcir l'observabilité et l'hébergement BI, et à livrer les moteurs de simulation sur-mesure.