L’architecture headless a le vent en poupe

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

L’utilisation massive et croissante des API contribue à l’essor de l’architecture headless et confère à GraphQL une place de choix dans cette architecture applicative néomoderne.

Depuis plus de vingt ans, les changements de paradigme majeurs dans les architectures applicatives ont eu un impact direct sur l’évolution de la mise à disposition des applications. Historiquement, les architectures applicatives appelées à dominer et à influencer notre marché émergent et commencent à le façonner tous les cinq ans, puis s’imposent environ cinq ans plus tard, entraînant à leur tour une évolution du marché de la mise à disposition des applications.

Les microservices (cloud native) ont commencé à susciter l’intérêt du marché en 2015, mais ce n’est qu’en 2020 que le maillage de services et le contrôle des flux entrants ont pris leur essor, orientant ainsi l’évolution du marché de la mise à disposition des applications. Nous observons désormais les premiers signes de l’émergence d’une nouvelle architecture — l’architecture « headless » — qui remplacera les microservices comme principal moteur de la mise à disposition des applications.

D’après les tendances historiques, l’architecture headless s’imposera dans les esprits sur le marché d’ici 2025 et commencera à transformer le marché de la fourniture d’applications. La régularité de ce cycle, conjuguée à l’activité et à l’intérêt croissants du marché pour les API et les technologies de graphes, laisse présager un impact majeur sur la fourniture d’applications d’ici 2030.

Tendances favorisant l’architecture headless

Plusieurs facteurs externes favorisent la convergence de deux tendances technologiques qui entraîneront la prochaine grande évolution de la mise à disposition des applications : la conception axée sur les API et la démocratisation des données.

1. Transformation numérique

La volonté de numériser les activités se traduit par des « services numériques » fournis par une « entreprise numérique ». Les services numériques sont des constructions métier éphémères composées d’applications, de services de mise à disposition des applications, de solutions de sécurité applicative et de données, intégrées, orchestrées et exploitées au moyen d’API. Aujourd’hui, 82 % des organisations fournissent des services numériques à des utilisateurs internes comme externes (SOAS 2022).

Parallèlement, l’adoption des microservices, qui communiquent principalement par l’intermédiaire d’API, a continué de progresser. D’après nos propres recherches, nous estimons que « le nombre d’API publiques et privées approche aujourd’hui les 200 millions et que, d’ici 2031, il pourrait se chiffrer en milliards ».

Tendance : Il en résulte une transition vers les API d’une ampleur telle qu’elle bouleversera le marché mature de la fourniture d’applications, tout comme les technologies mobiles et les microservices ont bouleversé ce marché entre 2010 et 2020.

Décentralisation

La décentralisation résulte d’une activité numérique distribuée, favorisée par le télétravail, l’adoption massive de l’IoT et les préoccupations relatives à la confidentialité des données. Elle est souvent associée aux technologies Web3 telles que la blockchain, ainsi qu’à l’edge computing, notamment dans le cadre de l’IoT industriel. Toutefois, ce sont en réalité les conséquences de la décentralisation qui entraînent des bouleversements. Les données comme les applications se « décentralisent », ce qui engendre les problèmes de performances et de sécurité inhérents à tout système distribué. Cela concerne notamment les 77 % d’organisations qui envisagent de déployer en périphérie des charges de travail de traitement des données et de front-end numérique (SOAS 2022).

Tendance : La décentralisation a des conséquences qui vont au-delà des applications distribuées, puisqu’elle englobe également la possibilité de distribuer les données. Les approches traditionnelles relèguent les données à un niveau protégé, derrière les applications. La décentralisation impose une nouvelle approche dans laquelle les données sont directement accessibles via des API, sans nécessiter d’intermédiaire (application). Cette évolution met fin à l’approche par niveaux de l’architecture applicative et offre aux partenaires externes, aux développeurs tiers et aux consommateurs un accès direct aux données. Les architectures de microservices marquent le début de cette démocratisation des charges de travail au sein de l’architecture applicative. La valeur commerciale actuelle de la démocratisation des données se manifeste également dans les modèles économiques fondés sur l’inversion, c’est-à-dire sur la libération des données via des API afin de créer de la valeur pour les partenaires et les développeurs tiers.

