# Compatibilité OpenAI et Ollama

> Comment un service LMSP reste compatible avec les clients OpenAI et Ollama existants grâce à une fine couche de conversion de données au-dessus d’un seul cœur d’exécution, et où s’arrête cette compatibilité.

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

## 8.1 Points de terminaison compatibles OpenAI {#openai}

Un service **DEVRAIT** proposer une interface compatible OpenAI à côté de l’interface LMSP, et la déclarer dans `interfaces` avec `kind` défini à `openai`. Pour couvrir les clients existants, un service qui le fait **DOIT** implémenter au moins ces points de terminaison sous le préfixe `/v1` :

| Point de terminaison | Remarques |
| --- | --- |
| `GET /v1/models` | Liste les modèles du catalogue LMSP. Chaque `id` est l’identifiant de modèle LMSP. |
| `POST /v1/chat/completions` | Chat Completions, avec et sans streaming. |
| `POST /v1/responses` | La forme OpenAI Responses. |
| `POST /v1/embeddings` | L’interface principale de LMSP 1.0 n’a pas de point de terminaison d’embeddings. L’adaptateur sert ce point de terminaison directement, pour les modèles dont `capabilities.embeddings` vaut `true`. |

Ces points de terminaison acceptent les mêmes jetons porteurs que l’interface LMSP. Un client qui parle le protocole OpenAI définit le jeton LMSP comme clé d’API.

Une première implémentation peut commencer par `/v1/models` et `/v1/chat/completions` ([page 12](https://madeforagent.com/fr/lmsp/1.0/mvp.md)).

## 8.2 Points de terminaison compatibles Ollama {#ollama}

Un service **DEVRAIT** aussi fournir ces points de terminaison, afin que les clients écrits pour Ollama fonctionnent eux aussi :

| Point de terminaison | Remarques |
| --- | --- |
| `GET /api/tags` | Liste les modèles du catalogue LMSP. |
| `POST /api/chat` | Chat. |
| `POST /api/generate` | Génération de texte simple. |

Un service qui les fournit déclare une interface avec `kind` défini à `ollama`.

## 8.3 Un seul cœur d’exécution {#core}

La couche de compatibilité **DOIT** se contenter de convertir des données. Elle **NE DOIT PAS** créer une seconde logique de gestion des modèles. Une requête sur une interface de compatibilité est transposée en une réponse LMSP, s’exécute sur le même cœur et le même adaptateur qu’une requête native, et utilise le même catalogue de modèles et la même authentification.

```text
OpenAI Chat Completions
          |  conversion de la requête
          v
     LMSP Response
          |  adaptation au backend
          v
llama.cpp / Ollama / vLLM / autres environnements d’exécution
```

Sur les points de terminaison `/v1` et `/api`, un service **DEVRAIT** signaler les erreurs dans le format que définit l’API correspondante, afin que les clients non modifiés puissent les interpréter. L’interface LMSP utilise toujours `application/problem+json`.

## 8.4 Limites {#boundaries}

La compatibilité a des limites, et il vaut mieux les énoncer clairement :

- Un client compatible OpenAI existant n’a généralement besoin que d’un `base_url` modifié. Il ne bénéficie pas automatiquement de la découverte LMSP.
- Seuls les clients qui prennent en charge LMSP peuvent découvrir un service automatiquement, lire ses capacités détaillées, reprendre des flux d’événements et gérer des tâches asynchrones.
- Aucun protocole côté serveur ne peut faire fonctionner un client qui n’est pas configurable et n’accepte que les adresses officielles du cloud.