Flux de travail IA

Ce projet a été construit avec Claude Code. La plupart des revendications « construit avec l’IA » s’arrêtent à l’étiquette. Voici le tableau complet : ce que l’IA sait, comment les sessions fonctionnent, à quoi ressemble le prompting en pratique et là où l’humain trace la ligne. Si vous construisez vous-même avec l’IA, ou si vous êtes simplement curieux de savoir à quoi cela ressemble vraiment, ceci est pour vous.

Ce que l’IA sait

Claude Code dispose d’un fichier mémoire persistant qui transporte le contexte d’une session à l’autre. Au lieu de ré-explorer la base de code à chaque conversation, il reprend là où nous nous étions arrêtés. Voici ce qu’il contient (version assainie) :

Identité du projet

Nom de l’application, emplacement source, licence, identifiant d’application
Relation de fork : l’amont est En Croissant par Francisco Salgueiro, nous maintenons notre propre fork de manière indépendante
Pourquoi le fork existe : le mainteneur amont a décliné la fonctionnalité TTS, ce qui est légitime — des visions différentes pour le même projet

Règles de compilation

pnpm uniquement — npm casse vanillaExtract (écran blanc à l’exécution, pas d’erreur, juste rien)
Node.js 22+ requis (Vite 7 nécessite crypto.hash)
Toujours pnpm format && pnpm lint:fix avant de commiter
Fermer l’application avant d’écraser le binaire (“Text file busy”)
Après avoir déplacé des répertoires source, cargo clean pour effacer les références de chemin obsolètes

Connaissance de l’architecture

Quels fichiers possèdent quelles fonctionnalités (atoms dans atoms.ts, navigation dans l’arbre dans tree.ts, moteur TTS dans tts.ts)
Pourquoi tous les atoms TTS nécessitent getOnInit: true (lectures impératives via store.get() avant que React ne s’abonne)
Comment fonctionne le cache audio (clés provider:voiceId:lang:text)
Le correctif des coordonnées chessground est côté CSS, pas un fork de la bibliothèque
Organisation des données : ce qui se trouve où, ce qui est lié par lien symbolique, ce qui survit aux redémarrages de l’application

Ce qu’elle ne sait pas

La mémoire ne contient pas de clés API, de mots de passe ni d’identifiants. Elle référence leurs emplacements de stockage (noms des atoms localStorage) mais jamais les valeurs. L’IA génère du code qui lit les clés depuis les paramètres — elle ne voit ni ne manipule jamais les secrets réels.

Ce qu’on dit à l’IA

Au-delà du fichier mémoire, Claude Code suit des règles intégrées dans son système :

Ne pas sur-ingéniérer. N’effectuer que les changements directement demandés. Une correction de bug n’a pas besoin que le code environnant soit nettoyé. Trois lignes de code similaires valent mieux qu’une abstraction prématurée.
Ne pas deviner les URL. Ne jamais fabriquer de liens ou de points de terminaison.
Lire avant de modifier. Ne jamais proposer de changements à du code qu’elle n’a pas lu.
Préférer la modification à la création. Ne pas créer de nouveaux fichiers sauf en cas de nécessité absolue.
Pas de vulnérabilités de sécurité. Surveiller les injections, XSS et les problèmes du top 10 OWASP.
Demander en cas d’incertitude. Si une instruction est ambiguë, demander plutôt que deviner.
Tourner sept fois sa langue dans sa bouche. Les opérations destructives (force push, reset —hard, suppression de fichiers) nécessitent l’approbation explicite de l’humain.

Écrire de bons prompts

La différence entre une interaction IA utile et une interaction frustrante tient presque toujours au prompt.

Soyez précis sur ce que vous voulez. Pas « corrige le bug » mais « la clé du cache TTS n’inclut pas le nom du fournisseur, donc passer de ElevenLabs à Google joue l’audio ElevenLabs mis en cache au lieu de générer un nouvel audio. »

Incluez le contexte que l’IA ne possède pas. L’IA peut lire votre code, mais pas dans vos pensées. « L’utilisateur a signalé que les coordonnées sont inversées sur l’échiquier » est moins utile que « le CSS dans chessgroundBaseOverride.css a les rangées et les colonnes inversées — l’original de Francisco les avait à l’envers. »

Énoncez vos contraintes. « Ne crée pas de nouveaux fichiers » ou « utilise le pattern d’atom existant » ou « ça doit fonctionner sans clé API » indiquent à l’IA où sont les garde-fous.

Dites ce que vous ne voulez pas. « N’ajoute pas de gestion d’erreurs pour des cas qui ne peuvent pas se produire » ou « ne refactorise pas le code environnant » prévient la sur-ingénierie — le mode de défaillance le plus courant de l’IA.