Nous constatons également la valeur commerciale actuelle de la démocratisation des données dans les modèles économiques qui reposent sur l’inversion, c’est-à-dire la mise à disposition des données via des API afin de créer de la valeur pour les partenaires et les développeurs tiers.

Low-Code/No-Code

La numérisation entraîne une demande de talents en ingénierie supérieure à l’offre disponible sur le marché. Les organisations ne peuvent donc pas exploiter les vastes volumes de données générés par leurs activités numériques. Les talents disponibles sont surchargés et souvent incapables de développer des solutions aussi rapidement que l’exigent les besoins de l’entreprise.

Ce déséquilibre entre l’offre et la demande entraîne un essor des solutions low-code/no-code, qui permettent à un plus large éventail d’utilisateurs de développer des solutions et des services. Une étude indique que 75 % des entreprises adopteront un « mélange de low-code/no-code et d’innovation conventionnelle ».

Tendance : Les solutions low-code/no-code reposent sur l’accès à la logique métier et aux données, toutes deux largement accessibles grâce à la démocratisation des données et à une conception privilégiant les API. Le besoin de telles solutions accélère la maturation des tendances liées aux données et aux API.

Le vocabulaire employé sur le marché à propos des API — routeurs, passerelles, intergiciels — est similaire à celui utilisé avant les précédentes évolutions du marché induites par les microservices, la mobilité et les changements architecturaux. L’activité, la terminologie et le rythme de création des API indiquent que cette évolution aura un impact significatif sur les marchés de la fourniture et de la sécurité des applications.

Nous observons déjà les prémices d’une transformation du secteur portée par les API, avec l’apparition de produits et services spécifiquement axés sur l’observabilité des API, leur sécurité, le renseignement sur les menaces et la fédération.

Ces évolutions ne se produisent pas en vase clos. En effet, la transformation de la livraison d’applications induite par les microservices était en grande partie due à l’adoption généralisée de Kubernetes et à sa décision architecturale d’intégrer directement des fonctionnalités traditionnellement proposées par les technologies de livraison d’applications, telles que les contrôleurs d’entrée (routage L7).

La transition vers les API ne fait pas exception, et les tendances actuelles indiquent qu’elle favorisera l’essor de GraphQL, une approche de conception des API qui interagit plus directement avec les données, répond aux problèmes de performances des solutions basées sur REST et, surtout, intégrera des fonctionnalités de mise à disposition des applications à son ensemble de fonctionnalités de base.

Architecture headless

La prédominance des API favorise l’essor de ce que les analystes appellent « l’architecture headless », c’est-à-dire des capacités et des fonctions métier exposées sous forme d’API, sans la couche de présentation traditionnelle. Cette architecture est souvent évoquée dans le contexte des « applications composables », une autre tendance technologique en plein essor sur le marché.

Les architectures headless répondent bien au besoin de solutions low-code/no-code, car les API constituent un moyen pratique de fournir une logique composable et facilement personnalisable sans effort considérable. L’architecture headless permet également de composer des services numériques à partir d’un large éventail d’applications, de services et de systèmes. Elle offre en outre un moyen particulièrement pratique d’intégrer des charges de travail distribuées, comme en témoigne déjà le marché de l’IoT, principalement axé sur les API.

Ainsi, il semble raisonnable d’affirmer que la prochaine évolution des technologies de mise à disposition et de sécurité des applications sera portée par les API, qui favoriseront l’adoption généralisée des architectures headless.

L’impact le plus important concernera les services de mise à disposition et de sécurité des API. Le marché a longtemps considéré les API comme un simple cas d’usage spécialisé de la mise à disposition et de la sécurité des applications web. Cette évolution révélera que les API constituent une catégorie d’entités à part entière, avec des besoins spécifiques en matière de mise à disposition et de sécurité auxquels les moyens traditionnels ne peuvent répondre. Cela est particulièrement vrai lorsqu’on examine l’impact des services de données directement exposés via des API. Pendant la majeure partie de l’histoire, les données n’ont été exposées qu’au travers d’applications. Leur exposition directe via une API constitue en soi une évolution majeure, mais illustre parfaitement pourquoi les API ne sont plus un sous-ensemble des applications web, mais un composant architectural distinct à part entière.

Le rôle de GraphQL dans l’architecture headless

Cette évolution des architectures applicatives intervient également à un moment où les approches en matière d’API connaissent elles aussi une transformation, généralement en réponse à l’évolution de leurs usages. Toutes les API servent en définitive à échanger des données, mais le type et le format de ces données évoluent au fil du temps pour tenir compte des contraintes et des possibilités liées à l’architecture des applications. Par exemple, REST et JSON se sont popularisés parallèlement à l’essor des applications mobiles et des microservices, afin de répondre au besoin d’échanges de données plus fréquents et à la puissance de calcul limitée des plateformes mobiles. SOAP et XML nécessitaient une analyse syntaxique complexe et consommaient une quantité excessive de bande passante. REST et JSON ont allégé cette charge en s’appuyant sur les mécanismes HTTP existants pour décrire les points de terminaison et en adoptant un format de données plus simple avec JSON.

Cependant, SOAP/XML comme REST/JSON nécessitent des compétences traditionnelles en développement, alors que la tendance est au low-code/no-code, qui ne requiert que peu, voire aucune compétence en développement. GraphQL est un langage de requête simple, destiné aux non-développeurs et particulièrement adapté à des outils simples qui le rendent accessible à un plus large éventail d’utilisateurs. Les API deviennent ainsi accessibles et peuvent être assemblées pour créer toutes sortes de services numériques. GraphQL constitue donc un substitut idéal à REST/JSON à mesure que les architectures évoluent vers des modèles reposant exclusivement sur des API (headless).

GraphQL est actuellement la solution privilégiée au problème de la prolifération des API et aux mêmes problèmes de performances qui ont contribué à la transition de la SOA (architecture orientée services) vers REST. GraphQL présente également l’avantage de disposer d’une spécification, qui favorise le développement de solutions low-code/no-code permettant de pallier les difficultés liées à la pénurie de talents.

Enfin, puisque GraphQL interroge les API et que la grande majorité des systèmes de stockage de données sont aujourd’hui accessibles via des API, les solutions basées sur GraphQL peuvent éliminer efficacement l’application intermédiaire et accéder directement à la source de données elle-même. Cela est particulièrement utile pour les applications distribuées qui ont besoin d’un accès rapide et direct aux données situées sur des sites distants.

Cela place GraphQL dans une position idéale pour servir de « passerelle » vers une architecture headless, à l’instar des contrôleurs d’entrée qui se sont imposés comme la « passerelle » vers une architecture de microservices.

Conclusion

On dit que la seule constante est le changement, et cela vaut aussi pour la technologie. Il est rare que les choses restent en l’état plus de quelques années avant que quelqu’un ne change les règles du jeu. Dans le domaine de la mise à disposition et de la sécurité des applications, ces règles sont en partie définies par les architectures applicatives. Ainsi, toute évolution majeure de ces architectures pousse nécessairement la mise à disposition et la sécurité des applications à évoluer elles aussi.

Cette évolution ne se concrétisera pleinement que dans quelques années, mais on peut déjà constater l’impact considérable de technologies telles que GraphQL et les API sur tous les aspects, de l’infrastructure à la périphérie du réseau, en passant par la mise à disposition des applications.

L’architecture headless gagne du terrain, et GraphQL jouera un rôle majeur.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie