Assistants IA Personnalisés en pratique : le code et les commandes qui comptent vraiment
Assistants IA Personnalisés : l'essentiel en un article — vrai code, schémas et étapes concrètes, extraits d'un cours de 44 leçons.
Pas de théorie interminable ici : on ouvre le terminal et on pratique. Voici l'essentiel de Assistants IA Personnalisés, extrait directement d'un cours complet de 44 leçons — avec du vrai code que tu peux copier-coller maintenant.
- Introduction et Mise en Route
- Concevoir un Assistant Efficace
- Creer des GPTs Personnalises
- Claude Projects et Gemini Gems
- Actions et Outils Externes
Threads, messages et runs
Objectifs pédagogiques
- Créer et gérer un Thread de conversation
- Ajouter des messages utilisateur dans un Thread
- Lancer un Run et gérer son cycle de vie
- Choisir entre polling et streaming
- Récupérer et afficher la réponse de l'assistant
Threads : qu'est-ce que c'est concrètement ?
Un Thread est un conteneur persistant qui stocke l'historique d'une conversation entre un utilisateur et un assistant. C'est OpenAI qui le persiste sur ses serveurs. Vous ne gérez que l'ID.
Bonne pratique : un Thread par session utilisateur. Par exemple, dans votre app, vous créez un Thread quand l'utilisateur commence à converser. Vous stockez le thread_id dans votre base.
| Statut | Signification |
|---|---|
| queued | En file d'attente, va démarrer |
| in_progress | L'assistant génère la réponse |
| requires_action | Function call : votre code doit répondre |
| completed | Terminé avec succès |
| failed | Échec, voir last_error |
| cancelled | Annulé manuellement |
| expired | Timeout (10 minutes) |
Polling : attendre la fin du Run
Le pattern classique consiste à vérifier régulièrement le statut jusqu'à la complétion :
Exemple complet : conversation simple
Un Assistant global
Créez l'Assistant une seule fois et stockez son ID en config.
Un Thread par session
Créez un Thread à la connexion de l'utilisateur, stockez l'ID en BDD.
Retrouver le Thread
À chaque nouveau message, reprenez l'ID stocké pour conserver l'historique.
Limites et quotas
| Aspect | Limite |
|---|---|
| Run timeout | 10 minutes |
| Messages par Thread | Pas de limite stricte, mais à surveiller |
| Threads par compte | Pas de limite stricte |
| Concurrence Runs | Selon tier (10-1000 simultanés) |
| Storage Threads | 30 jours par défaut, purge automatique après |
File search et code interpreter
Objectifs pédagogiques
- Créer un Vector Store et y uploader des fichiers
- Attacher un Vector Store à un Assistant pour le RAG
- Activer Code Interpreter et tester du calcul Python
- Récupérer les fichiers générés par Code Interpreter
- Combiner les deux tools dans un même Assistant
File Search : le RAG natif d'OpenAI
File Search est le tool de RAG natif de l'Assistants API. Vous lui donnez des fichiers, il les indexe automatiquement (chunking, embedding, vector store) et permet à l'Assistant de chercher des passages pertinents.
Différence avec un RAG custom : avec File Search, vous n'avez ni à choisir un chunker, ni à choisir un embedding model, ni à gérer un vector DB. OpenAI fait tout.
Les Vector Stores
Un Vector Store est un conteneur de fichiers indexés, réutilisable entre plusieurs Assistants. Vous le créez une fois, vous y ajoutez vos documents, puis vous l'attachez aux Assistants qui en ont besoin.
Récupérer les citations
Activer Code Interpreter
Uploader un fichier pour Code Interpreter
Function calling et tools personnalisés
Objectifs pédagogiques
- Définir une fonction custom au format JSON Schema
- L'attacher à un Assistant comme tool
- Gérer le statut requires_action et soumettre une réponse
- Définir plusieurs fonctions et les laisser l'Assistant choisir
- Construire un mini-agent qui combine plusieurs tools
Pourquoi du function calling ?
File Search et Code Interpreter sont puissants mais limités : ils accèdent uniquement aux fichiers et à Python local. Pour TOUT le reste (votre BDD interne, vos APIs custom, des actions métier spécifiques), il faut le function calling.
Principe : vous décrivez vos fonctions Python au modèle. Quand il veut les appeler, il retourne le nom de la fonction et les arguments. Vous exécutez la fonction de votre côté et soumettez le résultat.
Définir une fonction au format JSON Schema
Vous décrivez chaque fonction avec un nom, une description, et un schema des paramètres :
Gérer le statut requires_action
Quand l'Assistant décide d'appeler votre fonction, le Run passe au statut requires_action. Vous devez :
Parallélisation des tool_calls
Si l'Assistant demande plusieurs fonctions en même temps (par exemple "donne-moi la météo à Paris ET à Lyon"), vous pouvez les exécuter en parallèle pour gagner en perf :
Mini-agent : combiner tools natifs et fonctions
L'apothéose : un Assistant qui combine file_search, code_interpreter ET vos fonctions custom. Devient un véritable agent.
Cet article couvre les extraits les plus utiles — le cours complet Assistants IA Personnalisés (11 chapitres, 44 leçons, exercices corrigés et projet final) t'emmène jusqu'au bout.
./acceder-au-cours-complet cours gratuit : Ingénierie de promptsFAQ
Combien de temps pour apprendre Assistants IA Personnalisés ?
Faut-il des prérequis ?
Par où commencer concrètement ?
📬 Tu veux recevoir ce type de guide chaque semaine ? Abonne-toi gratuitement — code réel, zéro blabla.