Ma feuille de route IT sur 5 ans : de sysadmin à ingénieur d’infrastructure

🌐 Aussi en: English · Deutsch · Español

Linux. Windows. Réseau. Sécurité. Observabilité. Automatisation. Cloud. Kubernetes. IA.

Mais surtout :

🧠 Apprendre à comprendre les systèmes — pas seulement à les faire tourner.

J’ai pas mal réfléchi ces derniers temps à la direction que je veux donner à mes compétences IT dans les années à venir.

Mon parcours professionnel me donne déjà une base assez large :

• 🐧 Administration système Linux
• 📊 Supervision
• 🚨 Gestion technique des événements
• 📝 Gestion des logs
• 🌐 Réseau
• 🔐 Sécurité

Sur le plan professionnel, je me concentre de plus en plus sur Graylog et la gestion des logs.

En dehors du travail, je m’intéresse aussi beaucoup à :

• Windows Server
• Active Directory
• Docker
• Kubernetes
• Git
• Automatisation
• Systèmes d’exploitation
• IA

J’ai aussi un homelab plutôt costaud composé de trois serveurs physiques et deux PC tour.

La question n’est donc pas vraiment :

« Quelle technologie dois-je apprendre ensuite ? »

La question bien plus intéressante, c’est :

« Quel genre d’ingénieur est-ce que je veux devenir au cours des cinq prochaines années ? »

🎯 L’objectif

Mon objectif à long terme n’est pas de devenir celui qui connaît le plus de commandes.

Ce n’est pas non plus de collectionner les certifications comme des Pokémon.

Et ce n’est certainement pas d’apprendre chaque nouvelle techno qui débarque sur Hacker News tous les mardis. 😄

Je veux devenir quelqu’un capable de :

• comprendre une infrastructure complexe
• concevoir une infrastructure
• exploiter une infrastructure
• dépanner une infrastructure
• automatiser une infrastructure
• sécuriser une infrastructure
• superviser une infrastructure
• comprendre les dépendances
• analyser les pannes
• prendre des décisions d’architecture
• évaluer des choix technologiques
• utiliser efficacement l’IA comme outil d’ingénierie

Autrement dit :

🏗️ Ingénierie d’infrastructure

avec des bases solides en Linux, Windows, réseau, sécurité, observabilité, automatisation, cloud et technologies cloud-native.

🧠 Le plus important : comment je veux apprendre

C’est le socle de toute la feuille de route.

Ma façon d’apprendre s’éloigne délibérément du pur par-cœur.

L’infrastructure moderne est tout simplement trop complexe pour mémoriser chaque commande, chaque paramètre d’API et chaque option de configuration.

Et honnêtement :

man systemctl
man kubectl
Get-Help
documentation
Google
ChatGPT
Claude

...exist for a reason. 😎

Je veux donc monter d’un niveau d’abstraction.

❌ L’ancienne approche

Problem
   ↓
Remember command
   ↓
Run command
   ↓
Hope

✅ L’approche que je veux développer

Problem
   ↓
Define the problem
   ↓
Understand the architecture
   ↓
Identify components
   ↓
Understand dependencies
   ↓
Collect evidence
   ↓
Form hypotheses
   ↓
Test hypotheses
   ↓
Find root cause
   ↓
Design solution
   ↓
Automate
   ↓
Document

La commande elle-même ne devient qu’une étape du processus.

La commande est un outil. La compréhension est la compétence.

📐 Mon modèle d’apprentissage : la règle 20/30/30/20

Pour les grands sujets de cette feuille de route, je vise à peu près cette répartition :

Ce n’est pas une formule mathématique rigide.

C’est un rappel de l’endroit où doit porter l’effort.

Si je termine un sujet en connaissant 200 commandes mais sans pouvoir expliquer comment le système fonctionne, j’ai probablement appris la mauvaise chose.

🔬 Le cycle d’apprentissage

Chaque technologie majeure doit passer par le même cycle.

