June 2026 DevOps Meetup

Parler 1
**Titre : La plateforme, c'est le peuple : SLA, DORA et confiance pour des milliards de demandes par mois**
Par : Harry Bouras
Rôle / LinkedIn : leader de l'IA et de l'ingénierie Cloud, anciennement responsable de l'organisation API d'une entreprise leader, extrêmement mondiale et multiculturelle. LinkedIn : https://www.linkedin.com/in/harry-bouras/

Résumé :
La plupart des discussions sur la « plateforme » portent sur les outils. Celui-ci ne l'est pas. Diriger l'organisation API d'une entreprise leader, extrêmement mondiale et multiculturelle, interconnectant des décennies de systèmes existants tout en traitant des milliards de requêtes par mois et en évoluant à la fois sur Azure et Google Cloud, m'a appris une leçon à contre-courant à la dure : à ce volume, les plates-formes n'échouent pas sur la technologie, et les factures de cloud n'explosent pas à cause d'un mauvais Terraform. Ils échouent, ou réussissent, sur la façon dont l'organisation est configurée pour posséder, livrer et développer la chose. L'organigramme est la véritable architecture.

Je vais parcourir les leviers qui ont réellement fait bouger l'aiguille, chacun étant ancré dans des moments réels de cette échelle. Comment les SLA, formulés comme étant clairs plutôt que punitifs, modifient le comportement des ingénieurs plus que n'importe quel tableau de bord. Pourquoi accorder dès le départ confiance et temps à une équipe - la chose la plus inconfortable qu'un leader puisse faire, est précisément ce qui améliore la qualité de la construction et réduit les retouches que vous ne pouvez pas vous permettre face à des milliards de demandes. Qu'est-ce qui a véritablement changé lorsque nous avons entraîné une organisation en forme de cascade vers une livraison itérative basée sur Scrum, et pourquoi il s'agissait de raccourcir les boucles de rétroaction, et non d'ajouter des cérémonies. Et comment les métriques DORA sont devenues notre réponse objective à une question sur laquelle chaque équipe se débat : qu'est-ce qui fait réellement le succès d'un ingénieur logiciel senior et qu'est-ce qu'un ingénieur DevOps ?

Ensuite, le noyau humain, raconté honnêtement, ce qui signifie raconté comme une comédie. Ce qui fait un bon manager dans ce monde, raconté à travers les choses dont j'étais certain et sur lesquelles j'avais complètement tort. La blague courante est aussi le vrai point : presque tous les instincts qui ont fait de moi un bon ingénieur ont fait de moi un manager médiocre jusqu'à ce que je le désapprenne.

Enfin, jetez un œil à ce que nous sommes tous sur le point de commettre ensemble : l'IA oblige DevOps à évoluer vers DevSecOps - et les équipes qui le géreront bien seront celles qui ont déjà la culture de propriété, de confiance et de croissance dont parle réellement ce discours.

Parler 2
**Culture post-mortem : transformer les échecs en apprentissage, pas en blâme**
Par : Dani Yelovitch
La plupart des équipes d'ingénierie traitent les incidents comme des embarras à enterrer : une solution rapide, un vague message Slack, et tout le monde passe à autre chose. Cet exposé plaide en faveur d’une approche différente : traiter chaque échec comme un cadeau.
L’idée centrale est celle d’autopsies irréprochables – une pratique lancée chez Google et Netflix où le but n’est pas de trouver un bouc émissaire, mais de comprendre comment le système (personnes, outils, processus) a permis qu’un échec se produise en premier lieu. Si un humain a commis une erreur, la vraie question est : pourquoi le système a-t-il rendu cette erreur facile à commettre ?
La conférence porterait sur :
À quoi ressemble une bonne autopsie (et les raisons courantes pour lesquelles elle se trompe)
Comment mener un examen irréprochable sans qu'il ne devienne une session de blâme par comité
Transformer les actions en changements réels, et non en un document de cimetière que personne ne lit
Renforcer la sécurité psychologique afin que les ingénieurs signalent les problèmes le plus tôt possible au lieu de les cacher
Le point clé à retenir : les équipes qui apprennent des échecs plus rapidement que leurs concurrents produisent de meilleurs logiciels avec moins d'incidents catastrophiques, non pas parce qu'elles disposent de meilleurs ingénieurs, mais parce qu'elles ont construit de meilleures boucles de rétroaction.

**Discussion 3 :**
Titre : De l’organisation de services au libre-service : l’ingénierie des plateformes en action
Par Pavel Bureš de Sky

Les organisations d'ingénierie modernes accumulent des silos de plates-formes plus rapidement qu'elles ne peuvent les réduire : chaque équipe choisit sa propre façon de provisionner les charges de travail, les bases de données, les files d'attente et les caches, chacun avec des profils de sécurité, d'observabilité et de coûts subtilement différents. Dans cette présentation, nous expliquons comment nous abordons ce problème à grande échelle grâce à une pratique d'ingénierie de plateforme construite sur le principe d'une interface unifiée et abstraite pour une configuration centrée sur les applications — une approche qui fait passer les équipes de plateforme d'une « plomberie pilotée par tickets » à une réflexion produit : des contrats stables, des chemins d'or et un libre-service par défaut.

Dans la seconde moitié, nous zoomons sur PEaaS (Persistence Engineering as a Service), notre mise en œuvre concrète de ces principes pour les charges de travail avec état. Nous passerons en revue l'architecture - les fonctions de composition Crossplane 2.0 sur EKS, les revendications Kubernetes (XR) centrées sur les applications et un modèle d'intégration de locataires qui automatise IAM, les points de terminaison de VPC, le provisionnement OIDC et S3 - et comment elle résume les backends hétérogènes (Keyspaces, Aurora DSQL, Redis Cloud et Kafka sur EKS) derrière une interface cohérente.

Les participants repartiront avec : Un modèle pratique pour concevoir des plates-formes d'ingénierie dans leurs propres organisations.
Une architecture de référence pour la persistance en tant que service sur Crossplane.
Des leçons honnêtes sur la normalisation, l’intégration des locataires et l’adoption de la plateforme.