DEVOPS REX 2025

• REX d'une démarche de diffusion de la culture DevSecOps chez les équipes d'infrastructure et de sécurité : mesure de la maturité, outils, formations, avec un cap de reconstruction automatique d'ici 2027 (description officielle).
• Ce qu'a retenu Onepoint : une grille de maturité « à la Nutriscore » (notes A à E) sur 4 axes : Craft, CI, CD et Sécurité.
• Ce qu'a retenu Bpifrance.IO : la transformation tient à l'alignement DevOps, Craft et Agile, porté par des équipes de coaching dédiées et des « contrats » d'onboarding.
• Relecture de l'organisateur (blog, avril 2026) : « le vrai sujet n'est pas l'outil (GitOps, ArgoCD, etc.) mais le niveau de standardisation ».

• Plateforme d'ingénierie interne de Sopra Steria, 11 000 utilisateurs, qui outille les pratiques DevSecOps depuis 2018 et a été enrichie par l'IA : génération de code, couverture de tests, revue de code et autres usages opérationnels, avec des démonstrations (description officielle).
• Ce qu'a retenu Onepoint : une vision « Agentic AI in the Software Delivery Lifecycle » où des agents interviennent à chaque étape (exigences, user stories, architecture, tests, code review). C'est l'exemple phare de la tendance « IA intégrée au cycle DevOps » dans leur compte-rendu.

Sur scène (transcript) :

• Point de départ : la migration de SVN vers GitLab en 2017, où chaque projet inventait ses règles (« une équipe sécurise, l'autre croise les doigts »). Pas d'imposition hiérarchique : une communauté interne d'experts a co-construit le standard.
• Un pipeline standard avec la sécurité par défaut à chaque étape (SAST, scan d'image, SBOM systématique), et un « adaptive pipeline » : seuls les jobs critiques en développement, tous les jobs non bloquants en MR draft, tout échec bloquant en MR ready.
• Mise en œuvre par des templates GitLab CI/CD modulaires (un pipeline complet avec 4 includes), un site de documentation et un générateur graphique ; le projet est publié en open source sous le nom to-be-continuous.
• Adoption par le bouche-à-oreille : 10 000 projets en 2022, 14 000 en 2023, 19 000 en 2024, 22 000 en 2025 (la description de la vidéo parle de « plus de 17 000 projets »). Les SBOM remontés dans Dependency-Track permettent au RSSI de voir immédiatement les applications touchées par une faille.
• Formules : « Sans sécurité, c'est pas DevSecOps, ça sera juste un DevOps » ; « Les templates, c'est le pot de miel qui tire les bonnes pratiques dans les équipes. »
• Questions-réponses : pourquoi Artifactory (multicloud, scan Xray) ; les freins cités sont la complexité globale et… le fait de ne pas lire la documentation. Sondage à main levée : une majorité de la salle venait d'entreprises de plus de 5 000 salariés.

• REX de Datadog : plutôt que d'imposer des restrictions, l'équipe sécurité a repensé avec les équipes produit et plateforme les permissions sur les clusters Kubernetes et l'accès aux logs sensibles, sans casser la fluidité opérationnelle (description officielle).
• Ce qu'a retenu Bpifrance.IO : au-delà du « shift left » par scanners, des experts sécurité qui codent avec les équipes les fonctionnalités sensibles (IAM, chiffrement, secrets), ce qui crée de l'empathie et du partage de compétences. Le rédacteur y voit une confirmation de sa propre approche (une observabilité qui crée une « confiance partagée » plutôt que de la surveillance).

Sur scène (transcript) :

• Angle choisi : « ouvrir les portes de l'atelier » de la chercheuse en géopolitique du numérique en comparant son travail à celui d'un DevOps : corpus et jeux de données au lieu de clusters, chaîne collecte → nettoyage → géoréférencement → cartographie → texte au lieu d'un pipeline CI/CD, veille au lieu d'observabilité, câbles coupés et pannes de services au lieu d'incidents.
• Outils : RIPE Atlas et RIPEstat (routage BGP, latence, chemins), QGIS, outils d'OSINT, imagerie satellitaire (elle conseille l'alternative française Nimbo, mise à jour mensuelle, plutôt que Google Earth), du Python, du SQL et du GeoJSON. Par principe, elle évite les outils des grandes plateformes qu'elle critique.
• Le problème n°1, ce sont les données : absentes, fermées (propriété industrielle, infrastructures critiques) ou trop chères. Exemples : la consommation réelle des campus de centres de données annoncés en Europe (projets de 1 à 2 GW, voire 4 GW) n'est pas publiée, et les audits arrivent après les financements (« on met la charrue avant les bœufs »).
• Mesurer les dépendances : aucune cartographie n'existe. Savoir qu'on dépend d'AWS, d'Azure ou de Google Cloud ne suffit pas : il faut savoir de quels services on dépend dans ces « immenses bibliothèques » pour savoir quelle brique on peut remplacer. Elle pointe un manque de culture du risque dans les entreprises comme à l'État.
• Travail de terrain (Afrique du Sud) : des centres de données géants s'implantent près de quartiers sans électricité. Les indicateurs sont imparfaits (un nombre de datacenters n'est pas une capacité de calcul) et une carte se documente comme du code.
• Conclusion : la discipline est jeune, « on n'en est pas encore au DevOps » : ce qui lui manque, c'est l'automatisation de la veille et du traitement des données. Talk en dépassement, donc sans questions.

