Intégration Azure et plateforme d’API

Ce que nous construisons

La plateforme d’API. Azure API Management comme porte d’entrée : produits et abonnements par consommateur, contrats versionnés publiés à partir d’OpenAPI, limitation de débit, validation des requêtes, validation des jetons contre Entra ID, et un portail développeur qui vous débarrasse de la collection Postman envoyée par courriel. Les politiques vivent dans le contrôle de version, pas dans le portail.

La messagerie asynchrone. Azure Service Bus pour le travail ordonné, transactionnel et par session, avec files de rebut, détection de doublons et report de messages configurés volontairement plutôt que laissés aux valeurs par défaut. Event Grid quand le patron est la notification diffusée et non la file de travail. Nous nommons lequel sert à quoi, et pourquoi.

Le calcul. Azure Functions pour les traitements sans état et les transformations, en modèle worker isolé, avec identité managée vers chaque ressource en aval et aucune chaîne de connexion dans les paramètres d’application. Logic Apps là où un flux SaaS riche en connecteurs va réellement plus vite, choisi délibérément et documenté comme un compromis de portabilité.

Les contrats. Un schéma par message et par point de terminaison, versionné, avec une règle de compatibilité explicite. Une rupture de contrat passe par une fenêtre de dépréciation, pas par un courriel.

Le comportement en panne. Reprise avec délai exponentiel et gigue, clés d’idempotence sur chaque consommateur, coupe-circuit sur les appels sortants, traitement des rebuts avec un responsable nommé, et un chemin de rejeu qu’un technicien de soutien peut exécuter sans développeur.

L’observabilité. Identifiants de corrélation propagés de bout en bout, traçage distribué dans Application Insights, et des alertes sur la profondeur de file, le nombre de rebuts et le retard des consommateurs plutôt que sur l’usage processeur.

La gouvernance Power Platform. Stratégie d’environnements, politiques DLP, découpage en solutions Dataverse et ALM par pipelines, pour que l’application bâtie par un utilisateur et devenue critique ait enfin un chemin de déploiement et un propriétaire.

Comment nous décidons ce qui va où

Trois questions tranchent l’essentiel, et nous y répondons flux par flux, par écrit, plutôt que d’appliquer un style maison.

L’appelant a-t-il besoin de la réponse maintenant ? Les requêtes synchrones passent par API Management. Tout ce que l’appelant n’a pas à attendre passe par Service Bus. L’erreur coûteuse consiste à placer un système lent en aval d’un appel synchrone, puis à qualifier les délais d’attente qui en résultent de problème d’infrastructure.

Le message décrit-il un fait survenu ou un travail à accomplir ? Les événements sont diffusés sur Event Grid et peuvent légitimement n’avoir aucun consommateur. Les commandes vont dans une file et ont exactement un responsable. Confondre les deux produit un système où personne ne peut dire si un message a été traité.

Le processus est-il critique et durable ? Alors c’est du code dans un dépôt avec des tests, pas un canevas dans un concepteur graphique. Appliquée honnêtement, cette règle raccourcit la discussion sur Logic Apps et évite qu’elle soit rouverte tous les six mois.

Comment se déroule le mandat

Semaine 1, inventaire et contrats. Nous listons chaque interface existante, y compris le transfert SFTP planifié que personne n’a documenté, et notons pour chacune le sens, le volume, la tolérance à la latence et ce qui se passe aujourd’hui quand elle échoue. Cette dernière colonne est presque toujours vide, et la remplir constitue l’essentiel de la valeur de la semaine.

Semaine 2, plateforme. API Management, espaces de noms Service Bus, rubriques Event Grid, Functions et le chemin réseau entre eux, déployés en Terraform dans la landing zone avec points de terminaison privés et identité managée partout.

Semaines 3 et 4, deux premières intégrations. Nous construisons les deux flux les plus risqués, pas les deux plus faciles : ce sont les difficiles qui révèlent les décisions de plateforme erronées, pendant qu’il est encore temps de les changer.

Semaine 5, durcissement. Comportement en charge, réglage des reprises, procédures de rejeu, seuils d’alerte, et un exercice de panne volontaire où nous coupons un système en aval pour observer ce que fait la plateforme.

