01 · Noise

From noisy systems to decisions people can trust.

I'm Yohann Lesueur, a Python backend developer applying to join Sekoia.io. You are building an Autonomous SOC where machines investigate and people stay in control. I build reliable backends for agentic systems and make complex, inherited software safe to change.

Getting to the point Contact me

02 · Structure

Throughput is only part of the problem.

Reliable event processing also means controlling priorities, handling retries, preventing duplicate effects, and keeping downstream data consistent when part of the system fails.

I have applied those principles to asynchronous workflows and cascading financial computations, using dedicated queues, real-time and batch priorities, idempotent processing, and a transactional outbox for reliable event publication.

My production experience is with Celery and Redis, not Kafka or ClickHouse. The tools differ. The engineering questions are familiar.

03 · Correlation

Taking ownership of what already exists.

Accenta.ai · Apr 2023 → Jul 2025 · Energy and carbon platforms covering 10 million m²: I rebuilt a sensor data ingestion pipeline whose history had been compromised by years of unreliable readings. This required tracing data across undocumented legacy PHP systems, redesigning the storage model, and rewriting the import process.
The result: years of historical data reprocessed without duplicates, with faster imports through parallel processing and bulk writes.
I also reworked a real-time data visualisation module that had become risky to change. Hexagonal architecture and TDD made its behaviour testable and future changes safer.
Dawan · Sep 2019 → Sep 2021: For two years, I trained developers ranging from complete beginners to experienced engineers. I adapted sessions to their actual level, reviewed code individually, debugged problems live, and supported projects through to production. Taking ownership also means making a system easier for the next person to understand.

04 · Investigation

An agent that executes tools is an attack surface.

At iDem Agency, I designed and built the backend of Agentive, a platform where teams of AI agents collaborate on the same task.

The system combines FastAPI, PostgreSQL and pgvector with provider independent access to Anthropic and OpenAI. It handles automatic fallback, error classification, cost estimation, secret masking, retrieval-augmented generation, and sandboxed tool execution through MCP.

A transactional outbox keeps event publication reliable, while architecture rules enforced in CI prevent dependencies from quietly crossing system boundaries.

This was not a cybersecurity product. But the central engineering question was already familiar: how do you let autonomous agents act without surrendering control?

05 · The decision

The machine investigates.
The human decides.

You will probably find a few apparent gaps in my background.

I have not yet worked with Kafka or ClickHouse on a platform processing hundreds of thousands of events per second. My experience lies elsewhere: reliable asynchronous processing, event consistency, idempotency and systems designed to remain maintainable under real constraints. (Celery + Redis)

I also do not come from cybersecurity. My entry point is the security of agentic systems. At iDem, I worked on agents that execute tools, with sandboxed execution, secret masking and explicit architectural boundaries. Autonomous systems are also attack surfaces and that is a problem I already know how to think about. I also take some courses on Hack the Box.

My full-stack and agency background may also create the wrong impression. Since 2021, my core focus has been backend development with Python, Django and FastAPI.

Spoken English is a current limitation. I read, listen and write technical English every day, and I can work in English (C1 level). I am not yet fluent in spontaneous conversation because of a lack of practice. Since fluent English is a requirement for this role (C2), I would rather have that assessed during the first exchange than hide it behind a polished application.

06 · The Plan

The first 90 days

Day 0 → Day 30 Understand and contribute. My priority would be to understand the squad’s perimeter, architecture, workflows and operational constraints. I would learn the product vocabulary: STIX, Sigma, ECS, CTI, playbooks, detection and remediation and map the main flows from user need to production.
At the same time, I would aim to deliver small, well-scoped contributions from the first weeks: bug fixes, tests, documentation or minor improvements. This would help me become useful quickly while building a reliable understanding of the existing codebase.

Day 30 → Day 60Deliver with the team. Once familiar with the perimeter, I would take ownership of features end to end: clarify the requirement with Product, challenge technical assumptions when necessary, implement the backend changes, add the appropriate tests and follow the feature through review and deployment.
I would also contribute actively to code reviews and technical discussions, while documenting the parts of the system that were difficult to understand during onboarding. This documentation would make the product easier to maintain and future onboarding more efficient.

Day 60 → Day 90Take ownership. By this stage, I would aim to own a clearly defined part of the product, including its features, bugs, technical trade-offs and future evolution.
I would contribute to improving the squad’s engineering practices where useful testing, documentation, observability or development workflows without trying to change everything at once. My goal would be to become a dependable point of contact for my perimeter and, when the opportunity arises, help onboard the next team member.