Questions d'entretien ingénieur Azure DevOps sur les pipelines YAML

Le poste d'ingénieur Azure DevOps se confond souvent avec celui d'ingénieur DevOps Azure, alors que le sujet principal diffère. Ici, on parle de la plateforme de livraison : pipelines YAML à plusieurs stages, templates partagés entre projets, environnements avec approbations, agents hébergés par Microsoft ou installés sur les serveurs de l'entreprise, flux Azure Artifacts. Les cibles varient : App Service, AKS, mais aussi des serveurs Windows avec IIS et des scripts PowerShell.

Sur les CV, Azure DevOps apparaît souvent à côté de release pipelines classiques créés dans l'éditeur graphique. Microsoft recommande le YAML et y concentre ses évolutions, en particulier pour la sécurité. Un candidat qui a migré des pipelines classiques vers du YAML parle de checks, de templates extends et de ce qui manque encore. Celui qui a seulement utilisé un pipeline existant reste vague sur les service connections et les variable groups.

Reste à savoir où tourne la plateforme. Azure DevOps Server, la version installée sur ses propres serveurs, existe toujours : la dernière, sortie en décembre 2025, ne porte plus de millésime. Un poste sur ce produit ajoute la mise à jour du serveur, les agents internes et le proxy aux sujets de l'entretien.

Azure DevOps service par service, vu depuis le poste

Azure Pipelines YAML

Le pipeline écrit dans un fichier azure-pipelines.yml du dépôt, découpé en stages, jobs et steps. Les valeurs se résolvent à des moments différents selon la syntaxe utilisée, à la compilation ou à l'exécution, ce qui cause beaucoup d'erreurs. C'est le premier sujet à évaluer.

Templates et extends

Les templates factorisent des étapes, des jobs ou des stages entiers. On les range dans un dépôt partagé, référencé par resources.repositories. Un template extends impose un squelette à tous les pipelines, et un check sur l'environnement de production peut refuser un pipeline qui ne l'utilise pas.

Environnements, approbations et checks

Un environnement représente une cible de déploiement, comme la recette ou la production. On y attache des approbations, des horaires autorisés, un verrou exclusif ou l'appel à un service externe. Les deployment jobs y laissent l'historique de ce qui a été déployé, quand et depuis quel commit.

Agents hébergés, self-hosted et Managed DevOps Pools

Les agents hébergés par Microsoft repartent d'une image propre à chaque job. Les agents self-hosted tournent sur les machines de l'entreprise, avec accès au réseau interne et des caches, mais il faut les mettre à jour. Managed DevOps Pools, disponible en GA, prend la suite des pools sur Virtual Machine Scale Sets : Microsoft gère les VM, qui peuvent rejoindre le réseau virtuel de l'entreprise.

Service connections et Key Vault

Une service connection donne au pipeline un accès à Azure, à un registre ou à un cluster. Microsoft pousse la fédération d'identité de charge de travail pour se passer des secrets de principal de service, qui expirent. Les variable groups peuvent être liés à un Key Vault pour lire les secrets au moment de l'exécution.

Azure Repos et stratégies de branche

Le Git hébergé d'Azure DevOps, avec des stratégies sur les branches protégées : relecteurs obligatoires, lien vers un work item, build de validation à réussir avant la fusion. Des projets anciens gardent du TFVC, que Microsoft ne fait plus évoluer : un réglage permet d'en bloquer la création et Microsoft prévoit de le retirer peu à peu des nouveaux projets.

Azure Artifacts

Les flux de paquets NuGet, npm, Maven ou Python, avec des sources amont vers les registres publics et des vues (@prerelease, @release) pour promouvoir une version testée. Les droits sur le flux décident quel pipeline peut publier.

.NET, IIS et PowerShell

Une grande partie des pipelines Azure DevOps construit des applications .NET avec la tâche DotNetCoreCLI, puis déploie sur App Service ou sur des serveurs Windows. Sur IIS, le déploiement passe par des environnements avec des ressources VM, des scripts PowerShell et la gestion des pools d'applications. La personne doit savoir déployer sans couper le site.

Azure DevOps Server

La version installée sur site, héritière de TFS. La dernière, appelée simplement Azure DevOps Server, est sortie en décembre 2025 et reçoit un patch presque chaque mois. Elle reprend les nouveautés du service cloud avec du retard et demande d'administrer SQL Server, l'annuaire et les agents internes.