• La session la plus détaillée dans les comptes-rendus : migration d'une plateforme de monitoring d'AWS vers Scaleway (bare metal et services managés), pour 80 000 utilisateurs et 22 000 clients actifs (Onepoint).
• Chiffres retenus : 4 mois, 3 personnes à temps plein, coûts passés de ~50 000 € à ~20 000 € par mois, soit l'objectif de plus de 50 % de réduction atteint (Onepoint, Synapsys).
• Motivations : coûts AWS excessifs et RGPD. Principale difficulté : le vendor lock-in sur des services sans équivalent direct (Kinesis, Elasticsearch). Bascule en une seule fois vers Scaleway (Synapsys).
• Leçon la plus reprise : « il ne faut pas chercher à transposer à l'identique ». Il faut arbitrer entre besoins réels et ambition technique plutôt que de reproduire les standards de l'hyperscaler (Synapsys, description officielle).
• Après coup (speaker, LinkedIn, 15/12/2025) : Jérôme Galais dit avoir été « profondément touché » par les retours des participants ; en commentaire, un collègue de Kaliop salue un talk « qui semble avoir inspiré beaucoup de monde ».

• D'après la description officielle : migration de la plateforme Data et IA de Matmut vers S3NS, avec une réarchitecture pour tirer parti de services managés (Cloud Composer, BigQuery) tout en garantissant la confidentialité des données sensibles, et une préparation de l'évolution vers le « Cloud de confiance ».
• Aucun retour de participant trouvé (Onepoint ne fait que la citer).

• D'après la description officielle : transformer des ascenseurs classiques en machines connectées à Monaco (écrans, messages du syndic, services à valeur ajoutée), sur une infrastructure Kubernetes, CI/CD et MQTT.
• Une session « technique et décalée » sur la qualité logicielle et la haute disponibilité dans un contexte IoT. Le speaker travaille chez Exoscale, sponsor Gold de l'édition.
• Programmée le 10 décembre à 16 h 35, en fin de première journée (annonce Mastodon de l'organisateur). Le lendemain, Julien Maitrehenry y fait allusion sur scène : « je pense c'est hier, on nous a parlé de Kubernetes et des ascenseurs » (transcript).
• Aucun retour de participant trouvé.

• Table ronde entre acteurs publics (DGFiP, cloud Nubo) et privés (Groupama, Theodo, Couchbase) sur quatre axes : choix d'architecture entre souveraineté et performance, conduite du changement, gouvernance des données, compromis entre conformité réglementaire et besoins opérationnels (description officielle, article de l'organisateur de mars 2026).
• Placée le 10 décembre de 16 h à 16 h 35 (programme archivé), le jour de la keynote souveraineté et des REX de migration (Kaliop, Matmut), ce qui fait de cette première après-midi un bloc consacré à la souveraineté.
• L'organisateur la présente comme un débat « pragmatique et détendu » ; aucune citation individuelle n'a été trouvée et la vidéo n'a pas été transcrite. C'est la session la moins vue de la playlist (hors pitchs sponsors).

• Pourquoi les outils d'IA, même avancés, échouent sans contexte sur de l'infrastructure réelle, et comment modéliser l'infrastructure comme un graphe reliant services, ressources et environnements, avec une démonstration en direct (description officielle).
• Ce qu'a retenu Bpifrance.IO : pour déboguer, les agents IA ont besoin d'une infrastructure représentée en graphe de dépendances multi-sources, pas seulement des dépôts de code.

• Un agent intégré à GitLab qui analyse les merge requests, suggère des améliorations, génère des tests et attribue un score de qualité, construit avec des LLM open source (Mistral, LLaMA) et des workflows n8n (description officielle).
• Ce qu'a retenu Synapsys : l'illustration du passage de l'IA expérimentale à l'IA opérationnelle dans les pratiques DevOps.

