Monter un pipeline CI/CD fiable reste l’un des chantiers les plus demandés par les équipes cloud en France et en Europe. Azure DevOps continue d’occuper une place à part dans ce paysage, même si Microsoft pousse activement ses clients vers GitHub pour l’hébergement de code. En pratique, des milliers d’équipes gardent Azure Pipelines pour orchestrer leurs builds et leurs déploiements vers Azure Kubernetes Service (AKS), notamment dans les organisations qui ont déjà investi dans l’écosystème Azure DevOps pour la gestion de projet, les tests et la traçabilité. Ce tutoriel vous guide pas à pas pour construire un pipeline complet : du dépôt Git jusqu’au déploiement sur un cluster AKS, en passant par la construction d’une image Docker et sa publication sur Azure Container Registry (ACR). Comptez environ 75 minutes si vous suivez les 13 étapes dans l’ordre, avec un abonnement Azure actif et un peu de patience pour les premières exécutions.

Ce guide s’adresse aux équipes qui déploient déjà une application conteneurisée, ou qui veulent migrer un déploiement manuel vers un flux automatisé. Vous n’avez pas besoin d’être expert Kubernetes pour suivre les étapes : chaque commande est expliquée, et les pièges les plus fréquents sont listés à part pour que vous puissiez les repérer avant qu’ils ne cassent votre premier déploiement. À la fin, vous aurez un pipeline capable de construire une image à chaque push sur la branche principale, de la publier sur un registre privé, puis de la déployer automatiquement sur un cluster AKS, avec une option d’approbation manuelle avant la mise en production.

Pourquoi Azure DevOps reste incontournable pour le CI/CD en 2026

Azure DevOps a beaucoup évolué ces derniers mois. Le Sprint 275, publié le 17 juin 2026, a introduit plusieurs changements qui touchent directement la façon dont on écrit et sécurise un pipeline. La fonctionnalité la plus visible est l’arrivée, en préversion publique limitée, de Copilot Autofix pour GitHub Advanced Security sur Azure DevOps : les alertes de scan de code s’accompagnent désormais de suggestions de correction automatisées. Le déploiement du CodeQL default setup s’est également terminé sur cette même version, ce qui simplifie l’activation de l’analyse statique sans configuration manuelle. Les vérifications de statut liées à la sécurité avancée sur les pull requests sont, elles, passées en disponibilité générale (GA) à la même date.

Deuxième changement structurant : les service connections peuvent désormais s’appuyer sur les identités de charge de travail Microsoft Entra (workload identity), avec un principal de service ou une identité managée, plutôt que sur des jetons d’accès personnels (PAT). Cette option, aussi livrée en juin 2026, réduit un risque de sécurité classique : les PAT qui traînent dans des groupes de variables ou des scripts. Autre nouveauté à surveiller pour les équipes qui construisent des images multi-plateformes : des agents macOS sur puce Apple Silicon sont disponibles en préversion payante à l’usage. Sur la feuille de route du troisième trimestre 2026 figurent aussi des agents hébergés de plus grande taille et une traçabilité au niveau des stages de déploiement, deux points utiles pour des pipelines qui construisent des images lourdes ou déploient vers plusieurs environnements.

Microsoft communique en parallèle sur des migrations de dépôts Azure DevOps vers GitHub, un mouvement documenté sur son propre blog début juin 2026. Cela ne signifie pas qu’Azure Pipelines disparaît : la brique de build et de déploiement continue de fonctionner avec des dépôts GitHub ou Azure Repos, et reste la solution la plus intégrée pour les organisations qui déploient sur Azure. C’est justement l’angle de ce guide : construire un pipeline YAML moderne, avec les pratiques de sécurité de 2026, qui pousse une application conteneurisée vers AKS.

Pour les équipes basées en France ou ailleurs en Europe, ce choix a aussi une dimension réglementaire. Héberger son code et ses pipelines dans une organisation Azure DevOps rattachée à une région européenne, et déployer vers un cluster AKS situé en France Central ou en West Europe, simplifie les discussions autour de la localisation des données avec un service juridique ou un responsable conformité. Ce n’est pas une garantie automatique de conformité RGPD, mais cela réduit le nombre de questions à traiter par rapport à une chaîne d’outils répartie sur plusieurs continents.

Prérequis techniques : ce qu’il vous faut avant de commencer

Avant de créer le moindre pipeline, réunissez les éléments suivants. Rien d’exotique, mais un prérequis manquant fait perdre du temps en plein milieu du tutoriel, en général au pire moment, juste avant une démonstration à l’équipe.

Outil ou compteVersion recommandéeUsage dans ce tutoriel
Compte Azure DevOpsOrganisation gratuite (5 utilisateurs inclus)Héberge le projet, le dépôt et les pipelines
Abonnement AzureActif, rôle Contributeur ou PropriétaireProvisionne ACR, AKS et le groupe de ressources
Azure CLIDernière version stableCréation des ressources Azure en ligne de commande
kubectlVersion alignée sur celle du cluster AKSVérification et débogage des déploiements Kubernetes
Docker Engine ou Docker DesktopDernière versionConstruction et test local de l’image applicative
GitDernière versionClonage du dépôt et gestion des branches

Un dernier point avant de vous lancer : gardez un onglet ouvert sur le tarif officiel d’Azure DevOps Services et sur la documentation AKS, deux pages que vous consulterez plusieurs fois pendant ce guide. Vérifiez aussi, avant de commencer, que votre abonnement Azure a bien accès aux quotas de calcul nécessaires dans la région visée : un abonnement d’essai fraîchement créé refuse parfois la création d’un cluster à plusieurs nœuds tant qu’une augmentation de quota n’a pas été demandée manuellement.

Comprendre l’architecture du pipeline avant de coder

Le pipeline que vous allez construire suit un flux linéaire en quatre temps. D’abord, un développeur pousse du code sur une branche du dépôt Azure Repos (ou GitHub, si vous préférez garder votre code là-bas). Ensuite, le déclencheur CI démarre une étape de build : restauration des dépendances, tests unitaires, puis construction de l’image Docker. Cette image part vers Azure Container Registry, votre registre privé. Enfin, une étape de déploiement applique un manifeste Kubernetes sur le cluster AKS, avec une nouvelle version de l’image.

Ce tutoriel simplifie volontairement l’étape de tests pour rester concentré sur la partie déploiement. Dans un pipeline de production, ajoutez un job dédié aux tests unitaires avant le job de build Docker, avec une condition qui empêche la construction de l’image si les tests échouent. C’est un ajout de quelques lignes YAML une fois la structure de base en place, et il évite de publier une image cassée sur le registre.

Ce découpage en stages (build, publish, deploy) correspond directement à la structure d’un fichier azure-pipelines.yml. Chaque stage peut tourner sur un agent différent, avec ses propres conditions de déclenchement. C’est ce qui permet, par exemple, de ne déployer en production qu’après une approbation manuelle sur l’environnement cible, une pratique que nous verrons dans la section sur les astuces avancées.

Pour une équipe qui gère plusieurs environnements, rien n’empêche de dupliquer le stage Deploy avec un nom différent (DeployStaging, DeployProduction) et des conditions de déclenchement distinctes. Le stage de staging peut se lancer automatiquement à chaque fusion sur main, tandis que le stage de production attend une approbation manuelle. Ce tutoriel se limite volontairement à un seul environnement pour rester lisible, mais la structure YAML que vous allez écrire s’étend facilement une fois les bases comprises.

Étape 1 à 3 : créer l’organisation, le projet et le dépôt Azure DevOps

Étape 1. Rendez-vous sur dev.azure.com et créez une organisation si vous n’en avez pas déjà une. Choisissez une région proche de vos utilisateurs (Europe de l’Ouest fonctionne bien pour la France).

Étape 2. Dans cette organisation, créez un nouveau projet. Donnez-lui un nom explicite (par exemple demo-aks-pipeline) et choisissez la visibilité privée sauf besoin spécifique de rendre le projet public.

Étape 3. Clonez le dépôt Git généré automatiquement par le projet, ou connectez un dépôt GitHub existant depuis l’onglet Repos. Voici comment initialiser un dépôt local et pousser un premier commit :

