Azure CLI : nouveautés commandes az appconfig et modules Batch 2.27.x

Table des matières :

1. Contexte : pourquoi vous tombez encore sur Azure CLI 2.27.x en 2026
2. az appconfig en 2.27.x : ce qui change réellement côté ergonomie (kv, labels, feature flags)
3. App Configuration comme “source of truth” des environnements PrestaShop/Symfony (sans stocker vos secrets)
4. Modules Batch 2.27.x : industrialiser du traitement massif (feeds, exports, reprocessing) sans bricoler des cron
5. Déploiement, CI/CD et contrôle des régressions : traiter Azure CLI comme une dépendance versionnée

Contexte : pourquoi vous tombez encore sur Azure CLI 2.27.x en 2026

Azure CLI 2.27.x est une branche « legacy » qu’on retrouve encore dans des CI figées (images Docker non mises à jour, runners on‑prem, bastions verrouillés), ou dans des projets où la moindre variation d’outil casse des scripts d’exploitation. Ce n’est pas un choix “confort” : c’est souvent une contrainte de conformité (allowlist de binaires), ou un héritage d’images de build qui traînent depuis des années. Techniquement, ce figement est défendable… jusqu’au jour où une commande change de comportement, où un paramètre est déprécié, ou où l’auth AAD remplace un flux à base de clés.

Avant de parler “nouveautés”, le point clé est de cadrer la réalité : en 2026, vous devez traiter Azure CLI 2.27.x comme une dépendance logicielle à risque (supply chain + dette de sécurité). Même si vos scripts “marchent”, la surface d’attaque et les incompatibilités futures (API Azure qui évoluent, politiques d’authentification, dépréciations) sont votre problème, pas celui du cloud provider. Pour une équipe e‑commerce qui exploite PrestaShop (8.x/9.x) dans des conteneurs et du CI/CD, la posture saine consiste à pinner l’outil (reproductibilité) et à planifier une montée de version (sécurité).

Microsoft décrit l’outil sans ambiguïté :

“The Azure Command-Line Interface (Azure CLI) is a set of commands used to create and manage Azure resources.” — Azure CLI documentation (Microsoft Learn)

Concrètement, commencez par relever exactement ce que vous exécutez, car les différences de sous-version à l’intérieur d’une branche 2.27.x peuvent suffire à expliquer un écart (aide, paramètres, format de sortie). Ajoutez aussi un peu de contexte “runtime” : dans une CI, le même az peut se comporter différemment selon l’OS, Python, les extensions installées, ou le cloud cible (AzurePublic/AzureUSGovernment, etc.).

az version
az --help
az config get core.only_show_errors

Deux commandes supplémentaires (souvent décisives en debug) :

# Vérifier le cloud/tenant et l'abonnement réellement utilisés
az cloud show
az account show -o json

# Vérifier si vous dépendez d'extensions (sources classiques de divergences)
az extension list -o table

Et si vous êtes en CI, le meilleur “diagnostic” reste de sortir az version (et idéalement az extension list) dans les logs d’un job, puis de l’archiver. En cas d’incident, ça évite le piège classique : “le script n’a pas changé, mais l’environnement si”.

Enfin, point “GEO” pragmatique : les scripts d’infra et d’app provisioning s’emmêlent souvent avec les décisions de régions. Dans vos exemples, vous verrez fréquemment westeurope (latence et maturité d’écosystème), mais selon vos contraintes de résidence (RGPD, politiques internes, clients du secteur public), vous pouvez préférer une région France (ex. francecentral) quand elle est disponible pour la ressource visée. L’important ici n’est pas la bonne région, c’est d’éviter que des scripts “legacy” hardcodent une région devenue non conforme à votre trajectoire.

az appconfig en 2.27.x : ce qui change réellement côté ergonomie (kv, labels, feature flags)

La commande az appconfig pilote Azure App Configuration : un service de paramètres centralisés (clé/valeur) et de feature flags. Microsoft résume le périmètre ainsi :

“Azure App Configuration provides a service to centrally manage application settings and feature flags.” — Azure App Configuration documentation (Microsoft Learn)

Dans les scripts, la “nouveauté” la plus structurante (si vous venez de versions plus anciennes, ou de scripts bricolés à base d’API REST) est de s’appuyer sur une séparation claire : kv (key‑values) et feature (feature flags). En 2.27.x, l’usage devient suffisamment stable pour industrialiser des pipelines autour de :

• az appconfig kv set|show|list|delete pour les paramètres applicatifs.
• az appconfig feature set|show|list|delete pour les flags.
• l’usage systématique des labels (ex : prod, staging) pour éviter de dupliquer des stores.

