DEVOPS REX 2024

Sur scène (transcript) :

• Présentée par le MC comme le talk d'ouverture. Point de départ : la Digital Factory de Bpifrance, missionnée par l'État pour mettre en ligne la plateforme du PGE en quelques jours, avec près d'1 Md€ de prêts garantis dans les 24 premières heures.
• Quatre ans plus tard, près de 300 personnes et une dérive « en mode agence » : les 5 jours qui suffisaient au PGE étaient devenus le délai pour tester et déployer une simple feature.
• Réponse lean : des « pilotes digitaux » à double rattachement métier et digital, puis un kanban qui rend le stock visible et désigne le goulot (la conception technique). Suivent modularité (ateliers DDD), tests end-to-end automatisés, features partant de main, feature toggling : de 7 à 40 déploiements par jour.
• Qualité inspirée du Dantotsu de Sadao Nomura : analyse quotidienne des défauts dans une équipe pilote, défauts en prod divisés par 7 (de 70 à une dizaine par trimestre).
• Gemba walks du directeur : elles ont révélé une équipe qui clôturait des stories inachevées pour tenir son sprint goal (« une pyramide de Ponzi ») et une autre qui se croyait interdite de traiter sa dette.
• Résultats affichés : 89 % de satisfaction client, eNPS supérieur à 50. En Q&R : oui, ils déploient le vendredi, pas le week-end.

Sur scène (transcript) :

• Believe (plus de 2 000 collaborateurs, 135 000 artistes) avait une plateforme éclatée entre AWS et on-prem et a choisi de repartir de zéro sur GCP dans le cadre du programme d'entreprise #BeOdyssey, porté par des OKR qui rendent la migration aussi prioritaire que le produit.
• Stack : GKE, Argo CD, Vault (identifiants dynamiques courte durée), Datadog avec SLO gérés en IaC, Kafka chez Confluent, Temporal, KEDA.
• Abstraction pour les devs : images de base maison, et un chart Helm générique où les devs n'écrivent qu'environ 15 lignes de values, avec labels FinOps et Datadog fournis d'office et tests Ginkgo/Gomega. Crossplane remplace Terraform côté applicatif, mais reste « complexe à maintenir ».
• Plus de 30 building blocks GitLab CI, un pipeline GitOps « one commit » et Renovate pour propager les mises à jour.
• Accompagnement : formations Google, portail « My Console » basé sur Backstage, et des consultants Theodo Cloud intégrés à l'équipe.
• En Q&R, pourquoi ne pas former directement les devs à Kubernetes : ils ont déjà du mal avec Docker, et l'infra « les motive pas plus que ça ».

Sur scène (transcript) :

• Mission chez un opérateur télécom étranger : monter en 3 semaines une plateforme Kubernetes on-prem, open source, sur un OpenStack encore immature, pour les équipes de dev.
• Architecture : un cluster de bootstrap local qui installe Cluster API, puis un cluster de management d'où l'on déploie N clusters ; images Flatcar construites avec Image Builder.
• Une V1 en Helm lancé à la main (« chez moi ça marche »), puis une V2 GitOps avec Argo CD et le Helm addon provider comme catalogue d'applications : 4 clusters complets en environ 20 minutes, « le développeur a littéralement une minute 30 de boulot ».
• Galères : proxy authentifiant découvert en cours de route, connexion d'environ 512 kb/s pour des images de plusieurs gigaoctets, documentation du provider pas à jour.
• Gains : auto-réparation des nœuds cassés par les devs, montée de version de 1.28 à 1.30 en changeant l'image, test de portabilité vers Azure concluant. Durée réelle : environ 4 semaines de travail effectif.

Sur scène (transcript) :

• Laurent Chenay présente seul (Franck Maudet a annulé au dernier moment). Contexte : environ 160 projets Node.js sur Kubernetes chez AWS, des pics aux heures des repas.
• L'ancien process : un créneau d'1 h réservé dans un agenda partagé, jamais le vendredi, et des tests analysés à la main (« s'ils étaient plus rouges que rouges, il fallait rollback »). Cercle vicieux : créneaux allongés, attente de plus d'une semaine, gros lots et « ninja deploys ».
• Hyperloop : un prototype Jenkins + Slack en un mois, adopté à 90 % en deux mois, puis refondu avec TypeScript, Temporal, Argo CD et Datadog. Ajouts successifs : rollback automatique sur golden metrics puis métriques fonctionnelles, Argo Rollouts par paliers de 10 %, environ 10 montées de dépendances automatiques chaque matin pour résorber les CVE.
• Une option « casser les règles » permet d'aller en prod hors créneau, avec postmortem le lundi.
• Résultats : lead time d'une semaine à 50 minutes, tests stables à 93 %, 180 déploiements par semaine, et des nouveaux arrivants qui livrent dès leur premier jour.

Sur scène (transcript) :

• Format court (15 minutes). Cloud Temple, l'un des IaaS qualifiés SecNumCloud, a décidé en 2019 de se différencier des hyperscalers par la qualification : environ 6 M€, 2 ans et 50 personnes pour le premier produit.
• SecNumCloud : plus de 700 exigences de l'ANSSI. Rappel de l'historique juridique (Safe Harbor, Privacy Shield, arrêts Schrems) et des échecs du cloud souverain des années 2010.
• Approche : refuser la sécurité « véto de fin de cycle » et la semaine de gel avant audit ; shift-left, user stories de sécurité, et surtout automatisation de la génération des preuves d'audit.
• Pipeline type : lint, liste blanche de licences, Renovate, détection de secrets, SCA, Sonar, DAST avec ZAP, Trivy ; binômes dev/expert sécurité et security champions volontaires.
• Effet d'apprentissage : environ 3 ans pour le premier produit, 18 mois pour le PaaS, environ 8 mois pour les suivants. Le transcript donne deux dates de qualification de l'IaaS (2020 et 2022).

Sur scène (transcript) :

• Duo humoristique de « vieux de la vieille » sur l'automatisation sous fortes contraintes (ISO 27001, HDS, SecNumCloud). Il enchaîne sur le talk SecNumCloud de Cloud Temple.
• Cas d'un datacenter air-gapped : un lab iso-production, un dépôt Nexus construit Internet coupé, des montées de version répétées, puis un passage en salle blanche où les données sont scannées pendant une semaine. Sur site, on rejoue un plan écrit ; on fait un postmortem à chaque imprévu.
• Leçon business : ces interventions ne doivent pas être du pro bono. « Une intervention de 5 minutes qui se transforme en une intervention de 7 h » se chiffre.
• Usine logicielle sensible : « Tout ce qui vient d'Internet est challengeable » (Buildah préféré à Kaniko pour la responsabilité de l'éditeur, binaires vérifiés par empreinte). « Good bye GitOps » au profit d'un « BinOps » où l'entrepôt d'artefacts sert de frontière entre CI et CD, et où un humain décide de l'applicabilité d'une vulnérabilité.
• Partie cloud provider SecNumCloud : Cluster API et Crossplane, une zone d'administration qui signe les binaires, et aucun accès du prestataire au data plane du client sans entrée créée par celui-ci.
• En Q&R : « un junior qu'on n'envoie jamais sur le terrain reste junior toute sa vie » ; GitOps reste possible en HDS, pas en SecNumCloud.

Sur scène (transcript) :

• Ingénieur réseau chez Deezer et responsable infrastructure bénévole, Julien Briault part d'un PC serveur sans sauvegarde dans une antenne, puis d'une première baie redondée, jusqu'à une plateforme régionale.
• Règle d'or : « 1 € qui est dépensé, c'est un repas qui n'est pas distribué ». Le cloud public et VMware sont exclus ; le datacenter de Chartres est financé à 99 % par des dons (2,5 tonnes de serveurs déménagées à la main).
• Socle : réseau routé en BGP (leaf/spine, VXLAN), tout en IaC et déployé par CI/CD, Wazuh, Teleport, Rudder, MAAS et Packer, revue d'architecture obligatoire avant la prod.
• OpenStack tourne dans Kubernetes (Helm), avec Ceph hyperconvergé : le « Cloud du Cœur ». Kubernetes est jugé « astreinte-friendly ».
• Impact compté en repas : environ 12 millions de repas par an attribués à la trentaine d'applications (dont une sonde de température des chambres froides). Environ 700 VM, 9 bénévoles actifs.
• Sondage en salle : « qui a apprécié installer OpenStack ? », plus personne ne lève la main.

Sur scène (transcript) :

• Chez PayFit, le mot « incident » n'existait pas en 2021. Thèse : « les incidents, c'est définitivement pas un truc d'ops », ils concernent aussi les devs et le support client.
• N'importe qui peut déclarer un incident, la sévérité (SEV1 à SEV4) se revoit à la hausse plutôt qu'à la baisse ; une revue mensuelle mesure environ 3 % d'erreurs de sévérité. « Si quelqu'un pense qu'il y a un incident, c'est qu'il y en a probablement un. »
• L'incident commander est un facilitateur, souvent l'engineering manager concerné ; un channel Slack par incident et une war room ouverte à tous.
• Astreinte chiffrée : 80 € la nuit de semaine, 150 € le samedi, 200 € le dimanche, soit environ 40 000 € par an pour une personne en continu ; d'où une astreinte centrale d'environ 6 SRE plutôt qu'une par équipe produit.
• Outils : Datadog, PagerDuty, incident.io (retours « que super positifs »), Notion pour les postmortems ; leviers côté dev : retries, circuit breakers, modes dégradés.
• Le speaker revenait à DEVOPS REX, où il avait déjà parlé en 2017.

