Capstone : un vrai workflow Claude de bout en bout

Vous allez construire un assistant research-to-report qui se réveille chaque lundi, récupère des données fraîches depuis vos sources en production, rédige un rapport structuré dans la voix de votre maison et le dépose là où votre équipe travaille déjà. Pas de copier-coller, pas de fenêtre de chat à surveiller. Cette leçon porte sur les décisions d'architecture, pas sur les frappes clavier, pour que vous puissiez y substituer votre propre domaine (competitive intelligence, métriques hebdomadaires, veille réglementaire) sans rien réécrire.

Nous allons l'assembler à partir des briques que vous connaissez déjà : Projects, Connectors, 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 →, Claude Code, l'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 → Messages et un scheduler. **La compétence ici, c'est de choisir la *bonne* brique pour chaque tâche.**

Le workflow, de bout en bout

Voici la forme de ce que nous construisons :

1. Le contexte vit dans un Project pour que chaque exécution démarre avec le même background, les mêmes sources et les mêmes instructions.
2. Les données live arrivent via des Connectors ou un serveur MCP custom, pas via un copier-coller périmé.
3. Le gros du travail (raisonnement multi-étapes, génération de fichiers) passe par Claude Code ou l'API Messages.
4. La voix et le format sont imposés par un Style et une Skill réutilisable.
5. Un scheduler déclenche l'ensemble pour que ça tourne sans vous.

L'erreur la plus courante consiste à écraser ces cinq couches dans un seul prompt géant. Gardez-les séparées. Chaque couche a son propre rythme de changement : votre contexte évolue lentement, vos données changent quotidiennement, votre formatage ne bouge presque jamais. C'est cette séparation qui rend l'ensemble maintenable.

Couche 1 : le Project comme colonne vertébrale du contexte

Commencez dans l'app Claude et 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 →éez un Project pour cet assistant. Un Project est un espace de travail qui embarque des instructions persistantes et une base de connaissances de fichiers dans chaque conversation qu'il contient.

Mettez trois choses dans les instructions personnalisées du Project :

• La mission : « Vous produisez un rapport hebdomadaire de competitive intelligence sur le marché de la recharge de véhicules électriques. »
• L'audience et les contraintes : qui le lit, quelle longueur, ce qu'il ne faut jamais inclure.
• Le contrat de sortie : les intitulés de sections exacts que le rapport doit toujours comporter.

Chargez vos fichiers de référence dans la knowledge du Project : les rapports du trimestre précédent, votre taxonomie de concurrents, un glossaire. C'est le contexte à évolution lente. Vous le définissez une fois et il ancre chaque exécution.

Pourquoi un Project plutôt qu'un simple system promptsystem promptLes instructions cachées qui définissent le comportement d'un assistant IA avant toute question : son rôle, son ton, ses limites et ses règles.Voir la définition complète → dans l'API ? Parce que vous voulez aussi une surface utilisable par un humain. Quand l'exécution planifiée produit quelque chose d'étrange, vous ouvrez le Project, posez des questions de suivi sur le même contexte et déboguez de façon interactive. Le Project et l'automatisation partagent le même cerveau.

Consultez les capacités actuelles dans la documentation Projects.

Couche 2 : données live via Connectors et MCP

Un rapport ne vaut que par la fraîcheur de ses inputs. C'est là que MCP (Model Context Protocol) prend tout son sens. MCP est un standard ouvert qui permet à Claude de dialoguer avec des outils et sources de données externes via une interface uniforme, ce qui vous évite de bricoler une intégration sur mesure pour chaque source.

Vous avez deux voies :

Les Connectors sont des intégrations MCP prêtes à l'emploi que vous activez depuis l'annuaire de connecteurs dans les apps Claude : Google Drive, recherche web et une marketplace croissante de services tiers. Si vos données vivent déjà quelque part avec un connecteur officiel, utilisez-le. Zéro code.

Un serveur MCP custom, c'est ce que vous construisez quand vos données vivent dans un système spécifique : une base de pricing interne, une API partenaire, 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 → de scraping. Vous exposez cette source sous forme d'un petit serveur qui parle MCP, et Claude peut alors l'appeler comme n'importe quel autre outil.

