Industrialiser son infrastructure en 2026 : du one-shot au repeatable

La plupart des équipes ops gèrent leur infrastructure en mode réactif : quelqu’un demande un serveur, on le crée manuellement. Ce mode ne scale pas — à mesure que le nombre d’équipes produit grandit, l’équipe ops devient un goulot d’étranglement.

Le problème du “ticket-driven infrastructure”

Le symptôme classique : les développeurs ouvrent des tickets à l’équipe infra pour chaque besoin — nouvelle base de données, certificat TLS, accès S3. L’équipe infra devient un service desk. Les délais s’allongent, la frustration monte des deux côtés.

Les causes profondes : pas de self-service pour les ressources standard, connaissances non documentées dans les têtes de quelques personnes, pas de templates réutilisables.

Platform Engineering : construire le “developer platform”

Platform Engineering est l’approche qui répond à ce problème structurellement. L’équipe platform construit une Internal Developer Platform (IDP) — un ensemble d’outils et d’abstractions qui permettent aux équipes produit de provisionner des ressources de manière autonome.

Équipe Platform                    Équipes Produit
     │                                   │
     │  ← Backstage (portail self-service) ─ │
     │  ← Terraform modules validés ────── │
     │  ← Templates de pipelines CI/CD ─── │
     │  ← Runbooks et documentation ─────  │
     │                                     │
     └─── Golden paths : la voie recommandée ───┘

Golden Paths : le chemin recommandé

Un “Golden Path” est le chemin opinionné et pré-validé pour créer quelque chose — un nouveau service backend, une base de données, un pipeline de déploiement. Suffisamment simple pour être suivi sans expertise ops, suffisamment sécurisé pour être approuvé par défaut.

# Exemple de golden path via Backstage
backstage create-app
# → Choisir le template "Python API service"
# → Renseigner : nom du service, équipe owner, tier (critical/standard)
# → Backstage crée automatiquement :
#     - Repository GitLab avec pipeline CI/CD
#     - Namespace Kubernetes
#     - Service Account avec droits minimaux
#     - Dashboard Grafana
#     - Entrée dans le catalogue de services

GitOps : l’état désiré dans Git

GitOps pousse le principe IaC à son terme : tout l’état de l’infrastructure est dans Git, et des outils (ArgoCD, Flux) synchronisent automatiquement le cluster avec ce qui est dans le repo.

# ArgoCD Application : synchroniser un namespace Kubernetes avec un repo Git
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp-production
spec:
  project: default
  source:
    repoURL: https://gitlab.example.com/infra/k8s-manifests
    targetRevision: main
    path: apps/myapp/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true      # supprimer les ressources supprimées du repo
      selfHeal: true   # resynchroniser si quelqu'un modifie directement le cluster

Le résultat : tout changement d’infrastructure passe par une PR, est reviewé, et est déployé automatiquement. Pas de “j’ai changé ça directement sur le cluster en urgence et j’ai oublié de le documenter”.

Les indicateurs d’une infrastructure industrialisée

• Time-to-provision d’un nouveau service : heures, pas jours
• Pourcentage de ressources gérées en IaC : > 90%
• Toute modification d’infrastructure passe par une PR
• Un développeur peut déployer en production sans intervention ops
• Les rollbacks sont automatisés et prennent moins de 5 minutes

Nos formations CI/CD, Kubernetes et Terraform couvrent les briques techniques de cette industrialisation.