Dorian Wilhelm

_{alias Daihyxsk}

Administrateur Systèmes Linux · DevOps

J'automatise des systèmes et je règle des problématiques concrètes, entre développement, système libre et cybersécurité.

Nouvelle-Aquitaine · Remote et full remote

---

Ce que je construis

J'aime automatiser ce qui se répète et régler des problématiques concrètes, si bien qu'aucun de ces projets n'est né d'une envie d'empiler des technologies, mais chaque fois d'un agacement, d'un besoin réel, ou de l'envie de comprendre une techno en la pratiquant pour de bon.

Outillage système

Projet	Ce que ça fait	Stack
ansible-manager.sh	Met la gestion du vault, de l'inventaire et de l'exécution des playbooks Ansible derrière une seule commande.	Bash Ansible
kvm-cli-scripts	Pilote les VM KVM/QEMU en ligne de commande sans passer par les options de virsh.	Bash KVM/QEMU libvirt
repos-manager	Clone et synchronise des dépôts sur GitHub, GitLab, Forgejo, Bitbucket et Radicle depuis un seul CLI.	Python
git-identity-manager	Fixe l'identité Git dépôt par dépôt, avec sélection de l'identité via fzf.	Bash fzf Git

Sécurité

Projet	Ce que ça fait	Stack
bwsshd	Garde les clés SSH privées dans un coffre Bitwarden au lieu du disque et génère le ssh_config correspondant, à raison d'une clé par hôte, l'accès au coffre remplaçant la passphrase par clé.	Go SSH Bitwarden
dotenv-sec	Monte en une commande un environnement de pentest reproductible avec tmux, un proxy MITM, un Chromium isolé et Exegol, sur des images durcies et analysées par Trivy en CI.	Docker Exegol Trivy
PoC CVE-2024-41817	Exécution de code arbitraire sur ImageMagick via délégation XML, repris comme support d'un challenge de cybersécurité.	Python ImageMagick

Pédagogie

Projet	Ce que ça fait	Stack
git-chronicles	Enseigne Git à travers 23 quêtes bilingues qui vont de git init au CI/CD, dans un cadre narratif heroic fantasy.	Git FR/EN

Chantiers en cours, code fermé

Projet	Ce que ça fait	Stack
Infra Souveraine	La forge que vous lisez, où chaque machine tire sa propre configuration depuis le dépôt en ansible-pull, les services étant joignables en zero trust et l'ensemble provisionné depuis une VM vide par une collection Ansible privée.	Forgejo Ansible GitOps NetBird Proxmox
NetBird Ops Console	Pilote un parc de serveurs Linux depuis un client lourd, sans serveur central ni port d'administration ouvert, avec un agent par machine joignable uniquement à travers le mesh et un transport gRPC retenu après un banc d'essai chiffré.	Rust gRPC Tauri Svelte NetBird
cvforge	Génère mes CV en plusieurs variantes depuis une seule source YAML, avec thèmes, contrôle du budget de pages et vérification de compatibilité ATS.	Python YAML PDF

---

Ce avec quoi je travaille

Systèmes. Je suis surtout à l'aise sur Debian et Ubuntu, un peu moins sur Rocky Linux et Alpine Linux que je croise selon les contextes, le tout virtualisé sur Proxmox, KVM/QEMU ou ESXi. Quand un déploiement le demande, je construis des images sur mesure en preseed Debian, cloud-init ou ISO d'installation.

Déploiement. Je m'appuie sur Ansible en rôles et collections, en GitOps via ansible-pull, avec des conteneurs Docker ou Podman et des pipelines Forgejo Actions, GitLab CI ou GitHub Actions selon l'endroit où vit le dépôt. Côté cloud j'ai surtout pratiqué OVH Public Cloud et du S3, avec ce qu'il faut de DNS, DHCP, PXE et reverse-proxy autour.

Code. J'écris principalement du Python et du Bash pour l'outillage, et j'ai quelques binaires en Go que je compte réécrire en Rust, autant pour le résultat que pour l'excuse d'apprendre le langage sur du code que j'utilise vraiment.

Sécurité. Je fais de la détection et de l'analyse sur FortiSIEM et Sekoia, et le reste tourne autour du durcissement réseau, système et services sous Linux, avec nftables et iptables, et des overlays zero trust en NetBird et WireGuard.

---

Le parcours

J'ai commencé par réparer des machines, puis par écrire du code, et un jour j'ai voulu comprendre ce qu'il y avait dessous.

Le système libre m'a attrapé là et ne m'a plus lâché : des sources qu'on peut lire, des outils qu'on peut détourner, des infrastructures qu'on peut reconstruire de zéro juste pour voir comment elles tiennent debout. Autodidacte, j'apprends en construisant, quitte à casser plusieurs fois avant d'automatiser.

La sécurité est arrivée dans la foulée, parce que je ne comprends jamais aussi bien un système qu'en cherchant par où il casse. J'en ai fait mon métier comme analyste SOC, d'abord en L1 puis en L2, à qualifier des événements et à suivre des incidents. En dehors du travail je fais du CTF sur Root-Me et de l'offensif orienté web et Linux, avec quelques PoC de CVE et un peu de bug bounty au passage. Cette corde-là ne s'est jamais détendue, et elle ressort chaque fois que je durcis ce que je déploie.

Mon curseur s'est déplacé vers le développement, et le Rust prend aujourd'hui le plus clair de mon temps libre, appris en construisant de vraies choses plutôt qu'en enchaînant les tutoriels. Le fil rouge n'a pas bougé pour autant : comprendre un système en profondeur, l'automatiser, le rendre reproductible, transmettre ce que j'apprends au passage. C'est ce qui m'a amené au GitOps et à l'Infrastructure as Code.

---

Pourquoi cette forge

Cette forge est une instance Forgejo auto-hébergée sur mes propres machines, déployée et maintenue en ansible-pull. Le code, les tickets, la CI et les artefacts vivent sur une infrastructure que j'administre, dans un cadre juridique européen. Pas de politique de service qui change, pas de conditions d'utilisation à relire tous les six mois, pas d'usage tiers de mes dépôts, entraînement de modèles compris. Analyser des incidents et réduire des surfaces d'exposition toute la journée donne du mal à pousser ses notes d'infrastructure et ses inventaires chez quelqu'un d'autre : ce qui est privé ou personnel reste donc ici, chiffré, sauvegardé sous mon contrôle, accessible en zero trust via NetBird, sans port d'administration exposé.

L'héberger oblige évidemment à la maintenir, entre les mises à jour, les sauvegardes, la supervision et la restauration qu'on teste avant d'en avoir besoin, mais c'est précisément le terrain qui m'intéresse, au point que la forge est devenue autant une vitrine de la démarche qu'un outil de travail. Pour l'open source en revanche, la visibilité compte, autant pour les contributions que pour la découverte : mes projets publics sont donc publiés sur GitHub, qui reste le point d'entrée le plus simple et la destination des liens ci-dessus. La forge garde le rôle de source de vérité, et le privé ne quitte pas mes machines.

---

Me contacter

Forge · forge.infrasouveraine.fr

GitHub (miroir open source) · github.com/Dxsk

E-mail · daihyxsk@pm.me

_{Ce dépôt vit sur ma propre infrastructure, merci d'être passé.}