Microsoft AZ-400: Gestion des paquets et des artefacts — Guide d'étude

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Fait partie du Microsoft DevOps Engineer Expert AZ-400 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La gestion des paquets est l’épine dorsale des builds reproductibles, des déploiements fiables et des chaînes d’approvisionnement sécurisées dans Azure DevOps. Azure Artifacts centralise le stockage et la gouvernance des paquets à travers les écosystèmes — NuGet, npm, Maven, Gradle et les paquets universels — tout en permettant la mise en cache amont depuis les registres publics et des contrôles fins pour la promotion, la rétention et les autorisations. Combiné à l’automatisation du versionnement sémantique et aux outils de sécurité/conformité, il vous permet de standardiser la manière dont les dépendances internes et externes sont produites, découvertes, approuvées et consommées à grande échelle.

Concepts de base d’Azure Artifacts

Un flux (feed) est l’unité de stockage et de contrôle d’accès pour les paquets. Les équipes organisent généralement les flux par produit, plateforme ou périmètre de confiance (par exemple, un flux pour toutes les dépendances OSS publiques via l’amont, un pour les bibliothèques internes partagées, et un par produit). Les flux prennent en charge plusieurs types de paquets, chacun avec ses propres outils clients.

Les vues (views) implémentent un modèle de promotion contrôlée au sein d’un même flux :

local : tous les paquets nouvellement publiés apparaissent ici
prerelease : utilisé pour exposer les builds bêta/nocturnes aux adopteurs précoces et aux pipelines d’intégration
release : seuls les paquets approuvés pour la production sont promus ici pour une consommation générale Les consommateurs ciblent une vue spécifique pour éviter automatiquement le contenu instable. Promouvez ou rétrogradez les versions dans le cadre de votre processus de livraison pour contrôler le rayon d’impact (blast radius).

Les sources amont (upstream sources) connectent un flux aux registres publics (NuGet.org, npmjs.com, Maven Central). Lorsqu’elles sont activées, les développeurs résolvent les dépendances publiques via votre flux. Azure Artifacts agit comme un proxy transparent et met en cache les versions exactes qui sont utilisées, améliorant la fiabilité, permettant des scénarios déconnectés (air-gapped) et vous autorisant à « geler » ultérieurement l’approvisionnement en désactivant les nouveaux téléchargements amont. Vous pouvez définir quelles sources amont sont activées par flux pour répondre aux politiques.

La rétention est appliquée pour réduire les coûts de stockage tout en préservant ce qui est important. Définissez des politiques pour conserver les N dernières versions par paquet, ne retenir que les versions promues en release, et supprimer automatiquement les anciennes prereleases. Épinglez des versions spécifiques pour les exempter du nettoyage (par exemple, celles intégrées dans une branche de produit à longue durée de vie). Alignez les fenêtres de rétention sur les exigences d’audit et de restauration (rollback) pour équilibrer la traçabilité et le coût de stockage.

Les autorisations de flux suivent le principe du moindre privilège :

Owner (Propriétaire) : gère les paramètres du flux, les autorisations, les vues et les politiques de rétention
Contributor (Contributeur) : publie, déliste, déprécie et promeut les paquets ; ne peut pas modifier les paramètres au niveau du flux
Reader (Lecteur) : restaure/consomme uniquement ; ne peut pas modifier les paquets Note : « Collaborator » (Collaborateur) n’est pas un rôle de flux Azure Artifacts. Si vous rencontrez ce terme, faites correspondre sa capacité prévue (souvent « peut publier ») au rôle Contributor dans Azure Artifacts.

Gestion des écosystèmes de paquets

