Markdown — profil recruteurs / IA

Rendu marked.js (côté serveur) • aucun lien externe • 100 % autonome

← Retour au site 
document_type: candidate_profile
schema_hint: ats_ai_ingestion_v1
language: fr
full_name: "Oulom Souvannavong"
role_title: "Tech Lead intégration DevOps & cloud souverain — Linux, K8s, IA"
email: "ouloms@gmail.com"
phone_e164: "+33618679600"
location: "142 avenue de Saint-Ouen, 75018 Paris"
website: "https://oulom-souvannavong.fr/"
source_page_title: "Oulom Souvannavong — Tech Lead intégration DevOps & cloud souverain — Linux, K8s, IA"

Oulom Souvannavong

Rôle : Tech Lead intégration DevOps & cloud souverain — Linux, K8s, IA

Je conçois et fiabilise vos plateformes critiques — du bare-metal au cluster Kubernetes, du cloud souverain aux agents IA en production.

Résumé professionnel

Plus de 20 ans en production critique sur environnements Linux, mêlant intégration DevOps (Ansible, Terraform, GitLab CI), virtualisation et clouds souverains (VMware, OpenStack/NUBO, Kubernetes/Onyxia), et désormais IA en production. Référent technique transverse au Ministère des Finances, à Radio France, à la BnF, à l’INPI.

Nationalité française — Paris. Référent technique sur des environnements critiques : lien entre production et développement, automatisation des livraisons, sécurisation et exploitation à grande échelle (centaines de VMs, supervision, stockage).

Profil humain

Ingénieur curieux, posé et engagé : depuis vingt ans, je travaille au cœur des systèmes d’information critiques d’organismes français — Ministère des Finances, Radio France, BnF, INPI — en gardant le goût d’apprendre et d’expérimenter. J’aime être le point de rencontre entre la production et les équipes de développement, transmettre ce que j’ai compris, et rendre les systèmes plus fiables et plus sereins pour ceux qui les exploitent.

Contact

Indicateurs clés (stats)

Organisations de référence (confiance / références)

Arguments valeur (pourquoi ce profil)

Production critique sans coupure

Mises en production préparées, plans de retour arrière systématiques, PRA inter-datacenters. Continuité d’exploitation prouvée sur des organismes de dépôt et de service public.

Pile complète : du matériel au cloud

Du montage en baie et du SAN Fibre Channel aux clusters Kubernetes et au stockage S3 / Ceph. Une vue de bout en bout que peu de profils revendiquent.

Intégration & automatisation

Ansible, Terraform, Jenkins, GitLab CI, Helm. Je transforme les chaînes fragiles en livraisons fiables — et je documente ce que je fais.

Référent technique transverse

J’accompagne les chefs de projet, je débloque les équipes sur Linux/AD, virtualisation et sécurité ANSSI, et je transfère mes savoir-faire.

L’IA, expertise opérationnelle élargie

LLM intégrés à mon outillage : Cursor, agents n8n + Claude, inférence locale Ollama / Mistral, RAG. Concrètement : agents IA en production en TPE, RAG juridique livré en hackathon, et ce portfolio en data-driven build.

Expérience professionnelle

Ministère des Finances — Bercy HUB & DGFIP — Consultant indépendant expert Linux

Points saillants :

Deux entités

Missions auprès d’ au moins deux entités du ministère : Bercy HUB pour le projet Nubonyxia , puis la DGFIP (impôts) pour le projet RADAR .

Bercy HUB — projet Nubonyxia

Le projet Nubonyxia repose sur la mise à disposition du logiciel Onyxia — issu de l’ Insee et du travail des équipes Bercy . Onyxia s’installe sur un cluster Kubernetes et déploie les charges sous forme de pods via des charts Helm . L’offre est portée sur le socle d’hébergement retenu ( Bercy HUB / NUBO ), d’où le nom du projet (lien Nubo / Onyxia ). Rôle : participation au MCO d’une installation déjà en production et mise en place de services supplémentaires . Dans la pratique : adaptation des charts Helm pour qu’ils puissent être lancés depuis le portail Onyxia — transformation des paquets « à la sauce Onyxia » pour respecter le modèle du catalogue et les exigences de conformité . Une chaîne d’automatisation existait déjà pour faire circuler les livrables du développement jusqu’à la mise à disposition des utilisateurs . J’assurais notamment le bon fonctionnement de cette chaîne d’intégration continue , avec de nombreux sujets à traiter sur l’authentification et la sécurité . Une des grosses difficultés : cartographier l’ensemble des composants et flux à rendre visibles et maîtrisables — le périmètre était difficile à cadrer alors que l’ authentification posait de nombreux problèmes et que les chaînes d’intégration continue restaient peu stables .

DGFIP — projet RADAR

Objectif du projet RADAR : disposer d’un référentiel qui agrège plusieurs sources d’inventaire afin de réaliser l’état des lieux des versions des composants structurants du système d’information (visibilité sur le parc et ce qui est effectivement en production). Poste d’ intégrateur applicatif DevOps sur ce périmètre : chaîne d’outillage Ansible , Nexus , Jenkins , GitLab , avec services notamment CMDBUILD et Apache NiFi , complétés par Tomcat , PostgreSQL , socle Linux sur NUBO / OpenStack . Pour le déploiement , le projet s’appuie en particulier sur Jenkins et Ansible . À notre arrivée , la plateforme présentait de nombreux dysfonctionnements . Mon rôle a surtout consisté à stabiliser ce qui avait déjà été livré — dont la rédaction et la maintenance du code Ansible et Terraform pour la création des machines virtuelles sous OpenStack — puis à piloter la montée en version de l’ensemble des composants RADAR — dont le passage de CMDBUILD à la dernière version disponible (alignement avec la chaîne d’intégration et les dépendances). En l’absence de développeur JavaScript dédié, participation à la maintenance et à l’ évolution de l’IHM RADAR, réalisée avec le framework Ext JS .

Enedis, Fayat IT — Missions d’appui

Points saillants :

Enedis — janv. 2025

Conception d’un banc d’essai pour des logiciels temps réel : vérification du chaînage entre Linux et l’ application temps réel .

Fayat IT — janv. 2024

Intervention sur la migration d’un logiciel de l’environnement Linux vers Windows .

RYC — aide aux entreprises — Assistance informatique (société familiale)

Points saillants :

Détail

Depuis 2005 , accompagnement de RYC , structure d’ aide aux entreprises (conseils administratifs , précomptabilité notamment avec Sage Coala ). Appui informatique et bureautique : postes de travail Windows côté clients ; serveurs Linux pour l’infrastructure, avec partage de dossiers via Samba — le logiciel Coala tournant sur les postes Windows .

Automatisation des flux comptables

Depuis environ cinq ans , forte montée en automatisation : extraction automatique des relevés bancaires et intégration semi-automatique dans le logiciel comptable jusqu’à la saisie des écritures comptables. Très récemment : extraction automatique des factures et des pièces jointes pour générer les écritures comptables , en s’appuyant aussi sur le rapprochement bancaire .

