Et même si Claude est à la mode dans les recommandations de formations ou d’influenceurs, ChatGPT reste tout aussi pertinent et utilisé. Alors c’est l’occasion de se pencher sur ses petits noms qui apparaissent à côté de la barre de conversation.

Pourquoi ça compte de bien choisir

L’idée de base est simple : un modèle, c’est un compromis entre intelligence, vitesse et coût. Plus un modèle raisonne finement, plus il coûte cher et plus il est lent à répondre. Ce n’est pas un détail technique réservé aux développeurs qui optimisent une facture d’API : ça se sent directement dans l’usage, même via le chat web ou l’application de bureau.

Prendre un modèle trop léger pour une tâche qui demande de la réflexion se conclut souvent par une réponse incomplète ou à côté de la plaque. Ou alors on arrive au résultat, mais après beaucoup plus d’aller-retours - et un coût + temps final qui dépasse celui du modèle au-dessus. À l’inverse, prendre un modèle trop lourd pour une tâche simple, c’est le risque de gonfler inutilement la facture et le temps de réponse, voire de diverger : un modèle qui se met à trop réfléchir peut sortir plus facilement du cadre qu’on lui a donné. Et c’est pas toujours ce que l’on veut.

Il y a aussi un aspect que j’aime rappeler : le modèle le plus gros n’est jamais gratuit à faire tourner, ni pour le portefeuille ni pour l’environnement. Pas besoin de sortir l’artillerie lourde pour trier trois emails.

Note : Cette histoire de facture vous concerne même si vous payez un abonnement à prix fixe (Free, Go, Plus, Pro) plutôt que l’API : un modèle cher grignote votre quota plus vite. Le prix au token reste un bon ordre de grandeur, même sans passer par l’API.

Bref, le bon modèle n’est pas le plus intelligent du catalogue. C’est celui qui correspond à la tâche. À notre besoin.

Ce que sont Astra, Sol, Terra et Luna

OpenAI structure son offre ChatGPT en deux morceaux. D’un côté, la famille GPT‑5.6, sortie le 9 juillet 2026, avec trois niveaux de capacité : Sol, Terra, Luna. De l’autre, la toute nouvelle famille GPT‑6, avec Astra sorti début septembre 2026 qu’OpenAI présente comme une génération à part entière plutôt qu’un simple cran au-dessus de Sol.

Note : Astra n’a que quelques jours au moment où j’écris ces lignes. Les prix, et les bons usages peuvent encore bouger.

Luna est le modèle le plus rapide et le moins cher de la gamme (environ 0,20 $ / 1,20 $ par million de tokens en entrée / sortie), avec le même contexte de plus d’un million de tokens que les trois autres. OpenAI le positionne sur le volume : extraction de données structurées, classification, modération, les tâches mécaniques qu’un agent délègue à un modèle rapide pendant qu’un cerveau plus costaud supervise. C’est aussi, très concrètement, le modèle par défaut des comptes ChatGPT gratuits.

Terra est le modèle « équilibré » de la gamme (environ 2 $ / 12 $ par million de tokens), qu’OpenAI présente comme quasiment aussi bon que l’ancien modèle phare GPT‑5.5, pour moitié moins cher. Il est positionné pour le travail quotidien : développement courant, rédaction professionnelle, automatisation, assistants internes. C’est un peu le compromis entre qualité, vitesse et coût.

Sol est le modèle phare de la génération GPT‑5.6 (environ 4 $ / 20 $ par million de tokens). OpenAI le recommande pour le raisonnement complexe et les agents qui tournent sur la durée, le développement logiciel, la recherche, la cybersécurité défensive, les sciences et la production de documents professionnels exigeants, là où une erreur coûte cher. Il est inclus dans ChatGPT Plus.

Astra est le modèle le plus capable des quatre, présenté par OpenAI comme une génération à part entière pensée pour les missions de bout en bout : comprendre un objectif, utiliser des outils, prendre des décisions intermédiaires, vérifier le résultat produit. C’est logiquement aussi le plus cher de la gamme (10 $ / 50 $ par million de tokens). OpenAI le recommande pour les tâches extrêmement complexes, le raisonnement très avancé, les agents autonomes et le développement difficile, et met en avant ses performances pour piloter directement un ordinateur ou un navigateur. Il est pour le moment réservé aux abonnements Pro, Business et Enterprise (et à ChatGPT Plus par vagues ou via A/B testing on dirait).

Comment choisir, en vrai

Dans la pratique, j’observe beaucoup d’usage de Luna et Sol. Luna est adoré pour son rapport qualité-prix, surtout quand il est poussé avec un effort de raisonnement plus élevé où il devient étonnamment bon pour un prix toujours très bas (un réglage sur lequel je reviendrai une autre fois).

Sol est super pour planifier, et Astra fait le buzz comme tout nouveau modèle. Terra, au milieu, est un peu le mal-aimé : moins spectaculaire, parfois critiqué, vite mis de côté alors qu’il fait le travail pour une bonne partie des tâches du quotidien.

Pour débuter, je dirais que partir de Terra au milieu puis ajuster - monter vers Sol si ça coince, descendre vers Luna quand ce sont des petites tâches bien cadrées - n’a rien de déconnant. Mais ce n’est qu’un raccourci pratique. Ce qui compte vraiment, c’est d’adapter le modèle à la tâche ; le réflexe « défaut, puis monter ou descendre » est juste l’astuce la plus simple pour y arriver sans trop se prendre la tête.

J’utilise beaucoup Luna quand la tâche est répétitive, volumineuse, avec un cadre précis : extraire des champs, classer, reformuler, générer des variantes de titres, coder avec un périmètre restreint. Ou pour du plus compliqué s’il existe déjà un plan détaillé, Luna est un super exécutant.

Je monte vers Sol quand j’ai besoin de creuser plus loin ou de croiser plusieurs contraintes : un bug qui résiste, un audit de sécurité, une analyse où l’erreur coûte cher. J’aime aussi le sortir pour explorer et planifier. Petite réserve entendue côté communauté : poussé à l’effort maximal, Sol a tendance à trop réfléchir sur des questions qui n’en avaient pas besoin, et à faire du over-engineering.

Et Astra ? Je ne l’ai pas encore testé, mais je lui donnerais le même rôle d’exception qu’à Fable côté Claude : cybersécurité, un agent très autonome, la mission longue où on accepte d’attendre longtemps pour un résultat plus fiable (normalement :)).

Un modèle par défaut, pas un modèle unique

Comme pour Claude, l’idée n’est pas de trouver LE modèle et de s’y tenir à vie. C’est de partir d’un choix par défaut raisonnable, puis d’apprendre en pratiquant à repérer quand descendre ou monter pour utiliser le modèle le plus adapté à la tâche dès le début.

Et promis, bientôt on parlera d’orchestration car c’est tout autant valable avec les modèles d’OpenAI.

Oui, vous savez, ces petits noms à côté de la barre de discussion. Sonnet, Opus, Haiku, Fable. Que ce soit dans le chat web, Claude Cowork ou Claude Code, ou en API, ces noms ont un réel impact sur la qualité de la réponse, de l’exécution de la tâche et la facture. Ce n’est pas juste un petit nom de compagnon :)

Note : Quand je parle de facture, ça vous concerne même si vous payez un prix fixe par abonnement - un modèle cher dépensera votre quota plus rapidement. Le prix au token permet d’avoir un ordre de grandeur même si on n’utilise pas Claude via API.

Pourquoi ça compte de bien choisir

L’idée de base est simple : un modèle, c’est un compromis entre intelligence, vitesse et coût. Plus un modèle raisonne finement, plus il coûte cher et plus il est lent à répondre. Ce n’est pas un détail technique réservé aux développeurs qui optimisent une facture d’API : ça se sent directement dans l’usage, même via le chat web ou l’application de bureau.

Prendre un modèle trop léger pour une tâche qui demande de la réflexion se concluera probablement par une réponse incomplète, voire à côté de la plaque. Ou parfois, on arrive au résultat mais avec beaucoup plus d’aller-retours, et donc un coût + temps qui pourrait dépasser celui du modèle supérieur.