• D'après la description officielle : un LLMaaS souverain hébergé sur IaaS SecNumCloud pour des clients sensibles, avec des défis de scalabilité, de sécurité et de performance.
• Originalité annoncée : l'IA contribue à sa propre création (génération d'infra-as-code, scripts de supervision, aide au diagnostic, optimisation du routage).
• Pas de retour détaillé trouvé (Onepoint ne fait que la citer).

• Chatbot RAG pour un client des énergies renouvelables, sur un gros volume de données non structurées (R&D, support), avec l'exigence « 100 % français, hébergé en France » (description officielle).
• Chiffre d'accroche retenu : 70 à 88 % des POC IA ne passent jamais en production (Onepoint ; Synapsys note « 78–88 % »).
• Stack : Clever Cloud, PostgreSQL + pgVector, Mistral AI, Airflow, Streamlit, sans exposition à un cloud américain, avec des pratiques DevOps/DataOps et FinOps (Onepoint, description).
• Question posée par le speaker et retenue par Synapsys : éviter le « CV Driven Development » et l'adoption par FOMO.

• Plus de 1 000 applications, du COBOL au cloud-native : unifier et automatiser le delivery en respectant sécurité, traçabilité et gouvernance dans un environnement réglementé (description officielle).
• Ce qu'a retenu Bpifrance.IO : la performance DevOps n'est pas réservée aux start-up cloud-native. Le modèle de Westrum et les métriques Accelerate s'appliquent aussi dans un legacy contraint.

• D'après la description officielle : REX et pièges à éviter pour une équipe d'Ops chargée des moyens d'infrastructure et d'outillage, qui se sent « l'âme de super-héros » et décide « au doigt mouillé et dans l'urgence ».
• Chaque anti-pratique est expliquée et assortie d'alternatives (autonomie, Lean, culture produit).
• Aucun retour de participant trouvé.

Sur scène (transcript) :

• Contexte : une start-up avec une équipe de 3 personnes où il était le seul à maîtriser Kubernetes. Exemple du coût caché : migrer de NGINX Ingress Controller vers la Gateway API lui a pris une semaine. « Si on a la meilleure infrastructure du monde mais pas de produit à déployer dessus, notre valeur est toujours de zéro. »
• Premières étapes sur des PaaS managés (Azure Container Apps, DigitalOcean App Platform), avec leurs limites réseau : pour ne pas ouvrir un firewall à Internet, certains logs ont été sacrifiés.
• Puis le « vieux » qui marche : VM Linux et systemd (services et timers plutôt que cron), Terraform (« pas cloud agnostique mais multicloud »), Ansible et Ansible Vault, GitHub Actions en SSH. Rollback simple par binaire -previous. Des technos très documentées, que les LLM connaissent bien.
• Docker reste utile : Docker Compose en dev, outillage conteneurisé, Testcontainers.
• Kubernetes adopté au bout d'environ un an et demi, quand sont arrivées des applications clientes avec SLA. Message : « Faut-il toujours suivre les hypes ? Non, il faut choisir selon notre besoin réel. »
• En Q&R : un Kubernetes managé ne masque que le control plane ; ingress, opérateurs et monitoring restent à votre charge.

Sur scène (transcript) :

• REX client, présenté comme tel (« personne n'a la même manière de déployer Argo ») : une vingtaine de clusters dev et prod, montés à la main puis avec Terraform, donc pas tout à fait identiques. Il gère les briques communes (ingress, cert-manager, backup, observabilité) et des montées de version Kubernetes tous les 4 à 6 mois.
• Organisation : monorepo, trunk-based, un app-of-apps qui déploie des ApplicationSets ; les valeurs sont hiérarchisées par version de Kubernetes, puis type d'environnement, puis cluster, via les labels des secrets de cluster.
• Umbrella charts Helm pour rester peu dépendant d'ArgoCD (le tout reste déployable avec Helm seul). Pour les clusters hétérogènes, un generator matrix/merge avec un params.json par cluster — « pas sûr que ce soit une bonne pratique, mais ça marche ».
• Mises à jour : ArgoCD détecte la version du cluster et bascule les charts ; validation sur un cluster puis déploiement sur les 19 autres ; Renovate propose les PR de mise à jour.
• En Q&R : la vérification des merges de values YAML reste manuelle (« un enfer ») ; il utilise deux instances ArgoCD, l'une pour la dev, l'autre pour la prod.