Systèmes d’IA : assistants auto-hébergés, RAG et infrastructure locale

Sommaire

La plupart des configurations locales d’IA commencent par un modèle et un runtime.

Vous téléchargez un modèle quantifié, vous le lancez via Ollama ou un autre runtime, puis vous commencez à formuler des requêtes. Pour des expérimentations, c’est largement suffisant. Mais dès que vous dépassez la simple curiosité — dès que vous vous préoccupez de la mémoire, de la qualité de la récupération, des décisions de routage ou de la prise en compte des coûts — la simplicité commence à montrer ses limites.

Ce cluster explore une approche différente : traiter l’assistant IA non pas comme une simple invocation de modèle, mais comme un système coordonné.

Cette distinction peut paraître subtile au départ, mais elle change entièrement la façon dont vous concevez l’IA locale.

Orchestration de systèmes IA avec LLM locaux, RAG et couches de mémoire

Qu’est-ce qu’un système IA ?

Un système IA est plus qu’un modèle. C’est une couche d’orchestration qui relie l’inférence, la récupération, la mémoire et l’exécution pour former quelque chose qui se comporte comme un assistant cohérent.

Exécuter un modèle localement est un travail d’infrastructure. Concevoir un assistant autour de ce modèle est un travail de systèmes.

Si vous avez déjà exploré nos guides plus larges sur :

vous savez déjà que l’inférence n’est qu’une seule couche de la pile technique.

Le cluster Systèmes IA se situe au-dessus de ces couches. Il ne les remplace pas — il les combine.

Pour une vue d’ensemble transversale de la manière dont ces couches s’articulent dans les assistants de production — LLM, mémoire, outils, routage et observabilité, avec OpenClaw et Hermes comme systèmes de référence — consultez Architecture des assistants IA : LLM, mémoire, outils, routage, observabilité.

Une fois l’architecture de l’assistant solide, l’étape suivante consiste à le rendre proactif. Agents de pollage dans les assistants IA : 11 modèles d’implémentation détaille comment les workers de pollage en arrière-plan, l’exécution par files d’attente, les flux de travail durables et les évaluateurs sémantiques LLM transforment un assistant réactif en un assistant qui surveille, décide et agit de lui-même.

Lorsqu’un seul assistant ne suffit pas et que plusieurs agents doivent se coordonner, le choix du modèle de coordination détermine tout : latence, tolérance aux pannes, coût et débogabilité. Modèles d’orchestration multi-agents : un guide pratique couvre les six modèles canoniques — orchestrator-worker, pipeline séquentiel, fan-out, hiérarchique, essaim et maillage — avec des modes de défaillance spécifiques et un cadre de décision pour choisir la bonne architecture.

OpenClaw : un système d’assistant IA auto-hébergé

OpenClaw est un assistant IA open source, auto-hébergé, conçu pour fonctionner sur plusieurs plateformes de messagerie tout en s’appuyant sur une infrastructure locale.

Concrètement, il :

  • Utilise des runtimes LLM locaux tels qu’Ollama ou vLLM
  • Intègre la récupération sur des documents indexés
  • Maintient une mémoire au-delà d’une seule session
  • Exécute des outils et des tâches d’automatisation
  • Peut être instrumenté et observé
  • Fonctionne dans les limites matérielles

Ce n’est pas juste un habillage autour d’un modèle. C’est une couche d’orchestration qui relie l’inférence, la récupération, la mémoire et l’exécution pour former quelque chose qui se comporte comme un assistant cohérent.

Démarrage et architecture :

Contexte et analyse :

Extension et configuration d’OpenClaw :

Les plugins étendent le runtime OpenClaw — en ajoutant des backends de mémoire, des fournisseurs de modèles, des canaux de communication, des outils web et de l’observabilité. Les compétences étendent le comportement de l’agent — en définissant comment et quand l’agent utilise ces capacités. La configuration de production consiste à combiner les deux, façonnée autour de ceux qui utilisent réellement le système.

Hermes : un agent persistant avec compétences et sandboxing des outils

L’agent Hermes est un assistant auto-hébergé, agnostique par rapport aux modèles, axé sur le fonctionnement persistant : il peut fonctionner comme un processus de longue durée, exécuter des outils via des backends configurables et améliorer les flux de travail au fil du temps grâce à la mémoire et aux compétences réutilisables.

Concrètement, Hermes est utile lorsque vous souhaitez :

  • Un assistant axé sur le terminal qui peut aussi se connecter aux applications de messagerie
  • La flexibilité des fournisseurs via des endpoints compatibles OpenAI et le changement de modèles
  • Des limites d’exécution d’outils via des backends locaux et sandboxés
  • Des opérations de jour deux avec des diagnostics, des journaux et une hygiène de configuration

Les profils Hermes sont des environnements entièrement isolés — chacun avec sa propre configuration, ses secrets, ses mémoires, ses sessions, ses compétences et son état — ce qui fait des profils l’unité réelle de propriété en production, et non la compétence individuelle.

Connaissances persistantes et mémoire

Certains problèmes ne sont pas résolus par une simple fenêtre de contexte plus grande — ils ont besoin de connaissances persistantes (graphes, pipelines d’ingestion) et de plugins de mémoire d’agents (Honcho, Mem0, Hindsight et backends similaires) branchés dans des assistants tels que Hermes ou OpenClaw.

MCP : serveurs du protocole de contexte de modèle

Le protocole de contexte de modèle (Model Context Protocol, MCP) est un standard ouvert introduit par Anthropic pour connecter les modèles de langage IA à des sources de données, des outils et des systèmes externes. Il résout le problème d’intégration N×M en fournissant une interface universelle — pensez-y comme à un port USB-C pour les applications IA. La construction de serveurs MCP vous permet d’étendre les assistants IA avec des intégrations personnalisées pour les fichiers, les bases de données, les API et les outils invocables, en utilisant un simple protocole basé sur JSON-RPC via stdio ou HTTP.

  • Compétences d’agent vs serveurs MCP : cadre de décision — cadre de décision pratique pour savoir quand utiliser les compétences, quand construire des serveurs MCP, et comment le modèle de serveur mince combine les deux
  • Serveur MCP en Go — architecture du protocole, structure des messages JSON-RPC, négociation des capacités, SDK officiel Go et tutoriel pas à pas pour construire des serveurs MCP en Go
  • Construction de serveurs MCP en Python — guide d’implémentation pratique en Python couvrant les serveurs MCP de recherche web et de scraping, les transports stdio et SSE, et l’intégration avec Claude Desktop

A2A : protocole Agent-à-Agent

Le protocole Agent2Agent (A2A) est un standard ouvert pour la communication entre des systèmes d’agents IA déployés indépendamment. Là où MCP connecte un agent à des outils, A2A connecte des agents à d’autres agents — leur permettant de se découvrir via des cartes d’agent, d’échanger des tâches et des messages, de diffuser les progrès et de retourner des artefacts typés. A2A est conçu pour les systèmes où les agents sont possédés par différentes équipes, construits avec différents frameworks ou déployés comme des services séparés qui doivent interopérer.

Ce qui distingue les systèmes IA

Plusieurs caractéristiques méritent qu’on examine les systèmes IA de plus près.

Le routage de modèles comme choix de conception

La plupart des configurations locales par défaut vers un seul modèle. Les systèmes IA permettent de sélectionner les modèles intentionnellement.

Cela introduit des questions :

  • Les petites requêtes doivent-elles utiliser des modèles plus petits ?
  • Quand le raisonnement justifie-t-il une fenêtre de contexte plus grande ?
  • Quelle est la différence de coût par 1 000 jetons ?

Ces questions se rattachent directement aux compromis de performance discutés dans le guide de performance des LLM et aux décisions d’infrastructure décrites dans le guide de hébergement des LLM.

Les systèmes IA mettent ces décisions en lumière au lieu de les cacher.

La récupération est traitée comme un composant évolutif

Les systèmes IA intègrent la récupération de documents, mais pas comme une étape simpliste « embarquer et chercher ».

Ils reconnaissent :

  • La taille des blocs affecte le rappel et le coût
  • La recherche hybride (BM25 + vecteur) peut surpasser la récupération dense pure
  • Le ré-classement améliore la pertinence au prix de la latence
  • La stratégie d’indexation affecte la consommation de mémoire

Ces thèmes s’alignent avec les considérations architecturales plus profondes discutées dans le tutoriel RAG.

