Quatre services composent le poste de développeur Azure Integration Services, et les questions d'entretien doivent les couvrir avec la façon dont ils tiennent ensemble en production. Un workflow Logic Apps qui marche dans le portail ne dit rien de la suite : un message en dead-letter, un partenaire qui renvoie deux fois la même commande, un ERP joignable seulement par le réseau privé.
Deux parcours se présentent. Les anciens développeurs BizTalk connaissent les maps, les accusés B2B et la rigueur du rejeu, et découvrent l'identité managée, le réseau virtuel et le déploiement par pipeline. Les développeurs .NET écrivent de bonnes Functions mais voient Service Bus comme une simple file. Demandez à chacun la partie qu'il connaît le moins.
Le calendrier de Microsoft compte aussi. L'Integration Service Environment a été retiré en 2024, le modèle in-process des Functions .NET n'est plus supporté après le 10 novembre 2026, et BizTalk Server 2020 est la dernière version annoncée. Les CV qui en parlent au présent décrivent un existant à migrer.
Les services Azure d'un développeur intégration
Logic Apps
Le service de workflows, avec plus de 1 400 connecteurs. Deux hébergements : Consumption, facturé à l'exécution, un workflow par ressource ; Standard, sur un plan dédié, plusieurs workflows par application, intégration au réseau virtuel et développement local dans VS Code. Le plan Standard existe aussi en déploiement hybride sur une infrastructure de l'entreprise.
Service Bus
Le broker de messages d'Azure : files, topics et abonnements, sessions pour l'ordre, détection des doublons, dead-letter queue. La plupart des incidents d'intégration passent par lui. Demandez comment la personne lit une DLQ et rejoue les messages.
Event Grid et Event Hubs
Event Grid pousse des événements discrets vers des abonnés, avec nouvelles tentatives et lettres mortes. Event Hubs ingère des flux à fort débit, partitionnés, lisibles aussi en protocole Kafka. Le poste les utilise moins que Service Bus, mais le candidat doit savoir lequel choisir.
Azure Functions
Le code des flux : transformations complexes, appels particuliers, traitements déclenchés par une file. En .NET, le modèle isolated worker remplace le modèle in-process, dont le support s'arrête le 10 novembre 2026. Durable Functions permet d'écrire des orchestrations longues en code.
API Management
La passerelle qui expose les API et les workflows aux partenaires et aux applications. Les policies gèrent l'authentification, les limites d'appels, la réécriture et les erreurs. Le niveau choisi (classique ou v2) conditionne l'accès aux backends d'un réseau virtuel.
Integration account et B2B
Le stockage des schémas, des maps et des accords avec les partenaires pour les échanges AS2, EDIFACT et X12. Les Logic Apps Standard font les transformations XSLT et Liquid sans integration account, mais les échanges B2B avec accords en ont toujours besoin.
Identité managée et Key Vault
Les workflows et les Functions s'authentifient auprès de Service Bus, du stockage ou des API avec une identité gérée par Azure et des rôles limités, sans mot de passe stocké. Les secrets qui restent sont rangés dans Key Vault et référencés depuis la configuration.
Bicep, Terraform et pipelines
L'infrastructure est décrite en Bicep ou en Terraform (avec AzAPI pour Logic Apps Standard), les workflows sont livrés en zip par Azure DevOps ou GitHub Actions. Un candidat qui déploie depuis le portail aura du mal à tenir plusieurs environnements.
Application Insights et Azure Monitor
La supervision des flux : traces des runs, erreurs des Functions, métriques Service Bus, requêtes KQL dans Log Analytics et alertes. C'est là que le support retrouve une commande ou une facture précise.
Le développeur Azure Integration Services travaille dans une équipe d'intégration ou dans un programme qui modernise les échanges entre applications. Les offres associent Logic Apps, Service Bus, Functions et API Management à C#, et parfois à Dynamics 365 ou à une migration depuis BizTalk Server. Certaines missions sont surtout du run sur des flux existants, d'autres de la conception. Précisez dans l'offre l'hébergement Logic Apps en place (Consumption ou Standard), la part de code C#, l'existence d'échanges B2B (AS2, EDIFACT) et la part de migration BizTalk, car ces quatre points changent le profil à chercher.
Ce qu'il faut vérifier chez un développeur Logic Apps et Service Bus
- Logic Apps Standard et Consumption
- Messagerie Service Bus et Event Grid
- Azure Functions en C#
- API Management et sécurité des API
- Gestion des erreurs et rejeu des flux
- Déploiement Bicep ou Terraform et CI/CD
Cinq questions pour un développeur Azure Integration Services
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.
Question 1 · confirmé
Un nouveau flux doit écrire dans une base SQL Server joignable uniquement depuis un réseau privé. Vous partez sur Logic Apps Consumption ou Standard ?
Une bonne réponseStandard, et le candidat sait dire pourquoi. Le plan Standard s'intègre à un réseau virtuel et accepte des private endpoints, ses connecteurs intégrés (SQL Server, Service Bus) tournent dans le même processus que les workflows, une même ressource porte plusieurs workflows stateful ou stateless, et on développe en local dans VS Code. Consumption est facturé à l'exécution et reste plus simple pour un petit flux public, mais chaque ressource ne contient qu'un workflow et il faut une passerelle de données locale pour atteindre un réseau privé. Il parle aussi du coût fixe du plan Standard face au paiement à l'exécution.
Signal d'alerte« C'est pareil, on prend le moins cher », ou une proposition d'Integration Service Environment, retiré par Microsoft en 2024.
Question 2 · confirmé
Des messages s'accumulent dans la dead-letter queue d'un abonnement Service Bus. Comment trouvez-vous la cause, puis comment les rejouez-vous ?
Une bonne réponseIl lit d'abord la raison posée par Service Bus sur chaque message : MaxDeliveryCountExceeded (dix tentatives par défaut), TTLExpiredException, session absente sur une entité à sessions. Pour un dépassement du nombre de livraisons, il cherche l'exception côté consommateur ou un verrou expiré parce que le traitement dure plus longtemps que le verrou (peek-lock). Une fois la cause corrigée, il renvoie les messages, depuis Service Bus Explorer dans le portail ou par script, et s'assure que le consommateur est idempotent puisqu'il va les relire.
Signal d'alertePurger la DLQ, ou passer MaxDeliveryCount à 100 pour que l'alerte disparaisse.
Question 3 · senior
Les mises à jour d'un même client doivent être traitées dans l'ordre. Comment le garantissez-vous avec Service Bus ?
Une bonne réponseAvec les sessions : une file ou un abonnement où les sessions sont activées, et l'identifiant client placé dans SessionId. Un consommateur verrouille une session et traite ses messages dans l'ordre, pendant que d'autres consommateurs prennent d'autres sessions. Il ajoute la détection des doublons sur MessageId si l'émetteur peut renvoyer, et réfléchit à ce qu'il fait d'un message en échec au milieu d'une session.
Signal d'alerte« Service Bus est FIFO », sans parler de sessions, ou un seul consommateur pour toute la file.
Question 4 · junior à confirmé
Dans un workflow Logic Apps, une action HTTP échoue une fois sur cent. Comment gérez-vous l'erreur sans perdre la commande ?
Une bonne réponseUne politique de nouvelle tentative réglée sur l'action (exponentielle, quatre essais par défaut), puis un bloc Scope qui joue le rôle de try, suivi d'un bloc configuré avec runAfter sur Failed et TimedOut pour le catch. La fonction result() récupère le détail de l'erreur, le message part dans une file de rejeu ou une notification, et le workflow se termine en échec avec Terminate, pour que l'erreur reste visible.
Signal d'alerteAucun réglage de nouvelle tentative, ou un Terminate en Succeeded qui masque l'échec dans l'historique.
Question 5 · confirmé
Vous exposez un workflow Logic Apps à des partenaires par API Management. Que mettez-vous dans les policies ?
Une bonne réponseUne authentification des appelants (validate-jwt avec Microsoft Entra ID, ou certificat client), des clés d'abonnement par produit, des limites (rate-limit-by-key, quota), puis la réécriture vers le backend. L'URL du déclencheur Logic Apps contient une signature SAS : elle reste cachée, stockée dans une named value liée à Key Vault, ou remplacée par un appel avec identité managée. Il ajoute une section on-error qui renvoie des erreurs propres et l'envoi des traces vers Application Insights.
Signal d'alerteDonner directement aux partenaires l'URL du workflow avec sa signature, ou se contenter de la clé d'abonnement.
Recevez la fiche d'entretien complète en PDF
La fiche pour mener l'entretien de bout en bout, prête à imprimer ou à partager avec le manager.
- 30 questions sur 6 axes, avec la bonne réponse, le signal d'alerte et la relance
- Le niveau visé pour chaque question
- Une mise en situation de 20 minutes et ce qu'on attend du candidat
- La grille d'évaluation de 1 à 4, axe par axe
Questions de recruteurs sur les profils Azure Integration Services
Faut-il savoir coder pour un poste de développeur Logic Apps ?
Oui, dans la plupart des cas. Les workflows se dessinent, mais un flux réel demande des expressions, des maps XSLT ou Liquid, et souvent des Azure Functions en C# pour ce que les connecteurs ne font pas. Le déploiement passe par Bicep ou Terraform et un pipeline. Un profil qui ne fait que du glisser-déposer dans le portail convient à de petits flux internes, pas à une plateforme d'intégration.
Un développeur BizTalk est-il prêt pour Azure Integration Services ?
Il a la plus grande partie du métier : maps, schémas, échanges B2B, rejeu, suivi des messages. Ses maps XSLT se réutilisent souvent dans Logic Apps. Il lui manque en général le cloud : identité managée, réseau virtuel, Service Bus, déploiement par pipeline et supervision dans Application Insights. Demandez-lui ce qu'il a déjà construit sur Azure, même hors production, et comment il traduirait une orchestration BizTalk en services Azure.
Comment savoir si un candidat a vraiment exploité des flux en production ?
Faites-lui raconter un incident : une file qui grossit, des messages en dead-letter, un partenaire qui envoie des doublons. Écoutez s'il cite la raison du dead-letter, la durée du verrou, l'identifiant de corrélation, la façon de rejouer sans doublon. Les profils qui n'ont fait que construire décrivent le workflow. Ceux qui l'ont exploité décrivent ce qui s'est passé quand il a cassé, et ce qu'ils ont ajouté ensuite.
Quel test technique pour un développeur Azure Integration Services ?
Un schéma d'architecture commenté à voix haute marche mieux qu'un long exercice. Donnez un flux simple, par exemple des commandes à envoyer d'une API vers un ERP sur site, et demandez les services choisis, la gestion d'une panne de l'ERP et le déploiement. Si vous voulez du code, une Function déclenchée par Service Bus avec une écriture idempotente tient en une heure.
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.
