Routines Claude Code : 6 cas d'usage à tester dès maintenant

Avec les routines, Claude Code peut désormais travailler à votre place la nuit, en autonomie, sur votre code, vos fichiers et votre machine.

Bien utilisées, les routines dans Claude Code permettent de gagner un temps précieux. Lancées mi-avril par Anthropic, elles permettent d'automatiser les tâches répétitives de votre workflow. Comment configurer une routine ? Quels sont les meilleurs cas d'usage ? On fait le point.

Comment configurer une routine Claude Code ?

La manière la plus simple de configurer une routine est de passer par l'interface graphique de Claude : ouvrez-la, cliquez sur "Code" puis sur "Routines". Une routine Claude Code se compose d'un prompt, d'un déclencheur et d'un ou plusieurs connecteurs. Elle s'exécute prioritairement dans le cloud, mais peut aussi tourner en local sur votre machine, à condition que celle-ci soit allumée. En mode cloud, Claude utilise votre dépôt GitHub comme espace de travail ; en local, vous devrez lui indiquer un dossier cible.

Cliquez sur "Nouvelle routine", puis choisissez "Local" pour une exécution sur votre ordinateur, ou "A distance" pour une exécution dans le cloud. Pour un tri automatique de dossiers, optez pour "Local" ; pour une revue de code automatisée, préférez "A distance". Un configurateur graphique s'ouvre alors : renseignez le nom, la description de votre routine, et le prompt à utiliser, simple mais précis, comme vous l'auriez formulé directement dans Claude Code.

En mode cloud, vous devrez ensuite définir le type de déclencheur : une heure fixe dans la journée, un événement GitHub (par exemple l'ouverture d'une PR) ou un appel API depuis votre application. Les connecteurs habituels sont disponibles et peuvent être conservés ou supprimés selon votre cas d'usage. Attention, Claude utilise ces outils en autonomie, sans vous demander de confirmation à chaque action. Veillez donc à ne pas lui laisser accès à des connecteurs sensibles. Une routine peut par exemple scanner vos mails chaque matin avant votre réveil et les classifier automatiquement.

En local, le principe est identique, à deux différences près : le seul déclencheur disponible est l'horaire, et les connecteurs sont absents, Claude Code travaille uniquement avec ses propres outils.

A noter: la création de routines est limitée à 5 par jour avec un compte Pro, 15 avec un compte Max, et 25 avec une offre Team ou Enterprise. Les tokens consommés sont déduits de votre quota habituel, comme n'importe quel usage classique de Claude Code.

Voyons à présent quelques cas d'usage concrets pour tirer le meilleur parti des routines : trois scénarios dans le cloud, trois en local.

Dans le cloud

Une revue de code poussée chaque nuit

C'est sans doute le cas d'usage le plus utile pour un développeur : une revue de code automatisée et approfondie, doublée d'un audit de sécurité. Planifiée chaque nuit, la routine analyse l'ensemble de la base de code pendant que l'équipe dort et que la limite d’usage de tokens est plus large, et soumet une Pull Request au matin avec ses corrections classées par criticité.

Prompt à utiliser :

“Tu es un expert senior en revue de code et en audit de sécurité applicative, avec une spécialisation en OWASP Top 10, CWE et bonnes pratiques DevSecOps. Ta mission est de réaliser une revue complète de l'ensemble de cette base de code en couvrant trois axes. Premier axe, la qualité du code : lisibilité, complexité cyclomatique, duplication, respect des conventions du langage utilisé, gestion des erreurs, couverture de tests et dette technique. Deuxième axe, la documentation : présence et pertinence des docstrings, commentaires sur la logique métier complexe, README à jour, cohérence entre le code et la documentation existante. Troisième axe, la sécurité : injections (SQL, commandes, XSS), gestion des secrets et variables d'environnement, dépendances vulnérables, authentification et autorisation, validation des entrées utilisateur, exposition de données sensibles dans les logs, configuration CORS, chiffrement des données au repos et en transit. Pour chaque problème identifié, indique le fichier et le numéro de ligne concernés, classe la criticité (critique, élevée, moyenne, faible), explique brièvement le risque ou l'impact, et propose une correction concrète. Une fois l'analyse terminée, applique directement les corrections dans le code en créant une nouvelle branche nommée claude-code/audit-{date}, puis ouvre une Pull Request avec un récapitulatif structuré des modifications, en groupant les changements par catégorie (qualité, documentation, sécurité) et par criticité. Si tu rencontres une partie du code dont tu ne comprends pas l'intention métier, signale-le dans la PR plutôt que d'inventer une correction : il vaut mieux flaguer un faux positif que de casser une logique fonctionnelle.”

