• 👤 Invitée : Sylvain Gougouzian
  • Bluesky : @gouz.dev
  • LinkedIn : https://www.linkedin.com/in/gouz
• 🗓️ Date d’enregistrement : 30 juin 2026
• 🎧 Lien vers l’épisode

👤 Présentation de Sylvain – ⏱️ 1″

• https://www.youtube.com/@tourainetech37
• https://www.devquest.fr/
• https://slidesk.github.io/slidesk/

📰 News Techs 

🤖 Intelligence Artificielle – ⏱️ 56″03

Home assistant x OVHcloud AI Endpoints

https://rc.home-assistant.io/integrations/ovhcloud_ai_endpoints

The pressure

https://daniel.haxx.se/blog/2026/05/26/the-pressure/

La Norvège va interdire les chatbots IA aux écoliers

• https://next.ink/243458/la-norvege-va-interdire-les-chatbots-ia-aux-ecoliers/
• https://youtu.be/4xq6bVbS-Pw?si=bgIwiPNvJpZrMIzT
• https://youtu.be/M8QM4klrGcM?si=w7slhdu9TVyNcomw

GitHub Copilot is moving to usage-based billing

https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/

Is AI profitable yet?

https://isaiprofitable.com

NVIDIA announced NVCF

http://github.com/nvidia/nvcf

Le gouvernement américain interdit Fable 5 et Mythos 5 a tout non américain dans le monde

https://www.anthropic.com/news/fable-mythos-access

OpenAI acquires Ona (ex Gitpod)

https://twitter.com/i/status/2065572964062666976

☁️ Cloud – ⏱️ 1h27″40

Terraform S3 state locking with OVHcloud Object Storage

https://blog.ovhcloud.com/terraform-s3-state-locking-ovhcloud-object-storage/

🔐 Sécurité – ⏱️ 1h30″

Secure Image Signing with Cosign and OVHcloud KMS

https://blog.ovhcloud.com/secure-image-signing-cosign-ovhcloud-kms/

🎤 Conférences / meetup – ⏱️ 1h32″43

• https://gouz.dev/
• https://developers.events/
• https://sunny-tech.io/
• https://www.rivieradev.fr/

💡 Retrouvez l’ensemble des autres épisodes ici : https://smartlink.ausha.co/tranches-de-tech 💡

As both the cyberattack cause and cure, ever-expanding AI has been transforming cybersecurity from both sides of the battlefield. Organizations increasingly use AI to detect threats and automate security operations, but just as rapidly, attackers are also adopting AI to generate malware, accelerate phishing campaigns, and probe systems at scale.

As cyber threats evolve, cybersecurity education must evolve with them. Accordingly, future security engineers need more than theoretical knowledge — they need hands-on experience building and defending modern cloud environments against increasingly intelligent attacks.

This was the exact goal of the recent OVHcloud x EPITA Rennes SecDevOps Hackathon. Students spent three days developing cloud-native security solutions designed for an AI-driven threat landscape, helping train the next generation of tech talent.

Why AI is changing cybersecurity education

Traditional cybersecurity education often focuses on known attack patterns or defensive tools in isolation. But today’s security teams are operating in a very different reality.

Analysts now work across AI-assisted detection systems, cloud-native infrastructure, threat intelligence platforms, and automated incident response workflows. At the same time, attackers are using AI to automate reconnaissance, generate convincing phishing content, and adapt their techniques faster.

Preparing students for this environment means moving beyond classroom theory. They need realistic infrastructure, collaborative development, and hands-on security engineering under real technical constraints.

That is where hackathons can make the difference: they push students to solve practical cybersecurity problems in conditions much closer to the ones they will face in the field.

Building cloud-native security solutions

As part of the OVHcloud Education program, students from EPITA Rennes’ SecDevOps major were given access to OVHcloud Public Cloud infrastructure alongside AI credits and development resources. Working in teams, they designed, tested, and deployed solutions capable of addressing emerging cybersecurity challenges while operating in production-like cloud environments. Rather than focusing on theoretical concepts, every project tackled practical problems security teams increasingly encounter today.

Rethinking cyberdefense in the age of AI

Several projects reflected how defensive security is evolving alongside AI:

MIR[AI]GE: turning AI attackers against themselves

Awarded Best Technical Project, MIR[AI]GE explored a proactive approach to defending against autonomous AI attacks.

Instead of simply blocking malicious activity, the platform detects offensive AI agents and redirects them into isolated honeypot containers filled with realistic — but entirely fake — data.

The objective is not only to stop the attack but also to waste the attacker’s computing resources while gathering valuable behavioral information.

As AI-generated attacks become more sophisticated, deception technologies like honeypots are becoming increasingly valuable components of modern cyberdefense strategies.

Find out more: miraige.vercel.app

Honeymind: threat intelligence from attacker behavior

Winner of the Best Presentation Award, Honeymind focused on generating actionable threat intelligence.

The team developed an internet-facing honeypot capable of analyzing attacker requests before enriching the collected data with AI, improving deception techniques and producing insights that security operations teams could use during incident response.

Projects like this demonstrate how AI can support defenders — not only by automating analysis but by making security systems themselves more adaptive.

Discover the repository: github.com/al2al85/HoneyMind

Other innovative approaches

Other teams explored complementary security challenges:

Winnie developed a bounce honeypot that guides attackers through AI-generated environments inspired by the MITRE ATT&CK framework.

