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: en
full_name: "Oulom Souvannavong"
role_title: "Tech Lead DevOps integration & sovereign cloud — Linux, K8s, AI"
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 DevOps integration & sovereign cloud — Linux, K8s, AI"

Oulom Souvannavong

Role: Tech Lead DevOps integration & sovereign cloud — Linux, K8s, AI

I design and harden your critical platforms — from bare metal to Kubernetes clusters, from sovereign cloud to AI agents in production.

Professional summary

More than 20 years running critical Linux production, blending DevOps integration (Ansible, Terraform, GitLab CI), virtualization and sovereign clouds (VMware, OpenStack/NUBO, Kubernetes/Onyxia), and now AI in production. Cross-functional technical reference at the French Ministry of Finance, Radio France, the National Library of France, INPI.

French citizen — based in Paris. Technical reference on critical environments: bridge between production and development, delivery automation, security and large-scale operations (hundreds of VMs, monitoring, storage).

Human profile

A curious, calm and committed engineer: for twenty years I have worked at the heart of the critical information systems of major French organizations — Ministry of Finance, Radio France, BnF, INPI — keeping the desire to learn and experiment. I love being the meeting point between production and development teams, sharing what I have understood, and making systems more reliable and more peaceful for those who run them.

Contact

Key indicators (stats)

Reference organisations (trust / references)

Value arguments (why this profile)

Critical production with zero downtime

Carefully prepared go-lives, systematic rollback plans, cross-DC DRP. Proven service continuity in deposit and public service organizations.

Full stack: from hardware to cloud

From rack mounting and Fibre Channel SAN to Kubernetes clusters and S3 / Ceph storage. End-to-end visibility few profiles can claim.

Integration & automation

Ansible, Terraform, Jenkins, GitLab CI, Helm. I turn fragile chains into reliable deliveries — and I document what I do.

Cross-functional technical reference

I support project managers, unblock teams on Linux/AD, virtualization and ANSSI security, and pass on my know-how.

AI as broadened operational expertise

LLMs integrated into my tooling: Cursor, n8n + Claude agents, local Ollama / Mistral inference, RAG. Concretely: AI agents in production at a small business, legal RAG delivered at a hackathon, and this portfolio as a data-driven build.

Professional experience

Ministry of Finance — Bercy HUB & DGFIP — Independent Linux expert consultant

Key highlights:

Two entities

Assignments with at least two entities of the ministry: Bercy HUB for the Nubonyxia project, then the DGFIP (taxes) for the RADAR project.

Bercy HUB — Nubonyxia project

The Nubonyxia project relies on providing the Onyxia software — born at Insee with contributions from Bercy teams. Onyxia installs on a Kubernetes cluster and deploys workloads as pods via Helm charts . The offer rides on the chosen hosting base ( Bercy HUB / NUBO ), hence the project name ( Nubo / Onyxia ). Role: contributing to the operations of an installation already in production, plus rolling out additional services . In practice: adapting Helm charts so they can be launched from the Onyxia portal — turning packages into the Onyxia flavor to comply with the catalog model and compliance requirements. An automation chain was already in place to move deliverables from development through to user availability . I was responsible in particular for the healthy operation of this continuous integration chain , with many topics to handle around authentication and security . One major challenge: mapping all components and flows to make them visible and controllable — the perimeter was hard to scope while authentication raised many issues and continuous integration chains remained only mildly stable .

DGFIP — RADAR project

RADAR project goal : provide a framework that aggregates several inventory sources in order to map the versions of the structuring components of the information system (visibility into the fleet and into what is actually running in production). Role of application DevOps integrator on this perimeter: Ansible , Nexus , Jenkins , GitLab tool chain, with services including CMDBUILD and Apache NiFi , complemented by Tomcat , PostgreSQL , on a Linux base on NUBO / OpenStack . Deployment relies in particular on Jenkins and Ansible . On arrival , the platform showed numerous malfunctions . My role was mostly to stabilise what had already been delivered — including writing and maintaining Ansible and Terraform code for creating virtual machines on OpenStack — then to drive the version upgrade of all RADAR components — including the move of CMDBUILD to its latest version (alignment with the integration chain and dependencies). In the absence of a dedicated JavaScript developer , I also took part in maintaining and evolving the RADAR UI , built with the Ext JS framework.

