Je construis henny.info, la boutique, les applis — et cette newsletter — avec un outil appelé Claude Code. C’est un assistant IA qui vit dans le terminal : il lit ton code, modifie des fichiers, exécute des commandes. Ce qui est intéressant, ce n’est pas qu’il écrive du code. Ce qui est intéressant, c’est ce que tu n’as plus besoin de faire toi-même.

Voici dix tâches que je lui ai confiées. De « utile au quotidien » à « tourne pendant que je dors ». Rien de tout ça n’est magique — et rien ne te retire la décision. Elles te retirent la répétition.

1. Se mettre à niveau sur un projet inconnu

La première chose pour laquelle je l’utilise, ce n’est pas écrire, c’est lire : « Explique-moi ce projet. » Il lit le code, trouve les parties importantes et répond aux questions — au lieu que je clique pendant des heures dans des dossiers inconnus. Pour ton propre vieux code que tu ne comprends plus, ça marche tout aussi bien.

2. Enregistrer les workflows récurrents comme « skill »

Les choses que je fais toujours de la même façon — déployer, démarrer un article de blog, relire le code — je les écris une fois comme skill et je les appelle ensuite avec /deploy. Un skill n’est pas un programme ; c’est un ensemble d’instructions enregistré qu’il lit et suit. (Petite précision, parce que c’est souvent mal raconté : les commandes slash personnalisées ne sont pas une fonctionnalité en soi — tout ce qui commence par / est un skill.)

3. Vérifier automatiquement à chaque modification (hooks)

Un hook est une commande à toi qui s’exécute toujours lors d’un événement précis — par exemple le formateur de code après chaque modification de fichier. La différence avec un skill compte : un hook se déclenche inconditionnellement, pas « si l’IA y pense ». Tu ne peux donc plus oublier le formatage ou le test — ça se fait tout seul, à chaque fois.

4. Connecter tes outils (MCP)

Via des serveurs MCP, il accède à des services en dehors de ta machine : GitHub, Slack, une base de données, le navigateur. Pour la plupart des services courants, il existe des connecteurs prêts à l’emploi — tu ne construis rien, tu connectes. Ensuite, il peut lire une issue GitHub, ouvrir une pull request ou poster un message dans un canal Slack, directement depuis le terminal.

5. Faire travailler plusieurs assistants en parallèle (subagents)

Pour la recherche ou les grandes explorations, il envoie des subagents — chacun avec sa propre tête, chacun ne rapportant que le résumé. Ça garde la conversation principale propre, au lieu de la remplir avec une centaine de fichiers lus. Pas de magie en arrière-plan : ils partent en mission et reviennent une fois terminé.

6. Intégrer Claude dans des scripts (headless)

Avec claude -p "...", il devient un bloc de construction en ligne de commande — tu peux lui faire transiter des données comme n’importe quel outil de terminal :

git diff | claude -p "trouve les fautes de frappe dans ce diff"

C’est le passage de « je discute avec une IA » à « l’IA est une étape dans mon workflow ». Il exécute la tâche, affiche le résultat et se termine.

7. Faire relire automatiquement les pull requests (GitHub Actions)

Dans la CI — GitHub Actions, dans mon cas — il relit chaque pull request : bugs, failles de sécurité, étourderies. Il écrit son commentaire directement sur la PR. Tu peux aussi l’y interpeller avec @claude et lui demander quelque chose. Ainsi, chaque modification a une seconde paire d’yeux avant d’être fusionnée.

8. Le faire tourner sur un planning ou la nuit (routines)

Les routines tournent sur un planning dans le cloud — même quand ta propre machine est éteinte. Résumer les pull requests ouvertes chaque jour, envoyer un court rapport, surveiller quelque chose et te prévenir. (Pour une répétition rapide à l’intérieur d’une session ouverte, il y a /loop — mais c’est pour l’instant présent, pas pour un fonctionnement permanent.)

9. Conserver la connaissance du projet (CLAUDE.md + mémoire)

Un fichier appelé CLAUDE.md contient les règles du projet — « utilise pnpm, pas npm », « tests avant chaque commit », « les endpoints de l’API se trouvent ici » — et elles s’appliquent automatiquement à chaque session. Plus une mémoire dans laquelle il note lui-même ce qu’il a appris. Tu expliques les choses une fois, pas à chaque fois.

10. Autoriser les commandes de confiance (permissions)

Dans un settings.json, tu décides ce qu’il peut faire sans demander — git status, lancer les tests, regarder l’état. Pour tout le reste, il continue de demander. Il travaille ainsi de façon fluide sur les choses inoffensives, sans que tu perdes le contrôle sur les choses sensibles. (Pour interdire quelque chose durement, tu reprends un hook — il peut bloquer une action, une permission ne fait que l’autoriser.)

Le fil rouge à travers ces dix points : tu dis une chose une fois, bien faite — comme un skill, un hook, une règle — et ensuite ça se passe tout seul. C’est exactement pour ça qu’une seule personne peut aujourd’hui construire et faire tourner toute une boutique qui demandait autrefois une équipe. Ce site, la boutique et la newsletter en sont la preuve vivante.

J’apprends encore ça moi-même chaque jour, et les outils changent vite — l’état des fonctionnalités ici date de juillet 2026, et demain quelque chose portera peut-être un autre nom. Si un point t’intéresse davantage, écris-moi ; j’en ferai un article à part.

Sources

Les noms de fonctionnalités et les exemples sont vérifiés par rapport à la documentation officielle de Claude Code (à la date de juillet 2026) : Skills, Hooks, MCP, Subagents, Mode headless, GitHub Actions, Routines, Memory, Permissions.

Des questions, ou une erreur trouvée ? Écris-moi.