Gestion d'API : Outils CLI Open Source Gratuits

La gestion d'API signifiait autrefois une console GUI et une facture de fournisseur. Cela existe toujours, mais une grande partie du vrai travail se fait maintenant depuis le terminal. Vous définissez les routes, les plugins et les limites de débit dans un fichier de configuration, le commitez sur Git, et laissez une CLI le pousser vers la passerelle. Pas de clics à travers un tableau de bord, pas de décalage entre ce qui est déployé et ce qui est revu. L'aspect open-source est important ici. Si vous utilisez votre propre passerelle, la licence décide de ce que vous pouvez auto-héberger, forker et déployer sans payer par utilisateur. La plupart des outils ci-dessous sont sous licence Apache 2.0 ou MPL 2.0, ce qui signifie que le code source est disponible, que vous pouvez l'exécuter n'importe où, et qu'il n'y a pas de coût par utilisateur intégré. C'est une approche différente de celle qui consiste à choisir le binaire le plus petit ; ici, les questions sont la licence, l'auto-hébergement et l'activité du dépôt GitHub. Voici une liste de passerelles véritablement open-source avec une vraie histoire en ligne de commande : Kong Gateway OSS avec decK, Tyk, KrakenD Community Edition, Apache APISIX et Gravitee. Pour chacun, vous obtiendrez la licence, ce que fait réellement la CLI, et une commande d'installation et d'exécution réelle que vous pouvez coller. Si vous voulez un champ plus large, le tour d'horizon des outils de gestion d'API open-source couvre les plateformes ; cet article en est la version axée sur le terminal. Le texte officiel de la licence Apache 2.0 vaut la peine d'être parcouru si vous n'avez jamais lu les conditions sur lesquelles vous vous appuyez.

Une note honnête d'emblée. Apidog apparaît à la fin, mais pas en tant qu'entrée open-source, car ce n'en est pas une. C'est un produit commercial avec un niveau gratuit. J'expliquerai où il se situe sans prétendre qu'il est ce qu'il n'est pas.

Qu'est-ce qui rend un outil CLI "open-source" pour la gestion d'API ?

Trois choses séparent une véritable option open-source d'un essai gratuit avec un compte à rebours. Licence. Recherchez Apache 2.0, MIT ou MPL 2.0 sur la passerelle principale, pas seulement sur les SDK clients. Apache 2.0 vous permet d'auto-héberger et de modifier librement. MPL 2.0 (le choix de Tyk) est un copyleft au niveau du fichier ; vous pouvez le combiner avec du code propriétaire tant que les fichiers MPL restent ouverts. Tout ce qui est étiqueté "source-available" ou BSL n'est pas la même chose, alors lisez le fichier LICENSE réel dans le dépôt. Auto-hébergement. La passerelle fonctionne sur votre infrastructure sans que le serveur de licences ne communique avec l'extérieur. Vous contrôlez le plan de données. Si l'"édition communautaire" est tellement limitée qu'elle s'apparente à une démo, elle ne compte pas. Un dépôt maintenu et une CLI fonctionnelle. Vérifiez les étoiles GitHub, mais vérifiez surtout l'historique des commits. Une passerelle que vous pouvez configurer de manière déclarative depuis la ligne de commande, versionner dans Git et exécuter en CI est tout l'intérêt de cette liste. Pour les concepts généraux de gestion derrière tout cela, voir ce que la gestion d'API couvre réellement.

Kong Gateway OSS (avec decK)

Kong Gateway OSS est la version de Kong sous licence Apache 2.0. Kong Inc. continue de distribuer des versions OSS pour les personnes qui ne veulent que du code Apache 2.0, séparément de l'édition Enterprise. La passerelle elle-même est configurée via son API d'administration, mais l'outil que vous utilisez réellement est decK. decK est la CLI de configuration déclarative de Kong. Vous exportez l'état de la passerelle en cours d'exécution dans un fichier YAML, le modifiez et le synchronisez. Il effectue d'abord une comparaison (diff), de sorte que vous voyez exactement ce qui va changer avant que cela ne change, ce qui rend la dérive de configuration visible plutôt que silencieuse.

# Exportez la configuration Kong actuelle vers un fichier
deck gateway dump -o kong.yaml

# Poussez une configuration déclarative vers la passerelle
deck gateway sync kong.yaml