Enedis, Fayat IT — Support assignments

Key highlights:

Enedis — Jan 2025

Designed a test bench for real-time software : verified the chaining between Linux and the real-time application .

Fayat IT — Jan 2024

Worked on the migration of a piece of software from the Linux environment to Windows .

RYC — business support — IT support (family-run business)

Key highlights:

Detail

Since 2005 , supporting RYC , a business assistance structure (advice on administration , pre-accounting notably with Sage Coala ). IT and office support: Windows workstations on the client side; Linux servers for infrastructure, with folder sharing via Samba — the Coala software running on the Windows workstations .

Accounting flow automation

For about five years , strong rise in automation : automatic extraction of bank statements and semi-automatic integration into the accounting software up to the posting of accounting entries . Very recently: automatic extraction of invoices and attachments to generate accounting entries , also relying on bank reconciliation .

AI, agents and orchestration (very recent)

The arrival of AI opened up new possibilities : designing AI agents , using n8n for document sorting and processing , calling APIs — notably Claude (Anthropic) — for the recognition and processing of documents, extending the existing automation. First experience with local inference of two models via Ollama (running on workstation / server), based on Mistral LLMs.

Naarea — energy (small modular reactors) — HPC platform operations

Key highlights:

Context

Startup in the small modular nuclear reactor (SMR) sector; mostly Windows-based information system, with a decision to invest in a HPC platform for simulation and scientific computing.

Protected zone — directory, auth and mail

The entire Linux fleet sat in a protected network zone . Dedicated infrastructures were therefore needed within this perimeter: an LDAP directory, a zone-specific authentication mechanism, and an SMTP relay for the mail of the affected services.

Linux master — ANSSI recommendations

At Naarea , designed a Linux master image to deploy a homogeneous and durable base: built on my experience and aligned with the guides and recommendations of the ANSSI (hardening, best practices).

Lenovo platform — Slurm cluster

Lenovo infrastructure: 10 compute nodes , 4 development machines , 3 Proxmox machines hosting VMs. NAS with NFS shares for the data used by the Slurm cluster. InfiniBand network. Configuration of everything with Salt (SaltStack). Observability and operations: Grafana, Prometheus, Centreon; OpenMP, MPI, Python, Bash; Helm where needed.

Mission — Slurm, Proxmox and Linux support

Operations of the Slurm cluster and the Proxmox infrastructure (virtualization, hosting of virtual machines). Multi-hat role on every Linux need: integration of compute codes with scientific libraries (MPI, HPC software stack); continuous integration chains with GitLab ; containers — starting with Docker , then moving to Apptainer (Singularity) for HPC-compatible workloads.

Radio France — Linux expert — infrastructure project

Key highlights:

OnAir project

Hired as part of the OnAir project: migration of part of the radio business information system to a Linux software base, while the legacy until then was essentially Windows-based.

Linux, Active Directory and SSSD

Before my arrival, three Linux engineers had taken turns trying to unblock the situation. Critical issue: authentication and joining new Linux servers to the Microsoft network (Active Directory), through SSSD. Observed behaviour: significant slowdowns or no response — and no team could pin down the cause. Diagnosis and fixes on the Linux / AD (SSSD) integration chain that resolved these blocking incidents.

Mission — Linux expertise

Hired as a Linux expert to support the infrastructure project team on Linux topics — including the creation of a Linux master (Debian/Ubuntu) in an AD domain (Preseed/PXE), installation hardening, and contribution to level 3 support. Expert assistance to Linux application projects; microservices; Bash/Ansible automation. Azure and Kubernetes training.

Tech stack — VMware, PXE, Ansible

The whole perimeter was hosted on VMware . Development environments ran on machines booted via PXE (network boot). For customisation and deployment: Ansible playbooks and roles , with Rundeck then Ansible Tower (evolution of the orchestration / automation chain).

Linux master — MCO, MCS and ANSSI

At Radio France , beyond the technical specifications alone for the creation of the Linux master , I was able to invest time on a long-term framing: for MCO (operational maintenance), drawing on my professional experience in operations; for MCS (security maintenance), inspired by the ANSSI framework .

Advisory — Cyberwatch

Reusing experience gained at INPI on Cyberwatch , I advised Radio France on the platform installation (vulnerabilities, compliance) for Linux environments .

National Library of France (~3000 staff) — Integration engineer

Key highlights:

B2I bureau — engineering and integration

The B2I bureau (engineering and integration) bridged the production / operations teams and the R&D / studies teams — in short, the glue between development and prod. A small team of about ten people splitting up the entire application portfolio of the institution. Profiles deliberately polyvalent: combining operations / production know-how with that of studies and development, able to intervene across the whole spectrum without compartmentalisation.

Agile, Redmine and dual hat

Agile workflow; tracking development tasks in Redmine. Project support: studies / development side as technical reference; production side as integrators.

Business portfolio

Portfolio focused on business activities: bibliography and public service. Among the major software: the general catalog, central tool of the library's documentary plan; equally strategic, the booking system — book and room booking — at the heart of the BnF's operation. Public service: ticketing, checkout, etc.

Public service IS — NFC access and ticketing

Responsibility for the public service information system: access control based on NFC cards and rights management (room access, gates and doors with badge readers). For ticketing, the Vivaticket solution and associated checkout stations: each checkout combined a computer with the sales software, a touchscreen and a Zebra printer for tickets and labels.

Project — Heurist (Heurist Network) integration

Integration project for the Heurist software ( HeuristNetwork/heurist on GitHub ): an open source web platform for managing research data in the humanities (PHP, JavaScript, MySQL).

Taking over and inherited perimeter

One of the goals of the role: take over my predecessor's work, who had led many specific developments or integrations relative to existing standards or, more broadly, to the state of the art.

Release preparation and automation

One of the main difficulties: ahead of each release, reviewing developer commits, arbitrating what should enter the right version (release scope), Git branch merges, then preparing releases — driving history and branches, not just directory structure. Goal: automate a large part of this preparation to make the cycle reliable and faster.

Deliverables, production and tooling

On the project / studies side: preparing for production the install packs, documentation, go-live processes, release notes, delivery slip and everything needed for deployment. We were also responsible for installing environments in production: with Jenkins, deploying environments aligned with development versions in flight — continuous integration; Sonar to enforce code quality. Containers (Podman) and Ansible were brought in incrementally. Predominant application stack at the BnF: Java, Tomcat, PostgreSQL; alongside, Git, Node.js, React, Linux (CentOS), VMware, oVirt depending on the perimeter. DevOps foundation and Kubernetes training.

INPI — French Industrial Property Institute (~800 staff) — Linux systems architect engineer

Key highlights:

After Sungard — joining INPI

After the Sungard experience, joined INPI — about nine years there, a very rich experience. On arrival: no virtualization yet, no containers as we know them today; services were still massively installed on dedicated hardware ("bare metal" approach). Linux was not yet dominant across the fleet: a lot of Windows and proprietary Unix (HP-UX, AIX, Solaris). The following years dramatically changed the landscape (virtualization, Linux, automation — see below).

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.

Detail

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.

Sungard Group — Global Portfolio 3 / Asset Management (Neoxam) — Senior support consultant & integrator

Key highlights:

Detail

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 (museum) — Computing engineer

Key highlights:

Detail

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 — training centre (same group as EPSI) — Student job — IT support

Key highlights:

Support and student fleet

During studies at EPSI , student job at DGC , a training centre in the same group as the school. IT support and fleet management of the workstations dedicated to students : Windows NT 4 , then Windows 2000 . Created images with Ghost (Symantec / Norton Ghost) and multicast deployment to re-image machines regularly; Windows profile management (many incidents to handle); permissions and access for student accounts; antivirus installation . Also handled training software / e-learning deployed on site. Also the chance to set up Linux on recycled hardware to provide extra workstations serving site usage.

