Cela fait longtemps que l’IT d'entreprise est confrontée à des choix d'infrastructures souvent contradictoires, et les progrès récents ont sans doute aggravé la situation. Le cloud, par exemple, promettait d'améliorer les choses, mais plus de 10 ans d'investissements cloud natif ont compliqué les choses en créant un maquis de microservices, d'API et autres « meilleures pratiques cloud natif ». Et, pour ceux qui comptent sur l'IA pour résoudre tout cela, j'ai une mauvaise nouvelle : Aucun informaticien sain d'esprit ne connectera ChatGPT aux systèmes CRM ou ERP, par manque de gouvernance.

Malgré la complexité, et en dépit d'un environnement macroéconomique quelque peu difficile, « on ne peut pas se soustraire à la nécessité de construire un logiciel de qualité », comme l'a déclaré Matt DeBergalis, CTO et cofondateur d'Apollo GraphQL, lors d'une interview. Ne pas évoluer et garder des composants obsolètes ou trop compliqués sur l’infrastructure ne fonctionnera tout simplement pas. Mais il reste un espoir : GraphQL, qui s’appuie sur une technologie que les développeurs connaissent et apprécient déjà. Elle devrait même être un priorité pour les responsables IT.

La nouveauté n'existe pas

Dans le domaine de l’IT d'entreprise, personne ne peut prétendre créer une application dite « nouvelle ». Comme l'explique James Governor, analyste chez RedMonk, « les nouvelles technologies doivent coexister avec les compétences et les piles technologiques existantes et s'appuyer sur elles ». C'est la raison pour laquelle Cobol coexiste avec Java qui lui-même coexiste avec Rust. C'est aussi la raison pour laquelle une entreprise peut adopter AWS tout en conservant Azure (sans parler de HP-UX, Windows NT, etc.). Il y a très peu de soustraction dans l’IT d'entreprise, c'est presque toujours une question d'addition. C'est là qu'intervient GraphQL. Ce langage de requête flexible pour les API propose aux développeurs d'assembler des services disparates. Auparavant, ils passaient plus des deux tiers de leur temps à écrire un code d'API fragile pour connecter tous ces services. Ce n'est pas une bonne chose. GraphQL rend ces connexions aux services beaucoup plus flexibles. Mais, même cette approche n'est pas suffisante.

Les choses s'améliorent quand on introduit un supergraphe : un réseau unifié ou une couche de composition qui donne aux entreprises la visibilité d’une plateforme sur leurs microservices, leurs sources de données internes et externes, etc. Dans une interview, Matt DeBergalis décrit ce supergraphe comme « une couche d'API composable qui agit comme une plateforme ». Cela fait des années que les jeunes informaticiens branchés de Netflix utilisent ces supergraphes et ont découvert au passage qu’il avait des avantages significatifs. Comme l'explique le Netflix Technology Blog, le supergraphe « résout de nombreux problèmes de cohérence et de vitesse de développement avec des compromis minimes sur des aspects comme l'évolutivité et l'opérabilité ». Mais ce n'est plus seulement l'apanage des jeunes branchés. Selon Apollo GraphQL, l'un des principaux sponsors de GraphQL, la moitié des entreprises du classement Fortune 100 l’utilisent. Comme l'explique le dirigeant, les raisons sont claires : « GraphQL n'est pas uniquement la bonne solution technique pour le développement d'applications, c'est aussi une nécessité stratégique pour l'entreprise ». En effet, jusqu'à présent, les développeurs devaient « écrire à la main d'innombrables back-ends pour les front-ends ou les API d'expérience ». Le passage à une couche d'API composable « supergraphe » aide les développeurs à ce que l'infrastructure de l'entreprise travaille pour eux, et non contre eux. Oui, y compris avec une infrastructure d'IA telle que celle des grands modèles de langage (LLM).

Les complications de l’IA

Comme le souligne Matt DeBergalis, les progrès récents de l'IA générative (genIA) ont suscité un regain d'intérêt massif pour les technologies d'IA chez les développeurs et les chefs d'entreprise. Tout le monde réfléchit à la manière d'utiliser cette IA, mais personne ne pense que c'est une bonne idée de connecter directement les LLM aux systèmes d'entreprise. Il n’existe pas de bonne solution pour ériger des garde-fous et garantir que le LLM n'expose pas par inadvertance les données de l'entreprise. Par exemple, personne n'a encore résolu le problème de l'injection rapide. Tant que ce ne sera pas le cas, les entreprises hésiteront à juste titre à laisser les LLM s'approcher de leurs données les plus sensibles. Même si un supergraphe fédéré n’élimine pas les problèmes d'injection rapide, il apporte des améliorations. Avec la planification des requêtes et le moteur de politique de GraphQL, le supergraphe devient une option crédible pour connecter les LLM aux données et aux services dont les utilisateurs ont besoin pour fournir la prochaine génération d'expériences personnalisées. Certaines entreprises utilisent déjà des LLM pour construire des requêtes pour le graphe, mais elles sont encore relativement limitées. De plus, de nombreux développeurs s'intéressent aux moyens d'intégrer les requêtes LLM dans GraphQL (en voici un bon exemple).

Il reste encore beaucoup à faire, mais nous sommes en bonne voie. Heureusement, les développeurs (et leurs cadres en tenue Armani) n'ont pas besoin de changer leur approche API existante par un supergraphe alimenté par GraphQL. En effet, le CEO d’Apollo GraphQL ne demande pas aux entreprises de renoncer à des décennies d'investissements dans les API. Bien au contraire. Ils essaient de faire en sorte que ces investissements aient plus de valeur. « Dans la pratique, GraphQL est une couche qui donne plus de valeur à ces API », a expliqué le responsable. « REST et GraphQL vont très bien ensemble. Il est donc possible de conserver une ancienne infrastructure HP-UX et les modèles Google Gemini ou Amazon Bedrock, tous connectés de manière utile, avec une gouvernance toujours meilleure pour garantir la sécurité ? Il semble que l’on peut répondre positivement à toutes ces questions.