> For the complete documentation index, see [llms.txt](https://guides.ia.numerique.gouv.fr/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://guides.ia.numerique.gouv.fr/albert-api/ressources/changelog.md).
# Changelog
Cette page résume l’évolution fonctionnelle et technique visible d'Albert API.
## Référence de version
La **version d'Albert API** exposée sur `https://albert.api.etalab.gouv.fr/openapi.json` figure dans le champ `info.version` du document (par exemple `0.4.x` selon les déploiements). C’est la **source de vérité** pour les routes et schémas disponibles sur un environnement donné.
***
## Versions
0.9.0 (beta)
**Date de déploiement : 19 octobre 2026**
#### 🔑 Simplification de la gestion des clés
Vous pouvez filtrer les clés dans le playground selon leur statut : active, expirée ou révoquée. Les noms des clés n'ont plus l'obligation d'être uniques. Vous pouvez maintenant renommer vos clés directement depuis le playground.
#### 🔧 Fin du built-in tool `search` dans `/v1/chat/completions`
L’outil `search` sur `POST /v1/chat/completions` (`tools: [{"type": "search", ...}]` et `search_results`) est supprimé. Déprécié depuis la version 0.5.0, nous souhaitons revoir en profondeur le RAG sur Albert API durant les prochaines versions.
Si vous utilisiez l'outil `search` dans vos requêtes, vous devez le remplacer par la combinaison de l'usage de `/v1/search` et `/v1/chat/completion` pour un RAG maîtrisé.
#### ⏱️ Rate limiting
Dorénavant, vous trouverez dans les headers des réponses à vos modèles l'état des limites de votre compte. Vous pouvez ainsi implémenter facilement des systèmes de fallback en cas de dépassement de limite. Chaque réponse inclut désormais également l’en-tête `X-Request-ID` pour identifier la requête.
Les compteurs RPM / RPD / TPM / TPD du routeur ne sont débités qu’après un appel provider réussi. Ils ne sont pas débités sur un `429` ni sur un échec d’inférence.
Si vous coupez le stream du chat en cours de génération, les tokens déjà livrés sont dorénavant comptabilisés dans votre quota.
**💣 Compatibilité Pi / OpenCodeV2 et multi-tools**
Les schémas chat, embeddings et OCR ne documentent plus certains champs. Les clés non déclarées sont toujours relayées au provider, sans valeur par défaut côté gateway.
Cela vise à résoudre les problèmes de compatibilité sur Pi et OpenCodeV2 qui rendaient nécessaire d'utiliser un proxy intermédiaire comme [LLM Proxy](https://codeberg.org/jbousquie/llm-proxy). De même, cela corrige un problème remonté avec le SDK OpenAI qui ne passait pas `parallel_tool_calls=true` quand plusieurs tools étaient définis dans la requête.
#### ❗️ Simplification des types de modèles
Le type de routeur `image-text-to-text` est déprécié, remplacé par `text-generation`. Cela ne conduit à aucun changement fonctionnel.
0.8.0 (beta)
**Date de déploiement : 21 septembre 2026**
#### 📝 Refonte de la page "Usage" du Playground
La page "Usage" du Playground a été entièrement revue pour offrir une vue plus claire et détaillée de votre consommation d'API, clé par clé. Vous pouvez maintenant visualiser plus facilement vos quotas, les consommations par modèle ou par clé, ainsi qu'historiser votre activité. Cette mise à jour vise à simplifier le suivi de votre usage et à améliorer la compréhension de la facturation.
#### 📊 Prise en compte des "completions tokens" dans le calcul TPM/TPD
Le calcul des limites TPM ("tokens par minute") et TPD ("tokens par jour") intègre désormais non seulement les tokens "prompt", mais également les tokens générés en réponse ("completions"). Cette évolution permet un contrôle des quotas plus cohérent avec la consommation réelle de ressources pour l’ensemble des appels. Nous vous invitons à prendre en compte cette modification dans votre suivi et vos intégrations : vos quotas pourront atteindre leur limite plus rapidement si vos générations sont volumineuses.
0.7.0 (beta)
**Date de déploiement : 9 septembre 2026**
La version 0.7.0 d'Albert API homogénéise plusieurs contrats d'API côté compte, usage et clés. Les anciens chemins restent disponibles sous forme d'alias dépréciés lorsque cela est indiqué.
Nous vous invitons à vérifier les changements ci-dessous et à mettre à jour vos intégrations si vous êtes concernés.
#### 📦 Renommage d'endpoints
* L'endpoint `/v1/me/info` est renommé en `/v1/me`. Un alias déprécié est conservé sur l'ancien chemin.
* L'endpoint `/v1/me/keys` est renommé en `/v1/keys`. Un alias déprécié est conservé sur l'ancien chemin.
* L'endpoint `GET /v1/me/usage` est déplacé vers `GET /v1/usage`. Un alias déprécié est conservé sur l'ancien chemin.
0.6.0 (beta)
**Date de déploiement : 31 août 2026**
#### **🔐 Connexion au Playground via ProConnect**
Dans un souci d'améliorer la sécurité d'Albert API, la connexion au Playground se fait désormais via ProConnect, le SSO de l'Etat.
Vos comptes existants et vos clés d'API sont conservés : aucune action de migration n'est nécessaire.
⚠️ Connectez-vous avec l'adresse professionnelle exacte associée à votre compte actuel (celle de votre email de confirmation). Une autre adresse créera un nouveau compte, vide, sans vos clés. **Si votre email Albert API ne correspond pas à votre adresse ProConnect, merci de nous contacter pour faire le matching ().**
Si l'accès vous est refusé, rendez-vous sur notre [FAQ](/albert-api/ressources/faq.md#pourquoi-mon-compte-nest-pas-autorise) pour connaître la démarche à suivre.
#### 🎁 Phase de test pour Gemma 4
Un nouveau modèle vient s'ajouter au catalogue des modèles : `gemma-4-31-b-it`. Ce modèle est candidat au remplacement du modèle `openweight-medium` durant du phase de test allant jusqu'au 1er décembre 2026.
Nous attendons vos retours sur ce nouveau modèle. Vous retrouvez toutes les spécifications techniques de ce modèle dans notre [documentation](/albert-api/modeles/available-models.md#gemma-4-31b-it).
**Retrouvez le calendrier des migrations de modèle dans notre documentation** [**ici**](/albert-api/modeles/available-models.md#calendrier-des-migrations)**.**
0.5.0 (beta)
**Date de déploiement : 27 juillet 2026**
La version 0.5.0 d'Albert API introduit une phase d'expérimentation de nouveaux modèles ainsi que la suppression définitive de plusieurs fonctionnalités dépréciées depuis la version 0.4.1.
#### 🎁 Phase de test de nouveaux modèles
À compter du **25 juillet 2026**, nous lançons une phase de test de trois nouveaux modèles. Cette expérimentation se poursuivra jusqu'au **1er octobre 2026**, date à laquelle nous déciderons, en fonction de vos retours et de nos évaluations, de pérenniser tout ou partie de ces modèles.
**Nous attendons avec impatience vos retours sur le canal de support !**
* [LightOnOCR-2-1B](https://huggingface.co/lightonai/LightOnOCR-2-1B) (`openweight-ocr`)
Ce modèle, accessible via l'endpoint `/v1/chat/completions`, est spécialisé dans l'OCR. Il permet d'extraire du texte à partir d'images, notamment de documents ou de pages de PDF numérisées, grâce à ses capacités multimodales.
Une documentation détaillée sera publiée le **25 juillet**.
* [DeepSeek-V4-Flash](https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash)
Ce modèle de **284 milliards de paramètres** est évalué comme successeur du modèle **Qwen3-Coder-30B-A3B-Instruct** pour les usages liés au développement logiciel.
Si les résultats de la phase de test sont concluants, il remplacera le modèle actuellement proposé sous l'alias `openweight-code`.
**⚠️ Nous ne recommandons pas d'utiliser ce modèle pour d'autres usages que le code.**
* [Qwen3-VL-Embedding-8B](https://huggingface.co/Qwen/Qwen3-VL-Embedding-8B)
Ce modèle d'embeddings multimodal, accessible via l'endpoint `/v1/embeddings`, vous permettra de représenter de manière vectorielle des textes, des images, des screenshots et des vidéos. Cela vous permettra de réaliser dans votre vector store du RAG avec différents formats d'entrée.
Une documentation détaillée sera publiée le **25 juillet**.
#### 🗑️ Suppression de fonctionnalités dépréciées
Comme annoncé lors de la sortie de la version **0.4.1**, plusieurs fonctionnalités dépréciées seront définitivement supprimées avec la version **0.5.0**.
Ces évolutions visent à simplifier et homogénéiser les contrats d'API.
Nous vous invitons à vérifier les changements ci-dessous et à mettre à jour vos intégrations si vous êtes concernés.
* L'argument `collection` de l'endpoint `POST /v1/documents` est supprimé au profit de `collection_id`.
* L'endpoint `GET /v1/chunks/{document}/{chunk}` est remplacé par `GET /v1/documents/{document_id}/chunks/{chunk_id}`.
* L'endpoint `GET /v1/chunks` est remplacé par `GET /v1/documents/{document_id}/chunks`.
* L'endpoint `POST /v1/parse-beta` est supprimé.
* L'argument `collections` de l'endpoint `POST /v1/search` est remplacé par `collection_ids`.
* L'argument `search` de l'endpoint `POST /v1/chat/completions` est supprimé au profit de l'outil `search`, à utiliser via le champ `tools`.
* L'argument `prompt` de l'endpoint `POST /v1/search` est remplacé par `query` et l'argument `collections` par `collections`
* L'argument `collections` de l'endpoint `POST /v1/search` est remplacé supprimé par `collection_ids`.
#### 📦 Fonctionnalité dépréciées
* Le tool `search` de l'endpoint `POST /v1/chat/completions` est déprécié. La fonctionnalité est maintenue pour le moment mais ne fera plus l'objet d'améliorations, elle sera supprimée lors de la version 1.0.0 (Q4 2026). Nous souhaitons privilégier l'usage de la combinaison de l'usage de `/v1/search` et `/v1/chat/completion` pour un RAG maitrisé.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://guides.ia.numerique.gouv.fr/albert-api/ressources/changelog.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.