git clone https://dev.azure.com/VOTRE_ORG/demo-aks-pipeline/_git/demo-aks-pipeline
cd demo-aks-pipeline
echo "# Demo AKS Pipeline" > README.md
git add README.md
git commit -m "Premier commit"
git push origin main

À ce stade, vous avez un projet vide mais fonctionnel. La suite consiste à provisionner l’infrastructure Azure qui va recevoir vos déploiements.

Étape 4 à 6 : provisionner Azure Container Registry et le cluster AKS

Option A : réutiliser un cluster AKS existant

Si vous avez déjà un cluster AKS de test, passez directement à l’étape 6 (attachement d’ACR) et récupérez simplement ses identifiants avec az aks get-credentials.

Option B : créer un nouveau cluster AKS

Étape 4. Créez un groupe de ressources et un registre Azure Container Registry :

az login
az group create --name rg-demo-aks --location francecentral

az acr create --resource-group rg-demo-aks \
  --name demoaksacr$RANDOM \
  --sku Basic

Étape 5. Créez le cluster AKS dans le même groupe de ressources, en activant l’intégration avec ACR :

az aks create --resource-group rg-demo-aks \
  --name demo-aks-cluster \
  --node-count 2 \
  --enable-managed-identity \
  --generate-ssh-keys \
  --attach-acr demoaksacr$RANDOM

Étape 6. Récupérez les identifiants du cluster pour vérifier que tout fonctionne depuis votre poste :

az aks get-credentials --resource-group rg-demo-aks --name demo-aks-cluster
kubectl get nodes

Si la commande kubectl get nodes affiche vos nœuds avec un statut Ready, l’infrastructure est prête. Passez à l’écriture du pipeline.

Étape 7 à 9 : écrire le Dockerfile et le pipeline YAML de build

Étape 7. Ajoutez un Dockerfile minimal à la racine du dépôt. Adaptez-le à votre application, l’exemple ci-dessous convient pour une petite API Node.js :

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Étape 8. Créez un fichier azure-pipelines.yml à la racine du dépôt. Cette première partie gère le déclencheur, la construction et la publication de l’image sur ACR :

trigger:
  branches:
    include:
      - main

pool:
  vmImage: 'ubuntu-latest'

variables:
  acrName: 'demoaksacr'
  imageName: 'demo-app'
  imageTag: '$(Build.BuildId)'

stages:
  - stage: Build
    displayName: 'Build et publication de l image'
    jobs:
      - job: BuildAndPush
        steps:
          - task: Docker@2
            inputs:
              containerRegistry: 'demo-acr-connection'
              repository: '$(imageName)'
              command: 'buildAndPush'
              Dockerfile: '**/Dockerfile'
              tags: |
                $(imageTag)
                latest

Étape 9. Importez ce fichier dans Azure DevOps : ouvrez Pipelines, cliquez sur « Créer un pipeline », choisissez votre dépôt puis « Fichier YAML Azure Pipelines existant » et pointez vers azure-pipelines.yml. N’exécutez pas encore le pipeline, il manque une pièce essentielle : la connexion vers ACR. Si une tâche ou une propriété YAML vous semble obscure, le schéma YAML officiel d’Azure Pipelines liste l’ensemble des champs disponibles avec leurs valeurs par défaut.

Étape 10 à 11 : configurer les service connections et les secrets

Étape 10. Dans les paramètres du projet, section « Service connections », créez une nouvelle connexion de type Docker Registry, pointant vers votre registre ACR, et nommez-la demo-acr-connection (le même nom que dans le YAML). Depuis le Sprint 275, vous pouvez aussi créer une connexion Azure Resource Manager basée sur l’identité de charge de travail Microsoft Entra plutôt que sur un principal de service classique avec secret, ce qui évite de stocker un mot de passe dans Azure DevOps.

Étape 11. Créez un groupe de variables (Pipelines > Library) pour centraliser les valeurs sensibles, comme le nom du cluster ou le groupe de ressources. Référencez-le en haut de votre YAML :

variables:
  - group: demo-aks-secrets
  - name: imageTag
    value: '$(Build.BuildId)'