Sur scène (transcript) :

• Dernier talk du 4 décembre. Rappels : scopes 1, 2 et 3 (le scope 3 pèse environ 80 % des émissions d'un cloud provider), PUE, et l'eau (WUE), souvent oubliée : « un PUE faible va impliquer qu'il y a une consommation d'eau qui peut être démesurée ».
• Démonstration dans la console Scaleway : l'intensité carbone varie d'un facteur 16 entre Paris et Varsovie selon le mix électrique et le PUE.
• Leviers par ordre d'impact : mesurer (« on ne peut pas réduire ce qu'on ne peut pas mesurer »), choisir la géographie, puis le datacenter, puis l'architecture (pas de surdimensionnement, autoscaling, Kubernetes, serverless), et en dernier le code.
• En Q&R : la CSRD et les appels d'offres créent un signal ; les tarifs Scaleway ne dépendent pas du CO₂ ; sur l'IA, « la meilleure façon de faire de l'IA frugale, c'est de pas l'utiliser ».
• Talk présenté par une salariée du fournisseur, dont les exemples s'appuient sur les outils maison ; slides mal affichées (pas la bonne version).

Sur scène (transcript) :

• Monolithe temps réel militaire (Ada, C++, plusieurs millions de lignes) avec plus de 2 700 tests fonctionnels : 42 h en séquentiel, 8 h parallélisés sur un Jenkins saturé, sans droit à Kubernetes.
• Solution 1, le temps simulé : une surcouche maison qui n'avance l'horloge que « lorsque toutes les tâches sont endormies » (libfaketime écarté). 42 h ramenées à 1 h 40.
• Solution 2, parallélisation par Docker Compose (un conteneur par CPU) : environ 20 minutes.
• Les tests temps réel restent obligatoires : ordonnancement des tests longs en premier et gestion de charge en Groovy pour ne pas saturer Jenkins, soit 1 h 30.
• En Q&R : un test qui casse en temps simulé casse presque toujours en temps réel ; ajouter des machines ne suffisait pas, le nombre de tests augmente chaque année. Fil rouge humoristique « Pirates des Caraïbes ».

Sur scène (transcript) :

