Retour aux compétences

ADMINISTRATION SYSTÈMES

Déployer et maintenir des infrastructures stables en production. Gérer les systèmes d’exploitation et les services critiques.

Définition et contexte

L’administration systèmes, c’est gérer l’OS et l’infra qui fait tourner les services. C’est installer un serveur, le configurer, le sécuriser, le maintenir en prod sans downtime.

Il y a deux phases : la conception (comment organiser l’infra ?) et la maintenance (garder ça opérationnel). J’ai pratiqué les deux.

Au départ de ma carrière, je faisais du design infra. Maintenant, je fais surtout du maintien en production. C’est une évolution normale : tu apprends en construisant, puis tu deviens expert en le gérant.

En entreprise, c’est une compétence très demandée. Linux et Windows Server tournent partout. Les admins systèmes qui savent vraiment ce qu’ils font sont précieux.

Éléments de preuve : Trois anecdotes

Active Directory au projet ESIEA

Au projet réseau virtualisé, on devait mettre en place Windows Server avec Active Directory – la base de la gestion d’identités en entreprise.

Pas juste installer AD, mais concevoir la structure intelligemment. Créer les Unités Organisationnelles (OU) par département, créer les utilisateurs, et surtout appliquer des GPO (Group Policy Objects) pour du hardening massif.

On a verrouillé les machines de façon « drôle » (test pour voir jusqu’où on pouvait aller) : rien ne pouvait s’installer sans admin, les services inutiles désactivés, les droits au minimum. C’était excessif pour une vraie entreprise, mais c’était l’occasion d’apprendre comment AD fonctionne vraiment.

Résultat : Un AD fonctionnel, des machines sécurisées (peut-être trop), et une compréhension profonde de comment les identités et les permissions fonctionnent en Windows. [Lire la réalisation complète : Réseau virtualisé]

TrueNAS et ZFS au HomeLab

Au HomeLab, j’ai déployé TrueNAS Scale pour gérer le stockage. Mais y’avait des complexités :

ZFS RAIDZ2 : Configurer 5 disques en RAIDZ2 ce n’est pas trivial. Faut comprendre comment la parity fonctionne (perdre 2 disques sans perte de données, c’est cool en théorie, faut l’avoir fait pour vraiment comprendre). Fallait gérer l’ordre des disques dans le vdev, configurer les snapshots et clones pour les backups.

Passthrough des disques : Les 5 HDD n’étaient pas touchés par Proxmox, passés directement à TrueNAS. Faut bien configurer ça, sinon les permissions cassent ou le stockage devient instable.

Permissions SMB/NFS : Gérer qui peut lire/écrire où. Simple en théorie, c’est vite complexe quand t’as plusieurs VMs qui accèdent aux mêmes données.

Résultat : Un NAS fonctionnel qui stocke 12 To de données avec redondance 2-disques. Mais surtout, j’ai compris comment du vrai stockage en prod fonctionne. [Lire la réalisation complète : HomeLab]

Debian et CasaOS au HomeLab

Au HomeLab, j’ai aussi déployé Debian avec CasaOS pour héberger Jellyfin (streaming vidéo), Nextcloud (cloud perso), et autres services en Docker.

L’admin système ici, c’était : installer Debian proprement (partitioning, filesystem), configurer Docker, gérer les accès (qui peut faire quoi ?), monitorer les ressources (CPU, RAM, disque ne doit pas être full).

Le truc important : faire en sorte que ça tourne 24/7 sans intervention. Pas de « j’ai relancé le service ce matin ». Juste du stable.

Résultat : Un serveur Debian qui tourne depuis mois sans problème majeur. Je sais comment maintenir une machine Linux en prod. [Lire la réalisation complète : HomeLab]

Mon autocritique : Où j’en suis vraiment

Je me considère à un niveau confirmé sur cette compétence. Je peux installer et configurer un serveur (Linux ou Windows), je peux le maintenir en prod, je comprends les concepts clés (permissions, services, monitoring).

Ma marge de progression : J’ai surtout pratiqué du maintien en production (garder ça stable). Je suis moins bon sur la conception d’infra à l’échelle (comment organiser 100 serveurs ?). C’est une vue plus haute que je dois apprendre.

Contextualisation : Admin systèmes fonctionne différemment selon le contexte. En lab ? Tu peux casser et recommencer. En prod avec 500 users ? Un changement c’est une opération de 3 mois avec tests et rollback plans.

Vitesse d’acquisition : J’ai appris ça en combinant la théorie (cours école) avec la pratique (alternance, HomeLab). La théorie sans pratique, c’est oubliable. La pratique sans théorie, c’est des raccourcis qui cassent plus tard.

Mon conseil : Avec ce que je sais maintenant, je dirais : avant de déployer en prod, simule-le d’abord. Pas de « on verra bien ». Test, rollback plan, documentation. C’est ennuyeux, mais ça sauve des vies.

Mon évolution : Où je veux aller

À moyen terme, je veux monter en niveau de responsabilité. Passer de « je maintiens un serveur » à « je conçois l’infra pour 500 users ». Je vise aussi du cloud systems admin (AWS, Azure, GCP).

Formations en cours : Je lis sur Kubernetes et l’infrastructure cloud. Pas de certifications formelles, mais je pratique.

Réalisations rattachées :