2010 — 2019
Ingénieur architecte système Linux — INPI — Institut national de la propriété industrielle (~800 agents)
Courbevoie / Bécon-les-Bruyères

## 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.

## undefined
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.
