Pourtant, ils ne voient qu’une infime partie des applications.

Même pour des actions aussi simples que l’ajout d’un article dans un panier, la plupart des applications reposent désormais sur une multitude de services et de plateformes distribués sur internet, en général via une API REST.

Tel service de messagerie communique sur le cloud via Twilio, tel site e-commerce traite les paiements via Stripe, tel autre service de livraison vous géolocalise avec Google Maps… La liste des exemples est sans fin. Pour assurer des expériences numériques de qualité, il faut maîtriser le fonctionnement des API. Mais pour garantir le fonctionnement global des applications, il est essentiel d’appréhender l’accessibilité des API sur les réseaux internet et des fournisseurs cloud.

Une opacité bloquante pour résoudre les incidents

En cas de perturbation du flux d’applications, il faut agir vite. Mais les workflows actuels, distribués et complexes, ne permettent pas de déterminer facilement et rapidement la cause d’un incident. Ce qui est gênant lorsque réputation et performances applicatives sont liées !

Les outils actuels de monitoring des réseaux et des applications sont intéressants, mais inadaptés au niveau de visibilité nécessaire pour appréhender un problème, l’escalader correctement et le résoudre sur différents workflows externes. Pour prendre un seul exemple, la capture de paquets et l’analyse des flux ne fonctionnent pas en dehors de votre environnement.

Les entreprises sont donc confrontées à des angles morts qui masquent la plupart des chemins de livraison et, de ce fait, les empêchent d’identifier la source de la majorité des incidents dégradant l’expérience utilisateur. Pourtant, pour escalader et résoudre un problème hors de votre infrastructure, il vous faut des preuves convaincantes.

Sans cela, vous perdrez du temps et de l’argent auprès de services d’assistance impuissants, et vos clients vous quitteront sur une mauvaise expérience.

Mais, comme nous le constatons chez ThousandEyes, la visibilité n’est pas le seul problème. Le cloud n’est jamais stable et les chemins de livraison fluctuent constamment. Si l’API tierce dont vous dépendez est basée en Irlande, par exemple, rien ne garantit qu’elle y restera. Les datacenters ouvrent en grand nombre, puis sont relocalisés ou disparaissent, ce qui peut avoir un impact direct sur le fonctionnement de votre application. Pour résoudre les problèmes qui surviennent, il vous faut des outils plus nombreux et mieux adaptés.

Les analyses synthétiques proposées par les navigateurs sont des outils puissants pour tester les applications et mesurer l’expérience utilisateur sur tous les workflows. Mais il arrive qu’une seule requête déclenche une multitude d’interactions avec l’API dorsale (en backend), invisibles pour l’utilisateur. Ainsi, lorsqu’un client achète un article sur un site e-commerce, l’application déclenche plusieurs appels API pour contrôler le stock, traiter le paiement et générer le numéro de commande avant de diriger le client vers la page de confirmation d’achat. Pour l’utilisateur, ces services en backend sont invisibles, tout comme les pannes ou les ralentissements qui les affectent. Ils ont pourtant un impact direct sur son expérience.

Les propriétaires d’application ont intérêt à privilégier les tests qui intègrent le contexte de l’application principale au lieu de dépendre uniquement des interactions en front-end. Ils pourront ainsi comprendre l’impact du transport réseau sous-jacent (en général, des réseaux de FAI ou de fournisseurs cloud).

Le monitoring d’API personnalisé : une voie à suivre

Pour aller plus loin, il est possible de recourir à la supervision d’API personnalisée. Ici, les appels API sont exécutés en mode séquentiel, conditionnel ou itératif sur vos dépendances d’API. Ce mode de test synthétique, très souple, simule les interactions de l’application backend avec les points de terminaison d’API distants.

Les tests de monitoring d’API peuvent être déployés depuis des points d’observation situés en dehors de l’environnement de l’application ou depuis des agents qui y sont intégrés. Cette dernière méthode présente un net avantage : elle permet en outre de superviser les performances et les chemins réseau spécifiques de l’application jusqu’aux points de terminaison d’API.

Ces outils multiplient les possibilités de test et renforcent la visibilité sur les réseaux externes qui impactent les expériences applicatives. Ils permettent aux propriétaires d’application de mesurer dynamiquement les performances, de traiter distinctement les fonctions itératives et de valider la logique des workflows complexes. Quels en sont les atouts ? Résolution rapide des problèmes, workflows plus rationnels et collecte d’informations précieuses sur les possibilités d’optimisation de l’expérience digitale.