Azure DevOps est une plateforme Microsoft qui regroupe tous les outils dont une équipe de développement a besoin pour livrer un logiciel de la gestion des tâches jusqu'au déploiement en production. Ce guide explique ce qu'elle fait, comment elle fonctionne, et comment l'utiliser concrètement.

Introduction à Azure DevOps

Livrer un logiciel de qualité, régulièrement et sans chaos, demande plus qu'un bon code. Il faut suivre les tâches, gérer le code source, automatiser les tests, déployer sans tout casser, et faire collaborer des équipes qui n'ont pas toujours les mêmes priorités. Azure DevOps est la réponse de Microsoft à ce problème. Une plateforme unique, des outils intégrés, un flux de travail cohérent de la première ligne de code jusqu'à l'utilisateur final.

C'est quoi Azure DevOps ?

Azure DevOps est une suite d'outils en ligne proposée par Microsoft pour gérer l'intégralité du cycle de vie d'un projet logiciel. Elle couvre la planification des tâches, le stockage du code, l'automatisation des builds et des déploiements, la gestion des packages, et les tests. Elle s'adresse aussi bien aux petites équipes qu'aux grandes entreprises, et fonctionne avec pratiquement n'importe quel langage, framework ou cloud.

Historique et objectifs

Azure DevOps n'est pas né de rien. Il est l'héritier direct de Team Foundation Server (TFS), l'outil de gestion de code et de builds que Microsoft proposait depuis 2005 en version installée sur les serveurs des entreprises. En 2018, Microsoft a fait évoluer ce produit vers le cloud sous le nom Azure DevOps Services, tout en conservant une version on-premise appelée Azure DevOps Server pour les organisations qui ne peuvent pas ou ne veulent pas héberger leurs données dans le cloud.
L'objectif central est de supprimer les frictions entre les équipes de développement et les équipes opérationnelles et ce qu'on appelle le mur entre "Dev" et "Ops". Concrètement : moins d'attente entre l'écriture du code et sa mise en production, moins d'erreurs liées aux processus manuels, et une meilleure visibilité sur l'avancement des projets pour tout le monde.

Différences avec GitHub ou Jenkins

Les trois outils sont souvent mentionnés ensemble, mais ils ne font pas la même chose et ne s'adressent pas au même contexte.
GitHub est avant tout une plateforme de gestion de code source avec une forte dimension communautaire et open source. GitHub Actions permet d'automatiser des workflows, mais la gestion de projet (suivi des tâches, planification de sprints) reste plus légère qu'Azure DevOps. Microsoft a racheté GitHub en 2018, les deux coexistent et se complètent souvent.
Jenkins est un outil d'automatisation open source focalisé uniquement sur l'intégration et le déploiement continus. Il est très flexible et très personnalisable, mais il demande une infrastructure à maintenir soi-même, et sa configuration peut devenir complexe. Jenkins ne fait pas de gestion de projet, pas de stockage de code, pas de gestion de packages.
Azure DevOps couvre tout le spectre en un seul endroit : planification, code, build, déploiement, tests, packages. C'est son principal avantage sur Jenkins (qui est spécialisé) et sur GitHub (qui est moins complet sur la gestion de projet). Son principal inconvénient est qu'il est une plateforme commerciale Microsoft, avec les dépendances que ça implique.

Quelles sont les fonctionnalités d'Azure DevOps ?

Azure DevOps est composé de cinq modules distincts. On peut les utiliser tous ensemble ou seulement certains, selon les besoins de l'équipe.

Azure Boards

Azure Boards est l'outil de gestion de projet. Il permet de planifier le travail, de suivre l'avancement, et de visualiser qui fait quoi à quel moment.

Work Items et Queries

Un Work Item est l'unité de base du suivi dans Azure Boards. C'est une fiche qui représente une tâche, un bug, une fonctionnalité à développer, ou un élément de backlog. Chaque Work Item a un type, un statut, un responsable, une priorité, et peut être lié à d'autres Work Items ou à des commits de code.
Les Queries sont des filtres enregistrables qui permettent d'afficher exactement les Work Items dont vous avez besoin : "tous les bugs critiques non assignés", "toutes les tâches du sprint en cours assignées à moi", "tout ce qui est bloqué depuis plus de 3 jours". Une Query bien configurée remplace un tableau de bord de réunion entier.

Tableaux Kanban et Scrum

Azure Boards supporte les deux méthodes d'organisation les plus répandues. En mode Kanban, les Work Items sont des cartes qu'on déplace de colonne en colonne selon leur avancement : "À faire", "En cours", "En révision", "Terminé". Les colonnes sont personnalisables selon votre flux réel.
En mode Scrum, le travail est organisé en sprints de durée fixe (généralement 1 à 3 semaines). Azure Boards gère le backlog, la planification des sprints, le sprint burndown (graphique qui montre si l'équipe est en bonne voie pour finir le sprint), et les rétrospectives. Les deux modes peuvent coexister dans le même projet selon les équipes.

Azure Repos

Azure Repos est le gestionnaire de code source. C'est là que le code est stocké, versionné, et que les modifications sont examinées avant d'être intégrées.

Git et TFVC

Azure Repos supporte deux systèmes de gestion de versions. Git est le standard de l'industrie aujourd'hui : décentralisé, flexible, utilisé par la quasi-totalité des équipes de développement modernes. Si vous démarrez un nouveau projet, vous utilisez Git.
TFVC (Team Foundation Version Control) est le système historique de Microsoft centralisé, où il n'existe qu'une seule version de référence sur le serveur. Il est encore présent dans Azure Repos pour les équipes qui ont des projets historiques sous TFS et n'ont pas migré. Pour tout nouveau projet, Git est le bon choix.

Branches et Pull Requests

Dans Azure Repos, le travail quotidien se fait sur des branches. Chaque développeur crée une branche pour la fonctionnalité ou le bug sur lequel il travaille, sans toucher au code principal. Quand le travail est terminé, il ouvre une Pull Request et une demande formelle d'intégration du code dans la branche principale.
La Pull Request déclenche un processus de revue : d'autres membres de l'équipe examinent le code, laissent des commentaires, demandent des modifications. Des règles peuvent être configurées pour qu'une Pull Request ne puisse être acceptée que si les tests automatisés passent, qu'au moins deux développeurs ont approuvé, et qu'aucun commentaire n'est en suspens. C'est le mécanisme principal de contrôle qualité du code dans une équipe.

Azure Pipelines

Azure Pipelines automatise tout ce qui se passe entre l'écriture du code et sa mise en production : compilation, tests, création des packages déployables, et déploiement sur les environnements cibles.

Build Pipelines

Un Build Pipeline se déclenche automatiquement quand du code est poussé sur le dépôt. Il compile le code, exécute les tests unitaires, analyse la qualité du code, et produit un artefact. Le résultat buildé prêt à être déployé. Si quelque chose échoue, l'équipe est notifiée immédiatement. L'objectif est de détecter les problèmes le plus tôt possible, quand ils sont encore simples à corriger.

Release Pipelines

Un Release Pipeline prend l'artefact produit par le Build Pipeline et le déploie sur les environnements cibles: développement, staging, production selon des règles définies. Il peut inclure des étapes d'approbation manuelle (un responsable doit valider avant le déploiement en production), des tests de smoke après déploiement, et des mécanismes de rollback automatique si quelque chose se passe mal.

YAML vs Éditeur Classique

Azure Pipelines propose deux façons de configurer un pipeline. L'éditeur classique est une interface graphique ou on configure les étapes en cliquant, en remplissant des formulaires. C'est accessible pour démarrer, mais difficile à versionner et à partager.
La configuration YAML est un fichier texte stocké directement dans le dépôt de code, aux côtés du code source. C'est l'approche recommandée aujourd'hui. Le pipeline est traité comme du code : il évolue avec le projet, il est revu lors des Pull Requests, il peut être copié et adapté d'un projet à l'autre. La syntaxe demande un peu d'apprentissage, mais la flexibilité et la traçabilité qu'elle offre valent largement l'investissement.

Azure Artifacts

Azure Artifacts est le gestionnaire de packages d'Azure DevOps. Il permet d'héberger et de partager des packages: des bibliothèques de code réutilisables  au sein de l'équipe ou de l'organisation, sans passer par des registres publics.
Il supporte les formats les plus courants : npm (JavaScript), NuGet (.NET), Maven (Java), Python, et Universal Packages pour tout le reste. Concrètement, quand plusieurs équipes partagent du code commun, elles publient ce code sous forme de package dans Azure Artifacts. Les autres équipes l'importent comme n'importe quelle dépendance externe, mais depuis un registre privé contrôlé. Les versions sont gérées, les accès sont restreints, et les packages obsolètes peuvent être archivés sans disparaître.

Test Plans

Azure Test Plans gère les tests manuels et les tests exploratoires. C'est le module le moins automatisé des cinq , il est pensé pour les équipes QA qui testent manuellement des scénarios précis avant une mise en production.
Un Test Plan est un ensemble de cas de test organisés par fonctionnalité ou par version. Un testeur exécute chaque cas, marque le résultat (réussi, échoué, bloqué), et peut attacher des captures d'écran ou des enregistrements vidéo directement depuis l'interface. Les bugs détectés sont automatiquement créés comme Work Items dans Azure Boards. Test Plans s'intègre aussi avec les tests automatisés pour offrir une vue unifiée de la couverture de test — automatique et manuelle — sur un même projet.

Quel est le rôle d'un DevOps ?

Un ingénieur DevOps n'est pas un développeur qui fait de l'infrastructure, ni un administrateur système qui écrit du code. C'est un profil hybride dont le rôle est de construire et maintenir les systèmes qui permettent aux équipes de livrer du logiciel rapidement, de façon fiable et répétable.

Missions quotidiennes

Au quotidien, un ingénieur DevOps passe son temps sur plusieurs fronts en parallèle. Il configure et maintient les pipelines CI/CD et quand un pipeline tombe en panne ou ralentit, c'est lui qu'on appelle. Il gère l'infrastructure cloud (création d'environnements, gestion des ressources, optimisation des coûts). Il automatise les tâches répétitives que les développeurs font à la main : déploiements, rotations de secrets, sauvegardes, rapports. Il surveille les applications en production et réagit aux incidents. Et il passe du temps à documenter et à former les développeurs à utiliser correctement les outils mis en place.
Dans une équipe mature, le DevOps travaille aussi sur la fiabilité : définir des objectifs de disponibilité, mettre en place des tests de charge, préparer des runbooks pour que n'importe quel membre de l'équipe puisse gérer un incident courant.