À l’inverse, prendre un modèle trop lourd pour une tâche simple ou très spécifiée, c’est le risque d’augmenter inutilement la facture et le temps de réponse, et même de divaguer vu que le modèle va se mettre à vouloir beaucoup raisonner - il pourrait sortir plus facilement du cadre que vous lui avez donné.

Un autre point à avoir en tête, l’écologie. Ce serait dommage de constamment utiliser un modèle surdimensionné pour trier trois mails, on peut largement s’éviter ce gaspillage - pour chasser ces foutus moustiques tigres, j’utilise mes mains voire la raquette électrique et non un lance-flamme… même si, je l’avoue, je pourrais me laisser tenter.

Bref, le bon modèle n’est pas le plus puissant disponible. C’est celui qui correspond à la tâche. La solution adaptée au besoin, comme toujours :)

Ce que sont Haiku, Sonnet, Opus et Fable

Anthropic (l’entreprise derrière Claude) range ses modèles sur une échelle du plus rapide au plus capable. Voici où ça en est à l’heure où j’écris ces lignes (à vérifier sur la page officielle si ça change entre-temps).

Haiku 4.5 est le plus rapide et le moins cher (1 $ / 5 $ par million de tokens en entrée / sortie). Contexte de 200 000 tokens, une génération de retard sur les autres (le 4.5 a son importance). Anthropic le pense pour le volume : extraction de données, classification, tri, un sous-agent qui fait le sale boulot répétitif pendant qu’un modèle plus costaud supervise.

Sonnet 5 est le modèle “couteau suisse” qui équilibre les trois curseurs coût-temps-raisonnement (2 $ / 10 $ par million de tokens). Avec son 1 million de tokens disponible en contexte, c’est le modèle par défaut de Claude sur les plans gratuit et payant. Anthropic le recommande pour la majorité des usages : écrire du code, rédiger, analyser un document, faire tourner un agent.

Opus 5 monte d’un cran sur le raisonnement (5 $ / 25 $, même contexte de 1 million de tokens). Anthropic le pense pour l’entreprise : du code agentique complexe, de l’analyse juridique ou financière dense, les cas où une erreur de raisonnement coûte cher. (Note à part, je n’aime pas cette catégorisation “pour l’entreprise”, je trouve que ce n’est pas du tout pertinent. On y reviendra.)

Fable 5.1 est le plus haut de gamme disponible pour le public (Mythos étant sa version brute réservée à quelques acteurs) pensé pour les travaux longs et autonomes (10 $ / 50 $) : un agent qui tourne plusieurs heures sur un dépôt de code entier sans supervision.

Comment choisir, en vrai

Le discours officiel actuel d’Anthropic penche plutôt vers : “partez du modèle le plus intelligent disponible, puis ajustez le niveau d’effort pour maîtriser le coût ou prenez un modèle en-dessous”. D’une certaine manière, l’argument tient debout — un modèle plus capable se trompe moins souvent, ça peut coûter moins cher qu’un petit modèle qui tâtonne à plusieurs reprises. Ok, mais est-ce qu’il n’y aurait pas aussi un argument financier derrière ? Je suis sûr que ça les arrange un peu qu’on consomme les plus chers d’abord :)

Alors comment on fait ? Concrètement, je conseillerais de choisir le modèle Sonnet par défaut. Pour écrire, coder, analyser un document, faire tourner un agent qui touche du code ou du texte, Sonnet fait très bien le travail dans la majorité des cas, et pour prix + temps raisonnable.

Il est très polyvalent, que ce soit pour des tâches très techniques (créer un endpoint avec ses validations et tests, faire un bon refactoring, faire de la revue de code), ou pour des tâches plutôt métier (écrire une proposition client, préparer son plan de posts LinkedIn, synthétiser un ensemble de réunions et en tirer des actions concrètes).

Je descends vers Haiku quand je suis sur des tâches répétitives, que j’ai du volume à traiter, peu de nuance, un cadre clair, quelque chose de très spécifié. Trier, extraire, formater, classer, … les doigts dans le nez pour Haiku. Suivre un plan détaillé avec chaque étape, qu’un autre modèle aurait pu rédiger, est aussi dans ses cordes.

Je monte vers Opus quand Sonnet échoue vraiment, que j’ai besoin de beaucoup plus d’exploration ou raisonnement, que je touche une grande complexité : un bug incompréhensible qui traverse de nombreux fichiers, un contrat de 80 pages à décortiquer avec des clauses à analyser, planifier une stratégie, un plan de migration à rédiger point par point en pensant à tous les détails, effets de bords, etc.

Et Fable ? C’est plutôt une exception. Au vu du prix très élevé et de sa lenteur, on y réfléchit à plusieurs reprises avant. Je pense qu’on a plutôt envie de le sortir pour des questions de cybersécurité avancées, si on veut un agent autonome pendant des heures, qu’on fait de la recherche, qu’on est sur quelque chose d’assez massif. Ou quand on veut frimer avec son abonnement Max 20x en créant un PoC de site web 3D qui sera jeté juste après l’avoir montré. Je pense qu’on peut souvent essayer de faire échouer Opus avant de monter sur du Fable.

Un modèle par défaut, pas un modèle unique

Avec Sonnet par défaut, on ne tombe normalement jamais trop loin de la plaque. Si vraiment on ne sait pas ou qu’on débute avec tous ces trucs d’IA, ça me semble le meilleur choix de départ. Et puis, petit à petit, on apprend. On commence à prendre des habitudes et à repérer quel modèle est le plus adapté à chacun des types de tâches que l’on fait régulièrement.

Si vous êtes toujours resté sur le même modèle, ça vaudrait le coup d’essayer de changer, d’expérimenter ce qu’il se passe, pour découvrir ce qui sera le plus adapté pour vous.

Il y a un aspect que j’ai subtilement évoqué aujourd’hui : et si, pour une même tâche, on faisait travailler plusieurs modèles ensemble — un pour planifier, un autre pour exécuter ? C’est un vrai sujet, qui permet d’aller encore plus loin dans l’idée “le bon modèle pour la bonne tâche”, et ce sera pour un prochain article ;)

Je ne suis loyal à aucun labo, alors j’ai fait le même exercice un peu plus tard côté OpenAI -> Astra, Sol, Terra, Luna : quel modèle ChatGPT choisir ?.

Bon le petit soucis, c’est que cette “formation” donnée sur AlphaTango se compose surtout de documents PDF avec les réglementations publiés par l’État et les ministères. L’un d’eux fait presque 70 pages - plutôt sympa à lire quoi.

Dans le même temps, j’avais aussi envie de prendre l’air et faire du sport. J’ai donc commencé par chercher sur YouTube des vidéos assez complètes que je pourrais écouter dehors. Je vais faire court, je n’ai pas trouvé ce que je voulais.

Et puis j’ai eu une idée : pourquoi ne pas fabriquer moi-même le podcast dont j’avais besoin ?

Transformer des documents en épisodes audio

J’ai rassemblé les documents réglementaires et je les ai importés dans Gemini Notebook, l’outil dont j’avais déjà parlé dans un précédent article pour apprendre et discuter avec ses propres sources.

L’intérêt dans mon cas, c’est de travailler à partir de sources précises. J’ai besoin que les réponses soient liées aux documents fournis au lieu de reposer uniquement sur les connaissances générales du modèle. Et c’est justement l’un des points fort de Notebook. Pour de la réglementation, ça me semble assez important :)

Notebook propose aussi un espace appelé Studio, qui permet de produire différents contenus à partir des documents ingérés. Je l’avais déjà testé rapidement, mais sans vraiment pousser l’expérience. Cette fois, je me suis intéressé à la génération audio. J’ai commencé par lui demander de construire un plan pour trois épisodes d’une vingtaine de minutes. Une fois ce plan validé, je lui ai demandé de rédiger le script du premier épisode, puis de générer l’audio. Et idem pour les deux autres.

Sans trop d’effort, j’ai obtenu trois épisodes de 20 à 25 minutes prêts à être écoutés depuis mon téléphone.

L’impression d’écouter un vrai podcast ?

Je dois avouer que le résultat m’a un peu bluffé. Ce n’était pas parfait, évidemment, mais c’était largement écoutable. Allez, j’ai même envie de dire que c’était agréable. Je savais qu’on avait de très bonnes avancées sur la voix, notamment avec ElevenLabs par exemple, mais je m’attendais à avoir un rendu plus gadget via Gemini Notebook.

Deux voix dialoguaient autour du sujet, avec des intonations, des hésitations et quelques tics de langage qui donnent habituellement une impression de naturel aux podcasts. On est loin des voix robotiques que l’on entendait encore il n’y a pas si longtemps. Le tout amené avec une narration, des fils rouges intéressant pour amener chaque grandes thématiques. Ouais, quelque chose de vraiment agréable à écouter comme je disais.

Surtout, j’ai appris ce que je voulais apprendre. Le contenu était bien amené, progressif, et le format rendait l’ensemble beaucoup moins intimidant (chiant) qu’un long document réglementaire.

Quelques loupés par-ci par-là se sont insérés dans le podcast, évidemment. Certaines prononciations sont étranges et quelques phrases sont étrangemment interprétées. J’en ai une qui m’a fait sourire : pour la question « Mais la France y ajoute une spécificité, non ? », la diction a donné quelque chose comme : « … une spécificité. Non. ». Quelques mots massacrés aussi (« les propriéto de drones » - a priori je connais pas ce terme.

Mais dans le fond, c’était négligeable. J’en retiens beaucoup plus du positif que du négatif.

Une expérience à recommencer

Pour le temps que j’ai passé à préparer les sources, construire le plan et générer les épisodes, je suis content. L’effort était faible par rapport au bénéfice que j’en ai tiré. J’ai pu réviser mon sujet sans devoir me taper une lecture de 70 pages réglementaires, et j’ai réussi le QCM derrière (38/40).

C’était une expérimentation, et vu le résultat, je me vois bien recommencer. Testez de votre côté si l’occasion s’y prête. Ça pourrait vous surprendre aussi. Et c’est toujours un autre moyen de consommer des formats que l’on aime moins, ou de rassemble de nombreuses sources différentes.

Et puis, si vous êtes à la base consommateur de podcast, en obtenir un sur demande, c’est tentant non ?

Je suis passé à FluidVoice, une application de dictée pour macOS qui propose toujours le fonctionnement en local - la voix et le texte restent sur mon macbook tant que l’on n’active pas volontairement un fournisseur cloud. Qui est gratuite, et en plus, qui est également open source cette fois. J’aime bien que le code puisse être ouvert, surtout quand ça touche à des dommaines assez sensible.

D’ailleurs, ça me fait penser à son auteur. À la base, je suis tombé sur FluidVoice en traînant sur Reddit. Son auteur m’avait marqué. Il disait grosso-modo “ne payez jamais pour utiliser votre voix, et gardez là privée” en expliquant pourquoi il avait lancé ce projet et qu’il l’avait open-sourcé.

Ça marche très bien chez moi. L’onboarding est même plus agréable que celui de Vowen : il accompagne le choix du modèle vocal selon la langue, la précision et la rapidité recherchées. Pas besoin de savoir à l’avance lequel de Whisper, Parakeet ou un autre modèle est le plus adapté pour nous.

Et puis, il y a les petites fonctionnalités en plus. FluidVoice propose localement des choses que Vowen réserve à son offre payante : amélioration de la dictée, reformulation directement dans les champs de texte, historique audio optionnel… De quoi continuer à jouer avec sa voix.

Si ça vous tente, attendez, il y a encore mieux. Il y a aussi le Command Mode. L’idée est assez marrante : ouvrir des applications ou déclencher certaines actions à la voix. Ce n’est pas le genre de chose que je vais utiliser toute la journée — je suis encore très copain avec mon clavier — mais pour quelques moments où je préfère être debout les mains libres, pourquoi pas ? La démo donne une bonne idée du potentiel.

Bref, si vous cherchez une solution de dictée vocale locale sur Mac, FluidVoice mérite clairement un essai.

Je prenais l’exemple d’OpenClaw, mais le sujet dépasse largement cet outil. Claude Cowork/Code, Chat GPT Codex et les autres agents deviennent vraiment intéressants dès qu’on leur donne des outils, des skills, des données. Et c’est aussi là qu’ils peuvent potentiellement faire de très mauvaises choses si on leur donne de mauvaises instructions. Ils vont faire ce qu’on leur dit, mais pas forcément ce que l’on veut.

Un skill est plus que du texte

Un skill se présente en général sous la forme d’un fichier Markdown SKILL.md. Il explique à l’agent quoi faire pour réaliser une tâche, un processus. Ça a l’air innocent. Après tout, c’est juste du texte. Et effectivement, le skill seul n’est pas un problème. Sauf que l’agent IA, lui, est là précisément pour appliquer ces instructions, avec les outils, les données et les autorisations que vous lui avez accordés.

Un skill peut aussi embarquer des scripts, demander l’installation de dépendances, télécharger d’autres fichiers ou appeler des services externes. Il faut donc le considérer comme un élément de notre chaîne d’approvisionnement logicielle. Un peu comme une dépendance npm ou un script trouvé sur GitHub. Ce n’est pas une recette de cuisine inoffensive.

Pour vous donner quelques exemples de risques les plus évidents :

• Le vol de secrets : lire des variables d’environnement, des fichiers de configuration, des clés SSH ou des tokens, puis les transmettre ailleurs. Typiquement, on va essayer de vous voler vos clés d’api Claude/OpenIA, et vous vous retrouverez à payer l’usage d’un autre.
• L’exfiltration de données : envoyer le contexte de vos conversations, le contenu de fichiers ou des informations de votre projet vers un serveur externe.
• L’exécution de code : vous faire lancer une commande shell, télécharger puis exécuter un script distant, ou installer une dépendance douteuse. Votre machine pourrait devenir vérolée, servir à faire des attaques DDoS, etc.
• L’injection de prompt : cacher ou formuler des instructions pour que l’agent contourne ses règles, élargisse son périmètre ou fasse quelque chose qui n’a rien à voir avec la promesse du skill.

Le plus vicieux, c’est que ces éléments n’ont pas besoin d’être particulièrement cachés. Un curl | bash au milieu d’une procédure d’installation par exemple, une demande d’accès trop large, ou une URL qui récupère un script peuvent déjà mériter d’y prêter attention.

La plupart du temps, je crée mes propres skills (enfin, je fais créer) pour coller à mes usages. Mais il m’arrive d’en tester de sources externes. Dans ce cas, je préfère vérifier. C’est rapide, et je m’enlève un risque inutile.

Scanner un skill avant de l’utiliser

Mon outil de référence aujourd’hui est SkillSpector, un projet open source de NVIDIA. Il peut analyser un dépôt Git, un dossier, une archive ou un simple fichier SKILL.md, et remonte ensuite un score de risque et quelques explications pour attirer notre attention.

Il détecte par exemple les accès aux variables d’environnement, les lectures de fichiers sensibles, les téléchargements et exécutions de scripts, le code obfusqué, les dépendances vulnérables, ou encore les tentatives de manipulation de l’agent. Il va même chercher les caractères invisibles (oui, certains sont vicieux !). Pour les plus curieux, je vous invite à fouiller les documentations des outils (README de SkillSpector par exemple) pour découvrir les différentes catégories et attaques possibles, il y en a un paquet.

Je reviens à notre outil, SkillSpector. La version la plus simple fonctionne en analyse statique : elle lit les fichiers et cherche des comportements suspects. Ça tourne en local. Pas besoin de tokens, de clé d’API, de compte ou d’abonnement. Après installation de l’outil, on peut par exemple scanner un dépôt avant même de l’installer :

skillspector scan https://github.com/user/awesome-super-skill --no-llm

Le --no-llm est important ici : il force ce mode local et statique. C’est rapide, gratuit, et ça donne un premier filtre très utile. On peut également scanner un dossier sur notre machine, ou un fichier de skill directement. On a du choix.

Évidemment, un score faible ne transforme pas magiquement un skill en un truc sûr à 100 %. Le risque zéro n’existe pas vraiment en terme de sécurité informatique. Mais c’est un bon indicateur pour se questionner et nous aider à juger. À côté de ça, je vérifie aussi qui le maintient.

Quelques alternatives en ligne

Si vous ne voulez rien installer, ESET AI Skills Checker permet d’analyser l’URL d’un skill depuis le navigateur. Pas déconnant de la part de ESET, que je connaissais historiquement pour les anti-virus. Leur approche inclut une analyse des liens externes et de la chaîne de téléchargement. Pratique pour une première vérification.

J’ai aussi vu skill-spector.com, un service web qui dit s’inspirer de l’approche de NVIDIA et génère des rapports d’audit lisibles, avec score et points d’attention. En revanche, faites attention à ce que vous envoyez à un service en ligne : pour un skill interne ou contenant des informations sensibles, je privilégierais un outil local.

Et une alternative “boite à outils”

Petite dernière proposition. Je suis aussi tombé sur skillshare pendant mes recherches sur l’audit de skill. Celui-ci peut être intéressant si vous avez certains usages autour des skills : il propose, en plus de l’audit, de synchroniser vos skills entre Codex, Claude Code et beaucoup d’autres outils.

Bref

Les skills c’est cool, mais c’est aussi une potentielle porte d’entrée pour des problèmes. Que ce soit volontairement malveillant ou non d’ailleurs - un skill peut très bien avoir des vulnérabilités sans que l’auteur en soit conscient.

Donc un peu comme on évite d’installer des logiciels suspects sur notre machine sans creuser un minimum, on évite de télécharger des skills qui viennent de n’importe où et n’importe qui.

Je suis pas mal les nouveautés autour de l’IA et des agents. Parfois via le canal créateurs de contenu qui expérimentent beaucoup avec les agents. Ils testent les outils, partagent ce qui fonctionne, leurs use case, et ils inventent parfois de nouveaux mots pour décrire leurs façons de faire.

Et puis je suis tombé sur ce tweet de Peter Steinberger, le créateur d’OpenClaw :

Are we still talking loops or did we shift to graphs yet?

Peu de temps avant, je voyais du loop engineering partout. Maintenant, c’est le graph engineering qui commence à faire son apparition.

J’ai voulu comprendre un peu mieux ce qui se cachait derrière. Et je me suis dit : « Ah oui. On est en train de remettre des noms sur des choses que l’on connaît déjà assez bien. »

Pas exactement les mêmes choses, évidemment. Le contexte est nouveau, les outils aussi. Mais il y a comme un air de famille avec pas mal de pratiques tech et produit qui elles sont déjà ancrés depuis bien longtemps.

Avancer par petites étapes, encore et toujours

Le loop engineering, on pourrait dire que ça consiste à donner un objectif et des critères de réussite à un agent plutôt que de lui expliquer comment faire tout son travail. On lui donne un but à atteindre, pas une liste d’étape version notice IKEA. L’agent essaye, observe le résultat, corrige et recommence.

La première chose qui me vient, ce sont les tests d’acceptances. Forcément, il faut donner de bons critères de succès pour que l’agent sache de lui-même quand c’est est-ce qu’il a bien atteint son objectif.

Ça me fait penser aux boucles de feedback que l’on recherche partout quand on fabrique un produit ou du logiciel. On fait une petite chose, on vérifie si elle répond au besoin, on ajuste. Un test automatisé, une démo, un retour utilisateur, une revue de code, autant de façons d’apprendre avant d’avoir construit un gigantesque truc impossible à déplacer.

Ça me fait penser au quoi versus comment. Un PO ne va pas expliquer aux développeurs comment fabriquer la page de connexion. On explique autrement vers où on veut arriver, les collaborateurs ne sont pas de simples exécutants. On va donner de l’autonomie pour que l’équipe décide comment faire. Tiens, on pourrait penser aux OKR aussi.

Même idée avec le graph engineering. Au lieu de demander à un agent de réaliser une immense tâche dans son coin, on la découpe. On confie des responsabilités plus petites, on explicite ce qui dépend de quoi, on peut vérifier chaque morceau plus facilement.

Ça rappelle forcément le découpage d’un problème, les responsabilités bien séparées, les incréments livrables, les petites pull requests, … Bref, tout ce que l’on essaie de faire quand on veut garder un projet compréhensible et qui peut facilement évoluer.

On dirait que les agents aussi préfèrent qu’on évite de leur donner une mission du type : « Refais-moi toute l’application, et si tu as le temps pense aussi à la stratégie marketing. » Qui aurait pu prédire ? :)

Donner le bon contexte

Autre sujet que je vois revenir en permanence : le contexte.

Pour qu’un agent fasse correctement son travail, il faut lui donner les bonnes informations. Les objectifs, les contraintes, les exemples et contre-exemples, les fichiers utiles, la façon dont le projet est organisé, ce qui est acceptable ou non, des critères de succès, etc. Sinon, il devra deviner. Et quand une IA devine, elle le fait souvent avec une confiance assez impressionnante (les fameuses halucinations).

Là encore, ça me semble plutôt familier, et peut-être vous aussi.

Un nouveau développeur qui arrive dans une équipe, un collègue qui reprend un sujet, une personne à qui l’on délègue une tâche : tout le monde a besoin de contexte. Les décisions passées, le vocabulaire métier, les contraintes implicites, la définition de « c’est terminé ». Plus on explicite, plus on s’aligne, plus on travaillera efficacement ensemble.

Les fichiers d’instructions pour agents, les dossiers de contexte et les exemples de livrables sont peut-être de nouvelles façons de faire, mais le besoin qu’ils adressent est bien plus vieux : permettre à quelqu’un — ou quelque chose — de comprendre avant d’agir.

Rien de très neuf au final

Mon propos n’est pas de critiquer les personnes qui parlent de ces sujets, ou dire qu’elles n’inventent rien. Personne n’a la même histoire, le même… contexte. Je trouvais juste cette observation amusante, et j’avais envie de la partager.

Notre usage de l’IA et des agents nous faire (re)découvrir des partiques tech et produit, déjà existante. Sous une forme légèrement différente. Est-ce que l’IA remplacera nos jobs ? J’en sais rien. Mais on dirait que pour le moment, certaines façons de faire reste utile même si l’outil change. Et ça, c’est intéressant.

La culture tech et produit n’a pas pris un coup de vieux. Et c’est peut-être pour ça qu’elle était (et est toujours) pertinente.

Si on regarde en arrière, ce format était surtout utilisé par les développeurs et certains outils. C’est par exemple mon cas, je l’utilise depuis plusieurs années de différentes manières : un README qui accompagne le code des projets, mon système de notes avec Obsidian, et même ce blog - j’écris mes articles en Markdown, et c’est ensuite le moteur Hugo qui transforme ça en HTML.

Aujourd’hui, n’importe qui peut être amené à devoir lire ou manipuler un fichier Markdown en jouant avec l’essor des applications d’agents IA comme Claude Cowork ou ChatGPT Codex (voir mon guide sur la prise en mains d’agents IA). C’est également plus économique (en token) que des fichiers PDF.

La bonne nouvelle ? C’est incroyablement simple à apprendre. Pas besoin d’être développeur ou d’y connaître quelque chose dans la technique. En 5 minutes, vous aurez compris l’essentiel. Voyons ça ensemble.

C’est quoi, au juste ?

Markdown, déjà, c’est un format de fichier texte avec pour extension .md. Ça contient simplement du texte. On y retrouve le contenu de ce texte et sa mise en forme (gras, italique, …).

Quand on rédige un document sur Word ou Google Docs, si on veut faire de la mise en forme, on doit alternativement surligner des morceaux de texte puis cliquer sur un bouton : ça je veux que ce soit en gras, ça c’est en rouge, ça c’est le grand titre, etc. Et quand on copie-colle le texte ailleurs, on prie pour que ça applique bien le bon style :)

L’idée du format Markdown, c’est d’écrire le contenu textuel et d’utiliser quelques symboles pour indiquer la mise en forme, directement pendant la saisie. Par exemple : Une phrase avec un mot en *italique*.. On balise le texte (c’est un langage de balisage, comme HTML, mais bien plus simple).

Markdown se veut simple, concis, et lisible. On veut pouvoir facilement lire le texte contenu dans un fichier Markdown. Qui dit simplicité dit aussi moins de possibilités - ce format va à l’essentiel. On ne fera pas autant de folie qu’avec Word ou une page web. Et c’est tant mieux.

L’essentiel pas à pas

Les titres

Pour hiérarchiser avec des titres, des sections, on utilise le symbole dièse (#). C’est simple : plus il y a de dièses, plus le titre descend en niveau. On peut aller jusqu’à 6.

# Titre principal (H1)
## Titre de section (H2)
### Sous-titre (H3)

Mettre en valeur le texte

Besoin d’insister sur un mot ou d’ajouter du relief ? C’est le rôle de l’astérisque (*).

• Pour l’italique, on encadre les mots d’un astérisque : *italique*
• Pour le gras, on en met deux de chaque côté : **gras**
• Et si on veut vraiment appuyer en combinant les deux, on en met trois : ***les deux***

Simple, non ?

Listes

Pour faire une liste, un simple tiret (-) suivi d’un espace, et le tour est joué.

- Premier point
- Deuxième point

Ça marche aussi avec l’astérisque (*). Et si vous préférez une liste ordonnée, tapez simplement 1., 2., etc.

Citations

Pour citer quelqu’un ou mettre en avant une phrase importante, utilisez le chevron droit (>) en début de ligne. Ça donne ça :

Je sais que je ne sais rien.

Liens et images

C’est le moment le plus compliqué, mais promis, ça reste simple. Pour faire des liens, on utilise la combinaison de crochets et de parenthèses.

• Pour un lien : [le texte du lien](URL). Par exemple : [mon blog](https://jordanchapuy.com).
• Pour une image : c’est exactement la même chose, avec un point d’exclamation devant. Par exemple : ![Mon logo](https://site.com/logo.png).

Blocs de code

Même si vous n’écrivez pas de code, cette syntaxe reste utile pour isoler du texte, faire comprendre que c’est un extrait, ou montrer une formule sans que l’éditeur essaie de la formater. On utilise le backtick (`).

• Pour un passage au milieu d'une phrase, on l’encadre d’un seul backtick : `comme ceci`.
• Pour un bloc entier de plusieurs lignes, on utilise trois backticks (```) avant et après le bloc.

Ceci est un bloc de code.

Exemple complet

Voici un rapide exemple de contenu Markdown, pour assembler ce que l’on a vu. Et ça me permet de montrer une précision utile.

Après la plupart des “blocs” comme un titre, une citation, une liste, un bloc de code (tout ce qui devrait retourner à la ligne ensuite), il faut sauter une ligne pour que la mise en page soit bien prise en compte.

# Instant Kaamelott

Vais-je parler de Kaamelott dans chacun de mes articles ? 

Nooooon, je ne le cite pas tout le temps... Mais *un peu quand même*.

> Ouais, c'est pas faux ~ Perceval.

## Construire un château fort

Je m'y connais bien là-dedans, j'ai dû en bâtir **une dizaine** quand j'étais enfant. Rien de plus simple, il vous faut :

- Du [sable](https://fr.wikipedia.org/wiki/Sable),
- De [l'eau](https://fr.wikipedia.org/wiki/Eau), pour faire une sorte de ciment avec le sable, mais pas trop quand même,
- Un seau, c'est plus simple pour faire les tours.

```
[FICHE TECHNIQUE]
- Difficulté : Facile
- Temps de construction : 20 minutes
- Résistance aux vagues : 0, prévoir des douves
```

Vous voyez, ça reste facilement lisible. J’ai même envie de dire que si on ne connaît pas le Markdown, on peut tout de même comprendre le contenu.

À vous de jouer

Voilà. C’est suffisant pour la grande majorité du temps. Oui, il existe quelques autres mise en forme pour faire des tableaux complexes ou barrer du texte, mais c’est largement dispensable au début.

Pour pratiquer sans rien installer, je vous conseille d’aller sur Dillinger.io ou tout autre site qui propose une preview Markdown en ligne. Vous écrivez à gauche en texte brut, et le résultat s’affiche à droite en temps réel.

Prenez un instant pour faire le test ;)

Il n’a pas fallut attendre longtemps. Tout récemment (on parle de 48h à peine), un nouveau modèle a été dévoilé et la situation illustre bien ce que je disais. Souhaitons la bienvenue à Kimi K3, le nouveau nouveau meilleur.

Comme d’habitude, ça fait sensation. Si on regarde les créateurs de contenu, les influenceurs et même certains médias (ce qui est ecnore plus triste), tout le monde lâche ses plus beaux superlatifs : “C’est le meilleur”, “Ça va tout tuer”, “Fable 5 est déjà dépassé”. Bon, si on regarde dans le passé, c’est systématiquement la même chanson à chaque sortie de grand modèle.

J’ai envie d’en profiter pour prendre tout ça à contrepied, apporter de la nuance et sortir de cette logique de faire du sensationnel pour avoir des vues.

Un point sur les benchmarks

Qu’est-ce que ça veut dire concrètement, “être meilleur” ?

Souvent, l’élément phare cité dans les articles/vidéos/newsletter est un benchmark. Un tel est le nouveau meilleur parce qu’il a gagné plus de points que l’autre.

Mais rappellons quelques éléments :

• les benchmarks sont plus ou moins fiables, ils mesurent une fration des capacités et sont parfois purement subjectifs,
• c’est arrivé que certains modèles ont été (in)volontairement entraînés sur des benchmarks, ce qui fausse la donne,
• on a vu plusieurs fois des modèles devenir “moins bon” un peu après la release,
• le classement bouge sans cesse, pas de quoi se précipiter à changer.

Donc le benchmark, oui c’est un moyen de comparer, mais il ne faut pas rester dessus. Je pense qu’il faudrait plutôt garder ça comme un moyen d’avoir un aperçu, un tri rapide.

Là comme ça, j’ai l’idée de l’atelier eXtreme quotation qui me traverse l’esprit - ce modèle fait partie da la famille du top top (XL), ou non plutôt basique (du M).

Kimi K3, en surface

Parlons maintenant de Kimi K3 pour donner du contexte. C’est un modèle open-source de 2,8 billions de paramètres, qui rivalise avec les géants propriétaires sur certains tests de programmation, et qui occupe même la première place du classement Arena.ai pour le code front-end.

Il est devant Fable 5, qui était jusque-là le nouveau roi avec GPT 5.6 Sol, et tout ça, pour un prix bien inférieur.

Donc en résumé, on a mieux et moins chère. Que demander de plus ?

En profondeur

Ce qui m’a donné envie d’écrire, c’est une vidéo du créateur Chase AI. Il a sorti une comparaison intéressante entre Kimi K3, Claude Fable 5 et GPT 5.6 (ou ChatGPT).

Déjà, on commence à voir de la nuance - il y a d’autres aspects qui sont analysés. Par exemple, la rapidité, les hallucinations, l’économie des tokens, etc. On ne reste pas juste sur le classement de quelques benchmarks. Et c’est intéressant car on voit que ça pêche sur certains points.

Je ne vais pas tout détailler, car mon but n’est pas de descendre Kimi K3 ou d’encenser Fable 5, on s’en fout. Mais plutôt de montrer que la réponse est plus complexe qu’il n’y paraît. Donc rapidement, quelques aspects :

• La “consommation de token” : Pour une même tâche, pour un même prompt, chaque modèle va consommer plus ou moins de tokens. Kimi est réputé pour en gaspiller beaucoup plus.
• Le “coût par tâche” : Un comparaison du coût réel pour accomplir une tâche complexe. Kimmy K3 (0,95 $) est légèrement moins cher que GPT 5.6 (1,04 $), mais Fable 5 est beaucoup plus onéreux (2,75 $). Malgré le “coût par token” très faible de Kimi, le coût réel ne se démarque pas autant des autres à cause d’une plus grande consommation d’un côté / d’un meilleur optimisation de l’autre côté.
• L’ “index d’omniscience” : C’est une mesure sur la fiabilité des réponses et la quantité d’hallucinations. Fable score 40 points sur 100, GPT score 22, Kimi score 18.
• La “vitesse d’exécution” : Kimi est plus lent que ses copains Fable et GPT.

On s’éloigne finalement un peu de la hype qui entoure sa sortie et de tous les superlatifs. Finalement, il y a du bon et du moins bon, on nuance, on mitige. On n’est plus trop sur le fameux “Fable-killer”.

Le cas pratique

J’aime bien aussi l’expérience que montre Chase AI dans sa vidéo. Il a fait créer un dashboard de voyage avec la planète en 3D aux trois modèles, avec les mêmes instructions. On obtient des informations concrètes à analyser.

Dans ce cadre là, Kimi K3 s’avère être un énorme consommateur de tokens. Pour la même demande, il a englouti 21,5 millions de tokens là où Fable 5 n’en a consommé que 3,5 millions. Donc oui, Fable coûte plus cher au token mais il a été drastiquement plus efficace. Le prix final ne reflète pas la simple grille tarifaire. GPT 5.6 s’avère même être le moins cher des trois.

Le temps d’exécution est un autre indicateur. Là où Kimi K3 a ramé pendant plus d’une heure et demie, Fable 5 a plié l’affaire en 17 minutes et ChatGPT en 25 minutes.

Attention, cette expérience est imparfaite et unique. Ça ne vaut aucune vérité. Il faut aussi voir la qualité du rendu (subjectif) et surtout avoir bien plus d’expériences. Et probablement avoir une approche plus scientifique. Je m’appuie simplement sur ces résultats pour démontrer qu’il faut relativiser.

Retour à la base

Tout ça pour rappeler quelque chose que j’aime bien dire : quel est notre besoin ? Selon ce que l’on souhaite entreprendre, on aura besoin d’un outil moins cher, d’un modèle qui hallucine moins, d’une exécution plus rapide ou d’une plus grande qualité. Et puis, il y a différents domaines - un modèle peut exceller en design frontend et être à la traîne sur des questions scientifiques ou de la rédaction pure.

Donc sortons du sensationnalisme facile. Apportons de la nuance et restons centrés sur nos besoins réels.

Avec les agents IA, on ne demande plus seulement une réponse dans une conversation. On installe l’agent quelque part avec des fichiers, du contexte, des règles, des pouvoirs. Et là, il peut commencer à travailler dans un environnement, pas seulement répondre dans une fenêtre de chat.

C’est ce qui m’intéresse dans cet article : faire un premier pas concret. Pas devenir expert en automatisation, gestion de la mémoire, ou autres concepts qui gravitent autour. Non, juste créer un premier workspace IA, lancer une vraie tâche, et comprendre pourquoi ça change autant de choses.

Derrière ce titre à double sens, je vous propose donc un début accessible pour tous. Pas besoin d’être tech.

Rappel important : les IA (agent ou chat) peuvent réutiliser vos données. Faites attention au service et type d’abonnement que vous utilisez, et aux informations que vous communiquez.

Du chat à l’agent, il manque surtout un espace de travail

Dans l’article précédent sur les agents IA, je donnais l’image d’une boucle pour définir un agent : observer, décider, agir, observer à nouveau.

Un chat classique répond à ce qu’on lui donne. Si on oublie un contexte, il ne l’a pas. Si on veut qu’il reformate un fichier, il faut lui donner, expliquer la structure, récupérer le résultat, et le ranger quelque part. Ça marche, mais on finit vite par être l’assistant de notre propre assistant IA.

Un agent, lui, devient vraiment intéressant quand il a un endroit où travailler. Un dossier, des fichiers, des consignes, des exemples, du contexte, des notes, etc. Il devient davantage autonome pour atteindre un objectif.

Et c’est là-dessus qu’on va se concentrer. Notre premier pas avec les agents IA, ce ne sera pas d’écrire le prompt parfait, ni de trouver le meilleur modèle ou plateforme. Ce sera de créer un espace où l’agent peut comprendre notre contexte, poser les bonnes questions, puis produire quelque chose qui nous correspond.

Ah, et bonne nouvelle, ce premier espace est très simple à préparer.

Choisir une application, sans en faire une religion

Pour travailler avec un agent sur notre ordinateur, il faut généralement une application qui peut accéder à un dossier local, lire et manipuler des fichiers, lancer des commandes. C’est ce qui permet de passer du “chat” à un “agent qui travaille dans un projet”.

Aujourd’hui, on trouve plusieurs outils grand public dans cette famille : Claude Cowork côté Anthropic, ChatGPT Codex côté OpenAI, Antigravity côté Google, Cursor en précuseur pour les devs, et sûrement d’autres au moment où vous lirez ces lignes. Ce sont des applications à télécharger et installer sur un ordinateur.

Lequel choisir ? Honnêtement, pour commencer, je trouve que c’est moins important que le système que vous mettez en place autour.

Les modèles progressent vite, les abonnements changent, les limites bougent, et chacun aura ses préférences selon ses usages. J’en parlais déjà dans mon article sur le “meilleur” modèle IA : la bonne réponse dépend du contexte. Pour mes besoins actuels, j’ai une préférence pour Codex, avec Claude pas loin derrière. Mais ce n’est pas une véritée absolue.

L’important, pour ce premier exercice, c’est surtout de choisir un outil capable d’ouvrir un dossier de travail et d’agir sur des fichiers. Faites votre choix puis installez l’application sur votre ordinateur. Une fois que vous avez ça, on peut préparer l’espace de travail.

Préparer un premier workspace IA

On va partir sur une structure volontairement simple pour notre espace de travail. Ce n’est pas la bonne structure. C’est une structure pour commencer, que vous adapterez ensuite à votre façon de travailler et au fil de vos découvertes.

Une précision. Quand je parle d’espace de travail ou workspace, c’est tout simplement un dossier que vous ouvrirez avec votre application. L’agent pourra jouer avec tout ce qu’il y a à l’intérieur.

Vous allez donc devoir créer un dossier “workspace” où bon vous semble (sur votre bureau, dans vos documents) et avec le nom que vous souhaitez. Il faudra ensuite créer cet ensemble de dossiers et fichiers à l’intérieur du dossier workspace, qui correspond à notre structure :

workspace/
├── 00-contexte/
│   ├── a-propos-de-moi.md
│   ├── mon-style.md
│   └── regles.md
├── 01-projets/
│   └── premier-projet/
│       └── ...
├── 02-templates/
│   └── modele-xyz.md
└── 03-livrables/

Ici, plusieurs solutions. Via votre explorateur de fichier / Finder. Via Obsidian. Via un IDE ou en terminal. Peu importe. Ou sinon… pourquoi ne pas demander à un agent ? Après tout, on vient de dire qu’il peut manipuler des fichiers dans son espace de travail, alors profitons-en.

Faisons notre toute première tâche avec un agent :

• Lancez donc votre application (pour rappel, il s’agit de Claude Cowork, ChatGPT Codex, etc).
• Ouvrez votre dossier “workspace” (selon l’application, il faut créer un projet en ciblant le dossier).
• Démarrez une nouvelle conversation (en ciblant bien le dossier/projet) et demandez lui de travailler durement !

Crée l'arborescence de dossiers et les fichiers vides suivants dans mon workspace actuel :

workspace/
├── 00-contexte/
│   ├── a-propos-de-moi.md
│   ├── mon-style.md
│   └── regles.md
├── 01-projets/
│   └── premier-projet/
│       └── ...
├── 02-templates/
│   └── modele-xyz.md
└── 03-livrables/

Et voilà. J’en profite pour une rapide explication, à quoi servent chacun de ces dossiers ?

• 00-contexte contient ce que vous ne voulez pas répéter à chaque fois : qui vous êtes, comment vous travaillez, votre style, vos règles.
• 01-projets contient les informations et documents propres à chaque projet en cours. On peut imaginer des projets ma newsletter jardinage et ma super entreprise de plomberie par exemple.
• 02-templates garde la définition de vos formats à réutiliser. Le template d’une newsletter par exemple (les sections, la description de chaque section, etc), ou d’un mail de prospection.
• 03-livrables sert à ranger ce que l’agent produit.

Vous pouvez évidemment faire autrement. Ajouter un dossier archives pour les projets terminés. Un dossier ressources pour capturer des articles, posts, vidéos ou notes. On peut aussi définir des règles et styles par projet plutôt que pour tout le workspace. Ou partir sur une structure plus proche d’un wiki, comme le wiki proposé par Andrej Karpathy.

Ce qui compte, c’est que ça corresponde à vos besoins et que l’agent puisse se repérer sans que l’on doive tout réexpliquer à chaque prompt.

Les premières informations de contexte

Dans le dossier 00-contexte, on va créer trois fichiers Markdown.

Petite parenthèse sur Markdown : c’est un format de texte très simple, avec quelques symboles pour la mise en forme (gras, titre, liens). Vous pouvez apprendre le Markdown en 5 minutes avec mon guide. Au pire, vous écrivez du texte sans aucune mise en forme ou n’utilisez que des titres avec # et des listes avec -.

Son gros avantage, c’est qu’il est lisible partout. C’est du texte. On reste propriétaire de nos fichiers, et les modèles IA comprennent parfaitement ce format.

a-propos-de-moi.md

Ce fichier sert à donner le contexte humain, perso et professionnel. Qui vous êtes, ce que vous faites, vos sujets, vos objectifs, vos contraintes, vos rôles, vos domaines, etc.

L’idée n’est pas d’écrire une autobiographie complète. L’idée est d’éviter de répéter à chaque demande : “je suis indépendant”, “je suis expert en”, “mes clients sont”, etc. Pensez donc à tout ce qui sera utile à l’agent pour réussir les objectifs que vous lui donneraient.

Commencez simplement, et améliorez-le au fil du temps.

Pour donner des exemples tout au long de cet article, imaginons un personnage fictif :

# À propos de moi

Je suis Arthur, président de l'association "La Table Ronde".

Je gère une équipe de chercheurs sur le terrain (les "chevaliers"). 

Mon rôle est de suivre leurs avancées et de valider l'utilisation de notre budget annuel (financement de l'association).

Mes priorités quotidiennes :
1. Cartographier précisément les zones explorées pour éviter les doublons.
2. Suivre les indices concrets (sources historiques, pistes archéologiques).
3. Surveiller les dépenses logistiques (frais de déplacement, tavernes, équipement).

mon-style.md

Ce fichier décrit votre façon d’écrire et communiquer. Le ton, niveau de détail, structure, mots à éviter. Ajoutez aussi des exemples et contre-exemples pour aider l’agent à comprendre votre plume. Les exemples sont très puissant, mettez-en !

J’en profite pour glisser une astuce : utilisez votre agent pour vous aider à remplir ce type de fichiers. Vous pouvez lui demander de vous aider avec une suite de questions/réponses par exemple. Ou vous pouvez lui fournir des textes que vous avez rédigés. À vous de voir.

# Mon style

- **Ton :** Direct, pragmatique, professionnel mais accessible.
- **Structure :** Toujours utiliser des listes à puces et des tableaux pour les chiffres. Pas de longs paragraphes.
- **Niveau de détail :** Synthétique.
- **Formulations à éviter :** 
    - Supprimez toutes les formules de politesse excessives (pas de "noble roi", "Sire", "seigneur") 
    - Aucune expression vague ("on a cherché partout", "pas mal d'argent"). Je veux des faits précis.

regles.md

Ce fichier pose les règles de fonctionnement de l’agent. Ce qu’il doit faire, éviter, demander, où il doit écrire les résultats, comment nommer les fichiers. Et aussi comment fonctionne notre espace de travail.

# Règles de fonctionnement de l'agent

Tu dois respecter strictement les règles suivantes :

- **Limites de connaissances :** 
   - Si une information importante manque, pose une question plutôt que de supposer.
   - Dis explicitement quand tu n'es pas sûr.
- **Gestion du workspace :**
   - Ne modifie jamais les fichiers du dossier `00-contexte` sans me demander.
   - Mes projets en cours sont situés dans `01-projets`.
   - Mes templates sont dans `02-templates`.
   - Écris toutes les synthèses générées exclusivement dans le dossier `03-livrables`.
- **Traitement des données :** 
   - Ignore systématiquement les anecdotes personnelles, les histoires de taverne, les plaintes sur la météo ou la nourriture.
   - Ne conserve que : la zone géographique explorée, les indices concrets, et le montant total des dépenses.

Ajouter des instructions globales

Il faut savoir que les agents ne lisent pas automatiquement nos fichiers - son contexte exploserait sinon. Il faut soit directement les mentionner dans un prompt, soit que l’agent estime de lui-même qu’il doit lire le contenu de nouveaux fichiers pour réaliser son objectif.

Il y a quelques exceptions. Il est possible de créer des instructions globales. On peut les ajouter dans les paramètres de l’application, ou en créant un fichier spécial à la racine de notre workspace : AGENTS.md (pour la plupart) sinon CLAUDE.md (pour Claude).

C’est comme un brief permanent pour l’agent, il chargera ces instructions à chaque conversation. Et ça nous intéresse. On a au moins envie de lui indiquer de prendre en compte nos fichiers de contexte pour éviter de devoir lui rappeler à chaque fois.

Avant chaque tâche, commence par lire les fichiers du dossier `00-contexte`.

Je conseille d’utiliser les fichiers de type AGENTS.md/CLAUDE.md plutôt que les paramètres de l’application. Si demain vous changez d’outil, vos fichiers restent là. Vous n’avez pas tout caché dans les réglages d’un compte ou d’une app.

Autre chose à savoir, vous pouvez être granulaire. Une instruction globale à la racine du workspace, puis des instructions locales dans un dossier projet. On a des informations, règles, styles qui ont du sens uniquement pour un projet.

AGENTS.md
01-projets/
└── graal/
    └── AGENTS.md

Première mission

Ça y est, la base est prête. Vous pouvez commencez à utiliser un agent personnalisé avec votre contexte, dans votre projet.

Mettons-nous à la place d’Arthur. Que pourrait-il faire ? Il reçoit de nombreux rapports de quêtes de la part de ses chevaliers. Des rapports très longs, bourrés de détails inutiles, de plaintes, d’anecdotes de tavernes, etc.

• Rapport de Perceval et Karadoc
• Rapport de Lancelot

Il n’a pas de temps à perdre, il a déjà beaucoup de responsabilités. Il aimerait bien avoir des synthèses avec les informations essentielles pour prendre des décisions. Et ça tombe bien, dans son contexte, il a déjà indiqué son style et ses règles.

Il lui suffirait de mettre les fichiers texte contenant les rapport dans le dossier 01-projets/graal/rapports et de faire une simple demande à un agent :

Pour le projet Graal, je veux une synthèse des rapports des chevaliers.

Et ça suffit. On voit tout de suite la différence avec un chat. Ici, l’agent possède tout le contexte utile. Il peut décider d’aller chercher d’autres informations (les rapports). Puis il va réaliser la tâche demandée à l’origine : faire une synthèse. Le prompt est d’ailleurs assez court, car l’espace de travail a été préparé en amont.

• Synthèse générée par l’agent

C’est un cas d’usage simple, mais il permet de voir la puissance des agents. On pourrait lui demander de générer des slides sur Google Sheet pour faire une présentation des avancées. Ou de tenir à jour notre fichier Excel des dépenses.

Ce qu’il vous faut maintenant, c’est détecter quels sont tout vos process, ceux que vous répétez le plus et qui pourraient vous apporter rapidement de la valeur.

Les vérifications restantes

Une ia peut toujours se tromper, haluciner, mal interpréter une note, oublier une contrainte, etc. Vérifiez toujours le résultat. Puis, éventuellement, améliorez votre espace de travail.

Par exemple, si l’agent écrit toujours trop long, améliorez mon-style.md. S’il modifie des fichiers qu’il ne devrait pas toucher, précisez regles.md. S’il oublie une section dans chaque livrable, modifiez votre template.

C’est là que le workspace devient intéressant. Il s’améliore avec l’usage.

Pour aller plus loin

Nous voilà avec une bonne base de départ. Avec le temps, vous pourrez l’améliorer de nombreuses manières :

• en retravaillant le workspace, la structure,
• en ajoutant du contexte sur vous et vos projets,
• en connectant l’agent à d’autres outils et services (mails, drive, calendrier, slack, notion, …),
• en créant des SKILLS pour rendre réutilisable des process que vous faites régulièrement,
• en créant des tâches récurrentes,
• en creusant des concepts comme la mémoire, la gestion ducontexte, les tokens, etc.

Mais d’ici là, pratiquez, jouez avec votre nouvel espace de travail !

La réponse est oui, et j’en utilise un depuis bientôt deux ans maintenant. Il s’appelle mise-en-place, ou mise pour les intimes. Au départ, je l’ai adopté pour une raison très simple : j’en avais marre de chercher un nouveau version manager pour chaque écosystème.

nvm pour Node.js. pyenv pour Python. fvm pour Flutter. rustup pour Rust. chruby pour Ruby. Un autre pour je ne sais quel SDK qui arrive sur un projet. Vous avez la musique. Chaque outil est souvent très bien dans son coin, mais l’ensemble finit par créer une petite fatigue. Rien de dramatique, on va s’en remettre, mais le genre de friction qui revient souvent.

Installer. Mettre à jour. Changer de version. Expliquer à un collègue quoi installer. Retrouver où la version est déclarée. Se souvenir si cette commande s’applique globalement ou seulement dans le projet. La promesse de mise est assez agréable : apprendre une seule façon de faire, puis l’appliquer aux autres d’outils.

Un version manager généraliste

mise se place dans la famille des gestionnaires de versions généralistes, comme asdf ou vfox. L’idée n’est donc pas de gérer uniquement Node.js, Ruby ou Python, mais de fournir une interface commune pour tout un ensemble de langages, runtimes, SDK et outils de développement.

Dans un projet, je peux vouloir Python 3.12, Node.js 22, Flutter 3.32, Terraform, Bun, ou encore un outil CLI dont l’équipe a besoin. Plutôt que d’empiler les gestionnaires spécialisés, je peux demander à mise de s’en occuper. Derrière, il sait s’appuyer sur plusieurs sources et backends selon les outils. Honnêtement, au quotidien, je n’ai pas besoin d’y penser. Et c’est plutôt bon signe.

Ce n’est pas le seul outil capable de faire ça. J’avais déjà repéré asdf dans mon ancien article sur les version manager, et vfox existe aussi dans le même esprit. Pourquoi j’ai choisi mise ? Parce qu’il m’a semblé rapide, actif côté communauté, très fourni en outils supportés, et parce qu’il ne s’arrête pas au simple rôle de version manager. Je reviendrais dessus juste après.

Mais avant, commençons par le commencement. Installer mise. (Vérifiez tout de même le site officiel si la méthode a changé entre temps) :

curl https://mise.run | sh

Si je veux installer Node.js globalement (tout mon PC), la commande ressemble à ça :

mise use -g node@26

Si je veux installer Python pour un projet (un dossier et ses enfants) :

mise use python@3.13

À partir de là, quand j’entre dans le dossier du projet, python pointe vers la bonne version. Je tape python, pas mise python, pas pyenv exec python, pas une commande enveloppée avec un préfixe qui me sort du geste naturel. C’est un détail, mais je trouve que ça compte. Quand je lance flutter test, j’ai envie d’écrire flutter test, pas de me rappeler que sur ce projet précis je dois écrire fvm flutter test.

Le fichier mise.toml

Là où mise devient vraiment intéressant, c’est avec le fichier mise.toml.

Au début, on peut le voir comme un simple équivalent plus généraliste des fichiers .ruby-version, .node-version, .tool-versions, etc. On déclare les outils et les versions attendues par le projet, puis on versionne ce fichier avec le code. Comme ça, toute l’équipe partage la même configuration.

Un exemple très simple pourrait ressembler à ça :

[tools]
node = "26"
python = "3.13"

Ce n’est pas spectaculaire, mais c’est très pratique. Le projet dit explicitement “pour travailler ici, voici les outils et versions attendues”. Le nouveau collègue qui arrive, la machine fraîchement réinstallée, le runner de CI, le moi du futur qui aura tout oublié… tout le monde lit la même chose.

C’est la fin des discussions du style :

• Tu es sur quelle version de Node ?
• Attends, je croyais qu’on était passé en 26 ?
• Ah non, sur cette branche il faut encore la version 25.
• Pourquoi ça marche chez toi et pas chez moi ?

Bon, je m’emballe, cette dernière question ne disparaît jamais totalement malheureusement. Ce serait trop beau. Mais on passe tout de même d’un réglage individuel en un élément de projet versionnée.

Bien plus qu’un version manager

La surprise, pour moi, c’est que le fichier mise.toml ne s’arrête pas aux outils. On peut aussi y déclarer des variables d’environnement, et même des tâches. C’est là que mise a commencé à dépasser, chez moi, le rôle du “truc qui gère les versions” et où je me suis dis que j’allais le garder.

Les variables d’environnement, c’est le genre de chose qui finit souvent dans un .env, parfois un fichier différent par outils, ou pire dans une note. Avec mise, on peut les ajouter dans la configuration du projet. Pas les secrets, évidemment. Mais les valeurs non sensibles, les chemins, les réglages utiles au développement, oui.

Et puis il y a les tâches. On peut définir des commandes nommées, un peu comme on le ferait avec un Makefile ou des scripts maison. Sauf qu’elles vivent dans le même fichier que la déclaration des outils.

Par exemple :

[tasks.setup]
run = "mise install && npm install"

[tasks.test]
run = "npm test"

Je simplifie volontairement, mais l’idée est là. Sur un projet, il suffit de taper mise setup et cette commande prépare ce qu’il faut. Elle installe les outils attendus et prépare le terrain. C’est le genre de petite attention qui rend un projet plus accueillant. (et encore une fois, plus “future-proof” avec notre mémoire)

J’ai commencé à le faire sur tout mes nouveaux projets. Je crée un mise.toml, je le source, et petit à petit j’y mets les commandes que je rejoue souvent. Pas besoin de se demander si c’est make init, npm run setup, ./scripts/bootstrap.sh ou autre chose. Pour moi, de plus en plus, c’est mise run setup.

Même pour ce blog, j’ai une tâche new pour préparer un nouveau post. Créer le dossier, créer un fichier avec un template de post, mettre la date, puis l’ouvrir dans VS Code. Rien de révolutionnaire, mais j’aime beaucoup écrire de petits scripts pour éviter de répéter les mêmes opérations - je suis un flemmard.

Je vous ai parlé des alias ? Je peux faire encore plus court en tapant seulement setup ou new. Et ça marche pour tout, pas seulement pour les tâches - ce sont simplement des alias après tout.

[shell_alias]
new = "mise run new"

Attendez, ce n’est pas fini. On peut aller plus loin avec des hooks : des commandes qui se lanceront à chaque fois qu’on entre/sort du projet, avant ou après une installation, ou même faire du watch ! Quand je vous disais que cet outil allait les gouverner tous. Mon précieux, mon mise.

Ce qui se passe derrière

Sans rentrer dans un tutoriel complet, ça vaut le coup de comprendre grossièrement comment mise s’intègre au terminal.

Le principe de base est assez classique : mise installe les outils dans un de ses dossiers, puis modifie dynamiquement le contenu du PATH. Quand je suis dans un dossier avec un mise.toml, l’environnement actif change, et la commande node, python ou flutter pointe vers la version déclarée.

C’est aussi pour ça que l’expérience reste très rapide. En fait, elle est même inchangée. On ne lance pas un gros proxy à chaque commande. Le shell sait directement où chercher les exécutables.

Il existe aussi un mode avec des shims si on en a besoin, c’est-à-dire des petits exécutables intermédiaires qui redirigent vers la bonne version. Selon les environnements ou IDE, ça peut être utile. J’ai dû passer par les shims pour l’extension Flutter de VS Code par exemple.

Je trouve cette partie intéressante parce qu’elle répond à une inquiétude que j’avais avec certains version managers : est-ce que je vais ralentir mon terminal ? C’était par exemple le cas avec nvm qui est long à démarrer, même si on ne l’utilise pas.

Bref

Au départ, je cherchais surtout un version manager généraliste. Je voulais arrêter d’accumuler un outil par langage. mise m’a donné ça : une manière commune d’installer, mettre à jour et changer de version. Et il est même allé là où je ne l’attendais pas avec les variables d’environnement et les tâches.

Aujourd’hui, je n’installe quasiment plus de langage ou de SDK à la main. Flutter ? Via mise. Python ? Via mise. Les outils autour d’Ansible dont je parlais récemment ? Via mise aussi.

Quand je démarre un projet, mon premier réflexe est de créer et compléter le mise.toml au fur et à mesure pour réduire les frictions. À force, ça devient moins un outil de gestion de versions qu’un petit chef d’orchestre pour mon environnement de développement.