1️⃣ Comprendre

Qu’est-ce que cette technologie ?

2️⃣ Modéliser

Comment est-elle architecturée ?

3️⃣ Construire

La déployer dans le homelab.

4️⃣ Observer

Superviser et examiner son comportement.

5️⃣ Casser

Provoquer volontairement des pannes.

6️⃣ Dépanner

Trouver la cause de façon méthodique.

7️⃣ Automatiser

Transformer le travail répétitif en code.

8️⃣ Documenter

Rédiger la documentation d’architecture et des runbooks.

9️⃣ Expliquer

Être capable d’expliquer le système à un autre ingénieur.

🔟 Valider

Une certification, un test pratique ou un vrai projet comme dernier point de contrôle.

⏱️ Mon budget temps hebdomadaire réaliste

Je ne veux pas que cette feuille de route devienne un deuxième emploi à plein temps.

Une moyenne réaliste :

Objectif : environ 5 à 8 heures par semaine.

Avant une certification, cela peut augmenter temporairement.

Pendant les périodes chargées, cela peut baisser.

L’important, c’est la régularité sur la durée.

🗺️ LA FEUILLE DE ROUTE SUR CINQ ANS

2026
 │
 ├── Linux
 ├── Graylog
 ├── Git
 └── Ansible
       │
       ▼
2027
 │
 ├── Advanced Linux
 ├── Windows Server
 ├── Active Directory
 ├── Security
 └── Infrastructure Architecture
       │
       ▼
2028
 │
 ├── Terraform / OpenTofu
 ├── Infrastructure as Code
 ├── Kubernetes
 └── GitOps
       │
       ▼
2029
 │
 ├── Azure
 ├── Entra ID
 ├── Hybrid Cloud
 ├── Multi-RZ
 └── Disaster Recovery
       │
       ▼
2030
 │
 ├── Observability
 ├── OpenTelemetry
 ├── Platform Engineering
 ├── AI
 └── AIOps

🐧 ANNÉE 1 — Linux, Graylog, Git & automatisation

📅 Période : septembre 2026 – août 2027

Objectif principal : bâtir des bases extrêmement solides en systèmes et en automatisation.

Effort estimé : 5–8 heures/semaine.

🐧 Phase 1 — Linux avancé / ingénierie système

Durée : environ 6–9 mois

Objectif : 120–180 heures

Les sujets que je veux maîtriser

• architecture Linux
• processus de démarrage
• systemd
• processus et threads
• signaux
• ordonnancement CPU
• gestion de la mémoire
• mémoire virtuelle
• systèmes de fichiers
• LVM
• RAID
• ZFS
• réseau
• DNS
• SSH
• permissions
• ACL
• journald
• journalisation
• analyse de performances
• fondamentaux du noyau
• durcissement de la sécurité

Particulièrement important

Je veux comprendre pourquoi Linux se comporte comme il le fait.

Par exemple :

Pourquoi le serveur est-il lent ?

Au lieu de lancer tout de suite des commandes au hasard, je veux apprendre à distinguer :

CPU?
RAM?
I/O?
Network?
Filesystem?
Process?
Kernel?
Application?
Dependency?
Configuration?

Jalon de certification

🎓 LFCS — Linux Foundation Certified System Administrator.

Alternative :

🎓 RHCSA, surtout si l’écosystème Red Hat prend plus d’importance dans mon travail.

Objectif final

Donnez-moi un serveur Linux en panne, et je trouve méthodiquement la cause racine.

📊 Phase 2 — Graylog & gestion des logs

Durée : en continu pendant toute l’année 1

Priorité : TRÈS HAUTE

C’est ma spécialisation professionnelle actuelle.

Sujets

• architecture de Graylog
• nœuds Graylog
• Data Nodes
• OpenSearch
• shards
• réplicas
• index sets
• streams
• pipelines
• parseurs
• traitement
• rétention
• journal
• Fluent Bit
• syslog
• GELF
• Fluent Forward
• relais
• HA
• planification de capacité
• performances
• journalisation de sécurité
• détection d’événements

