# Otoroshi 18 est là : nouvelles fondations, même gateway

> Le plus gros chantier d'Otoroshi depuis des années, pensé pour être la mise à jour la plus ennuyeuse que vous ferez cette année.

- URL: https://blog.cloud-apim.com/otoroshi-18-est-la
- Published: 2026-11-10
- Language: fr
- Authors: Mathieu Ancelin
- Topics: Otoroshi, API gateway, Nouvelles versions, Scala 3, Pekko
- Publisher: Cloud APIM (https://www.cloud-apim.com)

---
Le 23 octobre, nous avons publié Otoroshi 18.0.0, suivie trois jours plus tard de la 18.0.1. C'est la version la plus importante depuis des années, et sans doute la mieux préparée : tout le socle technique a été remplacé, les Service Descriptors ont enfin disparu, et la gateway a traversé deux audits de sécurité complets.

Pourtant, pour la grande majorité des installations, la mise à jour devrait être d'un ennui parfait. Vos routes, vos plugins, vos clés d'API, vos certificats et vos exporteurs ne bougent pas. Votre trafic ne s'aperçoit de rien.

Cet article ouvre une série de sept billets sur Otoroshi 18 et sur ce que nous avons construit autour. On commence par la vue d'ensemble.

## Pourquoi il fallait changer les fondations

Otoroshi tournait sur Scala 2.12, Play 2.8 et Akka 2.6. Chacune de ces briques posait un problème :

- **Scala 2.12** date de 2016. De moins en moins de bibliothèques publient encore pour cette version.
- **Akka** est passé sous licence BSL en septembre 2023. La fondation Apache a repris la dernière version Apache 2.0 sous le nom d'**Apache Pekko**, et l'écosystème a suivi.
- **Play 2.8** n'est plus maintenu, et **Play 3**, la branche basée sur Pekko, est sortie fin 2023.

Pris séparément, chacun de ces points se gère. Ensemble, ils éloignaient Otoroshi du reste de l'écosystème JVM, un peu plus chaque mois. L'issue qui demandait la migration vers Play 3 avait été ouverte en novembre 2023.

Le portage a commencé en juin, et début juillet nous avons gelé les fonctionnalités pour nous y consacrer entièrement. La règle était stricte : changer les fondations, et rien d'autre.

## Ce qui a changé sous le capot

| Avant | Après |
| --- | --- |
| Scala 2.12 | Scala 3.8 |
| Play 2.8 | Play 3.0 |
| Akka 2.6 | Apache Pekko 1.6 |
| Java 11 minimum | Java 17 minimum |
| Interface d'admin construite avec webpack, jQuery | Vite, plus de jQuery |
| Bibliothèques tierces patchées et embarquées | Retour sur les versions officielles |

Pekko est un fork direct de l'Akka que nous utilisions déjà : même modèle d'acteurs, mêmes streams, même pile HTTP. Les noms de packages changent, le comportement reste le même.

## Ce qui disparaît : les Service Descriptors

Les Service Descriptors étaient dépréciés depuis février 2022, quand le nouveau moteur de proxy est arrivé. La version 17 avait livré les outils de migration. La 18 retire l'entité, son API d'admin, ses écrans et sa CRD Kubernetes. Les Routes sont désormais la seule façon de configurer le proxy HTTP : une entité, un modèle mental, un seul chemin de code.

Personne n'a de migration manuelle à faire. Au premier démarrage, un job sauvegarde chaque descriptor dans un fichier, puis le convertit en Route en gardant le même identifiant. Un descriptor n'est supprimé qu'une fois sa Route écrite et relue. Ce qui échoue est laissé en place, journalisé, et retenté au démarrage suivant. Les clés d'API qui pointaient vers un ancien service continuent de fonctionner.

## Ce qui arrive en plus

Une fois le portage validé, nous avons levé le gel. Les previews suivantes ont apporté des nouveautés qui changent la vie des équipes qui publient des API :

- **Chaque consommateur d'API devient une clé d'API**, quel que soit le plan (sans authentification, JWT, mTLS, OAuth2). Quotas, rate limiting et analytics s'appliquent à tous les appelants.
- **Des chaînes de plugins par consommateur** : un plan ou une clé d'API peut apporter ses propres plugins, en plus ou à la place de ceux de la route.
- **Des plugins conditionnels** : n'importe quel plugin peut ne s'exécuter que si des conditions sont remplies sur la clé, l'utilisateur, la route, la requête ou la réponse.
- **Des proxies de confiance** : l'adresse du client est lue depuis le bout fiable de la chaîne `X-Forwarded-For`. Un client ne peut plus choisir son IP pour contourner un rate limit.
- **Un chemin critique plus rapide**, et une JVM dimensionnée automatiquement d'après les limites du conteneur.

Nous détaillerons tout cela dans les prochains articles, à commencer par les performances.

## Vérifier, puis vérifier encore

Un portage de cette taille ne vaut que par les vérifications qui l'accompagnent. Nous avons passé au moins autant de temps à vérifier qu'à écrire.

| Le chantier en chiffres | |
| --- | --- |
| Durée, du premier commit du portage à la sortie | un peu plus de 4 mois |
| Commits | environ 1 000 |
| Issues fermées | 234 |
| Versions de test publiées | 9 previews, 4 release candidates |
| Lignes de tests ajoutées | plus de 70 000 |
| Audits de sécurité complets | 2 |

La suite de tests couvre désormais le clustering, le mTLS, WebAuthn, la validation SAML et les droits de l'API d'admin. Elle écrit et relit le JSON de chaque entité et de chaque configuration de plugin. Ce seul test a révélé des dizaines de réglages qui perdaient leur valeur à l'enregistrement. Aucun ne se serait vu en démo, tous sont corrigés.

Le document OpenAPI de l'API d'admin a été réécrit, et une suite de conformité le confronte désormais à un Otoroshi qui tourne. Chaque désaccord était un bug, d'un côté ou de l'autre, et il a été corrigé là où il devait l'être.

## Qui est derrière

Otoroshi est open source depuis son premier jour, en 2017, sous licence Apache 2.0. Cloud APIM a été fondée en 2021 par son créateur, et c'est chez nous que se fait aujourd'hui l'essentiel de son développement : sur les quelque 1 000 commits de la 18, plus de 800 viennent de l'équipe Cloud APIM. Merci aussi à tous ceux qui ont contribué au code, testé les previews et remonté des bugs.

Le jour de la sortie, nous avons aussi publié trois extensions compatibles avec la 18 : l'extension LLM et son AI Studio, la suite Threat Protection et son Threat Studio, et le tout nouveau Clever Cloud Reaper. Chacune aura son article dans cette série.

## Et maintenant ?

Pour la plupart des installations, la réponse tient en une phrase : passez en 18. Quelques points méritent tout de même un coup d'œil avant :

- Java 17 minimum.
- Les réglages `akka.*` deviennent `pekko.*` (les variables d'environnement `OTOROSHI_AKKA_*` continuent de fonctionner).
- Les plugins Scala maison doivent être recompilés pour Scala 3. Les plugins WASM ne sont pas concernés.
- Sur Kubernetes, appliquez les nouvelles CRD.

La branche 17.x reste disponible pour ceux qui ont besoin de plus de temps. Et si vous préférez ne pas y penser du tout, nos clusters [Otoroshi Managed](https://www.cloud-apim.com/fr/otoroshi-managed) sont mis à jour par l'équipe qui écrit le code.

**Pour aller plus loin**

- [L'article technique complet sur le blog d'Otoroshi](https://www.otoroshi.io/blog/otoroshi-18-new-foundations)
- [Les notes de version de la 18.0.0](https://github.com/MAIF/otoroshi/releases/tag/v18.0.0)
- [Le guide de migration des Service Descriptors](https://www.otoroshi.io/docs/topics/deprecating-sd)
- [La checklist de mise en production](https://www.otoroshi.io/docs/topics/production-checklist)

Prochain article : ce que nous avons mesuré et gagné en performances.