CNP — Internal Developer Platform
Plateforme repository-first qui embarque une application dans un workflow cloud-native standardisé, sans qu'elle écrive son pipeline.
Le problème
Onboarder une application dans un workflow cloud-native prend des jours, et le délai dépend surtout de qui, dans l'équipe plateforme, accepte d'aider. Chaque équipe réinvente son pipeline, avec ses propres approximations sur la sécurité et les conventions.
CNP fait de ce parcours un produit : le chemin standard devient le chemin le plus facile.
Comment ça marche
L'approche est repository-first. Une GitHub App instrumente le dépôt de l'équipe applicative : elle y installe le pipeline GitHub Actions, qui construit l'image, la publie sur GHCR et déclenche le déploiement sur Azure AKS.
Derrière, une API FastAPI tient l'état des applications et de leurs environnements, sur PostgreSQL via SQLAlchemy, avec les migrations gérées par Alembic. L'environnement de développement complet tourne en Docker Compose.
Python 3.12 · FastAPI · PostgreSQL · SQLAlchemy · Alembic · GitHub App · GitHub Actions · Docker Compose · Kubernetes · Azure AKS · GHCR
Ce que j'ai fait
- Développement de l'API de la plateforme et de son modèle de données (applications, environnements, déploiements).
- Intégration GitHub App : installation, permissions, écriture du pipeline dans le dépôt cible.
- Chaîne build → GHCR → déploiement AKS.
- Migrations Alembic et environnement de développement reproductible.
Résultat
Une équipe applicative passe du dépôt vide au premier déploiement sans écrire une ligne de pipeline. [TODO: métrique] time-to-first-deploy mesuré avant et après.
Ce que j'en retire
Une plateforme interne n'est pas un outil, c'est un produit avec des utilisateurs qui ont le droit de la contourner. Si le chemin standard n'est pas le plus rapide, personne ne le prend — et on se retrouve avec la gouvernance sur le papier et le chaos dans les dépôts.