• Le shift-left actuel empile SCA, SAST, scan d'IaC et contrôle de supply chain dans la CI ; selon le speaker, empiler des outils ne suffit pas.
• REX d'une attaque DDoS chez un ancien employeur : la cause venait de l'opérateur du cloud provider (« la supply chain de notre supply chain »). Aucun client perdu grâce à la transparence.
• Sur l'IA générative : des études montrent plus de vulnérabilités dans le code de Copilot ; leurs tests de remédiation Terraform par LLM sont justes dans 85 à 90 % des cas, ce qu'il juge insuffisant sans humain dans la boucle.
• Culture : apprentissage au moment du besoin (dans l'IDE plutôt que la CI), « la posture de coach au lieu de policier », règles d'exception à durée limitée.
• Talk d'un sponsor : le corps reste générique, l'autopromotion se limite aux questions-réponses.

Sur scène (transcript) :

• Une petite équipe DevSecOps au centre d'opérations des vulnérabilités d'EDF : labs Security Champions (7 sessions, OWASP Top 10, threat modeling), accompagnement, communauté, outillage. Environ 400 security champions recensés.
• Échec assumé : une grille de maturité OWASP SAMM adaptée, abandonnée faute d'appui des directeurs et de temps des projets.
• Sur l'IaC, face à des scans « sauvages », une solution clé en main : repo central de règles, outil choisi après benchmark avec les utilisateurs, image et runner durcis, règles surchargeables par projet. Choix de la CI plutôt que d'un plugin IDE, trop long à qualifier chez EDF.
• Quatre mois au total, lents surtout à cause de la concertation : « Les pratiques évoluent beaucoup plus vite que les politiques. »
• Message : la sécurité est un sujet organisationnel bien plus que technique, et l'appui du RSSI a été décisif. Il reconnaît du shadow IT et un fort turnover des champions (souvent des prestataires).

Sur scène (transcript) :

• Ouverture par un sondage debout : la salle se rassoit selon la date de son dernier déploiement un vendredi ; « quelques-uns » ont déployé le vendredi précédent.
• S'interdire le vendredi, c'est se priver de 20 % du temps de livraison (description officielle). « Une mise en production, ça va être un non-événement technique ; si ça ne l'est pas, c'est ça votre problème. »
• Trois peurs et trois réponses : petits incréments, observabilité par événements (plutôt que des métriques agrégées), chaos engineering pour les inconnus.
• SLO et error budgets traduits en euros (pratique à Veepee et SNCF Connect, selon lui) pour obtenir des chantiers techniques auprès du business.
• Platform engineering inspiré de Team Topologies : une approche produit tournée vers les équipes de dev, sans réinventer la roue. Anecdote : des « Day of Chaos » en préprod où les équipes gagnantes avaient des écrans d'observabilité.
• Conclusion : « On ne peut pas dire qu'on est DevOps si on a toujours cette règle. » Il reprend les chiffres entendus la veille (40 déploiements par jour, 180 par semaine).

Sur scène (transcript) :

• Chez un acteur international des jeux d'argent en ligne : Kubernetes on-prem et EKS, GitLab, GitOps, stack Grafana. Mais des équipes infra, build et produit qui ne se parlent pas, aucune vision long terme ni catalogue de services.
• Image retenue : « c'est comme filer une Formula One à quelqu'un qui sait pas conduire ».
• Réponse : une équipe « Professional Services » au milieu, qui commence par des workshops (Kubernetes, observabilité, pipelines), puis fait du support et de la revue de repos et remonte les besoins vers le socle, sans faire à la place des équipes.
• Résultat après presque 2 ans : plus de demandes de déploiement, et 90 à 95 % des sollicitations portent sur des composants cassés.
• Le modèle dépend de l'appui de la direction ; avec les équipes legacy réfractaires, c'est « très compliqué ».

Sur scène (transcript) :

• Suite d'un REX donné à une édition précédente de DEVOPS REX sur le DevOps multisite chez Groupama (équipes à Paris, en Bretagne, à Lyon et à Montpellier).
• 2018 : choix d'OpenShift et d'une approche produit (« Beluga »). Le cluster unique grossit jusqu'à bloquer les livraisons un vendredi soir ; 2020 : séparation prod/non-prod et une équipe « DevOps » rebaptisée platform team d'après Team Topologies.
• Apports : environnements iso-prod, images immuables, déploiements sans interruption, et « Easy Change », livraison sans comité pour certains correctifs, soit environ une livraison par jour en prod. Environ 70 % des applications conteneurisées.
• Migration vers OpenShift 4 en 2022 et passage de Jenkins à Tekton (plus de 1 600 pipelines). Quelques chiffres du transcript sont douteux.
• Mise en garde : « comme on est en on-prem, les gens ils ont l'impression que c'est gratuit ». D'où une note de A à G par périmètre applicatif, et en non-prod : « on les éteint et on attend que ça gueule ».
• « DevOps c'est une culture, c'est pas une équipe. » Démarrage perturbé par un souci technique.

Sur scène (transcript) :

• Pas un REX unique mais la synthèse de 50 à 60 équipes accompagnées. Rappel d'Accelerate et du programme DORA (quatre métriques, profils low à elite, 29 capabilities).
• Méthode : le quick check DORA pour créer le sentiment d'urgence face à la direction, l'argument de la courbe en J, puis quelques pratiques de base (gestion de version, CI/CD, observabilité, tests, petits lots, management visuel).
• Le coach prend à sa charge ce que l'équipe ne peut pas faire seule : il a obtenu dans une banque un « couloir accéléré » malgré un gel de trois semaines avant chaque mise en prod. Il pique au passage les scrumistes : une story finie en 2 jours attend la fin du sprint.
• Ordres de grandeur : environ 3 mois pour passer de low à medium performer. « Ça sert à rien de développer et de déployer vite si on n'est pas capable de mesurer que c'est OK. »
• En Q&R : des métriques déclaratives suffisent au début ; « l'outil, je m'en contrefiche », seul le processus compte. Il renvoie plusieurs fois au REX de Bpifrance de la veille.

Sur scène (transcript) :

• Dernier talk de l'édition (« on est à peu près tout ce qui se tient entre vous et l'apéro »). Back Market, née sur AWS, migre vers GCP en 6 mois sans impacter les roadmaps, pendant que les devs réécrivent le monolithe. Motivations : services managés, valeurs environnementales, ne pas financer un concurrent.
• Hypothèses contre réalité : un seul jalon à 3 mois fait perdre du temps, et le soutien du COMEX n'enlève pas la charge mentale des experts. Règle : « si aucune action identifiée ne permet de dérisquer, alors on doit avancer ».
• Ce qui fait gagner du temps : aucune VM migrée, tout déclaré via Backstage, réseau simplifié, exceptions supprimées.
• Six migrations : la première préprod prévue en 2 jours en a pris 5, la tentative par lots a été abandonnée, puis bascules one-shot ; la dernière prod a pris 2 h.
• Leçons : Kubernetes a bien servi d'abstraction, le non-standard prend 4 à 5 fois plus de temps, les données concentrent le risque. En Q&R, ils reconnaissent que rester sur AWS aurait coûté moins cher ; les clouds européens ont été écartés faute de services managés et de présence mondiale.
• La vidéo est titrée « 2025 », mais le programme archivé place le talk le 5 décembre 2024.