Technical skills (summary)

Synthesis aligned with my career: Linux/Unix operations in public service, finance, media and energy; virtualization (VMware to Proxmox), private OpenStack/NUBO clouds, Kubernetes & Helm (Onyxia, public-sector compliance), HPC Slurm/Apptainer; automation with Ansible, Terraform, GitLab, Salt; ANSSI hardening, MCS and Cyberwatch; AI agents and document chains in production.

Systems & networking (level 3/3)

Linux Red Hat/CentOS, Debian/Ubuntu, SUSE in production (level 3); Active Directory / LDAP / SSSD integration (Radio France, Naarea); PXE boot / Preseed, LTSP for thin clients (UCAD); BIND DNS, iptables firewall; kernel compilation and trimming (recycled fleet). Unix AIX, Solaris, HP-UX (INPI, Sungard GP3 migrations). Windows and Samba in mixed contexts (small businesses, museum).

Monitoring & observability (level 3/3)

Centreon, Grafana, Prometheus; Nagios → Centreon → Prometheus journey (INPI, Naarea). Graylog, Elastic Stack for logs and correlation. JMX metrics (Tomcat/Java). Tech-functional operations dashboards.

Storage, SAN & DRP (level 3/3)

HP 3PAR SAN, iSCSI, Fibre Channel, NFS; Ceph, S3 / MinIO object storage; MySQL Galera + ProxySQL. VMware Site Recovery Manager DRP / BCP, cross-DC replication and datacenter migrations (INPI). Backups: Bacula, BackupPC, NetBackup, Veeam.

Virtualization, cloud & Kubernetes (level 3/3)

VMware vSphere, oVirt, KVM, Proxmox, Hyper-V; OpenStack (NUBO, ministry). Kubernetes & Helm (Onyxia / Nubonyxia, "Onyxia-flavored" charts, catalog CI). Docker; Apptainer for container-style workloads; first clusters via Rancher / RancherOS (INPI).

Databases & middleware (level 2/3)

MySQL / MariaDB, PostgreSQL, Oracle (operations), MongoDB, MaxDB. Tomcat / Java stacks, Apache NiFi, CMDBuild (RADAR DGFIP). PHP, Node, Heurist (SHS at BnF) integrations. Ext JS (business UI).

Automation & CI/CD (level 3/3)

Ansible (Tower), Terraform (OpenStack VMs), Puppet, SaltStack; Git, Jenkins, GitLab CI, Bercy/BnF/INPI release chains; Rundeck → Ansible Tower (Radio France). Dollar Universe (scheduling). Bamboo / SVN (Sungard era).

Development, scripting & AI (level 3/3)

Bash/shell, Python, JavaScript/React, Go, Ext JS; Django, PHP, VBA/AutoIt. Recent projects: FastAPI, RAG, Whisper. In production: n8n agents, Claude API, local Ollama / Mistral inference (small business), operations scripts and Selenium (prod checks).

HPC & operational security (level 2/3)

Slurm, InfiniBand, Apptainer (MPI, scientific workloads), Lenovo platforms; protected network zones, dedicated LDAP (Naarea). Linux master images hardened to ANSSI guides, MCS. Cyberwatch (INPI rollout, Radio France advice).

Education

Education — additional information

Languages

Interests

Soft skills

Autonomy & focus on results

As an independent consultant, I work autonomously on advanced topics, set my priorities and deliver in demanding contexts.

Mentoring & knowledge transfer

Cross-functional technical reference: I enjoy supporting project managers, explaining the why, and leaving teams stronger than I found them.

Diagnosis & investigation

Comfortable with stalled situations others have failed to solve — like the SSSD episode at Radio France where three engineers had tried before I unblocked it.

Rigor & risk awareness

Carefully prepared go-lives, systematic rollback plans. I know that in a deposit organization or public service, downtime has a cost.

Curiosity & adaptability

From compiling Linux kernels in the 2000s to local Mistral inference in 2026 — I have crossed every technical disruption without freezing.

