Yandex Cloud explique pourquoi le frontend mène l'intégration de l'IA dans DataLens

Yandex Cloud propose de voir l'intégration de réseaux de neurones dans un produit non pas comme une tâche réservée au backend. Dans DataLens, la première couche fonctionnelle de Neuroanalyse a été prise en charge par l'équipe frontend : elle a assemblé l'interface de chat, une couche BFF et la logique de communication avec le modèle, sans attendre une grande restructuration serveur. L'idée est que pour un lancement initial d'une fonction d'IA, ce qui importe plus qu'une architecture parfaite pour les années à venir est une entrée rapide sur le marché avec une zone claire de responsabilité.

Nous parlons de DataLens, le système BI de Yandex Cloud pour visualiser de grands ensembles de données. Au sein du service est apparu le Neuroanalyseur — un assistant qui aide à construire des graphiques, rédiger des formules et résoudre des tâches analytiques en dialogue. Au lieu du schéma classique où le backend assume la responsabilité totale de l'intégration LLM, l'équipe a proposé une approche différente : entre le client et le modèle est apparue une couche BFF, dont le frontend est responsable.

Une telle couche peut être levée sur Node.js, Bun ou une autre pile familière et utilisée comme un serveur séparé orienté vers les besoins de l'interface. L'auteur illustre l'approche avec un projet de démonstration sous la forme d'un monorepo avec Express et React, où un tableau de bord BI fonctionne aux côtés d'un assistant de chat.

Dans ce schéma, le backend existant n'a pas besoin de réécriture urgente. Le BFF stocke les clés d'accès au modèle, gère la limitation de débit, CORS, la journalisation et la surveillance, et gère également le streaming des réponses. Pour les développeurs frontend, ce n'est pas un territoire inconnu : dans de nombreuses équipes produit, ils travaillent depuis longtemps comme des ingénieurs fullstack, maintenant le code serveur, CI/CD et l'infrastructure autour de l'application cliente.

C'est pourquoi la première étape de l'intégration peut se faire plus près de l'interface, où l'effet utilisateur est le plus rapidement visible. Si l'hypothèse ne fonctionne pas, le coût de l'erreur est inférieur à celui d'une refonte profonde du backend principal. Les auteurs de l'approche identifient quatre composants fondamentaux d'une telle intégration.

Premier — un kit d'UI pour l'interface de chat et les éléments connexes : champs de saisie, cartes, listes d'actions, streaming de messages. Deuxième — un SDK pour travailler avec le modèle via l'API ; ce qui importe ici n'est pas le fournisseur spécifique, mais la compatibilité, car de nombreux services répliquent le format de l'API OpenAI. Troisième — le tooling, c'est-à-dire l'appel de fonctions et l'accès du modèle aux fonctions d'application, par exemple l'obtention de données pour un graphique ou l'échantillonnage des 5 meilleurs produits.

Quatrième — le contexte : l'historique de la conversation, l'état de l'application, le code utilisateur, les résultats de calcul et les erreurs dont le modèle a besoin pour une réponse significative. Fondamentalement, ces quatre couches suffisent déjà pour lancer une fonction d'IA fonctionnelle dans l'interface. C'est précisément le contexte que l'auteur considère comme l'argument principal en faveur du frontend.

Les LLMs n'ont pas de mémoire propre, donc à chaque requête, il faut retransmettre l'historique de la conversation et tout ce qui est nécessaire pour une réponse. Dans les produits BI, une portion significative des données réside sur le client : les onglets ouverts, les paramètres actuels du tableau de bord, les fragments de requêtes, les messages d'erreur, les résultats intermédiaires et parfois même des fragments de code utilisateur. Transférer tout cela au backend pour chaque réponse du modèle est coûteux et pas toujours judicieux.

Pendant ce temps, bien que les fenêtres contextuelles des modèles augmentent, elles sont généralement limitées à des dizaines ou des centaines de milliers de tokens, parfois un million, et ne peuvent pas être utilisées sans sélection. De plus, les modèles ont toujours un mauvais rendement sur les calculs précis, ils ont donc besoin non seulement de beaucoup de données, mais de données correctement organisées et d'un accès à des outils qui calculent et récupèrent les faits nécessaires. Pour le marché, c'est un signal important : l'intégration de l'IA dans un produit cesse d'être un monopole du backend et devient une tâche d'ingénierie conjointe, où le frontend peut prendre en charge la phase initiale et livrer l'idée aux utilisateurs plus rapidement.

À mesure que la charge augmente, les opérations d'arrière-plan apparaissent et un couplage plus profond avec les systèmes internes émerge, le rôle du backend, bien sûr, se renforce à nouveau. Mais à un stade initial, c'est précisément cette approche BFF qui permet une vérification plus rapide des scénarios, la collecte d'insights produit et n'étrangle pas le lancement en raison d'une refonte architecturale majeure. Pour les équipes qui cherchent simplement une place pour leur première fonction LLM dans un produit, c'est un moyen pratique de commencer sans surcharge organisationnelle inutile.