JDN innove avec un chatbot RAG grâce à AgentKit d'OpenAI

Le JDN a entrepris de développer un chatbot innovant en utilisant le framework AgentKit d'OpenAI, une initiative qui vise à rendre la conception de chatbots d'IA générative accessible à un plus grand nombre. Lancé en octobre 2025, AgentKit est un SDK qui permet de créer des systèmes d'IA avec un minimum de code, grâce à ses modules complémentaires. Parmi ces modules, Agent Builder offre un canevas visuel pour concevoir des workflows multi-étapes, tandis que ChatKit propose des chatbots facilement intégrables sur une page web. Le JDN a été séduit par l'idée d'utiliser cet outil pour guider ses lecteurs dans le choix d'un modèle d'IA générative, en s'appuyant sur un comparateur recensant plus de 155 modèles.

Le principe de ChatKit

ChatKit repose sur une architecture en trois étapes. La première étape consiste à concevoir un workflow agentique via Agent Builder, l'interface visuelle d'OpenAI qui permet de configurer la logique métier du chatbot sur le principe de N8N. Ensuite, un serveur backend est configuré pour créer des sessions ChatKit et échanger des tokens d'authentification avec l'API OpenAI. Enfin, le widget de chat est intégré sur le site web via quelques lignes de JavaScript et React. Cette architecture permet de déployer un chatbot conversationnel sans avoir à développer l'interface utilisateur de A à Z, OpenAI gérant l'hébergement et la scalabilité du backend.

Sur le papier, l'architecture semble limpide : le widget de chat côté client dialogue avec les serveurs ChatKit d'OpenAI qui gèrent l'inférence, le stockage des fichiers et l'historique des conversations. Entre les deux, un serveur intermédiaire sécurise les échanges en créant les sessions et en gérant l'authentification.

Création du workflow dans Agent Builder

Pour créer le chatbot interactif, le JDN commence par concevoir le workflow de l'agent dans Agent Builder. Le cahier des charges est relativement simple : développer un chatbot capable de conseiller les lecteurs sur le meilleur modèle adapté à leurs besoins spécifiques, en prenant pour référence la base de données des modèles. Celle-ci comprend des paramètres tels que le nom, la modalité d'entrée, la modalité de sortie, le coût (estimé sur une échelle de ???? à ????????????), la nature open source ou propriétaire, la possibilité de fine-tuning, et les scores sur des benchmarks déterminants comme MMLU, LiveCodeBench, SWE Bench Verified, et AIME 2025.

Agent Builder fonctionne avec des modules. Le JDN commence par ajouter un module Guardrails qui permet de filtrer les requêtes des utilisateurs : modération des propos, réduction du risque de jailbreak, détection des textes NSFW et blocage des prompt injections, notamment. Une fois les guardrails passés, trois issues sont possibles : soit la requête est validée, soit elle échoue, soit une erreur se produit. Dans les deux derniers cas, le chatbot informe l'utilisateur qu'il ne peut pas traiter la demande. Lorsque les guardrails sont franchis avec succès, la requête entre dans un module de classification (Classify) qui détermine si la question de l'utilisateur porte sur un modèle d'IA. Si c'est le cas, elle est dirigée vers l'agent IA principal, équipé du RAG et de la base de données, pour formuler une recommandation adaptée. Dans le cas contraire, l'utilisateur est poliment informé que le chatbot est dédié au conseil sur les modèles d'IA et est invité à reformuler sa question.

RAG ou données dans le prompt system ?

Pour la logique de l'agent IA, le JDN s'est interrogé sur l'usage du RAG ou l'ajout direct des données du tableau du guide des modèles dans le prompt système. Les deux méthodes ont leurs avantages et leurs inconvénients. Injecter les données du tableau dans le prompt est l'approche la plus simple. En revanche, cette méthode montre rapidement ses limites dès que le volume de données augmente : coûts et latence plus élevés, maintenance plus complexe lors des mises à jour du guide, et surtout un risque accru de réponses imprécises lorsque le modèle doit raisonner sur plusieurs centaines de lignes simultanément. Cette approche aurait toutefois pu voir son coût partiellement réduit grâce au mécanisme de prompt caching, qui permet de mutualiser le traitement d'un prompt système identique sur plusieurs requêtes, sans pour autant résoudre les limites de fiabilité.

Le RAG ajoute une légère complexité, mais tout à fait gérable : il faut vectoriser le tableau et ajouter le module complémentaire dans Agent Builder. Pour chaque mise à jour, il faut revectoriser le fichier avec les données actualisées. Le jeu en vaut la chandelle pour maximiser l'efficacité du modèle. Le JDN a donc choisi d'opter pour une approche RAG. Pour ce faire, ils se sont rendus dans l'outil de stockage des vecteurs d'OpenAI, le Vector Store. Actuellement, l'outil ne permet pas de vectoriser des données tabulaires au format CSV ou XLSX (Excel) : il gère uniquement les fichiers texte non structurés. Le JDN a choisi de convertir le tableau en JSON (avec un prompt et Claude) pour obtenir un fichier .txt rempli de JSON. Le format JSON a été choisi car il permet de conserver une structure explicite et lisible des champs du tableau (modèle, prix, modalités, etc.) tout en restant compatible avec la vectorisation de fichiers texte non structurés.

