Aller au contenu
Chandler Nguyen
IA9 min de lecture

Mon Mac est mort. Je l'ai reconstruit avec Chrome et DeepSeek.

Mon Mac est mort, alors j'ai tout effacé et je suis reparti de zéro avec Chrome et un seul harness d'agent. La machine a maintenant environ 60 GB d'espace libre en plus, et j'ai arrêté de penser en termes d'applications.

Mon Mac mini est mort. Sans drame — il a simplement cessé d'être une machine à laquelle je pouvais faire confiance, et le plus raisonnable était d'effacer le disque et de tout réinstaller.

J'ai déjà fait cette danse un bon nombre de fois. Le rituel ne change jamais : réinstaller le système, puis passer une soirée à tout réinstaller. Homebrew. Node. Python. Une douzaine d'outils en ligne de commande que tu ne te souviens même pas d'avoir installés. Puis, trois semaines plus tard, tu découvres celui que tu avais oublié, parce qu'un truc qui marchait avant ne marche plus.

Cette fois, j'ai tenté autre chose.

J'ai installé Chrome, puis j'ai lancé une seule commande dans Terminal pour installer le harness lui-même. C'était toute la liste. Ensuite, je lui ai demandé de s'occuper du reste.

Chrome n'est pas un simple décor dans cette histoire. C'est la seule application avec interface graphique que je veux vraiment, et c'est aussi le navigateur que l'agent pilote quand une tâche en réclame un. L'outillage navigateur est déclaré dans la config du harness comme le reste, pas installé à la main.

Le harness, c'est la partie que j'ignorais

Ces deux dernières années, j'ai pensé les outils de codage IA essentiellement en termes de modèle. Lequel est le plus intelligent, lequel coûte le moins cher, lequel écrit le meilleur code frontend. J'ai résilié des abonnements à cause de cette question, et j'en ai parlé plus d'une fois.

Ce que je sous-estimais, c'était le harness — ce qui se trouve réellement entre la machine et moi. Le modèle apporte l'intelligence. Le harness apporte les mains, la mémoire de ma façon de travailler et l'interface.

Pour cette reconstruction, OpenCode était le harness et DeepSeek V4.1 Flash était le modèle. Mais j'ai cessé de croire que ces deux couches doivent être figées sur un seul choix, parce qu'elles se choisissent sur des critères complètement différents.