Compétences requises

Un bon ingénieur DevOps maîtrise plusieurs domaines sans être expert de tous. La base : Linux et la ligne de commande, un ou plusieurs langages de scripting (Python, Bash, PowerShell), Git, et les principes des réseaux (DNS, HTTP, TLS, load balancing).
Côté outils, Azure DevOps ou ses équivalents (GitHub Actions, GitLab CI), un ou plusieurs outils d'infrastructure as code (Terraform, Bicep, Ansible), Docker et Kubernetes pour la conteneurisation, et une plateforme cloud (Azure, AWS, GCP).
Côté softs skills qui, souvent sous-estimés, la communication est centrale. Un DevOps est à l'interface entre les développeurs, les équipes opérationnelles, la sécurité et parfois le management. Savoir expliquer un problème technique à quelqu'un qui n'est pas technique, documenter clairement un processus, et convaincre une équipe d'adopter une nouvelle pratique sont des compétences aussi importantes que la maîtrise de Kubernetes.

Salaire et évolution

En France, un ingénieur DevOps junior démarre autour de 38 000 à 45 000 € brut annuel. Avec 3 à 5 ans d'expérience, la fourchette se situe entre 50 000 et 65 000 €. Un profil senior ou spécialisé (SRE, Platform Engineer, DevSecOps) peut dépasser 70 000 à 80 000 € en région parisienne ou dans des entreprises tech.
Le marché est en forte demande et les profils expérimentés sont rares. Les certifications Azure (AZ-400 notamment) valorisent le profil mais ne remplacent pas l'expérience pratique. L'évolution naturelle se fait vers des rôles d'architecte cloud, de responsable plateforme, ou de SRE (Site Reliability Engineer) — un profil encore plus orienté fiabilité et observabilité.