La différence est que les systèmes IA intègrent la récupération dans un assistant vivant plutôt que de la présenter comme une démonstration isolée. Deep Research pousse cette idée le plus loin : au lieu d’un seul passage de récupération, le système planifie, se branche, re-vérifie et itère jusqu’à ce que les preuves soient suffisantes. Systèmes de recherche approfondie auto-hébergés : 12 outils comparés passe en revue douze systèmes auto-hébergés — arbres de recherche récursifs, conceptions planificateur-plus-sous-agents et boucles de lacunes de preuves parmi eux — et comment chacun transforme la récupération en une boucle de recherche adaptative.

La mémoire comme infrastructure

Les LLM sans état oublient tout entre les sessions.

Les systèmes IA introduisent des couches de mémoire persistante. Cela soulève immédiatement des questions de conception :

  • Que doit être stocké à long terme ?
  • Quand le contexte doit-il être résumé ?
  • Comment empêcher l’explosion des jetons ?
  • Comment indexer la mémoire efficacement ?

Ces questions intersectent directement les considérations de couche de données du guide d’infrastructure de données. Pour l’agent Hermes en particulier — mémoire bornée à deux fichiers, cache de préfixe, plugins externes — commencez par Système de mémoire de l’agent Hermes et la comparaison transverse des fournisseurs de mémoire d’agents. La capture et la réflexion automatiques peuvent aussi transformer l’inférence du modèle lui-même en « preuve » future — voir Boucles de mémoire auto-renforçantes dans les agents IA pour le mode de défaillance et Mnemosyne pour l’agent Hermes pour une implémentation locale conservatrice. Le pôle mémoire des systèmes IA liste les guides Cognee et de couche de connaissances associés.

La mémoire cesse d’être une fonctionnalité et devient un problème de stockage.

L’observabilité n’est pas optionnelle

La plupart des expérimentations locales d’IA s’arrêtent à « cela répond ».

Les systèmes IA permettent d’observer :

  • Utilisation des jetons
  • Latence
  • Utilisation matérielle
  • Modèles de débit

Cela se connecte naturellement aux principes de surveillance décrits dans le guide d’observabilité.

Si l’IA s’exécute sur du matériel, elle doit être mesurable comme toute autre charge de travail.

Ce que c’est que d’utiliser un système IA

De l’extérieur, un système IA peut encore ressembler à une interface de chat.

Sous la surface, plus de choses se passent.

Si vous lui demandez de résumer un rapport technique stocké localement :

  1. Il récupère les segments de documents pertinents.
  2. Il sélectionne un modèle approprié.
  3. Il génère une réponse.
  4. Il enregistre l’utilisation des jetons et la latence.
  5. Il met à jour la mémoire persistante si nécessaire.

L’interaction visible reste simple. Le comportement du système est en couches.

Ce comportement en couches est ce qui distingue un système d’une démonstration.

Où les systèmes IA se situent dans la pile

Le cluster Systèmes IA se situe à l’intersection de plusieurs couches d’infrastructure :

  • Hébergement de LLM : la couche d’exécution où les modèles s’exécutent (Ollama, vLLM, llama.cpp)
  • RAG : la couche de récupération qui fournit le contexte et l’ancrage
  • Performance : la couche de mesure qui suit la latence et le débit
  • Observabilité : la couche de surveillance qui fournit les métriques et le suivi des coûts
  • Infrastructure de données : la couche de stockage qui gère la mémoire et l’indexation

Comprendre cette distinction est utile. L’exécuter vous-même rend la différence plus claire.

Pour une installation locale minimale avec OpenClaw, consultez le guide de démarrage rapide OpenClaw, qui passe en revue une configuration basée sur Docker utilisant soit un modèle Ollama local, soit une configuration Claude cloud.

Si votre configuration dépend de Claude, ce changement de politique pour les outils d’agents clarifie pourquoi la facturation par API est désormais requise pour les flux de travail OpenClaw tiers.

Ressources liées

A2A : protocole Agent-à-Agent :

Serveurs MCP :

Comparaisons :

Guides d’assistants IA :

Couches d’infrastructure :

S'abonner

Recevez de nouveaux articles sur les systèmes, l'infrastructure et l'ingénierie IA.