Pour des secrets plus sensibles (clés API, chaînes de connexion), reliez ce groupe de variables à un coffre Azure Key Vault plutôt que de saisir les valeurs en clair dans Azure DevOps. L’option se trouve directement dans l’écran de création du groupe de variables.

Étape 12 à 13 : déployer vers AKS avec les stages de release

Étape 12. Ajoutez un manifeste Kubernetes dans un dossier manifests/deployment.yaml :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: demo-app
          image: demoaksacr.azurecr.io/demo-app:latest
          ports:
            - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app-service
spec:
  type: LoadBalancer
  selector:
    app: demo-app
  ports:
    - port: 80
      targetPort: 3000

Étape 13. Ajoutez un second stage au fichier azure-pipelines.yml, qui applique ce manifeste sur AKS après le build :

  - stage: Deploy
    displayName: 'Déploiement sur AKS'
    dependsOn: Build
    jobs:
      - deployment: DeployToAKS
        environment: 'production'
        pool:
          vmImage: 'ubuntu-latest'
        strategy:
          runOnce:
            deploy:
              steps:
                - task: KubernetesManifest@1
                  inputs:
                    action: 'deploy'
                    connectionType: 'azureResourceManager'
                    azureSubscriptionConnection: 'demo-azure-connection'
                    azureResourceGroup: 'rg-demo-aks'
                    kubernetesCluster: 'demo-aks-cluster'
                    manifests: 'manifests/deployment.yaml'
                    containers: 'demoaksacr.azurecr.io/demo-app:$(imageTag)'

Enregistrez, poussez le commit, puis exécutez le pipeline manuellement une première fois. Notez le stage environment: 'production' : il permet d’ajouter plus tard une approbation manuelle avant déploiement, sans toucher au reste du YAML.

Exemple de sortie : ce que vous devez voir à la fin

Si tout s’est bien passé, le journal du stage Deploy affiche une sortie proche de celle-ci :

##[section]Starting: Deploy to AKS
deployment.apps/demo-app configured
service/demo-app-service unchanged
##[section]Finishing: Deploy to AKS

$ kubectl get pods
NAME                        READY   STATUS    RESTARTS   AGE
demo-app-7d4f9c6b8d-2kxqz   1/1     Running   0          38s
demo-app-7d4f9c6b8d-x9mlp   1/1     Running   0          38s

$ kubectl get service demo-app-service
NAME                TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)
demo-app-service    LoadBalancer   10.0.112.44    20.103.xx.xx    80:31894/TCP

L’adresse IP externe met parfois deux à trois minutes à apparaître le temps que le load balancer Azure se provisionne. Si elle reste à <pending> plus de cinq minutes, direction la section dépannage plus bas.

Une fois l’IP externe attribuée, vérifiez que l’application répond réellement, et pas seulement que les pods sont marqués Running :

curl -i http://20.103.xx.xx

HTTP/1.1 200 OK
content-type: application/json

{"status":"ok","version":"demo-app"}

Une réponse 200 confirme que le trafic traverse bien le service Kubernetes jusqu’au conteneur. Si la commande curl échoue ou reste bloquée, le problème vient presque toujours du containerPort déclaré dans le manifeste, qui doit correspondre exactement au port exposé par votre application.

Coûts réels : combien coûte ce pipeline chaque mois

Azure DevOps : le coût des parallel jobs

Azure DevOps inclut un job parallèle Microsoft-hosted gratuit par organisation avec minutes illimitées. Au-delà, le tarif officiel liste un supplément de 40 $ par job Microsoft-hosted additionnel et de 15 $ par job self-hosted additionnel, toujours avec minutes illimitées. Converti en euros, cela donne environ 36,48 € par mois pour un job Microsoft-hosted supplémentaire, environ 72,96 € pour un agent macOS-hosted supplémentaire, et environ 14,58 € pour un job self-hosted additionnel, selon une analyse tarifaire publiée en juillet 2026. Ces chiffres sont des estimations basées sur les prix officiels en dollars, vérifiez le taux de change et la grille tarifaire à jour sur la page officielle Azure DevOps Services avant de budgétiser.

AKS : le coût du cluster et des nœuds

Contrairement à Amazon EKS, dont le plan de contrôle est facturé à l’heure et par cluster, AKS propose un niveau Free sans SLA garanti et un niveau Standard payant recommandé en production. Le coût principal reste celui des machines virtuelles qui composent le pool de nœuds (facturées comme n’importe quelle instance de calcul Azure), ainsi que le stockage et la bande passante sortante. Vérifiez toujours le tarif courant sur la page de tarification AKS avant de dimensionner un cluster de production, les prix varient selon la région (France Central, West Europe) et la série de machines choisie.

Sur le sujet des coûts Kubernetes, AWS applique une philosophie assez proche à Amazon EKS et la documente publiquement. Dans son guide de bonnes pratiques, AWS recommande d’abord d’« identify and eliminate waste in your environment » (identifiez et éliminez le gaspillage dans votre environnement), puis d’« architect and design for cost efficiency » (concevoir une architecture pensée pour l’efficacité des coûts). Le même document conseille de « choose the best purchasing option, e.g. on-demand instances vs Spot instances » (choisir la meilleure option d’achat, par exemple instances à la demande contre instances Spot). Ces principes s’appliquent tout aussi bien à un pool de nœuds AKS qu’à un cluster EKS : le fournisseur cloud change, la discipline FinOps reste la même.

Poste de coûtEstimationRemarque
1er job parallèle Microsoft-hostedInclusMinutes illimitées
Job Microsoft-hosted supplémentaire~36,48 €/moisEstimation basée sur 40 $ US officiels
Job macOS-hosted supplémentaire~72,96 €/moisNécessaire pour builds Apple Silicon
Job self-hosted supplémentaire~14,58 €/moisAgent installé sur votre propre VM
Nœuds AKS (pool de calcul)Variable selon la VMVérifier le tarif à jour par région
Azure Container Registry (Basic)Coût mensuel fixe modesteSuffisant pour un usage de test

Pour une petite équipe qui reste sur un job parallèle gratuit et un cluster AKS à deux nœuds de petite taille, le poste de dépense dominant reste presque toujours le calcul (les nœuds AKS), pas Azure DevOps lui-même. La facture Azure DevOps ne grimpe vraiment que lorsque l’équipe grandit et a besoin de plusieurs jobs parallèles pour paralléliser ses builds, ou d’agents macOS pour des builds multi-plateformes.

Pièges courants à éviter

La plupart des blocages rencontrés en suivant ce tutoriel viennent de six erreurs récurrentes, observées aussi bien chez des équipes qui découvrent Azure DevOps que chez des équipes qui l’utilisent depuis des années. Les repérer à l’avance évite une bonne partie des allers-retours entre le pipeline et le cluster.

  • Oublier d’attacher ACR au cluster AKS. Sans le flag --attach-acr ou une identité managée correctement configurée, AKS ne peut pas tirer les images du registre, même si la connexion Docker fonctionne côté pipeline.
  • Utiliser le tag latest comme seule référence. Kubernetes ne redéploie pas automatiquement un pod si le tag d’image ne change pas dans le manifeste. Utilisez toujours un tag unique, comme $(Build.BuildId), pour forcer un vrai déploiement.
  • Stocker des identifiants en clair dans le YAML. Passez systématiquement par une service connection ou un groupe de variables lié à Key Vault, jamais par une chaîne de connexion écrite en dur.
  • Ignorer les quotas de région. Certaines régions Azure limitent le nombre de cœurs disponibles par abonnement pour les nouveaux comptes. Une erreur de quota au moment de az aks create est fréquente sur un abonnement d’essai.
  • Ne pas définir de limites de ressources sur les pods. Sans resources.limits dans le manifeste, un pod défaillant peut consommer toute la mémoire d’un nœud et faire tomber les autres applications du cluster.
  • Confondre déclencheur CI et déclencheur de pull request. Un bloc trigger mal configuré peut lancer un déploiement en production à chaque push sur une branche de fonctionnalité, au lieu de se limiter à main.

Dépannage : 8 problèmes fréquents et leurs solutions

