shell_gpt : générer et exécuter des commandes shell depuis le terminal
A command-line productivity tool powered by AI large language models like GPT-5, will help you accomplish your tasks faster and more efficiently.
En bref
- De quoi s’agit-il ?
- sgpt transforme une phrase en commande shell, avec un aperçu avant exécution. Le projet est utile pour retrouver une syntaxe oubliée, mais il dépend d'une API payante et n'est pas optimisé pour les modèles locaux.
- À qui s’adresse-t-il ?
- Adoptez shell_gpt si vous travaillez déjà avec une clé API OpenAI et voulez générer des commandes shell ou des extraits de code sans quitter le terminal. Évitez-le si vous comptez fonctionner uniquement avec un modèle local, le README indiquant explicitement que le projet n'est pas optimisé pour ces modèles.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 76 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème concret : retrouver une syntaxe oubliée sans quitter le terminal
La situation visée est banale. Vous connaissez l'effet recherché, mais pas la commande exacte. Le README cite l'exemple de find : on sait qu'on veut lister des fichiers JSON, on ne se souvient plus des options. shell_gpt propose de décrire l'intention en langage naturel et de recevoir une commande prête à l'emploi. Le projet annonce couvrir la génération de commandes shell, d'extraits de code et de documentation. Le public visé est donc l'utilisateur de terminal qui accepte d'envoyer une requête à un LLM pour éviter une recherche dans un navigateur. La documentation précise que l'outil est compatible Linux, macOS et Windows, ainsi qu'avec PowerShell, CMD, Bash et Zsh. Ce positionnement explique la forme du paquet : une commande unique, sgpt, qui lit un prompt soit en argument, soit sur l'entrée standard.
Ce que sgpt envoie réellement au modèle
Le mécanisme repose sur une détection du contexte local avant l'appel au modèle. Pour l'option --shell, le README indique que ShellGPT connaît votre système d'exploitation et la valeur de $SHELL. La documentation donne l'exemple d'un même prompt, "update my system", qui produit sudo softwareupdate -i -a sur macOS et sudo apt update && sudo apt upgrade -y sur Ubuntu. Le contexte n'est donc pas seulement le texte de la requête : il inclut des informations sur la machine. Le second point d'architecture est le mode interactif. Par défaut, l'outil n'exécute rien directement. Il affiche la commande proposée puis demande [E]xecute, [D]escribe ou [A]bort. L'option --no-interaction désactive cette étape et écrit la commande sur stdout, ce qui la rend pipable. Le README montre l'usage avec pbcopy pour copier la commande dans le presse-papiers. L'entrée peut aussi venir d'un pipe ou d'une redirection : git diff | sgpt "Generate git commit message, for my changes", docker logs -n 20 my_app | sgpt "check logs, find errors...", ou une redirection classique comme sgpt "summarise" < document.txt. L'outil se comporte donc comme un filtre Unix ordinaire, avec un mode interactif en plus.
Installation et configuration : pip, clé API et fichier .sgptrc
L'installation tient en une commande : pip install shell-gpt. Par défaut, l'outil utilise l'API OpenAI et le modèle GPT-4. Une clé API est nécessaire, et le README renvoie vers la page de génération de clés d'OpenAI. Au premier lancement, la clé est demandée puis stockée dans ~/.config/shell_gpt/.sgptrc. Ce fichier est le point de configuration à connaître, car il contient la clé en clair sur le disque. Le README précise que l'API OpenAI n'est pas gratuite et renvoie à la grille tarifaire d'OpenAI. Pour l'intégration shell, la commande est sgpt --install-integration. Elle ajoute quelques lignes à .bashrc ou .zshrc, et le terminal doit être redémarré. Le raccourci par défaut est Ctrl+l : il remplace le contenu de la ligne de commande en cours par la suggestion, que l'utilisateur peut modifier avant de valider. C'est une différence d'usage notable par rapport au simple appel sgpt : la suggestion arrive dans le tampon d'édition, pas dans un historique séparé. Les options principales sont --shell (ou -s) pour les commandes, --code (ou -c) pour du code pur. Le README montre que la sortie de --code est redirigeable : sgpt --code "solve classic fizz buzz problem using Python" > fizz_buzz.py. Le mode --code accepte aussi un pipe, par exemple cat fizz_buzz.py | sgpt --code "Generate comments for each line of my code".
Le cas des modèles locaux, annoncé comme non optimisé
Le README mentionne la possibilité d'exécuter des modèles open source localement, par exemple avec Ollama, et renvoie à un guide du wiki. La phrase qui suit est sans ambiguïté : ShellGPT n'est pas optimisé pour les modèles locaux et peut ne pas fonctionner comme prévu. C'est une limite réelle, pas une précaution rhétorique. Le comportement décrit dans la documentation (détection de l'OS, génération de commandes exécutables, sortie de code pur) suppose probablement un modèle capable de suivre des instructions de formatage strictes. Rien dans le matériel fourni ne permet de dire quels modèles locaux passent ou échouent, ni dans quelles proportions. Un lecteur qui veut zéro coût d'API et zéro envoi de données à un tiers doit donc considérer cette voie comme expérimentale. Le mode interactif [E]xecute / [D]escribe / [A]bort reste une protection utile quel que soit le backend, mais il ne compense pas un modèle qui produit une commande syntaxiquement valide et sémantiquement fausse. C'est le risque principal de l'outil : une commande plausible, exécutée après une validation humaine trop rapide.
Ce que fait sgpt comparé à un client LLM généraliste
La différence avec un client de chat généraliste tient à trois éléments. D'abord le contexte système : sgpt injecte l'OS et $SHELL dans la requête pour l'option --shell, ce qui oriente la réponse vers une commande adaptée à la machine. Ensuite le mode d'entrée : l'outil lit stdin et se combine avec les pipes, ce qui permet de traiter un diff git, des logs Docker ou un fichier texte sans copier-coller. Enfin le format de sortie : --code demande du code pur, sans commentaire de présentation, ce qui rend la redirection vers un fichier exploitable telle quelle. Un client de chat ne donne pas ces garanties de format. En contrepartie, sgpt reste un outil en ligne de commande : pas d'historique de conversation mentionné dans le matériel fourni, pas de gestion de projet, pas de contexte de dépôt. Il faut le voir comme un générateur ponctuel, pas comme un assistant qui suit un travail sur la durée.
Maintenance, licence et coût d'exploitation
Le projet est publié sous licence MIT, ce qui autorise l'usage, la modification et la redistribution avec conservation de la mention de licence. Le matériel fourni ne contient pas de texte de licence complet, donc les conditions exactes doivent être lues dans le fichier LICENSE du dépôt. Le rythme des versions récentes est irrégulier : 1.4.5 en avril 2025, 1.5.0 en janvier 2026, 1.5.1 en mai 2026. Le dernier push sur la branche main est daté du 2 juillet 2026. Ces dates indiquent un projet encore actif à cette date, mais elles ne disent rien de la qualité des versions. Le coût d'exploitation dépend entièrement du fournisseur d'API choisi. Chaque appel à sgpt, que ce soit pour une commande shell ou du code, consomme des tokens facturés selon la grille d'OpenAI. Un usage intensif dans un script ou une boucle peut donc devenir coûteux, et le README ne propose aucun mécanisme de cache ou de quota visible dans le matériel fourni. La variable de configuration à surveiller est le fichier ~/.config/shell_gpt/.sgptrc, qui détermine le modèle et la clé utilisés.
Quand shell_gpt n'est pas le bon outil
Trois cas de figure écartent sgpt. Le premier est l'environnement sans accès réseau sortant : l'outil dépend d'une API distante par défaut, et la variante locale est annoncée comme non optimisée. Le deuxième est le poste où l'on ne veut pas écrire une clé API en clair dans un fichier de configuration, ce que fait le stockage dans ~/.config/shell_gpt/.sgptrc. Le troisième est l'usage en production automatisée : le mode --no-interaction supprime la confirmation humaine, ce qui est pratique pour piper une commande vers pbcopy, mais risqué si la sortie est exécutée directement. Le README ne décrit pas de mécanisme de validation supplémentaire dans ce mode. Pour les tâches où la commande exacte est déjà connue, l'outil n'apporte rien : il ajoute un appel réseau et une latence là où une page de manuel suffit.
Conclusion éditoriale
Adoptez shell_gpt si vous travaillez déjà avec une clé API OpenAI et voulez générer des commandes shell ou des extraits de code sans quitter le terminal. Évitez-le si vous comptez fonctionner uniquement avec un modèle local, le README indiquant explicitement que le projet n'est pas optimisé pour ces modèles. Avant de l'installer, vérifiez le contenu de ~/.config/shell_gpt/.sgptrc après la première exécution, et gardez en tête que chaque appel à --shell ou --code est facturé par le fournisseur d'API.
Notes de la communauté