IA, agents et orchestration (très récent)

L’arrivée de l’ IA a ouvert de nouvelles possibilités : conception d’ agents IA , utilisation de n8n pour le tri et le traitement des documents, appels d’ API — notamment Claude (Anthropic) — pour la reconnaissance et l’ exploitation des documents, en prolongement des automatisations existantes. Première expérience d’ inférence locale de deux modèles via Ollama (exécution sur poste / serveur), sur la base des LLM Mistral .

Naarea — énergie (petits réacteurs modulaires) — MCO plateforme HPC

Points saillants :

Contexte

Startup dans la filière petits réacteurs nucléaires modulaires (SMR) ; système d’information majoritairement sous Windows , avec décision d’investir dans une plateforme HPC pour la simulation et le calcul scientifique.

Zone protégée — annuaire, auth et messagerie

L’ensemble du parc Linux était situé dans une zone réseau protégée . Il fallait donc des infrastructures dédiées sur ce périmètre : un annuaire LDAP , un mécanisme d’ authentification propre à la zone, et un relais SMTP pour la messagerie des services concernés.

Master Linux — préconisations ANSSI

À Naarea , élaboration d’un master Linux pour déployer un socle homogène et durable : capitalisation sur mon expérience et alignement sur les guides et préconisations de l’ ANSSI (durcissement, bonnes pratiques).

Plateforme Lenovo — cluster Slurm

Infrastructure Lenovo : 10 nœuds de calcul , 4 machines de développement , 3 machines sous Proxmox pour l’hébergement de VMs. NAS avec partages NFS pour les données partagées exploitées par le cluster Slurm . Réseau InfiniBand . Configuration de l’ensemble avec Salt (SaltStack). Observabilité et exploitation : Grafana, Prometheus, Centreon ; OpenMP, MPI, Python, Bash ; Helm selon les besoins.

Mission — Slurm, Proxmox et support Linux

Exploitation du cluster Slurm et de l’infrastructure Proxmox (virtualisation, hébergement des machines virtuelles). Rôle multi-casquette sur les besoins nécessitant un Linux : intégration des codes de calcul avec les bibliothèques scientifiques (MPI, pile logicielle HPC) ; chaînes d’ intégration continue avec GitLab ; conteneurs — démarrage sous Docker , puis usage d’ Apptainer (Singularity) pour les charges compatibles avec le calcul haute performance.

Radio France — Expert Linux — projet infrastructure

Points saillants :

Projet OnAir

Recrutement dans le cadre du projet OnAir : migration d’une partie du système d’information métier radio vers un socle logiciel Linux, alors que l’existant reposait jusqu’alors essentiellement sur Windows.

Linux, Active Directory et SSSD

Avant mon arrivée, trois ingénieurs Linux s’étaient succédé pour tenter de débloquer la situation. Point critique : l’authentification et l’accrochage des nouveaux serveurs Linux au réseau Microsoft (Active Directory), via SSSD. Comportement observé : lenteurs importantes ou absence de réponse — et aucune équipe n’arrivait à en comprendre la cause. Diagnostic et corrections sur la chaîne d’intégration Linux / AD (SSSD) ayant permis de résoudre ces incidents bloquants.

Mission — expertise Linux

Embauché en tant qu’expert Linux pour soutenir l’équipe projet infrastructure sur les dossiers Linux — dont la création d’un master Linux (Debian/Ubuntu) dans un domaine AD (Preseed/PXE), le durcissement des installations, et la participation au support de niveau 3. Assistance expert aux projets applicatifs Linux ; microservices ; automatisation Bash/Ansible. Formations Azure et Kubernetes.

Stack technique — VMware, PXE, Ansible

L’ensemble du périmètre était hébergé sur VMware . Les environnements de développement reposaient sur des machines démarrées en PXE (boot réseau). Pour la personnalisation et le déploiement : playbooks et rôles Ansible , avec Rundeck puis Ansible Tower (évolution de la chaîne d’orchestration / d’automatisation).

Master Linux — MCO, MCS et ANSSI

Côté Radio France , en complément des seules spécifications techniques pour la création du master Linux , j’ai pu investir du temps sur un cadrage pensé pour la durée : pour le MCO (maintien en conditions opérationnelles), en m’appuyant sur mon expérience professionnelle d’exploitation ; pour le MCS (maintien en conditions de sécurité), en nous inspirant du référentiel de l’ ANSSI .

Conseil — Cyberwatch

En réinvestissant l’expérience acquise à l’INPI sur Cyberwatch , j’ai conseillé Radio France sur l’installation de la plateforme (vulnérabilités, conformité) pour les environnements Linux .

Bibliothèque nationale de France (~3000 agents) — Ingénieur intégrateur

Points saillants :

Bureau B2I — ingénierie et intégration

Le bureau B2I (ingénierie et intégration) faisait le lien entre les équipes de production et d’exploitation et les équipes recherche & développement / études — en somme la colle entre développement et prod. Petite équipe d’une dizaine de personnes répartissant l’ensemble du portefeuille applicatif de l’institution. Profils volontairement polyvalents : il fallait cumuler le savoir-faire exploitation / production et celui des études et du développement, et pouvoir intervenir sur tout le spectre sans cloisonnement.

Agile, Redmine et double casquette

Travail en mode agile ; suivi des tâches de développement dans Redmine. Accompagnement de chaque projet : côté études et développement, référents techniques ; côté production, intégrateurs.

Portefeuille métier

Portefeuille orienté métiers : bibliographie et service public. Parmi les logiciels majeurs : le catalogue général, outil central du plan documentaire de la bibliothèque ; à égalité d’importance stratégique, le système de réservation — réservation des livres et réservation des salles — au cœur du fonctionnement de la BnF. Service public : billetterie, caisses, etc.

SI service public — accès NFC et billetterie

Responsabilité du système d’information du service public : contrôle d’accès fondé sur des cartes NFC et la gestion des droits (accès aux salles, portes et portiques avec lecteurs de badge). Côté billetterie, solution Vivaticket et postes de caisse associés : chaque caisse regroupait un ordinateur avec le logiciel de vente, un écran tactile et une imprimante Zebra pour l’impression des billets et étiquettes.

Projet — intégration Heurist (Heurist Network)

Projet d’intégration du logiciel Heurist ( HeuristNetwork/heurist sur GitHub ) : plateforme web open source de gestion de données de recherche en sciences humaines (PHP, JavaScript, MySQL).

Reprise de poste et périmètre hérité

L’un des objectifs du rôle : reprendre le travail de mon prédécesseur, qui avait notamment conduit beaucoup de développements ou d’intégrations spécifiques par rapport aux normes existantes ou, plus largement, par rapport à l’état de l’art.

Préparation des livraisons et automatisation

Une des principales difficultés : en amont de chaque livraison, revue des commits des développeurs, arbitrage de ce qui doit entrer dans la bonne version (périmètre de la release), fusions sur les branches Git, puis préparation des releases — pilotage de l’historique et des branches, pas seulement la structure des répertoires. Objectif : automatiser une grande partie de cette préparation pour fiabiliser et accélérer le cycle.

Livrables, production et outillage

Côté projet et études : préparer pour la production les packs d’installation, la documentation, les processus de mise en production, les notes de version, le bon de livraison et le nécessaire au déploiement. Nous étions aussi responsables de l’installation des environnements en production : avec Jenkins, déploiement des environnements alignés sur les versions de développement en cours — intégration continue ; Sonar pour contrôler la qualité du code. Les conteneurs (Podman) et Ansible ont été intégrés au fur et à mesure. Stack applicative majoritaire à la BnF : Java, Tomcat, PostgreSQL ; à côté, Git, Node.js, React, Linux (CentOS), VMware, oVirt selon les périmètres. Formations DevOps fondation et Kubernetes.

INPI — Institut national de la propriété industrielle (~800 agents) — Ingénieur architecte système Linux & virtualisation (VMware, oVirt)

Points saillants :

Après Sungard — arrivée à l’INPI

Après l’expérience chez Sungard, intégration de l’INPI — environ neuf ans sur la durée, expérience très riche. À l’arrivée : pas encore de virtualisation ni de conteneurs au sens où on les pratique aujourd’hui ; les services étaient encore massivement installés sur machines dédiées (approche « bare metal »). Linux n’était pas encore majoritaire sur l’ensemble du parc : beaucoup de Windows et d’Unix propriétaires (HP-UX, AIX, Solaris). Les années suivantes ont largement fait évoluer le paysage (virtualisation, Linux, automatisation — voir ci-dessous).

Référent technique — Linux, VMware et virtualisation

À l’ INPI , j’ai accompagné en tant que référent technique toutes les installations logicielles sous Linux . J’étais aussi référent technique sur l’ensemble du périmètre VMware et, plus largement, de la virtualisation . C’est moi qui ai installé cette virtualisation à l’INPI : VMware vSphere de la 4.0 à la 6.0 , puis oVirt ( oVirt ), et plus tard les premiers environnements Kubernetes (« nuage » conteneurisé) avec RancherOS comme socle pour monter ces clusters. J’ai aussi réalisé les premiers masters Linux de l’INPI (images / installateurs de référence pour déployer le socle), ainsi que les premiers référentiels de sécurité Linux (durcissement, règles et bonnes pratiques d’exploitation). Chaque fois qu’un projet devait être installé sous Linux , j’ accompagnais systématiquement le chef de projet (cadrage, déploiement, exploitation).

Normalisation du parc Linux et gestion de l’obsolescence (RHEL, SUSE)

À mon arrivée, le système d’information comportait de nombreuses distributions Linux différentes, aux côtés de plusieurs Unix . À l’INPI , j’ai piloté la gestion de l’ obsolescence du parc Linux : récupération des anciennes installations et report sur des plateformes à niveau — en faisant évoluer des socles très anciens (par ex. RHEL 3 ) vers des versions supportables ( RHEL 5 , puis RHEL 7 selon les trajectoires). Au terme de la normalisation, le parc entreprise ne reposait plus que sur des installations SUSE Linux Enterprise Server : SUSE Linux Enterprise Server — une réussite notable au vu de l’hétérogénéité de départ. Nous avons remplacé l’ensemble des machines Unix par des systèmes Linux et migré les applications d’ Unix vers Linux , afin de ne conserver sur Unix que les bases de données Oracle .

Projet EPTOS — équipe eptosadmin (run, intégration & architecture)

Première mission : intégration de l’équipe eptosadmin du projet EPTOS ( European Patent and Trademark Office System ) — la suite logicielle de gestion portée par l’ Office européen des brevets (OEB / EPO) pour les offices membres. L’équipe ne se limitait pas au run et à la production : nous étions aussi responsables de l’ intégration et de l’ architecture — en résumé tout le volet technique , y compris l’ infrastructure : installation des serveurs sous Linux , montage en baie en salle informatique, administration de la baie SAN , câblage et raccordement réseau , etc. Pour une synthèse académique du programme EPTOS comme transfert de système de gestion des brevets depuis l’OEB : Marcuzzo Cavalheiro & Joia (2016), Public Administration & Development , DOI 10.1002/pad.1753 (étude de cas sur un office national en coopération avec l’EPO ; même famille de programme que les déploiements EPTOS). La suite reposait sur quatre applicatifs majeurs : Soprano (back-office ; tierce maintenance assurée notamment par Jouve , groupe rebaptisé Luminess ), e-OLF (dépôt en ligne), PHOENIX (gestion documentaire), et Register (registre). Développements en Java , servis via Tomcat , avec base de données MySQL ; le tout opéré sous Linux . Les premières mises en production étaient exclusivement en bare metal : la virtualisation n’était pas encore déployée sur le site. À l’arrivée de VMware ( vSphere 4 ), nous avons été parmi les premiers à migrer vers la virtualisation et à réaliser les premières conversions . Tout n’était pas encore abouti : en début de courbe, les outils de conversion P2V ne fonctionnaient pas pour tous les cas — il a fallu recourir à la création d’images disque brutes (copie depuis la machine physique) pour les réintégrer en machine virtuelle lorsque la conversion standard échouait. Puis généralisation des pratiques (vSphere 5.x, etc.). Au départ, la virtualisation ciblait d’abord le périmètre EPTOS . Pour l’ étendre à l’ensemble du système d’information , c’est notre équipe qui a porté le chantier : nous avions le plus d’ expérience sur la virtualisation. Plus précisément, EPTOS disposait d’une infrastructure dédiée : sauvegardes, bases de données et switchs propres au périmètre — fonctionnement autonome par rapport au reste du SI. Vers la fin du projet, décision de converger avec l’infrastructure centrale pour les fonctions transverses, notamment supervision et sauvegarde . L’effort de normalisation réalisé dans le cadre d’EPTOS a ensuite été réinvesti pour l’ensemble du système d’information : notamment création des bases (données et référentiels), et migration des machines obsolètes vers le nouveau socle technique . Plus tard, d’autres logiciels ont été intégrés autour de l’environnement EPTOS, notamment pour la diffusion et la valorisation des données : stack Talend couvrant entre autres ETL , ESB et MDM ( Master Data Management ).

SUSE Linux Enterprise — migrations SLES 9 → 11 (EPTOS)

À l’ INPI , nous avons géré les migrations de SLES 9 vers SLES 11 ( SUSE Linux Enterprise Server ) au fil de l’eau pour le périmètre EPTOS — planification des montées de version progressivement , sans tout basculer d’un seul coup.

Parcours d’équipe — production brevets, fusion Linux/Unix, diffusion EPTOS

