Comment je travaille, pour de vrai

J’ai lu des dizaines d’articles “comment je travaille”. La plupart decrivent un systeme que l’auteur aimerait avoir. Celui-ci decrit celui que j’utilise vraiment.

Ma page philosophie explique ce en quoi je crois — la confiance plutot que le controle, le deep work plutot que le hustle, l’IA comme amplificateur. Cet article est la version concrete. Les vrais outils, le vrai planning, les vraies decisions que je prends chaque jour en tant que Directeur Engineering qui code encore, manage une equipe de 8-10 personnes, et construit des side projects a cote.

La journee commence dans le terminal

Chaque matin, meme routine. Ouvrir le terminal, lancer jim tasks.

Jim est un gestionnaire de taches en CLI que j’ai construit pour moi. Pas de web app, pas de compte, pas de sync, pas de notifications. Tout vit dans ~/.jim/. C’est inspire de la methode Bullet Journal — chaque journee repart de zero. Les taches en retard ne hurlent pas. Tu revois ce qu’il y a, tu decides quoi garder, et tu laisses tomber le reste consciemment.

Laisser tomber une tache, ce n’est pas un echec. C’est une decision. Si quelque chose continue a etre repousse a demain, soit ca doit etre fait aujourd’hui, soit ca n’a pas besoin d’etre fait du tout.

Jim est aussi connecte a Claude Code via un fichier de skill global. Quand je travaille sur n’importe quel projet, Claude Code detecte les intentions qui meritent une tache — “faut que je refactorise ca”, “oublie pas de mettre a jour l’API” — et propose de les tracker dans Jim. Pas de saisie manuelle, pas de changement d’app. La tache est capturee sans casser le flow.

Le point : les priorites ne sont pas une liste qu’on fait une fois le lundi. Ce sont des decisions qu’on prend chaque matin.

Les priorites sont des decisions, pas des listes

Je n’utilise pas de backlog. Je ne fais pas de sprints pour mon propre travail. Chaque matin, trois questions :

Qu’est-ce qui a le plus de levier ? — Quelle seule chose, si elle est faite aujourd’hui, aurait le plus grand impact ?
Qu’est-ce qui bloque quelqu’un d’autre ? — Code reviews, decisions, feedback. Debloquer les autres est presque toujours plus levier que mes propres taches.
Pour quoi j’ai vraiment l’energie ? — Certains jours sont des jours d’architecture. D’autres des jours d’admin. Se battre contre son niveau d’energie, c’est une bataille perdue d’avance.

Ensuite je batch. Toutes les code reviews dans un bloc. Tout le Slack dans une fenetre. Tous les 1:1 a la suite l’apres-midi. Du travail similaire regroupe, parce que chaque changement de contexte coute 15-20 minutes de refocalisation. Sur une journee entiere, le switching non gere bouffe des heures de deep work.

Ce n’est pas du theatre de productivite. C’est juste etre honnete sur comment l’attention humaine fonctionne.

La forme d’une journee

Ma journee a trois phases.

8h30-10h — Deep work. C’est la que mon cerveau est le plus affute. Je l’utilise pour les problemes les plus durs : construire des agents, designer des architectures, ecrire du code qui demande une vraie concentration. J’ai plusieurs sessions Claude Code en parallele sur differents projets, je jette un oeil a quelques Slacks entre deux, mais le focus reste technique. Pas de meetings, pas d’appels. Ce bloc est sacre.

10h-16h — Meetings, equipe, communication. C’est la que je change de mode. 1:1, syncs, code reviews, aider les autres a se debloquer, rattrapage Slack, decisions. L’insight contre-intuitif : planifier les meetings quand ton cerveau n’est pas a son pic. T’as pas besoin de focus profond pour un sync — t’as besoin de presence et de contexte. Garde la puissance cognitive pour le travail qui en a vraiment besoin.

Apres 16h — Deuxieme session de deep work. Une fois les meetings termines, j’ai une autre fenetre de temps focus. Moins affute que le matin, mais toujours productif. Bon pour finir ce que j’ai commence a 8h30, ecrire de la doc, ou explorer de nouveaux outils.

La cle n’est pas un planning rigide — c’est le principe derriere. Proteger le temps de cerveau au pic pour le travail de cerveau au pic. Pousser tout le reste sur les creneaux ou t’es “pas chaud du cerveau”, comme on dit.

Je travaille depuis un espace de coworking. Pas de chez moi (trop de distractions), pas du bureau (trop d’interruptions). Le coworking est le juste milieu — assez social pour ne pas se sentir isole, assez calme pour se concentrer. Casque sur les oreilles = ne pas deranger. Tout le monde la-bas comprend le signal.

Slack est le mal necessaire. C’est anti-productif par design — un flux constant de changements de contexte deguises en communication. Mais il le faut. L’astuce c’est de le contenir. Je ne le garde pas ouvert pendant les blocs de deep work. Je batch mon temps Slack dans la fenetre de 10h a 16h avec tout le reste cote equipe. Pas de notifications. Si c’est vraiment urgent, les gens appellent.

Claude Code est mon second cerveau