La correction automatique des bugs

C'est probablement le cas d'usage le plus productif au quotidien. Qui ne rêve pas d'un agent capable de traiter en autonomie les tickets de bugs ouverts sur Jira ou équivalent ? Claude Code peut désormais s'en charger : il suffit de connecter votre outil de ticketing via MCP et de lui fournir des instructions de correction claires. L'agent priorise les tickets, identifie les bugs dans le code, applique les corrections et ouvre une PR.

Prompt :

"Tu es un expert senior en debugging et en résolution d'incidents logiciels, avec une solide expérience en analyse de root cause et en correction non régressive. Ta mission est de traiter automatiquement les bugs remontés dans le système de ticketing connecté (Jira, Linear, GitHub Issues ou équivalent selon le connecteur MCP disponible). Commence par récupérer la liste complète des tickets ouverts avec le label bug, incident ou équivalent, et qui ne sont pas déjà assignés ou en cours de traitement par un humain. Identifie ensuite les 5 bugs les plus prioritaires en croisant trois critères : la sévérité déclarée dans le ticket (critique, majeure, mineure), la fraîcheur du report (un bug récent sur une feature en production prime sur un bug ancien sur une feature legacy), et le périmètre fonctionnel touché (un bug qui bloque un parcours utilisateur critique comme l'authentification ou le paiement passe avant un bug d'affichage). Pour chacun de ces 5 bugs, analyse en profondeur le code concerné en remontant la stack trace ou la description du comportement, identifie la root cause précise (pas seulement le symptôme), puis propose une correction qui traite la cause et non le symptôme. Avant d'appliquer la correction, vérifie qu'elle ne casse pas de tests existants et, si la zone de code n'est pas couverte par des tests, ajoute un test unitaire ou d'intégration qui reproduit le bug et valide la correction. Crée une branche par bug, nommée claude-code/fix-{ticket-id}, et soumet une Pull Request distincte pour chaque correction afin de faciliter la revue humaine et le rollback éventuel. Dans chaque PR, structure la description ainsi : référence au ticket d'origine, description du bug observé, root cause identifiée, correction apportée, tests ajoutés ou modifiés, et risques résiduels éventuels. Si un bug semble nécessiter une décision produit (changement de comportement métier, refonte d'une feature, arbitrage UX), ne le corrige pas : ajoute un commentaire détaillé sur le ticket Jira pour expliquer pourquoi une intervention humaine est requise et passe au bug suivant dans la liste de priorité. Ne ferme jamais un ticket toi-même : laisse cette action à l'équipe après validation de la PR.“

Une veille technologique poussée

C'est un cas d'usage d'un genre différent. Claude Code peut réaliser une veille technologique ciblée sur les projets open source susceptibles d'enrichir votre application : il analyse votre stack, identifie les outils pertinents puis les teste directement dans un environnement isolé. Enfin, vous récupérez au matin un rapport structuré avec une recommandation claire pour chaque projet testé.

Prompt : 