Le poste apparaît dans deux familles d'offres. Les premières visent la plateforme de livraison d'équipes .NET ou Windows, avec du packaging, du PowerShell et parfois un Azure DevOps Server installé en interne. Les secondes associent Azure DevOps au cloud Azure, avec AKS, Terraform ou Bicep, et se rapprochent du poste d'ingénieur DevOps Azure. Certaines équipes gardent Azure DevOps pour les Boards et passent le code sur GitHub, ce qui change les questions sur les déclencheurs et les accès. Le candidat doit savoir quelle part du poste porte sur l'outil lui-même et quelle part sur l'infrastructure cible.

À vérifier pendant l'entretien d'un ingénieur Azure DevOps

• Pipelines YAML à plusieurs stages
• Templates et expressions
• Environnements, approbations et checks
• Agents hébergés et self-hosted
• Service connections et secrets
• Déploiement .NET, IIS et Azure Artifacts

Les questions techniques d'un entretien d'ingénieur Azure DevOps

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Dans un pipeline YAML, quelle différence faites-vous entre ${{ variables.env }}, $(env) et $[ variables.env ] ?

   Une bonne réponse${{ }} est une expression de template, évaluée à la compilation, avant le lancement : elle sert à choisir des étapes, des stages ou des valeurs de paramètres. $(env) est une macro remplacée juste avant l'exécution de chaque tâche. $[ ] est une expression runtime, réservée à la définition de variables, qui sert par exemple à reprendre la variable de sortie d'un job précédent. Une variable fixée pendant l'exécution n'est donc jamais visible d'une expression de template.

   Signal d'alerteLes trois seraient équivalentes, ou une condition sur un paramètre écrite avec $(...) qui ne s'évalue pas comme prévu.

2. Question 2 · confirmé

   Trente dépôts ont chacun un pipeline recopié d'un autre. Comment les ramenez-vous à un modèle commun sans bloquer les équipes ?

   Une bonne réponseUn dépôt de templates référencé par resources.repositories avec une ref figée (tag ou branche de release), des templates de steps et de jobs avec des paramètres typés, et pour la production un template extends qui impose les étapes de sécurité. Un check Required template sur l'environnement de production refuse tout pipeline qui n'étend pas le modèle. Les équipes gardent des points d'extension, par exemple un paramètre de type stepList.

   Signal d'alerteUn template lu sur la branche main, que chaque modification peut casser partout, ou des pipelines classiques clonés.

3. Question 3 · junior à confirmé

   La mise en production doit attendre l'accord d'un responsable et ne jamais tourner en même temps qu'une autre. Comment le configurez-vous ?

   Une bonne réponseUn deployment job qui cible l'environnement de production, et sur cet environnement un check d'approbation par un groupe, un verrou exclusif et, si besoin, des heures autorisées. Les checks sont posés sur la ressource : l'auteur du pipeline ne peut pas les retirer en modifiant son YAML. Il fixe aussi un délai d'expiration pour l'approbation.

   Signal d'alerteUne variable APPROVED à passer à true au lancement, ou une validation écrite dans le YAML que n'importe quel contributeur peut supprimer.

4. Question 4 · confirmé

   Votre pipeline déploie sur Azure avec une service connection qui contient le secret d'un principal de service. Ce secret a expiré ce matin. Que changez-vous ?

   Une bonne réponseIl passe la connexion en fédération d'identité de charge de travail : Azure DevOps émet un jeton OIDC pour le pipeline, Entra ID le reconnaît grâce à un identifiant fédéré sur l'application ou sur une identité managée, et plus aucun secret n'expire. L'identité reçoit un rôle limité au groupe de ressources, et l'usage de la connexion est réservé à certains pipelines, avec une approbation posée sur la connexion.

   Signal d'alerteGénérer un nouveau secret valable deux ans et le recoller dans la connexion.

5. Question 5 · confirmé

   Les builds sur agents hébergés n'atteignent pas une base SQL Server du réseau interne. Quelles options avez-vous ?

   Une bonne réponseDes agents self-hosted placés dans le réseau, sur VM ou en conteneur, ou un pool Managed DevOps Pools rattaché à un réseau virtuel de l'entreprise : Microsoft gère les VM, le réseau reste le vôtre. Ouvrir la base aux adresses des agents hébergés n'est pas sérieux, la plage est large et partagée entre clients. Il parle aussi de la mise à jour des agents, du nettoyage entre deux jobs et des droits du compte qui exécute l'agent.

   Signal d'alerteOuvrir le pare-feu de la base sur Internet le temps des tests.

Ingénieur Azure DevOps : questions fréquentes

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.