6.3 : Créer son propre module réutilisable

Depuis la section 5, plusieurs fonctions ont été écrites : Test-ServiceCritique, Get-EtatServicesCritiques, New-CompteDepuisCSV. Sophie regarde la pile de scripts éparpillés sur le bureau : « Toutes ces fonctions sont utiles, mais si tu dois les recopier dans chaque nouveau script, c’est le même problème qu’en section 5 avant les fonctions. Il est temps de créer ton propre outil, installable dans tout l’atelier. »

Le fichier .psm1 : le cœur du module

Un module PowerShell « maison » repose sur un fichier portant l’extension .psm1 (PowerShell Module), qui contient simplement les fonctions déjà écrites :

# NordikaTools.psm1

function Test-ServiceCritique {
    param ([string]$NomService)
    $service = Get-Service -Name $NomService -ErrorAction SilentlyContinue
    if ($service.Status -eq "Running") {
        Write-Output "$NomService : OK"
    } else {
        Write-Warning "$NomService est arrêté"
    }
}

function Get-EtatServicesCritiques {
    param ([string[]]$Services)
    foreach ($nomService in $Services) {
        Test-ServiceCritique -NomService $nomService
    }
}

Ce fichier doit être placé dans un dossier portant exactement le même nom, lui-même situé dans l’un des emplacements listés par $env:PSModulePath (vu en 6.1) :

Documents\WindowsPowerShell\Modules\NordikaTools\NordikaTools.psm1

Une fois ce dossier en place, le module se charge automatiquement dès qu’on appelle une de ses fonctions (auto-loading, vu en 6.1), ou explicitement avec :

Import-Module NordikaTools

Le fichier .psd1 : le manifeste du module

Un .psm1 seul fonctionne, mais un module « propre », destiné à être partagé avec d’autres administrateurs de Nordika, s’accompagne presque toujours d’un second fichier : le manifeste, avec l’extension .psd1 (PowerShell Data File).

Ce fichier ne contient aucun code exécutable — uniquement des métadonnées structurées sous forme de hashtable (revoyez la leçon 3.3, la syntaxe @{ } est exactement la même) :

# NordikaTools.psd1

@{
    RootModule        = 'NordikaTools.psm1'
    ModuleVersion      = '1.0.0'
    Author             = 'Service IT Nordika'
    Description        = 'Fonctions internes de supervision et d''administration Nordika'
    PowerShellVersion  = '5.1'
    FunctionsToExport  = @('Test-ServiceCritique', 'Get-EtatServicesCritiques')
    CmdletsToExport    = @()
    VariablesToExport  = @()
    AliasesToExport    = @()
}

On peut générer un squelette de manifeste automatiquement, plutôt que de tout écrire à la main :

New-ModuleManifest -Path ".\NordikaTools.psd1" -RootModule "NordikaTools.psm1" -ModuleVersion "1.0.0"

Pourquoi le manifeste change vraiment la donne

rois raisons concrètes justifient de ne jamais s’en passer sur un module destiné à durer :

Le versionnage. ModuleVersion permet à Get-Module de savoir exactement quelle version est chargée, essentiel dès que plusieurs personnes utilisent le module et que des corrections y sont apportées au fil du temps.

Le contrôle explicite de ce qui est exporté. FunctionsToExport liste précisément les fonctions rendues visibles à l’extérieur du module. Sans cette précision (FunctionsToExport = '*' par défaut dans un .psm1 seul), une fonction interne, utilitaire, purement technique, se retrouve exposée à tous les utilisateurs du module, ce qui nuit à la clarté de l’outil final.

La compatibilité annoncée. PowerShellVersion évite qu’un collègue encore sur PowerShell 5.1 installe par erreur un module qui suppose des fonctionnalités propres à PowerShell 7+.

Retour d’expérience terrain : sur les modules internes que j’ai pu voir circuler dans des équipes IT, l’absence de manifeste .psd1 est presque toujours la cause du même problème : personne ne sait plus quelle version du module tourne sur quel poste, et une correction de bug déployée sur un serveur n’atteint jamais les autres faute de mécanisme de version clair.

Vérifier le module créé

Get-Module -Name NordikaTools -ListAvailable | Format-List *

Cette commande affiche l’ensemble des métadonnées du manifeste, exactement comme pour un module publié officiellement sur la PowerShell Gallery (vue en 6.1).

Un exemple concret Nordika

En rassemblant les fonctions déjà écrites en section 5 (New-CompteDepuisCSV) et en 6.2, le module NordikaTools devient l’outil central du service IT, versionné et documenté :

Documents\WindowsPowerShell\Modules\NordikaTools\
    ├── NordikaTools.psm1
    └── NordikaTools.psd1

Import-Module NordikaTools
Get-EtatServicesCritiques -Services "Spooler", "W32Time", "Dnscache"

N’importe quel collègue de Nordika disposant de ce même dossier dans son PSModulePath peut désormais utiliser ces fonctions, sans jamais avoir vu ni recopié le code source original.

Source officielle : la documentation Microsoft about_Module_Manifests détaille l’ensemble des clés disponibles dans un fichier .psd1 (dépendances entre modules avec RequiredModules, scripts exécutés à l’import avec ScriptsToProcess…), accessible via Get-Help about_Module_Manifests.

Un module maison avec son manifeste, c’est la différence entre un outil bricolé qui traîne sur un poste, et une véritable brique d’infrastructure Nordika, versionnée, documentée, et partageable à toute l’équipe IT.