Claude Code peut devenir beaucoup plus utile sans installer un seul plugin supplémentaire. L’enjeu ne consiste pas uniquement à lui faire écrire du code. Il faut aussi savoir surveiller sa consommation, conserver les bonnes consignes, repartir proprement lorsque la conversation devient confuse et poser une question secondaire sans détourner le travail principal. Le contrôle à distance, le design et la recherche approfondie prolongent cette logique.
Dans sa vidéo « 7 funzionalità di Claude Code che (forse) non conosci », publiée le 30 septembre 2026, Raffaele Gaito présente sept fonctions intéressantes. Nous développons ici ces thèmes dans un guide original, avec des exemples et une vérification de la documentation Anthropic. Les « secrets » sont des possibilités peu exploitées, pas des astuces pour contourner un abonnement ou des autorisations.
Attention à la disponibilité : les commandes dépendent parfois de la version, du forfait, de l’environnement et des règles de l’organisation. Les explications ont été vérifiées à la date de publication. Si une option manque, commencez par contrôler ses conditions d’accès plutôt que de reproduire aveuglément une interface vue dans une vidéo.
La vidéo originale et les distinctions essentielles
Le point commun est l’organisation du travail. Ces fonctions ne rendent pas toutes le modèle plus intelligent : certaines permettent surtout de mieux gérer les informations et de comprendre l’activité de l’agent. C’est également une distinction importante dans notre analyse du DevDay d’OpenAI. Le modèle, les outils disponibles et l’environnement d’exécution constituent trois niveaux différents.
1. /usage : comprendre où passe votre budget
Le premier réflexe utile consiste à ne pas attendre l’avertissement de limite atteinte. Avec /usage, ou la rubrique de consommation de votre interface, vous pouvez vérifier si votre façon de travailler reste adaptée à vos ressources. Les informations affichées varient selon l’accès utilisé : un abonnement et une facturation à l’usage par API ne répondent pas aux mêmes règles.
La documentation sur les coûts décrit les limites des forfaits et certaines attributions récentes à des activités comme les skills ou les sous-agents. Une estimation locale n’est pas une facture API définitive. De même, l’analyse des sessions locales ne couvre pas nécessairement les activités effectuées dans l’application Claude ou depuis un autre appareil.
Exemple : une petite correction qui devient une grande mission
Vous demandez de corriger un module, puis ajoutez un audit de sécurité, une réorganisation du code, de la documentation et trois variantes de solution. Ce n’est plus une simple retouche. Les lectures, le raisonnement, les réponses et les travaux parallèles peuvent augmenter la consommation. Une comparaison avant et après aide à distinguer une vérification nécessaire d’un élargissement involontaire.
Une séquence plus maîtrisée consiste à délimiter le travail : lire les deux fichiers concernés, proposer la correction, la réaliser, puis lancer les tests pertinents. Si d’autres problèmes apparaissent, demandez une liste séparée au lieu d’autoriser automatiquement une enquête sur tout le dépôt. Vous choisissez ainsi où investir l’effort, sans renoncer à la qualité.
Le contexte et le quota ne sont pas la même chose. Le contexte correspond aux informations utilisables dans une conversation ; le quota concerne la consommation autorisée par le forfait. Une conversation courte peut avoir demandé beaucoup de travail. Une remise à zéro de la conversation ne recharge pas l’abonnement, et une question secondaire n’est pas une garantie de calcul gratuit.
2. /memory : conserver les règles utiles, pas les erreurs anciennes
La mémoire répond à une frustration très concrète : répéter les mêmes conventions à chaque session. Il faut distinguer les instructions explicites de CLAUDE.md des notes de mémoire automatique issues du travail. Le menu /memory permet d’inspecter et de gérer ces éléments, selon les options disponibles dans votre installation.
Le guide officiel de la mémoire explique un mécanisme fondé sur des fichiers. Il ne s’agit pas d’un entraînement personnalisé du modèle. Enregistrer une préférence ne modifie pas ses paramètres, et rien ne garantit que chaque détail soit conservé. La valeur de la mémoire dépend surtout de l’exactitude et de la pertinence de son contenu.
Quelles instructions faut-il conserver ?
Les bonnes règles décrivent un comportement observable : utiliser la commande de test du projet, respecter la bibliothèque de composants existante, ne pas écrire de secrets dans les journaux ou distinguer proposition et mise en production. « Fais toujours au mieux » n’aide pas à choisir. « Vérifie le schéma actuel avant de modifier une migration » fournit une action claire.
Imaginons une application financière où les montants et les dates doivent garder le même format. Cette convention mérite une instruction explicite. Une adresse de test provisoire, en revanche, peut devenir trompeuse si elle reste dans la mémoire longtemps après son abandon. Toutes les informations utiles aujourd’hui ne sont pas des règles durables.
Relisez périodiquement les commandes obsolètes, les préférences dépassées et les consignes contradictoires. N’y placez pas de mots de passe, de jetons, de clés privées ou de données personnelles. Un stockage local n’est pas automatiquement un coffre-fort. Supprimer une note n’annule pas les modifications déjà réalisées ni les copies éventuellement conservées ailleurs.
Si l’assistant reproduit une mauvaise procédure, demandez dans quel fichier il l’a trouvée. Corriger la source apporte davantage que répéter la même objection. Une mémoire courte et entretenue est plus facile à contrôler qu’une accumulation de règles impossibles à hiérarchiser.
3. /clear et /compact : repartir ou garder la continuité
Une conversation devient moins efficace lorsqu’elle réunit trop d’objectifs différents. Vous commencez par un bug, discutez ensuite de communication, changez de framework et demandez un texte commercial. À chaque étape, le système doit déterminer quelles consignes restent pertinentes. Une nouvelle conversation peut être plus simple qu’une série de corrections.
/clear lance une nouvelle conversation avec un contexte vide. /compact résume les échanges pour poursuivre le même travail avec moins d’encombrement. Le aide-mémoire des commandes distingue ces usages. Le premier convient à un nouvel objectif ; le second préserve la continuité d’une mission encore en cours.
Préparer une passation avant de vider le contexte
Si le travail n’est pas terminé, consignez son état dans un fichier approprié : changements effectués, tests réussis, problème ouvert et étape suivante. Vous n’avez pas besoin de recopier toute la conversation. Il faut un résumé opérationnel que la nouvelle session puisse comparer avec les fichiers réels.
Prenons une migration d’API. Le nouveau client fonctionne, mais les tentatives automatiques et le traitement des erreurs restent à contrôler. Une note utile indique les fichiers et les tests concernés. « Presque fini » ne permet pas de reprendre. Cette discipline s’applique aussi aux changements détaillés dans notre guide de migration des API de modèles.
/clear ne supprime pas les fichiers du projet, n’efface pas automatiquement la mémoire et ne réinitialise pas les limites du forfait. La gestion d’une conversation n’est ni une annulation du code ni une remise à zéro de l’ordinateur. Revenir sur une modification exige une opération distincte et contrôlée ; reprendre un ancien échange utilise le mécanisme prévu pour cela.
Identifiez donc le problème avant de choisir la commande. Un contexte trop chargé peut justifier une synthèse. Une règle permanente incorrecte demande une correction du fichier qui la contient. Une limite de consommation appelle une décision de budget. Confondre ces trois situations ne fait que masquer la cause initiale.
4. /btw : poser une question à côté sans détourner la mission
/btw permet de demander une explication pendant que le travail principal continue. Par exemple, l’agent prépare des tests et vous voulez comprendre ce qu’est une opération idempotente. La réponse secondaire clarifie le concept sans ajouter cette digression à l’historique principal.
La limite importante, précisée dans la documentation du mode interactif, est l’absence d’outils dans ce canal. La réponse peut utiliser les informations déjà présentes, mais elle ne peut pas ouvrir un nouveau fichier, exécuter une commande, naviguer sur le web ou modifier une configuration. Expliquer un fichier déjà lu n’est pas inspecter un fichier nouveau.
Trois bonnes questions et une demande inadaptée
/btw Pourquoi le code déjà examiné utilise-t-il un délai croissant entre les tentatives ?/btw Que signifie idempotence dans ce processus ?/btw Quel est le principal risque de la solution discutée ?- Demande inadaptée : « Ouvre le fichier des identifiants et change ce paramètre. » Elle exige des outils et concerne des données sensibles.
La séparation réduit les interruptions, mais ne rend pas la réponse omnisciente. Si une information n’a pas encore été obtenue dans la session, elle peut manquer aussi au canal secondaire. Demandez de distinguer une explication générale d’un fait réellement observé. Une formulation convaincante ne prouve pas qu’un contrôle a été effectué.
Utilisez ce canal pour comprendre les options, puis transmettez dans la conversation principale les décisions qui doivent modifier l’implémentation. Sinon, vous risquez de croire qu’un choix a été approuvé alors que l’agent chargé du travail ne l’a pas reçu. Une clarification et une nouvelle instruction opérationnelle n’ont pas le même rôle.
Choisissez également le canal selon la preuve nécessaire. Une définition brève convient ; une comparaison exigeant des sources nouvelles relève d’une autre démarche. Ce choix évite les interruptions inutiles et les fausses impressions de vérification.
5. Remote Control : suivre une session locale depuis le téléphone
Le contrôle à distance permet de continuer une session locale depuis un autre appareil. Vous pouvez consulter l’avancement, apporter une précision ou répondre à une demande d’autorisation sans rester devant l’ordinateur. Les fichiers et les outils continuent cependant à être utilisés dans l’environnement local de la session.
La documentation de Remote Control distingue cette fonction des sessions dans le cloud. L’ordinateur doit rester disponible et le processus doit continuer à fonctionner. Les forfaits compatibles et l’authentification prévue sont nécessaires ; une clé API ne suffit pas. Les règles d’une organisation peuvent aussi limiter l’accès.
L’astuce de la vidéo : l’activer pour les nouvelles sessions
En plus de l’activation ponctuelle avec /remote-control, les réglages proposent Enable Remote Control for all sessions lorsque l’environnement l’autorise. Cela évite de répéter l’opération au début de chaque session. C’est pratique pour un suivi fréquent sur téléphone ; une activation au cas par cas reste plus facile à maîtriser pour un usage occasionnel.
La connexion automatique ne rend pas vos sessions publiques. Vous devez néanmoins protéger le compte et les appareils. Ne partagez pas l’accès sans précaution et ne validez pas une commande simplement parce qu’une notification vous invite à le faire. Une opération destructive reste risquée, même depuis un téléphone.
Réservez le mobile au suivi et aux décisions étroites ; examinez les modifications importantes sur un écran permettant une véritable revue. Avant de partir, définissez ce que l’agent peut faire seul et ce qui exige une pause. Le confort du contrôle à distance ne remplace ni les tests ni les limites d’autorisation.
Gardez aussi les causes ordinaires de panne à l’esprit : ordinateur en veille, processus arrêté, environnement indisponible. Si rien n’avance, vérifiez l’hôte local avant de conclure à un blocage du modèle. L’interface distante donne accès au travail local ; elle n’en garantit pas l’exécution indépendante.
6. /design : transformer des exigences en proposition visuelle
Claude Design peut relier le contexte d’un projet à une exploration visuelle : écrans, parcours, compositions et prototypes à examiner. Son intérêt ne se limite pas à produire quelque chose de joli. Il s’agit de rapprocher les besoins réels du produit d’une proposition qui, autrement, partirait d’une description trop générale.
La commande /design possède des conditions précises dans la référence officielle : version de Claude Code, disponibilité des artifacts et accès au template Design. Elle ne fonctionne donc pas nécessairement avec chaque compte ou fournisseur d’exécution. Le résultat doit être revu dans le navigateur et confronté au parcours attendu.
Un brief plus utile que « fais un beau tableau de bord »
Demandez un écran comparant trois dépenses récurrentes, avec des montants lisibles, un filtre mensuel, un état vide et une distinction entre données confirmées et estimations. Précisez le public, la priorité des informations et les composants existants. Ce sont des critères de validation ; un adjectif esthétique ne suffit pas.
Vérifiez ensuite contraste, hiérarchie, comportement mobile, libellés longs et états d’erreur. Une maquette convaincante ne prouve pas que le code final est accessible ni que les interactions dessinées existent. Une passation aux développeurs doit préciser les comportements et les contraintes, pas seulement montrer une capture.
Le design d’interface n’est pas la génération d’une image. Un écran comporte des composants et des interactions ; une illustration éditoriale est un fichier visuel. Notre guide des outils de génération d’images aide à situer cette autre catégorie. Choisissez selon le livrable nécessaire, non selon le résultat le plus spectaculaire.
Pour un produit existant, préserver sa cohérence peut être plus important que renouveler son apparence. Fournissez les conventions établies et identifiez d’abord les éléments qui doivent changer. Une exploration limitée se vérifie plus facilement qu’une refonte générale sans problème clairement défini.
7. /deep-research : structurer une recherche sans automatiser la vérité
Une recherche approfondie est adaptée à une question nécessitant plusieurs sources et une comparaison réelle. Ce n’est pas le même besoin qu’une définition rapide. Comparer trois services sur leurs tarifs actuels, leurs restrictions, le traitement des données et la disponibilité régionale constitue un exemple pertinent.
La documentation des workflows décrit /deep-research comme une démarche de recherche en arrière-plan utilisant des investigations parallèles et produisant un rapport sourcé. L’outil de recherche web doit être disponible. Le suivi varie selon l’interface ; la CLI dispose notamment de /workflows.
Formuler une demande contrôlable
Délimitez le résultat : « Compare ces trois produits à partir de sources primaires actuelles ; distingue les fonctionnalités disponibles des annonces ; ajoute dates, liens et éléments impossibles à vérifier. » Indiquez les exclusions utiles : pas de prix reconstitués à partir de vieux articles et pas d’hypothèses sur les conditions entreprises sans source.
Contrôlez le rapport au lieu de considérer les citations comme un certificat. Ouvrez les liens décisifs et vérifiez qu’ils soutiennent réellement la conclusion. Un échec d’accès ne démontre pas l’indisponibilité d’un service. Une information non vérifiée doit rester non vérifiée, plutôt que devenir une réponse négative pour remplir un tableau.
Le choix d’un modèle nécessite toujours un essai représentatif. Notre guide de comparaison des modèles rappelle pourquoi les benchmarks et les capacités annoncées doivent être rapprochés du travail réel. La recherche réduit les options, mais ne remplace pas l’évaluation sur vos propres tâches.
Pour une décision importante, conservez les incertitudes avec les conclusions. Un rapport séparant faits, déductions et données manquantes est plus utile qu’un document qui remplit toutes les cases avec assurance. Les lacunes deviennent alors des questions précises à approfondir.
Combiner les sept fonctions de Claude Code dans un projet concret
Imaginons un petit site dont la récupération de compte doit être simplifiée. Ne lancez pas toutes les fonctions simultanément. Définissez d’abord l’objectif : clarifier le parcours sans modifier les règles d’autorisation. Lisez les consignes du projet et cherchez les procédures anciennes éventuellement conservées dans la mémoire.
La recherche externe n’est utile que si une information manque réellement, par exemple les exigences actuelles du fournisseur d’authentification. Si le problème est entièrement dans le code local, une vaste enquête web ajoute du bruit. Demandez une maquette après avoir identifié les contenus et les états du formulaire.
Pendant l’implémentation, utilisez les questions secondaires pour comprendre un terme, mais transmettez les changements de besoin dans la conversation principale. Surveillez la consommation si la mission s’élargit. Le suivi à distance peut aider ; les modifications sensibles doivent tout de même faire l’objet d’une revue complète.
À la fin, demandez les tests pertinents et un résumé concret. Ne conservez en mémoire que les conventions durables. Une mission différente mérite une nouvelle conversation ; la continuation de la même modification exige une passation. Le bénéfice vient de ces frontières, pas du nombre de commandes lancées.
Questions fréquentes et erreurs évitables
Pourquoi une commande n’apparaît-elle pas ?
Vérifiez version, forfait, méthode d’authentification, environnement et réglages de l’organisation. L’interface d’une vidéo peut différer de la vôtre. N’installez pas un plugin inconnu pour reproduire une option déjà intégrée ou simplement indisponible pour votre compte.
La mémoire rend-elle l’assistant fiable à elle seule ?
Non. Elle conserve aussi bien une bonne règle qu’une erreur. Les instructions essentielles doivent être explicites et actuelles. Lorsque le comportement est incorrect, rechercher l’origine de la règle permet de corriger le prochain démarrage plutôt que la seule réponse présente.
Peut-on y enregistrer les identifiants pour gagner du temps ?
Non. Utilisez un mécanisme protégé et accordez uniquement l’accès nécessaire. Les prompts, notes et rapports ne doivent pas devenir des copies de secrets. Mentionner une configuration protégée n’est pas la même chose qu’en recopier la clé.
Un rapport plus long et plus sourcé est-il forcément meilleur ?
Non. Trois sources primaires pertinentes peuvent être plus utiles que vingt pages qui se répètent. La relation entre question, preuve et conclusion importe davantage. Gardez les incertitudes qui influencent la décision plutôt que de les masquer derrière une bibliographie plus longue.
Par quoi commencer ?
Si vous utilisez surtout la conversation, adoptez trois habitudes : mesurer la consommation d’une vraie tâche, entretenir les instructions permanentes et séparer les nouveaux objectifs des anciens échanges. Ajoutez ensuite les questions secondaires, le contrôle distant, le design et la recherche lorsqu’ils répondent à un besoin précis.
Le véritable avantage est un processus maîtrisé. Sachez ce que le système mémorise, quels outils il possède, où le travail s’exécute et quelles réponses nécessitent une vérification. Les sept fonctions deviennent puissantes lorsque ces décisions restent sous votre contrôle.