$ cat about.txt

À propos

Je suis développeur bas niveau, spécialisé Rust et systèmes Linux. J'ai fini une licence informatique à l'URCA (Reims) sans avoir eu de poste professionnel — pas faute d'essayer, mais ça ne change pas grand chose à ce que j'ai construit en dehors.

La majorité de mon expérience vient de projets personnels où je voulais comprendre comment les choses marchent vraiment : pas "appeler la lib", mais comprendre pourquoi la lib fait ce qu'elle fait, et si je peux faire mieux dans mon contexte. C'est ce qui m'a poussé à écrire un KV store Redis-compatible en Rust — pas pour réinventer Redis, mais pour avoir les mains dans l'io_uring, les arbres radix, la gestion mémoire à grain fin.

Je suis à l'aise avec la mémoire virtuelle (mmap, madvise, huge pages, TLB pressure), l'optimisation de cache (localité de données, padding, alignement), et les modèles d'I/O asynchrones — je peux écrire des appels système directement sans passer par libc quand c'est nécessaire. Linux est mon environnement naturel, pas juste mon OS.

Je connais C, et C++ est à portée — avec Rust comme base, prendre en main un codebase C++ en contexte pro ne m'inquiète pas. Le bas niveau a une logique commune quelle que soit la syntaxe.

// compétences techniques

Rust

  • ownership, lifetimes, unsafe — pas de peur
  • async/await, futures, runtimes (monoio, tokio)
  • layout mémoire, repr(C), niche optimization
  • macro procédurales, traits avancés
  • profiling, flamegraphs, perf annotate

Systèmes Linux

  • mémoire virtuelle : mmap, madvise, THP
  • io_uring : SQE/CQE, SQ_POLL, modes d'opération
  • syscalls directs, eBPF basique, /proc, perf_events
  • optimisation cache : L1/L2/TLB, prefetch, faux partage
  • data-oriented programming, structure de tableaux

C / C++

  • C : maîtrisé, pointeurs, allocateurs custom
  • C++ : connaissances solides, montée en charge rapide
  • compréhension du modèle mémoire commun

Réseaux & protocoles

  • TCP/IP, parsing de protocoles binaires
  • RESP2 (Redis Serialization Protocol)
  • modèles event-driven, pub/sub, pipelining

// façon de travailler

Je lis les sources avant de lire la doc. Si quelque chose est lent, je profile avant de toucher au code. Si une abstraction me cache quelque chose d'important, je regarde ce qu'il y a dessous.

La performance n'est pas une obsession — c'est une contrainte comme une autre, qui se raisonne avec des données. Ce qui m'intéresse, c'est comprendre pourquoi un système se comporte d'une certaine façon, pas juste le faire marcher.

// contact