Introduction
Il y a cinq ans, je démarrais dans l’administration système. À l’époque, j’avais les compétences mais pas l’expérience du contexte professionnel. Cinq ans plus tard, je confirme : rien ne remplace le terrain.
Depuis, j’ai passé quatre ans et demi en PME spécialisée en sécurité informatique, tout en maintenant un homelab actif pour expérimenter. Entre les environnements Linux, les outils open source et les imprévus du quotidien, j’ai appris bien plus par la pratique que par la théorie.
Cet article, ce n’est pas un énième guide théorique. C’est un retour d’expérience honnête sur ce que j’ai vraiment appris : les leçons techniques, les erreurs qui font mal, et surtout les soft skills qu’on ne t’enseigne jamais. Ce que j’aurais aimé savoir en démarrant.
Si tu débutes en adminsys ou que tu as quelques années d’expérience, j’espère que tu trouveras ici des leçons concrètes qui résonnent avec ton quotidien.
La technique au quotidien
La documentation
Je l’ai appris à mes dépens : “je m’en souviendrai plus tard” est le plus gros mensonge qu’on se raconte. Six mois après avoir monté un service critique, quand tu dois intervenir dessus en urgence, tu ne te souviens plus de rien. Ni de la configuration particulière, ni de la raison pour laquelle tu as fait ce choix plutôt qu’un autre.
La documentation, ce n’est pas pour les autres. C’est d’abord pour toi, dans quelques mois, quand tu auras complètement oublié le contexte. Même imparfaite, même incomplète, elle vaut mieux que rien.
Ce qu’il faut vraiment documenter :
- Les procédures critiques (déploiement, rollback, gestion d’incident)
- Les choix techniques avec leur justification
- La résolution des incidents majeurs
Pour les outils, pas besoin de partir dans des solutions complexes. Markdown dans un dépôt Git, un wiki simple, ou même des README clairs font parfaitement l’affaire.
L’important, c’est que ce soit accessible et maintenu à jour.
Une documentation obsolète peut être pire que pas de documentation du tout : elle induit en erreur et fait perdre du temps.
L’automatisation intelligente
L’automatisation, c’est un gain de temps. Mais automatiser trop tôt, c’est créer de la complexité pour rien. Ma règle : si tu fais une tâche trois fois, là tu automatises. La première fois, tu la fais manuellement pour comprendre. La deuxième, tu notes les étapes. La troisième, tu envisages un script simple.
L’erreur classique, c’est de créer une usine à gaz que personne ne comprend, toi y compris trois mois plus tard. Un script de 50 lignes clair et commenté vaut toujours mieux qu’un système complexe que toi seul maîtrises. Pour du déploiement multi-machines, un playbook Ansible simple est souvent plus maintenable qu’une collection de scripts dispersés. Garde les choses simples, maintenables, et documente-les.
L’objectif de l’automatisation, c’est de te faire gagner du temps, pas d’en perdre à maintenir un système surdimensionné. Pense aussi aux autres : quelqu’un doit pouvoir comprendre et modifier ton script. C’est le vrai test de qualité.
Monitoring et alerting
Le monitoring, ce n’est pas optionnel. J’ai appris cette leçon de la pire des façons lors d’une panne de climatisation en salle serveur. Sans surveillance de la température, on a découvert le problème quand les machines ont commencé à s’éteindre une par une, surchauffe oblige. Le service était déjà tombé, les utilisateurs impactés, et on est intervenus en réaction au lieu d’anticiper. Si on avait eu une alerte à 30°C, on aurait pu agir avant la catastrophe.
Monitorer, c’est anticiper au lieu de subir. Les métriques essentielles : services critiques, espace disque, charge système, et température de la salle serveur. Des fondamentaux simples qui évitent les catastrophes.
⚠️ Le piège : trop d’alertes tue l’alerte. Des centaines de notifications quotidiennes dont 95% de faux positifs, et tu ignores même les vraies urgences. Les alertes doivent être préventives : à 80% d’utilisation du disque, pas à 95% quand il est trop tard.
Toujours avoir un plan B (et C)
Backups : les faire ET les tester
Faire des backups, c’est bien. Les tester régulièrement, c’est indispensable. J’ai vu trop de situations où on découvre que les sauvegardes sont corrompues ou incomplètes au moment critique, quand il faut vraiment restaurer. À ce moment-là, c’est trop tard pour se rendre compte que le backup ne fonctionne pas.
La règle est simple : si tu n’as jamais testé de restaurer depuis tes backups, tu n’as pas vraiment de backups. Planifie des tests réguliers, au moins une fois par trimestre pour les systèmes critiques.
Et documente la procédure de restore : dans l’urgence, tu n’as pas envie de chercher comment faire.
Stratégie de rollback
Avant chaque déploiement, pose-toi la question : comment je reviens en arrière si ça se passe mal ? Snapshot de VM, sauvegarde de base de données, versioning dans Git pour les configurations. Avoir un plan de rollback clair avant de toucher à la prod, c’est éviter de paniquer quand les choses tournent mal.
Teste ce rollback en environnement de test si tu peux. Savoir que tu peux revenir en arrière rapidement change complètement ton niveau de stress lors d’un déploiement.
Disaster recovery : le plan qu’on espère ne jamais utiliser
Le plan de disaster recovery, c’est celui qu’on espère ne jamais utiliser. Mais quand tout part en vrille, c’est lui qui fait la différence.
L’idée est simple : écris noir sur blanc comment récupérer d’une catastrophe. Qu’est-ce qui est vraiment critique ? Combien de temps tu peux te permettre d’être down ? Dans quel ordre tu remets les services en route ? Le plan doit être accessible quelque part, pas juste dans ta tête. Et surtout, implique l’équipe : tu ne dois pas être le seul à savoir quoi faire.
Un test annuel du plan peut sembler excessif, mais c’est ce qui révèle les failles avant qu’elles ne te coûtent cher.
Les solutions “temporaires” qui deviennent permanentes
Le quick fix qui reste en prod
On l’a tous fait : un script de contournement “juste pour dépanner”, une config “en attendant de faire mieux”, un patch temporaire qui résout un problème urgent. Le problème, c’est que ces solutions provisoires ont la fâcheuse tendance à devenir permanentes. Trois ans plus tard, elles sont toujours là, et personne n’ose y toucher de peur de tout casser.
La dette technique héritée
La dette technique s’accumule silencieusement. Chaque solution temporaire non réglée s’ajoute à la pile. Et parfois, on hérite aussi de la dette des autres.
J’ai découvert ça avec un fail2ban mal configuré sur un service derrière un reverse proxy. Après plusieurs tentatives de mot de passe échouées, le système bannissait l’IP du reverse proxy, rendant le service inaccessible pour tout le monde. La config était là depuis longtemps, personne n’y avait touché “parce que ça marchait”.
Sauf que non, ça ne marchait pas vraiment.
Comment limiter les dégâts
Ce genre de configuration bancale reste en place pour plusieurs raisons : la pression des délais, le manque de temps, les priorités qui changent. Il faut souvent choisir entre “faire fonctionner maintenant” et “bien faire”.
Pour limiter les dégâts, quelques règles simples. Documente clairement que c’est temporaire et pourquoi. Crée un ticket pour le refactoring. Sois honnête avec le management sur l’état réel du système. Et planifie du temps régulier pour traiter cette dette technique.
L’important, c’est d’être conscient de la dette que tu accumules et de prévoir du temps pour y revenir. Parce qu’elle ne disparaîtra pas toute seule.
La sécurité au quotidien
Théorie vs pratique
La théorie dit “il faut tout sécuriser”.
La pratique dit “avec quelles ressources et combien de temps ?"
Le vrai travail, c’est de prioriser : protéger d’abord ce qui est exposé et critique, puis améliorer le reste progressivement. Vouloir atteindre la sécurité parfaite dès le départ, c’est se condamner à ne jamais avancer.
Équilibrer sécurité et opérationnel
Tout verrouiller à 100%, c’est la garantie que la productivité se retrouve fortement impactée. Il faut trouver le bon équilibre : sécuriser ce qui est critique, accepter un risque calculé sur le reste. Un système ultra-sécurisé mais inutilisable ne sert à rien. L’important, c’est de comprendre ce qui compte vraiment pour le métier et d’adapter le niveau de sécurité en conséquence.
Mises à jour de sécurité
Gérer les vulnérabilités, c’est un travail continu. Tout patcher immédiatement, c’est risquer de casser quelque chose en production. Ne rien patcher, c’est laisser des portes ouvertes. La clé, c’est de trier : les CVE critiques sur des services exposés méritent une réaction rapide. Le reste peut souvent attendre une fenêtre de maintenance planifiée.
Quand tu patches, ne le fais jamais sur toutes les machines d’un coup. Commence par un petit échantillon : une ou deux machines. Vérifie que tout fonctionne correctement, que le service redémarre bien, qu’il n’y a pas d’effets de bord. Si tout est stable, déploie progressivement sur le reste du parc. Cette approche te permet de limiter les dégâts si le patch pose problème.
Cette approche de déploiement progressif dépend aussi de ta stack. Si tu utilises de l’open source, voici ce qu’il faut savoir.
Open source : avantage et contrainte
L’open source, c’est un atout : code auditable, communautés réactives, correctifs rapides. Mais sans souscription de support, tu es seul responsable de la maintenance, de surveiller les CVE, et de gérer les mises à jour. Avec des distributions comme Red Hat ou SUSE, tu as un support commercial.
Sans ça, c’est à toi de rester vigilant et de suivre l’actualité de tes outils.
Les leçons humaines et soft skills
Communication avant tout
Savoir faire, c’est bien. Savoir expliquer ce que tu fais et pourquoi, c’est indispensable. Que tu parles à quelqu’un de technique ou non, adapter ton discours pour te faire comprendre fait partie du métier. Une mauvaise communication crée des malentendus, des décisions mal informées, et des tensions inutiles. Cette compétence compte autant que tes compétences techniques.
Gérer les urgences et le stress
Les urgences arrivent, et rarement au bon moment. La différence entre quelqu’un qui gère bien et quelqu’un qui panique ? Une méthode. Avoir des procédures documentées, une check-list mentale, savoir vers qui se tourner.
Paniquer ne résout rien. Quand un service tombe, prends le temps d’analyser méthodiquement et concentre-toi sur la résolution du problème. Le stress ne fait qu’aggraver la situation. Et accepte de demander de l’aide quand tu bloques. Rester bloqué seul pendant deux heures alors qu’un collègue aurait la réponse en cinq minutes, c’est du temps perdu.
Savoir refuser
On te demandera parfois des choses hors de ton périmètre ou irréalistes dans les délais. Apprendre à dire non sans braquer, c’est essentiel.
Porter plusieurs casquettes, c’est formateur. Mais accepter des tâches complètement hors de ton rôle rallonge les délais sur ce qui compte vraiment : la mise en prod, la maintenance, la sécurité.
La méthode : explique tes priorités actuelles, les contraintes techniques, et l’impact sur les projets critiques. Propose des alternatives ou des délais réalistes. Oriente vers le bon service si ce n’est pas de ton ressort.
Dire oui à tout, c’est faire plusieurs choses moyennement bien au lieu de quelques-unes vraiment bien.
Conclusion
Cinq ans plus tard, qu’est-ce que je retiens vraiment ?
Que la documentation sauve du temps, que les backups doivent être testés, que le monitoring des métriques basiques évite les catastrophes, que la dette technique ne disparaît pas toute seule, et que savoir communiquer compte autant qu’être bon techniquement.
Ces cinq années m’ont appris une chose essentielle : la technique ne suffit pas. On peut être excellent techniquement et échouer si on ne sait pas expliquer, prioriser.
Pour ceux qui débutent : vous allez casser des choses. C’est normal. La différence entre un junior et quelqu’un d’expérimenté, ce n’est pas de ne jamais faire d’erreurs, c’est de savoir les gérer et d’en tirer des leçons concrètes.
La vraie compétence, c’est de rester curieux. Parce qu’on apprend toujours, et que c’est ce qui rend le métier intéressant.
Un conseil pour finir : La prochaine fois que vous intervenez sur un système en urgence, prenez 10 minutes après coup pour documenter ce que vous avez fait. Juste les étapes et pourquoi. Votre vous du futur vous remerciera.
Cet article vous a été utile ? Partagez-le avec quelqu’un qui débute en adminsys.