NuGet (dotnet/C#)

Versionnement : Préférez SemVer 2.0.0 (par ex., 1.4.0, 1.4.1-alpha.3+build.45). Les étiquettes de pré-version contrôlent la distribution via les vues ; les consommateurs de la vue release ne rencontrent jamais les variantes -alpha/-beta.
Publication : dotnet pack ou nuget pack, puis dotnet nuget push ou nuget push vers le point de terminaison de votre flux. Utilisez les tâches NuGet d’Azure Pipelines et promouvez vers les vues prerelease/release lors des portes de qualité (quality gates).
Consommation : configurez nuget.config avec l’URI source du flux (éventuellement limité à une vue). Restaurez via dotnet restore ou la tâche NuGet Restore.
Flux authentifiés : utilisez le fournisseur d’informations d’identification (Credential Provider) d’Azure Artifacts (intégré dans les SDK dotnet récents) ou la tâche de pipeline NuGet Authenticate. Pour les développeurs, connectez-vous via Visual Studio/Azure CLI ; pour la CI, accordez au principal de service de build les droits Reader/Contributor selon les besoins.

npm (JavaScript/TypeScript)

Paquets scopés (Scoped packages) : publiez les paquets internes sous une portée (scope) d’organisation, par ex., @fabrikam/button. Les portées correspondent naturellement aux autorisations de flux et permettent de restreindre la consommation entre projets.
.npmrc : définissez registry=https://pkgs.dev.azure.com/ORG/PROJECT/_packaging/FEED/npm/registry/, always-auth=true, et éventuellement @scope:registry=... pour les configurations multi-registres. En CI, utilisez la tâche npm Authenticate pour injecter un jeton d’authentification temporaire. En local, npm login avec un PAT.
Registre privé : Azure Artifacts agit comme un registre npm privé avec une source amont vers npmjs.com. Consommez uniquement depuis la vue release pour bloquer les pré-versions non approuvées.

Maven et Gradle (Java/Kotlin)

Publication (Maven) : définissez distributionManagement dans pom.xml pointant vers votre flux et une entrée server dans settings.xml avec les informations d’identification (PAT ou connexion de service). Utilisez mvn deploy ou la tâche Maven dans Azure Pipelines.
Publication (Gradle) : appliquez le plugin maven-publish et configurez repositories { maven { url = "https://pkgs.dev.azure.com/..." credentials { } } } puis publiez avec gradle publish.
Résolution de dépendances : ajoutez le point de terminaison de votre flux (éventuellement avec un suffixe de vue) aux repositories dans Gradle ou aux repositories dans pom.xml pour Maven. Adoptez SNAPSHOT pour les builds de développement et promouvez les versions release vers la vue release pour les consommateurs stables.

Paquets universels (blobs binaires, scripts, modèles)

Versionnement : suivez un style SemVer ou des versions entières ; chaque publication est immuable. Utilisez-les pour les artefacts qui ne correspondent pas aux écosystèmes spécifiques à un langage.
Tâches de publication/téléchargement : utilisez les tâches Azure DevOps Universal Publish et Universal Download dans les pipelines, ou l’Azure CLI (az artifacts universal publish/download). Authentifiez-vous via une connexion de service Azure DevOps ou une identité connectée.
Cas d’utilisation : CLI partagés, modules IaC, données de test, modèles ML, ou ressources inter-langages où vous avez besoin de RBAC, de rétention et de promotion, mais sans outillage spécifique au langage.

Contrôles de sécurité et de conformité

L’analyse des vulnérabilités doit être appliquée au moment du commit et de la compilation. Intégrez des outils qui identifient les dépendances connues comme vulnérables et fournissent des conseils de mise à niveau. Dans de nombreux environnements Azure DevOps, SonarQube est utilisé dans le cadre de la stratégie de quality gate pour signaler les problèmes, y compris des règles qui révèlent les risques liés aux dépendances ; vous pouvez le compléter avec des outils SCA dédiés (par ex., Snyk, Mend/WhiteSource ou Black Duck) pour une couverture CVE plus exhaustive à travers les écosystèmes. Pour .NET,

undefined

et pour npm,

undefined

peuvent fournir des signaux supplémentaires ; pour Java, OWASP Dependency-Check peut être ajouté comme étape de build.

La conformité des licences est assurée en analysant les SBOM ou les manifestes par rapport à une liste blanche (allowlist) de licences approuvées. Black Duck est couramment ajouté aux Azure Pipelines pour bloquer les builds lorsque des licences restreintes sont détectées. Stockez les rapports d’analyse en tant qu’artefacts de pipeline et joignez-les aux releases pour l’auditabilité.

Les paquets autorisés/bloqués sont mieux implémentés en tant que politique plutôt que par des exceptions ad hoc :

Restreignez les consommateurs à la vue de release ; ne promouvez que les versions validées.
Désactivez les nouveaux téléchargements upstream lorsque vous avez besoin d’un gel (freeze), en vous assurant que seules les versions mises en cache sont disponibles.
Utilisez les scopes npm et les permissions par flux (feed) pour restreindre les espaces de noms.
Ajoutez des vérifications de pipeline pour faire échouer les builds sur les paquets ou licences non autorisés, et utilisez la promotion d’artefacts comme flux de travail d’approbation.

L’audit et la gouvernance bénéficient de flux centralisés avec une mise en cache upstream : vous obtenez un point de contrôle unique pour l’entrée des paquets, des historiques immuables et une provenance cohérente pour la génération de SBOM.

Automatisation du versionnage et économie de la rétention

Le versionnage sémantique est plus facile à maintenir avec l’automatisation :

GitVersion lit votre historique Git et vos conventions de nommage de branches pour calculer les versions de manière prévisible (par ex., main produit 1.4.0, feature/* produit 1.5.0-feature.3). Configurez le mode (Mainline ou Continuous Delivery), les étiquettes de pré-release et les sources de tags. Injectez la version calculée dans

undefined

ou la propriété version de Gradle avant l’empaquetage (packing).

L’incrémentation automatique de version peut suivre la sémantique des commits ou les étiquettes de PR. Par exemple, chore n’incrémente pas, feat incrémente la version mineure, fix incrémente le patch ; breaking-change incrémente la version majeure. Utilisez une étape de pipeline pour définir

undefined

et passer la version aux tâches

undefined

Les étiquettes de pré-release doivent refléter l’intention de la branche (par ex., -alpha sur les branches de fonctionnalité, -rc sur les branches de release). Publiez les pré-releases dans la vue de pré-release et promouvez-les vers la vue de release après une mise en staging réussie.

La rétention et la gestion des coûts de stockage nécessitent une politique proactive :

Nettoyage automatique : configurez la rétention par flux pour supprimer les versions plus anciennes et non promues après N jours/versions. Prolongez les périodes pour les bibliothèques critiques ayant des horizons de support longs.
Épinglage (Pinning) : épinglez explicitement les versions qui sont intégrées dans des produits à longue durée de vie ou des instantanés de conformité pour les exclure de la suppression.
Optimisation du stockage : préférez la mise en cache upstream à la publication locale de doublons de paquets publics, et consolidez les flux lorsque cela est possible pour réduire la surcharge. Surveillez la croissance du stockage des flux et ajustez périodiquement les seuils de politique.

Spécificités des sources upstream :

NuGet : connectez-vous à

undefined

en tant que source upstream pour utiliser comme proxy et mettre en cache les paquets de NuGet.org.

npm : connectez-vous à

undefined

pour mettre en cache les dépendances de npmjs.com derrière votre flux authentifié.

Maven : connectez-vous à Maven Central (par ex.,

undefined

) afin que les consommateurs de l’entreprise récupèrent les dépendances via votre flux avec une seule URL.

### Scénario pratique

Adobe doit standardiser la gouvernance des paquets sur plusieurs clouds et langages tout en réduisant les pannes dues à l’instabilité des registres publics et en appliquant les politiques de licence. Les équipes publient des artefacts internes NuGet, npm et Maven et partagent de gros outils CLI multi-langages.

Établir des flux centralisés et des sources amont (upstreams)

Action : Créer trois flux Azure Artifacts : « oss-upstream » (avec des sources amont vers NuGet.org, npmjs.com, Maven Central), « shared-libs » (bibliothèques internes) et « productA » (paquets au niveau de l’application). Activer les vues (local, prerelease, release) sur tous les flux.
Justification : « oss-upstream » devient le point unique d’entrée et de mise en cache ; « shared-libs » et « productA » séparent les périmètres de confiance et les workflows de promotion.

Configurer la consommation client via les vues

Action : Pointer les fichiers nuget.config, .npmrc, et les dépôts dans settings.xml/Gradle vers la vue release de chaque flux pour les consommateurs d’exécution, et vers prerelease pour les pipelines de tests d’intégration.
Justification : Les vues garantissent que seuls les paquets promus et validés atteignent les consommateurs en production sans modifier les configurations client.

Implémenter la publication avec le versionnement sémantique

Action : Ajouter GitVersion à la CI pour les bibliothèques et les applications. Piloter l’injection de version dans dotnet pack, npm version (sans tag Git, contrôlé par le pipeline), et les champs de version de Gradle/Maven. Publier sur local ; promouvoir vers prerelease après une CI réussie ; promouvoir automatiquement vers release après les tests de pré-production (staging).
Justification : Un versionnement déterministe aligné sur le flux Git assure la cohérence des étiquettes de pré-version et des promotions prêtes pour l’automatisation.

Sécuriser les flux authentifiés et l’expérience développeur

Action : Utiliser les tâches NuGet Authenticate et npm Authenticate dans les pipelines ; activer le Azure Artifacts Credential Provider pour les postes des développeurs ; configurer les serveurs dans le fichier settings.xml de Maven avec des PATs dont la rotation est gérée via les groupes de variables Azure DevOps.
Justification : Une authentification transparente basée sur des jetons (tokens) évite la prolifération des informations d’identification et prend en charge les restaurations non interactives en CI.

Appliquer la politique de vulnérabilité et de licence

Action : Ajouter des quality gates SonarQube aux builds ; intégrer Black Duck pour appliquer des listes blanches de licences et bloquer les builds contenant des licences non autorisées ou des CVE de haute sévérité. Pour npm et .NET, exécuter npm audit et dotnet list package --vulnerable ; publier les SBOMs en tant qu’artefacts de build.
Justification : Plusieurs scanners complémentaires réduisent les angles morts ; Black Duck fournit une conformité de licence à grande échelle, tandis que SonarQube et les outils de l’écosystème détectent tôt les régressions de sécurité.

Contrôler l’entrée (ingress) et geler en cas de besoin

Action : Autoriser les téléchargements amont uniquement depuis « oss-upstream » ; désactiver les nouvelles entrées amont lors d’une réponse à incident pour geler l’approvisionnement. S’appuyer sur les paquets en cache pour maintenir les builds.
Justification : Un point de contrôle unique (choke point) permet un confinement rapide si un registre public est compromis ou instable.

Appliquer la rétention et l’épinglage (pinning)

Action : Conserver les 5 dernières versions pour shared-libs et productA ; supprimer les versions non promues de plus de 30 jours ; épingler les versions liées aux branches LTS et aux bases de référence réglementaires.
Justification : Le nettoyage automatisé réduit les coûts de stockage tandis que l’épinglage préserve l’auditabilité et la capacité de retour en arrière (rollback).

Déléguer l’accès avec le moindre privilège

Action : Assigner le rôle Owners à l’ingénierie plateforme ; Contributors aux mainteneurs de bibliothèques qui doivent publier/déprécier ; Readers aux équipes produit qui ne consomment que les artefacts de release.
Justification : Aligne les capacités sur les responsabilités ; les développeurs peuvent déréférencer/déprécier sans droits administratifs étendus.

Universal packages pour les outils multi-langages

Action : Publier les CLI internes et les modules IaC en tant que Universal packages via les tâches Universal Publish/Download ; les versionner sémantiquement et les promouvoir via les vues.
Justification : Fournit le RBAC, la rétention et la promotion pour les actifs non spécifiques à un langage avec un modèle de consommation cohérent.

Mesurer et itérer

Action : Suivre le stockage des flux, les taux de réussite du cache (cache hit rates) et les délais de promotion ; ajuster les seuils de rétention, les politiques amont et les critères de promotion en conséquence.
Justification : L’ajustement continu maintient la fiabilité, la rentabilité et la conformité à mesure que l’échelle du portefeuille évolue.

← Surveillance · Tous les domaines · Planification Agile et gestion du travail →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →