TP N°6 : Construire le module NordikaTools de A à Z

Sophie clôt cette section modules avec un ticket différent des précédents : « Cette fois, pas de nouveau service à vérifier. Je veux que tu rassembles proprement tout ce qu’on a codé depuis la section 5 dans un vrai module, que n’importe quel collègue pourra installer sur son poste. »

Objectif

Construire un module NordikaTools complet et fonctionnel : fichier .psm1 avec au moins deux fonctions, manifeste .psd1 généré et complété, et vérification que le module se charge correctement.

Ce TP utilise Get-Service et New-LocalUser plutôt que le module ActiveDirectory, pour rester réalisable même sans domaine AD à disposition. La logique reste strictement identique si vous remplacez New-LocalUser par New-ADUser sur un poste connecté à un domaine.

Consignes

Étape 1 — Créez le dossier attendu par PowerShell pour un module maison, nommé exactement NordikaTools.
Indice : revoyez la leçon 6.3, l’emplacement doit correspondre à l’un des chemins listés par $env:PSModulePath (vu en 6.1).

Étape 2 — Dans un fichier NordikaTools.psm1, recréez la fonction Test-ServiceCritique de la leçon 5.4, et ajoutez une nouvelle fonction New-CompteLocalSecurise qui crée un compte local (4.4) avec un mot de passe généré en SecureString, en utilisant try/catch (5.5) pour gérer le cas d’un compte déjà existant.

Étape 3 — Générez un manifeste .psd1 avec New-ModuleManifest, en précisant ModuleVersion, Author et Description.

Étape 4 — Modifiez manuellement le manifeste généré pour restreindre FunctionsToExport aux deux seules fonctions écrites à l’étape 2.

Étape 5 — Fermez et rouvrez votre console PowerShell, puis vérifiez que le module se charge automatiquement dès l’appel d’une de ses fonctions, sans Import-Module explicite.

Étape 6 (bonus) — Ajoutez une troisième fonction Get-VersionNordikaTools qui affiche simplement la version du module (ModuleVersion) définie dans le manifeste, en la récupérant dynamiquement avec Get-Module.