Pour notre rapport VE, admettons qu'il nous faille des chiffres live de déploiement de bornes depuis une API interne. Un outil minimal de serveur MCP ressemble à ceci :

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("ev-data")

@mcp.tool()
async def get_deployments(region: str, since_days: int = 7) -> dict:
    """Fetch new charger deployments for a region in the last N days."""
    url = f"https://internal.example.com/deployments"
    params = {"region": region, "since_days": since_days}
    async with httpx.AsyncClient() as client:
        resp = await client.get(url, params=params, timeout=30)
        resp.raise_for_status()
        return resp.json()

if __name__ == "__main__":
    mcp.run()

Voilà tout le pattern. Une fonction décorée devient un outil que Claude peut invoquer par son nom, la docstring servant de description que le modèle lit pour décider quand l'appeler. Écrivez des docstrings serrées : ce sont des surfaces de prompt, pas de simples commentaires.

Commencez par modelcontextprotocol.io pour la spec et les SDK.

Règle de décision : cherchez d'abord un Connector. Ne construisez un serveur MCP custom que si aucun connecteur n'existe ou si votre source est privée. Ne construisez pas ce que vous pouvez activer.

Couche 3 : le moteur, Claude Code vs l'API

Maintenant le gros du travail : lire les données, raisonner à travers les sources, écrire le rapport, sauvegarder un fichier. Vous avez deux moteurs, et le choix compte.

Claude Code est l'outil de coding agentique d'Anthropic qui tourne dans votre terminal. Il ne sert pas qu'à écrire du logiciel. Il peut lire et écrire des fichiers dans un répertoire de travail, exécuter des commandes et appeler vos serveurs MCP, ce qui en fait un runner de *workflow* capable. Pour notre rapport, Claude Code peut récupérer les données, synthétiser et écrire report-2026-W12.md sur le disque en une seule boucle agentique.

L'API Messages (ou le Claude Agent SDK par-dessus) est ce que vous utilisez quand vous voulez embarquer tout ça dans votre propre service : une app web, une Lambda, un pipeline de donnéespipeline de donnéesSéquence automatisée d'étapes qui déplace les données de la source vers la destination : ingestion, transformation, validation et chargement, pour qu'elles arrivent propres et prêtes à l'emploi.Voir la définition complète → existant. Plus de contrôle, plus de code.

Pour un capstone que vous faites tourner pour vous-même ou une petite équipe, Claude Code est la voie la plus rapide. Il gère déjà la boucle agentique, les I/O fichiers et les appels d'outils. Vous configurez vos serveurs MCP une fois dans ses settings et vous le pointez sur un prompt.

Voici la config MCP au niveau projet que Claude Code lit :

{
  "mcpServers": {
    "ev-data": {
      "command": "python",
      "args": ["./servers/ev_data.py"]
    }
  }
}

Avec ça en place, une seule instruction du type « Génère le rapport de cette semaine en utilisant l'outil ev-data pour les régions West et Northeast, respecte le contrat de sections du Project, et sauvegarde-le en markdown daté » exécute toute la chaîne.

L'Agent SDK devient le bon choix plus tard, quand vous voudrez faire tourner ça en headless dans une infrastructure de production avec votre propre logique de retry, votre logging et vos 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 →. À parcourir sur github.com/anthropics.

🎬 [VIDEO: "Building Agents with Claude Code and MCP" - youtube.com/results?search_query=claude+code+mcp+agents - une démonstration du branchement de serveurs MCP dans Claude Code pour des workflows automatisés multi-étapes]

Couche 4 : voix et structure avec les Styles et les Skills

Votre rapport ne peut pas sonner comme de la prose IA générique. Deux fonctionnalités règlent ça.

Les Styles contrôlent le ton et les conventions d'écriture. Créez un Style personnalisé entraîné sur quelques-uns de vos rapports passés pour que la sortie corresponde à la voix de votre maison : sec, sans précautions oratoires, orienté puces. Le Style voyage avec le Project.

Les Skills sont des instructions packagées et réutilisables, plus d'éventuelles ressources, que Claude charge quand c'est pertinent. Pour notre rapport, construisez une Skill qui encode la *procédure de génération du rapport* : comment pondérer les sources, comment signaler les affirmations peu fiables, le format de tableau exact pour les chiffres de déploiement. Une Skill est plus durable que d'entasser tout ça dans un seul prompt, et vous pouvez la versionner.