Idéal pour : l'infrastructure-as-code pour Kong. Si vous utilisez déjà Kong et souhaitez que vos routes et plugins soient dans Git avec révision et CI, decK est la solution. Limites honnêtes : c'est spécifique à Kong, et cela gère la configuration plutôt que de faire de la documentation ou des tests. Vous utilisez également la pile complète de Kong, qui est plus lourde qu'une passerelle à binaire unique.

Tyk

La passerelle de Tyk est open source sous licence Mozilla Public License 2.0. La MPL est un copyleft au niveau du fichier : les modifications apportées aux fichiers sous licence MPL doivent rester ouvertes, mais vous pouvez regrouper la passerelle avec des plugins propriétaires tant que ceux-ci résident dans des fichiers séparés. La passerelle principale, écrite en Go, prend en charge REST, GraphQL, TCP et gRPC. La pièce en ligne de commande que la plupart des gens utilisent est le bundler, livré à l'intérieur du binaire de la passerelle depuis la version 2.8. Il regroupe vos plugins middleware personnalisés dans un bundle signé que la passerelle peut charger.

# Construisez un bundle de plugins à partir de votre manifeste et de vos fichiers middleware
tyk bundle build -o bundle.zip

Idéal pour : les équipes qui souhaitent étendre la passerelle avec des plugins d'authentification ou de transformation personnalisés et qui ont besoin d'un moyen reproductible de les empaqueter. Limites honnêtes : la CLI est limitée au regroupement, et non à une configuration déclarative complète de l'ensemble de la passerelle ; une grande partie de la gestion de Tyk s'effectue toujours via son tableau de bord (qui est la partie payante) ou directement via l'API Gateway.

KrakenD Community Edition

KrakenD est une passerelle stateless, haute performance, et la Community Edition offre l'ensemble complet des fonctionnalités principales sous Apache 2.0. Stateless est la partie intéressante : il n'y a pas de base de données. La passerelle est entièrement définie par un fichier de configuration, ce qui en fait un ajustement naturel pour Git et la CI. Le binaire `krakend` est la CLI. Vous validez les configurations avec `check` et exécutez la passerelle avec `run`. Comme c'est un seul binaire Go, l'installation est un seul téléchargement.

# Validez et vérifiez votre configuration avant le déploiement
krakend check -c krakend.json --lint

# Exécutez la passerelle avec cette configuration
krakend run -c krakend.json

La fonctionnalité de configuration flexible (`FC_ENABLE=1`) vous permet de diviser une grande configuration en fichiers templatisés avec des variables, afin de maintenir les environnements DRY. Idéal pour : les passerelles déclaratives et sans état où le fichier de configuration est la seule source de vérité. Limites honnêtes : pas de persistance intégrée ni d'interface utilisateur d'administration dans l'édition CE ; vous composez le comportement dans la configuration plutôt que de cliquer sur des bascules, ce qui est une fonctionnalité si vous aimez l'IaC et une friction si ce n'est pas le cas.

Apache APISIX

Apache APISIX est un projet de la Fondation Apache Software de haut niveau, sous licence Apache 2.0. Cette gouvernance est importante pour la question de l'open-source : c'est un projet de fondation, et non une édition communautaire d'un seul fournisseur, donc la version OSS est le vrai projet plutôt qu'un aperçu allégé. APISIX dispose d'une CLI de contrôle pour les opérations de cycle de vie et d'une API d'administration REST (liée à `127.0.0.1` par défaut) pour gérer les routes et les plugins. La CLI démarre, arrête et recharge la passerelle ; `apisix reload` prend en compte les changements de configuration sans interrompre les connexions.

# Voir les commandes de contrôle disponibles
apisix help

# Démarrez la passerelle, puis rechargez à chaud après un changement de configuration
apisix start
apisix reload

Idéal pour : le routage dynamique à haut débit où vous souhaitez modifier les routes et les plugins à l'exécution sans redémarrage, piloté par l'API Admin. Limites honnêtes : la configuration du routage réside dans l'API Admin plutôt que dans un simple push déclaratif via la CLI, donc votre flux de travail "config dans Git" signifie généralement la scriptisation des appels d'API Admin ou l'ajout d'un outil comme l'ADC d'APISIX par-dessus.

Gravitee

La plateforme de gestion d'API de base de Gravitee est open source sous Apache 2.0. C'est plus qu'une passerelle : la Community Edition comprend la passerelle APIM (le runtime), l'API APIM (une interface de gestion REST) et la console APIM. Les fonctionnalités Enterprise comme les API asynchrones axées sur les événements sont dans l'édition payante, mais le cœur centré sur REST est un véritable OSS que vous pouvez auto-héberger. L'histoire de la ligne de commande nécessite une mise en garde honnête. L'administration quotidienne de Gravitee se fait via son API REST de gestion et sa console, et l'installation officielle auto-hébergée est souvent pilotée par la CLI Docker. Il existe un `graviteeio-cli` maintenu par la communauté sur GitHub qui enveloppe l'API de gestion pour automatiser les actions entre les modules, mais c'est un outil communautaire, pas un binaire propriétaire, donc traitez son état de maintenance comme vous traiteriez tout projet communautaire avant d'en dépendre.

# Exécutez le conteneur de la passerelle Gravitee APIM (auto-hébergé, OSS)
docker run --name gravitee-gateway -p 8082:8082 graviteeio/apim-gateway:latest

Idéal pour : les équipes qui souhaitent une couche de gestion open-source complète (passerelle plus console plus une API de gestion pour le scripting) plutôt qu'un simple proxy. Limites honnêtes : la surface d'automatisation propriétaire est l'API de gestion REST, pas une CLI unique et polie ; la CLI communautaire comble le manque mais vous assumez son risque de maintenance.

Où se situe Apidog (et pourquoi il n'est pas sur la liste open-source)

Apidog n'est pas open source, il ne fait donc pas partie de la liste ci-dessus. C'est un produit commercial avec un niveau gratuit, et je vous induirais en erreur de le classer sous Apache 2.0. Voici quand même le vrai argumentaire. Les outils ci-dessus sont des passerelles ; ils gèrent le trafic, les routes et les plugins. Ils ne conçoivent pas votre schéma d'API, n'exécutent pas vos tests de point de terminaison, ne génèrent pas votre documentation ou ne simulent pas les réponses avant que le backend n'existe. L'assemblage de ces tâches signifie généralement Spectral plus openapi-generator plus un serveur de maquette plus Newman, chacun avec sa propre configuration. Apidog regroupe la conception, les tests, le mocking et la documentation dans un seul espace de travail, et `apidog-cli` vous offre un chemin terminal vers tout cela.

# Installez et authentifiez la CLI Apidog
npm install -g apidog-cli
apidog login --with-token <TOKEN>

# Exécutez un scénario de test en CI (sortir non-zéro en cas d'échec)
apidog run

La CLI génère du JSON structuré avec `agentHints.nextSteps`, de sorte qu'elle s'intègre parfaitement dans la CI et dans les flux de travail d'agents IA ; si vous acheminez le travail d'API via Claude Code ou similaire, la gestion des API sans quitter vos agents IA couvre ce modèle. Elle prend également en charge l'importation et l'exportation d'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écrit les groupes de commandes. Considérez-le comme l'option intégrée gratuite à côté d'une passerelle OSS auto-hébergée, et non comme un remplacement.

Comment choisir

Choisissez en fonction du workflow, pas du nombre d'étoiles. Si vous utilisez déjà Kong, decK est la solution la plus rapide. Si vous voulez une passerelle sans état entièrement définie par un fichier, KrakenD convient. APISIX excelle dans les changements de routage dynamiques et à l'exécution ; Gravitee vous offre une couche de gestion complète avec une console. Pour une comparaison plus large incluant les plateformes commerciales, consultez les meilleurs outils de gestion d'API pour 2026 et l'angle de la gestion d'API sans interface graphique si vous construisez une pile API-first.

En résumé

La gestion d'API open-source via la CLI est mature. Kong Gateway OSS avec decK, Tyk, KrakenD CE, Apache APISIX et Gravitee sont tous sous licence Apache 2.0 ou MPL 2.0, tous auto-hébergeables et tous contrôlables depuis le terminal, ce qui signifie Git, revue et CI au lieu de cliquer sur des tableaux de bord. Choisissez celui dont le modèle correspond à votre façon de déployer. Pour la conception, les tests, le mocking et la documentation que les passerelles ne gèrent pas, un outil intégré comble le fossé. Téléchargez Apidog et exécutez `apidog run` dans votre pipeline pour voir le chemin CLI, puis intégrez-le à votre CI à côté de la passerelle OSS que vous choisirez.