Toute l’API ElevenLabs arrive dans le terminal avec un mode agents-as-code

ElevenLabs CLI v1 réunit génération audio et gestion des agents dans une interface en ligne de commande, avec sorties structurées, fichiers versionnables et déploiement par CI/CD.

Générer une voix, transcrire un enregistrement, composer une musique ou modifier un agent ElevenLabs peut désormais se faire depuis le terminal sans écrire directement les requêtes HTTP ni installer un SDK pour chaque opération. ElevenLabs CLI v1 transforme les fonctions publiées dans la spécification OpenAPI de la plateforme en commandes utilisables par une personne, un script ou un agent de code.

L’outil couvre l’ensemble des endpoints publics décrits par ElevenLabs. Une commande peut convertir un texte en parole et enregistrer le résultat dans un fichier, lancer une transcription, produire une musique, gérer des effets sonores, consulter les voix disponibles ou interagir avec les fonctions d’ElevenAgents. Les réponses textuelles peuvent être renvoyées en JSON, tableau, YAML ou CSV, tandis que les contenus binaires sont écrits directement vers le chemin indiqué.

Cette couverture ne correspond pas à l’arrivée de nouvelles fonctions audio. Le CLI constitue une autre interface pour appeler les services existants. Les générations, transcriptions et traitements continuent de s’exécuter sur l’infrastructure d’ElevenLabs, avec les droits, quotas et coûts associés au compte. Installer l’outil ne permet donc pas de faire fonctionner localement les modèles vocaux de l’entreprise.

Le code est publié sur GitHub sous licence MIT. La majeure partie des commandes est générée à partir de la spécification OpenAPI avec Fern. ElevenLabs ajoute par-dessus cette base des workflows écrits spécifiquement pour la gestion locale des agents, des outils et des tests. Cette construction doit permettre à l’interface de suivre l’évolution de l’API sans que chaque commande soit recréée manuellement.

L’installation passe par Homebrew sur macOS et Linux, Scoop sur Windows, ou un script pour les environnements utilisant un terminal Unix ou PowerShell. Le projet est écrit en Rust et peut également être compilé depuis ses sources. Une fois installé, le binaire `elevenlabs` devient accessible globalement.

Pour un usage local, la commande `elevenlabs auth login` ouvre une fenêtre de navigateur et lance une authentification OAuth. La documentation indique que les identifiants sont ensuite conservés dans un fichier local protégé par des permissions restreintes. Le dépôt prévoit également l’utilisation directe de la variable `ELEVENLABSAPIKEY`, d’un fichier `.env` ou d’une clé fournie pour une seule commande.

La variable d’environnement est plus adaptée aux pipelines automatisés. Dans GitHub Actions, par exemple, la clé peut être conservée comme secret, injectée au moment du déploiement puis utilisée pour prévisualiser, appliquer et contrôler la configuration. Un fichier `.env` placé dans le projet demande davantage de prudence : il doit être exclu du dépôt pour éviter de publier les identifiants avec le code.

Le CLI a été conçu pour tenir compte des différences entre une personne et un agent de code. La commande `--help` produit une documentation lisible, tandis que `--schema` renvoie un contrat structuré indiquant les paramètres disponibles, leur emplacement, leur type, les champs obligatoires et la forme attendue de la réponse.

Un agent peut ainsi interroger le schéma avant de construire sa commande au lieu de deviner la syntaxe. Lorsqu’une erreur survient, le programme détecte si la sortie est consultée dans un terminal interactif. Une personne reçoit alors un message formaté avec une piste de correction. Un programme ou un agent obtient plutôt une erreur en JSON, plus facile à analyser avant une nouvelle tentative.

Les commandes acceptent aussi les paramètres directement sous forme de JSON. Les résultats peuvent être transmis à `jq`, intégrés à un script ou enchaînés avec d’autres outils du terminal. L’option d’autopagination permet de récupérer plusieurs pages de résultats et de les diffuser progressivement sous forme de NDJSON.

Le mode `--dry-run` joue un rôle important dans cette automatisation. Il valide localement la requête et affiche l’appel HTTP qui serait envoyé, sans l’exécuter. Pour la synchronisation des agents, il présente également les différences prévues entre les fichiers locaux et la configuration distante.

Cette prévisualisation réduit le risque de modification accidentelle, sans constituer un test complet. Elle ne vérifie pas nécessairement les permissions finales du compte, les quotas, la disponibilité du service ou le comportement réel d’un agent après son déploiement. Une commande valide peut toujours être refusée par l’API ou produire une configuration qui fonctionne mal en conversation.

La principale nouveauté organisationnelle concerne les agents-as-code. La commande `elevenlabs agents init` crée une structure comprenant des registres pour les agents, les outils et les tests, ainsi que des dossiers destinés à leurs configurations respectives. Chaque agent devient un fichier JSON pouvant être placé dans Git, relu lors d’une pull request et associé à une version du produit.

La commande `elevenlabs agents pull` importe les agents d’un workspace dans le projet local. Les fichiers reçus conservent la représentation JSON fournie par l’API afin de pouvoir être renvoyés sans transformation. L’équipe peut ensuite modifier un prompt, changer la voix, sélectionner un autre modèle de langage, ajuster la durée maximale d’un appel ou remplacer un outil.

`elevenlabs agents push --dry-run` compare la configuration locale avec celle du workspace. Après validation, `elevenlabs agents push` applique les changements. Ce fonctionnement intéresse particulièrement les entreprises gérant de nombreux agents ou déployant des configurations similaires dans plusieurs organisations clientes, pour lesquelles une série de modifications manuelles dans un tableau de bord devient difficile à suivre.

La synchronisation demande néanmoins une méthode de travail claire. Par défaut, `agents pull` ignore les agents déjà présents localement. L’option `--update` est nécessaire pour remplacer leurs fichiers par les modifications effectuées depuis le