Rechercher une leçon
157 leçons.
- Chat, Cowork, Claude Code, trois outils, trois usagesChoisir la bonne porte d'entrée
Chaque environnement Claude répond à un besoin différent, aucun ne remplace les deux autres.
- Cowork, le mode par défaut pour un non techniqueChoisir la bonne porte d'entré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.
- Régler l'ordinateur pour les sessions longuesChoisir la bonne porte d'entrée
Maintenir l'ordinateur actif avant tout traitement long, sinon la session s'arrête sans prévenir.
- Comprendre le jeton et la fenêtre de contexteNe jamais tomber en panne de jetons
Chaque mot lu ou écrit consomme un jeton, et rouvrir une session ancienne recharge, donc repaie, toute sa fenêtre de contexte.
- Que faire quand la limite est atteinteNe jamais tomber en panne de jetons
Un quota atteint bloque l'envoi de nouveaux messages jusqu'à un évènement qui dépend du type de compte, et la seule action fiable en attendant est de savoir à l'avance qui contacter dans son organisation.
- Les bons réflexes pour économiserNe jamais tomber en panne de jetons
Plusieurs sessions courtes rattachées à un projet font relire beaucoup moins de matière qu'une seule session prolongée d'un jour sur l'autre.
- Le projet, contenant du contexteGarder le fil d'un jour à l'autre
Un projet regroupe fichiers, instructions et sessions en un seul endroit qui persiste d'une fois sur l'autre, une tâche traitée hors de tout projet reste une session isolée qui ne garde rien après sa fermeture.
- Activer la mémoire, distincte de l'historiqueGarder le fil d'un jour à l'autre
La mémoire retient une sélection choisie de ce qui a été dit, l'historique conserve chaque conversation telle quelle sans qu'une nouvelle session la relise toute seule.
- Reprendre une session sans tout reperdreGarder le fil d'un jour à l'autre
Ouvrir une session neuve rattachée au même projet et demander de reprendre le contexte coûte moins cher et va plus vite que prolonger une session déjà très chargée.
- Ce que Cowork voit et ce qu'il ne voit pasFaire agir Claude sur ses vrais dossiers
Les fichiers que Cowork lit et modifie sont ceux des dossiers que vous avez connectés, mais son regard ne s'arrête pas aux fichiers : selon la façon dont vous l'ouvrez, il voit aussi votre écran.
- Travailler sur une copie, jamais sur l'originalFaire agir Claude sur ses vrais dossiers
Un fichier ouvert directement par Claude dans un dossier connecté est modifié sur place, pas sur une copie invisible que vous retrouveriez ensuite.
- Compétences et plugins, la spécialisation à la demandeFaire agir Claude sur ses vrais dossiers
Une compétence est une spécialisation chargée pour répondre à un domaine précis, un plugin en regroupe plusieurs dans un seul paquet installable.
- Les connecteurs, un lien direct avec un logicielFaire agir Claude sur ses vrais dossiers
Un connecteur relie Claude à un service externe après une autorisation explicite, et cette autorisation vaut au delà de la conversation en cours, jusque dans les tâches planifiées.
- Ce qui exige une prudence particulière avant de faire traiter un documentDonnées personnelles, la vigilance obligatoire
Les données d'identité, de santé ou de situation personnelle sont des catégories protégées, et un secret ne doit jamais transiter par une conversation, même brièvement.
- Ce que le compte d'organisation garantit, et ce qu'il ne garantit pasDonnées personnelles, la vigilance obligatoire
Sur un compte d'organisation, Anthropic n'entraîne pas ses modèles sur les conversations, mais l'organisation reste seule responsable du traitement des données qu'elle y fait transiter.
- Traiter un premier cas réel de bout en boutPasser à la pratique et se repérer seul
Un livrable produit par Claude n'est acquis que lorsqu'on l'a relu soi-même, l'annonce de succès ou l'aspect propre d'un document n'est jamais une preuve du fond.
- Le glossaire de référencePasser à la pratique et se repérer seul
Neuf mots reviennent sans cesse dans les conversations sur l'outil : agent, jeton, fenêtre de contexte, projet, compétence, plugin, connecteur, tâche planifiée, sous-traitant.
- 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 d'une même famille partagent le même entraînement de base et ne diffèrent vraiment que par le compromis entre la vitesse de la réponse et la profondeur du raisonnement appliqué avant de répondre.
- 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, et une consigne explicite donne un résultat plus fiable qu'une consigne vague laissée à l'appréciation de Claude.
- Être clair, direct, et donner le pourquoiÉcrire une demande qui marche
Claude se comporte comme un nouvel employé brillant sans contexte implicite sur vos habitudes, donc une demande gagne à préciser le pourquoi et qui va lire ou entendre la réponse, pas seulement la tâche à accomplir.
- Attribuer un rôleÉcrire une demande qui marche
Un rôle d'une phrase, placé en tête d'une conversation ou d'un projet, oriente le ton, le vocabulaire et les priorités de Claude, et une seule phrase suffit déjà à faire cette différence.
- Séparer les données des instructionsÉcrire une demande qui marche
Mélanger les instructions et les données dans un seul bloc de texte crée de la confusion, alors qu'une frontière nette, balise XML, titre, bloc de code ou ligne de marquage, la supprime.
- Formater la sortie et parler à la place de ClaudeÉcrire une demande qui marche
Préciser le format exact attendu, jusqu'à interdire explicitement toute phrase d'introduction, supprime les préambules inutiles et les sorties mal formées, alors que la technique historique consistant à écrire soi même le tout premier caractère de la réponse de Claude n'est plus disponible sur les modèles actuels.
- 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
Une demande qui marche s'affine par petites touches plutôt que de repartir de zéro, et se fige ensuite en modèle réutilisable où seule la partie qui change d'une tâche à l'autre est remplacée.
- 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'est pas la même chose qu'un contrôle qui rend un chiffre juste, et un contrôle défaillant échoue rarement de façon bruyante, il rend un résultat qui a l'air correct.
- 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 : rejouer ce mécanisme une seconde fois ne le rend pas indépendant, seule une méthode réellement différente le prouve.
- 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
Plus une méthode de contrôle est disciplinée, plus elle donne l'illusion d'avoir tout couvert, parce qu'elle ne peut juger que ce qui existe déjà, jamais ce qui manque entièrement.
- Prouvé, ou simplement pas encore réfutéVérifier ce qu'il rend
Prouvé signifie qu'une commande précise a tourné et que sa sortie a été lue ; pas encore réfuté signifie seulement que rien n'a attrapé de problème jusqu'ici, une affirmation bien plus faible.
- Un contrôle de forme ne voit jamais une valeur fausseVérifier ce qu'il rend
Un contrôle automatique mesure la forme, l'encodage, la présence d'un mot clé, jamais la vérité, et valider une capture d'écran ou une étape intermédiaire ne prouve jamais ce que la personne va réellement ouvrir.
- 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é.
- Enchaîner les promptsTechniques qui changent le résultat
Découper une tâche complexe en une chaîne de prompts courts, où la sortie de l'un devient l'entrée du suivant, rend chaque maillon vérifiable séparément au lieu de juger un seul bloc opaque.
- Donner des mains à ClaudeTechniques qui changent le résultat
L'appel d'outils laisse Claude demander l'exécution d'une fonction que vous avez définie, mais le modèle n'exécute jamais rien lui-même : c'est votre application, ou pour certains outils fournis par Anthropic ses propres serveurs, qui exécute réellement l'opération, et la clarté de la description de l'outil détermine la justesse des arguments qu'il envoie.
- Composer un system prompt à partir de plusieurs sourcesTechniques qui changent le résultat
Fusionner les meilleures règles de plusieurs system prompts fonctionne comme une opération d'écriture ordinaire, à condition de réécrire chaque règle importée pour son propre contexte plutôt que de la copier telle quelle, et de laisser les règles déjà en vigueur trancher tout conflit.
- 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
Un eval est un jeu de tests fixes qui note un prompt, et le meta-prompting utilise Claude pour améliorer un prompt existant, mais dans les deux cas le résultat reste un brouillon à tester, jamais une réponse définitive.
- 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 paysage des modèles, une même famille de prédicteursChoisir son modèle et son outil
Claude, GPT, Gemini et les modèles à poids ouverts sont tous des prédicteurs du mot suivant entraînés différemment, et un gabarit de prompt écrit pour l'un se transpose presque sans changement chez les autres.
- Router par tâche, pas par marqueChoisir son modèle et son outil
Choisir un modèle se décide sur la nature de la tâche, son enjeu et sa nouveauté, non sur une fidélité de marque, et un cadrage plus honnête d'une demande débloque souvent plus 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
Un modèle à poids ouverts qui tourne en local n'entraîne aucun coût facturé à l'appel et ne fait sortir aucune donnée vers l'extérieur, un modèle ajusté sur mesure coûte cher à construire et ne se justifie qu'à très grand volume ou pour un format figé, et dans l'immense majorité des cas un prompt mieux écrit règle le problème plus vite que les deux.
- Ouvrir Cowork et installer son premier espace de travailCowork, le collègue numérique
Cowork est un agent de bureau qui exige un plan payant et, pour toucher vos fichiers locaux, l'application Claude Desktop ouverte et connectée ; un projet Cowork regroupe des dossiers, des instructions et une mémoire qui lui sont propres.
- 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
Cowork propose trois modes d'approbation, Manuel qui vous fait valider chaque action, Automatique qui laisse Claude se relire lui même avant d'agir, et Sans approbation qui ne vérifie plus rien : la suppression définitive d'un fichier reste confirmée dans les trois modes, une tâche s'arrête à tout moment, et sur un compte Team ou Enterprise un administrateur peut retirer le mode Automatique du sélecteur.
- Reconstruire un vrai tableur ou un rapport, pas un brouillon à corrigerCowork, le collègue numérique
Cowork livre des fichiers finis, un classeur avec des formules qui recalculent vraiment, un diaporama monté, un document mis en forme, pas seulement du texte brut à reprendre : nommer la structure exacte attendue ou fournir un modèle à copier rapproche le résultat de ce qui sera réellement utilisé, et un chiffre affiché juste dans une cellule ne prouve jamais que la formule qui l'a produit est correcte.
- 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 : au relevé du 2 septembre 2026, le connecteur Gmail de Google Workspace peut envoyer, répondre et transférer des messages directement, avec une approbation demandée par défaut avant chaque envoi que, sur un plan Team ou Enterprise, un propriétaire d'organisation peut autoriser les membres à lever, tandis que le connecteur Microsoft 365 pour Outlook peut aussi envoyer, mais seulement une fois qu'un administrateur du compte a activé cette capacité pour l'organisation entière.
- 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 intégré à l'application de bureau, puis en dernier recours le contrôle direct de l'écran, toujours dans cet ordre fixe, y compris pour une tâche planifiée qui s'exécute sans surveillance.
- Cowork partout, qui peut faire quoi, et la piste laissée derrièreCowork, le collègue numérique
Cowork est passé du bureau seul au web et au mobile le 7 juillet 2026 et reste en bêta sur ces deux surfaces, avec des sessions dans le cloud qui continuent sans aucun appareil allumé ; sur un compte Enterprise, des rôles personnalisés bornent l'accès équipe par équipe, et l'activité de Cowork se retrouve dans un export technique, pas dans la transcription du chat elle même, sauf pour une session qui tourne en local sur le poste, dont l'historique reste seulement sur cet ordinateur.
- 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
Une bonne mémoire commune repose sur quatre gestes, rassembler, repérer les doublons même quand la formulation diffère, relier ce qui va ensemble, et retrouver vite grâce à un sommaire léger plutôt qu'en fouillant tout le dossier à chaque fois.
- Recette : produire un même document en plusieurs langues sans qu'il divergeRecettes de métier
Une source unique et verrouillée pilote toutes les versions traduites, et un contrôle de cohérence compare ensuite les chiffres et les termes clés entre chaque langue, pour qu'une correction faite dans une version ne soit pas oubliée dans les autres.
- Recette : partager un document en un seul fichier qui s'ouvre partoutRecettes de métier
Un document destiné à être envoyé par courriel ou messagerie doit tenir en un seul fichier sans lien externe ni dépendance, validé en le rouvrant hors ligne avant l'envoi, pour qu'il s'affiche pareil chez tout le monde sans installation.
- Claude Code et la boucle de l'agentFondamentaux et boucle d'agent
Claude Code enchaîne réflexion, appel d'outil réel et lecture du résultat en boucle jusqu'à l'objectif, il ne répond pas une seule fois comme un chat.
- CLAUDE.md, la mémoire du projetFondamentaux et boucle d'agent
CLAUDE.md est lu automatiquement au début de chaque session sur le dépôt où il se trouve, et ses règles sont lues comme du contexte, sans garantie d'application stricte.
- Les commandes slash essentiellesFondamentaux et boucle d'agent
Un petit jeu de commandes slash pilote une session Claude Code entière, mémoire du projet, contexte de la conversation et extensions actives, sans jamais toucher au code du dépôt.
- Permissions et mode planFondamentaux et boucle d'agent
Le mode de permission décide quelles actions Claude Code exécute sans rien demander, et depuis la version 2.1.228, en session interactive de terminal ou VS Code, le mode qui accueille une nouvelle session sur les offres Pro, Max et Team n'est plus le mode default mais le mode auto, qui 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é, alors que Ctrl+C répond à une question différente 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 de vraies commandes sur votre poste, Claude lit la sortie réellement produite pour poursuivre son raisonnement, et une invite de permission s'affiche avant chaque commande nouvelle.
- Lire et approuver un diffFondamentaux et boucle d'agent
Un diff se lit ligne par ligne avant d'être approuvé, et l'approbation elle-même se fait aujourd'hui par un menu à options nommées plutôt que par une frappe libre de lettre.
- 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érant le travail en plusieurs étapes sans l'exposer, tandis qu'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
L'installateur natif de Claude Code se met à jour tout seul, la connexion se fait par un abonnement Pro, Max, Team, Enterprise ou Console plutôt que par une clé API oubliée dans l'environnement, et claude doctor rend un diagnostic en lecture seule avant toute correction.
- 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.
- Skills : apprendre un workflow à ClaudeÉtendre : compétences, MCP, sous-agents, hooks, plugins
Une skill encapsule un workflow reproductible dans un fichier SKILL.md, invoquée par une commande slash explicite ou par correspondance automatique sur sa description.
- 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
Les skills se découvrent dans deux bibliothèques publiques maintenues par Anthropic, et plusieurs skills déclarées pour des besoins distincts peuvent se charger ensemble sur une même tâche, mais une description mal choisie ne se déclenche jamais, ni seule ni empilée.
- MCP : le protocole de connexionÉtendre : compétences, MCP, sous-agents, hooks, plugins
MCP est le standard ouvert qui connecte Claude à des outils et à des données externes autour de trois primitives : les outils qu'il peut appeler, les ressources qu'il peut lire, les invites réutilisables qu'il peut proposer.
- Connecter un serveur MCP et ce qui a changéÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un serveur MCP se connecte par OAuth ou par clé, se vérifie par claude mcp list, et le protocole lui-même a changé de cœur le 28 juillet 2026, un fait indépendant de toute version de Claude Code.
- Construire son propre serveur MCPÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un serveur MCP maison se lance en processus enfant par transport stdio, déclare dans inputSchema un schéma JSON que le serveur doit lui même valider, et une description précise décide quand Claude l'appelle.
- Sous-agents : déléguer dans un contexte isoléÉtendre : compétences, MCP, sous-agents, hooks, plugins
Un sous-agent traite une tâche dans une fenêtre de contexte isolée et n'en renvoie que la conclusion, ce qui garde la conversation principale propre et permet d'en lancer plusieurs en parallèle.
- 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 sur un événement précis du cycle de vie, jamais une préférence confiée au modèle en espérant qu'il s'en souvienne.
- Les événements de hook, du déclenchement au messageÉtendre : compétences, MCP, sous-agents, hooks, plugins
PreToolUse peut empêcher un appel de se produire, PostToolUse ne peut plus que réagir après coup, et la décision d'un hook passe par des champs JSON précis, 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 et des commandes dans un seul répertoire versionné, installable et partageable en une seule fois, avec un manifeste unique qui vit à part de tout le reste.
- settings.json en profondeurÉtendre : compétences, MCP, sous-agents, hooks, plugins
Cinq niveaux de settings.json se succèdent du plus fort au plus faible, une clé scalaire commune aux deux fichiers se décide par le niveau le plus prioritaire, mais la plupart des listes, dont permissions.allow et permissions.deny, se fusionnent entre les niveaux au lieu de s'écraser.
- 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
Claude Code examine les fichiers de test déjà présents dans un projet pour écrire un nouveau test dans le même style avant l'implémentation, et confirmer que ce test échoue réellement prouve qu'il teste bien quelque chose qui n'existe pas encore.
- Revoir du code et piloter git en langage naturelGestes courants
La revue de code locale par /code-review propose cinq niveaux d'effort de low à max, et ultra n'est pas un sixième niveau de la même échelle mais un dispositif distinct, une revue multi agents dans le cloud facturée séparément.
- Prendre en main, documenter et migrer une base de codeGestes courants
Sur un dépôt inconnu, une vue d'ensemble demandée avant toute modification oriente les questions suivantes, et la commande /init lit réellement le contenu du projet pour écrire un premier CLAUDE.md plutôt que de partir d'une page blanche.
- 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 isole une session parallèle sur sa propre branche, et le drapeau --worktree l'automatise désormais entièrement, là où seul le geste manuel git worktree add existait auparavant.
- 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 action de Claude Code dans la session en cours, le menu de points de reprise ouvert par /rewind précède désormais Git, qui reste nécessaire pour tout ce que ce système ne suit pas : une modification faite par une commande bash, l'édition d'un sous-agent en arrière-plan, ou un fichier lié par un lien symbolique ou physique.
- Erreurs d'API et limite de débitQuand ça déraille
Un appel à l'API échoue de plusieurs façons différentes : une erreur 400 ou 404 signale le plus souvent une requête mal formée qui doit être corrigée avant tout nouvel essai, sauf le cas particulier d'un 400 renvoyé pour un plafond de dépense atteint, tandis qu'une erreur 429 ne se résout en attendant que si elle porte un en-tête Retry-After, ce qui n'est pas le cas d'un plafond de dépense atteint.
- Une commande bloquéeQuand ça déraille
Une commande shell qui ne répond plus se coupe par Ctrl+C sans quitter la session, et le délai qui la fait basculer en tâche de fond est déjà fixé par Claude lui même, pas par un préfixe que vous ajoutez à la main.
- 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 peut décrire le symptôme avec exactitude tout en se trompant sur la cause, et exécuter cette demande à la lettre ne corrige alors rien ou aggrave la situation.
- 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 qui dure repose sur quatre leviers seulement : le cache, qui réutilise un préfixe stable, le retrait des sorties d'outils périmées, la compaction, qui résume l'historique, et le partitionnement, qui délègue le travail volumineux à des sous agents isolés.
- 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 facture la lecture d'un préfixe identique à environ dix pour cent du prix d'entrée normal, avec une durée de vie qui dépend de l'offre, une heure pour la conversation principale d'un abonnement payant utilisé dans son forfait, cinq minutes pour une clé API ou un sous agent ; la Batch API, elle, traite un lot de requêtes en différé avec une remise de cinquante pour cent, sur un quota de débit séparé.
- 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
Une fenêtre étendue ne semble pas se reporter automatiquement d'un modèle à l'autre, un point que la documentation ne tranche pas explicitement : le suffixe de taille est à retaper par prudence à chaque changement de modèle par la commande /model, sauf pour deux modèles nommés dont le comportement diffère du cas général.
- D'où vient vraiment la facture, et pourquoi un décompte mentContexte et coût
Le coût réel d'une session se cache rarement où on le cherche : un décompte de jetons confond souvent une relecture au tarif de cache avec une première lecture au tarif plein, une poignée de sessions marathon porte l'essentiel de la facture parce que l'historique entier se relit à chaque appel d'outil, et tout fichier chargé automatiquement au démarrage se repaie en entier à chaque compaction, pas seulement une fois au début.
- 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.
- 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 lien entre doubles crochets tisse un réseau plutôt qu'une pile de dossiers, la carte de contenu qui les rassemble est une pratique communautaire et non une fonction du logiciel, et une note de type user de la mémoire automatique de Claude Code reste rangée dans son projet par défaut, sauf réglage explicite : les mémoires réellement communes à tous les projets sont le fichier d'instructions personnel, les règles de niveau utilisateur et la politique gérée par l'organisation.
- 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 fait mesuré et périmé cité comme actuel est pire que l'absence de chiffre, parce qu'il garde l'air de faire autorité tout en supprimant le réflexe de vérification : le test tient en une question, un changement demain serait il signalé à quelqu'un, et si la réponse est non, le chiffre n'a rien à faire dans un fichier chargé à chaque conversation.
- 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 lance des agents indépendants en parallèle derrière une barrière commune, le pipeline fait traverser chaque élément sans barrière et reste le défaut du multi-étapes, une barrière n'est justifiée que si une étape a vraiment besoin du résultat complet de la précédente, et parfois la bonne décision est de ne pas utiliser d'agent du tout quand un seul appel suffit déjà.
- Isoler et exécuter en tâche de fond : worktrees et boucle à secPlusieurs agents et vérification adverse
Un worktree git par agent évite que les fichiers de plusieurs agents parallèles entrent en collision, une boucle à sec répète jusqu'à ce qu'un cycle ne renvoie plus rien de nouveau en s'appuyant sur un ensemble déjà vu, et depuis le 13 août 2026 un agent non coéquipier lancé en session interactive tourne par défaut en arrière-plan avec notification à la fin plutôt que de bloquer la session.
- Faire tenir un fan-out à grande échellePlusieurs agents et vérification adverse
Un livrable volumineux confié à un seul agent se fait couper par une limite de taille sans que rien ne soit écrit : fractionner par axe, faire écrire chaque agent sur son propre fichier, respecter le plafond documenté de seize agents actifs à la fois et de mille agents au total sur un même run, un seul appel acceptant jusqu'à 4 096 éléments que le runtime ordonnance lui même sous ce plafond, puis vérifier en comparant les fichiers attendus à ce qui existe réellement sur le disque plutôt que de croire les agents sur parole.
- Workflows déterministes : schémas, checkpoints, reprisePlusieurs agents et vérification adverse
Un workflow est un script qui orchestre des sous-agents de façon déterministe, avec une sortie structurée par un schéma JSON et un checkpoint après chaque étape, mais le modèle qui s'applique à un agent relancé suit un ordre de priorité à quatre étages, et sans que les trois premiers soient renseignés, cet agent hérite en dernier recours du modèle de la session qui l'exécute, pas de celle qui a écrit le script.
- Vérification adversariale, panels de juges et critique de complétudePlusieurs agents et vérification adverse
Trois rôles de vérification servent des angles différents et ne se remplacent pas l'un l'autre : le sous-agent vérificateur reçoit seulement l'artefact à juger, les critères de succès et les outils pour vérifier, jamais le diagnostic ni l'historique de celui qui l'a construit, et son silence n'est légitime que s'il a réellement cherché sans rien trouver, puisque le biais par défaut face à un doute penche vers le rejet ; un panel qui compare plusieurs solutions notées est une pratique répandue du secteur, pas un motif nommé par Anthropic ; et un critique de complétude, motif documenté sous ce nom, cherche exclusivement ce qui manque au regard du cahier des charges, jamais les erreurs de ce qui a été livré.
- Multiplier les agents peut multiplier l'erreurPlusieurs agents et vérification adverse
Une étude testant cinq architectures d'agents sur 260 configurations mesure un taux d'erreur amplifié jusqu'à environ dix-sept fois celui d'un agent seul quand des agents indépendants travaillent sans coordinateur qui valide leurs sorties, contre environ quatre fois quand un coordinateur les valide, et sur une tâche strictement séquentielle, les quatre architectures multi-agents testées reculent toutes face à un agent seul.
- Une prémisse non vérifiée dans un prompt revient en conclusionPlusieurs agents et vérification adverse
Le texte de cadrage qu'un orchestrateur écrit dans le prompt de chaque agent reste invisible à la revue adverse, qui reçoit l'artefact produit et des critères de succès, jamais l'intention ni l'historique de celui qui a construit la tâche : une affirmation fausse glissée dans ce cadrage traverse donc toute la chaîne sans être testée, et un fan-out qui envoie le même cadrage à plusieurs agents multiplie cette exposition au lieu de la diluer.
- Trois états d'échec, et accepter un risque proprementPlusieurs agents et vérification adverse
Une automatisation qui traite une file devrait distinguer succès, échec récupérable qui sera retenté, et échec définitif abandonné, et seul le troisième doit remonter à une personne, sinon chaque échec récupérable éteint la valeur de l'alerte le jour où elle a raison ; accepter un risque avec un contrôle compensatoire diffère de l'ignorer, un instantané pris avant l'exécution permettant de classer le résultat en trois voies, variation normale silencieuse, changement important qui alerte seulement, perte catastrophique qui restaure automatiquement.
- 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 de référence à la place d'un nom reste une donnée personnelle dès qu'une table de correspondance existe quelque part, ce qui peut faire du destinataire un sous-traitant selon son rôle réel plutôt qu'une simple anonymisation, et une identité pseudonyme sur un dépôt a besoin de sa propre configuration locale.
- Auditer une compétence avant de l'installerSécurité et données
Une étude datée a trouvé une faille de sécurité sur plus d'un tiers d'un large échantillon de compétences tierces, dont la grande majorité des cas confirmés malveillants passait par une instruction cachée, et deux vulnérabilités réelles ont laissé un dépôt malveillant s'exécuter avant la moindre confirmation, ce qui ne laisse que la quarantaine, la lecture intégrale et le scan systématique comme protocole fiable.
- Ce qu'un agent peut faire fuiter sans qu'on le lui demandeSécurité et données
Une injection de prompt indirecte dissimule une instruction dans un contenu que l'agent lit plutôt que dans ce que vous avez tapé, un fichier généré n'a pas d'auteur qui s'engage sur son contenu, et une règle de configuration qui cible un chemin de fichier est acceptée sans erreur tout en ne bloquant rien pour l'outil qui exécute des commandes directes, alors qu'une règle qui cible le nom de cet outil bloque réellement.
- Automatisation responsable : réversible d'abord, panne signalée, correctif demandéSécurité et données
Une action irréversible attend un point de contrôle humain avant de s'exécuter, mais ce contrôle n'est automatique que dans le mode de permission Manual, le plus prudent parmi les six modes documentés : sur les offres payantes une session démarre pourtant en mode auto par défaut, et plusieurs de ces modes approuvent d'avance les commandes de fichiers à l'intérieur du dossier de travail, y compris la suppression, ce qui déplace la responsabilité du point de contrôle vers celui qui conçoit l'automatisation.
- Ce qui quitte la machine, ce qu'on archive, ce qu'on ne partage jamaisSécurité et données
Une requête envoie sur le réseau le texte du prompt et les réponses du modèle, chiffrés en transit, et la copie locale de cet échange reste ensuite lisible en clair sur le disque pendant une durée fixée par défaut ; supprimer un fichier ne laisse aucun chemin de retour alors qu'archiver le garde disponible et réversible ; et un document interne riche en détails devient dangereux dès qu'il part vers l'extérieur, pour la raison même qui le rend utile en interne, ce qui exige un inventaire brut puis une relecture adversariale avant tout envoi.
- La requête, une seule porte d'entréeL'API Claude pour ceux qui construisent
Toute interaction avec Claude passe par un seul point d'entrée HTTP, la requête POST /v1/messages, qui reçoit un tableau de tours et rend toujours la même structure de réponse.
- Des rôles qui tiennent, pas un pré remplissage qui casseL'API Claude pour ceux qui construisent
Le pré remplissage du tour assistant, une pratique qui commençait la réponse de Claude à la place du modèle, est désormais rejeté par une erreur 400 sur les modèles courants ; une instruction system stable ou une sortie contrainte le remplacent.
- Les outils, Claude propose, le code disposeL'API Claude pour ceux qui construisent
Un outil se déclare par un schéma nommé input_schema ; Claude ne l'exécute jamais lui même, il renvoie une demande d'usage que le code exécute avant de renvoyer le résultat pour que la conversation continue.
- Recevoir la réponse au fil de l'eauL'API Claude pour ceux qui construisent
Le mode flux garde une seule connexion HTTP ouverte et livre le texte par fragments au fur et à mesure de sa génération, et le décompte cumulatif de jetons se lit dans le dernier événement message_delta reçu, jamais dans l'événement final message_stop.
- 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.
- Pipeline de contenu, du brief au livrable partageableCas réels de bout en bout
Un pipeline de contenu fiable sépare six rôles à une seule tâche chacun, du brief validé au fichier HTML unique vérifiable hors connexion, et mélanger deux de ces rôles dans la même passe fait perdre le contrôle.
- Bâtir un actif de données, jeu synthétique ou base de connaissancesCas réels de bout en bout
Un jeu de données synthétique et une base de connaissances partagent la même architecture à quatre opérations, un schéma commun, un identifiant de correspondance, une déduplication et une validation avant tout usage en aval.
- La recherche en éventail, avec vérification contradictoireCas réels de bout en bout
Lancer plusieurs recherches en parallèle plutôt qu'en séquence accélère l'enquête, mais une affirmation ne se cite qu'après avoir résisté à une tentative réelle de la réfuter.
- 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
Un scaffold, la structure de départ générée automatiquement pour une application, une navigation entre écrans, un appel réseau et une correction des types signalés par erreur peuvent s'enchaîner dans une seule session de travail, avec une prévisualisation qui se met à jour sur votre propre téléphone à chaque modification.
- Automatiser sa propre pratique, pile et skillCas réels de bout en bout
Un appel scriptable sans interface, des déclencheurs de cycle de vie et une mémoire distillée forment une pile qui continue de travailler seule, et un geste répété une troisième fois mérite de devenir une commande nommée.
- Rendre son site lisible par les IA, citation et navigation agentiqueCas réels de bout en bout
Être cité par un assistant conversationnel et être utilisable par un agent qui navigue sont deux exigences distinctes, l'une se joue hors du site sur les mentions fiables, l'autre se joue sur la page elle même.
- Échauffement, assembler un prompt et cocher sa checklistAtelier, capstone et examen
Reconstruire de mémoire un prompt complet et cocher sa propre checklist de praticien avant tout chantier révèle les automatismes qui manquent encore, là où une relecture d'exemple ne testerait que la lecture.
- 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
Livrer une petite fonctionnalité réelle, construire son propre second cerveau relié par fichiers, ou monter un pipeline de contenu du brief à la publication sont trois chantiers de même exigence, un seul suffit pour valider le parcours.
- Capstone avancé, la revue contradictoire multi agentsAtelier, capstone et examen
Un orchestrateur qui distribue des rôles étroits à plusieurs relecteurs en parallèle, une étape qui bloque les sorties incomplètes, puis une synthèse qui fait remonter les conflits plutôt que de les lisser, produisent une revue plus fiable qu'un relecteur unique.
- La checklist de diplôme, l'examen finalAtelier, capstone et examen
Une auto évaluation écrite révèle des lacunes qu'une simple relecture ne montre pas, et le choix du modèle comme les boucles agentiques à points de contrôle marquent la frontière entre praticien et débutant.