D’abord rattaché uniquement à une équipe dédiée à la production du système d’information brevets , j’ai ensuite rejoint le reste de l’équipe système Linux / Unix (élargissement de mon périmètre). J’y ai réinvesti dans l’ ensemble du SI les briques nouvelles mises en place pour le projet EPTOS (socles, outillages, pratiques de normalisation).

Salle serveurs — baies, KVM Raritan IP, volumes, câblage

Nous montions nous-mêmes en baie les machines et gérions l’exploitation des serveurs en salle serveur — notamment KVM over IP Raritan ( Raritan , consoles distantes), mises à jour de firmwares , création de volumes disque côté serveurs / stockage, raccordements électriques et réseau , etc.

Disponibilité du dépôt — e-OLF, confidentialité et mises en production

L’ INPI est un organisme de dépôt : le service de dépôt doit fonctionner en permanence . J’avais la responsabilité du volet dépôt des brevets , notamment e-OLF (dépôt en ligne — périmètre EPTOS), et la mise en place ainsi que l’ exploitation de l’ environnement sécurisé pour les données soumises au secret jusqu’à leur publication éventuelle. Les mises en production étaient donc minutieusement préparées pour garder un temps de coupure aussi court que possible .

Physique vers virtuel (P2V) — VMware Converter, dd, méthodes artisanales

Passer d’une installation sur machine physique à une installation sur machine virtuelle n’a pas été de tout repos . La voie « standard » était VMware Converter (conversion P2V), mais il existait des cas où l’outil ne suffisait pas. Il a alors fallu créer des images disque brutes ( raw ) avec dd (copie secteur à secteur), puis parfois des chemins artisanaux : transfert par archives compressées et décompression sur la cible, réimport et ajustements manuels dans VMware lorsque la chaîne Converter / import direct échouait.

Ordonnancement des flux (Dollar Universe)

Les volumes de données étaient importants : les sauvegardes constituaient un sujet critique — d’où la nécessité d’une fenêtre de sauvegarde bien organisée — typiquement en fenêtre de nuit / heures creuses, avec planification fine des plages rigoureusement orchestrée avec Dollar Universe : Broadcom — Dollar Universe (workload automation). Les traitements automatisés présentaient encore beaucoup d’erreurs : j’ai dû tout corriger et fiabiliser l’ensemble des scripts shell et Python qui les supportaient.

MySQL — maintenance, sauvegardes et restaurations

Il a été nécessaire de disposer d’un savoir-faire solide sur la maintenance des bases MySQL : en particulier la capacité à sauvegarder correctement des bases importantes (volumétrie, criticité métier), et surtout à pouvoir les restaurer de manière fiable en exploitation. À l’ INPI , nous avons beaucoup étudié des sujets avancés dans le MCO MySQL : haute disponibilité , performance , sécurité et sauvegarde . Historiquement , le parc incluait aussi des bases MaxDB en complément de MySQL : MaxDB (moteur SAP, héritage de l’écosystème applicatif de l’époque).

Évolution SI — SQL actif-actif (Galera, ProxySQL) et stockage (S3, Ceph)

Plus tard dans l’ évolution du système d’information , pour des architectures plus solides et plus performantes , nous avons étudié la mise en place de SQL actif-actif : notamment des clusters MySQL Galera avec ProxySQL en couche d’accès : ProxySQL . Nous avons aussi étudié les futures solutions de stockage : stockage objet exposé via le protocole S3 , et installation de clusters Ceph .

Conteneurs et orchestration (Docker, Kubernetes, Rancher)

Nous avons évidemment commencé à migrer et à déployer des applications sous conteneurs avec Docker , et à étudier l’ orchestration avec Kubernetes ; la première approche est passée par Rancher : Rancher .

Intégration continue — Jenkins, Git, Ansible

Nous avons aussi mis en place des solutions d’intégration continue — ou du moins les socles pour les porter : installation de Jenkins ( Jenkins ) branché sur Git , et les premiers playbooks Ansible .

Automatisation et industrialisation (Go, JavaScript, React)

Sur les volets automatisation et industrialisation , j’ai réalisé des développements en Go , en JavaScript et avec le framework React : React .

Supervision et alertes sur les journaux (Nagios, Centreon, Prometheus / Grafana, Graylog, Elastic)

Le socle de supervision était d’abord Nagios . Nous avons ensuite migré vers Centreon , puis, plus tard, vers une stack Prometheus et Grafana — en complément de Centreon (cohabitation et périmètres selon les besoins). Nous avons aussi exploré les alertes basées sur les logs avec Graylog : Graylog — gestion centralisée des journaux et corrélation pour l’exploitation. La création de tableaux de bord avec Grafana a permis de compléter les tableaux de bord techniques par un tableau de bord technico-fonctionnel de production . À l’ INPI , nous avons aussi utilisé l’écosystème Elastic autour d’ Elasticsearch pour centraliser les logs applicatifs , avec Logstash (pipelines) et les modules Filebeat pour la collecte : Elastic Stack .

Agents et métrologie Java — Tomcat, JMX

Au niveau des agents et de l’exposition des métriques applicatives : une grande partie du parc était en Java servie par Apache Tomcat (dont Tomcat 4 sur une partie du périmètre à l’époque). Nous avons utilisé le protocole JMX ( Java Management Extensions ) pour superviser et instrumenter les JVM et les composants serveur : Oracle — tutoriel JMX .

Proactivité — jobs de vérification Selenium (production)

Pour renforcer la proactivité sur la résolution d’incidents , nous avons mis en place des jobs de vérification avec Selenium : Selenium , afin de tester automatiquement les services en production (parcours critiques / contrôles de bout en bout).

Sécurité — Cyberwatch

À l’INPI , dans le cadre du CODIR informatique , j’ai lancé le projet d’installation de Cyberwatch pour améliorer la sécurité des installations Linux : gestion des vulnérabilités et contrôle de conformité sur le système d’information. L’établissement a été parmi les premiers à déployer la plateforme. J’ai accompagné ce déploiement pour la conformité vis-à-vis des référentiels de sécurité (cartographie des exigences, preuves et suivi des écarts).

Infrastructure, salles informatiques et PRI / PRA (VMware Site Recovery)

Au niveau de l’ infrastructure , nous avons migré de salles informatiques à trois reprises pour toute la production . Après ces chantiers, la sécurité et la continuité d’exploitation se sont largement appuyées sur la virtualisation VMware , en particulier sur la capacité à déplacer ou répliquer les machines virtuelles d’un datacenter à un autre via VMware Site Recovery Manager : VMware — Site Recovery Manager (PRA / réplication inter-sites). C’est moi qui ai mis en place le dispositif de plan de reprise informatique ( PRI ) et le volet PRA associé, avec VMware Site Recovery Manager : mise à jour du tableau de production (inventaire et criticité), définition de l’ ordre d’importance des systèmes pour les bascules, et arbitrage sur ce qui devait être intégré pleinement au PRA (réplication, orchestration avec Site Recovery) ou laissé hors périmètre .

SAN — hôtes physiques et accès (iSCSI, Fibre Channel, NFS)

À l’ INPI , j’ai dû piloter le lien entre les hôtes physiques et le SAN . Plusieurs technologies ont été mises en œuvre : iSCSI sur câble Ethernet , Fibre Channel , et NFS pour les usages adaptés au partage de fichiers sur le réseau. J’ai aussi eu l’occasion d’exploiter des SAN HP , notamment des baies HP 3PAR : HPE 3PAR . Pour le plan de reprise informatique ( PRI ) avec VMware Site Recovery Manager , il était indispensable que le stockage soit compatible avec la réplication et l’orchestration inter-sites VMware.

Détail

MCO de larges parcs Linux (+500 VMs en phase mature) : CentOS, Red Hat, SUSE ; supervision : évolution Nagios → Centreon → Prometheus/Grafana (avec Centreon en complément) ; alerting logs (Graylog, Elasticsearch / Logstash / Filebeat) ; intégration Apache, Tomcat, PHP, MySQL/Galera, MaxDB, Oracle ; Dollar Universe ; automatisation (bash, Python, Go, Java, PHP, Selenium, AutoIt, Node, React) ; stockage NFS, SAN HP 3PAR, Ceph, NetApp, Samba ; support niveau 2.

Projets

Virtualisation VMware vSphere 5.5, PRA (VMware Site Recovery Manager, réplication inter-datacenters), évolution stockage (Ceph, Cassandra, S3), Puppet et Ansible, réflexion cloud / conteneurs / OpenStack, trois migrations de salles informatiques pour la production.

Synthèse du périmètre — Linux, mise en production, scripts

Mon travail à l’ INPI m’a permis d’intervenir sur un large périmètre : installation et maintenance des machines physiques ; hébergement via la virtualisation ; infrastructure de stockage ; puis installation et MCO des services en production — complété par les choix et évolutions du socle Linux , les mises en production , les retours arrière et les scripts d’exploitation pour le run (dans un SI où Unix et autres environnements coexistaient encore). Sur la chronologie , nous avions déjà réussi l’ensemble de l’ automatisation et de la normalisation du périmètre avant l’arrivée d’ Ansible et de Puppet , qui sont venus ensuite compléter le dispositif. Mon expérience à l’ INPI m’a permis de consolider une expérience validée et profonde de la production informatique sur des environnements critiques . J’y ai porté une attention particulière aux bonnes pratiques pour conduire les mises en production : préparation poussée et plans de retour arrière systématiques.

Contexte (chronologie)

Agence publique, DSI ~40 agents, +500 postes Windows. Production applicative Java/PHP, Apache, MySQL ; administration SUSE, Red Hat ; +20 hôtes ESX (HP DL560) ; Dollar Universe, scripts Bash/Python ; 3 baies SAN HP 3PAR (~180 To) ; deux salles (production et développement). Assistance aux projets technico-fonctionnels, migration vers VMware, PRA, normalisation de l'infrastructure.

Groupe Sungard — Global Portfolio 3 / Asset Management (Neoxam) — Consultant support & intégrateur senior

Points saillants :

Détail

Après l’expérience à l’UCAD, mission chez Sungard (une partie de l’offre GP3 existe aujourd’hui sous la marque Neoxam) : produit phare Global Portfolio 3 (GP3), solution de gestion d’actifs (asset management) pour banques et assureurs. Part très importante du marché : en France, la quasi-totalité des banques et assureurs actifs en asset management utilisaient la solution ; clients aussi à l’étranger (États-Unis, Allemagne, perspective internationale incluant la Chine à l’époque). Société d’environ 500 salariés, déploiements Unix (HP, AIX, Solaris, Linux…). Mon travail chez Sungard m’a appris à intervenir sur des environnements critiques dans un contexte à forte pression (exigence des acteurs financiers, délais serrés, enjeux de production).

Références clients (exemples)

Parmi les clients ou périmètres côtoyés chez Sungard, notamment : Société Générale, Crédit Agricole, Banque Populaire, Caisse des dépôts, State Street, Allianz, MMA, CNP Assurances, ainsi que CACEIS, Natixis, Covéa, CM-CIC (Crédit Mutuel / CIC) et d’autres grands comptes asset management — liste non exhaustive, selon missions et filiales.

Projets transverses, filiales & messagerie (JMS)

Référent sur les projets transverses : Sungard était un groupe possédant plusieurs filiales, dont une SSII — Décalog (services / intégration). Ces projets mobilisaient plusieurs entités pour faire circuler des informations entre logiciels métiers, en s’appuyant notamment sur des bus de messagerie et des mécanismes de type JMS (Java Message Service).

International & mobilité

Collaboration avec des correspondants allemands et déplacement professionnel en Allemagne — premier déplacement à l’étranger dans ce cadre. La société ambitionnait aussi de se développer sur des marchés internationaux, en particulier la Chine. Aux États-Unis, périmètres incluant notamment State Street (banque / services financiers).

Produit : héritage VMS, portage Unix, Java & Tomcat

La base historique reposait sur OpenVMS . Pour poursuivre la vente sur Unix, l’éditeur avait mis en place un runtime / socle d’exécution permettant d’héberger code et composants issus du monde VMS sur Unix. Développement surtout sous Linux , puis compilation et livraison vers les plateformes clients HP-UX , Solaris , AIX . Les services étaient exposés via Apache Tomcat ; une couche Java reprenait les anciens écrans, frames et masques « verts » VMS pour une interface Java. Pile effective : Java , Python , avec prolongement du patrimoine VMS .

Intégration, support applicatif & Atlassian

Première expérience structurante en intégration logicielle et support applicatif : montée en compétence sur la résolution d’incidents applicatifs en environnement client critique. Avant Jira, le suivi des anomalies et demandes s’appuyait sur MantisBT (bug tracker open source). Ensuite, passage à la suite Atlassian en premières versions — Jira, Confluence et Bamboo — pour piloter le cycle de vie du produit, la documentation et les recettes.

SVN, Bamboo & qualification plateformes

À l’époque, Git n’était pas encore l’outil de référence dans nos chaînes — le source était versionné avec Subversion (SVN). L’équipe était parmi les premières à industrialiser de l’intégration continue via Bamboo, en particulier pour enchaîner la recette qualité. Les builds étaient qualifiés sur des plateformes très précises — Red Hat Enterprise Linux, IBM AIX, Oracle Solaris — avec des versions majeures et mineures du système strictement cadrées.

Performance applicative

Périmètre personnel sur les sujets de performance du logiciel : lorsque le client constatait des lenteurs ou que « le logiciel était trop lent », j’étais chargé du diagnostic et du traitement de ces dossiers. J’avais défini une méthode d’analyse structurée pour investiguer (reproduction, mesures, identification des goulots d’étranglement, pistes de correction côté applicatif et plateforme).

Diagnostics difficiles — file descriptors, proxy HTTP (réseau)

