Rust s'impose comme le langage par défaut pour les nouveaux outils en ligne de commande
Rust est devenu le choix par défaut pour les nouveaux outils en ligne de commande livrés en 2026, supplantant discrètement Go, Python et C dans une catégorie où Go avait dominé depuis le milieu des années 2010. Ripgrep, fd, bat, exa/eza, delta, et des dizaines d'utilitaires CLI plus récents sont écrits en Rust — et lorsqu'une équipe lance aujourd'hui un nouveau projet CLI, Rust est de plus en plus le premier langage envisagé, plutôt qu'une alternative de niche.
Ce n'est pas une histoire de cycles de hype. C'est une histoire portant sur un ensemble précis de compromis — la latence au démarrage, la sécurité mémoire et la distribution en binaire unique — qui s'avèrent déterminants pour les outils en ligne de commande, mais bien moins pour les services web où Go domine encore.
Pourquoi les outils CLI privilégient spécifiquement Rust
Un outil CLI est invoqué des milliers de fois par jour par un seul développeur, souvent dans des boucles serrées (pensez à un linter qui s'exécute à chaque sauvegarde de fichier, ou à un outil de recherche intégré dans un script shell). La latence au démarrage s'accumule à cette fréquence d'une façon qui n'a pas d'équivalent pour un serveur web long-running. Rust compile en code natif sans runtime ni ramasse-miettes, ce qui permet à un outil CLI Rust de démarrer en quelques millisecondes — les outils Go démarrent vite eux aussi, mais paient un léger surcoût lié au GC et à l'initialisation du runtime que Rust n'a pas.
La sécurité mémoire sans ramasse-miettes est le second facteur. Les outils CLI traitent fréquemment des entrées non fiables — des chemins de fichiers arbitraires, des fichiers de configuration malformés, des arguments en ligne de commande hostiles. Le modèle de possession de Rust détecte des catégories entières de bugs mémoire à la compilation, ce qui compte davantage pour les outils qui reçoivent des octets bruts depuis internet (pensez à un formateur JSON acceptant des réponses API) que pour, disons, un microservice interne avec une forme d'entrée connue.
Les binaires uniques l'emportent sur les dépendances runtime
L'aspect pratique de la distribution est sans doute plus important que la question des performances. Un outil CLI Rust compile en un seul binaire statique sans aucune dépendance runtime — pas de version d'interpréteur Python à faire correspondre, pas de Node.js à installer, pas de pip install qui casse sur un autre système d'exploitation. cargo install ou un binaire téléchargé, ça fonctionne, point. Pour les outils distribués à des milliers de développeurs aux environnements hétérogènes, cela élimine toute une catégorie de tickets de support.
Les outils Python, en revanche, se cassent régulièrement entre environnements Python 3.9 et 3.11, conflits de dépendances et confusion autour des environnements virtuels — une friction considérable pour un outil censé fonctionner après un simple brew install de deux secondes.
La contrepartie : la courbe d'apprentissage
Rien de tout cela ne signifie que Rust est sans coût. Le borrow checker implique une vraie courbe d'apprentissage, et la vitesse d'itération pour un développeur solo prototypant rapidement un outil est plus lente en Rust qu'en Python ou même en Go, du moins au début. Les équipes rapportent qu'un outil CLI Rust met notablement plus de temps à atteindre une première version fonctionnelle que le même outil en Go — mais la charge de maintenance s'inverse avec le temps, puisque Rust détecte à la compilation des bugs que Go et Python ne feraient remonter qu'à l'exécution, souvent dans le terminal d'un utilisateur plutôt que dans une suite de tests.
L'écosystème a également suffisamment mûri pour que la courbe d'apprentissage soit moins pénalisante qu'il y a cinq ans. Des crates comme clap (parsing des arguments), serde (sérialisation) et anyhow/thiserror (gestion des erreurs) couvrent désormais le même terrain qui nécessitait du boilerplate sur mesure en 2020, ce qui permet à un développeur Rust compétent de monter un outil CLI complet en une après-midi.
Ce que cela signifie pour les équipes qui choisissent une stack
Si vous développez un outil CLI interne qui sera exécuté des milliers de fois par jour par d'autres développeurs, les avantages de Rust en matière de latence au démarrage et de binaire unique sont désormais suffisamment importants pour justifier la courbe d'apprentissage initiale plus prononcée — d'autant que des crates comme clap et serde ont comblé la plupart de l'écart de productivité avec Python. Si votre outil est un script ponctuel exécuté quelques fois, ou si votre équipe n'a aucune expérience de Rust et doit respecter un délai serré, Python ou Go restent la voie pragmatiquement plus rapide — ne réécrivez pas en Rust simplement parce que c'est tendance. Et si vous maintenez déjà un outil CLI en Python qui a dépassé son cas d'usage — démarrage lent, chaîne de dépendances fragile, utilisateurs se plaignant de la friction à l'installation — c'est le signal précis qui justifie une réécriture, pas une préférence générale pour un langage.