Administrateur systèmes pour environnements Linux et Windows. Automatisation de processus informatiques complexes avec Ansible et Puppet, gestion d'infrastructures serveur telles que virtualisations, serveurs web, pare-feu, proxys etc. Développeur web full-stack avec HTML, S/CSS, JavaScript, TypeScript, PHP et Python, MariaDB et PostgreSQL ; y compris solutions API.
Vous trouverez ici une sélection de mes projets professionnels. Chaque projet représente mes compétences et mon engagement dans différents domaines de l'administration et du développement logiciel.
03.2025 – 10.2025
@rtus (Artus) est un système de traitement des procédures (VBS) pour la documentation des opérations policières et des événements pénaux. Le système permet la saisie systématique, la gestion et l'analyse des données collectées. @rtus est développé par Dataport, un prestataire informatique de l'administration publique.
Le Landesbetrieb Daten und Information (LDI) est responsable de l'introduction et de l'exploitation pour la Rhénanie-Palatinat et la Sarre. Dans ce contexte, j'ai été sollicité en tant que spécialiste externe pour soutenir le projet.
Mon domaine de responsabilité comprenait l'administration système de l'environnement serveur Linux, basé sur RHEL et Debian, ainsi que l'automatisation des processus de déploiement et de maintenance au moyen d'Ansible. Un accent particulier était mis sur le développement de la collection Ansible existante : j'ai optimisé les performances, développé de nouveaux plugins en Python et implémenté des rôles supplémentaires. Les composants existants ont été refactorisés afin de garantir une meilleure idempotence.
La réalisation technique comprenait l'administration et l'automatisation des serveurs backend @rtus basés sur JBoss/Wildfly. Parallèlement, j'ai formé les membres de l'équipe à Ansible et Git afin de les rendre autonomes dans le développement de l'infrastructure.
Associé à ncsolution GmbH
2024
Le 30 juin 2024, CentOS 7 ayant atteint sa fin de vie (EOL) alors que plusieurs VM en étaient encore équipées, il fallait trouver une alternative. CentOS 8 n'était plus une option puisqu'il avait déjà été arrêté le 31 décembre 2021 et avait donc également atteint sa fin de vie. CentOS Stream aurait été une possibilité, mais c'est un concept très différent de ses prédécesseurs. En raison du rolling release, il n'est pas adapté à un environnement de production, étant moins stable et prévisible. Il ne restait donc qu'une migration vers RHEL, SUSE, Oracle ou les alternatives libres Rocky Linux et AlmaLinux. En raison de la libre utilisation, des meilleurs outils, de la meilleure documentation et des miroirs libres disponibles, j'ai opté pour AlmaLinux.
Dans un premier temps, CentOS 7 a été équipé des dépôts CentOS d'AlmaLinux, les mises à jour ont été effectuées et le système a été migré vers AlmaLinux 8 avec Leapp. À ce stade, les programmes installés ont pu être mis à jour, puis le système a été migré vers AlmaLinux 9. Enfin, les programmes installés ont de nouveau été mis à jour et diverses erreurs ont été corrigées, de sorte qu'un système sûr et fonctionnel était de nouveau disponible. Malheureusement, cela a dû être effectué manuellement sur tous les systèmes, car ceux-ci étaient configurés différemment et chacun avait ses propres problèmes.
La migration vers AlmaLinux a assuré une base stable pour les années à venir. Les mises à jour et surtout les mises à jour de sécurité sont de nouveau possibles et tous les programmes installés sont de nouveau à jour. Enfin, les serveurs ont été intégrés au job de mise à jour Ansible et sont désormais régulièrement maintenus à jour.
Associé à CSD Holding GmbH (Strehlow)
2024
Avec un nombre de serveurs en constante augmentation, la maintenance mensuelle des serveurs devenait de plus en plus chronophage. Afin d'automatiser les tâches de maintenance et de réduire le temps total, la décision collective a été prise d'introduire Ansible pour les serveurs Linux dans l'infrastructure hétérogène Windows-Linux.
J'ai implémenté un serveur Ansible basé sur Debian avec Semaphore UI comme interface utilisateur. L'intégration avec le serveur GitLab existant a permis un développement structuré des collections Ansible avec une branche de développement séparée et des branches de fonctionnalités temporaires. Semaphore UI récupérait les collections exclusivement depuis la branche main stable.
Pour réduire l'effort de maintenance mensuel et mettre à jour simultanément les serveurs Linux, j'ai développé une collection avec deux rôles centraux : des mises à jour quotidiennes et des redémarrages hebdomadaires déclenchés selon les besoins. Le système ne redémarrait les serveurs intelligemment que lorsqu'il y avait un besoin réel. La maintenance se réduisait ainsi à une simple vérification de l'historique des jobs dans le serveur Ansible au lieu de mises à jour manuelles individuelles.
Le département de développement a reconnu le potentiel et a demandé un soutien pour l'optimisation de la consommation de mémoire vive de leurs applications IIS. J'ai alors développé une autre collection avec des rôles spécialisés pour le recyclage coordonné des pools d'applications. La solution tenait compte des dépendances et implémentait des temps d'attente intelligents entre les redémarrages. L'exécution nocturne de cette automatisation a assuré des performances et une stabilité nettement améliorées pendant les heures de travail.
Le système Ansible a considérablement réduit l'effort de maintenance, augmenté la stabilité des systèmes et libéré des capacités pour d'autres tâches importantes.
Associé à CSD Holding GmbH (Strehlow)
2024
Comme premier projet après mon embauche chez Strehlow, j'ai pris en charge la modernisation du serveur de déploiement Windows, qui se trouvait dans un état critique. La situation de départ était problématique : le serveur distribuait une version obsolète de Windows 10 sans tâche de mise à jour séparée, de sorte que les mises à jour s'exécutaient de manière incontrôlée pendant le déploiement puis encore interminablement après. Le logiciel principal SaniVision était installé manuellement fichier par fichier en raison de sa complexité, ce qui était chronophage et source d'erreurs. Les logiciels supplémentaires étaient bien à jour sur le partage, mais n'étaient pas intégrés dans WDS. Sur certains modèles de matériel, les cartes réseau n'étaient pas reconnues après le démarrage PXE, nécessitant des adaptateurs USB-C comme solution de contournement. Les pavés tactiles et d'autres matériels ne fonctionnaient pas non plus dans Windows PE.
J'ai d'abord réparé le partage existant en intégrant une version actuelle de Windows 10 et en corrigeant les installations de logiciels et scripts existants. En parallèle, j'ai développé la première version d'un script PowerShell pour l'installation automatisée du logiciel complexe SaniVision.
Un partage entièrement nouveau avec une structure ordonnée a été créé et Windows 11 intégré. Tous les pilotes Windows PE nécessaires ont été implémentés, rendant les connexions réseau standard et les pavés tactiles disponibles dans l'assistant de déploiement Windows. Les séquences de tâches ont été optimisées et une tâche de mise à jour activée. Le script SaniVision a été remanié, de nouveaux scripts d'installation pour d'autres logiciels ont été ajoutés et l'affichage graphique a été amélioré pour une meilleure détection des erreurs. Le premier partage a été conservé comme système de secours.
Sur la base des enseignements acquis, un troisième partage hautement optimisé a été créé. Les scripts ont reçu une détection de dépendances et une gestion d'erreurs améliorée. Un mécanisme de mise à jour intelligent a été implémenté : les nouvelles versions n'avaient plus qu'à être copiées dans le répertoire correspondant, le script reconnaissait automatiquement la version la plus récente et l'installait. Des scripts de détection matérielle permettaient aux tâches de pilotes de n'installer que les pilotes spécifiques à l'appareil. Cela a réduit le nombre de séquences de tâches à une seule séquence standard au lieu de plusieurs variantes spécifiques. Le premier partage a été définitivement supprimé à l'achèvement de cette phase.
Le résultat était une installation entièrement automatisée et sans surveillance avec un taux d'erreur minimal. Le temps de déploiement a été considérablement réduit, la maintenance simplifiée et la fiabilité de l'ensemble du système nettement améliorée.
La refonte du serveur WDS a eu un autre effet positif. Les installations et scripts qui avaient été externalisés vers PDQ Deploy & Inventory comme solution de contournement et devaient y être lancés manuellement après chaque installation Windows, ont pu être réintégrés dans le serveur WDS. Cela a rétabli la séparation claire des responsabilités entre les deux systèmes. Le serveur WDS prenait désormais en charge toutes les installations générales, tandis que PDQ se concentrait exclusivement sur les mises à jour et les installations spéciales ainsi que les scripts.
Associé à CSD Holding GmbH (Strehlow)
2023
La société SCHUBERTH GmbH nous a chargés de développer un système de déploiement pour l'installation rapide et uniforme de leurs clients légers. Les exigences comprenaient une solution basée sur Linux avec connexion automatique et démarrage immédiat du client VMware Horizon préconfiguré.
Après des retards initiaux, j'ai pris la direction du développement. La solution reposait sur Debian avec des automatisations Preseed. J'ai développé un script qui assemblait automatiquement tous les composants nécessaires en une image ISO amorçable. Le processus comprenait la configuration d'un fichier Preseed pour les paramètres Debian ainsi que l'intégration de divers mécanismes pour l'installation du Horizon Client, les fonctions de démarrage automatique et les scripts de connexion. Le script modifiait une ISO Debian standard en créant les structures de répertoires nécessaires, en intégrant tous les fichiers requis, en adaptant le menu GRUB et en générant une nouvelle image ISO. Avec cette image, un nombre illimité de clés USB amorçables avec un résultat d'installation identique pouvait être créé.
Le processus d'installation se déroulait de manière entièrement automatisée : après le démarrage depuis la clé USB, l'installation sans surveillance pouvait être lancée via le menu GRUB. L'installateur Debian exécutait toutes les étapes de manière autonome, les late-commands prenant en charge l'installation du Horizon Client ainsi que l'implémentation de tous les scripts et adaptations système nécessaires.
En production, le système démarrait automatiquement, un script de surveillance vérifiait et corrigeait si nécessaire les paramètres système. Un utilisateur restreint était automatiquement connecté, puis le Horizon Client démarrait en mode plein écran. Un script de monitoring surveillait en continu l'exécution du client et initiait l'arrêt du système dès sa fermeture.
La solution a considérablement simplifié l'administration ; les systèmes défectueux pouvaient être réinstallés en quelques minutes, les analyses d'erreurs fastidieuses étaient supprimées. Les utilisateurs finaux bénéficiaient de l'intégration transparente, car ils pouvaient travailler directement avec leur environnement VMware Horizon habituel sans avoir besoin de connaissances Linux. L'installation des clients légers était effectuée de manière autonome par les administrateurs SCHUBERTH, tandis que nous restions disponibles pour les adaptations et extensions.
Associé à LOOMA GmbH
2019 – 2023
La direction de LOOMA GmbH a décidé une réorientation stratégique, abandonnant le modèle classique de société de services informatiques avec facturation à l'heure, contrats de maintenance et support réactif, au profit d'un modèle MSP avec prix fixes pour le matériel et les services gérés incluant un support proactif et des processus automatisés.
La phase de planification s'est concentrée sur le développement des différents paquets de services et la sélection d'outils adaptés pour le monitoring et la gestion. Des questions critiques ont été élaborées : comment résoudre proactivement les problèmes existants des clients ? Quelles sont les valeurs ajoutées pour les clients ? Les aspects juridiques tels que les questions de responsabilité en cas de dommages ou d'insolvabilité du client ont été pris en compte, ainsi que le défi de convaincre les clients existants du nouveau modèle et d'intégrer leur infrastructure existante. Une autre question importante s'est développée pendant la phase de planification : que faire si l'infrastructure d'un client existant ou nouveau ne peut pas être intégrée dans le modèle MSP ? Qui doit alors assurer le support de ces composants ?
La mise en œuvre s'est faite progressivement avec trois services principaux : Managed Workplace, Managed Security et Managed Server. Pour des installations Windows uniformes et spécifiques aux clients, un serveur WDS a été utilisé, capable de provisionner plusieurs appareils simultanément via le réseau (PXE). Comme solution de monitoring, Paessler PRTG a d'abord été implémenté, puis finalement Zabbix. Comme solution RMM, après l'utilisation de ManageEngine et SolarWinds, Datto RMM a finalement été adopté. Un système de tickets propre a été développé avec n8n/Zapier et Bubble, capable d'exécuter des processus automatisés via API et webhooks, et ultérieurement enrichi d'un support IA. Cela a permis la mise en œuvre des paquets MSP, ainsi que de services spécialisés comme l'infrastructure de télématique (TI) pour les cabinets médicaux. L'architecture de sécurité reposait sur les produits Sophos avec gestion centralisée via Sophos Central, tandis que les composants réseau Ubiquiti étaient gérés centralement via le cloud Ubiquiti. Les installations Office existantes et les serveurs Exchange des clients ont été migrés vers Microsoft 365.
Comme pressenti lors de la phase de planification, les réactions des clients étaient mitigées. Tandis que certains clients existants rejetaient le nouveau modèle et changeaient de prestataire, d'autres clients existants et nouveaux ont pu être conquis avec succès au modèle MSP. Sur la base des premières expériences, les services ont été continuellement optimisés. La préparation minutieuse a permis immédiatement une résolution proactive des problèmes et une détection précoce des dysfonctionnements. Les automatisations comme les mises à jour Windows gérées centralement ont considérablement réduit la charge de travail et garanti aux clients des systèmes stables et sécurisés.
Associé à LOOMA GmbH
2020
La société EQO Energiekonzepte GmbH avait subi plusieurs vols sur les chantiers de ses parcs solaires et nous a chargés de développer un système de surveillance mobile. Les exigences étaient clairement définies : le système devait être discret, mais rapide et simple à installer sur place. Comme le courant de chantier était disponible sur tous les sites, une installation standard 230 volts pouvait être réalisée.
Après l'élaboration d'un plan de composants détaillé et la concertation avec le client, la mise en œuvre technique a été réalisée. Le système reposait sur un routeur LTE pour la connexion Internet et des composants Ubiquiti pour la surveillance : un switch PoE, un Cloud Key pour la gestion et le téléchargement cloud, ainsi que diverses caméras Ubiquiti. Tous les composants ont été montés sur une tôle perforée dans un coffret de distribution verrouillable et fixés avec des colliers de serrage.
La configuration permettait des enregistrements automatiques lors de la détection de mouvement avec téléchargement direct dans le cloud Ubiquiti. Lors du déclenchement, les responsables recevaient des notifications par e-mail avec des captures d'écran des enregistrements. Après une formation approfondie, l'employé d'EQO a pris en charge de manière autonome le montage et le démontage du système sur les différents sites.
Malgré des fausses alarmes occasionnelles dues aux animaux sauvages, au vent ou à la neige, le système a rempli son objectif : les accès non autorisés et les vols ont été documentés, ce qui a permis de les prévenir en partie ou au moins de les enregistrer de manière à pouvoir identifier les plaques d'immatriculation ou les personnes. La sécurité sur les chantiers a été durablement améliorée.
Pour les questions, modifications et support, nous sommes restés à la disposition de l'entreprise après l'implémentation.
Associé à LOOMA GmbH
2019
Les Stadtwerke Wernigerode prévoyaient l'introduction d'un système Digital Signage pour deux domaines d'utilisation : en interne pour l'information des employés dans les établissements et comme système publicitaire dans les centres clients. Le choix s'est porté sur Xibo comme plateforme centrale.
Ma tâche dans ce projet consistait en l'installation complète du serveur. Comme base technique, j'ai choisi Debian avec Apache HTTP Server et MySQL. J'y ai installé le CMS Xibo et effectué les configurations système nécessaires.
L'installation et le raccordement des Xibo Players ont été réalisés par les administrateurs des Stadtwerke de manière autonome, ce qui a assuré une intégration transparente dans le paysage informatique existant.
Après l'achèvement du projet, je suis resté disponible en tant que support de 3e niveau et j'ai assuré la formation des employés à l'utilisation du nouveau système. Cet accompagnement continu a permis aux Stadtwerke d'utiliser le système Digital Signage de manière optimale et de créer des campagnes de manière autonome.
Associé à LOOMA GmbH
2004 – 2014
Après 2000, de nombreuses autorités et institutions fédérales ont déménagé à Berlin. La décision de 1991 de faire de Berlin la capitale avait lancé un long processus de déménagement qui s'est prolongé en partie jusqu'à la fin des années 2010. Comme les tâches et procédures de ces projets étaient largement similaires, je les résume ici.
Nous avons participé à plusieurs de ces déménagements à différentes phases. L'envergure des projets variait : pour certaines autorités, nous avons pris en charge la préparation de l'infrastructure informatique à Berlin, pour d'autres le démontage de la technique à Bonn. Dans de nombreux cas, nous avons accompagné l'ensemble du processus de déménagement, du démontage à la nouvelle installation.
L'éventail des tâches comprenait souvent aussi l'installation et la configuration de postes de travail complets. Pour ces déploiements à grande échelle, nous avons d'abord utilisé les Remote Installation Services (RIS), puis nous sommes passés aux Windows Deployment Services (WDS) plus modernes. Ces solutions de déploiement automatisées, y compris des scripts PowerShell, nous ont permis d'installer des centaines de postes de travail de manière efficace et standardisée.
Associé à Das Systemhaus Datentechnik Berlin GmbH
2005
À l'origine, il s'agissait simplement de créer une possibilité pour les clients de calculer eux-mêmes les prix de transport pour les marchandises encombrantes. Cette fonction a ensuite été intégrée dans un espace client protégé avec fonction de connexion et continuellement enrichie. Progressivement, de nouvelles fonctionnalités ont été ajoutées, notamment l'inscription pour les ordres d'enlèvement et les informations AVIS.
Le calculateur initial pour marchandises encombrantes s'est développé en un calculateur de prix de transport complet. Outre les marchandises normales et encombrantes, il était désormais possible de calculer des prestations supplémentaires comme les livraisons same-day et next-day ainsi que les assurances transport.
Dès la première version, General Express avait une longueur d'avance sur le partenaire système GO! Express & Logistics. La version finale constituait même un système unique en Allemagne.
J'ai réalisé le portail côté backend avec PHP et MySQL, pour le frontend XHTML, CSS et JavaScript ont été utilisés. La réalisation technique a été effectuée sur un serveur web compatible PHP avec base de données MySQL chez Strato.
Le portail a connu un grand succès auprès des clients de Berlin et a ensuite été utilisé à l'échelle nationale par des clients de GO!. Avec de petites adaptations et extensions, il est resté en service avec succès jusqu'à la cessation d'activité de General Express (2010).
Associé à Michel Abele (entreprise individuelle en activité complémentaire, Berlin)
2004
Dans ce projet extraordinaire, il s'agissait de transférer les serveurs Medien-Communication (MeCom) du Deutscher Depeschendienst (ddp, alors encore ProSieben), du centre de données ProSieben à Unterföhring au centre de données Level 3 de Berlin, sans interruption majeure. Le défi particulier était que les serveurs ne pouvaient être transportés que pendant les heures sans activité rédactionnelle et que d'éventuels dommages de transport devaient être réparés immédiatement.
Le créneau horaire était extrêmement serré : le démontage des serveurs ne pouvait commencer qu'après la déconnexion du dernier reporter, généralement entre minuit et une heure du matin. À Berlin, les systèmes devaient être à nouveau pleinement opérationnels au plus tard à six heures pour le début de la rédaction, ou au plus tard à huit heures pour le début de la rédaction principale.
Avec une distance d'environ 580 kilomètres entre Unterföhring et Berlin, principalement sur autoroute, un trajet normal durerait cinq à six heures. Cela aurait dépassé le créneau horaire. La solution était simple et efficace : avec l'Audi RS6 Avant du patron, le temps de trajet pouvait être réduit à quatre heures et demie, permettant ainsi de respecter les délais critiques.
Le projet se divisait en deux phases. Dans la première phase, l'infrastructure complète a été préparée dans le centre de données Level 3 de Berlin. Les composants réseau et le câblage ont été installés de manière à ce que les administrateurs systèmes de ProSieben puissent ajuster leurs configurations réseau pendant le temps de transport. La seconde phase comprenait le trajet vers Unterföhring, le démontage des trois serveurs MeCom, le trajet vers Berlin et l'installation sur place.
Lors de la mise en œuvre, le dernier reporter s'est déconnecté vers 0h30. Après le démontage rapide des serveurs, le « trajet » a débuté à une heure du matin. Après l'arrivée à Berlin, les serveurs ont été montés dans le rack, mis en service et deux disques durs défectueux ont été remplacés. À six heures pile, la rédaction a pu reprendre son travail comme prévu.
Associé à Das Systemhaus Datentechnik Berlin GmbH
2003
Comme les tickets de support sur papier étaient fréquemment perdus ou oubliés et que l'état de traitement était difficilement traçable, l'équipe a décidé de développer son propre système de tickets numérique.
Lors de la phase de planification, un cahier des charges simple a été élaboré, permettant à tous les collaborateurs d'apporter leurs exigences et idées. La réalisation technique s'est faite avec PHP, XHTML et CSS, tandis qu'une base de données MySQL assurait le stockage des données côté backend. Comme base, un système Debian avec Apache HTTP Server sur du matériel propre a été utilisé. Avec un collègue, j'ai pris en charge l'installation et la programmation du système. Après l'achèvement, les autres collègues ont été formés au nouveau système.
Au fil du temps, la solution a été continuellement enrichie de fonctionnalités supplémentaires. Un module important était le système d'inventaire intégré. Celui-ci gérait de manière centralisée les plages de numéros attribuées par les clients et garantissait qu'aucune attribution en double ne puisse se produire. Auparavant, il y avait régulièrement des doublons de numéros d'inventaire ou des omissions de plages entières.
Ce qui avait commencé comme solution à un problème s'est développé en un outil complet allant bien au-delà de la gestion de tickets initiale. Le département support a pu considérablement améliorer son efficacité, les tickets étant désormais transparents et traçables de manière centralisée. Le système a fonctionné de manière stable jusqu'à la liquidation de l'entreprise, mon collègue et moi assurant la maintenance et l'entretien continus.
Associé à Das Systemhaus Datentechnik Berlin GmbH