La répartition est nette : **le Style gouverne *le son*, la Skill gouverne *la fabricationfabricationUne hallucination, c'est lorsqu'un modèle d'IA produit une réponse fluide et assurée mais factuellement fausse, inventée, ou non étayée par ses données sources.Voir la définition complète →***. Gardez la logique de formatage hors de votre couche de données et hors de votre moteur. Quand votre patron demande une nouvelle section le trimestre prochain, vous éditez la Skill, rien d'autre.

Couche 5 : le scheduler

Un assistant qu'il faut lancer à la main n'est pas de l'automatisation. Il vous faut un déclencheur.

Claude Code s'exécute comme une commande, donc le scheduler n'est rien d'autre que votre système d'exploitation ou votre CI. L'approche la plus propre est un job cron (un scheduler Unix qui lance une commande selon un motif temporel) ou un workflow GitHub Actions.

Une entrée cron pour chaque lundi à 7h :

0 7 * * 1 cd ~/ev-report && claude -p "Generate this week's report using the prompt in run.md" >> run.log 2>&1

Le flag -p lance Claude Code en mode non interactif (« print ») : il exécute le prompt, fait son travail agentique et sort. C'est ce qui le rend scriptable. Votre run.md contient l'instruction permanente pour que la ligne de cron reste stable.

Pour une équipe, poussez plutôt ça dans GitHub Actions. Un workflow planifié exécute la même commande sur des runners hébergés par Anthropic ou les vôtres, commite le rapport généré dans le repo, et l'intégration GitHub permet au modèle d'ouvrir une pull request avec le brouillon pour relecture humaine avant toute publication. Cette étape de relecture compte : vous voulez qu'une personne approuve le rapport, pas qu'un robot publie des affirmations non lues à des parties prenantes.

Assembler les coutures

Prenez du recul et observez comment les couches se passent le relais :

• Le Project détient le contexte lent et vous donne une surface humaine de débogage.
• MCP/Connectors injectent des données fraîches via une interface uniforme.
• Claude Code orchestre la boucle agentique et écrit les fichiers.
• Styles + Skills imposent la voix et la structure de façon indépendante.
• Cron ou GitHub Actions déclenche à l'heure dite, avec une validation humaine.

Chaque couture est un endroit où vous pouvez remplacer une pièce sans toucher au reste. Changer de sources de données ? Nouveau serveur MCP, même moteur. Passer le moteur à l'Agent SDK pour la production ? Même config MCP, même Skill. C'est la vraie leçon de ce capstone : les bons workflows IA sont *composés de pièces remplaçables*, pas de prompts monolithiques.

Une note sur les modes de défaillance

Deux choses casseront en premier, alors anticipez-les dès maintenant.

Données périmées ou vides. Votre outil MCP doit renvoyer un signal clair quand une source est hors service, et votre Skill doit demander à Claude de signaler un rapport dégradé plutôt que d'halluciner autour des chiffres manquants. Un rapport qui dit « données de déploiement indisponibles cette semaine » est correct. Un rapport qui invente des chiffres est dangereux.

Dérive silencieuse. Planifiez chaque mois une lecture humaine d'une sortie complète, de bout en bout. L'automatisation masque la dégradation lente. La surface Project est exactement l'endroit où mener cet audit, parce qu'elle partage le contexte avec l'exécution automatisée.

À retenir

• Séparez les cinq couches (contexte, données, moteur, formatage, scheduler) selon leur rythme de changement. Le contexte lent va dans un Project, les données quotidiennes passent par MCP, le formatage durable va dans une Skill.
• Activez un Connector avant de construire un serveur MCP. Ne codez un serveur à la main que pour des sources privées ou spécifiques, et écrivez des docstrings d'outils serrées, car Claude les lit comme du prompt.
• Utilisez Claude Code avec -p pour le capstone, et ne passez au Claude Agent SDK que lorsque vous avez besoin d'un contrôle headless en production.
• Conservez une validation humaine. Faites en sorte que l'intégration GitHub ouvre une pull request avec le brouillon, pour qu'une personne valide avant que les parties prenantes ne le voient.
• Concevez pour l'échec : rendez explicites les données manquantes, et planifiez un audit humain périodique via le Project partagé pour détecter la dérive silencieuse.