Les bases techniques de l'API OpenAI et de son écosystème

ChatGPT est une application grand public prête à l'emploi, pensée pour une conversation directe avec un utilisateur. L'API OpenAI donne accès aux mêmes modèles sous-jacents, mais destinés à être intégrés dans un logiciel tiers : un chatbot de support sur un site web, un outil interne de synthèse de documents, une fonctionnalité d'assistance dans une application métier. Utiliser l'API implique d'écrire du code, de gérer l'authentification par clé API et de construire soi-même l'interface utilisateur, l'historique de conversation et la logique métier autour des réponses du modèle. Ce choix a aussi une implication en matière de responsabilité : dans une application construite sur l'API, c'est l'équipe qui développe le produit qui définit les garde-fous, la modération des entrées utilisateur et la gestion des erreurs, alors que ces aspects sont pris en charge nativement dans ChatGPT.

Historiquement, l'intégration se faisait via l'endpoint Chat Completions, où l'application envoie une liste de messages (système, utilisateur, assistant) et reçoit une réponse générée. OpenAI a introduit depuis la Responses API, une interface plus récente pensée pour les usages agentiques : elle unifie l'appel au modèle, l'utilisation d'outils (recherche web, exécution de code, function calling) et le maintien de l'état de conversation côté serveur, ce qui simplifie la construction d'assistants capables d'enchaîner plusieurs étapes de raisonnement et d'action. Chat Completions reste disponible et largement utilisé, mais OpenAI recommande la Responses API pour les nouveaux projets qui ont besoin d'orchestrer des outils. Migrer une intégration existante de Chat Completions vers la Responses API n'est pas toujours nécessaire : pour un cas d'usage simple de génération de texte sans outil ni état de conversation complexe à maintenir, Chat Completions reste une solution robuste et bien documentée.

Le function calling permet de décrire à un modèle un ensemble de fonctions disponibles, avec leur nom, leur objectif et leurs paramètres attendus. Lorsqu'une demande de l'utilisateur correspond à l'une de ces fonctions, le modèle ne l'exécute pas lui-même : il renvoie une réponse structurée indiquant quelle fonction appeler et avec quels arguments, à charge pour l'application d'exécuter réellement cette fonction (interroger une base de données, appeler une API météo, créer un ticket) et de renvoyer le résultat au modèle pour qu'il poursuive la conversation. C'est ce mécanisme qui permet à un assistant de réserver un rendez-vous, de consulter un stock en temps réel ou de déclencher un workflow métier, plutôt que de se limiter à générer du texte. Une application peut enchaîner plusieurs appels de fonctions successifs au sein d'une même conversation, par exemple vérifier d'abord la disponibilité d'un créneau puis confirmer la réservation, le modèle orchestrant la séquence d'appels en fonction des résultats intermédiaires qu'il reçoit à chaque étape.

Un embedding transforme un texte (un mot, une phrase, un document) en un vecteur numérique qui capture son sens : deux textes proches en signification obtiennent des vecteurs proches dans cet espace, même s'ils n'emploient pas les mêmes mots. Cette propriété est à la base de la recherche sémantique, qui retrouve les documents pertinents pour une question sans dépendre d'une correspondance exacte de mots-clés, et du RAG (retrieval-augmented generation), une architecture où l'application récupère d'abord les passages les plus pertinents d'une base documentaire via les embeddings, puis les transmet au modèle en contexte pour qu'il rédige une réponse ancrée sur ces sources plutôt que sur sa seule mémoire d'entraînement. Concrètement, un moteur de recherche interne basé sur les embeddings retrouve des documents pertinents même quand la question posée n'emploie aucun des mots-clés exacts du document source, ce qu'une recherche par mots-clés classique manquerait.

L'usage de l'API est facturé au token, avec des tarifs distincts pour les tokens d'entrée (le prompt et le contexte envoyés) et les tokens de sortie (la réponse générée), et des prix qui varient fortement selon le modèle choisi : un modèle plus capable ou un modèle de raisonnement coûte généralement plus cher par token qu'un modèle plus léger. Maîtriser ce coût passe par le choix du modèle le plus adapté à chaque tâche, la limitation de la longueur du contexte transmis et la mise en cache des réponses répétitives. Le fine-tuning, qui consiste à ré-entraîner légèrement un modèle sur des exemples propres à un cas d'usage, reste une option plus coûteuse et plus lente à mettre en place qu'un prompt bien conçu, à réserver aux situations où le prompting seul ne suffit pas à obtenir la constance de format ou de style recherchée. Avant d'investir dans un fine-tuning, il est recommandé de vérifier que le problème rencontré ne peut pas être résolu par un prompt mieux structuré, des exemples plus représentatifs ou une architecture RAG, des options généralement moins coûteuses à mettre en œuvre et à maintenir dans la durée.