Meanwhile, SRE-squad created an assistant designed for SOC analysts, helping correlate logs with operational runbooks and prioritize alerts in environments increasingly flooded with AI-generated attack traffic.

Together, these projects illustrate how future security professionals are beginning to combine cloud infrastructure, automation, and AI into practical defensive workflows.

What organizations can learn

While the hackathon centered on students, the technologies they explored mirror challenges many organizations already face.

Modern cybersecurity increasingly relies on:

• Cloud-native security architectures
• Threat intelligence pipelines
• AI-assisted analysis
• Deception technologies such as honeypots
• Automated security operations

As these capabilities become mainstream, organizations will need engineers who understand both software development and security engineering — the core principles behind SecDevOps.

Providing students with opportunities to build these systems today helps the next generation of cybersecurity professionals prepare for tomorrow’s threats.

Supporting the next generation of security engineers

The OVHcloud Education program aims to bridge academic learning with real-world cloud engineering by giving students access to production-grade infrastructure and practical technical challenges.

The hackathon also offered members of the winning teams a fast-track interview with OVHcloud’s technical recruitment teams for their end-of-studies internships.

A special thank you goes to Gabin, Lucas, and Magali, whose mentorship and expertise helped make this year’s event a success.

If you’re ready to turn AI cybersecurity training into a career, explore opportunities on the OVHcloud Careers site. And if your institution would like to organize a hackathon with the OVHcloud Education program, we’d love to hear from you.

Every month, the OVHcloud Developer Advocate team creates content, shares knowledge, and connects with the tech community. Here’s a look at what we did in June 2026. 🚀

🎙️ “Tranches de Tech” – Our monthly podcast

A new episode of our French-language podcast Tranches de Tech 🥑 just dropped!

🎧 Episode 29: Dessiné c’est gagné !

This episode of “Tranche de Tech” features host Stéphane, co-host Aurélie, and guest Ane, a front-end developer at Datadog, who discuss visual thinking and sketchnoting, Ane’s experience contributing to the Chromium open-source project, and the growing impact of AI on software development practices. A significant portion of the conversation explores how AI tools are both accelerating code generation and creating challenges for open-source communities, including a flood of low-quality pull requests and security vulnerabilities being discovered (and sometimes irresponsibly disclosed) by AI systems. The episode wraps up with reflections on the instability of GitHub, the financial struggles facing tech conferences, and a shared concern about preserving the human and collaborative elements of the developer profession.

See episode shownotes

📺 Live on Twitch

We streamed live on Twitch this month! Here’s what we covered:
🎥 Stéphane Philippart discussed with Fanny Bouton about quantum computing at OVHcloud.
Catch the replay on YouTube ▶️.

🎤 Conference Talks

The team hit the road (and the stage) at several conferences this month:

🇫🇷 Paris JUG, Paris 🇫🇷

Stéphane gave a talk: Toi aussi crée ta CLI boostée à l’IA avec Picocli

🇫🇷 DevQuest Niort, Niort 🇫🇷

Aurélie Vache gave two talks:

• J’ai packagé mon application en image Docker, et maintenant ?
• Comprendre Kubernetes de manière visuelle

Stéphane Philippart gave a workshop: Développer avec l’IA : et si c’était aussi simple qu’ajouter une librairie ?

🇫🇷 BreizhCamp, Rennes 🇫🇷

Stéphane Philippart gave two talks

• JBang, un fichier Java pour les gouverner tous ? 💍
• 🧰 Les dev containers, la boîte à outils ultime pour les devs ?

🤝 Community Engagement

We connected with the community through more than just conferences:

🏫 Meetup Tech Speak’Her – June, 4 – Toulouse, France 🇫🇷

Aurélie was a member of the jury during the “Tremplin DevFest Toulouse” evening, organized by the Tech Speak’her association.

During ths “pitch contest” event, eight women from the region delivered their pitches, and the jury had the difficult task of selecting the winner. She will have the opportunity to give a talk at DevFest Toulouse, while the two runners-up will be invited to present their talks at a Tech Speak’her meetup.

📝 Our latest blog posts

Here are the articles our team published on the OVHcloud Blog this month.

📝 Secure Image Signing with Cosign and OVHcloud KMS – by Aurélie Vache

This article by Aurélie Vache explains how to use Cosign, a tool from the Sigstore project for signing and verifying OCI container images, together with the OVHcloud Key Management Service (KMS) through a dedicated plugin. It walks through the full workflow: generating a key pair stored securely in OVHcloud KMS, signing a container image, and verifying the signature. The main benefit is keeping cryptographic signing keys out of local environments and CI/CD variables, reducing secret sprawl and improving supply chain security.

📝 Terraform S3 state locking with OVHcloud Object Storage – by Aurélie Vache

This article by Aurélie Vache explains how to enable native S3 state locking for Terraform and OpenTofu using OVHcloud’s S3-compatible Object Storage, made possible by the recent addition of conditional writes support. When activated via the use_lockfile = true backend option, Terraform creates a .tflock file during an operation, preventing any concurrent apply from modifying the state file simultaneously and avoiding state corruption. The post walks through the full setup and demonstrates the locking mechanism in action with practical CLI examples.

📝 How to process large AI requests with Batch Mode on OVHcloud AI Endpoints – by Stéphane Philippart

This article by Stéphane Philippart introduces the Batch Mode feature (currently in beta) for OVHcloud AI Endpoints, which allows processing large volumes of LLM requests asynchronously by uploading a JSONL file, submitting a batch job, and retrieving results within up to 24 hours , at 50% lower cost than synchronous requests. The post walks through the full Python workflow using the OpenAI-compatible SDK: uploading the input file, creating and polling the batch, and downloading the results. It’s ideal for non-time-sensitive workloads like bulk classification, translation, or dataset generation, but not suited for real-time use cases like chatbots.

💻 Code Samples and Open Source

We regularly publish code samples and open-source projects to help you get started with OVHcloud products. Check out our public-cloud-examples repository on GitHub.

New this month:

• 🆕 New release: OVHcloud Pulumi provider v2.14.0
• 🆕 Contributions in the new Sigstore cosign plugin for OVHcloud KMS
• 🆕 Contributions in the okms-k8s-encryption-provider

🗓️ Coming up next

Here’s a sneak peek at what’s coming next.

🗓️ – July, 2 & 3 – Sunny Tech (Montpellier, France)

🎤 Aurélie Vache is giving two talks:
– Comprendre Kyverno de manière visuelle (Thursday the 2nd)
– J’ai packagé mon application en image Docker, et maintenant ? (Friday the 3rd)

🎤 Stéphane Philippart is giving one talk (Thursday the 2nd): 🧰 Les dev containers, la boîte à outils ultime pour les devs ?

🗓️ – July, 6, 7 & 8 – Riviera Dev (Sophia-Antipolis, France)

🎤 Aurélie Vache is giving two talks:
– Questions pour un conteneur – édition Supply Chain » (Tuesday the 7th)
– Comprendre Kubernetes de manière visuelle (Tuesday the 7th)

🎤 Stéphane Philippart is giving one workshop (Tuesday the 7th): Créer un assistant IA dans son terminal avec Java, Picocli et Quarkus

🗓️ – July, 8, 9 & 10 – We are developers (Berlin, Germany)

🎤 Aurélie Vache is giving one talk (Thursday the 9th): Understanding Kubernetes in a visual way

🗓️ New “Tranches de Tech” podcast episode

🎧 All episodes are available on Ausha and all your favorite podcast applications!

💬 Stay in Touch

Want to chat with us, share your thoughts, or just say hi? Here’s how to get in touch with the Developer Advocate team:

• 🟣 Discord: OVHcloud Discord server
• 🐦 X / Twitter: @OVHcloud
• 💼 LinkedIn: OVHcloud LinkedIn
• 🐙 GitHub: github.com/ovh

See you next month! 👋

Introduction

As part of a project of mutual interest between OVHcloud and Sopra Steria, the technical teams of each company joined forces to design the deployment of a Landing Zone. Initially, the project was designed and adapted to the needs of the public sector, to be later expanded to other markets and use cases.

Why a Landing Zone?

Compliance and regulatory requirements

The starting point of the project was very specific: from day one, the Canadian government required a cloud environment that meets very strict sovereignty and security standards. Without a ready-to-use solution, each public client had to spend weeks, if not months, setting up their architecture, drafting procedures, and validating each component with the authorities. This created a bottleneck when projects were initiated.

“The lack of a process to deploy a Landing Zone that was compliant with the requirements of the Canadian public sector was a real roadblock.”

The Landing Zone was designed as a deployment that complies with a regulatory framework: the created infrastructure automatically meets the segmentation, encryption, logging, and access control requirements imposed by authorities. Clients no longer have to worry about how to prove that their environment is compliant; the compliance report is generated simultaneously with the deployment. In fact, this is the whole idea behind the solution.

Accelerating cloud adoption

Once the compliance issue is resolved, the Landing Zone proves to be a true adoption accelerator for all types of clients: startups, SMEs, large accounts, and, of course, governments.

• Automation of best practices: the tools automatically deploy private networks, subnets, firewalls, service accounts, and IAM policies.
• Standardisation: each environment follows the same architectural model, which facilitates maintenance, monitoring, and upgrades.
• Time-to-market: where a manual deployment could take several weeks of work (reading documentation, manually creating resources, compliance testing), the Landing Zone allows for an operational (and compliant) environment in less than an hour.

“In half an hour, you have something ready to use: 30 to 40% of security requirements are already automatically deployed.”

The concrete benefits for technical teams

Time saving and reproducibility

At the core of automating a Landing Zone is Infrastructure as Code (IaC). Terraform (or its fork OpenTofu) orchestrates all OVHcloud services.
Thanks to this model:

• a single script can be executed multiple times, across different accounts or regions, without changing the outcome
• human errors that occur when manually creating resources (typographical errors, configuration oversights, incorrect role assignments) are nearly eliminated
• teams move from tedious configuration to deployment validation, freeing up several days of work for each project

Governance and access management

In addition to the infrastructure, the Landing Zone incorporates a governance model: roles, policies, and safeguards are preconfigured, simplifying access management and revoking rights when someone leaves the company. This layer of abstraction addresses one of the main challenges for IT departments: visibility and control over cloud resources.

Modularity and adaptability to different profiles

The code has been designed to be modular. Three basic profiles are available: “small business”, “medium” and “government”. Each profile activates a tailored set of services in terms of cost, scalability, and compliance requirements. 

The same code base can be extended: if a client from the financial sector requires an HSM encryption module or a certified payment gateway, it is simply a matter of adding the corresponding module and rerunning the script. This flexibility allows you to reuse the same foundation for very different projects, while ensuring compliance and performance guarantees.

A solution that makes a difference

