Lorsque l’on se lance dans le Platform Engineering, la question la plus fréquente reste : « Par où commencer ? »
Cette interrogation, simple en apparence, cache une complexité sous-jacente, car elle touche à la fois à des considérations techniques et organisationnelles. Nous vous partageons ici notre réflexion, issue de nos expériences, pour aborder ce premier jalon stratégique.
Notre approche repose sur une séparation des responsabilités entre infrastructure et plateforme, et un démarrage pragmatique avec des outils simples :
Cette méthodologie s’inscrit dans une démarche itérative, permettant à chaque équipe de monter en puissance tout en minimisant les risques initiaux.
Dès les premières étapes, une distinction claire entre infrastructure et plateforme s’impose.
Pour mieux refléter les contextes de nos clients, nous avons adopté une approche où :
Cette séparation des responsabilités facilite non seulement l’alignement des équipes sur leurs missions respectives, mais permet aussi de s’adapter aux réalités organisationnelles.
Plutôt que de se perdre dans une ambition démesurée, nous avons opté pour un noyau minimaliste, capable de poser les bases sans se surcharger inutilement.
Sous l'impulsion d'Aurélien Maury, nous avons adopté Terraform pour la création des ressources et Ansible pour leur configuration. Cette combinaison nous permet de gérer efficacement l’infrastructure avec des outils complémentaires :
Ces choix impliquent la création et la gestion d’un couple Access Key / Secret Key auprès du fournisseur cloud, nécessaire au fonctionnement de Terraform et Ansible.
Pour organiser notre travail et assurer la traçabilité, nous avons centralisé nos scripts IaC dans un repository Git. Ce dernier joue un rôle pivot en :
Cette approche soulève néanmoins deux questions clés :
La question du stockage de ce premier repository Git se pose, et on revient rapidement à l'œuf et la poule : ce repo doit-il appartenir à la plateforme ?
Notre réponse est clairement non. Qu'il soit hébergé sur un service SaaS (GitLab, GitHub, Bitbucket – choisissez votre poison) ou sur une machine interne (mais régulièrement sauvegardée), ce nucleus doit être stocké en dehors de la plateforme pour permettre une reconstruction complète rapide. Ce choix garantit non seulement une indépendance vis-à-vis des premières capacités déployées, mais également une résilience en cas de défaillance.
L’accessibilité est cruciale dans la gestion des capacités d’une plateforme. C’est pourquoi nous avons fait du DNS une priorité dès les premières étapes.
Pour répondre à ce besoin, nous avons opté pour une solution standard et open-source : Bind9.
Bind9 a été déployé sur une machine dédiée (via Ansible/Terraform), en incluant la création d’un secret (rfc2136_tsig_secret) pour faciliter l’intégration à venir.
Limite identifiée : L’absence d’automatisation complète pour nettoyer les enregistrements DNS nous a contraints, dans un premier temps, à autoriser des connexions SSH vers la machine Bind9, en collaboration avec l’équipe infrastructure.
Pour OXP, nous avons fait le choix de Kubernetes comme socle d’exécution.
Les scripts IaC déployés par l’équipe infrastructure permettent de :
Ce cluster racine est essentiel pour héberger les premières capacités et inclut des secrets critiques comme le rfc2136_tsig_secret pour la gestion DNS.
Dans le cadre d’OXP, nous avons choisi d’instancier un cluster Kapsule, hébergé au sein d’un compte Scaleway.
Une fois le cluster initial opérationnel, l’équipe infrastructure délègue entièrement la suite des opérations à l’équipe plateforme. Cela inclut :
Cette organisation nous a permis de structurer efficacement le démarrage de la plateforme tout en clarifiant les rôles et responsabilités. Cependant, certains points restent perfectibles, en particulier la gestion des droits et la collaboration sur les scripts IaC.
On peut imaginer la mise à disposition de ces scripts sous forme d'API (via Caddy ou un produit tel qu'Ansible AWX). Mais cette délégation d’utilisation est un projet en soi et ne fournit pas forcément de valeur ajoutée immédiate.