“Tu es un expert en veille technologique et en évaluation de logiciels open source, avec une double compétence d'architecte logiciel et d'analyste produit. Ta mission se déroule en quatre phases. Phase 1, analyse du contexte : explore la base de code pour identifier le stack technique utilisé (langages, frameworks, librairies principales, base de données, infrastructure), les enjeux fonctionnels de l'application (lis le README, les fichiers de documentation, les noms des modules principaux et les dépendances pour reconstituer le domaine métier), et les points de friction ou les zones où des outils tiers pourraient apporter de la valeur (performances, observabilité, sécurité, DX, automatisation de tests, gestion de la donnée, etc.). Phase 2, veille ciblée : effectue une recherche sur GitHub des projets open source pertinents publiés ou significativement mis à jour au cours des trois derniers mois, en te concentrant sur ceux qui dépassent 500 étoiles ou qui montrent une croissance rapide (plus de 100 étoiles par semaine), et qui sont compatibles avec notre stack identifié en phase 1. Ecarte les projets non maintenus (dernier commit datant de plus de 6 mois), les forks sans valeur ajoutée et les projets dont la licence est incompatible avec un usage commercial (AGPL, SSPL, BSL si tu ne peux pas confirmer la compatibilité avec notre modèle d'usage). Phase 3, sélection et test : choisis entre 3 et 5 projets parmi les plus pertinents, en privilégiant la diversité des cas d'usage couverts plutôt que cinq variantes d'un même outil. Pour chacun, crée un dossier d'évaluation dans un répertoire dédié /tech-watch/{date}/{nom-du-projet}, installe le projet en suivant sa documentation officielle, configure une intégration minimale viable avec un cas d'usage représentatif de notre base de code (sans toucher au code de production : crée un sandbox isolé), et exécute au moins trois scénarios de test couvrant un cas nominal, un cas limite et un cas d'échec. Phase 4, rapport final : rédige un rapport structuré au format Markdown dans /tech-watch/{date}/rapport.md contenant pour chaque projet évalué les éléments suivants : nom et lien GitHub, description en deux phrases, métriques d'adoption (étoiles, contributeurs actifs, fréquence des releases, date du dernier commit), licence et compatibilité avec notre usage, problème que le projet résoudrait dans notre contexte spécifique (cite les fichiers ou modules concernés), résultat des tests réalisés avec captures de logs ou outputs pertinents, effort d'intégration estimé (heures de dev, impact sur le bundle, dépendances ajoutées), risques identifiés (maturité, gouvernance du projet, lock-in, performance), et recommandation finale parmi trois options : adopter rapidement, garder en watch pour réévaluation dans 3 mois, écarter. Termine le rapport par un tableau de synthèse comparatif et un classement des projets par ratio valeur/effort d'intégration. Si aucun projet réellement pertinent n'émerge de ta veille, dis-le explicitement plutôt que de remplir le rapport avec des choix médiocres : un rapport vide et honnête vaut mieux qu'un rapport rempli de bruit.”.

En local

Le tri automatique des dossiers et fichiers

C'est un cas transversal, utile bien au-delà du développement. Le tri automatique de vos fichiers (téléchargements, bureau, documents…) permet d'attaquer chaque journée sur une session propre et organisé.

Prompt :

“Tu es expert en organisation de fichiers, approche strictement conservatrice : aucune suppression, jamais. Trie les dossiers Téléchargements, Bureau et Documents de cet ordinateur. Archive dans /Archives/{année}/{mois}/ tout fichier non modifié depuis plus de 180 jours. Regroupe les fichiers actifs restants par type dans des sous-dossiers thématiques (PDF, Bureautique, Images, Vidéos, Audio, Code, Installateurs), en réutilisant les dossiers existants au nom proche plutôt que d'en créer en parallèle. Détecte les doublons par hash de contenu, garde la version la mieux rangée, déplace les autres vers /Archives/Doublons/{date}/. Renomme uniquement les fichiers au nom générique (IMG_1234, scan001) si tu peux inférer un nom fiable depuis les métadonnées ou le contexte, sinon laisse tel quel. Ne touche jamais aux dossiers système, cachés, dépôts Git, projets de dev (présence d'un package.json, pyproject.toml, Cargo.toml), ni aux dossiers contenant un fichier .noclaude. Journalise chaque action dans /Archives/journal-tri-{date}.md au format action / source / destination / raison, pour permettre une réversion manuelle. En cas d'erreur bloquante, arrête immédiatement et produis un rapport.”

Un audit cyber hebdomadaire