L’IA n’est pas une nouveaute dans mon workflow — c’est de l’infrastructure. Claude Code est mon outil principal pour tout ce qui est technique. Claude Desktop gere le reste — redaction, reflexion, brainstorming, ecriture qui n’est pas du code.

Il n’y a pas de VS Code dans mon workflow. Claude Code est l’editeur. Je decris ce que je veux, je review les diffs, je corrige le cap. Pour les rares cas ou j’ai besoin d’un IDE visuel, j’ouvre Cursor, mais c’est l’exception.

Le vrai multiplicateur, ce sont les sessions paralleles. Pendant mon bloc de deep work du matin, j’ai une instance Claude Code qui construit un agent, une autre qui refactorise un module dans un autre projet, et une troisieme qui explore une API que je n’ai jamais utilisee. Je donne la direction, review l’output, ajuste. C’est comme avoir trois collaborateurs focus qui ne se fatiguent jamais et n’ont pas besoin de standup.

Chaque projet sur lequel je travaille a un CLAUDE.md a la racine. Il decrit l’architecture, les conventions, la stack, et les decisions cles. Quand Claude Code entre dans le projet, il lit ce fichier en premier — comme de la documentation d’onboarding, mais le lecteur est une IA. Ecrire ces fichiers m’a rendu meilleur documenteur globalement. Si tu ne peux pas expliquer ton architecture a une IA, tu ne peux probablement pas l’expliquer a un nouveau dans l’equipe non plus.

J’utilise aussi des serveurs MCP — Model Context Protocol — pour donner a Claude Code acces a des outils et du contexte externes au-dela du codebase. Schemas de base de donnees, APIs internes, configs de deploiement. C’est encore tot, et l’ecosysteme evolue vite, mais le pattern est clair : plus l’IA a de contexte, meilleur est son output. MCP est la facon standardisee de fournir ce contexte.

Le take honnete : l’IA ne remplace pas la reflexion. Elle remplace les parties mecaniques de la reflexion. Le developpeur doit toujours savoir quoi construire et pourquoi. L’IA gere le comment, plus vite. Les ingenieurs qui prospereront sont ceux qui apprennent a piloter l’IA efficacement tout en gardant leurs competences fondamentales affutees.

Il y a un shift plus profond en cours. On devient des builders plutot que des software engineers. Notre metier n’est plus juste d’ecrire du code — c’est de construire des briques pour que les gens du produit, les sales, et tous les autres metiers puissent a leur tour construire des choses. L’IA accelere ca. Le code est un moyen, pas une fin. Le vrai output, c’est de permettre aux autres de creer.

Les outils qui comptent vraiment

Je ne cours pas apres les nouveaux outils. Je choisis ceux en qui j’ai confiance et je vais en profondeur. La liste complete est courte — intentionnellement :

Warp — mon terminal. Jim pour les taches, Claude Code pour le developpement, git pour le versioning. L’essentiel de ma journee se passe ici.
Claude Code — l’editeur, le pair programmer, le second cerveau pour tout le travail technique.
Claude Desktop — pour tout ce qui n’est pas du code : ecriture, reflexion, brainstorming, redaction de docs et communication.
Cursor — seulement quand j’ai besoin d’un IDE visuel, ce qui est rare.
Slack — le mal necessaire. Contenu dans la fenetre 10h-16h.
Notion Calendar — le planning, rien de plus.
Linear — le suivi de projets pour l’equipe.
Jim — mon propre gestionnaire de taches en CLI. Pas d’app, pas de compte. Juste jim tasks dans le terminal.

Pas d’app de todolist. Pas de Trello. Pas de Notion docs pour les notes perso. Moins il y a d’outils, moins il y a d’endroits ou les choses se perdent.

Le meta-point : les meilleurs outils sont ceux qu’on utilise regulierement. La profondeur bat la largeur. Un outil qu’on connait par coeur sera toujours plus performant qu’un “meilleur” outil qu’on est encore en train d’apprendre.

Ce que je n’ai pas encore resolu

Ce systeme n’est pas parfait. Quelques trucs sur lesquels je travaille activement :

La frontiere de disponibilite. En tant que Directeur, les gens ont besoin d’acces a moi. L’equilibre entre deep work et etre joignable change chaque semaine selon les besoins de l’equipe. Mais meme les jours charges en meetings, j’ai toujours au moins un agent Claude Code qui tourne en tache de fond — lance le matin, checke le soir. Le travail ne s’arrete jamais vraiment, il change juste de forme.

Dire non. Il y a plus de taches interessantes que d’heures. Jim aide en rendant le fait de laisser tomber une tache un acte explicite, mais l’instinct de dire oui a tout est encore la. Je m’ameliore.

Le rythme de l’outillage IA. Les serveurs MCP, les conventions CLAUDE.md, les workflows agentiques — tout ca bouge vite. Mon workflow dans six mois sera probablement different d’aujourd’hui. Le systeme n’est pas fige. Il evolue.

Je ne crois pas a la hustle culture. Je crois au travail a fort levier, a la regularite, et a savoir quand s’arreter. Le repos fait partie du systeme. L’objectif n’est pas de travailler plus d’heures — c’est de faire compter les heures qu’on travaille.