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

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