amazon-q-developer-cli : un agent de chat en terminal, désormais en maintenance

Le binaire q et le public visé

Le problème visé est simple à énoncer : garder le contexte d'un projet sans quitter le shell. Le dépôt décrit chat_cli comme « the q CLI, allows users to interface with Amazon Q Developer from the command line ». La cible est donc l'ingénieur qui vit déjà dans un terminal et qui veut poser une question sur un fichier, un extrait de code ou une commande sans ouvrir d'éditeur ni de navigateur. Les sujets déclarés du dépôt (agent, cli, mcp, shell, terminal) confirment ce positionnement : il s'agit d'un outil d'agent, pas d'un plugin d'IDE. C'est un point qui compte, car la valeur d'un tel outil dépend du shell hôte et de la manière dont on enchaîne les commandes, pas de la richesse d'une interface graphique. Un lecteur qui cherche une complétion de code intégrée à son éditeur ne trouvera pas ici ce qu'il attend.

Ce que laisse voir l'arborescence des crates

Le README donne un plan du dépôt plutôt qu'une description d'architecture : chat_cli contient le CLI, crates/ contient tous les crates Rust, scripts/ regroupe les scripts d'exploitation et de build, docs/ contient de la documentation technique. Le langage principal déclaré est Rust, avec TypeScript également listé dans les sujets, ce qui suggère une partie non triviale écrite hors Rust, sans que le matériel fourni permette de dire laquelle. Le point d'entrée est un binaire unique, chat_cli, et les sous-commandes se lancent en passant des arguments après le nom du binaire. C'est tout ce qu'on peut affirmer sur le flux de données interne. Le README ne détaille ni le protocole utilisé pour parler au service, ni la façon dont le contexte du terminal est transmis, ni le rôle exact de MCP dans la boucle. Une revue sérieuse demanderait de lire docs/ et le contenu de crates/, ce que ce matériel ne permet pas.

Installer et compiler : les commandes du dépôt

Pour un utilisateur final, le README ne propose que des canaux préconstruits : une image DMG pour macOS, la commande brew install --cask amazon-q, et pour Linux des liens vers Ubuntu/Debian, AppImage et des builds alternatifs, tous hébergés sur la documentation AWS. Aucune commande d'installation générique n'est donnée dans le dépôt lui-même. Pour un contributeur, la procédure est plus explicite. Il faut cloner le dépôt, installer la chaîne Rust via rustup avec rustup default stable et rustup toolchain install nightly, puis cargo install typos-cli. La compilation et l'exécution se font avec cargo run --bin chat_cli, les tests avec cargo test, les lints avec cargo clippy, le formatage avec cargo +nightly fmt. Les sous-commandes suivent le même schéma : le README donne l'exemple cargo run --bin chat_cli -- login. Les prérequis côté macOS incluent Xcode 13 ou ultérieur et Brew. Notez que le nightly est requis pour le formatage uniquement, ce qui signifie qu'une toolchain stable suffit pour compiler et tester, mais pas pour appliquer le style du projet.

Un dépôt en maintenance, pas en développement

C'est la contrainte dominante, et elle est écrite en tête du README : le projet open source « is no longer being actively maintained and will only receive critical security fixes ». Le même encadré indique qu'Amazon Q Developer CLI est désormais disponible sous le nom Kiro CLI, présenté comme un produit closed source, et que les problèmes doivent être signalés sur le dépôt Kiro. Autrement dit, le dépôt reste lisible, compilable et sous licence permissive, mais il ne faut pas attendre de nouvelles fonctionnalités ni de corrections hors sécurité. Les trois dernières versions listées (v1.19.7, v1.19.6, v1.19.5) sont datées de novembre 2025, alors que le dernier push sur la branche main est daté d'août 2026. Cet écart entre une release et un push plus récent n'est pas expliqué par le matériel fourni ; il peut correspondre à des commits de maintenance ou à des mises à jour d'outillage, mais rien ne permet de le confirmer. Ne l'interprétez pas comme un signe de reprise.

Le cas où ce n'est pas le bon outil

Si votre besoin est un agent de code activement développé, avec des fonctionnalités qui évoluent au rythme des modèles, ce dépôt est le mauvais choix, et le README le dit avant vous. La migration annoncée vers Kiro CLI signifie que toute nouvelle capacité arrivera dans un produit fermé, pas ici. Deuxième cas défavorable : une organisation qui exige un support éditeur contractuel. Le dépôt ne mentionne aucun canal de support commercial pour cette base de code, seulement un fichier SECURITY.md pour les questions de sécurité. Troisième cas : une équipe qui ne peut pas compiler de Rust en interne et qui dépend entièrement des binaires distribués. Elle dépend alors d'une chaîne de publication que le projet ne décrit plus comme active, et dont le sort à moyen terme n'est pas documenté dans ce matériel.

Kiro CLI et la différence de modèle

L'alternative réelle est nommée par le projet lui-même : Kiro CLI. La différence n'est pas une question de fonctionnalités, c'est une question de modèle de distribution. Ici, vous obtenez du code Rust sous double licence MIT et Apache-2.0, que vous pouvez cloner, compiler avec cargo run --bin chat_cli, modifier et redistribuer selon les termes de ces licences. Là, vous obtenez un produit closed source, dont le code n'est pas fourni et dont les correctifs passent par le dépôt de suivi Kiro. Le compromis est net : le dépôt vous donne la maîtrise du binaire et la possibilité de le figer, au prix d'une base qui n'évolue plus ; le produit fermé vous donne un développement actif, au prix de la maîtrise. Il n'existe pas de troisième voie proposée dans ce matériel. Une équipe qui a besoin des deux, code ouvert et développement actif, devra chercher ailleurs, et le README ne l'aide pas sur ce point.

Licences, marques et coût de reprise

Le dépôt est sous double licence MIT et Apache-2.0, avec les fichiers LICENSE.MIT et LICENSE.APACHE à la racine. Ces deux licences sont permissives et permettent le fork et la redistribution, mais le README ajoute une clause sur les marques : les noms et logos AWS ne peuvent pas être utilisés d'une manière susceptible de créer une confusion ou de discréditer AWS. Un fork interne doit donc être renommé, ce qui est une contrainte concrète et non théorique dès qu'on redistribue un binaire. Sur le coût de maintenance, le matériel ne fournit aucune donnée de vulnérabilités, aucun calendrier de fin de support et aucune politique de rétrocompatibilité. Ce qu'on peut dire, c'est que reprendre ce dépôt implique de faire vivre soi-même la chaîne Rust (stable plus nightly pour le formatage), les lints clippy et la suite de tests, sans dépôt amont actif pour absorber les montées de version des dépendances. Ce paragraphe ne constitue pas un avis juridique ; faites relire la clause de marques et le choix entre MIT et Apache-2.0 par qui de droit.

Conclusion éditoriale

Ce dépôt convient à ceux qui veulent un agent de chat en terminal sous licence MIT ou Apache-2.0 et qui acceptent de rester sur une base figée, par exemple pour un usage interne déjà outillé autour de q. Il ne convient pas aux équipes qui cherchent des fonctionnalités nouvelles, puisque le README indique que seuls les correctifs de sécurité critiques seront publiés et que la suite est Kiro CLI, un produit closed source. Avant toute adoption, vérifiez le contenu de SECURITY.md et la version exacte du tag que vous comptez compiler, puis lancez cargo test et cargo clippy sur votre fork pour mesurer ce que vous reprenez réellement.

Sources officielles

1. aws/amazon-q-developer-cli on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases