Ollama et LiteLLM : transformer un script Python en véritable chat LLM en console

Dans la deuxième partie du guide sur Ollama et LiteLLM, un simple script Python devient un chat LLM en console. On y ajoute une boucle de conversation, un system prompt et une gestion d'erreurs de base : le squelette minimal sans lequel un assistant local ne ressemble pas à une application. Ce n'est plus une requête isolée au modèle, mais une base pour une interface vivante et pour d'autres expériences avec l'IA locale.

Traité par IA depuis Habr AI ; édité par Hamidun News
Ollama et LiteLLM : transformer un script Python en véritable chat LLM en console
Source : Habr AI. Collage: Hamidun News.
Écouter l'article
Fiche synthèse et chiffres clés
ParamètreDonnées
Source primaireHabr AI ↗
Rédacteur en chef
Chiffre clé #1Une boucle de conversation qui accepte de nouveaux messages jusqu'à la commande de sortie
Chiffre clé #2Un system prompt qui définit le rôle, le ton et les limites de comportement du modèle
Chiffre clé #3Une liste de messages, pour que le modèle voie les échanges précédents et garde le contexte

Dans la deuxième partie du guide consacré à Python, Ollama et LiteLLM, l'auteur passe de l'appel ponctuel au modèle à un véritable chat en console. Le script simple devient la base d'une application d'IA locale, avec un dialogue continu, un rôle système et une protection contre les pannes courantes.

Du script au chat

La première étape ne consiste pas à changer de modèle, mais à changer de scénario d'usage. Une requête unique suffit pour vérifier que l'ensemble Python, Ollama et LiteLLM répond. Mais dès qu'on veut demander une précision, reformuler ou poursuivre une idée, ce type de script atteint vite ses limites.

Le chat en console règle le problème de la façon la plus directe : le programme ne s'arrête pas après une réponse, il reste dans le dialogue et permet de converser avec le modèle comme avec un interlocuteur ordinaire dans le terminal.

Pour le développeur, c'est un tournant important. Au lieu de « j'appelle l'API, je reçois du texte », une interface d'application minimale apparaît : saisie de l'utilisateur, historique des messages, réponse du modèle et logique de contrôle autour. LiteLLM est pratique comme couche unique d'accès aux modèles, tandis qu'Ollama assure l'exécution locale. Résultat : même un petit projet pédagogique commence à ressembler à un vrai produit, que l'on peut déjà lancer, tester et enrichir progressivement sans refaire la base.

Ce qui apparaît dans le code

La couche suivante regroupe les détails qui font du chat plus qu'une boucle d'entrée/sortie : un programme maîtrisé. Dans ce genre d'exemples, ce qui compte n'est pas la fonctionnalité « magique », mais les éléments d'ingénierie de base : qui définit le rôle du modèle, où le contexte est stocké et ce qui se passe quand une requête échoue. C'est ce qui donne l'impression d'une base de travail pour un assistant local plutôt que d'une démo de cinq minutes.

  • Une boucle de conversation qui accepte de nouveaux messages jusqu'à la commande de sortie
  • Un system prompt qui définit le rôle, le ton et les limites de comportement du modèle
  • Une liste de messages, pour que le modèle voie les échanges précédents et garde le contexte
  • Une validation de base de la saisie, pour ne pas envoyer de requêtes vides
  • Une gestion des exceptions, pour que le programme ne plante pas à la première erreur

Chacun de ces points paraît simple, mais ensemble ils changent la qualité de l'interaction. Le system prompt ne sert pas seulement à donner du « caractère » au bot : il permet de fixer les règles de réponse, le format, la langue et les contraintes. L'historique des messages permet de tenir une conversation cohérente au lieu de réexpliquer la tâche à chaque tour. La gestion des erreurs fait gagner du temps au débogage : si le modèle local se fige, si Ollama n'est pas lancé ou si LiteLLM renvoie une exception, la session n'est pas perdue en entier.

Premiers pas vers l'application

Un point à part concerne les premiers pas vers une application d'IA « vivante ». L'interface console paraît modeste, mais c'est là qu'il est le plus simple de vérifier comment le bot se comporte dans un dialogue réel, où l'utilisateur formule ses idées de façon imparfaite, demande des précisions et change sans cesse de contexte.

Les points faibles apparaissent vite : un prompt système trop général, un format de sortie peu pratique, l'absence de commandes pour quitter ou redémarrer, des erreurs peu claires au chargement du modèle.

Ce squelette s'étend facilement sans architecture superflue. On peut y ajouter le streaming de tokens, des commandes comme /clear pour réinitialiser l'historique, le changement de modèle, la journalisation des dialogues ou la connexion d'outils. Mais l'intérêt de cette étape est ailleurs : l'auteur montre qu'une interface utile ne commence pas par une GUI ni par une application web, mais par une boucle de conversation fiable dans le terminal. Si cette couche est soignée, il est plus facile d'évoluer ensuite, aussi bien vers un produit que vers de nouvelles expériences.

Ce que cela signifie

Pour ceux qui construisent des outils d'IA locaux en Python, cette étape est incontournable. L'association d'Ollama et de LiteLLM devient intéressante non pas au moment de la première réponse réussie, mais lorsqu'un vrai circuit de communication se met en place autour du modèle. Le chat en console en est la forme minimale : assez simple pour démarrer et assez utile pour y bâtir la couche suivante de fonctionnalités.

Dossier

Questions clés sur cet article

Que sait-on sur Du script au chat ?

La première étape ne consiste pas à changer de modèle, mais à changer de scénario d'usage. Une requête unique suffit pour vérifier que l'ensemble Python, Ollama et LiteLLM répond. Mais dès qu'on veut demander une précision, reformuler ou poursuivre une idée, ce type de script atteint vite ses limites. Le chat en console règle le problème de la façon la plus directe : le programme ne s'arrête pas après une réponse, il reste dans le dialogue et permet de converser avec le modèle comme avec un interlocuteur ordinaire dans le terminal. Pour le développeur, c'est un tournant imp

Que sait-on sur Ce qui apparaît dans le code ?

La couche suivante regroupe les détails qui font du chat plus qu'une boucle d'entrée/sortie : un programme maîtrisé. Dans ce genre d'exemples, ce qui compte n'est pas la fonctionnalité « magique », mais les éléments d'ingénierie de base : qui définit le rôle du modèle, où le contexte est stocké et ce qui se passe quand une requête échoue. C'est ce qui donne l'impression d'une base de travail pour un assistant local plutôt que d'une démo de cinq minutes. Une boucle de conversation qui accepte de nouveaux messages jusqu'à la commande de sortie Un system prompt qui définit le

Que sait-on sur Premiers pas vers l'application ?

Un point à part concerne les premiers pas vers une application d'IA « vivante ». L'interface console paraît modeste, mais c'est là qu'il est le plus simple de vérifier comment le bot se comporte dans un dialogue réel, où l'utilisateur formule ses idées de façon imparfaite, demande des précisions et change sans cesse de contexte. Les points faibles apparaissent vite : un prompt système trop général, un format de sortie peu pratique, l'absence de commandes pour quitter ou redémarrer, des erreurs peu claires au chargement du modèle. Ce squelette s'étend facilement sans archite

ZK
Zhemal Khamidun — CPO d'Alpina Digital, product manager d'AlpinaGPT. Conçoit des produits IA depuis 2019. Hamidun News est un projet personnel devenu un agrégateur en production avec plus de 6 000 lecteurs.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
Qu'en pensez-vous ?
Chargement des commentaires…