Même en suivant les étapes à la lettre, un premier pipeline échoue rarement du premier coup. C’est normal : entre les droits Azure, les noms de ressources et les identifiants, il y a beaucoup de pièces mobiles. Le tableau ci-dessous couvre les huit erreurs les plus fréquentes remontées par les équipes qui débutent avec un déploiement AKS depuis Azure DevOps.

SymptômeCause probableSolution
Erreur « ImagePullBackOff »ACR non attaché au cluster ou tag introuvableRéexécutez az aks update --attach-acr et vérifiez le tag poussé
Pipeline bloqué sur « En attente d’une autorisation »La ressource (service connection ou environnement) n’a pas été approuvéeOuvrez le pipeline, cliquez sur « Autoriser les ressources »
IP externe reste à <pending>Quota de Load Balancer public atteint dans la régionVérifiez les quotas réseau ou changez de région
Erreur 403 lors du push vers ACRService connection Docker mal configuréeRecréez la connexion avec les identifiants ACR actuels
Le déploiement « réussit » mais l’app ne répond pasMauvais containerPort dans le manifesteAlignez le port du conteneur avec celui exposé dans le Dockerfile
Job self-hosted introuvableAgent non enregistré ou pool mal nomméVérifiez le nom du pool dans les paramètres du projet
Erreur de quota de cœurs à la création du clusterAbonnement d’essai avec quota basDemandez une augmentation de quota ou réduisez --node-count
Groupe de variables introuvable dans le YAMLLe pipeline n’a pas les droits sur la LibraryAutorisez explicitement le pipeline à utiliser ce groupe de variables

Astuces avancées pour aller plus loin

Une fois le pipeline de base opérationnel, plusieurs options méritent d’être testées. Activez d’abord les vérifications de sécurité passées en disponibilité générale au Sprint 275 : elles bloquent une pull request tant qu’une alerte de scan de code critique n’est pas résolue, ce qui évite qu’une vulnérabilité connue atteigne la branche principale. Si votre organisation dispose de GitHub Advanced Security pour Azure DevOps, activez aussi le CodeQL default setup : la configuration se fait en quelques clics et couvre les langages les plus courants sans écrire de workflow d’analyse à la main.

Ajoutez ensuite une approbation manuelle sur l’environnement de production. Depuis Pipelines > Environments, ouvrez l’environnement production, section « Approvals and checks », et ajoutez un ou plusieurs approbateurs. Le stage de déploiement se met alors en pause jusqu’à validation humaine, un filet de sécurité simple avant tout déploiement irréversible.

Pour les équipes qui construisent des images pour plusieurs architectures, gardez un œil sur la préversion des agents macOS Apple Silicon en facturation à l’usage : elle évite de maintenir un runner ARM self-hosted pour des builds occasionnels. Enfin, si vos pipelines commencent à ralentir sous la charge, la feuille de route du troisième trimestre 2026 prévoit des agents hébergés de plus grande taille, une option à activer dès qu’elle sortira de préversion pour les jobs de build les plus lourds.

Un dernier réglage à considérer une fois le pipeline stabilisé : la traçabilité au niveau des stages, elle aussi annoncée pour le troisième trimestre 2026. Elle permettra de suivre précisément quelle version d’image tourne sur quel environnement à un instant donné, un vrai gain pour les équipes qui gèrent plusieurs clusters AKS en parallèle et qui perdent aujourd’hui du temps à recouper manuellement les journaux de déploiement avec les tags d’image.

Sécuriser le pipeline : scans de code, permissions et bonnes pratiques

Un pipeline qui déploie automatiquement en production mérite les mêmes précautions qu’un accès administrateur. La première règle, souvent négligée, consiste à limiter les permissions du pipeline au strict nécessaire. Un principal de service ou une identité managée qui a le droit d’écrire dans tout l’abonnement Azure est une mauvaise idée : préférez un rôle personnalisé restreint au groupe de ressources rg-demo-aks et aux actions réellement utilisées, comme la mise à jour d’un déploiement Kubernetes ou la lecture d’un registre ACR.

Deuxième réflexe : activez une politique de branche sur main dans Azure Repos. Exigez au minimum une pull request avec un relecteur, et cochez l’option qui bloque la fusion tant que le build n’est pas vert. Combinée aux vérifications de statut de sécurité passées en disponibilité générale au Sprint 275, cette politique empêche un code non testé, ou porteur d’une alerte de scan critique, d’atteindre la branche qui déclenche le déploiement en production.

Troisième point, spécifique à ce tutoriel : ne laissez jamais un manifeste Kubernetes en clair référencer un secret applicatif. Le fichier manifests/deployment.yaml de ce guide ne contient volontairement aucune donnée sensible. Pour une vraie application, injectez les secrets via un objet Secret Kubernetes distinct, lui-même alimenté depuis Azure Key Vault avec le pilote CSI Secrets Store, plutôt que de les écrire dans le YAML versionné avec le reste du code. Enfin, limitez le nombre de personnes ayant le rôle Administrateur de projet dans Azure DevOps : c’est ce rôle qui permet de modifier les service connections et de contourner les politiques de branche, il doit rester entre peu de mains.

Pensez enfin à consulter régulièrement l’onglet Audit d’Azure DevOps, disponible au niveau de l’organisation. Il journalise les changements de permissions, les créations de service connections et les modifications de politiques de branche. Sur un pipeline qui touche à la production, c’est souvent le premier endroit à vérifier après un incident, avant même de regarder les journaux du pipeline lui-même.

Optimiser la vitesse du pipeline : cache et parallélisation

Un pipeline qui prend quinze minutes décourage vite les équipes de pousser souvent. Le premier levier consiste à mettre en cache les dépendances entre deux exécutions. Azure Pipelines propose une tâche Cache@2 qui stocke un dossier (comme node_modules ou le cache npm) et le restaure automatiquement si la clé de cache correspond, par exemple un hash du fichier package-lock.json. Ajoutée avant l’étape de build, cette tâche évite de retélécharger les mêmes paquets à chaque exécution.

steps:
  - task: Cache@2
    inputs:
      key: 'npm | "$(Agent.OS)" | package-lock.json'
      restoreKeys: |
        npm | "$(Agent.OS)"
      path: $(npm_config_cache)
    displayName: 'Cache des dépendances npm'

Le deuxième levier concerne la construction de l’image Docker elle-même. La tâche Docker@2 utilisée à l’étape 8 profite déjà du cache de couches par défaut sur les agents hébergés, mais vous pouvez encore réduire le temps de build en réorganisant le Dockerfile : placez les instructions qui changent rarement (installation des dépendances) avant celles qui changent à chaque commit (copie du code source). C’est exactement ce que fait le Dockerfile de l’étape 7, avec COPY package*.json suivi de RUN npm ci avant le COPY . . final.

Enfin, si votre pipeline exécute des tests unitaires, des tests d’intégration et un scan de sécurité, ne les enchaînez pas dans un seul job séquentiel. Répartissez-les en jobs parallèles au sein du même stage, avec dependsOn: [] pour indiquer qu’ils ne dépendent pas les uns des autres. Sur un plan gratuit à un seul job parallèle, ce découpage n’accélère rien puisque les jobs s’exécutent quand même l’un après l’autre faute de capacité, un argument de plus pour évaluer un second job parallèle self-hosted (environ 14,58 € par mois d’après l’estimation citée plus haut) dès que l’équipe grandit.

Azure DevOps face à GitHub Actions et GitLab CI

La question revient souvent : faut-il rester sur Azure DevOps ou migrer vers GitHub Actions ? Microsoft documente lui-même des migrations d’entreprise vers GitHub, avec des articles publiés début juin 2026 sur la conduite de ces transitions à grande échelle et sur ce que l’entreprise appelle « l’ère de l’IA » pour Azure DevOps et GitHub. Concrètement, cela ne signifie pas la fin d’Azure Pipelines : les deux outils cohabitent, et beaucoup d’équipes gardent Azure Boards et Azure Repos pour la gestion de projet tout en poussant leurs workflows CI vers GitHub Actions, ou l’inverse. Le choix dépend surtout de l’écosystème déjà en place : une organisation fortement investie dans Azure DevOps pour le suivi de tickets a rarement intérêt à tout migrer d’un coup, alors qu’une équipe qui démarre un projet neuf choisira plus naturellement GitHub Actions si son code est déjà hébergé sur GitHub. Ce tutoriel reste valable dans les deux cas : la logique de stages, de service connections et de manifestes Kubernetes se retrouve, avec une syntaxe différente, dans un workflow GitHub Actions ciblant AKS.