C'est quoi la méthode DevOps ?

DevOps est avant tout une culture et une façon de travailler. Les outils  dont Azure DevOps  viennent après. Sans la culture, les outils ne servent à rien.

Principes CALMS

Le modèle CALMS est le cadre de référence pour comprendre ce que DevOps signifie concrètement en entreprise.

  • Culture: Le point de départ: DevOps casse le mur traditionnel entre développeurs (qui veulent livrer vite) et opérationnels (qui veulent stabiliser). Les deux équipes partagent la responsabilité de ce qui est en production. Un bug en prod, c'est le problème de tout le monde, pas seulement des ops.
  • Automatisation: Tout ce qui peut être automatisé doit l'être : builds, tests, déploiements, provisionnement d'infrastructure. L'automatisation élimine les erreurs humaines et rend les processus reproductibles.
    Lean: Éliminer ce qui ne crée pas de valeur: Des processus de validation trop lourds, des environnements de tests qui prennent des jours à provisionner, des réunions de planification de déploiement hebdomadaires, tout ça est du gaspillage que DevOps cherche à éliminer.
  • Mesure : Si vous ne mesurez pas, vous ne savez pas si vous vous améliorez. Les équipes DevOps mesurent le temps entre l'écriture du code et son déploiement, le taux d'échec des déploiements, le temps de récupération après un incident.
    Sharing: Le partage des connaissances, des outils et des pratiques entre équipes. Les post-mortems d'incidents sont publics et sans blame. Les runbooks sont accessibles à tous. Les bonnes pratiques se propagent plutôt que de rester dans les silos.

 

Cycle CI/CD

CI/CD est le moteur opérationnel de DevOps. CI signifie Continuous Integration ou intégration continue et CD signifie Continuous Delivery ou Continuous Deployment.

  • L'intégration continue : chaque développeur intègre son code plusieurs fois par jour dans la branche principale. À chaque intégration, un pipeline automatique compile le code et lance les tests. L'objectif est de détecter les conflits et les régressions au plus tôt, quand ils sont encore simples à corriger.
  • La livraison continue : le code qui passe les tests est automatiquement déployé sur un environnement de staging, prêt à être mis en production à tout moment. La décision de déployer en production reste humaine.
  • Le déploiement continu va un cran plus loin : tout code qui passe les tests est automatiquement déployé en production, sans intervention humaine. C'est ce que pratiquent des entreprises comme Netflix ou Amazon, qui font plusieurs déploiements par jour.

 

Différence avec Agile

Agile et DevOps sont complémentaires, pas concurrents, mais ils ne parlent pas de la même chose.
Agile est une méthode de gestion de projet. Elle organise le travail de l'équipe de développement en cycles courts (sprints), avec des livraisons fréquentes et des ajustements réguliers selon les retours. Elle répond à la question : comment organiser l'équipe pour construire le bon produit ?
DevOps est une culture et un ensemble de pratiques techniques. Il répond à la question : comment livrer rapidement et de façon fiable ce que l'équipe a construit ? Une équipe peut être parfaitement Agile dans sa gestion de projet et avoir des déploiements manuels chaotiques. Une autre peut avoir des pipelines CI/CD exemplaires sans aucune pratique Agile.
En pratique, les deux fonctionnent mieux ensemble : Agile construit les bonnes choses, DevOps les livre efficacement.

Avantages et Inconvénients

Ce qui fonctionne bien
Azure DevOps couvre l'ensemble du cycle de développement dans une plateforme unique, ce qui évite de jongler entre cinq outils différents qui ne se parlent pas. L'intégration avec l'écosystème Microsoft est native et profonde — Azure, Visual Studio, Teams, Active Directory. Le support des entreprises est sérieux, avec des SLA, de la documentation fournie, et une communauté active. La flexibilité est réelle : on peut utiliser seulement Azure Pipelines avec GitHub Repos, ou Azure Boards avec un dépôt GitLab.
Ce qui est moins bien
L'interface peut être déroutante pour les nouveaux utilisateurs car certaines fonctionnalités sont difficiles à trouver, et la terminologie (Work Items, Iterations, Areas) demande une courbe d'apprentissage. La configuration avancée des pipelines YAML peut devenir complexe sur des projets multi-services. Et la dépendance à Microsoft est réelle : si votre organisation décide un jour de sortir de l'écosystème Azure, la migration demande du travail.

Tarification

Azure DevOps propose un niveau gratuit pour commencer, puis une tarification qui évolue selon l'usage.
Le plan gratuit inclut 5 utilisateurs (Basic), un accès limité aux pipelines (2 000 minutes de build par mois sur les agents hébergés), Azure Repos illimité pour les dépôts Git, et Azure Artifacts avec 2 Go de stockage.
Au-delà, les utilisateurs supplémentaires avec le plan Basic coûtent environ 6 $ par utilisateur et par mois. Les pipelines supplémentaires (jobs parallèles hébergés) sont facturés environ 40 $ par job parallèle. Test Plans est le module le plus cher : environ 52 $ par utilisateur et par mois. Les grandes organisations négocient des accords Enterprise avec Microsoft qui modifient ces tarifs.
Pour une équipe de 10 développeurs sans Test Plans et avec des besoins pipeline raisonnables, le coût mensuel tourne autour de 50 à 100 €.

 

Comment démarrer ?

Créer un compte

Rendez-vous sur dev.azure.com. Connectez-vous avec un compte Microsoft existant (Outlook, Xbox, ou un compte professionnel Azure Active Directory). Si vous n'en avez pas, la création est gratuite et prend deux minutes.
Une fois connecté, vous créez une organisation Azure DevOps et c'est le conteneur de plus haut niveau qui regroupe tous vos projets. Le nom de l'organisation apparaîtra dans l'URL de votre espace (dev.azure.com/votre-organisation). Une organisation peut appartenir à une personne ou à une entreprise, et plusieurs projets peuvent coexister à l'intérieur.

Premier projet

Dans votre organisation, cliquez sur "New Project". Donnez-lui un nom, choisissez sa visibilité (privé ou public), et sélectionnez le processus de travail : Agile, Scrum ou CMMI selon votre méthodologie. Pour la plupart des équipes, Agile ou Scrum sont les bons choix. Ce paramètre influence les types de Work Items disponibles dans Azure Boards.
Votre projet est créé instantanément. Vous avez accès aux cinq modules dans le menu de gauche. Commencez par Azure Boards pour créer vos premières tâches, puis par Azure Repos pour initialiser votre dépôt Git.

Premier pipeline

Dans votre projet, allez dans Azure Pipelines et cliquez sur "Create Pipeline". L'assistant vous demande où se trouve votre code Azure Repos, GitHub, Bitbucket, ou un autre système. Sélectionnez votre dépôt.
Azure Pipelines analyse votre code et propose des templates adaptés à votre stack : Node.js, .NET, Python, Docker, etc. Sélectionnez le template correspondant. Un fichier YAML est généré automatiquement avec les étapes de base. Lisez-le, ajustez si nécessaire, et cliquez sur "Save and Run".
Votre premier pipeline tourne. Vous pouvez suivre l'exécution en temps réel, voir les logs de chaque étape, et identifier immédiatement ce qui fonctionne ou ce qui échoue. À partir de là, vous ajoutez progressivement des étapes : tests automatisés, analyse de code, déploiement sur un environnement de dev.