A l'heure où les cybermenaces se multiplient, réaliser un audit de sécurité régulier sur votre machine peut faire la différence entre détecter une anomalie à temps ou la découvrir trop tard. Claude Code peut s'en charger automatiquement. Une exécution une fois par semaine est raisonnable pour la plupart des usages.

Prompt :

“Tu es expert en audit de sécurité endpoint sur Windows, macOS et Linux. Identifie d'abord l'OS, sa version et le profil d'usage de la machine. Réalise ensuite un audit couvrant huit axes : état des mises à jour (OS, navigateurs, apps critiques), configuration de sécurité native (pare-feu, chiffrement disque, Gatekeeper/Defender), comptes et authentification (admin, politique de mot de passe, 2FA), applications et processus suspects (logiciels non signés, extensions douteuses, lancements automatiques), exposition réseau (ports ouverts, partages, services exposés), données sensibles exposées (fichiers .env, clés SSH sans passphrase, patterns de clés API, permissions trop larges), sauvegardes (présence, fraîcheur, isolation pour résister au ransomware), et traces d'incident (logs de connexion échouées, modifications inhabituelles, outils d'admin à distance). Classe chaque finding en quatre niveaux : critique, élevé, moyen, informationnel. Contraintes absolues : n'exécute aucune commande qui modifierait l'état du système, ne cherche pas à élever tes privilèges si une vérification les requiert (mentionne-le simplement dans le rapport), et ne lis jamais le contenu de fichiers personnels, uniquement leurs métadonnées et permissions. Rédige le rapport dans /Documents/audits-cyber/rapport-{date}.md avec un résumé exécutif et un score de posture sur 100, puis 10 recommandations priorisées indiquant pour chacune : le problème, l'impact, la commande ou procédure exacte de correction, et le temps estimé. Si certaines vérifications n'aboutissent pas, liste-les honnêtement plutôt que de masquer les angles morts.”

Transcription automatique des enregistrements audio

Vous enregistrez des réunions ou des notes vocales sur votre ordinateur, mais vous oubliez régulièrement de les transcrire ? Claude Code peut s'en charger. La routine détecte chaque nuit les nouveaux fichiers audio et les transcrit via Whisper, avec un modèle adapté à la configuration hardware de votre ordinateur.

Prompt : 

“Tu es expert en transcription audio automatisée avec Whisper. Identifie d'abord la configuration matérielle de la machine (OS, RAM disponible, présence et type de GPU) afin de choisir un modèle Whisper adapté : tiny ou base pour une machine modeste sans GPU (moins de 8 Go de RAM exploitable), small ou medium pour une configuration standard, large-v3 ou turbo si un GPU dédié avec au moins 8 Go de VRAM est disponible. Privilégie l'implémentation faster-whisper pour ses performances supérieures à OpenAI Whisper en CPU, ou whisper.cpp si l'environnement le permet. Si Whisper n'est pas installé, installe-le via pip dans un environnement virtuel dédié (/.venv-whisper) sans polluer l'environnement système. Scanne le dossier cible {chemin-dossier-audio} et identifie tous les fichiers audio supportés (mp3, wav, m4a, flac, ogg, opus, mp4 pour la piste audio). Pour chacun, détecte automatiquement la langue parlée plutôt que de la présupposer, sauf si un fichier .lang situé à côté du fichier audio force une langue spécifique. Transcris chaque fichier et produis pour chacun un fichier .md du même nom à côté de l'audio, contenant : métadonnées (date du fichier, durée, langue détectée, modèle utilisé), transcription complète avec horodatages toutes les 30 secondes au format [hh:mm:ss], et résumé exécutif en 5 lignes en tête du document. Ne retranscris jamais un fichier qui dispose déjà d'un .md associé daté postérieurement à l'audio (évite le travail en double sur les exécutions successives de la routine). Stocke les transcriptions volumineuses (plus de 30 minutes d'audio) dans un sous-dossier /Transcriptions/ pour ne pas polluer le dossier source. Journalise dans /Transcriptions/journal-{date}.md la liste des fichiers traités, ignorés et échoués avec la raison. Si un fichier échoue (corruption, format non supporté, mémoire insuffisante), passe au suivant plutôt que d'arrêter la routine.”