# Vue d’ensemble

> Vue d’ensemble du brouillon de LMSP 1.0. Ce qu’est le Local Model Service Protocol, les conceptions sur lesquelles il s’appuie, son architecture en couches, la façon de lire la spécification et les termes employés.

Source: https://madeforagent.com/fr/lmsp/1.0/
Language: fr
Specification: LMSP 1.0 (draft)
Updated: 2026-11-08

## 1.1 Résumé {#abstract}

Le Local Model Service Protocol (LMSP) définit la façon dont les clients trouvent et utilisent les services de modèles de langage qui s’exécutent sur l’appareil ou le réseau local de l’utilisateur. Il spécifie la découverte de services, un catalogue de modèles, la génération synchrone et en streaming, et des tâches asynchrones qui survivent aux redémarrages. Il définit aussi comment un même service propose une interface compatible OpenAI à côté de l’interface LMSP, afin que les clients existants continuent de fonctionner.

LMSP ne remplace ni l’API OpenAI, ni Ollama, ni MCP. Il combine leurs points forts dans une couche de protocole conçue pour un service local résident.

## 1.2 État de ce document {#status}

Ceci est le premier brouillon public de LMSP 1.0, publié le 2026-11-08. « LMSP » est un nom de travail. Le texte est ouvert aux retours et peut changer de façon incompatible jusqu’à ce que la version 1.0 soit définitive.

Le texte anglais fait foi. Les traductions sont fournies par commodité ; en cas de différence, le texte anglais prévaut.

## 1.3 Fondements de la conception {#design-basis}

LMSP réutilise des conceptions éprouvées plutôt que d’en inventer de nouvelles :

- **API OpenAI Responses.** Éléments de sortie structurés, événements sémantiques envoyés par le serveur, et exécution en arrière-plan avec interrogation et annulation pour les travaux de longue durée. C’est la référence de l’interface de conversation principale de LMSP. Voir [les réponses en streaming](https://developers.openai.com/api/docs/guides/streaming-responses) et [le mode arrière-plan](https://developers.openai.com/api/docs/guides/background).
- **Ollama.** Il sert les points de terminaison compatibles OpenAI `/v1/models`, `/v1/chat/completions` et `/v1/responses`, ce qui montre qu’un service associé à une couche d’adaptation OpenAI réduit fortement le coût d’adoption. Voir [la compatibilité OpenAI d’Ollama](https://docs.ollama.com/api/openai-compatibility).
- **Model Context Protocol (MCP).** Sa conception la plus récente abandonne l’initialisation de session obligatoire au profit d’une découverte sans état : chaque requête porte ses propres informations de version, et les clients apprennent les capacités par une interface de découverte. Cela convient aux services locaux, où les redémarrages, les plantages de clients et les connexions interrompues ne doivent pas corrompre l’état du protocole. Voir [MCP](https://modelcontextprotocol.io/).
- **Agent2Agent (A2A).** Les cartes de service, les états de tâche explicites, l’abonnement aux tâches et l’annulation ont inspiré la description de service et le modèle de tâches asynchrones de LMSP. Voir [A2A](https://a2a-protocol.org/).

## 1.4 Architecture {#architecture}

LMSP est organisé en trois couches, au-dessus des adaptateurs qui dialoguent avec les environnements d’exécution des modèles :

```text
+---------------------------------------------------------------+
| Discovery      mDNS / DNS-SD + well-known service document    |
+---------------------------------------------------------------+
| Core           model catalog, responses, SSE, async tasks     |
+---------------------------------------------------------------+
| Compatibility  OpenAI API, optional Ollama API                |
+---------------------------------------------------------------+
| Adapters       llama.cpp, Ollama, vLLM, custom runtimes       |
+---------------------------------------------------------------+
```

- **Découverte.** mDNS/DNS-SD et un document de description de service à une adresse bien connue ([page 3](https://madeforagent.com/fr/lmsp/1.0/discovery.md)).
- **Cœur.** Le catalogue de modèles, les réponses synchrones, les événements envoyés par le serveur et les tâches asynchrones ([pages 5 à 7](https://madeforagent.com/fr/lmsp/1.0/models.md)).
- **Compatibilité.** Une API compatible OpenAI et, en option, une API compatible Ollama ([page 8](https://madeforagent.com/fr/lmsp/1.0/compatibility.md)).
- **Adaptateurs.** Des passerelles vers llama.cpp, Ollama, vLLM ou un environnement d’exécution sur mesure.

Le principe directeur est **un seul cœur d’exécution des modèles, deux familles d’interfaces**. Un service propose l’interface LMSP et l’interface OpenAI au-dessus du même cœur, de sorte qu’il n’y a qu’un seul endroit où les modèles sont chargés, les requêtes exécutées et les tâches suivies.

## 1.5 Vocabulaire de conformité {#conformance}

Les mots-clés **DOIT/DOIVENT** (MUST), **NE DOIT PAS/NE DOIVENT PAS** (MUST NOT), **REQUIS** (REQUIRED), **DEVRAIT/DEVRAIENT** (SHOULD), **NE DEVRAIT PAS/NE DEVRAIENT PAS** (SHOULD NOT), **RECOMMANDÉ** (RECOMMENDED), **PEUT/PEUVENT** (MAY) et **OPTIONNEL** (OPTIONAL) de ce document sont à interpréter comme décrit dans le [BCP 14](https://www.rfc-editor.org/info/bcp14) ([RFC 2119](https://www.rfc-editor.org/rfc/rfc2119), [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174)) lorsque, et seulement lorsque, ils apparaissent en gras et en majuscules. Partout ailleurs, ce sont des mots ordinaires.

Chaque page est marquée comme normative ou informative. Les pages normatives définissent des exigences ; les pages informatives donnent des indications. Les exemples sont informatifs. Le JSON est en UTF-8, et les noms de champ utilisent `snake_case`.

## 1.6 Terminologie {#terminology}

| Terme | Signification |
| --- | --- |
| Service | Un processus résident qui implémente LMSP et exécute des modèles par l’intermédiaire d’adaptateurs. |
| Client | Un logiciel qui découvre et appelle un service : un agent, une application ou un outil. |
| Adaptateur | Le composant qui relie le service à un seul environnement d’exécution de modèles, comme llama.cpp, Ollama ou vLLM. |
| Modèle | Un modèle disponible localement, identifié par un `id` stable. |
| Réponse | Le résultat d’une requête de génération : éléments de sortie, consommation et un état. |
| Tâche | Une exécution asynchrone et persistée d’une requête de réponse, avec un état explicite. |
| Événement | Un événement envoyé par le serveur, avec un numéro de séquence, émis pendant la génération d’une réponse. |
