Une liste d'outils raconte rarement comment quelqu'un apprend. Elle dit qu'il utilise Neovim, un iPad, Krita, un fer à souder ou une table réglable. Elle laisse de côté le plus important : ce que ces outils obligent à comprendre.
Dans une interview publiée par Uses This en mai 2026, Justin Garrison décrit un poste de travail qui ressemble moins à une collection de gadgets qu'à une boucle d'apprentissage.1 Le terminal lui sert à travailler, mais aussi à comprendre Linux. Son garage lui sert à fabriquer, mais sa petite taille lui impose de ranger et de choisir. Ses outils bon marché diminuent le coût d'entrée, puis la panne devient le moment où il décide s'il faut acheter mieux.
L'intérêt d'IRZ n'est donc pas de recommander son setup. C'est de regarder comment un poste de travail peut devenir une architecture d'apprentissage : chaque outil ouvre une pratique, expose une contrainte et produit un prochain problème.
Le terminal comme atelier
Garrison utilise Linux comme système principal depuis son premier ordinateur. Il explique que ce choix lui a appris comment la machine fonctionne et comment la réparer.1 Ce n'est pas une déclaration de préférence logicielle. C'est une relation entre outil et compétence.
Dans son travail professionnel, il passe une grande partie de son temps dans un terminal et développe avec Neovim.1 Il maintient aussi des listes de TUI et de plugins tmux. La liste pourrait ressembler à de la collection. Elle joue plutôt le rôle d'un carnet d'essais : les outils sont assez nombreux pour être comparés, mais le critère reste leur utilité dans une pratique réelle.
Le détail important est que Garrison ne présente pas le terminal comme une interface réservée aux experts. Il le décrit comme l'endroit où son travail et son apprentissage se croisent. Utiliser une distribution Linux, corriger un problème réseau ou tester un outil textuel ne sont pas trois activités séparées. Elles partagent le même environnement et rendent leurs problèmes voisins.
Cela change la manière de penser un poste de travail. Une bonne installation n'est pas celle qui masque toutes les difficultés. C'est celle qui rend certaines difficultés accessibles assez souvent pour qu'elles finissent par devenir familières.
Des outils suffisamment bon marché
Pour ses projets hardware, Garrison dit utiliser beaucoup d'outils sans marque et peu coûteux. Il cite la stratégie d'Adam Savage : acheter la version la moins chère qui permette de commencer, puis réévaluer lorsque l'outil casse.1
Cette méthode n'est pas une apologie du matériel médiocre. Elle déplace le moment de la décision. Au lieu d'acheter une qualité supposée avant d'avoir une pratique, on achète une possibilité d'essai. La panne fournit ensuite une information située : ce qui a cassé, à quel moment, et si cette limite revient assez souvent pour justifier une dépense.
Le principe vaut aussi pour les outils numériques. On peut commencer avec un logiciel qui a des défauts connus, puis observer la friction réelle avant de migrer. La différence est que le numérique cache parfois mieux ses limites : une application peut être présente sans donner accès au problème qui se trouve derrière. Garrison apprécie au contraire les outils qui laissent voir leur fonctionnement, notamment dans l'environnement Linux et le terminal.
Le garage comme contrainte
Son espace de fabrication est un garage rénové, mais seulement la moitié reste disponible : l'autre sert encore au stockage d'une voiture.1 Dans son setup idéal, il voudrait davantage d'espace sur l'établi, de rangement, une fenêtre et des zones séparées pour l'exercice et le tournage.
Ce passage est plus instructif qu'une photo d'atelier parfaitement organisé. Le manque d'espace ne disparaît pas grâce à un nouvel outil. Il modifie la pratique : les projets doivent trouver leur place, le rangement devient une condition de reprise, et l'établi indique ce qui peut être commencé sans tout déplacer.
On peut appeler cela une architecture d'apprentissage parce que la contrainte organise le retour au projet. Un espace trop petit rend visibles les coûts de chaque nouvelle idée. Il faut choisir ce qui reste installé, ce qui peut être démonté, et ce qui mérite une boîte plutôt qu'un coin permanent.
Garrison ne prétend pas que cette contrainte est désirable. Il dit simplement ce qu'il aimerait changer. Cette nuance compte : une limite peut produire une méthode sans devenir une vertu.
Le portable ne remplace pas l'atelier
Son billet consacré à l'iPad Pro montre la même logique par l'échec.2 Il voulait un appareil petit, doté d'un terminal SSH, de Tailscale et d'un clavier assez grand pour écrire. L'iPad répondait à une partie de ces besoins : écran de 11 pouces, Apple Pencil, Procreate, connexion cellulaire et terminal Blink.
Mais le déplacement de fichiers restait pénible, le montage vidéo était limité et la batterie diminuait rapidement pendant les tâches lourdes.2 Les applications fonctionnaient souvent moins bien que leurs versions web ou desktop. Avec iPadOS 26, la gestion des fenêtres est devenue la dernière friction qui l'a convaincu de revenir à un ordinateur portable.
Le résultat n'est pas « l'iPad est mauvais ». C'est plus intéressant : un appareil peut être excellent pour dessiner ou écrire et pourtant échouer comme poste de travail lorsque les tâches changent de nature. Garrison avait besoin de passer d'une activité de création à des opérations réseau et hardware qui demandaient un terminal local, des interfaces filaires et des outils absents d'iPadOS.
Le setup n'est donc pas une identité. Il est une hypothèse à tester contre le travail réel. L'iPad a tenu dix-huit mois, suffisamment longtemps pour produire une réponse détaillée plutôt qu'une impression de premier jour.
La liste devient une boucle
Ce que Uses This documente vraiment est une boucle : choisir un outil assez accessible, l'utiliser dans une situation concrète, rencontrer une limite, puis décider si cette limite mérite une réparation, un contournement ou un changement de matériel.
La boucle est réutilisable, mais ses résultats restent personnels. Le bon outil dépend de la taille du garage, du type de fichiers, du besoin de réseau, du dessin, du montage ou du niveau de tolérance aux pannes. L'article ne permet pas de conclure que Linux, Neovim ou l'iPad conviennent à un lecteur donné.
Il permet de poser une question plus utile : quel outil dans mon poste de travail m'apprend encore quelque chose, et lequel ne fait que déplacer la difficulté ?
La différence entre les deux est parfois petite. Un outil peut simplifier une tâche tout en ouvrant une autre compréhension. Le terminal économise peut-être des clics, mais il force aussi à voir les processus. Un établi minuscule ralentit un projet, mais révèle le prix du désordre. Un iPad voyage bien, mais montre à quel moment la mobilité devient dépendance à une plateforme.
Le poste de travail de Garrison est intéressant pour cette raison. Il ne promet pas une configuration idéale. Il montre des outils replacés dans une pratique, avec leurs avantages, leurs irritations et une sortie de secours lorsque la promesse ne tient plus.