De retour dans Agent Builder, un module agent IA est créé pour permettre au modèle de répondre à partir de la requête utilisateur. Le module utilise le File Search en renseignant l'ID du vecteur précédemment créé. Le modèle répondra alors en utilisant les données du fichier du guide des modèles.

Pour le choix du modèle, le JDN a décidé de se tourner vers GPT-5.3-nano plutôt que GPT-4o pour des raisons de coût et de scalabilité future. Le modèle est l'un des moins chers et il devrait être supporté encore quelques mois par OpenAI. Il dispose d'un raisonnement minimal qui lui permettra, si par la suite le JDN le souhaite, d'utiliser la recherche web assez efficacement pour répondre à la demande de l'utilisateur avec plus de précision (en donnant les articles du JDN en source par exemple). Le niveau de raisonnement "low" est activé, le minimum pour utiliser le RAG avec ce modèle.

Le prompt est élaboré en prenant une base rédigée à la main, puis améliorée par Claude pour un meilleur formatage. Le prompt définit précisément l'identité éditoriale de l'agent, sa mission de conseil, son périmètre d'expertise, ses règles de style conversationnel, ainsi que la méthodologie à suivre pour qualifier un besoin avant toute recommandation. À noter que lors des différentes itérations, chaque micro-changement dans le prompt a eu une incidence sur l'ensemble des instructions. Il faut benchmarker et recommencer les tests à chaque nouvelle version.

Structure de notre prompt :

• Rôle/expertise
• Style conversationnel
• Objectif principal
• Valeur ajoutée différenciante
• Autorisations (scope)
• Règles de confidentialité

[RÈGLES DE STYLE]

• Format obligatoire (prose/liste/autre)
• Interdictions formelles
• Limite de tokens/mots

[UTILISATION DES DONNÉES]

• Sources (RAG/web/internal)
• Notation spécifique (étoiles, scores)
• Vérification obligatoire

[RÈGLE FONDAMENTALE]

• Workflow critique (ex : questions avant reco)
• Exceptions au workflow

[APPROCHE CONVERSATIONNELLE]

• Logique d'adaptation (vague→précis)
• Sujets à explorer
• Nombre de questions/interactions
• Hiérarchie de décision (critères ordonnés)
• Logique de tranchage
• Format de présentation résultats
• Proposition après action principale
• Mauvais vs Bon (2-3 cas concrets)
• Données manquantes
• Tentatives d'extraction

Pour des raisons de sécurité, la version actuelle du prompt en production ne peut être diffusée.

Personnaliser l’apparence du chatbot

Une fois la logique métier du bot configurée dans Agent Builder, il est temps de personnaliser l'apparence du chatbot. OpenAI propose une interface très simple d'utilisation dans son playground de ChatKit. Il est possible de configurer le thème en mode nuit ou jour, la couleur générale du bouton d'envoi, la police et la taille de police utilisées, la phrase d'accroche principale, les phrases de démarrage (les exemples), la possibilité d'uploader ou non des fichiers, et bien d'autres paramètres.

Les caractéristiques graphiques validées, il suffit de récupérer le code en cliquant sur la balise de code. L'ensemble de l'interface est donc pré-paramétré dans le code. Le GUI et la logique métier sont désormais configurés, nous pensons ensuite au déploiement, partie la plus technique pour les non-initiés.

Le déploiement sur serveur de développement

Comme expliqué précédemment, le SDK ChatKit d'OpenAI ne peut pas fonctionner uniquement dans le navigateur. La raison est simple : votre clé API OpenAI, celle qui est liée à votre facturation, ne doit jamais se retrouver dans le code côté client. Dans le cas contraire, n'importe quel utilisateur un peu curieux pourrait ouvrir les outils développeur de son navigateur, récupérer cette clé et l'utiliser à vos frais. Pour éviter cela, OpenAI impose un mécanisme de sécurité : vous devez disposer d'un serveur intermédiaire qui détient votre clé API et qui, à chaque nouvelle conversation, contacte OpenAI pour créer une session. OpenAI renvoie alors un token temporaire, valable uniquement pour cet échange, que le serveur transmet au navigateur. Le widget ChatKit utilise ce token éphémère pour fonctionner, et votre clé API principale ne circule jamais côté client.

Pour mettre en place cette architecture, le JDN a commandé un serveur VPS chez OVH, premier prix, quelques euros par mois.