Chez Sungard , il a fallu traiter des problèmes difficiles à détecter et à localiser — par exemple des incidents liés aux file descriptors sur des composants fortement sollicités , ou une modification du flux HTTP par un proxy ajouté par une équipe réseau dans un environnement critique , avec peu d’indices applicatifs visibles immédiatement.

Outillage d’analyse & automatisation

Pour outiller les analyses (performance et autres investigations), scripts en Python et en shell ; développement de tableaux de bord avec Django. Automatisation de traitements sur documents en VBA (Visual Basic for Applications), puis passage à VB.NET pour fiabiliser et faire évoluer ces chaînes.

Support & contraintes d’exploitation

Poste très exigeant : équipe support sous forte pression, sans accès systématique à la production — il fallait donc cerner un problème au mieux à partir d’informations partielles pour orienter et dépanner les équipes d’exploitation. Rythme soutenu. Les intégrations et livraisons vers la production restaient particulièrement délicates. Nous avons dû mettre en place des méthodes d’analyse d’incidents : communication avec le client , analyse des journaux , vérifications minutieuses — nous sommes ainsi devenus de véritables experts support .

Missions

Intégration des composants sur Unix ; support et TMA auprès des banques et assurances ; outils de support (VB .NET, Python) ; participation aux projets inter-filiales et aux nouvelles versions.

UCAD — Union centrale des arts décoratifs (musée) — Ingénieur informatique

Points saillants :

Détail

Institution muséale, +300 salariés. Parc mixte : postes de travail Windows et postes Linux ; serveurs Linux (production Debian, etc.) et stack Windows/Novell. Pas encore d’Active Directory : l’institution reposait sur Novell, dont l’annuaire (NDS / eDirectory) centralisait utilisateurs et ressources — l’équivalent fonctionnel antérieur à l’écosystème AD dans ce type d’infrastructure. MCO serveurs Windows et Novell, Solaris ; support bureautique niveau 1 et production niveau 2.

Contexte — recyclage Windows → Linux

Pour revenir en arrière à l’époque où j’étais à l’ UCAD , l’un des points les plus remarquables était le recyclage des anciennes machines abandonnées ou jugées obsolètes sous Windows : les nouvelles générations de Windows exigent toujours plus de puissance, alors que des installations sous Linux permettaient de réutiliser le matériel existant et de prolonger le service à moindre frais . Expérience marquante dans l’ensemble du mandat : remettre à niveau un parc longtemps délaissé avec très peu de moyens ; les alternatives open source ont aussi permis de remplacer des logiciels propriétaires à coût de licence quasi nul, tout en évitant de mettre au rebut du matériel encore exploitable.

Site distant & portables recyclés

Avec des budgets serrés, il fallait optimiser tout le parc et recycler au maximum. Les portables étaient encore très chers ; peu de collaborateurs en avaient un — le standard restait la tour sous le bureau. Pour équiper un site distant et permettre aux équipes de réaliser des inventaires dans les réserves du musée, nous avons récupéré d’anciens ordinateurs portables, à peine assez puissants pour faire tourner Linux avec une stack graphique légère (X11), puis le client Citrix pour accéder aux applications métier en mode bureau distant. L’association Linux + Citrix permettait de donner au personnel une expérience de poste de travail exploitable avec très peu de ressources locales.

Debian, noyau & pilotes (matériel recyclé)

Pour arriver à ce résultat (fait tourner des machines « bout de course » sous Linux), il a fallu maîtriser l’ensemble des composantes du système Linux et, au premier chef, la compilation du noyau : itérations successives — compiler encore et encore jusqu’à obtenir une installation suffisante (stable et utilisable) sur le matériel cible. Un effort considérable est aussi allé à la compatibilité matérielle : le support n’était pas encore homogène comme aujourd’hui, peu de pilotes vraiment génériques dans les noyaux standards ; traque de pilotes adaptés, recompilation pour du matériel très spécifique, et recompilation pour alléger le noyau (RAM, CPU, disque) en retirant les modules inutiles. Base essentiellement Debian . À l’époque, je m’étais beaucoup appuyé sur la documentation et la formation qu’ Alexis Delattre mettait librement à disposition sur Internet : Formation Linux (PDF) — linux.bouzzi.com .

Affichage graphique — interfaces et configurations optimisées

À l’ UCAD , j’ai aussi dû étudier les interfaces graphiques — ou du moins toute la chaîne de composants nécessaire à l’ affichage graphique sous Linux — puis choisir et configurer les combinaisons les plus optimisées possibles pour qu’elles restent tenables sur du matériel peu puissant (parc recyclé), tout en restant compatibles avec l’usage bureautique.

Contrôle et bureau à distance (VNC, RDP, NX Server)

J’ai aussi dû étudier les solutions de contrôle à distance et de bureau à distance : VNC , RDP (Remote Desktop Protocol) et NX Server / NoMachine (NX) — pour l’assistance, l’accès aux postes distants et l’exploitation d’un parc Windows / Linux hétérogène.

Compilation depuis les sources (Apache, SSL, modules)

Il n’était pas rare de devoir compiler nous-mêmes des logiciels plutôt que de nous limiter aux paquets fournis : pour plusieurs briques, le packaging n’était pas encore assez abouti. C’était souvent le cas pour les serveurs Apache, les bibliothèques SSL/TLS et les différents modules Apache associés (mod_ssl, etc.).

Proxy Squid et miroir local de paquets (Apache)

À l’ UCAD , j’avais installé un serveur proxy Squid : Squid — pour sécuriser et fluidifier les accès Internet lors des installations de logiciels . Nous utilisions en parallèle un miroir local des paquets d’installation, exposé sous Apache ( HTTP Server ), afin de limiter la bande passante sortante et d’accélérer les déploiements sur le parc.

Sauvegardes

La sauvegarde sur bande était assurée par Bacula (pools, jobs, lecteurs…). La sauvegarde sur disque reposait sur BackupPC — solution libre de sauvegardes incrémentelles vers stockage disque, complémentaire à la partie magnétique.

Messagerie

Le socle messagerie : Postfix (MTA) avec accès IMAP pour les clients lourds, et webmail via SquirrelMail pour l’accès dans le navigateur.

Périmètre réseau (Linux & iptables)

Il n’y avait pas encore d’appliance pare-feu dédiée : une machine Linux tenait lieu de pare-feu ; la configuration passait par iptables pour filtrer et piloter l’ensemble du trafic réseau du musée.

DNS (BIND)

Le service DNS était assuré par BIND ( Berkeley Internet Name Domain ), tel que maintenu par l’ISC.

Wi-Fi : Linksys WRT54G & DD-WRT

Pour l’accès sans fil, utilisation de routeurs Linksys WRT54G . Pour maximiser la capacité d’exploitation et simplifier la maintenance, le firmware constructeur a été remplacé par le projet libre DD-WRT .

Sécurité, recyclage : LTSP, PXE & postes diskless

Pour les postes légers , je m’étais notamment appuyé sur LTSP — Linux Terminal Server Project — qui permet de faire démarrer les clients sur le LAN depuis une installation modèle sur le serveur (image/chroot), avec iPXE, DHCP/TFTP et root en squashfs/NFS : entretenir des dizaines de stations diskless comme un seul poste. J’ai aussi étudié et mis en place le boot à distance via PXE et des déploiements diskless (sans disque dur local) : on manquait souvent de disques sur le matériel récupéré, et ce modèle permettait de n’avoir côté poste que de simples terminaux — système et données servis depuis l’infrastructure centrale. Chaîne PXE opérationnelle (menu de boot, profils par adresse MAC , redéploiement à distance) pour sécuriser la remise en service du parc et prolonger le recyclage ; montages d’arborescences via NFS pour les postes diskless.

Matériel, vidéo et kiosques

Le parc n’était pas très puissant : les machines les plus récentes étaient des Intel Pentium 4 , à peine suffisantes pour la lecture vidéo. On travaillait surtout en MPEG-1 et MPEG-2 ; le H.264 / MP4 n’était pas encore la norme sur ce type de poste. VideoLAN existait déjà, mais n’était pas le plus léger sur ce matériel. Le lecteur le plus frugal et optimisé pour nos usages était MPlayer . Dans les salles du musée, kiosques sur mesure : postes Linux lançant un navigateur (affichage plein écran), avec verrouillage des touches de fonction et des raccourcis pour empêcher l’utilisateur de sortir du parcours prévu. Postes dédiés à la lecture vidéo et autres dédiés à l’affichage de sites intranet .

Gestion des collections (Mobidoc)

Pour la gestion des œuvres et du fonds muséal, le logiciel métier était Micro Musée, édité par la société Mobidoc ; à l’époque, aucun équivalent open source ne permettait de couvrir le besoin de façon satisfaisante.

Déploiement & migrations

Les déploiements couvraient le poste Windows (réinstallation massive sous délais serrés) et la partie Linux du parc (postes et serveurs). Pour Windows, l’habitude était l’image disque avec Symantec Ghost et des masters sur l’infrastructure Novell — peu souple. Nous avons expérimenté Unattended pour des installations automatisées et paramétrables, en complément des méthodes rigides par clone. Première expérience marquante en automatisation : les chaînes Unattended reposaient sur de nombreux scripts mélangeant shell , Perl et AutoIt — langage dédié au pilotage de l’interface Windows (fenêtres, frappes clavier, mouvements de souris) pour fiabiliser les installations, en parallèle de la préparation de paquets MSI et de déploiements silencieux. Côté bureautique et fichiers : migration vers Samba pour le partage (Windows XP / NT4 / 2000), cohabitant avec l’annuaire Novell ; rationalisation des lecteurs CD. Les débuts de GLPI et de l’ OCS Inventory (serveur) sur le site : réalisation d’un plugin pour alimenter GLPI à partir des remontées OCS, ce qui a permis d’obtenir un inventaire complet et exploitable de tout le parc. À l’époque, peu d’institutions avaient encore généralisé un système de tickets pour les incidents ; il a été décidé d’adopter Request Tracker (RT) , logiciel libre de gestion d’incidents et de suivi d’actions.

Documentation

La documentation technique et procédurale a été rédigée en LaTeX ( LaTeX Project ), pour des livrables structurés, révisables et export PDF.

DGC — centre de formation (même groupe que l’EPSI) — Job étudiant — support informatique

Points saillants :

Support et parc étudiants

Pendant les études à l’EPSI , job étudiant au DGC , centre de formation du même groupe que l’école. Support informatique et gestion du parc des postes dédiés aux étudiants : Windows NT 4 , puis Windows 2000 . Création d’ images avec Ghost (Symantec / Norton Ghost) et déploiement en multicast pour re-imager régulièrement les machines ; gestion des profils Windows (nombreux incidents à traiter) ; droits et accès pour les comptes étudiants ; installation des antivirus . Prise en charge aussi de logiciels de formation / e-learning déployés sur le site. L’occasion aussi de mettre en place Linux sur du matériel recyclé pour offrir des postes supplémentaires au service des usages du site.

Compétences techniques (synthèse)

Synthèse alignée sur le parcours : exploitation Linux/Unix sur service public, finance, presse et énergie ; virtualisation (VMware à Proxmox), clouds privés OpenStack/NUBO, Kubernetes & Helm (Onyxia, conformité sectorielle publique), HPC Slurm/Apptainer ; automatisation Ansible, Terraform, GitLab, Salt ; durcissement ANSSI, MCS et Cyberwatch ; agents IA et chaînes documentaires en production.

Systèmes & réseau (niveau 3/3)

Linux Red Hat/CentOS, Debian/Ubuntu, SUSE en production (niveau 3) ; intégration Active Directory / LDAP / SSSD (Radio France, Naarea) ; boot PXE / Preseed, LTSP pour postes légers (UCAD) ; DNS BIND, pare-feu iptables ; compilation et allègement de noyau (parc recyclé). Unix AIX, Solaris, HP-UX (migrations INPI, Sungard GP3). Windows et Samba en contextes mixtes (TPE, musée).

Supervision & observabilité (niveau 3/3)

Centreon, Grafana, Prometheus ; trajectoire Nagios → Centreon → Prometheus (INPI, Naarea). Graylog, Elastic Stack pour journaux et corrélation. Métrologie JMX (Tomcat/Java). Tableaux de bord technico-fonctionnels d’exploitation.

Stockage, SAN & PRA (niveau 3/3)

SAN HP 3PAR, iSCSI, Fibre Channel, NFS ; Ceph, stockage objet S3 / MinIO ; MySQL Galera + ProxySQL. PRA / PRI VMware Site Recovery Manager, réplication inter-datacenters et migrations de salles (INPI). Sauvegardes : Bacula, BackupPC, NetBackup, Veeam.

Virtualisation, cloud & Kubernetes (niveau 3/3)

VMware vSphere (4.0→6.0), oVirt / KVM (migration et exploitation, INPI), Proxmox, Hyper-V ; OpenStack (NUBO, ministère). Kubernetes & Helm (Onyxia / Nubonyxia). Docker ; Apptainer ; premiers clusters via Rancher / RancherOS (INPI). PRA inter-DC avec VMware SRM.

Bases de données & middleware (niveau 2/3)

MySQL / MariaDB, PostgreSQL, Oracle (exploitation), MongoDB, MaxDB. Stacks Tomcat / Java, Apache NiFi, CMDBuild (RADAR DGFIP). Intégrations PHP, Node, Heurist (SHS BnF). Ext JS (IHM métier).

Automatisation & CI/CD (niveau 3/3)

Ansible (Tower), Terraform (VM OpenStack), Puppet, SaltStack ; Git, Jenkins, GitLab CI, chaînes release Bercy/BnF/INPI ; Rundeck → Ansible Tower (Radio France). Dollar Universe (ordonnancement). Bamboo / SVN (époque Sungard).