Les modèles, je les choisis sur quatre choses : leur intelligence, leur vitesse de génération (les tokens par seconde, que je ressens bien plus que je ne l'aurais cru), ce qu'ils coûtent, et ce qu'il advient des données que je leur envoie.

Le coût mérite mieux que le prix affiché, parce que le prix affiché n'est pas ce que tu paies. Le chiffre qui compte, c'est le taux de succès du cache. Quand le harness peut tenir un contexte stable, la majeure partie de l'entrée est servie depuis le cache et la facture s'effondre — mon taux de succès sur le cache DeepSeek est régulièrement au-dessus de 99 %. Deux modèles au même prix par token peuvent donner des dépenses très différentes en pratique, selon que ton harness sait garder un cache ou non.

Je ne fais pas non plus tout passer par un seul modèle. Des tâches différentes appellent des modèles différents, et un modèle gratuit suffit souvent pour un travail mécanique — y consacrer un modèle de pointe, c'est du gaspillage.

Les harnesses, je les choisis selon mes préférences. L'interface, et l'habitude. J'utilise OpenCode parce que mes habitudes y vivent, et je fais tourner le harness de DeepSeek à côté, parce que j'aime travailler dans les deux. Au travail, j'en utilise encore un autre — Antigravity CLI qui pilote Gemini 4 Argon ou 3.8 Flash — parce que ce boulot-là est structuré autrement : je lui donne un plan et il le déroule pendant des heures.

Aucun benchmark ne tranche ça, contrairement à un choix de modèle. Il faut savoir ce dont tu as besoin, et choisir en conséquence.

J'ai écrit en août sur le passage à un seul modèle et un seul harness sans nommer ce qui avait réellement changé pour moi. Ce billet se terminait par une note : j'allais utiliser davantage Flash, parce qu'à ce prix-là, il n'y avait aucune raison de s'en priver. C'est bien de ça qu'il s'agit, avec une correction : un seul était le mauvais réflexe.

Cette distinction a l'air théorique jusqu'au moment où tu reconstruis un ordinateur avec. Là, elle cesse très vite de l'être. Un harness capable de lancer des commandes, de lire et d'écrire des fichiers, d'installer des paquets et d'essayer de vérifier son propre travail, ce n'est pas de l'autocomplétion. C'est plus proche d'une couche d'exploitation — et une fois que tu en as un, la liste des choses que tu installes toi-même devient très courte.

Le workflow, étape par étape

Le schéma était le même à chaque fois, et ce n'est pas comme ça que je travaillais avant :

  1. Décris le résultat, pas les étapes. Pas « voici la commande brew », mais « il faut que je puisse lancer ce genre de script en local, mets-le en place ».
  2. Laisse l'agent installer et configurer, y compris réparer ce qu'il vient de casser.
  3. Vérifie — cette partie reste la mienne. L'agent peut te montrer exactement ce qu'il a exécuté, et c'est ce qui rend la vérification peu coûteuse.
  4. Quand je ne peux pas vérifier un truc, je le fais moi-même. Les clés de service et les identifiants SSH sont les deux choses que j'ai créées à la main et que je n'ai pas déléguées.
  5. Lis ce qu'il a réellement fait, et attends-toi à une réponse fausse mais plausible, un jour ou l'autre. Pas chaque ligne — juste assez pour savoir ce qui a changé sur ma machine, et assez pour repérer le changement qui a l'air juste et qui ne l'est pas.

La différence avec mes anciennes reconstructions est plus facile à montrer qu'à décrire :

Mes anciennes reconstructionsCelle-ci
Installé à la mainLe système, puis une soirée de Homebrew, Node, Python et une douzaine d'outils CLIChrome, plus une commande pour le harness
Tout le resteMoi, sur une soiréeL'agent, à la demande
Où vit l'étatDes services locaux, des runtimes, des images de conteneursUn fichier de config et une connexion que j'ai autorisée une fois
Ce qui s'accumuleUn dépôt laissé par chaque expérimentationRien d'installé « au cas où »

Deux choses rendent ça possible. D'abord, les harnesses gardent leur configuration dans des fichiers que je peux lire et modifier — je vois exactement ce qui est branché et je peux le changer. Ensuite, un nombre croissant de mes serveurs MCP sont distants. Supabase, Resend et Vercel sont des URL que j'ai autorisées une fois, pas des services sur mon disque. Les serveurs locaux tournent via npx à la demande : ils ne sont donc pas installés avant le moment où je m'en sers.

Avant, ma machine hébergeait des services. Maintenant, elle contient un fichier de config et un token, et les services vivent ailleurs.

Le disque est resté vide

Je ne cherchais pas à en faire un benchmark, alors prends ça comme une observation, pas comme une mesure. Mais le chiffre est difficile à ignorer : par rapport à mon ancienne config, j'ai désormais environ 60 GB d'espace libre en plus sur la même machine.

Pour une machine avec un SSD soudé, ce n'est pas une erreur d'arrondi. Le stockage est l'une des rares choses que tu ne peux pas améliorer après coup sur un Mac moderne, et son prix le reflète. Soixante gigaoctets récupérés, c'est une part non négligeable de ce qu'aurait coûté le palier supérieur.

Où tout cet espace est passé est plus facile à expliquer qu'à prouver. Certains outils tournent désormais à la demande au lieu de rester en permanence sur le disque, et l'habitude d'installer des choses à l'avance s'est estompée, parce que les demander plus tard ne coûte presque rien.

De l'application à l'intention

Voici le basculement, et je cherche encore jusqu'où il va.

La majeure partie de ma vie informatique a été façonnée par les applications. Je veux faire un truc, alors je cherche l'application qui fait ce truc, je l'installe, j'apprends son interface et je vis à l'intérieur de ses partis pris. L'application est l'unité de travail.

Travailler comme ça, c'est être façonné par l'intention. Je décris ce dont j'ai besoin. Quelque chose capable d'agir sur la machine détermine de quelles briques il a besoin, les met en place et s'en occupe. L'application devient un détail d'implémentation, et parfois un détail que je n'installe jamais consciemment.

Il s'agit d'un changement plus important que « l'IA écrit mon code ». Le codage n'a jamais été mon goulot d'étranglement ; c'était la distance entre vouloir quelque chose et l'avoir. Cette distance est bien plus courte aujourd'hui.

C'est aussi pour ça que je plaisante à moitié en disant que je finirai peut-être sous Linux. La raison pour laquelle je suis resté sur macOS pendant des années n'a jamais été le système d'exploitation — c'était toute la configuration accumulée qu'il faudrait reconstruire. Si ton environnement se résume pour l'essentiel à un fichier de config et à un agent compétent, la plateforme en dessous compte moins qu'avant. Je ne change pas cette semaine. Je ne sais simplement plus ce qui m'en empêcherait.

Je dois admettre que je n'avais pas vu ça venir. Si tu m'avais dit il y a cinq ans qu'un Mac tout neuf, plus un navigateur, plus un seul agent suffisaient à se remettre au travail, j'aurais cru que tu décrivais une démo, pas un tranquille mardi soir.

Ce que je ne prétends pas

Quelques réserves honnêtes, parce que j'ai lu assez d'enthousiasme à ce sujet pour me méfier du mien.

  • Le harness est devenu ce qui m'enferme. Le choix du modèle est de plus en plus facile à changer, mais mes habitudes, ma config et mon workflow vivent dans le harness. C'est une vraie dépendance, et je la surveille.
  • « Il a tout installé » n'est pas la même chose que « je comprends ma machine ». Je connais moins bien ma config que quand je l'assemblais à la main. Il s'agit d'un coût réel, et la raison d'être de l'étape cinq ci-dessus.
  • Ce n'est pas gratuit. Environ $60 sur les 30 derniers jours, et ce chiffre ne couvre pas seulement mon codage — il inclut l'API DeepSeek qui fait tourner quelques-uns de mes produits en production. Pour situer : la même habitude me coûtait environ $200 par mois il y a un an. (J'ai écrit sur ce basculement en août.)

Questions fréquentes

Qu'est-ce qu'un harness en codage IA ?

Un harness est le programme qui relie un modèle à un environnement réel. Le modèle raisonne ; le harness lui donne des outils — lancer des commandes, lire et écrire des fichiers, appeler des services externes — et gère la conversation et les permissions qui l'entourent. OpenCode est délibérément agnostique quant au modèle, et c'est pourquoi j'ai pu changer de modèle en dessous sans rien changer d'autre. Claude Code et Codex sont aussi des harnesses, mais chacun est construit autour des modèles de son propre éditeur. Ma règle empirique : choisis un modèle sur sa capacité, sa vitesse, son coût et le traitement des données ; choisis un harness selon que tu aimes vraiment y travailler.

Peut-on vraiment configurer un nouvel ordinateur avec seulement un navigateur et un agent IA ?

Pour ma config — un développeur qui travaille surtout dans un terminal et un navigateur — globalement oui, et avec une commande, pas zéro. Il te faut un navigateur pour accéder au modèle et à internet, un moyen d'installer le harness lui-même, et il faut accepter de vérifier ce que l'agent a fait. Je ne partirais pas du principe que ça vaut pour la machine d'un designer ou d'un comptable.

Pourquoi cette config utilise-t-elle autant moins de disque ?

Environ 60 GB de moins que mon ancienne config, pour trois raisons. Certains services tournent désormais à distance et sont atteints via une URL au lieu d'être installés en local. Certains outils tournent à la demande au lieu de rester en permanence sur le disque. Et l'habitude de préinstaller des choses « au cas où » s'estompe quand les demander plus tard ne coûte presque rien.


Toujours surpris de voir que « installe Chrome et on verra bien » a donné un ordinateur fonctionnel.

À bientôt, Chandler :P