Études de cas

Des décisions techniques confrontées au réel.

Pas de catalogue de technologies. Chaque cas part d’un problème concret, montre les arbitrages réalisés et ce qui a changé après l’intervention.

Édition de logiciel (SaaS)

Europe

Standardiser les images Docker sans réécrire toute la chaîne de livraison

Une organisation SaaS sur Kubernetes voyait sa chaîne CI/CD et son registry se complexifier à mesure que les équipes adoptaient des images de base, des pratiques de build et des contrôles différents.

  • Les équipes disposent d’une baseline commune pour définir une image acceptable
  • Les revues sécurité et plateforme disposent d’un point de contrôle plus clair dans la chaîne CI

Lire le cas

Logiciel et services numériques

Europe

Faire de l’observabilité un outil de décision, pas une collection de dashboards

Une organisation disposait déjà de métriques, logs et tableaux de bord. Pourtant, les décisions de release et d’architecture dépendaient encore fortement du savoir tribal, parce que la télémétrie ne répondait pas aux questions de risque réellement posées.

  • Les signaux nécessaires aux décisions de release ont été distingués de la télémétrie de confort
  • L’extension d’outils a été différée tant que propriété et questions de décision n’étaient pas tranchées

Lire le cas

Logiciel B2B

Europe

Reprendre le contrôle d’une plateforme Kubernetes avant une release critique

Une organisation produit dépendait d’une plateforme Kubernetes partagée. À l’approche d’une release métier à date fixe, le principal risque n’était pas une panne connue mais l’absence de frontières de responsabilité claires entre produit et plateforme.

  • Les critères de release sont devenus explicites entre produit et plateforme
  • Les zones de responsabilité ambiguës ont été transformées en décisions et actions nommées

Lire le cas