Rechercher une leçon

173 leçons.

Chat, Cowork, Claude Code, trois outils, trois usagesChoisir la bonne porte d'entrée
Le chat répond, Cowork agit sur vos fichiers et Claude Code travaille sur du code : trois interfaces pour la même famille de modèles. Elles se distinguent par les outils que le modèle peut appeler et le contexte que vous lui fournissez, le travail de code allant vers Claude Code, le travail de connaissance vers Cowork.
Cowork, le mode par défaut pour un non techniqueChoisir la bonne porte d'entrée
Sur un compte qui n'a pas encore basculé vers la nouvelle expérience unifiée, Cowork agit directement sur les dossiers connectés et se découpe en petites passes plutôt qu'en un seul traitement géant; une fois basculé, ces mêmes gestes se font depuis la même conversation que le chat, avec un seul réglage d'approbation pour toute la conversation.
Régler l'ordinateur pour les sessions longuesChoisir la bonne porte d'entrée
Pour une tâche longue qui touche vos fichiers locaux, empêchez la mise en veille automatique de votre ordinateur et activez les notifications de l'application Claude. Claude Desktop doit alors rester ouverte, éveillée et connectée : si l'ordinateur s'endort, la tâche s'interrompt sans autre signal que le résultat manquant. Une tâche planifiée entièrement distante n'en a pas besoin.
Chat et Cowork ne font plus qu'une conversationChoisir la bonne porte d'entrée
Depuis la fusion du chat et de Cowork en une seule conversation, vous ne choisissez plus un outil avant d'écrire: Claude décide lui-même de répondre ou d'agir, et un seul réglage, Auto ou Manual (Manuel), remplace les anciens choix propres à chaque outil.
Comprendre le jeton et la fenêtre de contexteNe jamais tomber en panne de jetons
Claude lit des jetons, de petits fragments de texte, et la fenêtre de contexte est l'espace où tient tout ce qu'il voit en même temps : votre message, l'historique et les fichiers joints. Rouvrir une session ancienne recharge tout cet historique à chaque question, même courte, ce qui la rend plus lente et plus gourmande en quota.
Que faire quand la limite est atteinteNe jamais tomber en panne de jetons
Quand la limite est atteinte, l'envoi de nouveaux messages devient impossible jusqu'à ce qu'un évènement le débloque : attendre la remise à zéro du compteur, changer de formule ou acheter des crédits d'usage. Seule l'attente est gratuite, et la seule préparation utile est de savoir à l'avance qui contacter dans votre organisation.
Les bons réflexes pour économiserNe jamais tomber en panne de jetons
Pour économiser le quota, si la tâche n'a pas de rapport avec la précédente, ouvrez une nouvelle session rattachée au même projet plutôt que de prolonger une session d'un jour sur l'autre. Une session prolongée relit tout son historique à chaque question, alors que la nouvelle repart d'une base courte et retrouve les fichiers et l'instruction du projet.
Le projet, contenant du contexteGarder le fil d'un jour à l'autre
Un projet regroupe en un seul endroit permanent des fichiers de référence, une instruction écrite une seule fois et les sessions ouvertes à l'intérieur. Une conversation ouverte hors de tout projet ne garde aucun de ces trois éléments au-delà de sa fenêtre : la fermer revient à la vider. Une tâche qui revient avec les mêmes fichiers relève d'un projet.
Activer la mémoire, distincte de l'historiqueGarder le fil d'un jour à l'autre
La mémoire n'est pas l'historique : l'historique conserve chaque conversation telle qu'elle s'est déroulée, la mémoire retient seulement une sélection et la réutilise dans une session suivante. Elle est active par défaut sur les comptes personnels et inactive sur les comptes d'organisation, où il faut d'abord vérifier qu'elle est allumée.
Reprendre une session sans tout reperdreGarder le fil d'un jour à l'autre
Ouvrez une session neuve dans le même projet et demandez-lui explicitement de reprendre le fil. Les fichiers et l'instruction du projet restent en place, mais le détail de la conversation précédente ne suit pas : ce qui n'est écrit nulle part dans le projet ne reviendra pas, sauf si vous le redonnez.
Ce que Cowork voit et ce qu'il ne voit pasFaire agir Claude sur ses vrais dossiers
Cowork ne modifie de fichiers que dans les dossiers que vous avez connectés, mais il voit davantage que des fichiers : avec votre autorisation, il prend des captures de votre écran, et depuis le panneau latéral de Chrome il voit la page affichée. Fermez ou masquez ce qui n'a rien à voir avec la tâche.
Travailler sur une copie, jamais sur l'originalFaire agir Claude sur ses vrais dossiers
Travaillez sur une copie, car Claude modifie le fichier lui-même, à l'endroit où il se trouve, sans créer de copie de secours. Une réécriture ne demande pas la confirmation d'une suppression : l'erreur silencieuse devient plus probable. Dupliquez donc tout document qui doit rester une référence avant de le confier à Claude.
Compétences et plugins, la spécialisation à la demandeFaire agir Claude sur ses vrais dossiers
Une compétence est une spécialisation que Claude charge pour un domaine précis ou une façon de faire répétée, écrite une seule fois. Un plugin regroupe plusieurs compétences dans un seul paquet installable. Lisez la description avant d'activer l'un ou l'autre : c'est le seul endroit où son auteur dit ce qu'il fait.
Les connecteurs, un lien direct avec un logicielFaire agir Claude sur ses vrais dossiers
Un connecteur est un lien authentifié entre Claude et un service externe, une messagerie, un agenda, un espace de fichiers. Son autorisation engage au-delà de la conversation en cours, jusque dans vos tâches planifiées, et la liste des connecteurs proposés dépend, sur un compte d'organisation, d'un administrateur.
Ce qui exige une prudence particulière avant de faire traiter un documentDonnées personnelles, la vigilance obligatoire
L'identité, la santé, la situation personnelle et les secrets d'accès exigent une prudence particulière avant de faire traiter un document. Remplacer un nom par un numéro ne suffit pas tant qu'une table de correspondance existe quelque part. Un secret qui transite par une conversation, même brièvement, doit être considéré comme déjà compromis.
Ce que le compte d'organisation garantit, et ce qu'il ne garantit pasDonnées personnelles, la vigilance obligatoire
Sur un compte d'organisation, le contenu des conversations n'entraîne pas les modèles, sauf si l'organisation adhère elle-même au programme de partenariat de développement. Cette garantie ne répond qu'à la question de l'entraînement : l'organisation reste seule responsable du traitement, et un compte individuel suit d'autres conditions.
Traiter un premier cas réel de bout en boutPasser à la pratique et se repérer seul
Traitez un cas réel dans votre projet, en petites passes, puis ne tenez le livrable pour acquis qu'après l'avoir relu vous-même. L'annonce de fin de tâche et la mise en page propre ne prouvent rien : comptez les éléments, comparez-les à la source, retrouvez chaque valeur chiffrée dans le document d'origine.
Le glossaire de référencePasser à la pratique et se repérer seul
Ce glossaire réunit les mots qui reviennent sans cesse dans le parcours : agent, jeton, fenêtre de contexte, projet, compétence, plugin, connecteur, tâche planifiée, sous-traitant. Ils suffisent pour formuler une demande et décrire un blocage à quelqu'un. Gardez la fiche ouverte durant votre première semaine plutôt que de la mémoriser d'un coup.
Prédire le mot suivant, rien de plusCe qu'est un modèle de langue, sans jargon
Un modèle de langue ne fait qu'une chose : prédire le fragment de texte le plus probable à la suite de ce qu'il a déjà lu, et une réponse inventée sort du même calcul qu'une réponse exacte, sans qu'aucun signal interne ne les distingue l'une de l'autre.
Le jeton et la fenêtre, ce que le modèle voit réellementCe qu'est un modèle de langue, sans jargon
Le modèle voit des jetons empilés dans une fenêtre au plafond fixe, pas des mots entiers pris un par un, et une conversation qui approche ce plafond change de contenu avant même d'atteindre son coût maximal, puisque Claude résume alors les échanges les plus anciens.
Le mythe du réglage magiqueCe qu'est un modèle de langue, sans jargon
Deux réponses différentes à la même question ne signalent pas une panne : elles viennent d'un réglage interne, la température, qui ajuste la prise de risque dans le choix du mot suivant, et ce réglage ne corrige pas une demande mal posée, la demande elle-même le peut.
Une famille de modèles, un choix de vitesse contre profondeurCe qu'est un modèle de langue, sans jargon
Les modèles Claude, Fable, Opus, Sonnet et Haiku, sortent du même entraînement de base et se distinguent surtout par un compromis : la vitesse de la réponse contre la profondeur du raisonnement. Les plus rapides conviennent aux tâches courtes et répétées, les plus profonds aux dossiers à recouper, et le tarif suit le même axe.
Le sens sans dictionnaire, et pourquoi l'ordre compteCe qu'est un modèle de langue, sans jargon
Claude n'ouvre aucun dictionnaire, il associe chaque mot à des mots de sens proche et évalue chacun par rapport à tous les autres au moment de répondre, ce qui fait que la place d'une consigne dans le message change son poids réel dans la réponse.
Comment Claude a appris à répondre, et jusqu'à quandCe qu'est un modèle de langue, sans jargon
Claude traverse trois étapes d'entraînement avant toute conversation, une lecture large du monde, un ajustement en assistant utile, puis une autocorrection fondée sur des principes écrits, et la connaissance qui en résulte s'arrête à une date qui varie selon le modèle utilisé.
Les trois blocs d'une demandeÉcrire une demande qui marche
Une demande qui marche sépare trois blocs : ce que Claude doit être, ce qui a déjà été dit, et ce qu'on demande maintenant. Pour un comportement au-delà du minimum, demandez-le explicitement plutôt que de compter sur Claude pour le deviner. Avec un projet, le rôle se pose une fois dans ses instructions.
Être clair, direct, et donner le pourquoiÉcrire une demande qui marche
Claude se comporte comme un nouvel employé brillant qui ne connaît ni vos habitudes ni votre secteur : soyez précis et donnez le pourquoi, pas seulement la tâche. Nommez aussi qui lira ou entendra la réponse. Pour vérifier la clarté, montrez votre demande à un collègue sans contexte : s'il est perdu, Claude le sera aussi.
Attribuer un rôleÉcrire une demande qui marche
Une seule phrase de rôle, placée en tête d'une conversation ou d'un projet, oriente le ton, le vocabulaire et les priorités de Claude, plus efficacement qu'une longue liste de consignes éparpillées. Un bon rôle nomme une spécialité, un public et au moins une contrainte de forme, plutôt qu'un titre trop général.
Séparer les données des instructionsÉcrire une demande qui marche
Mélanger instructions et données dans un seul bloc oblige Claude à deviner où s'arrête la consigne : une phrase du texte collé peut passer pour une instruction. Entourez chaque type de contenu d'une frontière explicite, balise, titre Markdown ou ligne de marquage, et vérifiez que chaque balise ouverte trouve sa fermeture.
Formater la sortie et parler à la place de ClaudeÉcrire une demande qui marche
Précisez le format en disant ce que la réponse doit contenir plutôt que ce qu'elle ne doit pas contenir. Pour qu'elle commence par le résultat, nommez le premier élément attendu : cela remplace l'ancien préremplissage, qui consistait à écrire soi-même le début de la réponse de Claude et ne fonctionne plus sur les modèles récents.
Faire raisonner Claude avant de conclureÉcrire une demande qui marche
Demander à Claude d'écrire son raisonnement avant sa conclusion améliore la précision sur les questions à plusieurs étapes, que ce raisonnement soit invité par une phrase dans la demande ou déjà actif comme un mode à part, et les deux versions consomment des jetons supplémentaires.
Montrer la cible plutôt que l'interdireÉcrire une demande qui marche
Trois à cinq exemples entrée vers sortie ancrent un format ou un ton mieux qu'une longue liste de règles, et une instruction positive donne une cible claire là où une instruction uniquement négative laisse Claude deviner par quoi la remplacer.
Composer une demande complexe sans inventerÉcrire une demande qui marche
Une demande complexe se compose pièce par pièce, qui doit être Claude, le contexte, la donnée à traiter, ce qui est demandé, un exemple, le format attendu, puis une dernière ligne qui autorise Claude à dire je ne sais pas plutôt que d'inventer une réponse.
Faire durer et réutiliser une demande qui marcheÉcrire une demande qui marche
Gardez une demande qui marche et ajustez-la par petites touches, une seule partie à la fois, plutôt que de la réécrire de zéro. Placez un long document tout en haut de la demande, avant la question. Figez enfin la demande en modèle réutilisable, où seul ce qui change d'une tâche à l'autre est remplacé.
Un vert ne prouve rien tant qu'il n'a pas été prouvé lui-mêmeVérifier ce qu'il rend
Un contrôle qui n'a jamais été mis en défaut par un cas qu'il doit réellement trouver n'a rien prouvé, au sens strict où prouver exige qu'une commande précise ait tourné et que sa sortie ait été lue : un détecteur cassé rend zéro problème, et cela se lit exactement comme un succès.
Testez le vérificateur avant de croire son verdictVérifier ce qu'il rend
Un contrôle qui rend un chiffre plausible n'en rend pas forcément un juste, et l'écart ne s'annonce presque jamais. Testez donc le script avant de croire son verdict : donnez-lui une entrée fabriquée qu'il doit signaler et une entrée propre qu'il ne doit pas signaler, couvrant les particularités de votre terrain.
Le remède contre l'invention peut inventer lui aussiVérifier ce qu'il rend
Un dispositif de vérification est un livrable comme un autre, produit par le même type de mécanisme que ce qu'il contrôle. Relancer le même contrôle ne le rend pas indépendant, car un bug déterministe se répète à l'identique : seule une méthode réellement différente, qui peut échouer autrement, a valeur de preuve.
Où vous regardez détermine ce que vous trouvezVérifier ce qu'il rend
Une vérification pointée sur le dernier changement dit où l'on a regardé, jamais où sont réellement les défauts : sans avoir examiné le reste avec le même soin, aucune conclusion sur la dangerosité comparée du code récent et du code ancien ne tient.
Une vérification très rigoureuse peut quand même ne rien voirVérifier ce qu'il rend
Une vérification, même très disciplinée, ne juge que ce qui existe déjà : un écran jamais construit ou une fonction jamais écrite n'apparaissent nulle part dans son périmètre. Ce qui comble ce trou est une question différente, posée hors du code relu, comme un parcours d'utilisateur complet confié à un usage réel.
Prouvé, ou simplement pas encore réfutéVérifier ce qu'il rend
Prouvé signifie que vous avez exécuté une commande précise et que vous pouvez citer sa sortie. Pas encore réfuté signifie seulement que rien n'a attrapé de problème jusqu'à présent, une affirmation bien plus faible. Un aperçu vert ou une absence d'erreur en console ne prouvent donc pas qu'aucun défaut n'existe.
Un contrôle de forme ne voit jamais une valeur fausseVérifier ce qu'il rend
Un contrôle automatisé vérifie presque toujours la forme et très rarement la vérité : un fichier valide, un encodage correct ou un mot clé présent peuvent coexister avec un chiffre faux. Valider une capture de la page qui génère le document ne prouve pas non plus ce que la personne ouvre réellement.
Rouvrir chaque source avant de la croireVérifier ce qu'il rend
Un agent de recherche rapporte ce qu'un index montre, pas ce qu'une page en direct contient aujourd'hui, et présente un lien mort avec la même assurance qu'un lien vivant : toute source destinée à soutenir une conclusion se rouvre avant d'être citée.
Compter toute la population, et nommer la mesure pour ce qu'elle capteVérifier ce qu'il rend
Mesurer sur les quelques cas remarqués par hasard plutôt que sur toute la population rend une conclusion pleine d'assurance et pourtant fausse, et cette même conclusion reste fausse si le nom qu'on donne au résultat dit autre chose que ce que l'instrument a réellement capté.
Trois agents d'accord, une seule sourceVérifier ce qu'il rend
Des agents qui rendent la même conclusion en citant la même page ne confirment rien : l'équipe tient une seule source, citée plusieurs fois. Un accord vaut ce que valent les sources distinctes qui le portent, et une adresse différente ou une copie sous un autre domaine n'est pas encore une source indépendante.
Ce qu'un contrôle exempte disparaît de sa sortieVérifier ce qu'il rend
Ce qu'un contrôle exempte disparaît de sa sortie : le périmètre est décidé une fois, puis plus personne ne le relit. Un verdict conforme porte sur le dossier moins la partie exemptée, qui peut grossir sans bruit. Donnez à cette partie son propre seuil, qui pèse sur le verdict ; afficher son poids ne suffit pas.
Enchaîner les promptsTechniques qui changent le résultat
Enchaîner consiste à découper une tâche complexe en plusieurs messages courts, où la réponse de l'un sert de matière première au suivant. Chaque maillon devient alors un point où l'on peut lire, corriger ou arrêter la chaîne avant de continuer. Le schéma le plus simple enchaîne brouillon, relecture, correction.
Donner des mains à ClaudeTechniques qui changent le résultat
Claude agit au-delà du texte en passant par un outil, une fonction décrite par un nom, une explication et la forme de ses arguments. Il choisit de l'appeler et propose des arguments, mais l'exécution revient toujours à autre chose que lui, votre application ou certains serveurs d'Anthropic. Plus la description est précise, plus les arguments sont justes.
Composer un system prompt à partir de plusieurs sourcesTechniques qui changent le résultat
Reprenez une règle trouvée ailleurs, mais réécrivez-la avec vos propres mots pour votre situation au lieu de la copier telle quelle. En cas de conflit avec une règle déjà en place, la priorité revient à celle du propriétaire du system prompt. Vérifiez ensuite que la règle reformulée déclenche encore le comportement attendu.
Citer les sources et ne pas tourner autour du potTechniques qui changent le résultat
Une citation utile tient dans un crochet en ligne juste après la phrase qu'elle prouve, une source par crochet, sans section à part en fin de message, et une réponse directe pose le fait au lieu de l'annoncer puis de se refermer sur une question de politesse.
Sorties structurées et garde-fousTechniques qui changent le résultat
Imposer un schéma exact à une sortie et vérifier cette sortie avant de l'utiliser sont deux moitiés du même réflexe, l'une force la forme en amont, l'autre la contrôle en aval, et les deux comptent davantage quand l'action qui suit ne se rattrape pas.
Vérifier un prompt comme on vérifie un résultatTechniques qui changent le résultat
On vérifie un prompt avec un eval, un jeu de cas de test fixes écrits à l'avance qui le note automatiquement, et non sur quelques exemples essayés par hasard. Un prompt amélioré en le demandant à Claude (meta-prompting) reste un brouillon et passe par le même jeu de cas. Retestez sur exactement le même jeu, avant et après.
Faire dire plusieurs fois, et se contredire soi-mêmeTechniques qui changent le résultat
Demander plusieurs réponses indépendantes et garder la majorité filtre le bruit d'une seule réponse, et demander à Claude de jouer l'avocat du diable contre sa propre réponse trouve des erreurs qu'une seule passe rate, à condition de toujours faire une synthèse finale pour trier les objections valides du bruit.
Le premortem : supposer que le plan a déjà échouéTechniques qui changent le résultat
Le premortem renverse la question. Au lieu de demander si le plan est bon, ce qui invite à chercher des raisons de répondre oui, vous posez qu'il a déjà échoué et vous demandez l'autopsie. Elle fait sortir les causes d'échec, qui restent des hypothèses à vérifier.
Le paysage des modèles, une même famille de prédicteursChoisir son modèle et son outil
Claude, GPT et Gemini reposent sur le même principe d'entraînement de base, que décrit ainsi Anthropic pour Claude : prédire le mot suivant. Les modèles à poids ouverts partagent cette architecture. Une technique de prompt apprise sur Claude fonctionne donc souvent presque telle quelle ailleurs, même si la fenêtre de contexte, le traitement des données et les outils changent.
Router par tâche, pas par marqueChoisir son modèle et son outil
On choisit un modèle d'après ce que la tâche exige : capacité, vitesse, coût et effort de réglage, non l'habitude. Deux questions situent la tâche, routinière ou nouvelle, enjeu faible ou élevé. Mieux régler le prompt, avec un rôle plus précis ou un contexte mieux posé, change souvent plus le résultat qu'un changement de modèle.
Composer un system prompt entre plusieurs fournisseursChoisir son modèle et son outil
Quand un prompt doit fonctionner sur plusieurs fournisseurs, on relève la règle la plus forte de chacun, on les fusionne sans contradiction, et les règles écrites par le propriétaire du prompt priment en général sur les valeurs par défaut d'un fournisseur, sauf quand elles entreraient en conflit avec les limites de sécurité que ce fournisseur pose lui-même.
Modèle local, sur mesure, ou simplement un meilleur promptChoisir son modèle et son outil
Pour une petite structure, dans l'immense majorité des cas, un prompt mieux écrit règle le problème plus vite. Un modèle à poids ouverts local n'a aucun coût par appel et ne sort aucune donnée, mais demande du matériel. Un modèle sur mesure coûte cher à construire et ne se justifie qu'à très grand volume ou pour un format fixe.
Low, medium, high, xhigh, max : choisir votre niveau d'effortChoisir son modèle et son outil
Partez du niveau marqué Default, montez d'un cran si la réponse vous paraît superficielle, descendez d'un cran si elle tarde sur une question simple. Le niveau d'effort règle le travail que Claude fournit avant de répondre : plus il est élevé, plus la réponse est approfondie, mais plus elle tarde et plus elle entame votre forfait.
Ouvrir Cowork et installer son premier espace de travailCowork, le collègue numérique
Cowork est l'agent de bureau d'Anthropic : il exige un plan payant et, pour toucher vos fichiers locaux, l'application Claude Desktop ouverte et connectée. Son espace de travail est un projet, qui regroupe des dossiers attachés, des instructions écrites une fois pour toutes et une mémoire qui lui appartient.
Ce que Cowork peut toucher, et ce qu'il ne doit jamais toucherCowork, le collègue numérique
L'accès de Cowork se découpe en trois plans distincts, les dossiers connectés, l'usage direct de vos applications et de votre écran, et un réseau isolé qui bloque par défaut les adresses internes ; dans les trois cas, une suppression définitive de fichier demande toujours votre confirmation.
Écrire un brief que Cowork peut exécuter, puis lire son plan avant qu'il ne démarreCowork, le collègue numérique
Un bon brief nomme un résultat, sa source, sa destination et l'espace de travail concerné, comme pour un collègue qui commence le jour même ; Cowork répond par un plan qu'il faut relire, parce qu'une hypothèse fausse repérée avant l'exécution se corrige sans coût, repérée après elle peut demander de défaire des écritures.
Choisir son niveau d'approbation, étape par étapeCowork, le collègue numérique
Sur un compte pas encore basculé vers la nouvelle expérience, les modes d'approbation décident qui contrôle une action de Cowork avant qu'elle s'exécute : vous (Manuel), Claude lui-même (Automatique), personne (Sans approbation). Passez en Manuel pour des éléments sensibles, un outil utilisé pour la première fois ou une erreur difficile à défaire.
Reconstruire un vrai tableur ou un rapport, pas un brouillon à corrigerCowork, le collègue numérique
Cowork renvoie un fichier fini, classeur aux formules qui recalculent vraiment, diaporama monté ou document mis en forme, pas un texte brut à remettre en page. Nommez la structure exacte attendue ou fournissez un modèle à copier. Un chiffre juste dans une cellule ne prouve pas la formule : cliquez sur la cellule et lisez-la.
Connecteurs : ce qu'ils lisent et écrivent vraimentCowork, le collègue numérique
Les capacités d'un connecteur se vérifient service par service : un connecteur ne se devine pas par ressemblance avec un autre outil du même éditeur. Le connecteur Gmail peut envoyer, répondre et transférer, avec une approbation demandée par défaut. Celui d'Outlook dépend de ce qu'un administrateur du compte a activé pour toute l'organisation.
Tâche planifiée ou Computer Use : dans quel ordre Cowork essaieCowork, le collègue numérique
Cowork essaie d'abord un connecteur, puis le navigateur de l'application de bureau, et en dernier recours seulement le contrôle direct de l'écran, toujours dans le même ordre. Une tâche planifiée déclenche cette même cascade à l'heure fixée, sans qu'un humain ne regarde l'écran au moment où elle s'exécute.
Cowork partout, qui peut faire quoi, et la piste laissée derrièreCowork, le collègue numérique
Cowork tourne sur le bureau, le web et le mobile, avec des sessions cloud qui continuent sans appareil allumé. L'accès dépend du plan : sur Enterprise, un administrateur doit l'activer. Sur Team et Enterprise, un export technique, limité par défaut aux métadonnées, n'existe que si un administrateur a configuré un collecteur ; il ne couvre pas une session locale.
Recette : trier son courrier sans jamais rien envoyer par erreurRecettes de métier
Une attaque par injection de prompt exige deux conditions à la fois, lire un contenu non fiable et pouvoir agir dessus : pour le courrier, la vraie barrière n'est plus l'incapacité d'envoyer, elle tient au réglage d'approbation en vigueur sur votre espace, à vérifier avant de faire confiance à votre seule relecture.
Recette : transformer des notes éparses en document ou tableur propreRecettes de métier
Cowork produit des documents structurés et des tableurs avec des formules qui fonctionnent à partir de notes brutes : sur un gros lot, demander explicitement un plan puis chaque section séparément donne un résultat plus fiable qu'une seule grande consigne lancée sur tout le dossier.
Recette : bâtir un texte en étapes séparées plutôt qu'en un seul jetRecettes de métier
Un texte important se découpe en étapes nommées, chacune avec un seul rôle, un plan approuvé d'abord, la rédaction ensuite, un alignement du ton comme étape à part entière, puis une relecture confiée à un rôle d'éditeur plutôt qu'une simple demande de réécriture.
Recette : organiser la mémoire commune de l'équipe sans la dupliquerRecettes de métier
La mémoire commune ne s'améliore pas en ajoutant des fichiers : elle s'améliore quand elle relie ce qui existe déjà et signale ce qui se répète. Faites comparer le contenu des documents plutôt que leurs titres, notez un lien vers le document apparenté plutôt que de fusionner, et tenez à jour un sommaire d'une page.
Recette : produire un même document en plusieurs langues sans qu'il divergeRecettes de métier
Désignez une version comme source et verrouillez-la, puis demandez chaque langue directement à partir d'elle, jamais d'une traduction. Comparez ensuite les chiffres clés et les termes techniques entre les versions. Notez dans chaque fichier la version de la source utilisée, pour qu'une correction ne soit pas oubliée dans une langue.
Recette : partager un document en un seul fichier qui s'ouvre partoutRecettes de métier
Produisez un seul fichier autonome, qui embarque tout ce qu'il affiche, texte, images et mise en forme, sans lien ni police extérieurs. Ouvrez-le ensuite hors ligne avant l'envoi : une image manquante ou une mise en forme cassée révèle une dépendance. Le format ne garantit rien à lui seul.
Claude Docs : un document que votre équipe édite avec ClaudeRecettes de métier
Claude Docs sert à écrire des documents vivants avec Claude et votre équipe. Les personnes qui ont l'accès éditeur travaillent sur le document en même temps que vous, et chaque modification apparaît en temps réel, attribuée à son auteur. Pour une retouche précise, commentez un passage et mentionnez @Claude, qui répond dans le fil.
Claude Code et la boucle de l'agentFondamentaux et boucle d'agent
La boucle de l'agent est le cycle où Claude Code réfléchit à l'action à mener, appelle un outil réel, puis observe ce que l'outil a produit avant de décider la suite. Il ne renvoie pas une réponse unique : la boucle recommence autant de fois que nécessaire, jusqu'à l'objectif. Chaque réflexion et chaque observation s'affichent au fil de l'eau.
CLAUDE.md, la mémoire du projetFondamentaux et boucle d'agent
CLAUDE.md est un fichier texte posé à la racine d'un dépôt, que Claude Code lit automatiquement au début de chaque session ouverte sur ce dépôt. Ses règles sont lues comme du contexte, sans garantie stricte de conformité. Pour bloquer une action quoi que Claude décide, il faut un hook PreToolUse.
Les commandes slash essentiellesFondamentaux et boucle d'agent
Quelques commandes slash gèrent la mémoire du projet, remettent le contexte à zéro ou le résument, et inspectent ce qui est chargé dans la session, sans jamais toucher au code du dépôt. /clear efface tout, /compact garde un résumé de ce qui vient d'être fait, utile en plein milieu d'une tâche longue.
Permissions et mode planFondamentaux et boucle d'agent
Le mode de permission décide quelles actions Claude Code exécute sans rien demander : depuis septembre 2026, une session interactive de terminal ou de VS Code sans mode configuré démarre en mode auto, sur tous les forfaits, et non plus en mode default, et le mode auto agit largement sous la surveillance en arrière-plan d'un second modèle.
Interrompre et rediriger en cours de tâcheFondamentaux et boucle d'agent
Échap interrompt le tour en cours, réflexion ou appel d'outil, sans perdre le contexte accumulé ; tapez ensuite la correction pour repartir sur la même base. Ctrl+C dépend de ce qui tourne à cet instant et, pressé une seconde fois quand rien ne tourne, termine la session Claude Code elle-même.
Pointer vers les fichiers avec @Fondamentaux et boucle d'agent
Le symbole arobase ouvre un menu qui pointe vers un fichier ou un dossier réel du disque, se filtre au fur et à mesure de la frappe, et distingue nettement l'instant où un chemin est inséré dans le message de l'instant où ce message part.
Exécuter des commandes shellFondamentaux et boucle d'agent
L'outil Bash exécute une vraie commande shell sur votre poste, pas une simulation, puis Claude Code lit la sortie standard et la sortie d'erreur pour poursuivre à partir de ce qui a réellement été produit. Une invite de permission s'affiche avant chaque commande nouvelle, sauf pour un jeu intégré de commandes en lecture seule.
Lire et approuver un diffFondamentaux et boucle d'agent
Un diff se lit ligne par ligne avant d'être approuvé : il marque en moins ce qui disparaît du fichier et en plus ce qui s'ajoute, et une modification chirurgicale se reconnaît à la brièveté de ces deux blocs. L'approbation se fait par un menu à options nommées, pas par une frappe libre.
La liste de tâches et la ligne de statutFondamentaux et boucle d'agent
Sur les modèles les plus récents, la liste de tâches reste vide par défaut : Claude gère le travail en plusieurs étapes sans l'exposer. Une ligne de statut configurée par un script affiche en direct le modèle actif, la fenêtre de contexte et le coût de la session.
La carte d'une installation structuréeUne installation structurée
Une installation Claude Code qui tient dans la durée se lit comme une carte de sept éléments, le moteur, la constitution CLAUDE.md, la mémoire de fichiers, le transport git, les hooks, les skills et le battement de coeur planifié, plutôt que comme un empilement de réglages sans plan.
Installer, se connecter et premier lancementUne installation structurée
Claude Code s'installe par cinq commandes, mais seules les deux natives (curl, irm) se mettent à jour toutes seules. Connectez-vous par votre abonnement : une clé API déjà présente dans l'environnement n'est pas utilisée en silence, et Claude Code vous demande de l'approuver. Lancez ensuite claude doctor, qui ne propose de correction qu'après son rapport.
CLAUDE.md global, une constitutionUne installation structurée
Le CLAUDE.md global cible désormais une longueur en lignes plutôt qu'en kilo-octets, et il ne prend pas le pas sur les autres CLAUDE.md par écrasement : les quatre échelles, gérée, utilisateur, projet, locale, se concatènent dans le contexte du plus large au plus spécifique.
Brancher la mémoire de fichiers sur gitUne installation structurée
Un dossier de mémoire versionné par git, avec un remote privé et une règle de fusion qui conserve les deux contenus plutôt que de forcer, reste une technique à construire soi-même, distincte de la mémoire automatique native qui, elle, ne quitte jamais la machine locale.
Hooks et battement de coeurUne installation structurée
Les événements du cycle de vie déclenchent des hooks selon trois cadences distinctes, SessionStart et SessionEnd forment la paire naturelle pour automatiser le protocole mémoire, et la consolidation nocturne reste une tâche planifiée du système d'exploitation à construire soi-même, pas un mécanisme Claude Code documenté sous ce nom.
Curer ses skills et boucler la mise en placeUne installation structurée
Une skill s'installe une par une contre un besoin déjà rencontré, jamais en lot, et boucler l'installation consiste à prouver chacun des sept éléments de la carte du module par un geste exécutable plutôt que de les supposer en place.
AGENTS.md : quand Claude Code le lit, et comment le constaterUne installation structurée
Au réglage par défaut, Claude Code lit AGENTS.md seulement quand aucun CLAUDE.md, CLAUDE.local.md compris, ne le remplace dans le dossier de travail ou au-dessus. Le panneau /config dit ce qui est demandé, pas ce qui a été lu : constatez-le au démarrage de la session, par la ligne affichée dans la conversation, ou avec la commande /memory.
Vos consignes vieillissent avec les modèlesUne installation structurée
Vos consignes vieillissent parce qu'une règle née d'un défaut d'un modèle reste en place quand le modèle change : elle n'est pas fausse, elle devient inutile, et le modèle la lit à chaque session. La commande /doctor prompt-audit relit vos fichiers de consignes et repère celles écrites pour d'anciens modèles.
Skills : apprendre un workflow à ClaudeÉtendre : compétences, MCP, sous-agents, hooks, plugins
Une skill apprend un workflow à Claude en réunissant un mode opératoire complet dans un seul fichier SKILL.md. Claude la déclenche de deux manières : par une commande slash portant le nom du dossier, ou automatiquement quand sa description recoupe la demande. Une fois chargée, son texte s'ajoute au tour comme des instructions supplémentaires.
Créer une skill qui devient aussi une commandeÉtendre : compétences, MCP, sous-agents, hooks, plugins
Une commande personnalisée et une skill sont désormais le même mécanisme : un fichier .claude/commands/nom.md et un dossier .claude/skills/nom/SKILL.md produisent tous deux la commande /nom avec le même comportement, et pour une skill personnelle ou de projet, c'est le nom du dossier, pas le champ name du frontmatter, qui devient le nom de la commande.
Découvrir, curer et empiler des skillsÉtendre : compétences, MCP, sous-agents, hooks, plugins
Cherchez d'abord dans les deux bibliothèques publiques maintenues par Anthropic, claude-plugins-official et claude-community, avant d'écrire une skill. Plusieurs skills peuvent se charger ensemble sur une même tâche, mais chacune ajoute du texte au contexte de chaque session : retirez celle dont la description ne répond plus à un besoin récurrent.
MCP : le protocole de connexionÉtendre : compétences, MCP, sous-agents, hooks, plugins
MCP est un standard ouvert qui décrit comment Claude Code se connecte à des outils et à des données extérieurs. Un serveur MCP expose trois primitives distinctes : des outils que Claude appelle avec des arguments, des ressources qu'il lit, et des invites que seul l'utilisateur déclenche. Elles ne se substituent pas l'une à l'autre.
Connecter un serveur MCP et ce qui a changéÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un serveur MCP distant se connecte en une commande, claude mcp add, et Claude Code détecte lui-même si une authentification est nécessaire. claude mcp list affiche l'état réel de chaque serveur déclaré. Indépendamment de Claude Code, la spécification MCP a changé de cœur : un cœur sans état remplace le cœur avec état.
Construire son propre serveur MCPÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un serveur MCP maison est un programme ordinaire que Claude Code lance lui-même comme processus enfant, par le transport stdio. Le schéma JSON déclare ce que l'outil attend, mais la validation reste due par le serveur, et c'est la description qui décide si Claude choisit cet outil.
Sous-agents : déléguer dans un contexte isoléÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un sous-agent exécute une tâche dans sa propre fenêtre de contexte, séparée de la conversation principale. Quand il termine, seule sa conclusion revient dans le fil que vous suivez : les fichiers lus, les journaux parcourus et les impasses explorées restent dans son contexte à lui. Une bonne délégation donne un objectif complet et un périmètre d'écriture nommé.
Hooks : automatiser le cycle de vieÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un hook est une action que le harnais exécute lui-même quand un événement précis du cycle de vie survient. Une consigne écrite en mémoire reste une préférence que le modèle peut oublier ; un hook déclaré une seule fois s'exécute à chaque occurrence, indépendamment de ce que le modèle retient à cet instant.
Les événements de hook, du déclenchement au messageÉtendre : compétences, MCP, sous-agents, hooks, plugins
PreToolUse s'exécute avant l'outil et peut empêcher l'appel ; PostToolUse s'exécute après et ne peut que réagir, y compris en remplaçant le résultat de l'outil. Un hook communique sa décision par un objet JSON aux champs précis et par son code de sortie, jamais par une phrase écrite sur la sortie standard.
Plugins : regrouper skills, hooks, MCP et agentsÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un plugin regroupe des skills, des hooks, des serveurs MCP, des commandes et des sous-agents dans un seul répertoire versionné, installable et partageable en une seule fois. Son manifeste plugin.json vit seul dans .claude-plugin/ ; l'erreur la plus fréquente est d'y placer skills/, commands/, agents/ ou hooks/ au lieu de la racine du plugin.
settings.json en profondeurÉtendre : compétences, MCP, sous-agents, hooks, plugins
Sur une clé simple présente à plusieurs niveaux, le niveau le plus prioritaire l'emporte entièrement, tandis que la plupart des listes, dont permissions.allow et permissions.deny, se fusionnent entre niveaux. Le bloc env suit les mêmes niveaux que le reste du fichier, et une variable du shell n'est pas un niveau de cette pile.
Le routage des skills échoue en silenceÉtendre : compétences, MCP, sous-agents, hooks, plugins
Claude décide d'invoquer une skill en comparant le vocabulaire de la demande au seul champ description de cette skill, et un décalage de langue ou de jargon entre les deux fait échouer l'invocation automatique sans aucun signal visible dans la réponse.
Déboguer et corriger un bugGestes courants
Une commande de reproduction précise et une trace de pile complète orientent le diagnostic vers la cause réelle d'un bug, et la correction ne se déclare close qu'après qu'un test de régression reproduisant le cas fautif a été exécuté et sa sortie lue.
Construire et refactorer avec les tests d'abordGestes courants
Demandez les tests avant l'implémentation, puis lancez le lanceur de tests pour constater qu'ils échouent réellement : le rouge prouve que le test peut échouer, le vert que l'implémentation le satisfait. Claude reproduit le style des tests déjà présents dans le dépôt, puis le refactor avance une préoccupation à la fois.
Revoir du code et piloter git en langage naturelGestes courants
/code-review lance une revue de code locale avec des niveaux d'effort de low à max, et ultra n'en fait pas partie : c'est un dispositif distinct, une revue multi-agents dans le cloud, facturée séparément. Git se pilote ensuite en langage courant, avec le même filet de permissions que les commandes tapées à la main.
Prendre en main, documenter et migrer une base de codeGestes courants
Sur un dépôt inconnu, commencez par demander une vue d'ensemble avant toute modification : elle oriente les questions suivantes. La commande /init lit réellement le contenu du dépôt pour écrire un premier CLAUDE.md, un premier jet à relire et à couper, et la migration ou la documentation se conclut par la relecture du diff final.
Automatiser une tâche répétitive et écrire un script jetableGestes courants
Automatiser un geste répété commence par séparer ce qui reste fixe de ce qui varie à chaque fois, se décrit par son entrée, sa sortie et l'environnement où il doit tourner, et se vérifie par un essai à blanc avant toute étape qui supprime, déplace ou écrase quoi que ce soit.
Les gestes rapides du terminalGestes courants
Une poignée de gestes courts couvre l'essentiel d'une session au quotidien : reprendre une session précise, revenir à un point de contrôle antérieur, lancer une commande shell sans quitter la conversation, et demander un raisonnement plus profond pour un seul tour sans changer le réglage de toute la session.
Mode headless, styles de sortie et tâches de fondGestes courants
Le mode headless exécute Claude Code sans interface interactive avec -p, --output-format détermine si la sortie reste du texte ou devient un objet JSON exploitable par un script, avec le coût total inclus, et run_in_background laisse une commande longue continuer sans bloquer la conversation.
Paralléliser : worktrees, modèle et mode rapideGestes courants
Un git worktree ouvre un second checkout du dépôt, sur sa propre branche, ce qui permet à des sessions Claude Code de travailler en parallèle sans s'écraser. La commande claude --worktree le crée automatiquement. Dans chaque worktree, le modèle se choisit sur la difficulté, et le mode rapide sur le coût.
Pièges d'écriture : fichiers, edits parallèles et livrables perdusGestes courants
Un rapport de succès écrit par un sous-agent ne prouve rien sur l'état réel des fichiers, puisqu'il démarre dans un contexte isolé sans accès à ce que l'agent principal a déjà lu ou écrit, et la seule preuve fiable reste un diff vérifié après coup, pas le texte du rapport.
Boucles, contexte pollué et redémarrageQuand ça déraille
Le signal d'une boucle est la répétition du même message d'échec, un contexte saturé se traite par une compaction ciblée ou par un effacement complet, et repartir avec un résumé écrit à la main des décisions déjà prises vaut mieux que d'insister dans une conversation dégradée.
Annuler et récupérer une modificationQuand ça déraille
Pour annuler la dernière modification de Claude Code dans la session en cours, ouvrez le menu de points de reprise avec /rewind plutôt que de passer d'abord par Git. Git reste l'outil pour ce que ces points ignorent : les modifications faites par une commande bash, les éditions d'un sous-agent en arrière-plan et les fichiers liés.
Erreurs d'API et limite de débitQuand ça déraille
Une erreur d'API porte un code de statut qui distingue des causes très différentes : une requête mal formée doit être corrigée avant tout nouvel essai, alors qu'un plafond temporaire se résout en respectant Retry-After. Un plafond de dépense atteint ne porte pas cet en-tête, et attendre ne sert à rien : il faut relever le plafond.
Une commande bloquéeQuand ça déraille
Pour une commande shell figée, tapez Ctrl+C, qui tente d'interrompre l'opération ; sinon relancez avec claude --resume. N'ajoutez pas de préfixe timeout à la main, car l'outil Bash porte déjà un paramètre de délai que Claude choisit lui-même, et la plupart des commandes qui atteignent leur délai basculent en tâche de fond au lieu d'être arrêtées.
Plusieurs sessions meurent ensemble, soupçonnez la machineQuand ça déraille
Quand plusieurs sessions meurent au même instant sans aucune trace dans leurs propres journaux, la cause probable est le système d'exploitation qui tue des processus sous pression mémoire, et le journal système tranche plus vite qu'une chasse aux erreurs applicatives.
La demande peut reposer sur une fausse prémisseQuand ça déraille
Une demande de correction mêle un symptôme observé et une cause supposée : le symptôme peut être exact pendant que la cause est fausse. L'exécuter à la lettre ne répare alors rien. Mesurez l'état réel, énoncez l'écart dès le début de la réponse, puis corrigez la cause réelle.
Lire la fonction appelée, prouver le coupableQuand ça déraille
Un correctif dont le test unitaire passe au vert peut être annulé, dans le même tour d'exécution, par la fonction appelée juste après, et la fonction déjà corrigée n'est un coupable prouvé qu'après qu'un test a isolé son effet de celui des fonctions suivantes.
Les quatre leviers d'une session longueContexte et coût
Une session longue ne gonfle pas indéfiniment le texte envoyé au modèle, grâce à des leviers distincts : le cache, qui réutilise un début de conversation identique, le retrait des sorties d'outils inutiles, la compaction, qui remplace l'historique par un résumé, et la délégation à des sous-agents, qui ne renvoient que leur conclusion.
Compacter, effacer, lire juste ce qu'il fautContexte et coût
La commande /compact remplace l'historique de messages par un résumé et poursuit la même conversation, la commande /clear efface cet historique et repart de zéro, et dans les deux cas les fichiers du projet sur le disque ne bougent pas : le geste qui économise le plus reste de ne faire lire à Claude que la tranche pertinente d'un fichier.
Cache de prompt et Batch API, deux remises à connaîtreContexte et coût
Le cache de prompt et la Batch API sont deux remises différentes sur le même coût en jetons. Le cache récompense un début de conversation qui ne change pas, la Batch API récompense un volume de requêtes qui peut attendre. La durée de vie du cache dépend de votre offre : abonnement payant ou clé d'API.
Le seuil d'auto-compactage ne fait pas ce qu'on croitContexte et coût
Le seuil d'auto-compactage déclenche un résumé de la conversation quand le contexte l'atteint, ce n'est pas un mur qui ferme la fenêtre : une valeur réglée au-dessus de la fenêtre réelle du modèle actif est plafonnée à cette fenêtre, un comportement documenté dont l'absence d'avertissement à l'écran reste à vérifier soi-même.
Une fenêtre de contexte ne suit pas le modèleContexte et coût
La fenêtre de contexte est une propriété du modèle : les modèles récents ont la grande fenêtre de base, deux modèles plus anciens la demandent par le suffixe [1m], et chaque changement de modèle se vérifie à l'écran par /model puis /context.
D'où vient vraiment la facture, et pourquoi un décompte mentContexte et coût
Le coût d'une session ne vient pas du volume de travail mais du nombre de fois où l'historique accumulé est renvoyé : chaque appel d'outil le relit, au tarif réduit du cache mais jamais à coût nul. Un décompte de jetons qui confond relecture en cache et première lecture donne une idée fausse de la facture.
Quota, débit et routage vers le modèle le moins cherContexte et coût
Deux plafonds distincts gouvernent une session, le coût en argent et le débit en jetons par minute, et les deux se traitent par le même réflexe : router les tâches répétitives vers Haiku ou Sonnet, garder Opus pour le raisonnement difficile, et attendre en respectant un délai croissant après une erreur 429 plutôt que de relancer aussitôt.
Un sous-agent coûte avant d'avoir travailléContexte et coût
Un sous-agent coûte avant d'avoir travaillé, car sa conversation contient déjà des éléments que vous n'avez pas écrits et que chaque lancement recharge. Sans champ tools, il hérite de tous les outils ; sans modèle nommé, il tourne sur le même modèle que vous. Listez ses outils et nommez son modèle selon son rôle.
Mémoire fichier : structure et disciplines de baseLe second cerveau
La mémoire de Claude Code vit dans un dossier de fichiers markdown, un fait par fichier classé par un champ type à quatre valeurs, et une note qui porte une seule idée reliée à au moins une autre reste trouvable en quelques secondes plutôt qu'en une relecture complète.
Obsidian : wikilinks, cartes de contenu et types de mémoireLe second cerveau
Le wikilink est une fonctionnalité native d'Obsidian qui connecte une note à une autre sans dépendre du dossier où chacune se trouve. La carte de contenu n'est qu'une pratique, une note qui rassemble des liens. Beaucoup de gens reprennent dans leur coffre Obsidian le vocabulaire de types de la mémoire de Claude Code, mais ce sont deux outils séparés.
Interroger un graphe plutôt que tout relireLe second cerveau
Un graphe de connaissance construit une fois répond à une question en parcourant des liens explicites, ce qui coûte nettement moins de jetons qu'une relecture complète des fichiers sources, un écart illustré par un exemple public qui porte sa propre réserve, et le même principe s'applique à un vieux transcript de session, interrogé par niveaux avant d'être rouvert en entier.
Dream et apprentissage continu : la consolidation nocturneLe second cerveau
Une consolidation nocturne de mémoire est une automatisation personnelle bâtie sur une tâche planifiée, pas une fonction native de Claude : elle digère les notes en quatre phases, orientation, collecte, consolidation par fusion et archivage, vérification, et seule une tâche qui tourne sur le poste ou dans une session ouverte peut lire un dossier de notes stocké en local.
Un chiffre périssable dans un fichier toujours chargéLe second cerveau
Un chiffre qui dort dans un fichier toujours chargé se lit comme un chiffre du jour, alors qu'il a pu devenir faux. Si personne ne recevrait d'alerte le jour où il change, sa place est dans un registre daté, ouvert seulement quand la question se pose, et le fichier chargé cite le principe ou renvoie au registre.
Un coffre partagé n'a pas d'édition concurrenteLe second cerveau
Une application de notes à fichiers locaux ne verrouille rien sur un lecteur réseau partagé : un témoignage public documente un dossier de paramètres qui s'écrase entre utilisateurs sur ce type de montage, et le même mécanisme rend plausible, sans que la source ne le documente elle-même, la perte silencieuse d'une édition de note.
Le journal de l'assistant parle surtout de l'assistantLe second cerveau
Une revue d'un grand corpus de mémoire tenu par un agent montre que la plupart des entrées documentent les erreurs de l'agent lui-même, écrites par lui, à propos de lui, avec presque aucune instruction explicite de la personne qu'on croit profiler : c'est comme juger un pilote par le journal de maintenance de l'avion.
Fan-out, pipeline, barrière : choisir l'architecture, ou y renoncerPlusieurs agents et vérification adverse
Le fan-out converge derrière une barrière qui attend tous les agents, alors que le pipeline fait avancer chaque élément sans attendre les autres. La troisième option consiste à ne lancer aucun agent, car l'architecture multi-agents est une option coûteuse : commencez par l'approche la plus simple qui fonctionne.
Isoler et exécuter en tâche de fond : worktrees et boucle à secPlusieurs agents et vérification adverse
Pour qu'un agent n'écrase pas le travail d'un autre dans le même dépôt, donnez à chacun son propre worktree avec isolation: worktree. Un agent lancé en session interactive tourne désormais en arrière-plan par défaut. Pour qu'une recherche sache s'arrêter, comparez chaque cycle à l'ensemble déjà connu et arrêtez-vous dès que les passages consécutifs ne signalent plus rien de nouveau.
Faire tenir un fan-out à grande échellePlusieurs agents et vérification adverse
Un agent unique chargé d'un livrable trop long est interrompu par une limite de taille de sortie : la parade est un agent par axe, chacun écrivant son propre fichier. Vérifiez ensuite le disque, jamais le rapport : écrivez avant le lancement la liste exacte des fichiers attendus et comparez-la à ce qui existe vraiment.
Workflows déterministes : schémas, checkpoints, reprisePlusieurs agents et vérification adverse
Un workflow est un script qui enchaîne des appels d'agent de façon déterministe : mêmes étapes et même schéma de sortie à chaque exécution. Un schéma JSON impose des champs nommés d'une étape à l'autre, et chaque étape terminée écrit un checkpoint, ce qui permet de reprendre un workflow interrompu sans tout refaire.
Vérification adversariale, panels de juges et critique de complétudePlusieurs agents et vérification adverse
Un vérificateur adversarial reçoit l'artefact à juger, des critères de succès clairs et les outils pour vérifier, et un rapport vide n'est crédible que s'il compte ce qu'il a contrôlé. Un panel compare des solutions, un critique de complétude compare le cahier des charges à ce qui a été livré : des rôles à ne pas confondre.
Multiplier les agents peut multiplier l'erreurPlusieurs agents et vérification adverse
Une étude (prépublication arXiv) mesure que des agents indépendants, sans coordinateur qui valide leurs sorties, amplifient les erreurs bien plus qu'un agent seul. Un coordinateur qui relit chaque sortie réduit nettement cette amplification, et sur une tâche aux étapes strictement ordonnées, les quatre architectures multi-agents testées reculent face à un agent seul.
Une prémisse non vérifiée dans un prompt revient en conclusionPlusieurs agents et vérification adverse
Une prémisse fausse glissée dans le cadrage d'un prompt n'est jamais testée : l'agent la traite comme un fait et la reflète dans son résultat, et le vérificateur adverse, qui ne relit que ce résultat, ne la voit pas. Dans un fan-out, elle est répétée dans chaque sortie, ce qui donne une fausse impression de corroboration.
Trois états d'échec, et accepter un risque proprementPlusieurs agents et vérification adverse
Une file de tâches distingue le succès, l'échec récupérable qui sera retenté et l'échec définitif ; les confondre en une seule catégorie d'échec casse la valeur de toute alerte. Accepter un risque, c'est le laisser se produire puis vérifier après coup grâce à un instantané pris avant l'exécution, pas l'ignorer.
Retirer l'outil avant d'écrire l'interditPlusieurs agents et vérification adverse
Une consigne qui interdit oriente ce qu'un agent tente sans rien empêcher : la protection qui tient lui retire d'abord les outils dont sa mission n'a pas besoin, puis la liste fermée des effets attendus et l'interdit par classe viennent en deuxième et troisième lignes, comme consignes.
Réussi, échoué, interrompu, sans tracePlusieurs agents et vérification adverse
Quand une coupure arrête une file de tâches, un journal tenu hors du processus, écrit avant et après chaque tâche, sépare quatre états : réussi, échoué, interrompu en cours de route, et sans trace de tentative ; les confondre fait relancer ce qui a peut-être déjà agi, ou déclarer en échec ce que personne n'a examiné.
Plafonner une boucle de juges avant de la lancerPlusieurs agents et vérification adverse
Fixez le plafond avant la première passe, dans les critères du lot : un nombre maximal de passes de juge et d'agents. Le critère d'arrêt appartient au juge, que vous ne maîtrisez pas, et tant qu'il trouve quelque chose, la boucle continue et son coût grimpe. À l'atteinte du plafond, on corrige les constats majeurs sourcés et on clôt.
Secrets : ne jamais les faire transiter, ne jamais les afficher en clairSécurité et données
Un secret collé dans une conversation, même brièvement, reste ensuite présent dans les journaux et dans toute relecture automatique de l'historique, et une commande de configuration lancée pour un motif précis peut afficher un secret voisin en clair si son filtre est trop large.
Un secret commis est brûlé : rotation immédiate, jamais la dateSécurité et données
Un secret suivi par un dépôt se traite comme compromis à l'instant où il est écrit, pas quand quelqu'un prouve qu'il a été lu, et le remède qui atteint chaque copie est de faire tourner l'identifiant, la réécriture de l'historique venant en second et pas toujours nécessaire.
Pseudonyme et anonyme, deux choses différentesSécurité et données
Un numéro à la place d'un nom reste une donnée personnelle tant qu'une table de correspondance existe quelque part, ce qui peut faire du destinataire un sous-traitant selon son rôle réel, et une identité pseudonyme sur un dépôt exige sa propre configuration locale.
Auditer une compétence avant de l'installerSécurité et données
Auditez une compétence tierce avant de l'installer : mettez-la en quarantaine, lisez tout son contenu, passez un scanner de sécurité, et faites tourner tout secret qu'une compétence retirée a pu toucher. Le risque le plus fréquent est l'instruction cachée, presque toujours combinée à du code malveillant.
Ce qu'un agent peut faire fuiter sans qu'on le lui demandeSécurité et données
Une instruction cachée dans un contenu que Claude lit pendant la tâche, page web, fichier ou commentaire de dépôt, peut lui faire proposer une action de sortie que vous n'avez pas demandée : c'est l'injection de prompt indirecte, que les protections documentées réduisent sans l'éliminer.
Automatisation responsable : réversible d'abord, panne signalée, correctif demandéSécurité et données
Une automatisation en mode Auto, Accept Edits ou Bypass Permissions exécute la plupart des suppressions au moment où la commande est atteinte, sans confirmation : construisez donc le point de contrôle humain avant la commande destructive. Une panne silencieuse ne s'annonce jamais elle-même, et un correctif bloqué se demande, il ne se note pas.
Ce qui quitte la machine, ce qu'on archive, ce qu'on ne partage jamaisSécurité et données
Chaque requête envoie le prompt et la réponse sur le réseau et laisse une copie locale lisible en clair sur le disque : un secret collé une fois existe à deux endroits. Archivez plutôt que supprimer, car un déplacement reste annulable. Filtrez un document interne avant de l'envoyer : inventaire des données sensibles, puis relecture en lecteur hostile.
Lire suffit à exposer un secretSécurité et données
Une recherche de texte sur un dossier entier renvoie chaque ligne qui contient le motif, même celles d'un fichier .env caché, sans qu'aucune lecture de ce fichier n'ait été demandée. Une règle de refus Read(./.env) ne couvre pas une commande qui lit des fichiers sans les nommer, comme grep -r, ni un sous-processus qui ouvre lui-même ses fichiers.
Une garde par motif de texte n'est pas une frontière de sécuritéSécurité et données
Une garde qui refuse un mot dans le texte d'une commande juge une écriture et non un effet : toute écriture qui évite ce mot passe, et même une liste de commandes admises à l'égalité exacte laisse passer le code qu'une commande admise lit dans un fichier que l'agent peut modifier.
Un accord général n'autorise pas un envoi précisSécurité et données
Un accord donné sur une méthode de travail valide la façon de procéder, pas un envoi dont le contenu n'a pas encore été montré : l'accord d'envoi nomme le texte et les destinataires, ou la catégorie d'envois qu'une autorisation durable désigne elle-même.
La requête, une seule porte d'entréeL'API Claude pour ceux qui construisent
L'API Claude n'a qu'une seule porte d'entrée, la requête POST de l'API Messages : chaque échange passe par ce point, avec un tableau messages et un modèle choisi. Le champ max_tokens est obligatoire, sans valeur par défaut, et la réponse suit toujours la même forme, avec un stop_reason qui indique pourquoi la génération s'est arrêtée.
Des rôles qui tiennent, pas un pré remplissage qui casseL'API Claude pour ceux qui construisent
Compléter soi-même le début de la réponse de Claude, le pré remplissage du tour assistant, ne fonctionne plus sur les modèles courants : le serveur renvoie une erreur, sauf un cas particulier de gestion des refus. Une instruction system stable produit le même résultat sans toucher au tableau messages, et le champ output_config.format contraint la forme de la sortie.
Les outils, Claude propose, le code disposeL'API Claude pour ceux qui construisent
Claude n'exécute jamais un outil lui-même : il renvoie une demande d'usage, le code du développeur l'exécute réellement, puis renvoie le résultat pour que la conversation continue. Ce cycle repose sur un seul contrat, le schéma déclaré par le champ input_schema. Un outil se déclare par name, description et input_schema.
Recevoir la réponse au fil de l'eauL'API Claude pour ceux qui construisent
Le mode flux garde la connexion HTTP ouverte et livre le texte par fragments, au fur et à mesure que le modèle le produit, sans attendre la fin de la génération. Le décompte de jetons vit dans le champ usage du dernier événement message_delta, jamais dans message_stop : un code qui l'y cherche ne le trouve pas.
Deux leviers de coût, la mémoire en cache et le traitement par lotL'API Claude pour ceux qui construisent
Un préfixe de requête marqué comme réutilisable coûte une fraction réduite du prix normal quand il est relu depuis le cache, et un ensemble de requêtes non urgentes traité en lot coûte moins cher qu'un traitement immédiat, deux réductions qui se cumulent entre elles et avec les autres modificateurs de prix.
Compter avant d'envoyer, la fenêtre de contexteL'API Claude pour ceux qui construisent
Un point de comptage dédié rend le nombre de jetons d'une requête avant de l'envoyer, et la fenêtre de contexte à comparer à ce chiffre n'est plus une valeur commune à toute une gamme de modèles, elle varie désormais fortement d'une famille à l'autre.
Choisir un modèle, en changer, encaisser un refusL'API Claude pour ceux qui construisent
Le choix d'un modèle est un compromis entre qualité, vitesse et coût qui se revoit à chaque nouvelle génération, et un refus renvoyé par un classificateur de sécurité se traite comme un cas normal du protocole, pas comme une panne.
Passer à Opus 5.5 sans casser votre codeL'API Claude pour ceux qui construisent
Passer de Claude Opus 5 à Claude Opus 5.5 ne se résume pas à changer l'identifiant : quatre réglages anciens renvoient désormais une erreur 400, et les notes écrites entre deux appels d'outils arrivent vides tant que le code ne règle pas thinking.display.
Pipeline de contenu, du brief au livrable partageableCas réels de bout en bout
Un contenu destiné à être traduit, cité par un assistant et relu hors connexion se produit par une suite de rôles distincts, chacun avec une seule tâche : brief, rédaction, alignement de voix, optimisation pour la recherche, traduction en lot, empaquetage. Chaque rôle commence quand le précédent est terminé et approuvé, jamais en parallèle sur le même texte.
Bâtir un actif de données, jeu synthétique ou base de connaissancesCas réels de bout en bout
Un jeu synthétique et une base de connaissances partagent la même architecture : ingestion ou génération en lot, déduplication, liaison par un schéma partagé, puis rappel via un index léger. Le schéma se fixe avant le premier enregistrement, et la déduplication se fait avant la validation, jamais après.
La recherche en éventail, avec vérification contradictoireCas réels de bout en bout
Lancer les recherches en parallèle accélère la collecte, pas le jugement : la vitesse ne change rien à la fiabilité. Chaque affirmation retenue doit être activement contestée par une source distincte avant d'être citée avec sa source, et celle qui ne résiste pas sort du brouillon au lieu d'y rester adoucie.
Vérifier avant de croire, quatre pièges réelsCas réels de bout en bout
Un rapport rédigé par l'agent d'un tiers, une skill payante vendue comme un lot de fonctionnalités, un connecteur de données annoncé comme synchronisé et une page concurrente qui affiche une fonctionnalité absente partagent la même faille : chacun remplace une mesure directe par une affirmation qu'il faudrait vérifier avant de la citer.
Une application mobile de bout en boutCas réels de bout en bout
Une seule session suffit pour enchaîner la structure de départ générée (le scaffold), une navigation entre écrans, un appel réseau et la correction des types signalés, à condition de garder ouverte dès le premier écran la prévisualisation, qui se met à jour sur votre téléphone. Une erreur vue juste après l'avoir introduite se corrige en quelques secondes.
Automatiser sa propre pratique, pile et skillCas réels de bout en bout
Un geste qui se répète à l'identique devient une commande nommée, invoquée d'un mot plutôt que reconstruite chaque fois. Plusieurs couches la font travailler seule : l'appel scriptable fait le travail, le déclencheur de cycle de vie décide quand le lancer, la mémoire distillée garde ce qu'il faut retenir.
Rendre son site lisible par les IA, citation et navigation agentiqueCas réels de bout en bout
Citation par un assistant et navigation agentique sont deux capacités distinctes, vérifiées par deux contrôles distincts. La citation dépend d'abord de ce que d'autres pages disent du site, le balisage ne la crée pas ; la navigation se joue sur la page, où un bouton sans texte ni étiquette accessible reste invisible pour un agent.
Échauffement, assembler un prompt et cocher sa checklistAtelier, capstone et examen
L'échauffement n'écrit aucune ligne de code : il vérifie que les réflexes acquis reviennent seuls, sans notes. Reconstruisez de mémoire un prompt complet, puis cochez la checklist du praticien point par point avant le chantier suivant ; chaque brique manquante désigne un automatisme pas encore installé.
Se situer, du débutant à l'expert, avant de choisir son chantierAtelier, capstone et examen
Quatre paliers d'autonomie (un Project muni d'instructions, une session Claude Code cadrée par un fichier de configuration, un skill maison, un dossier mémoire relié et consolidé) indiquent lequel des trois chantiers de fin de parcours correspond à son propre niveau.
Le capstone, trois chantiers réels au choixAtelier, capstone et examen
Le capstone se réussit en livrant jusqu'au bout un des trois chantiers au choix : une fonctionnalité, un second cerveau ou un pipeline de contenu. Le plan est approuvé avant l'exécution, le périmètre tient dans une seule session et la vérification finale se fait dans l'environnement réel.
Capstone avancé, la revue contradictoire multi-agentsAtelier, capstone et examen
Un seul relecteur retombe souvent sur le même angle mort que l'auteur du code. Distribuer la relecture à plusieurs sous-agents, chacun avec un rôle étroit, corrige ce biais, à condition que les rôles restent distincts, qu'aucune sortie incomplète ne passe à l'étape suivante et que la synthèse finale fasse remonter les désaccords au lieu de les lisser.
La checklist de diplôme, l'examen finalAtelier, capstone et examen
Relire sa checklist et se dire oui, je sais faire ça, ne prouve rien : une relecture confirme ce qu'on croit déjà savoir. La version qui révèle une lacune demande de citer le geste précis qui prouve chaque point ; si vous ne vous souvenez que de l'avoir lu, ne cochez pas la case.