Semaine 6, transfert. Pipelines, documentation, catalogue d’interfaces, et une séance de passation avec les développeurs qui construiront eux-mêmes les vingt flux suivants.

Ce que vous gardez

Un dépôt Terraform de la plateforme d’intégration, dans votre organisation Git.
Un catalogue d’interfaces : chaque flux, son contrat, son responsable, son comportement en panne.
Les définitions OpenAPI versionnées et les politiques API Management en code.
Les procédures de rejeu des rebuts et des trois pannes les plus probables.
Les pipelines de déploiement avec promotion d’environnement et retour arrière.
La liste écrite de ce que nous avons choisi de ne pas intégrer, et pourquoi.

Pour qui c’est fait

Les organisations dont le parc applicatif a été acheté par morceaux et doit maintenant s’accorder : un ERP, un CRM, un système d’entrepôt, un portail, et une plateforme de données derrière. Cela s’installe bien après une landing zone Azure et juste avant un programme Microsoft Fabric, parce que des interfaces propres sont ce qui empêche un lakehouse de devenir une deuxième copie du désordre existant.

C’est aussi la bonne première étape quand un projet d’IA est bloqué. La plupart des travaux d’agents calent sur l’accès aux données et non sur les modèles, raison pour laquelle les mandats d’ingénierie IA commencent si souvent ici.

Pour qui ce n’est pas

Si vous avez deux systèmes et un transfert de fichier nocturne, une plateforme d’intégration est une charge inutile : gardez le transfert et ajoutez-y de la supervision. Si vous voulez un connecteur point à point livré ce mois-ci, sans intérêt pour le contrat ni pour le chemin d’échec, ce travail existe mais ce n’est pas le nôtre, et la dette vous revient dans un an.

Si le vrai problème est que deux directions ne s’entendent pas sur le système qui détient la fiche client de référence, aucune quantité de Service Bus n’y changera rien. C’est une décision de gouvernance, et elle se prend par une personne, idéalement celle que décrit la page direction des SI à temps partagé.

Questions fréquentes

Avons-nous besoin d’API Management ou une Function suffit-elle ?

Si vous avez trois points de terminaison internes et un seul consommateur, une Function derrière Application Gateway suffit, et nous vous le dirons. API Management devient rentable quand il y a plusieurs consommateurs, un besoin de limitation par consommateur, des contrats versionnés à publier, ou l’obligation de montrer à un auditeur qui a appelé quoi. En deçà, c’est un abonnement qu’on paie pour se sentir gouverné.

Faut-il bâtir sur Logic Apps ?

Pour du travail planifié riche en connecteurs vers des SaaS, Logic Apps se construit plus vite et s’entretient moins cher que le code équivalent. Pour un processus d’affaires central qui doit rester portable, testable unitairement et lisible en pull request, c’est le mauvais contenant. Nous tranchons intégration par intégration et écrivons dans quelle catégorie chacune tombe.

Comment évitez-vous les échecs silencieux ?

Chaque message porte un identifiant de corrélation de bout en bout, chaque consommateur est idempotent, chaque file et chaque rubrique a une file d’attente de rebut avec un responsable nommé et une alerte, et Application Insights trace toute la chaîne. L’échec silencieux vient presque toujours de l’absence de politique de rebut, pas d’un bogue.

Pouvez-vous intégrer un ERP sans API ?

Oui. Quand une API moderne existe, nous l’utilisons. Sinon les options sont un flux de changements au niveau de la base, un dépôt de fichiers surveillé, ou un adaptateur éditeur. Chacune a un profil de panne différent que nous documentons avant de choisir, et nous disons lesquelles vieillissent mal.

Qui exploite la plateforme après la mise en service ?

Votre équipe, dans votre dépôt, avec le Terraform et les pipelines. Si vous préférez que nous l’exploitions, c’est une entente d’infogérance distincte, tarifée séparément, et non une dépendance que nous aurions conçue dans l’architecture.

La Power Platform est-elle couverte ?

Oui, comme couche de gouvernance : stratégie d’environnements, politiques DLP, conception Dataverse, et la frontière entre ce qui relève de Power Automate et ce qui relève d’une Function. Le développement citoyen sans cadre devient de l’informatique fantôme avec un logo Microsoft dessus.

Une question sur ce mandat ?

Trois champs. Un architecte le lit et répond en un jour ouvrable.