Landing Zone is more than just scripts that create networks and accounts.

It is a comprehensive set of services that covers the entire lifecycle of a cloud project: from strategic reflection to production deployment, and then to daily management administered by the client.

This dual expertise provides coverage for the entire lifecycle: strategy → deployment → operation.

Conclusion

The Landing Zone deployed on OVHcloud infrastructures addresses two major challenges: compliance  for many regulated sectors (particularly public, finance and health) and speed of adoption  for all cloud customers. By automating part of the security requirements, offering ready-to-use governance, and remaining highly modular, it frees up technical teams to focus on their business value.

Are you responsible for a cloud project and looking to reduce your production timelines while ensuring compliance? Contact OVHcloud to find out how a Landing Zone can become the foundation of your digital transformation.

Introduction

Dans le cadre d’un projet d’intérêt commun entre OVHcloud et Sopra Steria, les équipes techniques ont réuni leurs expertises pour concevoir le déploiement d’une Landing Zone (ou « zone d’accueil »). Dans un premier temps, le projet a été conçu et adapté aux exigences du secteur public et pourra ensuite être étendu à d’autres marchés/cas d’usage.

Pourquoi une Landing Zone ?

Conformité et exigences réglementaires

Le point de départ du projet était très concret : le gouvernement canadien exigeait, dès le premier jour, un environnement cloud qui respecte des standards de souveraineté et de sécurité très stricts.

Sans une solution prête à l’emploi, chaque cliente ou client public devait passer des semaines, voire des mois, à mettre en place son architecture, à rédiger des procédures et à valider chaque composant auprès des autorités. Cela engendrait un goulot d’étranglement lors de l’initialisation de projets.

« Le fait de ne pas disposer d’un processus pour déployer une Landing Zone conforme aux exigences du secteur public du Canada était un véritable bloqueur. »

La Landing Zone a été conçue comme un déploiement respectant le cadre réglementaire : l’infrastructure créée répond automatiquement aux exigences de segmentation, de chiffrement, de journalisation et de contrôle d’accès imposées par les autorités. La clientèle n’a donc plus à se soucier de la façon de prouver que son environnement est conforme. Le rapport de conformité est en effet généré en même temps que le déploiement. C’est d’ailleurs là tout l’intérêt de cette solution.

Accélération de l’adoption du cloud

Une fois le problème de conformité résolu, la Landing Zone se révèle un véritable accélérateur d’adoption pour tous types de clientes et clients : startups, PME, grands comptes et, bien sûr, les administrations.

• Automatisation des bonnes pratiques : les outils déploient automatiquement les réseaux privés, les sous-réseaux, les pare-feux, les comptes de service et les politiques IAM.
• Standardisation : chaque environnement suit le même modèle d’architecture, ce qui facilite la maintenance, le monitoring et la montée en charge.
• Time-to-market  : là où un déploiement manuel pouvait prendre plusieurs semaines de travail (lecture de la documentation, création manuelle des ressources, tests de conformité), la Landing Zone permet d’obtenir un environnement opérationnel (et conforme) en moins d’une heure.

« En une demi-heure, vous avez quelque chose de prêt à l’emploi : 30 à 40 % des exigences de sécurité sont déjà déployées automatiquement. »

Les bénéfices concrets pour les équipes techniques

Gain de temps et reproductibilité

Le cœur de l’automatisation d’une Landing Zone repose sur de l’Infrastructure as Code (IaC). Terraform (ou son fork OpenTofu) orchestre l’ensemble des services OVHcloud.
Grâce à ce modèle :

• un même script peut être exécuté plusieurs fois, dans différents comptes ou régions, sans que le résultat change ;
• les erreurs humaines liées à la création manuelle de ressources (erreurs de typographie, oublis de configuration, mauvaise attribution de rôle) sont quasiment éliminées ;
• les équipes passent de la configuration fastidieuse à la validation du déploiement, libérant ainsi plusieurs jours de travail par projet.

Gouvernance et gestion des accès

Outre l’infrastructure, la Landing Zone intègre un modèle de gouvernance : rôles, politiques et garde-fous sont préconfigurés, ce qui simplifie la gestion des accès et la révocation des droits lorsqu’une personne quitte l’entreprise. Cette couche d’abstraction répond à l’une des principales difficultés des DSI : la visibilité et le contrôle sur les ressources cloud.

Modularité et adaptabilité aux différents profils

Le code a été pensé pour être modulaire. Trois profils de base sont proposés : « small business », « medium »et « government ». Chaque profil active un jeu de services adapté (coût, évolutivité, exigences de conformité). 

Le même socle de code peut être étendu : si un client ou une cliente du secteur financier a besoin d’un module de chiffrement HSM ou d’une passerelle de paiement certifiée, il suffit d’ajouter le module correspondant et de relancer le script. Cette flexibilité permet de réutiliser la même base pour des projets très différents, tout en conservant la garantie de conformité et de performance.

Une solution qui fait la différence

Lorsque l’on parle de Landing Zone, on ne parle pas seulement de scripts qui créent des réseaux et des comptes.

Il s’agit d’un ensemble complet de services qui couvre tout le cycle de vie d’un projet cloud : de la réflexion stratégique à la mise en production, puis à la gestion quotidienne opérée par le ou la cliente.

Cette double expertise permet de couvrir l’ensemble du cycle de vie : stratégie → déploiement → exploitation.

Conclusion