Architecture cible

Thousands of Servers
        │
        ▼
Agents / Syslog
        │
        ▼
Relay Tier
        │
        ▼
Graylog
        │
        ▼
OpenSearch
        │
        ▼
Hot / Cold Storage

Ce que je veux savoir calculer

• volume d’ingestion quotidien
• besoins en stockage
• surcoût de réplication
• rétention
• stockage chaud
• stockage froid
• dimensionnement du cluster
• scénarios de panne

Jalon professionnel

Être capable de concevoir et de défendre une architecture de journalisation centralisée prête pour la production.

🌱 Phase 3 — Git & Ansible

Durée : 4–6 mois

Git

• dépôts
• branches
• merge
• rebase
• tags
• pull requests
• GitLab
• bases de CI/CD

Ansible

• inventaire
• rôles
• collections
• variables
• templates
• Jinja2
• Vault
• handlers
• idempotence
• tests
• AWX

Objectif

Manual configuration
       ↓
Ansible
       ↓
Git
       ↓
Version-controlled infrastructure
       ↓
Repeatable infrastructure

Je veux en arriver au point où je me dis :

« Si je dois configurer ça deux fois à la main, je m’y prends mal. »

🪟 ANNÉE 2 — Windows Server, Active Directory & architecture

📅 Période : septembre 2027 – août 2028

Objectif principal : passer de l’administration Linux à l’infrastructure d’entreprise.

🪟 Phase 4 — Windows Server

Durée : 4–6 mois

Sujets

• architecture de Windows Server
• rôles et fonctionnalités
• PowerShell
• réseau Windows
• stockage Windows
• clustering Windows
• journaux d’événements Windows
• WinRM
• services
• analyse de performances
• sécurité

🔐 Phase 5 — Active Directory

Durée : 5–7 mois

Sujets

• AD DS
• forêt
• domaine
• conception des OU
• contrôleurs de domaine
• rôles FSMO
• réplication AD
• Sites et services
• DNS
• stratégies de groupe
• Kerberos
• LDAP
• SPN
• comptes de service
• gMSA
• AD CS
• PKI
• sécurité AD

Lien important avec Linux

                 Active Directory
                        │
             ┌──────────┼──────────┐
             │          │          │
            DNS      Kerberos     LDAP
             │          │          │
             └──────────┼──────────┘
                        │
              ┌─────────┴─────────┐
              │                   │
           Windows              Linux
              │                   │
             GPO             SSSD / PAM
          PowerShell          Kerberos
             WinRM               LDAP

L’objectif n’est pas de devenir administrateur Windows à la place d’administrateur Linux.

L’objectif est de comprendre les deux mondes et les interfaces entre eux.

Jalon de certification

🎓 Parcours de certification Microsoft Windows Server / Hybrid Administration.

L’examen exact sera choisi au début de la phase, car Microsoft remanie régulièrement son catalogue de certifications.

🏗️ Phase 6 — Architecture d’infrastructure

Durée : 6–12 mois

C’est l’une des phases les plus importantes de toute la feuille de route.

Sujets

• patterns d’architecture
• hiérarchie
• dépendances entre services
• domaines de défaillance
• HA
• redondance
• répartition de charge
• architecture de stockage
• architecture réseau
• multi-datacenter
• reprise après sinistre
• RPO
• RTO
• planification de capacité
• scalabilité
• architecture de sauvegarde
• architecture de sécurité
• documentation

Grand projet

Concevoir une infrastructure d’entreprise fictive pour :

• 5 000 serveurs
• Linux + Windows
• deux datacenters
• journalisation centralisée
• supervision centralisée
• services d’identité
• supervision de la sécurité
• sauvegarde
• HA
• DR

Livrables :

• schémas d’architecture
• conception réseau
• carte des dépendances
• concept HA
• concept DR
• calcul de capacité
• concept de sécurité
• concept de supervision
• concept de journalisation

Cet exercice est volontairement plus ambitieux qu’un projet de homelab classique.

L’objectif est d’apprendre à penser comme un architecte d’infrastructure.

☁️ ANNÉE 3 — Infrastructure as Code & Kubernetes

📅 Période : septembre 2028 – août 2029

🏗️ Phase 7 — Terraform / OpenTofu

Durée : 4–6 mois

Sujets

• providers
• ressources
• state
• modules
• variables
• outputs
• remote state
• secrets
• CI/CD
• cycle de vie de l’infrastructure

Objectif

Git
 ↓
Infrastructure as Code
 ↓
Provisioning
 ↓
Ansible
 ↓
Configuration
 ↓
Monitoring
 ↓
Logging

Je veux comprendre clairement la différence entre :

• provisionnement
• gestion de configuration
• orchestration
• déploiement d’applications

☸️ Phase 8 — Kubernetes

Durée : 8–12 mois

Priorité : HAUTE

Sujets

• control plane
• API Server
• etcd
• scheduler
• contrôleurs
• kubelet
• runtime de conteneurs
• réseau
• DNS
• Services
• Ingress
• stockage
• PVC
• RBAC
• Secrets
• Helm
• Operators
• GitOps
• Flux
• sécurité
• dépannage

Jalons de certification

🎓 CKA — administration Kubernetes.

Plus tard :

🎓 CKS — sécurité Kubernetes.

La CKS m’attire particulièrement, car elle combine Kubernetes avec mon expérience existante en sécurité.

☁️ ANNÉE 4 — Azure, cloud hybride & multi-datacenter

📅 Période : septembre 2029 – août 2030

☁️ Phase 9 — Azure

Durée : 6–9 mois

Sujets

• architecture Azure
• VNets
• sous-réseaux
• routage
• NSG
• répartition de charge
• VM
• stockage
• identité
• sécurité
• supervision
• journalisation
• gouvernance
• disponibilité
• DR

Jalon de certification

🎓 AZ-104 — Azure Administrator Associate

Elle s’intègre bien dans la feuille de route, car elle réunit calcul, stockage, réseau, identité et administration dans Azure.

🔑 Phase 10 — Entra ID & identité hybride

Durée : 3–5 mois

On-Prem AD
    │
    │ Hybrid Identity
    ▼
Microsoft Entra ID
    │
    ▼
Azure
```

Sujets :

• • architecture d’identité

• • authentification

• • autorisation

• • fédération

• • identité hybride

• • accès conditionnel

• • RBAC

• • identités de service

• • sécurité

🏢 Phase 11 — Multi-datacenter / architecture de datacenter

Durée : 4–6 mois

Cette phase réunit beaucoup des sujets précédents.

                    Global Services
                           │
             ┌─────────────┴─────────────┐
             │                           │
            DC1                         DC2
             │                           │
      ┌──────┼──────┐             ┌──────┼──────┐
      │      │      │             │      │      │
   Compute Network Storage      Compute Network Storage
      │                           │
      └──────────────┬────────────┘
                     │
                 Services
                     │
          Monitoring / Logging / IAM

Sujets

• domaines de défaillance
• redondance de sites
• répartition de charge
• réplication
• sauvegarde
• RPO
• RTO
• DR
• split brain
• quorum
• partitionnement réseau
• dépendances entre services
• planification de capacité

C’est ici que le travail d’architecture précédent devient concret.

📡 ANNÉE 5 — Observabilité, platform engineering & IA

📅 Période : septembre 2030 – août 2031

📊 Phase 12 — Observabilité moderne

Durée : 4–6 mois

                 Observability
                      │
          ┌───────────┼───────────┐
          │           │           │
       Metrics       Logs       Traces
          │           │           │
     Prometheus     Graylog   OpenTelemetry
          │           │           │
          └───────────┼───────────┘
                      │
                    Grafana

Sujets

• métriques
• logs
• traces
• corrélation
• systèmes distribués
• Prometheus
• Grafana
• Graylog
• OpenTelemetry
• alerting
• analyse d’incidents

L’objectif est de passer de :

« Le serveur est rouge. »

à :

« Le service exposé aux clients s’est dégradé parce que la dépendance X a subi de la latence après que le composant Y a épuisé la ressource Z. »

🤖 Phase 13 — IA & AIOps

Durée : en continu

Sujets

• LLM
• prompt engineering
• API d’IA
• RAG
• embeddings
• bases de données vectorielles
• LLM locaux
• agents IA
• MCP
• dépannage assisté par IA
• documentation assistée par IA
• automatisation assistée par IA
• corrélation d’incidents
• AIOps

Exemple

Monitoring Alert
       │
       ▼
Context Collection
       │
       ▼
AI Analysis
       │
       ▼
Possible Causes
       │
       ▼
Diagnostic Tests
       │
       ▼
Human Validation
       │
       ▼
Automation

L’IA doit me rendre plus rapide.

Elle ne doit pas me rendre paresseux intellectuellement.

🏠 Le homelab — mon terrain d’entraînement

Le homelab est une partie importante de la feuille de route, mais il a volontairement moins de priorité que les objectifs d’apprentissage eux-mêmes.

Le plan d’apprentissage passe en premier.

Le homelab sert à transformer la théorie en expérience pratique.

Mon matériel :

• 🖥️ 3 serveurs physiques
• 🖥️ 2 PC tour

C’est largement suffisant pour monter un labo d’infrastructure étonnamment capable.

🧪 Règle n° 1 du homelab

Ne pas se contenter de faire tourner des services. Construire des scénarios.

Au lieu de :

« J’ai un cluster Kubernetes. »

je veux :

« J’ai monté un cluster Kubernetes, tué volontairement un nœud, observé la panne, analysé le comportement et documenté la reprise. »

C’est une expérience d’apprentissage complètement différente.

🖥️ Usage du homelab par phase d’apprentissage

💥 Le programme « Cassez-le exprès »

L’une des parties les plus importantes du homelab consistera à provoquer délibérément des pannes.

Exemples :

• casser le DNS
• remplir un système de fichiers
• arrêter des services critiques
• casser des certificats
• couper la connectivité réseau
• simuler des pannes de stockage
• tuer des nœuds Kubernetes
• casser le RBAC
• casser la réplication Active Directory
• casser l’ingestion Graylog
• générer un volume de logs excessif
• introduire de la latence
• simuler des pertes de paquets

Ensuite :

Failure
  ↓
Symptoms
  ↓
Evidence
  ↓
Hypotheses
  ↓
Tests
  ↓
Root Cause
  ↓
Fix
  ↓
Prevention
  ↓
Documentation

C’est là que je m’attends à apprendre une grande partie de l’essentiel.

📚 Le homelab doit produire de la documentation

Chaque projet sérieux doit laisser une trace.

homelab/
│
├── ansible/
├── terraform/
├── opentofu/
├── kubernetes/
├── monitoring/
├── logging/
├── security/
├── networking/
│
├── architecture/
│   ├── network.md
│   ├── storage.md
│   ├── logging.md
│   ├── kubernetes.md
│   └── disaster-recovery.md
│
└── incidents/
    ├── dns-failure.md
    ├── storage-failure.md
    ├── ad-failure.md
    └── kubernetes-node-failure.md

Le homelab devient ainsi un portfolio concret de travail d’ingénierie.

🤖 L’IA dans le processus d’apprentissage

ChatGPT et Claude feront partie du workflow pendant les cinq années.

Mais c’est le workflow qui compte.

Mauvais workflow

Problem
 ↓
Ask AI
 ↓
Copy solution
 ↓
Done

Meilleur workflow

Problem
 ↓
My own hypothesis
 ↓
AI challenge
 ↓
Alternative hypotheses
 ↓
Diagnostic tests
 ↓
Evidence
 ↓
My decision
 ↓
Implementation
 ↓
Validation

Quelques questions que je veux poser régulièrement :

« Qu’est-ce qui m’échappe ? »

« Quelles sont trois causes racines plausibles ? »

« Quel test permettrait de départager ces hypothèses ? »

« Relis ta réponse précédente d’un œil critique. »

« Sur quelles hypothèses te bases-tu ? »

L’IA devient ainsi un partenaire technique d’entraînement plutôt qu’un générateur de commandes.

🏆 Stratégie de certification

Les certifications sont utiles, mais elles doivent valider la feuille de route, pas la dicter.

La règle est simple :

Pas de certification juste parce qu’elle existe.

Une certification doit soit :

• combler une vraie lacune
• apporter de la structure
• valider des compétences pratiques
• être utile professionnellement

Sinon, le projet lui-même a probablement plus de valeur.

📈 Les niveaux de compétence

Je veux aussi mesurer ma progression en compétences, et pas seulement en certificats.

Niveau 1 — Opérateur

Je sais suivre la documentation et exploiter le système.

Niveau 2 — Administrateur

Je comprends la configuration et je sais résoudre les problèmes courants.

Niveau 3 — Ingénieur

Je comprends l’architecture, les dépendances et les modes de défaillance.

Niveau 4 — Concepteur

Je sais concevoir le système et justifier les choix d’architecture.

Niveau 5 — Architecte

Je sais concevoir des systèmes complexes couvrant plusieurs technologies et domaines de défaillance.

Au fond, la feuille de route sur cinq ans consiste à passer de :

Operator
   ↓
Administrator
   ↓
Engineer
   ↓
Designer
   ↓
Architect

🧠 Ce que je veux savoir faire dans cinq ans

Imaginez qu’on me soumette ce problème :

« Nous exploitons plusieurs milliers de systèmes Windows et Linux répartis sur plusieurs datacenters. Il nous faut une gestion centralisée des identités, de la supervision, de la journalisation, de la sécurité, de l’automatisation, de la haute disponibilité et de la reprise après sinistre. Concevez la plateforme. »

Je veux être capable de raisonner sur :

• Linux
• Windows
• Active Directory
• DNS
• réseau
• sécurité
• stockage
• journalisation
• supervision
• observabilité
• Kubernetes
• cloud
• identité
• automatisation
• HA
• DR
• capacité
• dépendances
• domaines de défaillance

Et surtout :

Je veux comprendre pourquoi l’architecture ressemble à ce qu’elle est.

🚀 La philosophie finale

Il y aura toujours une nouvelle technologie.

Une nouvelle version de Kubernetes.

Une nouvelle plateforme cloud.

Une nouvelle distribution Linux.

Un nouveau système de supervision.

Un nouveau framework d’IA.

Une nouvelle certification.

Et encore une commande que j’aurai oubliée demain matin.

Ce n’est pas grave.

Les technologies changent.

Les principes d’ingénierie changent beaucoup plus lentement.

Les systèmes ont toujours :

• des dépendances
• des interfaces
• des modes de défaillance
• des frontières de sécurité
• des limites de capacité
• des exigences de disponibilité
• des flux de données
• des contraintes d’exploitation

C’est là que je veux investir mon effort d’apprentissage.

🐧 Moins de commandes apprises par cœur.

🏗️ Plus d’architecture.

🔍 Plus de dépannage.

🤖 Plus d’automatisation.

☁️ Plus de réflexion d’infrastructure.

🧠 Plus de compréhension.

Et oui…

J’aurai quand même un terminal, une antisèche, la documentation, ChatGPT et Claude ouverts en même temps.

Parce que :

Être un bon ingénieur d’infrastructure, ce n’est pas tout retenir.

C’est savoir ce qui compte, savoir trouver le reste, et savoir vérifier si la réponse est vraiment correcte.

😎 Maintenant, construisons-le. Et cassons-le de temps en temps.