Windows suffit pour débuter côté support et poste de travail, mais Linux devient rapidement incontournable dès qu'on progresse vers l'infrastructure — et c'est une compétence qui fait la différence sur un CV. Voici comment doser. Pour un poste de support N1/N2 centré sur les utilisateurs, l'essentiel de votre quotidien sera Windows (et un peu de macOS selon l'organisation) : installer, dépanner, gérer les comptes, les mises à jour. Vous pouvez démarrer sans Linux, et c'est même recommandé de ne pas tout apprendre en même temps. Mais dès que vous touchez à l'infrastructure, Linux est partout : la majorité des serveurs web, des services cloud, des équipements réseau, des conteneurs et des systèmes embarqués tournent sous Linux. Beaucoup d'outils d'administration, de supervision et de sécurité sont pensés pour Linux. Un administrateur système, réseau ou cloud qui ne connaît pas Linux est très limité. Concrètement, la progression logique est : maîtriser d'abord Windows côté poste (là où sont vos premières responsabilités), puis vous initier à Linux progressivement — comprendre l'arborescence, les permissions, la ligne de commande, installer un service simple sur une machine virtuelle d'entraînement (section 4.5). La bonne nouvelle, développée dans cette section, est que les concepts sont communs : si vous comprenez les fichiers, les comptes, les permissions et les processus sous Windows, vous les retrouverez sous Linux, avec une syntaxe différente. L'investissement est donc moins lourd qu'il n'y paraît. Mon conseil : ne vous mettez pas la pression pour tout savoir dès le départ, mais considérez Linux comme une compétence à acquérir dès que vous visez l'infrastructure ou une spécialisation (réseau, cloud, sécurité — section 5.5). C'est souvent ce qui distingue un technicien qui plafonne d'un technicien qui évolue.

Pas nécessairement dans l'instant, mais il faut impérativement rester sur une version encore supportée — et cette nuance est capitale en sécurité. Distinguons deux choses. Passer à la toute dernière version dès sa sortie n'est pas obligatoire ni toujours souhaitable : en entreprise, on attend souvent quelques mois qu'une nouvelle version soit éprouvée (correction des bugs de jeunesse, vérification de la compatibilité des logiciels métier et du matériel) avant de la déployer massivement. Migrer précipitamment tout un parc peut créer des incompatibilités et des interruptions. Cette prudence est raisonnable. En revanche, rester sur une version en fin de support est une faute grave. Quand un OS atteint sa fin de support, Microsoft cesse de publier des mises à jour de sécurité : les failles découvertes après cette date ne sont plus corrigées, et la machine devient une porte d'entrée pour les attaquants — un risque qui s'aggrave avec le temps. Les incidents majeurs (rançongiciels notamment) exploitent régulièrement des systèmes obsolètes non mis à jour. Un système en fin de support est donc à considérer comme un danger à traiter en priorité, même s'il « fonctionne encore » : le fait qu'il démarre ne dit rien de sa sécurité. La bonne pratique consiste donc à : maintenir un inventaire des versions d'OS de votre parc (section 5.3), surveiller les dates de fin de support annoncées par l'éditeur, et planifier les migrations avant l'échéance — pas dans l'urgence le jour où le support s'arrête. Anticiper une migration (tester la compatibilité, prévoir le déploiement, informer les utilisateurs) évite à la fois le risque de sécurité et la précipitation. Entre « toujours la dernière version » et « ne jamais changer », la voie professionnelle est : une version stable, éprouvée et toujours supportée, migrée à temps.