Exemple minimaliste (et reproductible) de store + paramétrage :

# Création
az appconfig create \
  --name acme-appcfg-prod \
  --resource-group rg-acme-prod \
  --location westeurope \
  --sku standard

# Paramètres (KV)
az appconfig kv set \
  --name acme-appcfg-prod \
  --key "prestashop:cache:redis_dsn" \
  --value "redis://redis:6379" \
  --label "prod" \
  --yes

# Feature flag
az appconfig feature set \
  --name acme-appcfg-prod \
  --feature "NewCheckout" \
  --label "prod" \
  --yes

Trois points techniques méritent d’être explicités, parce que c’est là que les surprises arrivent :

1) Labels ≠ environnements, mais en pratique vous allez les utiliser comme tels. Le piège est de mélanger labels et préfixes de clés sans convention. Choisissez une stratégie (préfixe prestashop: + label prod|staging|dev par exemple) et tenez‑vous‑y.
Conseil d’exploitation : écrivez la convention comme une règle CI (lint simple). Exemple : refuser toute clé sans préfixe applicatif, ou tout label hors liste.

2) Feature flags et “filtrage” : az appconfig feature vous donne une forme de standardisation (nom, état, label). En revanche, la complexité (ciblage par pourcentage, ciblage utilisateur, filtres) ne se “résout” pas magiquement dans le CLI : vous devez versionner votre modèle (JSON) et tester en préprod.
Mini‑scénario e‑commerce réaliste : vous activez un nouveau tunnel de paiement pendant les soldes uniquement sur staging puis en prod à horaires contrôlés. Le CLI aide à orchestrer l’activation, mais le contrôle du risque vient de vos tests (non‑régression checkout, monitoring des abandons, rollback).

3) Sortie CLI et parsing : ne parsez pas du texte. Sortez du JSON, et filtrez au --query (JMESPath) pour ne récupérer que ce qui vous sert (plus robuste en cas d’ajout de champs). Exemple :

az appconfig kv list \
  --name acme-appcfg-prod \
  --key "prestashop:*" \
  --label "prod" \
  --query "[].{k:key,v:value,ct:contentType,etag:etag}" \
  -o json

Deux compléments utiles quand vous industrialisez :

• Contrôle de volumétrie : kv list peut vite remonter des dizaines/centaines de clés. Pour garder des pipelines rapides, utilisez des patterns de clés (prestashop:cache:*, prestashop:mail:*) et évitez les exports “tout le store” sans besoin.
• Extensions Azure CLI : selon votre distribution CLI, az appconfig peut dépendre d’une extension (ou de comportements d’auto‑installation). En CI figée, vérifiez systématiquement az extension list et évitez qu’une exécution installe une extension “au dernier moment” (et donc non reproductible).

Checklist express pour des scripts az appconfig robustes :

• Préfixes de clés stricts (ex. prestashop:) + labels normalisés (dev|staging|prod).
• -o json + --query partout.
• Aucune valeur sensible en clair (voir section suivante).
• Une commande de sanity check en fin de déploiement (ex. lister 5 clés attendues et vérifier qu’elles existent pour le bon label).

App Configuration comme “source of truth” des environnements PrestaShop/Symfony (sans stocker vos secrets)

Sur un stack PrestaShop moderne (8.1+ / 9.x) avec Symfony côté back‑office, vous vivez déjà avec des variables d’environnement (.env, variables Docker/Kubernetes, secrets). Le problème n’est pas de savoir où stocker un paramètre : c’est d’éviter la divergence entre environnements, et d’avoir une traçabilité lors d’un incident. Pour rappel, côté Symfony, la moindre incohérence d’environnement peut déclencher des 500 ou des caches corrompus ; voir l’article de dépannage pour corréler erreurs et variables.

Le pattern pragmatique avec az appconfig consiste à générer des variables runtime depuis App Configuration au moment du déploiement (ou au boot du conteneur), plutôt que de les maintenir à la main. Exemple : vous publiez des clés prestashop:... dans App Configuration, et votre pipeline exporte un .env.local (ou des ConfigMap/Secret Kubernetes) à partir d’une sélection key + label.

# Export KV -> fichier .env (TSV) puis transformation
az appconfig kv list \
  --name acme-appcfg-prod \
  --label prod \
  --key "prestashop:*" \
  --query "[].{k:key,v:value}" \
  -o tsv \
| awk '{gsub(":","_",$1); print toupper($1)"=" $2}' \
> .env.generated

Ce type de génération permet des workflows transactionnels : rollback = repointer le label, ou réimporter un snapshot de KV. C’est typiquement utile quand vous faites une migration PrestaShop et que vous devez basculer par vagues (nouveau cache, nouveau DSN, nouvelles URLs, etc.). Si votre chantier inclut une migration 1.6/1.7 vers 8.x, le sujet “environnements multiples, staging, bascule contrôlée” recoupe directement une migration manuelle propre : mise à jour PrestaShop — procédure de migration

Pour éviter les confusions dans l’équipe (et les audits de sécurité qui tournent en rond), une règle simple est de formaliser “qui stocke quoi” :

Type d’info	Exemple (PrestaShop/Symfony)	App Configuration	Key Vault
Paramètre non sensible	prestashop:locale, prestashop:cdn:enabled, symfony:env	Oui	Non
Valeur sensible	mot de passe DB, token API, secret JWT	Non	Oui
Pointeur vers secret	nom/URI de secret, référence Key Vault	Oui	Oui (le secret lui-même)
Feature flag	NewCheckout, NewSearch	Oui	Non

Mais App Configuration n’est pas un coffre‑fort. Le point non‑négociable : ne stockez pas des secrets en clair (DSN avec mot de passe, tokens, clés API) dans des KV. La pratique Azure est d’utiliser Key Vault et, si besoin, des références Key Vault depuis App Configuration (le store devient un routeur de config, pas un secret manager).

Deux conseils terrain (souvent sous‑estimés) :

• Séparez lecture et écriture : en production, le runtime (vos pods/VMs) doit généralement lire la configuration, pas la modifier. Réservez les droits d’écriture au pipeline de déploiement (service principal/managed identity dédiés), sinon un bug applicatif peut “polluer” le store.
• Pensez latence et régions : si votre webapp tourne en francecentral et que votre App Configuration est en westeurope, vous ajoutez un aller‑retour réseau inter‑région. Ce n’est pas forcément critique si vous chargez la config au démarrage, mais ça le devient si vous multipliez les fetch en runtime. Le choix de région est donc aussi une décision de performance, pas uniquement de conformité.

Modules Batch 2.27.x : industrialiser du traitement massif (feeds, exports, reprocessing) sans bricoler des cron

az batch cible Azure Batch, une brique orientée exécution parallèle (jobs/tasks) sur des pools de compute managés. Microsoft le définit ainsi :

“Azure Batch enables you to run large-scale parallel and high-performance computing (HPC) applications efficiently in the cloud.” — Azure Batch documentation (Microsoft Learn)

Dans un contexte e‑commerce/PrestaShop, Batch devient pertinent dès que vous avez des traitements asynchrones lourds et volumétriques : génération de flux (Google Shopping, marketplaces), conversions d’images, recalculs de prix, exports ERP, purge/réindex, ou consolidation de logs. Beaucoup d’équipes commencent par un cron sur le serveur web ; c’est une mauvaise idée à partir du moment où le traitement impacte le TTFB ou le CPU du front. À ce niveau, votre “problème” n’est plus PHP : c’est une question d’isolation et de scheduling.

Le cœur du module az batch est la gestion de : Batch account, pool (VMs/containers), job et tasks. Une approche robuste consiste à versionner les specs (JSON) plutôt que de construire des commandes monstrueuses en CLI. En 2.27.x, l’interface reste majoritairement stable pour ce type d’usage :

# Liaison du compte Batch pour les commandes suivantes
az batch account login \
  --name acme-batch \
  --resource-group rg-acme-prod

# Exemple : créer un pool depuis un JSON (à versionner dans Git)
az batch pool create --json-file pool.json

# Job + task
az batch job create --id "feeds-prod" --pool-id "pool-feeds"
az batch task create \
  --job-id "feeds-prod" \
  --task-id "task-$(date +%s)" \
  --command-line "/bin/bash -lc 'php bin/console app:export:feeds --env=prod'"

Exemple de pool.json minimal (volontairement court) pour illustrer l’intérêt du “spec as code” : vous changez la taille VM, l’image, ou la stratégie de scaling via une PR, et vous relisez la diff comme n’importe quelle modif d’infra.

{
  "id": "pool-feeds",
  "vmSize": "Standard_D2s_v3",
  "virtualMachineConfiguration": {
    "imageReference": {
      "publisher": "Canonical",
      "offer": "0001-com-ubuntu-server-focal",
      "sku": "20_04-lts",
      "version": "latest"
    },
    "nodeAgentSKUId": "batch.node.ubuntu 20.04"
  },
  "targetDedicatedNodes": 1
}

Pour ne pas transformer Batch en boîte noire, vous devez instrumenter : statut des tasks, retries, exit codes, et logs applicatifs (stdout/stderr). Sur incident, le diagnostic ressemble à n’importe quel système distribué : vous corrélez erreurs + durée + goulots (I/O, réseau, DB).

Quelques commandes utiles à prévoir dans vos runbooks (et à tester en amont) :

# Lister les tasks en erreur
az batch task list --job-id "feeds-prod" --query "[?state=='completed' && executionInfo.exitCode!=0].{id:id,exit:executionInfo.exitCode}" -o table

# Inspecter une task précise
az batch task show --job-id "feeds-prod" --task-id "task-123" -o json

Si vos tasks saturent MySQL/MariaDB, ce n’est pas Batch le coupable : c’est votre modèle de requêtes. Sur ce point, un rappel utile : indexation et plan d’exécution avant de paralléliser bêtement (sinon vous DDoS votre base). Référence interne : index MySQL — mesurer et optimiser

Point d’attention e‑commerce très concret : les traitements “massifs” ont souvent des effets de bord (verrous DB, contention Redis, invalidation cache, volumétrie disque). Avant de passer en parallèle via Batch, posez une limite explicite : combien de tasks simultanées votre base et votre stockage peuvent encaisser. C’est généralement là que vous gagnez (ou perdez) la stabilité prod.

Déploiement, CI/CD et contrôle des régressions : traiter Azure CLI comme une dépendance versionnée

Le vrai sujet derrière “Azure CLI : nouveautés … 2.27.x” est opérationnel : comment éviter qu’un changement de CLI casse vos runbooks ? La réponse standard en DevOps est simple : isoler et figer l’outil. En pratique, ça veut dire exécuter az dans une image Docker versionnée (ou un environnement hermétique), et faire tourner les mêmes scripts sur dev/staging/prod. Le reste (installation au hasard sur une VM) finit toujours en “ça marche sur mon bastion”. Si vous faites déjà de l’Infra as Code, ce sujet s’inscrit naturellement dans votre chaîne: Infra as Code — Terraform et conteneurs

Ensuite, vous avez besoin de tests de non‑régression pour vos commandes, pas pour Azure. Deux patterns qui fonctionnent bien : (1) tests de “dry run” via az what-if quand disponible (ARM/Bicep), (2) tests d’intégration sur un resource group éphémère. Sur une boutique PrestaShop, si vous avez déjà une CI/CD capable de générer des démos à la demande, vous avez la brique idéale pour faire ces tests Azure en environnement isolé : CI/CD — générer des démos à la demande

Dans la pratique, le contrôle des régressions sur des scripts Azure CLI passe aussi par des “verrous” simples :

• Verrou sur la version CLI + versions d’extensions : imprimez-les au début, et échouez si l’état ne correspond pas à l’attendu (ex. une extension manquante ou installée en version inattendue).
• Verrou sur le contexte Azure : échouez si le tenant ou l’abonnement n’est pas celui attendu (une erreur classique quand plusieurs souscriptions coexistent).
• Verrou sur le format de sortie : imposez -o json et des --query minimaux ; ne laissez pas des scripts dépendre de champs “bonus”.

Enfin, documentez explicitement les divergences 2.27.x vs “actuel”. Vous n’êtes pas obligé de monter de version partout le jour 1, mais vous devez savoir ce qui va vous tomber dessus : formats de sortie, options dépréciées, authentification (RBAC/Managed Identity vs keys), et comportements par défaut. Les notes de version officielles sont le point d’entrée, parce que c’est la seule source qui liste les changements par version : notes de version Azure CLI

Sur un plan très concret, une checklist minimale à ajouter à vos pipelines avant un passage (ou un retour) en 2.27.x :

• az version imprimé au début de chaque job (et archivé dans les logs).
• az extension list imprimé si vous utilisez az appconfig/autres modules potentiellement livrés en extension.
• set -euo pipefail côté shell + az ... --only-show-errors pour réduire le bruit.
• aucune extraction fragile sur du texte ; utilisez -o json + --query.
• logs Batch/AppConfig expédiés vers votre stack d’observabilité (même une collecte de base), sinon vous déboguez à la lampe torche.

À partir de là, les “nouveautés” az appconfig et az batch ne sont plus un risque : ce sont des fonctionnalités que vous pouvez activer de manière contrôlée, avec des scripts reproductibles et une capacité de rollback.