GitLab CI occupe une place plus marginale dans les organisations orientées Azure, mais reste pertinent pour les équipes qui gèrent déjà leur code sur une instance GitLab auto-hébergée pour des raisons de souveraineté. Le fichier .gitlab-ci.yml reprend une structure très proche de celle d’Azure Pipelines, avec des stages et des jobs, et peut tout aussi bien construire une image Docker et la déployer vers AKS via kubectl ou Helm. Le choix entre les trois plateformes tient rarement à des différences techniques majeures : il dépend surtout de l’endroit où vit déjà votre code, et des compétences internes de l’équipe.

Foire aux questions

Azure DevOps est-il gratuit pour une petite équipe ?
Oui, l’organisation gratuite inclut cinq utilisateurs, un job parallèle Microsoft-hosted avec minutes illimitées et Azure Boards. Au-delà de cinq utilisateurs ou d’un job parallèle, des coûts supplémentaires s’appliquent.

Peut-on utiliser Azure Pipelines avec un dépôt GitHub plutôt qu’Azure Repos ?
Oui. Lors de la création du pipeline, choisissez GitHub comme source, autorisez l’application Azure Pipelines sur votre compte GitHub, puis pointez vers le fichier azure-pipelines.yml du dépôt.

Faut-il obligatoirement Azure Container Registry, ou peut-on utiliser Docker Hub ?
ACR n’est pas obligatoire. Docker Hub ou tout autre registre compatible fonctionne, à condition de créer la bonne service connection et d’adapter le nom d’image dans le manifeste. ACR simplifie simplement l’authentification avec AKS via l’identité managée.

Comment revenir en arrière si un déploiement casse la production ?
La commande kubectl rollout undo deployment/demo-app revient à la version précédente du déploiement. Pour l’automatiser dans le pipeline, ajoutez un stage conditionnel qui déclenche ce rollback en cas d’échec des tests post-déploiement. Gardez aussi un historique de révisions suffisant avec kubectl rollout history deployment/demo-app, utile pour identifier précisément quelle version fonctionnait avant l’incident.

Les identités de charge de travail Microsoft Entra remplacent-elles complètement les PAT ?
Pas totalement en 2026 : certains scénarios s’appuient encore sur des jetons d’accès personnels, mais la nouvelle service connection basée sur workload identity, livrée au Sprint 275, couvre désormais la majorité des cas d’usage courants pour l’accès à Azure DevOps depuis un pipeline.

Quelle est la différence entre le niveau Free et le niveau Standard d’AKS ?
Le niveau Free ne garantit pas de SLA sur le plan de contrôle, ce qui convient pour du développement ou des tests. Le niveau Standard, payant, ajoute une garantie de disponibilité recommandée pour la production. Vérifiez les conditions exactes sur la documentation officielle avant de choisir.

Combien de temps prend un déploiement complet vers AKS une fois le pipeline en place ?
Une fois configuré, un cycle complet (build, push, déploiement) prend généralement entre 3 et 8 minutes selon la taille de l’image et le nombre de replicas, hors temps de provisionnement initial du load balancer.

Peut-on déployer sur plusieurs clusters AKS depuis le même pipeline ?
Oui, en dupliquant le stage de déploiement avec des paramètres azureResourceGroup et kubernetesCluster différents, ou en utilisant une matrice de déploiement si vous gérez plusieurs environnements régionaux. C’est une configuration courante pour les équipes qui doivent répliquer un déploiement entre France Central et West Europe pour des raisons de résilience ou de proximité utilisateur.

Le pipeline fonctionne-t-il aussi avec Azure Container Apps plutôt qu’AKS ?
Oui, la logique de build et de publication d’image reste identique. Seul le stage de déploiement change : remplacez la tâche KubernetesManifest@1 par la tâche AzureContainerApps@1, plus adaptée si vous n’avez pas besoin de la flexibilité complète d’un cluster Kubernetes géré.

Ressources complémentaires