Développement, scripting & IA (niveau 3/3)

Bash/shell, Python, JavaScript/React, Go, Ext JS ; Django, PHP, VBA/AutoIt. Projets récents : FastAPI, RAG, Whisper. En production : agents n8n, API Claude, inférence locale Ollama / Mistral (TPE), scripts d’exploitation et Selenium (checks prod).

HPC & sécurité opérationnelle (niveau 2/3)

Slurm, InfiniBand, Apptainer (MPI, charges scientifiques), plateformes Lenovo ; zones réseau protégées, LDAP dédié (Naarea). Masters Linux durcis selon guides ANSSI, MCS. Cyberwatch (lancement INPI, conseil Radio France).

Formation

Formation — informations complémentaires

Langues

Centres d’intérêt

Soft skills

Autonomie & sens du résultat

Consultant indépendant, j’interviens en autonomie sur des sujets pointus, je sais cadrer mes priorités et livrer dans des contextes exigeants.

Pédagogie & transmission

Référent technique transverse : j’aime accompagner les chefs de projet, expliquer le pourquoi, et laisser derrière moi des équipes plus solides qu’à mon arrivée.

Diagnostic & investigation

À l’aise dans les situations bloquées que d’autres n’ont pas résolues — comme l’épisode SSSD à Radio France où trois ingénieurs s’étaient succédé avant que je débloque le sujet.

Rigueur & sens du risque

Mises en production minutieusement préparées, plans de retour arrière systématiques. Je sais que dans un organisme de dépôt ou de service public, l’indisponibilité a un coût.

Curiosité & adaptabilité

De la compilation de noyau Linux dans les années 2000 à l’inférence locale Mistral en 2026 — j’ai traversé toutes les ruptures techniques sans rester figé.

Esprit d’équipe transverse

Le poste B2I à la BnF — la « colle » entre dev et prod — m’a appris à écouter, à arbitrer, à ne jamais opposer études et exploitation.

IA, agents et outils (usage professionnel)

L’IA n’est pas une mode pour moi : depuis l’arrivée des LLM accessibles, j’en ai fait à la fois un compagnon de travail quotidien et un terrain d’expérimentation. Je m’en sers pour coder, concevoir et raisonner — et je conçois des agents qui tournent en production, y compris en inférence locale pour préserver la souveraineté des données.

Codage & raisonnement augmentés (au quotidien)

Agents & inférence (en production)

Hackathon & RAG (expérimentation)

Projets ou expériences IA cités

Veille & curiosités tech

Sélection de projets que je trouve marquants pour comprendre où va l’écosystème système, virtualisation et navigateur. Bonne illustration des frontières actuelles entre Linux, low-level et WebAssembly.

Linux/Wasm (Noyau Linux · WebAssembly)

Le noyau Linux qui démarre directement dans le navigateur via WebAssembly : BusyBox + musl, terminal Xterm.js. Une preuve de concept passionnante pour qui s’intéresse au scheduling, aux primitives système et aux limites du sandbox JS moderne (pas de MMU, suspension de tâches émulée via Web Workers, etc.).

Lien : https://joelseverin.github.io/linux-wasm/

DOS Wasm X (Émulation · WebAssembly)

Émulateur DOS / Windows 95-98 dans le navigateur, basé sur DOSBox-X compilé en WebAssembly via Emscripten. Disque dur sauvegardable côté navigateur, gestion ISO/IMG/CD, support gamepad — démo très convaincante de ce que permet aujourd’hui un Wasm avec exceptions et asyncify.

Lien : https://github.com/nbarkhina/DosWasmX

Projets personnels et initiatives

En parallèle des missions :

Portail collections d’œuvres & IA (2026)

En 2026 , pilotage de la création d’un portail web pour la gestion de collections d’œuvres d’art, avec assistance par intelligence artificielle .

Hackathon IA — chatbot vocal & Code législatif (Fév. 2025)

En février 2025 , participation à un hackathon dédié à l’intelligence artificielle : notre équipe a développé un chatbot vocal capable d’extraire et de restituer rapidement des informations issues du Code législatif français . Objectif : simplifier l’accès au droit grâce à la reconnaissance et à la synthèse vocales. Sources légales — les textes de référence provenaient de git.tricoteuses.fr , constituant une base législative complète. Technologies — Whisper (conversion voix → texte), LightRAG ( RAG contextualisé sur GitHub ), scripts shell pour nettoyer et formater les jeux de données, Python & FastAPI pour exposer les services web, préparation des datasets sur poste de développement (Mac mini, 24 Go RAM). Infrastructure — déploiement des LLM sur le cluster Kubernetes GPU de SPESYS Services , avec accès GPU pour des performances adaptées au temps court du hackathon. Mon rôle — préparation des datasets : extraction, structuration et normalisation des textes législatifs ; création d’ API primitives Python/FastAPI reliant la couche de reconnaissance vocale, le module RAG et la restitution. Collaboration — hackathon sur deux jours , avec échanges avec la DINUM , l’équipe Bercy HUB autour du projet Onyxia (Nubonyxia) , et d’autres acteurs publics (Ministère de l’Économie, Ministère de la Justice, etc.). Remerciements — Stéphane Baisse et les équipes SPESYS ( Thomas Williot , Gérald Moreno ) pour l’accès à l’infra et l’accompagnement. Innovation — accessibilité (questions à voix haute), rapidité grâce au GPU, impact social pour professionnels et grand public.

Portail logiciel — data science & IA (Depuis 2023)

Depuis 2023 , développement d’un portail logiciel à destination des data scientists , orienté data science et IA .

Institut d’art — Échirolles (bénévolat) (2022)

En 2022 , participation bénévole à la création d’un institut d’art à Échirolles , en tant qu’ expert informatique (conseil et mise en place du socle numérique).

Sites vitrine WordPress (2020)

En 2020 , création de sites internet sous WordPress , avec Elementor , pour des petits entrepreneurs .

Le Signe — gestion de collections (Chaumont) (Vers 2019)

Le Signe — logiciel de gestion de collections d’œuvres d’art : Groovy (backend), JavaScript et React (frontend). Expérimenté et développé vers 2019 dans le cadre du récolement des collections à Le Signe , centre national du graphisme à Chaumont .

Correction automatique de QCM — AMC (2013)

En 2013 , conception d’une solution de correction automatique de QCM bâtie sur le logiciel libre Auto Multiple Choice (AMC) : génération de questionnaires uniques à chaque session d’examen (questions et réponses dans un ordre différent d’un exemplaire à l’autre), code-barres unique par copie papier imprimée, puis numérisation , reconnaissance automatique des réponses (OMR) et correction automatique .

Document généré automatiquement depuis les données structurées du site (build). Destiné aux ATS et aux assistants IA des recruteurs : format texte, sections explicites, métadonnées structurées dans un bloc YAML en tête.