Le schéma est : intention + contexte + contraintes. Maîtrisez cela et l’IA devient considérablement plus utile.

Le mode plan : utiliser un Claude pour prompter un autre

Claude Code dispose d’un « mode plan » qui sépare la réflexion de l’action. En mode plan, l’IA lit les fichiers, explore la base de code et produit un plan — mais n’écrit aucun code. Vous examinez le plan, l’ajustez, puis passez en mode implémentation où l’IA exécute.

Pourquoi cela fonctionne-t-il ? Parce que la partie la plus difficile de toute tâche de programmation n’est pas d’écrire le code. C’est de comprendre quel code écrire — quels fichiers modifier, quels patterns suivre, quels cas limites existent. Le mode plan consacre toute l’attention à cette question avant qu’une seule ligne ne soit écrite.

Exemple tiré de ce projet : lorsque nous avons restructuré le menu Aide pour ajouter le sélecteur de langue, la conversation en mode plan a exploré le fonctionnement des menus Tauri, les atoms déjà existants, comment le visualiseur de documentation résolvait les chemins de ressources et à quoi ressemblait l’API de la boîte de dialogue de confirmation. Au moment de passer à l’implémentation, l’IA disposait d’une carte complète des changements. Aucun faux départ.

Vous utilisez essentiellement une instance de l’IA comme architecte senior et une autre comme développeur. Le même modèle, des rôles différents.

Comment fonctionnent les sessions

Une session typique ressemble à ceci :

L’humain énonce son intention. « Ajoute une note sur la mise en cache dans la section KittenTTS. » « Supprime la télémétrie PostHog. » « Les notes de qualité sont fausses, voici ce qu’elles devraient être. »
L’IA lit les fichiers concernés. Elle ne devine pas ce qu’il y a dans un fichier. Elle le lit, comprend l’état actuel, puis propose des modifications. Plusieurs fichiers sont lus en parallèle lorsqu’ils sont indépendants.
L’IA effectue le changement. Des modifications ciblées sur les fichiers existants. Pas des réécritures — des modifications chirurgicales qui préservent tout ce qui les entoure.
L’humain vérifie. Chaque modification est affichée avant d’être écrite sur le disque. L’humain approuve, rejette ou réoriente. « Non, c’est trop édulcoré — dis que c’est vraiment mauvais. » « Remonte ce paragraphe. » « Ce n’est pas ce que je voulais dire. »
Commit sur instruction. L’IA ne commite jamais de sa propre initiative. L’humain dit « commit » ou « commit and push ». Les commits incluent Co-Authored-By: Claude Opus 4.6 — toujours attribués, jamais dissimulés.

Fenêtres de contexte et sauvegardes d’état

Chaque conversation IA possède une fenêtre de contexte — la quantité totale de texte qu’elle peut garder en mémoire à la fois. Lorsque la conversation devient suffisamment longue, les messages les plus anciens sont compressés pour libérer de la place.

Deux stratégies : garder les conversations ciblées (une tâche par conversation), et utiliser les sauvegardes d’état (Claude Code enregistre les transcriptions sous forme de fichiers JSONL que vous pouvez reprendre avec le contexte complet restauré). Le fichier mémoire sert un objectif différent — c’est une base de connaissances persistante qui survit à toutes les conversations.

Ce que l’IA propose vs. ce qui est livré

La première suggestion de l’IA est rarement la version finale. Un échange typique :

L’IA rédige quelque chose de raisonnable
L’humain dit « trop corporate » ou « sois plus direct » ou « c’est faux, voici pourquoi »
L’IA ajuste
L’humain approuve

Le goût, le ton et la décision finale sont toujours humains. L’IA apporte la vélocité — lire les fichiers, comprendre le contexte, effectuer des modifications précises à travers une base de code qu’elle peut tenir en mémoire. L’humain apporte le jugement — quoi construire, comment cela doit se ressentir, quand s’arrêter.

Compétences et commandes slash

Claude Code prend en charge les « compétences » (skills) — des prompts réutilisables stockés sous forme de fichiers markdown dans le répertoire .claude/commands/. On les invoque avec une commande slash, comme /translate-docs.

Ce projet utilise une compétence /translate-docs qui automatise la traduction de la documentation en plusieurs langues. Le fichier de compétence contient les instructions complètes : quels fichiers traduire, quel format utiliser, comment gérer les blocs de code et les liens, quel ton maintenir. Au lieu d’expliquer tout cela à chaque fois, il suffit de taper /translate-docs et l’IA sait exactement quoi faire.

