WEBVTT 00:00:00.140 --> 00:00:03.820 Bienvenue dans un nouvel épisode des pépites de connaissances Microsoft, je suis votre autre Mirko Peters. 00:00:04.040 --> 00:00:07.220 Le sujet d'aujourd'hui est quelque chose dont presque tout le monde a entendu parler, mais que peu comprennent vraiment. 00:00:07.920 --> 00:00:10.260 Les API. Vous avez probablement entendu ce terme très souvent. 00:00:10.860 --> 00:00:14.160 C'est l'un de ces mots techniques que les gens utilisent pour paraître experts dans leur domaine. 00:00:15.040 --> 00:00:16.860 Et voici le fait, les API sont en réalité simples. 00:00:17.640 --> 00:00:19.880 Ce sont juste un moyen pour qu'un logiciel communique avec un autre. 00:00:20.480 --> 00:00:22.720 Votre téléphone demande des données à un serveur. Le serveur les renvoie. 00:00:23.040 --> 00:00:23.780 C'est ça, un appel API. 00:00:24.160 --> 00:00:26.400 Imaginez maintenant que vous ayez 20 API, ou 50, ou 100. 00:00:26.680 --> 00:00:29.580 Chacune peut utiliser une authentification différente, des limites de débit variées, 00:00:29.580 --> 00:00:31.600 et une documentation différente, voire inexistante. 00:00:32.080 --> 00:00:35.740 Soudainement, ce qui a commencé comme une simple conversation entre deux applications devient un chaos total. 00:00:36.620 --> 00:00:39.000 Sans gestionnaire central, chaque équipe réinvente la roue. 00:00:39.600 --> 00:00:42.700 Une équipe crée son propre système d'authentification, une autre son propre système de journalisation. 00:00:43.020 --> 00:00:44.200 Des feuilles de sécurité apparaissent partout. 00:00:44.780 --> 00:00:46.440 Les développeurs ne savent plus quelle API fait quoi, 00:00:46.580 --> 00:00:49.700 et vous n'avez aucune vision globale de ce qui se passe dans votre système. 00:00:50.080 --> 00:00:51.880 Ah, Azure API Management Résouceau. 00:00:52.420 --> 00:00:53.580 Ils vous offrent un centre de contrôle unique. 00:00:54.600 --> 00:00:57.220 Voyez cela comme une tour de contrôle aérien pour vos API. 00:00:57.220 --> 00:01:01.060 A la fin de cet épisode, vous comprendrez ce que c'est, pourquoi c'est important, 00:01:01.200 --> 00:01:02.480 et comment tout cela s'articule. 00:01:03.600 --> 00:01:05.040 Prenez votre café, plongeons dans le sujet. 00:01:06.340 --> 00:01:07.880 Le problème, trop d'API, aucun contrôle. 00:01:08.760 --> 00:01:10.100 Voici la réalité des logiciels modernes. 00:01:10.500 --> 00:01:12.340 Il y a 10 ans, vous avez probablement une seule grosse application. 00:01:12.820 --> 00:01:15.260 Un monolithe, une base de données, une API, simple. 00:01:16.760 --> 00:01:19.640 Aujourd'hui, cette même application pourrait être décomposée en dizaines de microservices. 00:01:20.260 --> 00:01:23.560 Chaque service gère une chose, compte utilisateur, paiement, inventaire, notification, 00:01:23.560 --> 00:01:28.920 et chacun expose sa propre API, et, soudainement, vous avez 10, 50, 100 points d'entrée différents dans votre système. 00:01:29.480 --> 00:01:32.320 Imaginez maintenant que vous soyez un développeur, essayant de construire quelque chose qui utilise ces API. 00:01:32.740 --> 00:01:35.360 Vous devez trouver chacune d'elles, comprendre l'authentification de chacune. 00:01:35.900 --> 00:01:38.560 Certaines utilisent des clés API, d'autres aux autres, certaines rien du tout. 00:01:39.080 --> 00:01:41.480 Vous devez gérer manuellement les limites de débit sous peine d'être bloquées. 00:01:42.220 --> 00:01:44.060 Vous devez comprendre le format de données attendu par chacune. 00:01:44.620 --> 00:01:45.180 C'est épuisant. 00:01:45.900 --> 00:01:47.220 Et cela empire du point de vue des opérations. 00:01:47.740 --> 00:01:51.800 Sans passerelle centrale, chaque équipe doit ajouter manuellement la sécurité et la journalisation à son propre service. 00:01:51.800 --> 00:01:54.220 Certaines équipes le font bien, d'autres oublient de journaliser les erreurs. 00:01:54.620 --> 00:01:55.840 Certaines ne valident même pas les entrées. 00:01:56.280 --> 00:01:57.660 C'est incohérent et sujet aux erreurs. 00:01:58.000 --> 00:01:59.240 Un cauchemar de sécurité en devenir. 00:01:59.800 --> 00:02:01.160 La conformité devient presque impossible. 00:02:01.720 --> 00:02:03.800 Besoin de prouver qui a accédé à quoi et quand ? 00:02:03.800 --> 00:02:07.500 Bonne chance pour extraire les pistes d'audit de 20 services différents, chacun avec son propre format de journalisation. 00:02:07.920 --> 00:02:11.260 Besoin de savoir combien d'appels API votre système a traité le mois dernier ? 00:02:11.260 --> 00:02:13.560 Compiler des métriques provenant d'une douzaine de tableaux de bord différents. 00:02:14.380 --> 00:02:14.840 Voici le problème. 00:02:15.200 --> 00:02:16.860 A mesure que vous évoluez, cela ne se contente pas d'être pénible. 00:02:17.120 --> 00:02:17.520 Ça casse tout. 00:02:17.520 --> 00:02:21.160 Impossible d'ajouter plus de développeurs, de services ou de clients sans un point de contrôle central. 00:02:21.520 --> 00:02:22.540 Voyez cela comme un bâtiment. 00:02:22.940 --> 00:02:24.260 Imaginez que chaque pièce posait une sérieux différente. 00:02:24.640 --> 00:02:26.000 Il n'y a ni réception, ni annuaire. 00:02:26.560 --> 00:02:31.740 Les visiteurs errent pour trouver la bonne porte, sagacent et finissent par abandonner le chaos total. 00:02:32.500 --> 00:02:34.520 C'est le problème que la gestion d'API a été conçue pour résoudre. 00:02:35.520 --> 00:02:37.060 Qu'est-ce qu'Azure API Management ? 00:02:37.060 --> 00:02:37.820 La tour de contrôle. 00:02:38.540 --> 00:02:40.760 Alors qu'est-ce qu'Azure API Management exactement ? 00:02:40.760 --> 00:02:41.840 Voici la définition la plus simple. 00:02:42.280 --> 00:02:47.680 C'est un service managé qui se place entre vos API back-end et les applications, sites web, appareils et partenaires qui les utilisent. 00:02:48.620 --> 00:02:50.160 Mais attention, ce n'est pas qu'un simple proxy. 00:02:50.620 --> 00:02:51.880 Un proxy transfère le trafic et c'est tout. 00:02:52.320 --> 00:02:55.020 Azure API Management couvre tout le cycle de vie de vos API. 00:02:55.700 --> 00:02:58.220 Publiez, sécurisez, surveillez et finissez par les retirer. 00:02:58.620 --> 00:02:59.560 C'est un centre de contrôle complet. 00:03:00.080 --> 00:03:01.620 Décomposons cela en trois composants principaux. 00:03:01.960 --> 00:03:02.740 Le premier est la passerelle. 00:03:03.120 --> 00:03:03.700 C'est la porte d'entrée. 00:03:03.700 --> 00:03:08.020 Chaque requête entrente d'une application ou d'un site web frappe d'abord la passerelle, jamais votre back-end directement. 00:03:09.180 --> 00:03:13.320 La passerelle traite la requête, applique vos politiques, collecte des métriques, puis la transfère au bon service back-end. 00:03:14.820 --> 00:03:15.960 Considérez-la comme un agent de circulation. 00:03:16.600 --> 00:03:17.520 Vient ensuite le plan de gestion. 00:03:18.320 --> 00:03:19.520 C'est là que vous définissez tout. 00:03:20.040 --> 00:03:22.180 Vos API, vos politiques, vos produits, vos abonnements. 00:03:23.040 --> 00:03:27.760 Vous faites cela via le portail Azure, la ligne de commande, l'infrastructure Ascode, comme Bicep ou Terraform. 00:03:28.340 --> 00:03:30.360 C'est la salle de contrôle où vous configurez le fonctionnement de tout. 00:03:31.020 --> 00:03:32.160 Et ensuite le portail des développeurs. 00:03:32.160 --> 00:03:38.080 C'est un site en libre-service où les développeurs internes ou externes peuvent découvrir vos API, lire la documentation, obtenir des clés d'abonnement. 00:03:38.340 --> 00:03:40.760 Et même tester les appels API directement dans leur navigateur. 00:03:40.980 --> 00:03:41.580 Eh ! 00:03:41.580 --> 00:03:43.400 Fini l'échange incessant de PDF par email. 00:03:43.900 --> 00:03:44.760 Voici une analogie utile. 00:03:45.020 --> 00:03:45.920 Pensez à un aéroport moderne. 00:03:46.260 --> 00:03:47.380 La passerelle et la piste d'atterrissage. 00:03:47.780 --> 00:03:48.960 Chaque avion y atterrit en premier. 00:03:49.420 --> 00:03:50.780 Le plan de gestion et la tour de contrôle. 00:03:51.520 --> 00:03:53.740 Elle dirige le trafic, définit les règles et surveille tout. 00:03:54.360 --> 00:03:56.020 Et le portail des développeurs et le panneau d'informations. 00:03:56.800 --> 00:04:00.460 Les pilotes le consultent avant de voler et trouvent toutes les informations nécessaires sans parler à personne. 00:04:01.000 --> 00:04:02.100 Maintenant, zoom-on sur la passerelle. 00:04:02.580 --> 00:04:05.480 C'est la partie à laquelle vos applications parlent réellement et là où la magie opère. 00:04:07.060 --> 00:04:08.560 La passerelle, la porte d'entrée de vos API. 00:04:09.240 --> 00:04:12.720 Parlons de la passerelle car c'est la partie avec laquelle vos applications communiquent réellement. 00:04:13.200 --> 00:04:17.000 Chaque requête venant d'une application mobile, d'un site web ou d'un appareil IoT atteint d'abord la passerelle. 00:04:17.420 --> 00:04:18.440 Jamais votre back-end directement. 00:04:18.780 --> 00:04:19.300 C'est tout l'intérêt. 00:04:19.740 --> 00:04:22.040 La passerelle se place devant et agit comme un point d'entrée unique. 00:04:22.600 --> 00:04:24.980 La passerelle peut appliquer des stratégies avant de transmettre la requête. 00:04:25.540 --> 00:04:27.900 Les stratégies sont des règles que vous écrivez en XML ou en JSON, 00:04:27.900 --> 00:04:31.580 comme la limitation de débit, le filtre à JP, la réécriture d'entête et les contrôles d'authentification. 00:04:32.860 --> 00:04:34.600 Le tout sans changer une seule ligne de votre code back-end. 00:04:35.080 --> 00:04:35.900 Voici un exemple concret. 00:04:36.360 --> 00:04:38.740 Disons que vous avez une offre gratuite et une offre premium pour votre API. 00:04:39.260 --> 00:04:42.060 Avec une stratégie, vous pouvez limiter les utilisateurs gratuits à 5 requêtes par minute, 00:04:42.180 --> 00:04:43.700 tandis que les utilisateurs premium en obtiennent 100. 00:04:44.140 --> 00:04:45.440 Votre back-end ne voit jamais la différence. 00:04:45.800 --> 00:04:46.820 Il traite simplement les requêtes. 00:04:47.240 --> 00:04:48.500 La passerelle gère l'application des règles. 00:04:48.840 --> 00:04:50.280 La passerelle gère également la mise en cache. 00:04:50.700 --> 00:04:53.620 Si des données sont demandées à répétition, comme une liste de produits qui changent rarement, 00:04:53.620 --> 00:04:56.640 la passerelle peut mettre la réponse en cache et la servir directement. 00:04:56.960 --> 00:04:57.720 Et la servir directement. 00:04:57.880 --> 00:04:59.580 Il n'est pas nécessaire de solliciter votre back-end, 00:04:59.580 --> 00:05:02.120 ce qui signifie des réponses plus rapides et moins de charges sur vos serveurs. 00:05:02.580 --> 00:05:03.680 Elle peut aussi transformer les données. 00:05:04.220 --> 00:05:07.260 Votre back-end peut renvoyer du XML alors que votre application mobile attend du JSON. 00:05:07.720 --> 00:05:08.960 La passerelle peut le convertir à la volée. 00:05:09.640 --> 00:05:11.660 Votre back-end n'a pas besoin de changer et votre application non plus. 00:05:11.920 --> 00:05:12.280 Et... et... 00:05:12.280 --> 00:05:14.000 La passerelle gère la traduction. 00:05:14.860 --> 00:05:17.580 Et elle enregistre chaque appel, chaque requête, chaque réponse, chaque erreur. 00:05:18.100 --> 00:05:21.000 Vous obtenez une piste d'audit complète de qui a appelé quoi, quand et ce qui s'est passé. 00:05:21.900 --> 00:05:23.920 Rien que cela justifie l'investissement pour la conformité. 00:05:24.440 --> 00:05:27.200 Si vous avez une audience mondiale, vous pouvez déployer la passerelle dans plusieurs régions. 00:05:28.440 --> 00:05:32.520 Le trafic est automatiquement routé vers la plus proche, ce qui réduit la latence et améliore l'expérience. 00:05:33.480 --> 00:05:35.960 Une dernière chose, la passerelle masque l'URL réelle de votre back-end. 00:05:36.300 --> 00:05:37.580 Les clients ne voient que l'adresse de la passerelle. 00:05:37.940 --> 00:05:39.640 Vos serveurs back-end restent cachés d'internet. 00:05:40.120 --> 00:05:42.280 C'est un énorme avantage en matière de sécurité de la maison service. 00:05:43.020 --> 00:05:45.660 Les stratégies, le moteur qui contrôle tout... 00:05:45.660 --> 00:05:47.400 Alors qu'en est-il de ces stratégies que j'ai mentionnées ? 00:05:47.400 --> 00:05:49.460 Ce sont le moteur qui rend la gestion d'API vraiment puissante. 00:05:50.080 --> 00:05:53.920 Une stratégie modifie le comportement des requêtes ou des réponses sans jamais toucher à votre code back-end. 00:05:54.500 --> 00:05:56.200 Voyez cela comme une enveloppe autour de votre API. 00:05:56.840 --> 00:05:59.960 A mesure que le trafic circule, elle peut ajouter, supprimer ou modifier des éléments automatiquement. 00:06:00.740 --> 00:06:03.380 Les stratégies peuvent s'exécuter à 4 moments du cycle vide de la requête. 00:06:03.920 --> 00:06:06.880 En entrée, à l'arrivée, avant que la requête n'atteigne votre back-end, 00:06:07.580 --> 00:06:10.260 en sortie, au retour, avant que la réponse ne parvienne au client. 00:06:10.700 --> 00:06:12.900 Back-end, juste avant que la requête n'atteigne votre service. 00:06:13.320 --> 00:06:14.880 Et en cas d'erreur, lorsqu'un problème survient. 00:06:15.700 --> 00:06:19.440 Les tâches entrantes courantes incluent la validation de jetons JWT pour vérifier l'identité de l'appelant, 00:06:19.880 --> 00:06:22.960 la vérification des clés API, la réécriture d'URL et la restriction par adresse IP. 00:06:23.380 --> 00:06:25.740 Tout cela se produit avant que votre back-end ne reçoive la moindre requête. 00:06:26.180 --> 00:06:27.920 Pour les flux sortants, vous pouvez transformer le corps de la réponse. 00:06:28.720 --> 00:06:31.640 Rechercher et remplacer du texte, supprimer des champs sensibles, changer des formats. 00:06:31.640 --> 00:06:34.980 Vous pouvez mettre les réponses en cache pour que les requêtes répétées n'atteignent pas votre back-end. 00:06:35.360 --> 00:06:38.000 Vous pouvez même supprimer les entêtes qui divulguent des informations internes. 00:06:38.380 --> 00:06:39.200 Voici un exemple concret. 00:06:39.660 --> 00:06:42.660 Imaginez que votre API renvoie des descriptions de produits contenant le mot bleu partout. 00:06:43.360 --> 00:06:45.080 Vous souhaitez changer l'image de marque et utiliser jaune à la place. 00:06:45.940 --> 00:06:48.940 Au lieu de modifier le code de votre back-end, vous ajoutez une stratégie sortante. 00:06:49.760 --> 00:06:52.420 Rechercher bleu, remplacer par jaune, c'est tout. 00:06:52.840 --> 00:06:53.780 Votre back-end ne change jamais. 00:06:54.380 --> 00:06:57.000 Les stratégies de limitation de débit de quota protègent votre back-end contre les abus. 00:06:57.000 --> 00:07:00.760 Si une application devient incontrôlable et bombarde votre API dix et mille fois par seconde, 00:07:00.840 --> 00:07:03.160 la stratégie intervient et digue à ralentissez à gueule. 00:07:03.760 --> 00:07:04.820 Votre back-end reste sain. 00:07:05.240 --> 00:07:06.040 Il y a besoin d'une logique avancée. 00:07:06.420 --> 00:07:08.740 Vous pouvez écrire des expressions séchères personnalisées au sein des stratégies. 00:07:09.040 --> 00:07:10.280 Elles sont compilées pour garantir l'apparemment. 00:07:10.640 --> 00:07:11.660 Il n'y a donc aucun coût à l'exécution. 00:07:12.160 --> 00:07:14.840 Vous pouvez rechercher des rôles d'utilisateur, calculer des limites de débit dynamique 00:07:14.840 --> 00:07:17.220 ou transformer conditionnellement des réponses selon les entêtes de requêtes. 00:07:18.120 --> 00:07:19.100 Voici le point essentiel à retenir. 00:07:19.600 --> 00:07:23.400 Les stratégies vous permettent de contrôler le comportement de vos API sans toucher au code qui les exécute. 00:07:23.400 --> 00:07:26.700 Cela signifie des changements plus rapides, moins déploiements et moins de risques. 00:07:27.740 --> 00:07:28.540 Produits et abonnements. 00:07:29.140 --> 00:07:30.620 Packagez les API pour les consommateurs. 00:07:31.240 --> 00:07:34.600 Maintenant vos API sont définis, les stratégies sont en place et la passerelle fonctionne à merveille. 00:07:35.320 --> 00:07:38.800 Mais comment donner à différents clients accès à différentes choses ? 00:07:38.800 --> 00:07:40.220 C'est là qu'interviennent les produits et les abonnements. 00:07:40.920 --> 00:07:43.280 Dans Appim, vous regroupez les API dans ce qu'on appelle un produit. 00:07:44.280 --> 00:07:45.100 Considérez cela comme un bon. 00:07:45.660 --> 00:07:48.600 Pour y avoir un produit gratuit qui inclut seulement vos API de base. 00:07:49.540 --> 00:07:50.820 Peut-être juste un accès en lecture seul. 00:07:50.820 --> 00:07:55.160 Puis un produit premium inclus en tout, y compris les opérations d'écriture et les points de terminaison d'administration. 00:07:55.880 --> 00:07:58.620 Les développeurs ne s'abonnent pas à des API individuels et s'abonnent à un produit. 00:07:59.420 --> 00:08:01.260 Lorsqu'ils s'abonnent, ils reçoivent une clé d'abonnement. 00:08:01.740 --> 00:08:04.580 Faites deux clés pour pouvoir en renouveler une sans interruption de service. 00:08:04.920 --> 00:08:07.500 Cette clé est leur laissée passer pour utiliser toute API présente dans ce produit. 00:08:07.840 --> 00:08:09.100 Vous contrôlez le fonctionnement des abonnements. 00:08:09.800 --> 00:08:11.140 Les produits peuvent nécessiter une approbation. 00:08:11.720 --> 00:08:14.740 Vous acceptez manuellement chaque abonné, ou ils peuvent être ouverts au libre service. 00:08:15.300 --> 00:08:16.940 N'importe qui s'inscrit obtient un accès immédiat. 00:08:16.940 --> 00:08:20.760 Vous pouvez également inclure des conditions légales que les utilisateurs doivent accepter en sa bonne. 00:08:21.200 --> 00:08:23.160 C'est important si vos API traitent des données sensibles. 00:08:23.520 --> 00:08:24.840 C'est ainsi que vous monétisez vos API. 00:08:25.220 --> 00:08:27.620 Un produit gratuit avec des limites de débit basse, 5 appels par minute. 00:08:28.220 --> 00:08:30.620 Un produit payant avec des limites plus élevées ou plus de points de terminaison. 00:08:30.760 --> 00:08:32.940 100 appels par minute, plus l'accès à des fonctionnalités premium. 00:08:33.460 --> 00:08:34.500 Votre maquette ne s'en soucie pas. 00:08:34.720 --> 00:08:37.520 La passerelle applique les limites en fonction du produit auquel la plan a souscrit. 00:08:38.060 --> 00:08:38.900 Voici un exemple concret. 00:08:38.900 --> 00:08:40.720 Imaginez que vous créez une application de conférence. 00:08:41.100 --> 00:08:45.260 Vous créez un produit pour les participants avec des API pour le planning, les bio des intervenants et le plan du site. 00:08:46.060 --> 00:08:48.580 Puis un produit pour les sponsors qui inclut aussi des API de génération de leads. 00:08:49.420 --> 00:08:51.980 Les sponsors peuvent scanner les badges des participants et obtenir leurs coordonnées. 00:08:52.300 --> 00:08:54.260 Même backend, produits différents, niveau d'accès différents. 00:08:54.920 --> 00:08:56.780 Ces deux clés d'abonnement sont conçues pour la rotation. 00:08:57.900 --> 00:09:00.080 Si une clé est compromise, vous en générez une nouvelle. 00:09:00.760 --> 00:09:02.800 La deuxième clé vous permet de basculer sans interrompre le service. 00:09:03.420 --> 00:09:06.340 Générez une nouvelle clé, mettez à jour votre application, révoquez l'ancienne. 00:09:06.340 --> 00:09:10.460 En toute transparence, le portail développeur, le libre service pour les consommateurs d'API. 00:09:11.020 --> 00:09:12.320 Vous avez donc configuré vos produits API. 00:09:12.800 --> 00:09:13.960 Maintenant les développeurs doivent les trouver. 00:09:14.320 --> 00:09:15.420 C'est le rôle du portail développeur. 00:09:15.800 --> 00:09:18.500 Le portail développeur est un site web intégré à chaque instance APM. 00:09:19.060 --> 00:09:24.600 Les développeurs l'utilisent pour parcourir vos API, lire la documentation et tester les points de terminaison directement dans leur navigateur. 00:09:25.360 --> 00:09:27.000 Aucune configuration requise et aucun échange d'email. 00:09:27.580 --> 00:09:29.320 Mais attention, il n'est pas publié par défaut. 00:09:30.000 --> 00:09:33.500 Lorsque vous créez votre instance APM, le portail existe mais personne ne peut le voir. 00:09:33.960 --> 00:09:35.440 Vous devez d'abord le personnaliser et le publier. 00:09:35.440 --> 00:09:36.480 C'est intentionnel. 00:09:36.840 --> 00:09:38.780 Vous ne voulez pas montrer un portail inachevé au monde entier. 00:09:39.340 --> 00:09:43.820 Vous pouvez personnaliser les couleurs, les logos et même intégrer du contenu WordPress pour un blog à côté de vos docs API. 00:09:44.400 --> 00:09:46.960 Il est entièrement personnalisable pour correspondre à l'image de votre entreprise. 00:09:47.400 --> 00:09:48.660 La vraie valeur réside dans le libre service. 00:09:49.180 --> 00:09:53.780 Les développeurs s'inscrivent, obtiennent leur clé d'abonnement automatiquement et commencent à appeler les API immédiatement. 00:09:54.780 --> 00:09:58.400 Pas d'email manuel, pas d'attente d'approbation, pas de ticket de support demandant comment obtenir une clé. 00:09:59.200 --> 00:10:01.960 Ils le font eux-mêmes, ce qui réduit considérablement votre charge de support. 00:10:02.580 --> 00:10:04.040 Vous pouvez également publier des journaux de modification. 00:10:04.040 --> 00:10:08.180 Lorsque vous mettez à jour une API, les développeurs le voient sur le portail sans surprise. 00:10:09.160 --> 00:10:16.460 L'accès peut être public pour toute personne ayant l'URL ou restreint aux utilisateurs de votre tenant EntraID pour que seuls les membres de votre organisation puissent y accéder. 00:10:17.720 --> 00:10:19.460 Les deux options existent pour différents cas d'usage. 00:10:19.980 --> 00:10:22.700 Le portail développeur fait de votre gestion d'API une véritable plateforme. 00:10:23.280 --> 00:10:24.600 Considérez-le comme la vitrine de vos API. 00:10:25.180 --> 00:10:27.800 Sans lui, les développeurs doivent fouiller dans la doc et poser des questions. 00:10:27.800 --> 00:10:30.760 Avec lui, ils trouvent ce dont ils ont besoin et commencent à coder. 00:10:31.880 --> 00:10:34.960 Sécurité, authentification, autorisation et secrets. 00:10:35.740 --> 00:10:38.620 Toute cette puissance est inutile si la sécurité n'est pas verrouillée. 00:10:39.240 --> 00:10:41.920 Parlons donc de la manière dont la PIM gère l'identité, l'accès et les secrets. 00:10:42.400 --> 00:10:44.280 La PIM prend en charge plusieurs méthodes d'authentification. 00:10:44.880 --> 00:10:47.240 La plus simple est celle des clés d'abonnement dont nous avons parlé plus tôt. 00:10:47.900 --> 00:10:56.900 Cependant, pour les systèmes en production, il vous faut une protection renforcée comme OOS 2.0, les jetons JWT, les certificats clients ou le filtrage IP, ou superposer ces couches selon le niveau de sensibilité de votre API. 00:10:57.340 --> 00:11:00.380 Pour la production, la meilleure pratique consiste à utiliser OOS 2.0 avec EntraID. 00:11:00.880 --> 00:11:01.720 Voici comment cela fonctionne. 00:11:02.120 --> 00:11:05.500 L'application cliente obtient un jeton auprès d'EntraID et l'envoie avec la requête API. 00:11:06.040 --> 00:11:10.060 PIM valide le jeton en vérifiant la signature, l'émetteur, l'audience et l'expiration. 00:11:10.860 --> 00:11:14.040 S'il est valide, PIM transmet la requête à votre backend, jeton inclus. 00:11:14.820 --> 00:11:18.740 Votre backend lui fait confiance, car PIM l'a déjà vérifié, évitant ainsi une nouvelle validation. 00:11:19.120 --> 00:11:21.580 Bah, c'est une gestion de moins à assurer pour chaque service. 00:11:22.420 --> 00:11:23.300 Parlons maintenant des secrets. 00:11:23.880 --> 00:11:25.560 Clé d'API, chaîne de connexion, certificat. 00:11:25.680 --> 00:11:28.540 Vous ne voulez pas qu'il soit codé en dur dans les fichiers de politique ou le contrôle de source. 00:11:29.020 --> 00:11:30.800 PIM dispose d'une fonctionnalité appelée Valeurs Nommées. 00:11:31.280 --> 00:11:35.040 Vous stockez les secrets de manière centralisée dans PIM et les référencer par leur nom dans vos politiques. 00:11:35.480 --> 00:11:37.400 La valeur réelle n'apparaît jamais dans le code de votre politique. 00:11:37.980 --> 00:11:40.640 Mieux encore, vous pouvez connecter les valeurs nommées à Azure Key Vault. 00:11:40.640 --> 00:11:44.220 Les secrets restent chiffrés dans Key Vault et PIM les récupère lors de l'exécution. 00:11:44.580 --> 00:11:47.280 Personne, pas même votre équipe DevOps, ne voit la valeur réelle du secret. 00:11:47.700 --> 00:11:52.320 Lorsque vous devez renouveler une clé, vous la mettez à jour dans Key Vault et PIM prend en compte le changement automatiquement. 00:11:53.200 --> 00:11:55.060 PIM prend également en charge les identités gérées. 00:11:55.880 --> 00:12:01.700 Cela permet à PIM de s'authentifier auprès d'autres services Azure, comme Key Vault ou une API backend, sans stocker d'identifiant. 00:12:02.360 --> 00:12:04.360 Azure gère l'identité, il vous suffit donc d'accorder les autorisations. 00:12:04.360 --> 00:12:09.380 Et pour l'isolation réseau, vous pouvez déployer APIM au sein d'un réseau virtuel, c'est le niveau premium. 00:12:10.320 --> 00:12:17.080 Ou utiliser Azure Front Door, l'essentiel est que vos services backend n'aient jamais besoin d'être exposés directement à Internet. 00:12:17.960 --> 00:12:19.820 APIM est la seule chose que le monde extérieur peut voir. 00:12:20.480 --> 00:12:22.480 Cette approche multicouche renforce la défense en profondeur. 00:12:23.000 --> 00:12:27.100 Authentification à la passerelle, secret dans un coffre-fort, isolation réseau autour de vos backend. 00:12:27.760 --> 00:12:29.060 Chaque couche renforce la suivante. 00:12:30.260 --> 00:12:31.800 Niveau de tarification, lequel vous convient. 00:12:31.800 --> 00:12:33.620 Alors quel est le coût ? 00:12:33.620 --> 00:12:34.600 Passons en revue les différents niveaux. 00:12:34.920 --> 00:12:35.660 Le niveau consommation. 00:12:36.160 --> 00:12:38.020 Payé par appel API sans coût mensuel fixe. 00:12:38.760 --> 00:12:41.800 Parfait pour les faibles volumes ou les charges de travail irrégulières comme lors du prototypage. 00:12:42.500 --> 00:12:44.260 Si vous n'êtes pas encore sûr de vos besoins, commencez par là. 00:12:44.840 --> 00:12:47.680 Le niveau développeur offre un coût mensuel fixe bas à environ 50$. 00:12:48.360 --> 00:12:49.600 Jeu complet de fonctionnalités mais sans SLA. 00:12:50.020 --> 00:12:51.600 Idéal pour les environnements de développement et de tests. 00:12:51.740 --> 00:12:54.300 Vous bénéficiez de tout ce que propose le niveau premium mais sans pouvoir l'utiliser en produit. 00:12:54.560 --> 00:12:56.340 Le niveau basique est une offre d'entrée de gain pour la production. 00:12:56.760 --> 00:12:59.780 Débit plus faible, pas de support de réseau virtuel mais vous bénéficiez d'un véritable SLA. 00:12:59.780 --> 00:13:03.100 Adapté aux outils internes ou aux petits projets où le réseau privé n'est pas critique. 00:13:04.300 --> 00:13:06.260 La plupart des entreprises optent pour le niveau standard. 00:13:06.860 --> 00:13:10.980 Il inclut la prise en charge des réseaux virtuels, un SLA de 99,89 sans un bon débit. 00:13:11.840 --> 00:13:15.040 Si vous exécutez des API critiques pour votre activité, c'est probablement là que vous vous orienterez. 00:13:15.420 --> 00:13:19.540 Le niveau premium est destiné aux entreprises mondiales ayant besoin d'une fiabilité maximale et de réseaux privés. 00:13:19.540 --> 00:13:25.440 Déploiement multi-région, passerelle auto-hébergée SLA de 99,89 sans injection complète dans un réseau virtuel. 00:13:26.080 --> 00:13:28.060 A partir d'environ 2,700 par mois et par unité. 00:13:28.800 --> 00:13:30.500 Microsoft a également introduit les niveaux V2. 00:13:30.760 --> 00:13:32.680 Basic V2, Standard V2, Premium V2. 00:13:33.400 --> 00:13:36.560 Il simplifie la tarification avec des quotas de requêtes inclus, une facturation par million d'unités excès. 00:13:36.940 --> 00:13:41.900 Au lieu de suivre plusieurs compteurs, vous bénéficiez d'un volume de requêtes claires et payez l'utilisation supplémentaire par palier simple. 00:13:42.480 --> 00:13:43.160 Voici comment choisir. 00:13:43.480 --> 00:13:44.820 Commencez avec le niveau développeur pour les tests. 00:13:45.240 --> 00:13:46.280 Passez au standard pour la production. 00:13:46.880 --> 00:13:49.580 Optez pour le premium si vous avez besoin d'une échelle mondiale ou d'un réseau privé. 00:13:50.180 --> 00:13:52.060 Et n'oubliez pas que vous pouvez toujours migrer vers d'autres niveaux plus tard. 00:13:52.720 --> 00:13:54.200 Commencez petit et évoluez selon vos besoins. 00:13:54.980 --> 00:13:55.800 Voici ce que nous avons couvert. 00:13:56.180 --> 00:14:02.020 La gestion d'API transforme le chaos de nombreuses APIs en un centre de contrôle unique pour la passerelle, les politiques, la sécurité et l'expérience développeur. 00:14:02.500 --> 00:14:04.600 L'essentiel est de retenir qu'il s'agit de bien plus qu'un simple principe. 00:14:05.120 --> 00:14:07.640 Considérez cela comme le cerveau et le système nerveux de votre écosystème d'API. 00:14:07.760 --> 00:14:10.860 Sans cela, chaque équipe crée sa propre authentification, journalisation et limitation de débito. 00:14:10.860 --> 00:14:14.640 Vous vous retrouvez avec des incohérences, des failles de sécurité et aucune vue centralisée de ce qui se passe. 00:14:15.280 --> 00:14:21.100 Avec, vous bénéficiez de cohérence, de sécurité et d'évolutivité, sans réinventer la roue pour chaque service. 00:14:22.060 --> 00:14:22.920 Voici un exercice simple. 00:14:23.460 --> 00:14:25.540 Pensez à une API que vous exposez actuellement directement. 00:14:26.120 --> 00:14:28.000 Peut-être un point de termaison de fonction ou un service d'application. 00:14:28.560 --> 00:14:33.420 Comment le fait de placer la gestion d'API en amont changerait-il votre posture de sécurité et votre capacité à surveiller l'utilisation ? 00:14:33.420 --> 00:14:35.680 Rien que le fait de réfléchir à cet exercice vous en démontrera la valeur. 00:14:36.100 --> 00:14:37.440 Prochaine étape, abonnez-vous à la chaîne. 00:14:37.440 --> 00:14:43.520 Dans les prochains épisodes, nous vous montrerons comment importer une API, appliquer votre première politique et surveiller l'utilisation en temps réel. 00:14:43.900 --> 00:14:45.000 Vous passerez de la théorie à la pratique. 00:14:45.640 --> 00:14:48.300 Si vous avez trouvé cela utile, partagez-le avec quelqu'un qui développe une application. 00:14:48.680 --> 00:14:49.900 Cela leur évitera des mois de mot de tête. 00:14:50.280 --> 00:14:50.900 Merci de nous avoir écouté. 00:14:50.900 --> 00:14:51.900 Merci. 00:14:51.900 --> 00:14:52.900 Merci. 00:14:52.900 --> 00:14:53.900 Merci. 00:14:53.900 --> 00:14:54.900 Merci.