Cross-team spirit

The B2I role at the BnF — the "glue" between dev and prod — taught me to listen, to arbitrate, and never to oppose studies and operations.

AI, agents and tools (professional usage)

AI is not a fad for me: ever since accessible LLMs appeared, I've made them both a daily working companion and an experimentation field. I use them to code, design and reason — and I build agents that run in production, including local inference to preserve data sovereignty.

Augmented coding & reasoning (daily)

Agents & inference (in production)

Hackathon & RAG (experimentation)

AI projects or experiences cited

Tech watch & curiosities

Selection of projects I find compelling to understand where the systems, virtualization and browser ecosystem is heading. Good illustration of today's frontiers between Linux, low-level and WebAssembly.

Linux/Wasm (Linux kernel · WebAssembly)

The Linux kernel booting directly in the browser via WebAssembly: BusyBox + musl, Xterm.js terminal. A fascinating proof of concept for anyone interested in scheduling, system primitives and the limits of the modern JS sandbox (no MMU, task suspension emulated via Web Workers, etc.).

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

DOS Wasm X (Emulation · WebAssembly)

DOS / Windows 95-98 emulator in the browser, based on DOSBox-X compiled to WebAssembly via Emscripten. Browser-side persistent hard disk, ISO/IMG/CD handling, gamepad support — a very convincing demo of what Wasm with exceptions and asyncify enables today.

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

Personal projects and initiatives

In parallel with my assignments:

Artwork collection portal & AI (2026)

In 2026 , leading the creation of a web portal for managing artwork collections , with AI assistance .

AI hackathon — voice chatbot & Legal Code (Feb 2025)

In February 2025 , took part in a hackathon dedicated to artificial intelligence : our team built a voice chatbot able to extract and quickly serve information from the French Legal Code . Goal: simplify access to law through speech recognition and synthesis. Legal sources — the reference texts came from git.tricoteuses.fr , providing a complete legislative base. Technologies — Whisper (voice → text), LightRAG ( contextualized RAG on GitHub ), shell scripts to clean and format datasets, Python & FastAPI to expose web services, dataset preparation on a development machine (Mac mini, 24 GB RAM). Infrastructure — LLM deployment on the Kubernetes GPU cluster of SPESYS Services , with GPU access for performance suitable to the short hackathon time frame. My role — dataset preparation: extraction, structuring and normalisation of legislative texts; creation of Python/FastAPI primitive APIs linking the speech recognition layer, the RAG module and the rendering. Collaboration — two-day hackathon with exchanges with the DINUM , the Bercy HUB team around the Onyxia (Nubonyxia) project, and other public-sector actors (Ministry of the Economy, Ministry of Justice, etc.). Acknowledgements — Stéphane Baisse and the SPESYS teams ( Thomas Williot , Gérald Moreno ) for infra access and support. Innovation — accessibility (questions out loud), GPU-powered speed, social impact for professionals and the general public.

Software portal — data science & AI (Since 2023)

Since 2023 , developing a software portal for data scientists , focused on data science and AI .

Art institute — Échirolles (volunteer) (2022)

In 2022 , volunteer participation in the creation of an art institute in Échirolles , as IT expert (advice and rollout of the digital base).

WordPress showcase websites (2020)

In 2020 , built websites with WordPress and Elementor for small entrepreneurs .

Le Signe — collection management (Chaumont) (Around 2019)

Le Signe — artwork collection management software: Groovy (backend), JavaScript and React (frontend). Tested and developed around 2019 as part of collection inventory at Le Signe , French national centre for graphic design in Chaumont .

Automatic MCQ correction — AMC (2013)

In 2013 , designed an automatic MCQ correction solution built on the open source Auto Multiple Choice (AMC) tool: generation of unique questionnaires per exam session (questions and answers in a different order from one copy to another), unique barcode per printed paper copy, then scanning , automatic answer recognition (OMR) and automatic grading .

Document automatically generated from the site's structured data (build). Designed for ATS and recruiters' AI assistants: plain text, explicit sections, structured metadata in a YAML header block.