Les compétences encodent un processus, pas seulement de l’information. Vous pouvez en créer pour tout flux de travail récurrent : exécuter des tests, déployer, examiner des PR, mettre à jour des changelogs.

Principes de développement

Le document complet des principes se trouve dans le dépôt à .claude/01_UNIVERSAL_PRINCIPLES.md. Il a commencé comme le Clean Code de Robert C. Martin (2008) plus des ajouts pour l’ère de l’IA. Puis nous avons eu une conversation honnête sur ce qui tient encore et ce qui ne tient plus.

Ce qui est intemporel

Des noms révélateurs d’intention. Toujours. Pour toujours.
Les fonctions font une seule chose. Le vrai principe est la cohérence, pas la taille.
Pas d’effets de bord. Toujours la source de la plupart des bugs.
Les commentaires expliquent le pourquoi, pas le quoi.
Responsabilité unique. Un module ne devrait avoir qu’une seule raison de changer.
Programmer contre des interfaces, pas des implémentations.
Ne pas avaler les erreurs. Chaque erreur est une information.
Conception émergente : tous les tests passent, pas de duplication, exprime l’intention, minimise la complexité. Dans cet ordre.

Ce qui est contextuel

Ces principes sont solides, mais les règles spécifiques reflètent un monde pré-IA ou spécifique à un langage. Nous appliquons l’esprit, pas la lettre :

DRY. La duplication qui diverge est dangereuse. Mais extraire chaque pattern répété dans une abstraction crée une indirection qui peut être pire. Parfois trois lignes lisibles ici même valent mieux qu’une abstraction prématurée dans un autre fichier.
La cérémonie stricte du TDD. Le principe — livrer du code testé, savoir qu’il fonctionne — est non négociable. La cérémonie — le test doit exister avant le code — a été conçue pour un flux de travail où les humains tapent lentement. Écrivez des tests. Assurez-vous qu’ils passent. Que le test ou le code ait été écrit en premier importe moins que le fait que les deux existent.
La règle du Boy Scout. « Laissez le terrain de camping plus propre » — oui. Mais le Boy Scout nettoyait le campement, pas la forêt entière. Corrigez ce que vous touchez. Ne refactorisez pas la structure entière d’un fichier parce que vous avez changé une seule ligne dedans.

Ajouts de l’ère IA

Les principes directeurs évoluent mieux que les règles. Le principe permet le jugement ; la règle est fragile.
Si l’agent l’a construit, l’agent peut le maintenir. Conservez le contexte des conversations et les artefacts. Documentez le processus de construction, pas seulement le résultat.
Clair plutôt que malin. Le système qui a construit ceci doit pouvoir reconstruire le raisonnement et le modifier correctement. Une structure explicite bat de petites abstractions astucieuses.
Cela pourrait-il devenir de l’infrastructure ? Un outil résout un problème pour vous. L’infrastructure permet aux autres de construire par-dessus. Concevez en conséquence.

Là où l’humain trace la ligne

L’IA est un outil. Un remarquablement bon. Mais il y a des choses qu’elle ne fait pas :

Les décisions produit. Quelles fonctionnalités construire, lesquelles supprimer, comment l’application doit se ressentir. « La note de qualité du System TTS devrait dire “passable” parce qu’il est vraiment mauvais » — c’est un jugement humain fondé sur le fait de l’avoir réellement écouté.
Le goût. L’IA peut écrire une prose soignée, mais la voix du projet, la décision d’être franc sur la qualité, le choix de créditer Francisco de manière visible — ce sont des choix humains.
L’éthique. Supprimer PostHog n’était pas une tâche de refactoring. C’était « la page des paramètres dit qu’on ne collecte pas de télémétrie, mais il y a une clé API PostHog active dans le code. C’est un mensonge. Corrige ça. » L’IA a exécuté. L’humain a identifié le problème et s’en est soucié.
Les échecs. L’échiquier se moque de vos outils.

Pourquoi partager tout cela

Parce que « construit avec l’IA » est devenu vide de sens. Tout le monde le dit. Personne ne le montre. La question intéressante n’est pas de savoir si l’IA a été impliquée — c’est comment elle a été impliquée, et ce que l’humain a réellement apporté.

Voici la réponse. L’humain apporte la vision, le goût, le jugement et la responsabilité. L’IA apporte la vélocité, la mémoire et la volonté infatigable de lire des messages d’erreur Rust à 2h du matin.

Aucun des deux ne construit cela seul. Les deux sont crédités. C’est le marché.

En Parlant~ est un fork de En Croissant par Francisco Salgueiro, construit avec Claude Code par Anthropic.