La Landing Zone déployée sur les infrastructures OVHcloud répond à deux enjeux majeurs : la conformité pour de nombreux secteurs réglementés (notamment public, financier et de santé) et la rapidité d’adoption pour l’ensemble des clientes et clients du cloud. En automatisant une partie des exigences de sécurité, en offrant une gouvernance prête à l’emploi et en restant hautement modulaire, elle libère les équipes techniques pour leur permettre de se concentrer sur leur valeur métier.

Vous êtes responsable d’un projet cloud et vous cherchez à réduire vos délais de mise en production tout en garantissant la conformité ? Contactez OVHcloud pour découvrir comment la Landing Zone peut devenir le socle de votre transformation numérique.

Building a real-time data pipeline used to mean months of infrastructure work. Here is what the modern stack looks like in 2026.

Your database is doing its job. It records every transaction, every event, every state change your application produces. The data is reliable, consistent, and safely stored.

But a database is a starting point, not a destination. The question is what happens after the write. Does that data stay in storage, answering application queries, while the insights it could generate stay locked in place? Or does it flow downstream, in real time, to the systems built to make sense of it?

Building that downstream pipeline used to be a serious infrastructure project. Kafka clusters to provision and tune, ZooKeeper ensembles to manage, connectors to configure, sinks to wire up, and a schema registry to operate. A team could spend weeks on the scaffolding before the first event reached an analytics engine.

In 2026, the pipeline architecture has not changed. But the operational weight has. Managed services handle provisioning, replication, failover, and upgrades. What used to take a dedicated platform team now takes an afternoon. This article walks through what a complete real-time data pipeline looks like, how each layer connects, and what it takes to build one without building the infrastructure underneath it.

The four layers

A modern real-time data pipeline has four layers. Each has a distinct job, and none of them are optional if you want data to move continuously from storage to insight.

Storage

Where your data originates. A relational database like PostgreSQL handles transactions, enforces consistency, and serves your application. It is your source of truth. Every insert, update, and delete is recorded with precision. That write log is also the starting point for everything downstream.

Streaming

How data moves. Apache Kafka captures changes from your database the moment they happen and distributes them to downstream consumers as events. Every row-level modification becomes a structured message that other systems can act on in real time. Kafka’s core design principle is decoupling: producers write events without knowing who will consume them, and consumers read events without touching the source system. This means you can add new downstream use cases – a new analytics engine, a new alerting system, a new data warehouse – without modifying the database or the application above it.

Analytics

Where data becomes answers. Two distinct engines cover the two main post-storage use cases. ClickHouse handles OLAP workloads: fast columnar queries, real-time aggregations, time-series analysis, and dashboards over millions of rows per second. OpenSearch handles full-text search, log analytics, and observability: complex queries across weeks of event data, anomaly detection, distributed tracing, and alert rules over live event streams. Both engines are designed for reads at scale, not for transactional consistency: this is exactly the trade-off you want after Kafka.

Visualisation

How the answers reach people. Grafana connects to both ClickHouse and OpenSearch, pulling from live data to power dashboards, alert panels, and operational monitors. It is the layer that makes the pipeline visible across the organisation – to the product team checking feature adoption, to the security team watching for anomalies, and the platform team tracking infrastructure health.

Two paths through the same architecture

The topology is consistent regardless of your use case: source database, Kafka as the streaming backbone, one or both analytics engines, and Grafana on top. How you build it depends on what your team needs first.

The real-time analytics path

PostgreSQL + Kafka + ClickHouse + Grafana is the right starting point when the primary need is fast, flexible querying. Product analytics, business intelligence, time-series reporting, funnel analysis, A/B test results in real time: these all call for ClickHouse. It ingests directly from Kafka topics, materialises views that dashboards query in milliseconds, and handles aggregations over hundreds of millions of rows without breaking a sweat. The SaaS company that needs to see feature adoption as it happens, the fintech tracking transaction volumes by the minute, the e-commerce platform running live inventory analytics – these all follow this same path.

The search and observability path

PostgreSQL + Kafka + OpenSearch + Grafana is the right starting point when the primary need is full-text search, log aggregation, or system-wide observability. OpenSearch indexes events as they arrive, enabling complex searches across months of structured and semi-structured data with sub-second response times. The security team correlating events across distributed services, the platform team centralising logs from dozens of microservices, the SRE team building alerts on top of live event streams – these all follow this path.

How the data moves

The connection between your database and Kafka starts with change data capture. CDC is the mechanism that reads your database’s internal write log and turns each modification into a stream of structured events.

In PostgreSQL, this works through logical replication. The write-ahead log records every change made to the database, at the row level. With logical replication enabled, a connector can read that log and emit each change as a structured event with the full before and after state of the row. Kafka Connect is the integration layer that runs these connectors. Debezium, configured as a source connector within Kafka Connect, reads the PostgreSQL WAL and publishes each change to a dedicated Kafka topic. From there, sink connectors route events to ClickHouse, OpenSearch, or both.

One technical development worth understanding for anyone building on Kafka in 2026: Kafka 4.0 removes ZooKeeper entirely. ZooKeeper was the external service Kafka relied on to manage cluster metadata, leader election, and coordination. It was a separate system to deploy, configure, monitor, and upgrade alongside the Kafka brokers. Kafka 4.0 replaces it with KRaft, Kafka’s native Raft-based consensus protocol. Cluster metadata is now managed internally by Kafka itself. The result is a single, self-contained system with fewer components, fewer failure modes, and faster recovery. For anyone who operated a Kafka cluster under the ZooKeeper model, this is a material simplification. For anyone running Kafka as a managed service, the transition is mostly invisible: what you get is a faster, more resilient cluster with one less operational surface.