Intégrations et Écosystème

Avec Azure

L'intégration entre Azure DevOps et les services Azure est native. Depuis un Release Pipeline, vous déployez directement sur une App Service, une VM, un cluster AKS (Kubernetes managé), une Azure Function, ou un Static Web App  sans configuration complexe, via des tâches prédéfinies qui gèrent l'authentification et la connexion automatiquement.
Azure Monitor et Application Insights peuvent être branchés sur vos pipelines pour déclencher un rollback automatique si les métriques de production se dégradent après un déploiement. Azure Key Vault s'intègre nativement pour gérer les secrets. Par ailleurs,  les mots de passe et tokens ne sont jamais stockés en clair dans vos pipelines.

Avec GitHub et Slack

Si votre code est hébergé sur GitHub, Azure Pipelines s'y connecte directement. Vous gardez GitHub pour le code et les Pull Requests, et vous utilisez Azure Pipelines pour les builds et déploiements. Les deux se synchronisent : un statut de pipeline apparaît directement sur la Pull Request GitHub.
L'intégration Slack permet d'envoyer des notifications dans vos channels : résultat d'un build, démarrage d'un déploiement, échec d'un pipeline. Les membres de l'équipe restent informés sans avoir à vérifier l'interface Azure DevOps en permanence. Microsoft Teams propose la même intégration avec encore plus de profondeur, les Work Items pouvant être créés et modifiés directement depuis Teams.

Sécurité et Conformité

RBAC et Permissions

Azure DevOps utilise un système de contrôle d'accès basé sur les rôles (RBAC — Role-Based Access Control). Chaque utilisateur se voit attribuer un rôle qui détermine ce qu'il peut faire : lire le code, modifier des Work Items, déclencher des pipelines, gérer les paramètres de l'organisation.
Les permissions sont granulaires et hiérarchiques. Elles s'appliquent au niveau de l'organisation, du projet, du dépôt, ou même de la branche. Vous pouvez autoriser un développeur externe à lire un dépôt sans lui donner accès aux pipelines ou aux autres projets de l'organisation. Les groupes simplifient la gestion : plutôt que de configurer les droits utilisateur par utilisateur, vous créez des groupes (développeurs, QA, déploiement) et assignez des permissions aux groupes.

GDPR et Audits

Pour les organisations soumises au RGPD, Azure DevOps propose des outils pour gérer les données personnelles stockées dans la plateforme : export des données utilisateur, suppression sur demande, et journaux d'accès. Microsoft publie régulièrement ses certifications de conformité (ISO 27001, SOC 2, RGPD) pour la plateforme Azure DevOps Services.
Les journaux d'audit enregistrent toutes les actions significatives dans l'organisation : connexions, modifications de permissions, suppressions, changements de configuration. Ces journaux sont exportables et peuvent être intégrés à un SIEM (outil de surveillance de sécurité) pour détecter des comportements anormaux. La rétention des journaux et des données est configurable selon vos contraintes réglementaires.

Questions Fréquentes (FAQ)

Le plan gratuit d'Azure DevOps est-il suffisant pour démarrer ?

Pour une petite équipe, oui. Le plan gratuit inclut 5 utilisateurs, un job de pipeline hébergé avec 1 800 minutes par mois, Azure Repos illimité et 2 Go de stockage Artifacts. C'est suffisant pour un projet naissant. Les limites apparaissent quand l'équipe dépasse 5 personnes ou quand les builds deviennent longs et fréquents — à ce stade, il faut passer à un plan payant ou ajouter des agents self-hosted.

Peut-on utiliser ses propres serveurs de build ?

Oui. Azure Pipelines permet d'enregistrer des agents self-hosted sur vos propres machines, physiques ou virtuelles  pour exécuter les pipelines. Ces agents ne consomment pas les minutes du plan gratuit et ne coûtent rien en plus sur Azure DevOps. C'est une option courante dans les entreprises qui ont des contraintes réseau (accès à des ressources internes), des builds très lourds, ou des environnements de compilation spécifiques difficiles à reproduire sur les agents hébergés.

Peut-on migrer depuis TFS vers Azure DevOps ?

Oui, et c'est officiellement supporté par Microsoft via l'Azure DevOps Migration Tool. L'outil migre les Work Items, l'historique Git ou TFVC, les pipelines et les artefacts. La migration complète avec tout l'historique est faisable, mais elle demande une préparation sérieuse : nettoyage des données, vérification des compatibilités de version, et validation sur un environnement de test avant la bascule en production. Pour les projets TFS anciens et complexes, prévoir un accompagnement spécialisé puisqu' une migration bâclée sur un historique de plusieurs années est difficile à corriger après coup.

Pourquoi l'erreur "No hosted parallelism has been purchased or granted" apparaît-elle ?

C'est une mesure anti-abus de Microsoft sur les nouveaux comptes. Les organisations récemment créées doivent soumettre une demande manuelle pour accéder aux agents hébergés gratuits. En attendant la validation qui peut prendre quelques jours, la solution immédiate est d'enregistrer un agent self-hosted sur votre propre machine pour débloquer les pipelines.

Le pipeline réussit en local mais échoue sur Azure Pipelines. Pourquoi ?

La cause la plus fréquente est une dépendance installée sur votre machine mais absente sur l'agent hébergé. L'agent repart d'un environnement propre à chaque exécution or il ne connaît pas votre configuration locale. La bonne pratique est d'utiliser des tâches de pipeline qui installent explicitement les versions dont vous avez besoin (Node, .NET, Python, etc.) plutôt que de supposer qu'elles sont déjà disponibles. Vérifiez aussi les différences de système d'exploitation si vous développez sur macOS et que l'agent tourne sous Linux.

Les variables secrètes ne sont pas accessibles dans mon pipeline. Comment résoudre ça ?

Les variables de type secret sont masquées par Azure Pipelines et ne sont pas injectées automatiquement dans tous les contextes. Vérifiez trois choses : que la variable est définie au bon niveau (organisation, projet, pipeline ou étape), qu'elle est bien passée explicitement en paramètre aux scripts qui en ont besoin, et que vous n'essayez pas de l'afficher dans les logs. Azure Pipelines bloque volontairement l'affichage des secrets, même dans les traces de debug.

Le déploiement s'est terminé en succès mais l'application ne fonctionne pas. Que vérifier ?

Quand le pipeline réussit mais que l'application dysfonctionne, le problème est rarement dans le pipeline lui-même. Commencez par les logs de l'application après déploiement et non pas les logs du pipeline. Les causes les plus fréquentes sont des variables d'environnement manquantes ou mal configurées sur la cible, des permissions insuffisantes sur les ressources Azure (base de données, storage, Key Vault), ou une version de configuration différente entre staging et production. Le pipeline a livré le bon artefact au bon endroit : il faut chercher  l'environnement, pas le build.

Azure DevOps fonctionne-t-il avec des dépôts GitHub ou GitLab ?

Oui. Azure Pipelines se connecte nativement à GitHub, GitLab, Bitbucket et d'autres dépôts Git externes. Vous pouvez très bien héberger votre code sur GitHub et utiliser uniquement Azure Pipelines pour les builds et déploiements sans toucher à Azure Repos. Cette flexibilité permet d'adopter Azure DevOps progressivement sans migrer tout son outillage existant d'un coup.

Quelle est la différence entre Azure DevOps Services et Azure DevOps Server ?

Azure DevOps Services est la version cloud hébergée par Microsoft accessible depuis n'importe où, maintenue et mise à jour automatiquement. Azure DevOps Server est la version installée sur vos propres serveurs, pour les organisations qui ne peuvent pas héberger leurs données dans le cloud pour des raisons réglementaires ou de sécurité. Les fonctionnalités sont globalement équivalentes, mais Azure DevOps Server a toujours un léger retard sur les nouvelles fonctionnalités déployées d'abord sur la version cloud.