Gestion d'API : Outils CLI Open Source Gratuits

La gestion d’API ne se limite plus à une console graphique et à une facture de fournisseur. Aujourd’hui, un workflow reproductible consiste à définir routes, plugins et limites de débit dans des fichiers de configuration, à les versionner dans Git, puis à les déployer depuis la CLI. Vous réduisez ainsi l’écart entre la configuration revue en pull request et celle réellement exécutée. Pour choisir une passerelle open source, évaluez surtout sa licence, sa capacité d’auto-hébergement et la maturité de son workflow terminal. Cette sélection couvre Kong Gateway OSS avec decK, Tyk, KrakenD Community Edition, Apache APISIX et Gravitee. Pour une vue plus large des plateformes, consultez les outils de gestion d’API open source ; cet article se concentre sur l’automatisation depuis le terminal. Relisez aussi le texte officiel de la licence Apache 2.0 si vous déployez ces composants dans votre infrastructure.

Essayez Apidog dès aujourd’hui

Note : Apidog est présenté à la fin comme outil complémentaire, mais il n’est pas inclus dans la liste open source. Il s’agit d’un produit commercial proposant un niveau gratuit.

Qu’est-ce qui rend un outil CLI réellement open source ?

Avant d’adopter une passerelle, vérifiez ces trois points.

1. La licence de la passerelle principale
   
   Recherchez Apache 2.0, MIT ou MPL 2.0 dans le fichier LICENSE du dépôt principal, pas uniquement dans les SDK.

   • Apache 2.0 : autorise l’auto-hébergement et la modification.
   • MPL 2.0 : copyleft au niveau du fichier ; les modifications des fichiers MPL restent ouvertes, mais vous pouvez ajouter du code propriétaire dans des fichiers séparés.
   • Source-available ou BSL : ce n’est pas équivalent à de l’open source ; lisez les conditions exactes.

2. L’auto-hébergement réel
   
   La passerelle doit fonctionner sur votre infrastructure sans dépendre d’un serveur de licences externe. Vous devez contrôler le plan de données et pouvoir déployer sans coût par utilisateur intégré.

3. Un workflow CLI maintenu
   
   Vérifiez l’activité récente du dépôt, puis testez le chemin concret : configuration déclarative, validation, déploiement et intégration CI. L’objectif est de stocker l’état dans Git et d’automatiser les changements.

Pour le vocabulaire et les responsabilités associées, consultez ce que la gestion d’API couvre réellement.

Kong Gateway OSS avec decK

Kong Gateway OSS est distribué sous licence Apache 2.0. La passerelle expose une API d’administration, mais l’outil pratique pour l’infrastructure-as-code est decK.

Avec decK, vous exportez l’état courant de Kong dans un fichier YAML, vous le versionnez, puis vous synchronisez ce fichier vers la passerelle. La commande de synchronisation calcule d’abord les différences, ce qui permet de détecter la dérive de configuration avant le déploiement.

# Exporter la configuration actuelle de Kong
deck gateway dump -o kong.yaml

# Vérifier les changements attendus
deck gateway diff kong.yaml

# Synchroniser la configuration déclarative
deck gateway sync kong.yaml

Workflow recommandé

1. Exportez l’état existant avec deck gateway dump.
2. Nettoyez et versionnez kong.yaml.
3. Exécutez deck gateway diff dans votre pipeline.
4. Exécutez deck gateway sync uniquement après validation de la pull request.

Idéal pour : gérer les routes et plugins Kong dans Git, avec revue et CI.

Limite : decK est spécifique à Kong et couvre la configuration, pas la documentation ni les tests d’API. La pile Kong reste également plus lourde qu’une passerelle à binaire unique.

Tyk

Tyk Gateway est open source sous licence Mozilla Public License 2.0. La passerelle, écrite en Go, prend en charge REST, GraphQL, TCP et gRPC.

La CLI intégrée cible notamment le packaging de middleware personnalisé. Le bundler, fourni dans le binaire de passerelle depuis Tyk 2.8, prépare un bundle signé que la passerelle peut charger.

# Construire un bundle depuis le manifeste et les middlewares
tyk bundle build -o bundle.zip

Workflow recommandé

1. Écrivez vos middlewares d’authentification ou de transformation.
2. Définissez le manifeste du bundle.
3. Construisez bundle.zip dans CI.
4. Déployez le bundle avec le reste de votre configuration de passerelle.

Idéal pour : les équipes qui étendent Tyk avec des plugins personnalisés et veulent un artefact reproductible.

Limite : la CLI est principalement centrée sur le bundling, pas sur une configuration déclarative complète de la passerelle. Une partie importante de l’administration passe encore par l’API Gateway ou le tableau de bord payant.

KrakenD Community Edition

KrakenD Community Edition est une passerelle stateless sous licence Apache 2.0. Son modèle est particulièrement adapté au config-as-code : il n’y a pas de base de données intégrée, et le comportement de la passerelle est défini par un fichier de configuration.

Le binaire krakend permet de valider puis d’exécuter cette configuration.

# Valider la configuration et appliquer les règles de lint
krakend check -c krakend.json --lint

# Démarrer la passerelle
krakend run -c krakend.json

Pour les configurations plus grandes, activez la configuration flexible afin de découper les fichiers et d’utiliser des variables d’environnement :

FC_ENABLE=1 krakend check -c krakend.json --lint

Workflow recommandé

1. Conservez krakend.json et ses fragments dans Git.
2. Lancez krakend check --lint à chaque pull request.
3. Déployez le même fichier validé avec krakend run.
4. Utilisez des variables et des templates pour séparer les environnements sans dupliquer la configuration.

Idéal pour : une passerelle sans état où le fichier de configuration est l’unique source de vérité.

Limite : pas de persistance intégrée ni d’interface d’administration dans l’édition Community. C’est un avantage pour les équipes IaC, mais une contrainte si vous préférez administrer via une console.

Apache APISIX

Apache APISIX est un projet de la Apache Software Foundation sous licence Apache 2.0. Il ne s’agit pas seulement d’une édition communautaire allégée : la version open source correspond au projet principal.

APISIX combine une CLI de cycle de vie avec une API d’administration REST, liée à 127.0.0.1 par défaut. Utilisez la CLI pour démarrer, arrêter ou recharger la passerelle, et l’API Admin pour gérer routes et plugins dynamiquement.

# Afficher les commandes disponibles
apisix help

# Démarrer la passerelle
apisix start

# Recharger la configuration sans couper les connexions
apisix reload

Workflow recommandé

1. Démarrez APISIX avec apisix start.
2. Gérez les routes et plugins via l’API Admin.
3. Scriptiez les appels API dans vos jobs CI ou utilisez un outil comme ADC.
4. Utilisez apisix reload après un changement de configuration local.

Idéal pour : le routage dynamique à haut débit et les changements de routes à l’exécution.

Limite : le workflow Git nécessite généralement de scriptiser les appels à l’API Admin ou d’ajouter un outil déclaratif au-dessus d’APISIX.

Gravitee

La plateforme de base Gravitee est open source sous licence Apache 2.0. Elle inclut davantage qu’un proxy : la Community Edition fournit la passerelle APIM, l’API de gestion APIM et la console APIM.

L’administration quotidienne passe surtout par l’API REST de gestion et la console. Pour l’exécution auto-hébergée, Docker fournit un chemin simple :

# Exécuter la passerelle Gravitee APIM auto-hébergée
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

Il existe aussi un graviteeio-cli maintenu par la communauté pour automatiser les actions via l’API de gestion. Avant de l’intégrer à un pipeline critique, vérifiez son activité, ses versions et son historique de maintenance comme pour tout dépendance communautaire.

Workflow recommandé

1. Déployez la passerelle via Docker ou votre orchestrateur.
2. Utilisez l’API de gestion REST pour automatiser la création et la publication d’API.
3. Centralisez les scripts d’administration dans votre dépôt.
4. Utilisez la console pour les tâches qui nécessitent une vue d’ensemble.

Idéal pour : les équipes qui veulent une couche de gestion open source complète avec passerelle, API de gestion et console.

Limite : l’automatisation principale repose sur l’API REST plutôt que sur une CLI unique et intégrée.

Où se situe Apidog ?

Apidog n’est pas open source et ne doit donc pas être confondu avec les passerelles précédentes. C’est un produit commercial avec un niveau gratuit.

Les outils présentés plus haut gèrent principalement le trafic, les routes et les plugins. Ils ne remplacent pas un workflow de conception de schéma, de tests de points de terminaison, de mocking ou de génération de documentation. Sans outil intégré, vous assemblez généralement plusieurs composants : Spectral, openapi-generator, un serveur de mocks et Newman.

Apidog regroupe conception, tests, mocking et documentation dans un espace de travail unique. Sa CLI permet d’exécuter ces opérations dans un pipeline.

# Installer et authentifier la CLI
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# Exécuter un scénario de test en CI
# La commande retourne un code non nul en cas d'échec.
apidog run

La CLI produit du JSON structuré avec agentHints.nextSteps, ce qui facilite son utilisation dans la CI ou dans des workflows pilotés par des agents IA. Pour ce type d’intégration, voir la gestion des API sans quitter vos agents IA.

Elle prend également en charge l’import et l’export OpenAPI, l’exécution de scénarios et la gestion des mocks depuis la ligne de commande. Le guide complet de la CLI Apidog détaille les groupes de commandes.

Considérez Apidog comme un complément à une passerelle OSS auto-hébergée, pas comme son remplacement.

Comment choisir

Outil	Idéal pour	Licence	Open source ?	CLI / commande
Kong Gateway OSS + decK	Configuration IaC pour Kong dans Git	Apache 2.0	Oui	deck gateway sync
Tyk	Bundles de plugins personnalisés, multi-protocole	MPL 2.0	Oui	tyk bundle build
KrakenD CE	Passerelle stateless, config-as-code	Apache 2.0	Oui	krakend run
Apache APISIX	Routage dynamique à haut débit	Apache 2.0	Oui, projet ASF	apisix start / apisix reload
Gravitee	Couche de gestion OSS complète avec console	Apache 2.0	Oui, noyau	Docker CLI / API REST
Apidog CLI	Conception, tests, mocks et documentation	Freemium	Non	apidog run

Choisissez selon votre workflow, pas selon le nombre d’étoiles GitHub :

• Vous utilisez déjà Kong : adoptez decK pour versionner et synchroniser la configuration.
• Vous voulez un fichier de configuration unique et une passerelle sans état : choisissez KrakenD.
• Vous devez modifier routes et plugins dynamiquement à l’exécution : regardez Apache APISIX.
• Vous recherchez une plateforme incluant passerelle, console et API de gestion : utilisez Gravitee.

Pour comparer plus largement les plateformes, consultez les meilleurs outils de gestion d’API pour 2026 ainsi que l’approche de la gestion d’API sans interface graphique.

En résumé

La gestion d’API open source depuis la CLI est une approche mature : Kong Gateway OSS avec decK, Tyk, KrakenD CE, Apache APISIX et Gravitee sont auto-hébergeables et utilisables depuis le terminal.

Le point commun utile est simple : versionnez la configuration, validez-la en CI et déployez uniquement l’état revu. Choisissez ensuite le modèle qui correspond à votre architecture :

• Kong + decK pour l’IaC Kong ;
• Tyk pour les bundles de middleware ;
• KrakenD pour une passerelle stateless déclarative ;
• APISIX pour le routage dynamique ;
• Gravitee pour une couche de gestion plus complète.

Pour couvrir conception, tests, mocks et documentation à côté de votre passerelle, téléchargez Apidog et testez apidog run dans votre pipeline CI.