OpenSearch 3.0 is also a meaningful release for anyone building observability pipelines. The upgrade to Apache Lucene 10 delivers up to 60 per cent lower search latency, with the largest gains on vector search, KNN, and neural search workloads. Star-tree indexing reduces query work for heavy aggregations by up to 100 times. And OpenSearch 3.0 adds native MCP protocol support, which means it integrates directly with AI agents and LLM-based tooling. For teams building observability pipelines that feed into AI-driven incident investigation or alerting workflows, this is a capability that was unavailable even twelve months ago.

Why managed matters

The first thing most teams underestimate about this stack is not the initial setup: it is the ongoing operational surface.

On Kafka, the harder work starts after launch. Partition leader rebalancing when a broker restarts under load. KRaft controller quorum recovery after a node failure. Consumer group offset management when a sink connector falls behind and you need to replay events without duplicating records downstream. JVM heap tuning as throughput grows. Connector worker restart policies that do not lose in-flight events. On OpenSearch, add shard allocation decisions during cluster scaling, index lifecycle management policies to control storage costs as event volumes grow, and JVM tuning for the ML nodes that power vector and neural search. On ClickHouse, merge tree settings and partition pruning strategy matter from day one: getting these wrong early means rewriting table schemas under load.

Managed services absorb this operational surface. Rolling upgrades run without downtime because the service handles leader migration before taking a node offline. Connector workers are monitored and restarted automatically. Failover is handled at the infrastructure level across availability zones. Index lifecycle policies are configurable through the console rather than through manually applied configuration files. Analytics engineers already spend up to 40 per cent of their time on infrastructure maintenance rather than delivering insights. The managed services model moves that complexity to a layer you do not have to own.

For teams in Europe, there is a second dimension. Hyperscaler deployments in EU regions run on infrastructure governed by U.S. law, which means the legal framework around who can access your data, and under what circumstances, is not straightforward. Running on OVHcloud means the infrastructure is European, operational control is European, and the jurisdiction governing data access is unambiguous. For teams in regulated industries, or for any team that fields GDPR compliance questions from customers or auditors, that is a material difference from a cloud region that happens to be located in Europe.

Pricing is the third dimension. Hyperscaler bills can be opaque: data transfer costs between services, storage billed separately from compute, egress fees that compound as event volumes grow. OVHcloud pricing includes IOPS, traffic, and backups. You see the cost before you provision. There are no surprises when your Kafka throughput increases.

Building it on OVHcloud

OVHcloud runs all four layers as managed services, deployed and monitored from a single console.

Provision Managed Kafka, pick your region, and your cluster is ready in minutes. Kafka 4.0 with KRaft means no ZooKeeper to configure or monitor. Add Managed Kafka Connect and configure your PostgreSQL source connector, with optional Debezium CDC for full row-level change capture. Then provision Managed ClickHouse and add a sink connector to start routing events from your Kafka topics into ClickHouse tables, or provision Managed OpenSearch and route events there instead. Add Managed Grafana to connect to both engines and begin building dashboards on live data.

The full stack is five managed services on one platform: PostgreSQL, Kafka, ClickHouse or OpenSearch (or both), and Grafana. One console for provisioning and monitoring. One bill. One support team that understands the full pipeline, not just individual components in isolation.

Start with one layer

You do not have to build the whole pipeline on day one. The most common starting point is Kafka: get your data flowing before you decide where it is going. Once events are moving through Kafka topics, adding ClickHouse or OpenSearch is a connector configuration, not a re-architecture.

The pipeline you build this way is modular by design. Each layer adds independent value. The team that starts with Kafka and adds ClickHouse six months later has not wasted anything in between. The Kafka layer was already doing its job. The pipeline grew without disrupting what was already working.

The infrastructure is managed. The data stays in your hands. The pricing is transparent. The pipeline you need already exists on one stack.

Explore the OVHcloud managed data pipeline

From 1 September 2026, electronic invoicing will come into effect for all businesses and associations subject to VAT in France.

At OVHcloud, we have chosen to plan ahead for this transition to support our clients as best we can. That’s why we are inviting affected clients to verify or complete certain information in their control panel.

What’s changing with electronic invoicing

An electronic invoice must meet strict formatting and layout criteria in order to be automatically processed via approved platforms. It therefore requires reliable and up-to-date administrative data.

The objective of this reform is to:

• Reduce the risks of errors or VAT fraud
• Simplify administrative procedures for businesses
• Speed up payment times
• Allow better monitoring of financial activity (e-reporting)

Two key dates to remember

From 1 September 2026:

• All relevant businesses and associations must be set up to receive electronic invoices.
• Large businesses and medium-sized enterprises must issue their invoices in electronic format.

From 1 September 2027:

• This requirement will be extended to small and medium-sized enterprises (SMEs) and micro-businesses.

Start preparing now

To ensure a smooth transition to electronic invoicing, certain information associated with our client accounts must be complete, accurate, and up to date.

To this end, clients will be invited to:

• verify or complete the information relating to their organisation
• provide their electronic billing address

This information will ensure compliance, as well as ensure that invoices are sent properly in the new format.

If this mandatory legal data is not completed by 1 September, OVHcloud will not be able to issue invoices that comply with the applicable regulatory requirements. As a result:

• We will not be able to identify your business as an entity subject to VAT and will have to consider you as a private customer
• Your invoices will be treated as belonging to a private individual, for which VAT deduction is not applicable
• Automated integration into your accounting will not be activated
• You would be contravening our general terms and conditions of sale
   
  

Committed to our clients

Electronic billing will be a major change for all French companies.

At OVHcloud, we are determined to support our clients in their development and growth goals. That’s why we are committed to assisting them in this transition, particularly by sharing the actions that need to be taken ahead of the upcoming changes.

Go further

Keep checking the official resources to keep up with the latest information made available by the General Directorate of Public Finances.

Software supply chains have become more complex and increasingly targeted, making container image security a fundamental requirement for building trust in modern delivery pipelines.

By signing images with Cosign and protecting signing keys in OVHcloud KMS, teams can keep cryptographic material out of local environments and CI/CD variables, all while making image signing easier to control, audit and integrate into delivery pipelines.

In this blog post, you will learn how to use the OVHcloud KMS plugin for Cosign to generate a key, sign a container image with this key and verify that the OCI image has been correctly signed.

Cosign

Cosign is a tool from the Sigstore project used to sign, verify, and attest OCI container images and software artifacts.

Cosign supports several signing modes, including keyless signing through Sigstore, where short-lived certificates are generated at signing time based on your identity (via GitHub, Google or another OIDC provider), as well as ephemeral key generation, hardware and KMS-backed signing and custom PKI integration.

Cosign supports multiple KMS providers to generate and sign keys. Several external KMS providers are supported, including HashiCorp Vault, AWS KMS, GCP KMS and Azure Key Vault.
Cosign can now also be integrated with OVHcloud KMS through the Sigstore Cosign OVHcloud KMS plugin 💪.

OVHcloud Key Management Service (KMS)

OVHcloud KMS, often called OKMS, is a managed service that centralizes the creation, storage, and management of encryption keys. Its main goal is to help businesses secure data and control cryptographic operations from a single platform.

Each KMS is associated with a region, so the keys stored in that region are guaranteed to stay in that region. You can order multiple KMSs, either in different regions or in the same region.

Prerequisites

To be able to use the Sigstore KMS OVHcloud provider, you need to follow some prerequisites:

• Have an OVHcloud account
• Have created an OKMS domain (“305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have created an IAM local user (“cosign-305db938-1234-5678-9012-3a0a29291661” for example in this blog post)
• Have installed the OVHcloud CLI
• Have uuidgen CLI installed

💡The cosign OVHcloud plugin supports both token and mTLS authentication. For the purposes of this blog post, we will use the token authentication mode. Please follow the Sigstore Cosign KMS plugin for OVHcloud guide if you wish to use mTLS authentication mode.

Generate a PAT token (for token authentication only)

List the OKMS domains:

$ ovhcloud okms list
┌──────────────────────────────────────┬─────────────┐
│                  id                  │   region    │
├──────────────────────────────────────┼─────────────┤
│ 305db938-1234-5678-9012-3a0a29291661 │ eu-west-par │
│ xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx │ eu-west-par │
└──────────────────────────────────────┴─────────────┘

Save the OKMS ID in an environment variable:

export KMS_RESTAPI_OKMSID="305db938-1234-5678-9012-3a0a29291661"

The cosign OVHcloud plugin needs the permission to create and fetch keys from the OVHcloud KMS.

If you want to use token autentication, you’ll need a token (PAT). You can use the ovhcloud CLI to do that:

PAT_TOKEN=$(ovhcloud iam user token create <iam-local-user-name> --name pat-<iam-local-user-name> --description "PAT cosign for domain $KMS_RESTAPI_OKMSID" -o json  | jq .details.token |  tr -d '"')

echo $PAT_TOKEN

You should have a result like this:

$ PAT_TOKEN=$(ovhcloud iam user token create cosign-305db938-1234-5678-9012-3a0a29291661 --name pat-cosign-305db938-1234-5678-9012-3a0a29291661 --description "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661" -o json  | jq .details.token |  tr -d '"')
2026/05/07 08:48:34 Final parameters:
{
 "description": "PAT cosign for domain 305db938-1234-5678-9012-3a0a29291661",
 "name": "pat-cosign-305db938-1234-5678-9012-3a0a29291661"
}

$ echo $PAT_TOKEN
eyJhbGciOiJFZE...ASgXy55_DDFHdy4Z5uSq8lww-Bw

Save the KMS information

Save the KMS information in environment variables. For example:

export KMS_RESTAPI_ENDPOINT=$(ovhcloud okms get $KMS_RESTAPI_OKMSID -o json | jq .restEndpoint | xargs)
export KMS_RESTAPI_TYPE="token"
export KMS_RESTAPI_TOKEN=$PAT_TOKEN

Display the saved information:

$ echo $KMS_RESTAPI_ENDPOINT
https://eu-west-par.okms.ovh.net

$ echo $KMS_RESTAPI_OKMSID
305db938-1234-5678-9012-3a0a29291661

$ echo $KMS_RESTAPI_TYPE
token

$ echo $KMS_RESTAPI_TOKEN
eyJ...BIoHCA

Cosign KMS plugin installation

Install the plugin locally:

curl -fsSL https://raw.githubusercontent.com/ovh/sigstore-kms-ovhcloud/main/install.sh | sh

⚠️ The binary is installed in $HOME/.local/bin by default (created if it does not exist). Make sure this directory is in your PATH.

Or follow the other installation methods.

Now you can use the OVHcloud KMS plugin directly in the cosign command 🎉.

Let’s use Cosign with the OVHcloud KMS!

Generate a key

First, to sign an image, we need to generate a key pair. To do that we need to generate a UUID and use it in the cosign generate-key-pair command.

export KEY_ID=$(uuidgen)
cosign generate-key-pair --kms ovhcloud://$KEY_ID

The signing key is created in OVHcloud KMS, and the public key is written locally.

You should see an output like this:

$ export KEY_ID=$(uuidgen)
$ cosign generate-key-pair --kms ovhcloud://$KEY_ID

Public key written to cosign.pub

The command generates a key pair using the ECDSA algorithm and writes the public key to cosign.pub.

Check the keys have been created:

$ ls -l cosign.pub
-rw-------  1 avache  staff  178 18 juin  16:06 cosign.pub

$ cat cosign.pub

-----BEGIN PUBLIC KEY-----
MFkw...QgwA==
-----END PUBLIC KEY-----

Once the key pair has been generated, use the corresponding OVHcloud KMS key ID in the ovhcloud://$KEY_ID URI when signing and verifying images.

Or get an existing public key (optional)

Instead of creating a new public key, you can retrieve an existing one with the following command:

cosign public-key --key ovhcloud://$KEY_ID --outfile cosign-ovhcloud.pub

Sign an image

Replace the $IMAGE@sha256:$HASH parameter with the URI to your image and the hash to your image and execute this command:

cosign sign --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign sign --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verify the image has been signed

cosign verify --key ovhcloud://$KEY_ID $IMAGE@sha256:$HASH

You should see an output like this:

$ cosign verify --key ovhcloud://$KEY_ID 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Verification for 12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The signatures were verified against the specified public key

[{"critical":{"identity":{"docker-reference":"12345678.c1.de1.container-registry.ovh.net/my-project/my-image@sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"},"image":{"docker-manifest-digest":"sha256:b1202...2334e2"},"type":"https://sigstore.dev/cosign/sign/v1"},"optional":{}}]

Conclusion

In this blog post, we have shown how to use Cosign with the OVHcloud KMS plugin to generate a key pair, sign a container image and verify its signature.

By keeping signing keys in a managed KMS, teams can reduce secret sprawl, protect sensitive cryptographic material and make image signing easier to integrate into secure CI/CD workflows.

Feel free to take a look at our Cloud Roadmap & Changelog to follow the latest features coming to OVHcloud Public Cloud products.

À partir du 1^er septembre 2026, la facturation électronique entre en vigueur pour l’ensemble des entreprises et associations assujetties à la TVA en France.

Chez OVHcloud, nous avons choisi d’anticiper cette transition pour accompagner nos clients dans les meilleures conditions. À ce titre, nous invitons les clients concernés à vérifier ou compléter certaines informations dans leur espace client.

Ce qui change avec la facturation électronique

Une facture électronique doit répondre à des critères stricts de formatage et de mise en forme afin d’être automatiquement traitée via des plateformes agréées. Elle nécessite donc des données administratives fiables et à jour.

L’objectif de cette réforme est de :

• réduire les risques d’erreurs ou de fraude à la TVA ;
• simplifier les démarches administratives des entreprises ;
• accélérer les délais de paiement ;
• permettre un meilleur suivi de l’activité économique (e-reporting).

Deux dates clés à retenir

À partir du 1er septembre 2026 :

• Toutes les entreprises et associations concernées devront être en mesure de recevoir des factures électroniques.
• Les grandes entreprises et les entreprises de taille intermédiaire (ETI) devront émettre leurs factures au format électronique.

À partir du 1er septembre 2027 :

• L’obligation d’émission sera étendue aux petites et moyennes entreprises (PME) et aux micro-entreprises.

Se préparer dès aujourd’hui

Pour assurer une transition fluide vers la facturation électronique, certaines informations associées aux comptes clients doivent être complètes, exactes et à jour.

Dans ce cadre, les clients seront invités à :

• vérifier ou compléter les informations relatives à leur organisation ;
• renseigner leur adresse de facturation électronique.

Ces informations permettront de garantir la conformité et la bonne transmission des factures au nouveau format.

En l’absence de données légales obligatoires complètes le 1^er septembre, OVHcloud ne serait pas en mesure d’émettre des factures conformes aux exigences réglementaires applicables. En conséquence :

• nous ne pourrons pas les identifier comme des entités assujetties à la TVA et devrons les considérer comme des clients particuliers ;
• leurs factures seront traitées comme celles d’un particulier pour lesquelles la déduction de TVA n’est pas applicable ;
• l’intégration automatisée dans leur comptabilité ne sera pas activée ;
• les clients concernés seraient en situation de non conformité avec nos conditions générales de vente.
   

Engagés auprès de nos clients

La facturation électronique constitue une évolution majeure pour l’ensemble des entreprises françaises.

Chez OVHcloud, nous avons à cœur d’accompagner nos clients dans leur développement et leurs objectifs de croissance. Dans ce cadre, nous nous engageons à les soutenir dans cette transition, notamment en communiquant sur les actions à réaliser pour anticiper les changements à venir.

Pour aller plus loin

Nous vous invitons à consulter régulièrement les ressources officielles pour suivre les dernières information mises à disposition par la Direction Générale des Finances Publiques.