# Bonnes pratiques opérationnelles

LLMS index: [llms.txt](/v1.1.1.0/llms.txt)

---

Cette page décrit les modèles d'exploitation recommandés pour PackageUpdateInfo dans
les shells interactifs, profils et automatisations.

## Commence avec le comportement par défaut

Réinitialise les paramètres avant d'introduire des réglages personnalisés, surtout sur des systèmes partagés :

```powershell
Set-PackageUpdateSetting -Reset
```

Inspecte la configuration et les règles actuelles :

```powershell
Get-PackageUpdateSetting
Get-PackageUpdateRule -IncludeDefaultRule
```

## Utilise des intervalles de mise à jour pour réduire le bruit

`Get-PackageUpdateInfo` respecte `UpdateCheckInterval`. Si la dernière vérification
effective est encore dans l'intervalle configuré, la cmdlet retourne rapidement.

Définis un intervalle qui correspond à ton environnement :

```powershell
Set-PackageUpdateSetting -UpdateCheckInterval (New-TimeSpan -Hours 6)
```

Utilise `-Force` uniquement pour des vérifications ad-hoc :

```powershell
Get-PackageUpdateInfo -Force
```

## Préfère un démarrage de shell non bloquant

Un modèle de profil pratique est :

```powershell
Start-Job -ScriptBlock {
    Get-PackageUpdateInfo -ShowOnlyNeededUpdate | Export-PackageUpdateInfo
} | Out-Null

Import-PackageUpdateInfo
```

Pourquoi ça fonctionne bien :

- Le démarrage reste rapide car l'import lit les données en cache.
- La vérification en ligne coûteuse s'exécute en arrière-plan.
- Tu obtiens toujours une visibilité utile sur les mises à jour dans chaque session.

## Vérifie explicitement la portée quand c'est nécessaire

Utilise les paramètres de portée lorsque les permissions diffèrent entre modules utilisateur et système :

```powershell
Get-PackageUpdateInfo -CurrentUser
Get-PackageUpdateInfo -AllUsers
```

Utilise `-Repository` dans des environnements avec plusieurs dépôts configurés :

```powershell
Get-PackageUpdateInfo -Repository PSGallery
```

## Conçois soigneusement les règles

Utilise des exclusions larges uniquement si c'est intentionnel. Exclure de grands motifs peut masquer
des mises à jour importantes.

Crée des règles personnalisées ciblées pour les modules à forte rotation :

```powershell
Add-PackageUpdateRule -IncludeModuleForChecking "Az.*" -ReportChangeOnMajor $true -ReportChangeOnMinor $true -ReportChangeOnBuild $false -ReportChangeOnRevision $false
```

Vérifie la priorité des règles en listant toutes :

```powershell
Get-PackageUpdateRule -IncludeDefaultRule | Sort-Object Id
```

## Utilise l'exportation/importation de façon intentionnelle

Les chemins d'exportation et d'importation par défaut sont spécifiques à la plateforme et incluent l'édition PowerShell et la version majeure dans le nom de fichier. Cela aide à éviter de mélanger des données provenant de différentes versions d'exécution.

Options d'exportation courantes :

```powershell
Get-PackageUpdateInfo | Export-PackageUpdateInfo -OutputFormat XML
Get-PackageUpdateInfo | Export-PackageUpdateInfo -OutputFormat JSON
Get-PackageUpdateInfo | Export-PackageUpdateInfo -OutputFormat CSV
```

Recommandations :

- Utilise XML si tu veux préserver des objets typés pour une réimportation.
- Utilise JSON ou CSV pour des rapports externes et intégrations.
- Utilise `-IncludeTimeStamp` pour le suivi historique.

## Garde les notifications utiles

Utilise les notifications toast uniquement là où elles apportent une valeur ajoutée :

- Sur des hôtes Windows avec BurntToast installé.
- Sur des sessions où des alertes interactives sont attendues.

Pour les serveurs, CI, et shells non interactifs, privilégie les rapports exportés plutôt que les notifications toast.