Automatiser le travail récurrent

Le même prompt que vous lancez à la main chaque lundi matin peut se lancer tout seul, produire un brief concurrentiel et arriver dans votre boîte mail avant que vous ayez fini votre café. L'écart entre une tâche Claude ponctuelle et un pipeline autonome est plus petit qu'il n'y paraît, et cette leçon le comble.

Vous savez déjà obtenir un excellent résultat de Claude une fois. Nous allons maintenant le rendre reproductible, planifié et sûr.

Les trois endroits où vit l'automatisation

L'échelle de l'automatisation compte trois barreaux, et vous les gravissez selon le niveau de contrôle et d'infrastructure que vous souhaitez.

Barreau 1 : dans les applications Claude. Les Projects, Connectors et Skills vous permettent de faire beaucoup sans écrire une ligne de code. Un Connector branche Claude sur un système externe (Gmail, Google Drive, Linear, une base de données) via MCPMCPUn standard ouvert qui permet aux assistants IA de se connecter aux outils et données de l'entreprise de façon cohérente et gouvernée, sans intégration sur mesure à chaque fois.Voir la définition complète →, le Model Context Protocol, le standard ouvert qui permet à un modèle d'appeler des outils et des sources de données externes. C'est le barreau no-code.

Barreau 2 : Claude Code et les agents planifiés. Claude Code peut tourner sans surveillance dans un terminal ou un conteneur. Associez-le à cron (le planificateur de tâches standard d'Unix) et vous obtenez un agent récurrent sur votre propre machine ou un petit serveur.

Barreau 3 : la CI, comme GitHub Actions. Votre automatisation vit dans un repo, tourne sur l'infrastructure d'Anthropic ou de GitHub, dispose de logs et se déclenche sur une planification ou un événement. C'est l'option la plus auditable et la plus « production ».

Nous allons construire le brief du lundi sur le barreau 3, mais je vous montrerai où se placent les barreaux 1 et 2.

Ce que « planifié » veut vraiment dire

Une planification n'est qu'un déclencheur. Le travail lui-même reste un agent Claude classique : un prompt, quelques outils, un appel au modèle. **L'ingrédient nouveau, c'est que *personne ne regarde pendant l'exécution*. Cela change la façon de le concevoir.**

Dans la fenêtre de chat, c'est vous le garde-fou. Vous voyez une mauvaise réponse et vous relancez. Un pipelinepipelineL'ensemble des opportunités commerciales actives réparties selon les étapes du processus de vente, avec leur valeur potentielle cumulée et leur probabilité de conclusion.Voir la définition complète → non surveillé n'a pas d'humain dans cette boucle, les garde-fous doivent donc être écrits dans le pipeline lui-même. Gardez cette idée en tête : elle guide toutes les décisions de conception qui suivent.

La construction concrète : un brief concurrentiel du lundi

Voici l'objectif. Chaque lundi à 7 h, Claude :

1. Récupère les actualités récentes et les pages de pricing de trois concurrents.
2. Les compare au brief de la semaine précédente.
3. Rédige un brief d'une page mettant en avant ce qui a changé.
4. L'envoie par mail à l'équipe, mais seulement après un contrôle de coût et de cohérence.

Étape 1 : faire fonctionner la tâche une fois, à la main

N'automatisez jamais quelque chose que vous n'avez pas d'abord exécuté manuellement. Construisez-la dans une session Claude Code ou un Project jusqu'à ce que le résultat soit réellement bon. C'est votre spec.

Capturez les instructions gagnantes sous forme d'actif réutilisable. Un Skill est un ensemble packagé d'instructions et de ressources que Claude charge à la demande, par exemple un playbook d'analyse concurrentielle avec votre template de brief, vos règles de ton et votre liste de sources. Un Skill rend le même comportement portable de votre session bureau vers la session automatisée.

Étape 2 : choisir le moteur

Pour une tâche planifiée, le Claude Agent SDK (anciennement Claude Code SDK) est l'outil adapté. Il vous donne la boucle d'agent de Claude Code (planification, appels d'outils, modifications de fichiers) sous forme de bibliothèque programmable, si bien que votre exécution planifiée se comporte comme la session interactive que vous avez déjà réglée.

Voici le cœur de la tâche. Il est volontairement réduit : l'intelligence est dans le prompt et le Skill, pas dans le Python.

import os
from claude_agent_sdk import query, ClaudeAgentOptions

async def generate_brief() -> str:
    options = ClaudeAgentOptions(
        system_prompt="You are a competitive intelligence analyst. "
                      "Use the competitive-brief skill. Be concise and cite sources.",
        allowed_tools=["WebFetch", "Read", "Write"],
        permission_mode="acceptEdits",
        max_turns=20,
    )

    prompt = (
        "Generate this week's competitive brief comparing Acme, Globex, and Initech. "
        "Compare against last_week.md. Output a one-page brief to brief.md. "
        "Flag only what materially changed."
    )

    result = []
    async for message in query(prompt=prompt, options=options):
        result.append(message)
    return open("brief.md").read()

Deux choses à noter. allowed_tools est une whitelist : l'agent peut récupérer des pages web, lire et écrire des fichiers, et rien d'autre. max_turns limite la durée de la boucle d'agent. Les deux sont des garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète →, et nous ne faisons que commencer.

Étape 3 : la planifier

Sur votre machine ou votre serveur, cron suffit. Une entrée de crontab, c'est cinq champs de temps plus une commande. Celle-ci lance la tâche chaque lundi à 7 h :

# m h dom mon dow  command
0 7 * * 1  cd /opt/briefs && /usr/bin/python run_brief.py >> brief.log 2>&1

Le 1 du cinquième champ, c'est lundi. La redirection en fin de ligne conserve un log, ce dont vous serez content la première fois que quelque chose cassera à 7 h pendant que vous dormez.

Cron est parfait pour un serveur personnel, mais il meurt quand votre portable se met en veille et il n'offre aucune piste d'audit au-delà d'un fichier texte. Dès qu'une équipe en dépend, passez à la CI.

Étape 4 : la promouvoir dans GitHub Actions

GitHub Actions exécute votre tâche sur planification avec la même syntaxe cron, mais dans un conteneur cloud propre, avec logs, gestion des secrets et historique. L'intégration GitHub officielle de Claude est faite pour ça.

name: weekly-competitive-brief
on:
  schedule:
    - cron: "0 7 * * 1"   # Lundis 07:00 UTC
  workflow_dispatch:        # permet aussi de déclencher une exécution manuelle

jobs:
  brief:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install claude-agent-sdk
      - name: Generate brief
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: python run_brief.py

Votre clé APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → vit dans les secrets chiffrés de GitHub, jamais dans le code. workflow_dispatch est un ajout modeste mais important : il vous permet de lancer le pipeline à la demande pour le tester, au lieu d'attendre lundi.

Les garde-fous qui rendent l'ensemble sûr

C'est la partie que les gens sautent, et c'est celle qui compte. Un agent non surveillé avec une carte de crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →édit et un bouton d'envoi de mail est un risque tant que vous ne l'avez pas contraint.

Plafonds de coût

Fixez un budget strict au niveau du compte dans la Console Anthropic, avec des limites d'usage et des alertes de dépense sur la clé API utilisée par ce pipeline. Donnez à l'automatisation sa propre clé, pour qu'une boucle incontrôlée ne puisse pas vider tout votre budget. Le plafond max_turns du SDK est votre deuxième couche : il borne une exécution unique même si le prompt fait tourner l'agent en rond.

Choisissez aussi le bon modèle pour la tâche. Un brief hebdomadaire n'a pas besoin de votre modèle le plus coûteux pour chaque sous-tâche. Des modèles moins chers pour la récupération et le résumé, un modèle plus fort pour la synthèse finale : le coût reste prévisible.

Une étape de revue avant tout acte irrirrLe taux de rendement interne est le taux d'actualisation qui annule la valeur actuelle nette d'un projet. Il exprime le rendement annualisé attendu d'un investissement.Voir la définition complète →éversible

Envoyer un mail est irréversible. Découpez donc le pipeline : generate tourne sans surveillance, mais send attend un feu vert humain, au moins jusqu'à ce que vous lui fassiez confiance.

Le pattern le plus propre dans GitHub Actions consiste à publier le brief en brouillon comme output et à exiger une approbation manuelle (une environment protection rule) avant l'exécution de l'étape d'envoi. Vous obtenez le mail rédigé automatiquement et un « ship it » en un clic.

Valider la sortie, pas seulement l'exécution

Une tâche qui « réussit » peut très bien produire n'importe quoi. Ajoutez une porte de validation peu coûteuse avant l'étape d'envoi : brief.md existe-t-il, sa longueur est-elle raisonnable, contient-il les noms des trois concurrents, cite-t-il au moins une URL source ? Si un contrôle échoue, on s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →ête et on alerte au lieu d'envoyer des absurdités.

def validate(brief: str) -> None:
    assert 500 < len(brief) < 8000, "brief length looks wrong"
    for name in ("Acme", "Globex", "Initech"):
        assert name in brief, f"missing competitor: {name}"
    assert "http" in brief, "no sources cited"

Ce code est bête à dessein. Les contrôles déterministes attrapent les défaillances qu'une revue par modèle pourrait justifier après coup.

Cadrer les outils au plus juste

Notez que nous n'avons jamais donné à l'agent d'outil « envoyer un mail » dans l'appel au SDK. L'envoi se fait dans un script séparé et bête, *après* approbation. Gardez les actions destructrices ou tournées vers l'extérieur hors de la liste d'outils de l'agent, dans du code simple que vous contrôlez. L'agent écrit un fichier ; votre pipeline décide quoi en faire.

Où se place le barreau no-code

Vous n'avez pas toujours besoin d'un repo. Si votre tâche récurrente est « résumer les issues Linear de la semaine dans un post Slack », un Connector plus un déclencheur planifié dans un outil d'automatisation peuvent suffire, sans une ligne de Python. La marketplace de connectors grandit vite : vérifiez si votre source de données en a déjà un avant de construire un serveur MCP sur mesure.

La règle de décision : restez en no-code tant que la tâche est simple et le rayon d'impact réduit. Passez au SDK et à la CI quand vous avez besoin de versioning, de vrais logs, de contrôles de coût et de portes de revue. Le brief du lundi est pile sur la frontière, et c'est pour ça qu'il fait un bon exemple pédagogique.

L'idempotence : l'exigence discrète

Un dernier concept sépare le jouet du pipeline. L'idempotence signifie qu'exécuter la tâche deux fois produit un résultat correct, pas deux pagailles. Si GitHub relance une exécution, ou si vous la déclenchez manuellement pour tester, vous ne voulez pas deux mails ni un fichier d'historique corrompu.

Rendez l'exécution répétable sans risque : écrivez dans un fichier daté (brief-2026-01-19.md), vérifiez si le brief de la semaine existe déjà avant d'envoyer, et traitez « déjà fait » comme un succès. Peu coûteux à ajouter, pénible à rattraper le jour où vous recevez deux briefs et où l'équipe ne comprend plus rien.

Points clés

• Faites-le fonctionner à la main d'abord, puis planifiez-le. Votre session Claude Code ou votre Project réglé constitue la spec ; packagez le comportement gagnant en Skill pour qu'il se transpose proprement dans l'exécution automatisée.
• Adaptez le barreau à l'enjeu. Connectors et application pour les tâches simples et peu risquées ; Claude Agent SDK plus cron pour les tâches personnelles ; GitHub Actions quand une équipe dépend des logs, des secrets et de l'historique.
• Écrivez les garde-fous dans le pipeline, parce qu'aucun humain ne regarde. Utilisez une clé API dédiée avec des limites d'usage, plafonnez max_turns, mettez les outils en whitelist et lancez une validation déterministe avant toute action irréversible.
• Gardez les actions irréversibles hors de l'agent. Laissez Claude générer le fichier ; laissez du code simple, conditionné à une approbation humaine, faire l'envoi.
• Rendez chaque exécution idempotente. Des sorties datées et des contrôles « déjà fait » garantissent qu'une reprise ou un test ne produit jamais de mails en double ni d'état corrompu.