# Alejandro Rioja — FR > Alejandro Rioja — AI agent systems for founders. Plus posts on growth, marketing, sales, ops, and business from inside live P&Ls. Site: https://alejandrorioja.com/fr/ Author: Alejandro Rioja Language: fr --- ## Premières impressions sur Claude Fable 5 : le point de vue d'un opérateur Source: https://alejandrorioja.com/fr/claude-fable-5-first-impressions/ Published: 2026-06-12 Updated: 2026-06-12 Tags: AI Agents TL;DR: Fable 5 est le modèle le plus performant d'Anthropic, et cela se voit sur les tâches d'agent difficiles et de longue haleine, mais ce n'est pas la mise à niveau par défaut. Il coûte plus cher par token, utilise un nouveau tokenizer qui gonfle vos décomptes de tokens d'environ 30 %, exécute un raisonnement toujours actif que vous ne pouvez pas désactiver, et peut refuser des requêtes au niveau du classifieur. Pour la plupart des charges de travail, Opus 4.8 reste le bon choix. Réservez Fable 5 aux tâches réellement difficiles. ## Table des matières _Mis à jour en juin 2026._ **TL;DR :** Fable 5 est le modèle le plus performant d'Anthropic, et cela se voit sur les tâches d'agent difficiles et de longue haleine, mais ce n'est pas la mise à niveau par défaut. Il coûte plus cher par token, utilise un nouveau tokenizer qui gonfle vos décomptes de tokens d'environ 30 %, exécute un raisonnement toujours actif que vous ne pouvez pas désactiver, et peut refuser des requêtes au niveau du classifieur. Pour la plupart des charges de travail, Opus 4.8 reste le bon choix. Réservez Fable 5 aux tâches réellement difficiles. **[Le point de vue de l'opérateur]** J'exploite plus de 30 agents en production, répartis entre une marque de conseil et un complexe de pickleball. Un nouveau modèle phare n'est donc pas un benchmark pour moi : c'est une ligne de dépense et une migration. Voici ce qui a changé quand j'ai réellement branché Fable 5 sur quelques-uns d'entre eux, et là où j'ai laissé Opus 4.8 en place. ## Ce qu'est réellement Fable 5 [Claude](/recommends/claude) Fable 5 est le modèle le plus performant qu'Anthropic ait déployé à grande échelle. Il vise le haut du spectre des exigences : raisonnement approfondi et travail agentique de longue haleine, ces exécutions où un agent doit garder le fil d'un plan sur des dizaines d'appels d'outils sans le perdre. La surface de l'API est presque identique à celle d'Opus 4.7/4.8, ce qui a facilité les tests. Fenêtre de contexte de 1M de tokens par défaut, jusqu'à 128K tokens de sortie par requête. Si vous avez construit quoi que ce soit sur la récente lignée Opus, la forme des requêtes vous sera familière. Les différences sont dans les détails, et c'est dans les détails que se cachent l'argent et les surprises. Une précision sur la nomenclature pour éviter toute confusion : **Mythos 5** est le même modèle (mêmes capacités, même tarification, même comportement), disponible uniquement via le programme Project Glasswing d'Anthropic. Si vous n'êtes pas dans ce programme, le modèle qu'il vous faut est `claude-fable-5`. Tout ce qui suit s'applique aux deux. ## Là où il est réellement meilleur Je lui ai d'abord soumis ma tâche d'agent la plus difficile : une exécution de recherche et de synthèse en plusieurs étapes qui lit une pile de sources, recoupe les affirmations et rédige une note avec citations. C'est le genre de travail où les modèles plus faibles dérivent : ils perdent la trace de quelle affirmation venait de quelle source au bout d'une dizaine d'appels d'outils. Fable 5 a gardé le fil. La synthèse était plus serrée, les citations sont restées rattachées aux bonnes affirmations, et il a repéré deux contradictions entre sources que ma version Opus 4.8 lissait discrètement. Sur le raisonnement long et structuré, c'est un vrai bond en avant, pas une amélioration marginale de benchmark. C'est l'argument honnête en sa faveur. Si le mode d'échec de votre agent est « il s'effondre sur les 10 % les plus difficiles », Fable 5 réduit cet écart. Si votre agent résume des newsletters ou rédige des publications pour les réseaux sociaux, vous ne sentirez pas la différence, et vous paierez pour une capacité que vous n'utilisez pas. ## Le piège des coûts dont personne ne vous prévient Voici celui qui vous mordra si vous survolez les notes de version. Fable 5 est livré avec un **nouveau tokenizer**, et le même contenu se tokenise en environ **30 % de tokens en plus** par rapport à la lignée Opus. Relisez bien, car cela se cumule avec le prix. Fable 5 est déjà tarifé au-dessus du palier Opus (10 $ par million de tokens en entrée, 50 $ par million en sortie). Ajoutez maintenant une inflation des tokens d'environ 30 % par-dessus chaque prompt et chaque complétion. Une charge de travail inchangée — mêmes prompts, mêmes sorties — peut coûter sensiblement plus cher après migration, avant même d'avoir modifié quoi que ce soit à ce que fait l'agent. Alors ne réutilisez pas vos anciens chiffres. Vos réglages `max_tokens`, vos budgets de fenêtre de contexte, vos estimations de coût par exécution : tous ont été mesurés sur un tokenizer différent. Bonne nouvelle : l'endpoint de comptage de tokens renvoie les décomptes sous les **deux** tokenizers lorsque vous passez `model: "claude-fable-5"`, ce qui vous permet de mesurer l'écart sur vos prompts réels avant de basculer quoi que ce soit. ```bash # Measure the tokenizer delta on YOUR prompt before migrating. # The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old). curl https://api.anthropic.com/v1/messages/count_tokens \ -H "x-api-key: $ANTHROPIC_API_KEY" \ -H "anthropic-version: 2023-06-01" \ -H "content-type: application/json" \ -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":""}] }' ``` J'ai d'abord lancé cette commande sur mes prompts les plus lourds. L'écart n'était pas uniforme — il varie selon le contenu — mais « prévoyez environ 30 % de plus, puis ajoutez la prime de prix » était le bon modèle mental. ## Le raisonnement est toujours actif, et vous ne pouvez pas le désactiver Sur Fable 5, le raisonnement adaptatif tourne en permanence. Le seul nouveau changement cassant par rapport à la lignée Opus : si vous envoyez un `thinking: {type: "disabled"}` explicite, vous obtenez une 400. Le correctif est simple — il suffit d'omettre entièrement le paramètre `thinking` — mais si vous aviez du code qui désactivait explicitement le raisonnement pour des appels bon marché et rapides, ce code génère désormais une erreur. Vous ne récupérez pas non plus la chaîne de raisonnement brute. Fable 5 la protège : vous recevez des blocs `thinking` normaux, et vous pouvez demander un résumé lisible avec `display: "summarized"`, mais le raisonnement non filtré n'est jamais exposé. Pour la plupart des applications, c'est un non-problème — lisez le résumé si vous avez besoin de visibilité. Là où cela compte, c'est dans les **agents multi-tours** : quand vous poursuivez une conversation sur le même modèle, vous devez renvoyer les blocs de raisonnement **inchangés**. Supprimez-les ou modifiez-les, et le tour casse. Si vous construisez des boucles d'agents, traitez les blocs de raisonnement comme des tokens opaques que vous transportez tels quels. ## Les refus sont désormais un problème de flux de contrôle C'est le changement qui affecte le plus la façon dont vous écrivez le code autour du modèle. Fable 5 exécute des classifieurs de sécurité sur les requêtes entrantes, ciblant principalement la biologie de recherche et la majeure partie des contenus de cybersécurité. Lorsqu'une requête est refusée, vous obtenez un **HTTP 200 réussi** avec `stop_reason: "refusal"` — pas une erreur, pas une exception. Le tableau `content` peut être vide. Si votre code fait `response.content[0].text` sans vérifier d'abord `stop_reason`, il plantera le jour où une requête sera refusée. Et un travail adjacent bénin — un outillage de sécurité légitime, des tâches en sciences du vivant — peut occasionnellement déclencher un faux positif, donc ce n'est pas un problème réservé aux personnes aux intentions douteuses. La règle est la suivante : **branchez sur `stop_reason`, jamais sur `stop_details`.** ```typescript const res = await client.messages.create({ model: "claude-fable-5", max_tokens: 1024, messages, }); if (res.stop_reason === "refusal") { // classifiers declined — content is empty or partial. Don't read content[0]. await handleRefusal(res); } else { console.log(res.content[0].text); } ``` Pour la production, il existe une voie plus propre : un paramètre `fallbacks` côté serveur (en bêta) qui réessaie automatiquement une requête refusée sur `claude-opus-4-8` dans le même aller-retour, avec une retarification de type crédit appliquée. Si vous exécutez des agents sans surveillance, mettez cela en place pour qu'un seul faux positif de refus ne bloque pas toute une exécution. C'est la même leçon que je réapprends sans cesse au sujet des agents qui [continuent d'échouer en production](/blog/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it) : le modèle qui devient plus intelligent ne supprime pas la nécessité de gérer ses cas limites — il les déplace ailleurs. ## Deux autres détails de migration Quelques points plus mineurs qui m'ont coûté du temps, pour qu'ils ne vous coûtent pas le vôtre : - **Pas de préremplissage de l'assistant.** Si vous orientiez la sortie en préremplissant le dernier tour de l'assistant, ce schéma a disparu. Utilisez plutôt des sorties structurées (`output_config.format`) ou des instructions dans le prompt système. - **La rétention des données pendant 30 jours est obligatoire.** Fable 5 n'est pas disponible en mode zéro rétention de données. Si vous êtes en ZDR pour des raisons de conformité, Fable 5 est hors de question et Opus 4.8 reste votre plafond. Vérifiez ce point *avant* de planifier une migration, pas après. ## Faut-il vraiment basculer ? Voici mon verdict d'opérateur après l'avoir vécu au quotidien. **Fable 5 n'est pas la cible par défaut du « passez au dernier modèle » — c'est Opus 4.8.** Cela surprend, mais c'est le bon cadrage. Opus 4.8 est un simple changement d'ID de modèle depuis la 4.7, sans nouveau changement cassant, il est moins cher, et pour l'écrasante majorité du travail d'agent, sa qualité de sortie est indiscernable. Fable 5 gagne sa place sur les tâches réellement difficiles : agents de longue haleine qui doivent rester cohérents sur de nombreuses étapes, raisonnement approfondi multi-sources, ces exécutions où l'échec que vous cherchez à éliminer est subtil. Pour celles-là, la capacité est réelle et vaut la prime. Pour tout le reste — rédaction de contenu, classification, routage, résumé — vous payez plus de tokens à un prix plus élevé pour une qualité que vous ne percevez pas. J'ai fini par faire tourner les deux. Mon agent de recherche et de synthèse est passé à Fable 5. Tout le reste est resté sur Opus 4.8. Ce partage, c'est tout l'enjeu : choisissez le modèle selon la tâche, pas selon la mode. Si vous exploitez une flotte d'agents, la même discipline dont je parlais dans [ma stack d'opérateur 2026](/blog/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack) s'applique : dirigez le travail difficile vers le modèle coûteux et arrêtez de surpayer le travail facile. ## La conclusion de l'opérateur Testez Fable 5 sur votre tâche la plus difficile avant de toucher à quoi que ce soit d'autre : c'est là qu'il est rentable, et s'il ne fait pas la différence là, il ne la fera nulle part. Lancez le compteur de tokens sur vos prompts réels pour que l'inflation d'environ 30 % du tokenizer et la prime de prix ne vous surprennent pas sur la facture. Ajoutez une vérification `stop_reason: "refusal"` (ou le repli côté serveur vers Opus 4.8) partout où Fable 5 touche la production. Ensuite, routez délibérément : Fable 5 pour les 10 % difficiles, Opus 4.8 pour le reste. Le meilleur modèle n'est pas le plus performant — c'est celui qui correspond à la tâche. --- ## Le guide ultime du débutant sur les agents IA : Cowork, Codex et les outils qui font vraiment le travail Source: https://alejandrorioja.com/fr/ai-agents-for-beginners-cowork-codex-guide/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Les agents IA sont l'étape au-delà des chatbots : vous leur donnez un objectif en français courant et ils font le travail — lire vos fichiers, rédiger, organiser, écrire et exécuter du code. Cowork est la rampe d'accès sans code ; Codex et Claude Code sont pour quiconque touche une base de code. La compétence qui compte, c'est écrire une instruction claire et bien délimitée, pas apprendre à programmer. ## Table of contents _Mis à jour juin 2026._ **TL;DR :** Les agents IA sont l'étape au-delà des chatbots : vous leur donnez un objectif en langage courant et ils font le travail — lire vos fichiers, rédiger, organiser, écrire et exécuter du code, et vérifier leur propre résultat. **Cowork** est la rampe d'accès sans code pour les non-techniciens ; **Codex** et **Claude Code** sont pour quiconque touche une base de code. La seule compétence qui compte, c'est écrire une instruction claire et bien délimitée — pas apprendre à programmer. **[Note de l'auteur]** Je gère plus de 30 agents codés au quotidien, mais la plupart des gens n'ont pas besoin de code pour capturer 80 % de la valeur. Ils ont besoin d'un prompt clair et d'un endroit pour l'exécuter. Ce guide est l'introduction que je donnerais à un ami intelligent qui n'a jamais écrit une ligne de code. ## Ce qu'est réellement un « agent IA » Un chatbot répond à une question. Un **agent** accomplit une tâche. La différence, c'est qu'un agent peut enchaîner des actions en boucle — lire un document, décider quoi faire ensuite, écrire un fichier, exécuter une commande, vérifier le résultat, corriger ce qui cloche — sans que vous guidiez chaque étape. Concrètement : vous ne demandez pas «comment je nettoie ce tableur ?» Vous dites «voici le tableur — supprime les doublons, corrige les formats de date et signale les lignes avec des e-mails manquants», et l'agent le fait et vous rend le fichier nettoyé. Ce glissement — du *conseil* au *travail terminé* — c'est tout l'intérêt. ## Les deux familles d'outils Il y a deux portes d'entrée dans ce monde, et vous n'avez besoin que de celle qui correspond à votre métier. ### Porte 1 : Les agents sans code (commencez ici si vous ne codez pas) **Claude Cowork** est un espace de travail où vous donnez à Claude un objectif et les matériaux — fichiers, liens, notes — et il produit le résultat que vous relisez et utilisez : un brouillon, un résumé, un plan, un tableur nettoyé. Vous écrivez des instructions, pas du code. Pensez «un assistant très capable qui lit vite et ne se fatigue jamais», pas «un outil de programmation». C'est le bon point de départ pour les marketeurs, les fondateurs, les opérateurs, les rédacteurs, les analystes — tous ceux dont le travail est avant tout des documents, de la recherche et des décisions. ### Porte 2 : Les agents de programmation (utilisez-les dès qu'une base de code est impliquée) **OpenAI Codex** et **Claude Code** sont des agents qui vivent là où le logiciel se construit — un terminal, un IDE ou le cloud. Vous décrivez un changement («ajoute un bouton mode sombre», «corrige ce test en échec», «migre ce fichier vers la nouvelle API») et l'agent modifie le code, l'exécute et itère jusqu'à ce que ça fonctionne. Vous continuez à tout relire ; l'agent fait la frappe. Vous n'avez pas besoin d'être un ingénieur senior pour les utiliser. Beaucoup de non-développeurs utilisent des agents de programmation pour lancer de petits sites web, automatiser des tableurs sous forme de scripts et corriger des bugs dans des outils qu'ils n'ont pas écrits. Mais il y a une vraie courbe d'apprentissage, donc la plupart des débutants ont intérêt à commencer par la Porte 1 et à passer la Porte 2 quand ils se heurtent à une tâche qui nécessite vraiment du code. ## Votre premier résultat concret (faites-le aujourd'hui) Choisissez une petite tâche pénible que vous faites souvent. Bons premiers candidats : - Transformer un compte-rendu de réunion brouillon en notes propres avec une liste de points d'action. - Résumer un long PDF en 5 points clés et 3 questions à poser. - Réécrire un brouillon d'e-mail pour le rendre clair, chaleureux et en moins de 120 mots. Puis utilisez la structure qui rend les agents fiables plutôt qu'aléatoires — **rôle → entrée → instruction exacte → contrainte → une vérification** : > Tu es mon assistant. Voici une [transcription de réunion / PDF / brouillon d'e-mail] collée ci-dessous. Fais ceci : [transforme-la en notes propres avec une liste en gras «Points d'action» / résume en 5 points + 3 questions de suivi / réécris pour être clair, chaleureux et en moins de 120 mots]. Garde ma voix. Pose-moi une question si quelque chose est ambigu avant de commencer. > > [collez votre contenu ici] C'est tout. Vous venez de déléguer une tâche. La structure est tout le jeu — et elle fonctionne à l'identique dans Cowork, ChatGPT ou un agent de programmation. ## Le prompt en quatre parties qui rend les agents fiables Les débutants pensent que le secret est une formule magique. Ce n'est pas le cas. C'est la précision. Toute instruction fiable pour un agent comporte quatre parties : 1. **Rôle** — qui est l'agent pour cette tâche («Tu es mon assistant de recherche»). 2. **Contexte** — les matériaux et le *pourquoi* («Je me prépare pour un appel commercial avec un fondateur fintech»). 3. **Tâche** — l'action exacte et délimitée («Trouve trois faits récents sur des levées de fonds et rédige deux questions d'ouverture»). 4. **Contraintes + une vérification** — format, longueur, ton, et une instruction pour demander avant de supposer («Uniquement des puces, cite les sources, pose-moi une question de clarification si l'entreprise est ambiguë»). Vague en entrée, vague en sortie. Plus un agent peut *faire*, plus votre clarté compte — un chatbot qui comprend mal gaspille une phrase ; un agent qui comprend mal gaspille un après-midi de travail à défaire. ## Les erreurs de débutant à éviter - **Le traiter comme un moteur de recherche.** Ne posez pas des questions d'une ligne. Donnez-lui du vrai travail avec de vrais fichiers. - **Sauter la contrainte.** «Écris-moi un plan» vous donne un mur de texte. «Écris-moi un plan d'une page avec trois phases et un responsable par tâche» vous donne quelque chose d'utilisable. - **Ne pas demander une vérification.** Ajoutez «pose-moi une question si quelque chose est ambigu» et vous attraperez les malentendus *avant* que l'agent ne démarre, pas après. - **Laisser les agents de programmation tourner sans surveillance sur du code important.** Relisez le diff. Les agents sont rapides et généralement corrects, mais «généralement» fait du travail dans cette phrase — gardez un humain dans la boucle sur tout ce qui est mis en production. - **Passer à la Porte 2 trop tôt.** Si votre tâche concerne des documents et des décisions, vous n'avez jamais besoin d'ouvrir un terminal. ## Comment choisir votre premier outil - **Votre travail concerne les documents, la recherche et la rédaction** → commencez avec **Cowork** (ou le produit de chat que vous payez déjà, utilisé en mode agent). - **Vous voulez construire ou corriger des logiciels** → **Claude Code** ou **OpenAI Codex**. - **Vous voulez du travail récurrent sans intervention** (un digest quotidien, un rapport hebdomadaire) → passez aux **[tâches planifiées](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/)** une fois que vous maîtrisez le prompt manuellement. ## Agents IA pour débutants — FAQ 2026 ### Faut-il savoir coder pour utiliser des agents IA ? Non. Les agents sans code comme Claude Cowork sont conçus pour les utilisateurs non techniques — vous écrivez des instructions en langage courant. Les agents de programmation comme Codex et Claude Code impliquent une courbe d'apprentissage, mais même ceux-là sont de plus en plus utilisés par des personnes qui ne se considèrent pas comme des programmeurs. Commencez sans code, passez au code uniquement quand une tâche l'exige. ### Quelle est la différence entre un chatbot et un agent IA ? Un chatbot répond à des questions ; un agent accomplit des tâches. L'agent peut enchaîner une séquence d'actions — lire, décider, agir, vérifier, corriger — en boucle, produisant un travail terminé plutôt que des conseils. En pratique, le même produit fait souvent les deux ; le «mode agent» est le comportement d'agent. ### Cowork est-il meilleur que Codex ? Ils sont faits pour des travaux différents, pas meilleurs ou moins bons l'un que l'autre. Cowork est un espace de travail sans code pour les documents, la recherche et les opérations. Codex (et Claude Code) sont des agents de programmation pour construire et corriger des logiciels. Choisissez celui qui correspond à votre tâche. ### Comment obtenir de bons résultats d'un agent IA ? La précision. Utilisez la structure en quatre parties : rôle, contexte, tâche exacte et contraintes plus une vérification. Donnez-lui de vrais matériaux, indiquez-lui le format que vous voulez et demandez-lui de signaler les ambiguïtés avant de commencer. Les instructions claires comptent plus que n'importe quel «prompt magique». ### Est-il prudent de laisser les agents IA tourner seuls ? Pour les tâches à faible risque et réversibles (rédiger, résumer, organiser), oui — relisez le résultat et continuez. Pour tout ce qui modifie des systèmes réels (déployer du code, envoyer des messages, supprimer des données), gardez un humain dans la boucle et vérifiez avant qu'il agisse. La réversibilité est le bon critère : plus quelque chose est facile à annuler, plus l'agent peut avoir d'autonomie en toute sécurité. **Lectures connexes :** [Comment être cité dans les réponses de ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) · [Le manuel llms.txt](https://alejandrorioja.com/llms-txt-playbook/) · [Comment utiliser les tâches planifiées de Claude](https://alejandrorioja.com/how-to-use-claude-scheduled-tasks/) --- **Vous voulez de l'aide pour mettre des agents au travail dans votre entreprise ?** Je construis des systèmes d'agents IA pour des équipes opérationnelles — [contactez-moi](https://alejandrorioja.com/contact/) ou lisez-en plus sur [ma façon de penser tout ça](https://alejandrorioja.com/seo-tips/). --- ## Comment Anthropic gagne-t-il de l'argent ? Le modèle économique de Claude expliqué Source: https://alejandrorioja.com/fr/how-does-anthropic-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: Anthropic vend l'accès à ses modèles d'IA Claude via cinq canaux principaux : une API basée sur l'usage (vous payez par token), des abonnements grand public (Claude Pro et Max), des plans entreprise (licences Team et Enterprise), Claude Code pour les développeurs, et la distribution via des marketplaces cloud comme Amazon Bedrock et Google Vertex. L'API et le segment entreprise — pas l'application grand public — sont les principaux moteurs de revenus. ## Table of contents _Mis à jour juin 2026._ **TL;DR :** Anthropic vend l'accès à ses modèles d'IA Claude via cinq canaux principaux : une **API basée sur l'usage** (vous payez par token), des **abonnements grand public** (Claude Pro et Max), des **plans entreprise** (licences Team et Enterprise), **Claude Code** pour les développeurs, et la **distribution via des marketplaces cloud** comme Amazon Bedrock et Google Vertex AI. L'API et le segment entreprise — pas l'application de chat grand public — sont les principaux moteurs de revenus. **[Note de l'opérateur]** Je développe sur l'API d'Anthropic au quotidien, donc je vois l'activité de l'intérieur du compteur. Ce qu'il faut comprendre : Anthropic est une entreprise B2B avec une porte d'entrée grand public. L'application de chat que vous utilisez est du marketing et une ligne de revenus ; le vrai argent vient des développeurs et des entreprises qui mesurent leurs tokens via l'API et paient pour des licences à grande échelle. ## Qu'est-ce qu'Anthropic Anthropic est une entreprise de recherche en sécurité de l'IA, fondée en 2021, qui développe la famille de grands modèles de langage **Claude**. Elle vend ces modèles — et les outils qui les entourent — aux particuliers, aux développeurs et aux entreprises. C'est une société privée, largement soutenue par des investisseurs stratégiques dont Amazon et Google, qui sont également partenaires cloud et de distribution. Le produit est de l'intelligence en tant que service : vous n'achetez pas de logiciel en boîte, vous louez l'accès à un modèle qui lit, écrit, raisonne et agit en votre nom. Chaque canal ci-dessous est un emballage différent autour du même actif central. ## Comment Anthropic gagne-t-il de l'argent ? ### 1. L'API (basée sur l'usage, le moteur central) Le fondement de l'activité. Les développeurs et les entreprises appellent Claude via une API et paient **par token** — grossièrement, par fragment de texte en entrée et en sortie. La tarification évolue avec les capacités du modèle : - **Claude Opus** (le niveau le plus performant) est tarifé le plus haut — de l'ordre de quelques dollars par million de tokens en entrée et plusieurs fois plus pour la sortie. - **Claude Sonnet** (le modèle équilibré) se situe au milieu. - **Claude Haiku** (le niveau rapide et économique) est le moins cher, pour les tâches simples à volume élevé. Les tokens de sortie coûtent plus cher que les tokens d'entrée, et des fonctionnalités comme le contexte long, la mise en cache des prompts et le traitement par lots ont leur propre tarification. La dynamique clé : **les revenus évoluent directement avec l'usage**. Une startup qui intègre Claude dans son produit et qui grandit jusqu'à des millions d'utilisateurs génère chaque mois davantage de revenus API sans qu'Anthropic signe un nouveau contrat. Ce modèle basé sur l'usage explique pourquoi les laboratoires d'IA parlent de « revenus annualisés » croissant si vite — ils s'accumulent avec la croissance propre des clients. ### 2. Abonnements grand public (Claude Pro et Max) Les applications Claude (web, bureau, mobile) sont gratuites à l'essai, avec des niveaux payants pour ceux qui les utilisent intensément : - **Claude Pro** — un abonnement mensuel fixe pour des limites d'usage plus élevées, l'accès aux meilleurs modèles et des fonctionnalités comme un contexte plus large et un accès prioritaire. - **Claude Max** — un niveau plus coûteux pour les utilisateurs avancés qui atteignent les limites de Pro, avec un espace d'usage substantiellement plus grand. C'est la partie la plus visible d'Anthropic mais, pour une entreprise dont les clients sont majoritairement des professionnels, c'est une part plus petite que les lignes API et entreprise. Sa valeur stratégique est autant un entonnoir et une surface de marque qu'une source de revenus. ### 3. Entreprise (licences Team et Enterprise) C'est là que réside une grande partie des revenus durables. Les entreprises achètent Claude pour leurs employés sur la base de **licences par utilisateur**, avec des plans conçus pour les organisations : - **Team** — pour les petites entreprises : usage mutualisé, facturation centralisée, fonctionnalités collaboratives. - **Enterprise** — pour les grandes organisations : sécurité et conformité renforcées, authentification unique, fenêtres de contexte plus larges, contrôles administrateurs et garanties d'usage. Les contrats entreprise sont récurrents, s'étendent dans le temps (plus de licences, plus d'usage) et s'accompagnent du type de coûts de changement qui rendent les revenus stables. C'est le mouvement SaaS classique superposé au modèle. ### 4. Claude Code (outils pour développeurs) **Claude Code** est l'outil de codage agentique d'Anthropic — un agent qui écrit, modifie et exécute du code dans votre terminal, IDE ou le cloud. Il est monétisé via les mêmes rails d'abonnement et d'usage (il est inclus dans les niveaux Pro/Max/Team/Enterprise et compte dans votre plan). Stratégiquement, il fait deux choses : c'est une ligne de revenus à part entière, et il génère beaucoup d'usage de tokens à haute valeur, car les agents de codage consomment une grande quantité de capacité du modèle. ### 5. Distribution via les marketplaces cloud (AWS, Google et autres) Anthropic ne vend pas Claude uniquement en direct — il distribue également via les grandes plateformes cloud : - **Amazon Bedrock** et **Claude Platform on AWS** — les clients déjà sur AWS accèdent à Claude via l'infrastructure et la facturation d'Amazon. - **Google Vertex AI** et **Microsoft Foundry** — la même idée sur Google Cloud et la plateforme de Microsoft. Ces canaux rejoignent les entreprises là où leurs dépenses cloud et leurs processus d'achat existent déjà, ce qui réduit la friction pour adopter Claude. Les revenus sont partagés avec la plateforme, mais la portée est énorme — et les investissements profonds d'Amazon et Google font de ces partenariats des alliances stratégiques, pas seulement commerciales. ### 6. La plateforme d'agents émergente De plus en plus, Anthropic vend non seulement des appels de modèles bruts mais aussi une **infrastructure d'agents** — des services gérés où Anthropic exécute la boucle de l'agent et héberge l'environnement dans lequel les agents exécutent les tâches. À mesure que davantage de clients passent de « poser une question au modèle » à « faire effectuer le travail par un agent », cette couche de niveau supérieur devient un nouvel endroit pour capturer de la valeur au-delà du noyau de paiement par token. ## Anthropic est-il rentable ? Anthropic est privée et ne publie pas de comptes audités, mais le tableau public est le même que celui de ses pairs : **les revenus croissent extrêmement vite**, tandis que l'entreprise dépense des sommes considérables en calcul (entraînement et inférence des modèles) et en talents de recherche. Comme les autres laboratoires d'IA de pointe, elle est dans une phase d'investissement intense où la croissance du chiffre d'affaires, et non le bénéfice actuel, est le titre de référence. Le pari que font les investisseurs est que les revenus basés sur l'usage continuent de s'accumuler à mesure que l'IA s'intègre dans davantage de logiciels, dépassant finalement le coût du calcul. ## Comment cela se compare-t-il à OpenAI Les structures sont similaires — les deux monétisent via des abonnements grand public, une API basée sur l'usage, des licences entreprise et des outils pour développeurs. Les différences tiennent à l'emphase et aux partenariats : Anthropic mise fortement sur l'API développeurs/entreprise et est soutenu par Amazon et Google ; OpenAI a une empreinte grand public plus large et un partenariat profond avec Microsoft. Si vous voulez l'autre côté de la comparaison, consultez [comment OpenAI gagne de l'argent](https://alejandrorioja.com/how-does-openai-make-money/). ## Modèle de revenus d'Anthropic — FAQ 2026 ### Quelle est la principale source de revenus d'Anthropic ? L'**API basée sur l'usage** et les **contrats entreprise** sont les principaux moteurs. Les développeurs et les entreprises paient par token pour appeler Claude, et les organisations achètent des plans par utilisateur pour leurs équipes. L'abonnement Claude grand public est le produit le plus visible mais une part plus petite des revenus que les lignes métier. ### Comment fonctionne la tarification de l'API Claude ? Vous payez par token — entrée et sortie mesurées en fragments de texte. Les modèles plus performants (Opus) coûtent plus cher par token que les modèles équilibrés (Sonnet) ou rapides (Haiku), et les tokens de sortie coûtent plus cher que les tokens d'entrée. Des fonctionnalités comme le contexte long, la mise en cache des prompts et le traitement par lots ont leur propre tarification. Les revenus évoluent directement avec l'utilisation que font les clients des modèles. ### Anthropic est-il coté en bourse ? Non. Anthropic est une société privée soutenue par des investisseurs stratégiques et en capital-risque, dont Amazon et Google. Ses actions ne sont pas disponibles sur les marchés boursiers publics et aucune introduction en bourse n'est confirmée. ### Anthropic gagne-t-il de l'argent avec l'application Claude gratuite ? Pas directement avec les utilisateurs gratuits — le niveau gratuit est un entonnoir. L'argent vient quand les utilisateurs gratuits passent à **Pro** ou **Max**, quand les équipes achètent des **licences entreprise**, et surtout quand les développeurs construisent sur l'**API**. Le rôle de l'application gratuite est la portée et la marque ; les niveaux payants et l'API sont là où elle convertit. ### Qui sont les plus gros clients d'Anthropic ? Principalement d'autres entreprises : des sociétés de logiciels qui intègrent Claude dans leurs produits via l'API, et des entreprises qui déploient Claude pour leurs employés. La distribution via des marketplaces cloud à travers AWS, Google et Microsoft attire également de grands clients entreprise qui achètent via leurs fournisseurs cloud existants. **Lecture connexe :** [Comment OpenAI gagne de l'argent](https://alejandrorioja.com/how-does-openai-make-money/) · [Le guide du débutant sur les agents IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Comment être cité dans les réponses de ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- ## La version courte Anthropic loue l'accès à ses modèles Claude. Les développeurs paient par token via l'API, les particuliers paient mensuellement pour Pro et Max, les entreprises paient par licence pour Team et Enterprise, les ingénieurs utilisent Claude Code dans ces mêmes plans, et les géants du cloud (AWS, Google, Microsoft) revendent Claude aux entreprises via leurs marketplaces. C'est une activité B2B avec une porte d'entrée grand public — et le compteur, pas l'application de chat, est là où se trouve l'argent. --- ## Comment OpenAI gagne-t-il de l'argent ? Le modèle économique de ChatGPT et de l'API Source: https://alejandrorioja.com/fr/how-does-openai-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business, AI TL;DR: OpenAI gagne de l'argent de quatre manières principales : les abonnements ChatGPT (Plus, Pro, Team, Enterprise, Edu), une API à la consommation où les développeurs paient par token, de grands contrats d'entreprise et son partenariat avec Microsoft (distribution et partage des revenus). Contrairement à la plupart des laboratoires d'IA, le modèle d'abonnement grand public d'OpenAI constitue sa plus grande source de revenus — la taille de ChatGPT est le moteur. ## Table of contents _Mis à jour en juin 2026._ **TL;DR :** OpenAI gagne de l'argent de quatre manières principales : les **abonnements ChatGPT** (Plus, Pro, Team, Enterprise, Edu), une **API à la consommation** où les développeurs paient par token, de grands **contrats d'entreprise** et son **partenariat avec Microsoft** (distribution et partage des revenus). Contrairement à la plupart des laboratoires d'IA, le modèle d'abonnement grand public d'OpenAI constitue sa plus grande source de revenus — l'immense taille de ChatGPT est le moteur. **[Note pour les opérateurs]** OpenAI est l'inverse d'une entreprise d'IA d'entreprise classique : elle a d'abord construit un phénomène grand public, puis un modèle économique pour les développeurs et les entreprises. Les centaines de millions d'utilisateurs de ChatGPT sont à la fois la marque et la machine à générer des revenus. Tous les autres acteurs de cet espace aimeraient disposer d'un tel entonnoir d'acquisition. ## Qu'est-ce qu'OpenAI ? OpenAI est la société de recherche en IA à l'origine de **ChatGPT** et de la famille de modèles **GPT**, ainsi que de produits comme le modèle vidéo Sora, la génération d'images et l'agent de programmation Codex. Fondée en 2015, elle a atteint la notoriété grand public lorsque ChatGPT a été lancé fin 2022 et est devenu l'un des produits grand public ayant connu la croissance la plus rapide de l'histoire. Sa structure est inhabituelle : elle a commencé comme une organisation à but non lucratif et a créé un bras à but lucratif plafonné pour lever l'énorme capital qu'exige l'entraînement de modèles de pointe. Elle n'est pas cotée en bourse et entretient un partenariat profond et pluriannuel avec **Microsoft** qui fournit calcul, distribution et capital. Le produit, comme pour tout laboratoire d'IA, est l'intelligence en tant que service — vendue sur les canaux grand public, développeur et entreprise. ## Comment OpenAI gagne-t-il de l'argent ? ### 1. Les abonnements ChatGPT (la plus grande ligne de revenus) C'est ce qui distingue OpenAI de ses pairs. ChatGPT est gratuit, avec des niveaux payants qui convertissent une partie de son immense base d'utilisateurs en revenus récurrents : - **ChatGPT Plus** — un abonnement mensuel fixe donnant accès aux meilleurs modèles, à des limites plus élevées et à des fonctionnalités premium. Le niveau grand public. - **ChatGPT Pro** — un niveau tarifaire supérieur pour les utilisateurs intensifs souhaitant une utilisation maximale et les paramètres de modèle les plus performants. - **ChatGPT Team** — des plans par siège pour les petites entreprises, avec des espaces de travail partagés et des outils d'administration. - **ChatGPT Enterprise** — pour les grandes organisations : sécurité avancée, conformité réglementaire, SSO, contexte élargi et garanties d'utilisation. - **ChatGPT Edu** — une version adaptée aux universités et aux écoles. ChatGPT touchant des centaines de millions d'utilisateurs hebdomadaires, même un taux de conversion à un seul chiffre bas vers les abonnements payants génère une activité d'abonnement considérable. Cette échelle grand public est l'avantage distinctif d'OpenAI, et les abonnements sont selon les rapports sa plus grande source de revenus. ### 2. L'API (à la consommation, pour les développeurs) Les développeurs et les entreprises intègrent les modèles d'OpenAI dans leurs propres produits et paient **par token** — par fragment de texte (ou d'image ou d'audio) traité. Les tarifs évoluent avec la capacité du modèle : les modèles de raisonnement phares coûtent plus cher par token que les modèles plus petits, rapides et économiques, et la génération de sortie est tarifée plus cher que l'entrée. L'API transforme chaque entreprise qui développe sur GPT en client mesuré dont la facture augmente avec sa propre utilisation. C'est la même dynamique de composition sur laquelle repose chaque laboratoire d'IA : une startup qui intègre OpenAI et passe à des millions d'utilisateurs génère davantage de revenus API chaque mois sans nouveau contrat. ### 3. Les contrats d'entreprise Au-delà de l'API en libre-service et des plans Team, OpenAI signe de grands accords personnalisés avec de grandes entreprises — utilisation en volume, capacité dédiée, support personnalisé et engagements de sécurité et de conformité. Ces contrats sont récurrents, se développent dans le temps et deviennent incontournables une fois qu'une entreprise construit des flux de travail critiques sur les modèles. Cette activité entreprise coexiste avec le modèle grand public et représente un domaine de croissance majeur. ### 4. Le partenariat avec Microsoft Microsoft est le partenaire stratégique le plus important d'OpenAI. La relation fonctionne sur plusieurs axes : - **Calcul** — Le cloud Azure de Microsoft fournit une grande partie de l'infrastructure sur laquelle OpenAI entraîne et héberge ses modèles. - **Distribution** — Les modèles d'OpenAI sont proposés via les plateformes de Microsoft (services IA d'Azure, produits Copilot), mettant GPT devant l'immense clientèle d'entreprise de Microsoft. - **Partage des revenus** — Les deux entreprises partagent les revenus dans le cadre de leur accord commercial, et Microsoft a massivement investi dans OpenAI. Ce partenariat est à la fois capital et mise sur le marché : il donne à OpenAI accès à des entreprises qu'il lui faudrait des années à démarcher directement. ### 5. Nouveaux produits et produits adjacents OpenAI continue d'élargir la surface qu'il peut monétiser : - **Codex** — son outil de programmation agentique, monétisé via abonnements et utilisation de l'API (et un moteur de consommation importante de tokens). - **Sora** — génération de vidéo, proposée dans les niveaux payants et comme produit à part entière. - **Génération d'images et autres modalités** — incluses dans les abonnements et mesurées via l'API. - **Un écosystème développeurs et agents** — GPTs personnalisés, une plateforme d'agents et des outils permettant aux entreprises de construire sur les modèles d'OpenAI. Chacun d'eux est un autre emballage autour du même actif central, visant à capturer davantage de ce que les utilisateurs et les développeurs sont prêts à payer. ## OpenAI est-il rentable ? OpenAI est privé et ne publie pas d'états financiers audités. Le tableau largement rapporté : **les revenus sont très importants et croissent rapidement**, mais les coûts aussi — entraîner des modèles de pointe et servir des centaines de millions d'utilisateurs consomme des quantités stupéfiantes de calcul. Comme ses pairs, OpenAI est dans une phase d'investissement intensif où la priorité est la croissance et la capacité, et non le profit à court terme. Le pari est que l'échelle conjuguée à l'adoption croissante par les entreprises finira par dépasser les coûts de calcul. ## Comparaison avec Anthropic Les briques de base sont similaires — abonnements grand public, API à la consommation, contrats d'entreprise, outils de programmation — mais l'accent diffère. L'avantage distinctif d'OpenAI est **l'échelle grand public** (ChatGPT) et son partenariat avec **Microsoft** ; Anthropic mise davantage sur **l'API développeurs et entreprises** et est soutenu par Amazon et Google. Pour l'autre côté de la comparaison, consultez [comment Anthropic gagne de l'argent](https://alejandrorioja.com/how-does-anthropic-make-money/). ## Modèle de revenus d'OpenAI — FAQ 2026 ### Quelle est la plus grande source de revenus d'OpenAI ? **Les abonnements ChatGPT.** ChatGPT touchant des centaines de millions d'utilisateurs, ses niveaux payants (Plus, Pro, Team, Enterprise, Edu) constituent la plus grande ligne de revenus d'OpenAI — un profil inhabituel pour un laboratoire d'IA, dont la plupart gagnent davantage grâce aux API et aux entreprises qu'aux consommateurs. ### Comment l'API d'OpenAI génère-t-elle des revenus ? Les développeurs paient **par token** pour utiliser les modèles d'OpenAI dans leurs propres applications — par fragment de texte, d'image ou d'audio traité. Les modèles plus performants coûtent plus cher par token, et la sortie est tarifée plus cher que l'entrée. Les revenus augmentent automatiquement à mesure que l'utilisation des clients progresse. ### OpenAI est-il coté en bourse ? Peut-on acheter des actions OpenAI ? Non. OpenAI est une société privée et ses actions ne sont pas disponibles sur les marchés publics. La plupart des gens ne peuvent pas investir directement. Microsoft détient une participation importante via son partenariat, mais ce n'est pas la même chose qu'OpenAI étant cotée en bourse. ### Comment le partenariat avec Microsoft rapporte-t-il de l'argent à OpenAI ? Microsoft fournit le calcul Azure, distribue les modèles d'OpenAI via ses produits et son cloud à une immense clientèle d'entreprise, et les deux sociétés partagent les revenus dans le cadre de leur accord commercial. Microsoft a également massivement investi dans OpenAI. C'est à la fois une source de financement et un canal de distribution. ### OpenAI gagne-t-il de l'argent grâce aux utilisateurs gratuits de ChatGPT ? Pas directement — le niveau gratuit est un entonnoir. Les revenus arrivent lorsque les utilisateurs gratuits passent à **Plus** ou **Pro**, lorsque les entreprises achètent des sièges **Team** ou **Enterprise**, et lorsque les développeurs développent sur **l'API**. Le rôle du produit gratuit est la portée ; les niveaux payants et l'API la convertissent. **À lire également :** [Comment Anthropic gagne de l'argent](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Comment SpaceX gagne de l'argent](https://alejandrorioja.com/how-does-spacex-make-money/) · [Le guide du débutant sur les agents IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) --- ## La version courte OpenAI convertit l'immense base d'utilisateurs de ChatGPT en revenus d'abonnement (Plus, Pro, Team, Enterprise), facture les développeurs par token via son API, signe de grands contrats d'entreprise et s'appuie sur Microsoft pour le calcul, la distribution et les revenus partagés. Sa caractéristique distinctive est l'échelle grand public — la plupart des laboratoires d'IA monétisent d'abord les développeurs ; OpenAI a construit un phénomène grand public et un modèle économique derrière lui. --- ## Comment SpaceX gagne-t-il de l'argent ? Lancements, Starlink et la question de l'IPO Source: https://alejandrorioja.com/fr/how-does-spacex-make-money/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Business TL;DR: SpaceX gagne de l'argent de trois façons : les services de lancement (vente de places en orbite sur des fusées Falcon réutilisables), Starlink (internet par satellite pour les particuliers, les entreprises, le maritime/l'aviation et les gouvernements) et les contrats gouvernementaux (équipage et fret NASA, modules d'atterrissage lunaire, lancements de sécurité nationale). Starlink est désormais le principal moteur de revenus. SpaceX reste privée ; un IPO de SpaceX lui-même n'est pas imminent, bien qu'une future scission de Starlink soit évoquée depuis longtemps. ## Table of contents _Mis à jour juin 2026._ **TL;DR :** SpaceX gagne de l'argent de trois façons : les **services de lancement** (vente de places en orbite sur des fusées Falcon réutilisables), **Starlink** (internet par satellite pour les particuliers, les entreprises, le maritime/l'aviation et les gouvernements) et les **contrats gouvernementaux** (équipage et fret NASA, modules d'atterrissage lunaire, lancements de sécurité nationale). Starlink est désormais le principal moteur de revenus. SpaceX reste privée ; un IPO de SpaceX lui-même n'est pas imminent, bien qu'une future scission de Starlink soit évoquée depuis longtemps et régulièrement tempérée. **[Lecture de l'opérateur]** SpaceX est l'exemple moderne le plus clair d'une entreprise ayant utilisé un avantage technologique dans le matériel dur (fusées réutilisables) pour bootstrapper un modèle d'économie logicielle (internet par satellite) par-dessus. L'activité de lancement gagne le droit d'exister ; Starlink, c'est là que se trouve l'argent récurrent et scalable. C'est toute l'histoire en une phrase. ## Qu'est-ce que SpaceX ? SpaceX (Space Exploration Technologies Corp.) conçoit, construit et fait voler des fusées et des engins spatiaux, et exploite le réseau internet par satellite Starlink. Fondée en 2002 avec l'objectif à long terme de rendre l'humanité multiplanétaire, elle est devenue le principal fournisseur de lancements au monde en faisant quelque chose que personne d'autre n'avait fait à grande échelle : atterrir et réutiliser le premier étage d'une fusée orbitale, ce qui a effondré le coût d'accès à l'espace. Cet avantage de coût est le moteur de tout le reste. Des lancements bon marché, fréquents et fiables, c'est ce qui rend économiquement possible une constellation de plus de 7 000 satellites — et la constellation est ce qui transforme une activité de lancement irrégulière et basée sur des projets en une activité à revenus récurrents. ## Comment SpaceX gagne-t-il de l'argent ? ### 1. Services de lancement L'activité originelle. SpaceX vend des lancements à trois types de clients : - **Opérateurs de satellites commerciaux** — les entreprises qui ont besoin d'une charge utile en orbite paient pour un lancement dédié ou une place sur une mission **rideshare** (de nombreux petits satellites sur une même fusée, tarifés au kilogramme). - **Gouvernement et militaires** — charges utiles de sécurité nationale et missions scientifiques, souvent avec une prime pour la fiabilité et les garanties. - **Autres entreprises spatiales** — y compris, de plus en plus, des concurrents qui dépendent encore de SpaceX parce que c'est le trajet le moins cher et le plus disponible. L'économie unitaire fonctionne grâce à la **réutilisabilité** : le même propulseur de premier étage vole de nombreuses fois, de sorte que le coût marginal d'un lancement est bien inférieur au prix. Falcon 9 est le cheval de bataille ; Falcon Heavy gère les charges utiles les plus lourdes. ### 2. Starlink (la machine à revenus récurrents) Starlink est une constellation de milliers de satellites en orbite basse terrestre fournissant internet haut débit aux endroits que le haut débit terrestre ne peut pas atteindre ou ne dessert pas. C'est désormais la partie de SpaceX qui ressemble à un véritable modèle d'abonnement, avec plusieurs couches : - **Particuliers** — les foyers paient pour une antenne (matériel) plus un abonnement mensuel. - **Entreprises et mobilité** — des forfaits à prix plus élevé pour les entreprises, le maritime (navires, yachts) et **l'aviation** (accords Wi-Fi en vol avec les compagnies aériennes). - **Gouvernement** — dont **Starshield**, la variante orientée défense vendue aux clients militaires et gouvernementaux. - **Direct-to-cell** — partenariats avec des opérateurs mobiles pour fournir une connectivité satellite directement aux téléphones ordinaires dans les zones sans couverture. Starlink combine les ventes de matériel (le terminal) avec des revenus mensuels récurrents (l'abonnement) auprès de millions d'abonnés — la forme classique rasoir-et-lames, à l'échelle planétaire. C'est pourquoi la plupart des estimations placent désormais Starlink devant les lancements comme principale ligne de revenus de SpaceX. ### 3. Contrats gouvernementaux Un segment distinct et très important qui chevauche les lancements mais mérite d'être séparé : - **NASA** — SpaceX transporte des astronautes vers la Station spatiale internationale dans le cadre du programme **Commercial Crew** (Crew Dragon) et la ravitaille avec **Cargo Dragon**. Elle a également remporté un contrat pour construire un système d'atterrissage lunaire habité basé sur **Starship** pour les ambitions lunaires de la NASA. - **Sécurité nationale** — contrats de lancement récurrents pour les charges utiles de défense et de renseignement. Ces contrats sont à haute valeur ajoutée, pluriannuels, et financent une grande partie du développement qui bénéficie au secteur commercial. ### 4. Starship (le moteur du futur, pas encore un centre de profit) Starship est le véhicule de lancement super-lourd entièrement réutilisable de SpaceX — le remplacement à long terme du Falcon et la clé des missions lunaires/martiennes et de la prochaine génération, plus grande, de satellites Starlink. Aujourd'hui, c'est un centre de coûts financé par les trois autres activités. S'il atteint des vols de routine, il abaisse à nouveau considérablement le coût des lancements et permet un déploiement Starlink bien plus important — c'est le pari que font réellement les investisseurs. ## SpaceX est-elle rentable ? SpaceX est privée et ne publie pas d'états financiers audités, donc toute précision est une estimation. Le tableau largement rapporté : les lancements sont rentables par mission grâce à la réutilisabilité, et Starlink est passé en flux de trésorerie positif à mesure que sa base d'abonnés a grandi. L'entreprise réinvestit des sommes énormes dans le développement de Starship, donc le « profit » dépend largement de la façon dont on traite cette R&D. La direction de marche — revenus Starlink récurrents croissants au-dessus d'une activité de lancement dominante — est ce qui soutient l'énorme valorisation privée de l'entreprise. ## La question de l'IPO C'est la partie que tout le monde pose, voici donc la version honnête. **On ne s'attend pas à ce que SpaceX fasse une IPO prochainement.** Elon Musk a dit à plusieurs reprises qu'il préfère garder SpaceX privée tant que Starship et le programme martien sont intensifs en capital et à long horizon — la pression trimestrielle du marché public ne correspond pas à une mission de plusieurs décennies. À la place, SpaceX offre de la liquidité aux employés et aux premiers investisseurs via des **offres de vente périodiques** (l'entreprise facilite les ventes d'actions à un prix fixé), ce qui permet aux gens de récupérer leur mise sans cotation publique. Ces ventes secondaires sont ce qui produit les chiffres de valorisation dans les titres — SpaceX a été valorisée à plusieurs centaines de milliards de dollars lors de récentes levées de fonds. **Un IPO de scission Starlink est évoqué depuis longtemps** — Musk lui-même a suggéré il y a des années que Starlink pourrait éventuellement entrer en bourse une fois que ses revenus seraient réguliers et prévisibles. Mais il a également à plusieurs reprises douché les espoirs de calendrier à court terme. À partir de 2026, Starlink n'a pas fait d'IPO, et il n'y a pas de date confirmée. Traitez tout titre « date d'IPO Starlink » avec scepticisme à moins qu'il ne provienne de l'entreprise elle-même. ## Conclusion Le modèle de SpaceX est une pile : le lancement réutilisable crée un avantage de coût, cet avantage rend Starlink économiquement possible, Starlink transforme le tout en activité à revenus récurrents, et les contrats gouvernementaux financent le travail de frontière (Starship) qui réinitialise à nouveau la courbe des coûts. Elle reste privée par choix, en utilisant des offres de vente plutôt qu'un IPO — et la voie la plus probable vers les marchés publics est une future cotation de Starlink, pas SpaceX dans son ensemble, quand l'entreprise décidera que le moment est venu. ## Modèle de revenus de SpaceX — FAQ 2026 ### Quelle est la plus grande source de revenus de SpaceX ? La plupart des estimations placent désormais **Starlink** devant les services de lancement comme principale ligne de revenus de SpaceX, portée par des millions d'abonnements particuliers, entreprises, mobilité et gouvernement, plus les ventes de matériel de terminaux. Les services de lancement restent importants et très rentables par mission, mais le modèle récurrent de Starlink évolue plus vite. ### SpaceX est-elle cotée en bourse ? Puis-je acheter des actions SpaceX ? Non. SpaceX est une entreprise privée et ses actions ne sont pas disponibles sur les bourses publiques. La plupart des gens ne peuvent pas investir directement ; l'accès est généralement limité aux employés et aux investisseurs accrédités participant à des tours privés ou des offres de vente. Méfiez-vous des offres d'« actions SpaceX » qui suggèrent le contraire. ### SpaceX ou Starlink feront-ils une IPO ? On ne s'attend pas à ce que SpaceX entre en bourse à court terme — Musk a dit vouloir la garder privée pendant la phase intensive en capital de Starship/Mars. Un IPO de **Starlink** est discuté depuis des années comme une possibilité une fois que ses revenus seront prévisibles, mais à partir de 2026, il n'y a pas de date confirmée. Toute affirmation de « date d'IPO » spécifique doit être traitée avec scepticisme à moins qu'elle ne vienne de l'entreprise. ### Comment Starlink gagne-t-il de l'argent ? Starlink facture aux clients une antenne satellite (matériel) plus un abonnement mensuel, sur des niveaux particuliers, entreprises, maritime, aviation et gouvernement — dont le Starshield orienté défense et les partenariats d'opérateurs direct-to-cell. C'est un modèle rasoir-et-lames : matériel en amont, revenus récurrents ensuite. ### Comment la réutilisabilité aide-t-elle les bénéfices de SpaceX ? Atterrir et réutiliser le même propulseur de fusée de nombreuses fois réduit considérablement le coût marginal de chaque lancement en dessous du prix facturé. Cet avantage de coût est ce qui fait de SpaceX le fournisseur de lancements le moins cher et ce qui rend économiquement viable le déploiement d'une constellation Starlink de plusieurs milliers de satellites. **Lectures connexes :** [Comment Uber gagne de l'argent](https://alejandrorioja.com/how-does-uber-make-money/) · [Comment Shopify gagne de l'argent](https://alejandrorioja.com/how-shopify-makes-money/) · [Comment PayPal gagne de l'argent](https://alejandrorioja.com/how-does-paypal-make-money/) --- ## La version courte SpaceX vend des places en orbite à bas prix parce qu'elle réutilise ses fusées, puis utilise cet avantage de coût pour exploiter Starlink — un abonnement internet par satellite qui est désormais son plus grand générateur de revenus — tandis que les contrats gouvernementaux financent le Starship de nouvelle génération. Elle reste privée délibérément ; un IPO de Starlink, pas de SpaceX, est la voie éventuelle la plus probable vers les marchés publics. --- ## Comment utiliser les tâches planifiées de Claude : automatiser les travaux récurrents avec cron Source: https://alejandrorioja.com/fr/how-to-use-claude-scheduled-tasks/ Published: 2026-06-11 Updated: 2026-06-11 Tags: Productivity, AI TL;DR: Les tâches planifiées transforment un prompt Claude ponctuel en un travail récurrent : il se déclenche selon un calendrier de type cron, effectue le travail et livre le résultat. Utilisez l'application Claude pour les prompts personnels récurrents (un digest matinal, un résumé hebdomadaire) et les routines Claude Code ou les déploiements Managed Agents pour l'automatisation développeur qui tourne dans le cloud. Le gain vient de l'automatisation du travail que vous feriez autrement à la main chaque jour ou chaque semaine. ## Table of contents _Mis à jour juin 2026._ **TL;DR :** Les tâches planifiées transforment un prompt Claude ponctuel en un travail récurrent : il se déclenche selon un calendrier de type cron, effectue le travail et livre le résultat. Utilisez l'**application Claude** pour les prompts personnels récurrents (un digest matinal, un résumé hebdomadaire) et les **routines Claude Code** ou les **déploiements Managed Agents** pour l'automatisation développeur qui tourne dans le cloud. Le gain vient de l'automatisation du travail que vous feriez autrement à la main chaque jour ou chaque semaine. **[Lecture pour les opérateurs]** Les automatisations à fort levier ne sont pas spectaculaires — ce sont les petits travaux récurrents qui vous volent silencieusement 20 minutes par jour. Une tâche planifiée, c'est la façon de les confier à Claude une bonne fois pour toutes et de ne plus jamais y penser. J'en exécute plusieurs : un scan matinal de la concurrence, une vérification nocturne de l'état des PRs, un brouillon hebdomadaire du pipeline de contenu. Aucune n'a pris plus de dix minutes à configurer. ## Ce qu'est une tâche planifiée Une session Claude normale est synchrone : vous tapez, elle répond, vous êtes là. Une **tâche planifiée** est asynchrone et récurrente : vous définissez un prompt (ou tout un workflow d'agent) ainsi qu'un calendrier, et Claude l'exécute de lui-même — à 7h chaque jour ouvré, chaque lundi, chaque heure — et vous remet le résultat quand c'est terminé. Sous le capot, c'est un cron job avec un LLM au centre. Vous n'écrivez pas de code pour assembler des APIs ; vous décrivez le résultat en langage naturel et laissez l'agent déterminer les étapes à chaque déclenchement. ## Les trois endroits où vous les configurerez Il n'y a pas un seul bouton — il y a trois surfaces, adaptées à votre profil. ### 1. L'application Claude (pour tout le monde) Les applications Claude grand public prennent en charge les tâches récurrentes : vous enregistrez un prompt et une cadence, Claude l'exécute selon le calendrier et vous notifie avec le résultat. C'est le chemin sans code — idéal pour un briefing quotidien, une veille récurrente, un travail « résume mes newsletters non lues chaque matin ». Si vous n'êtes pas développeur, c'est par là que vous commencez. ### 2. Les routines Claude Code (pour ceux qui vivent dans le terminal) Si vous utilisez **Claude Code**, vous pouvez planifier un prompt ou une slash command pour qu'il s'exécute selon une cadence cron en tant qu'agent cloud — une « routine ». Elle tourne côté serveur sur votre dépôt ou espace de travail, donc elle fonctionne même quand votre ordinateur portable est fermé. Usages typiques : surveiller les pull requests ouverts, exécuter une passe de lint-et-correction nocturne, générer un brouillon de post chaque matin pour révision. Vous définissez le calendrier et la tâche ; Claude Code gère le déclenchement et le journal des exécutions. ### 3. Les déploiements Managed Agents (pour les développeurs qui créent des produits) Pour les équipes qui développent sur la Claude API, les **déploiements planifiés** exécutent un agent selon un calendrier cron récurrent — chaque déclenchement lance une session qui effectue le travail de façon autonome (un scan de conformité nocturne, un rapport hebdomadaire, un moniteur horaire). Vous obtenez un journal d'exécution par déclenchement pour auditer succès et échecs. C'est la version programmatique et de niveau production de la même idée. ## Comment penser le calendrier Les trois utilisent le même modèle mental — **quelle tâche, à quelle fréquence, que faire avec le résultat** : 1. **La tâche** — rédigez-la comme vous rédigeriez n'importe quel bon prompt d'agent : rôle, contexte, action précise, contraintes et une vérification. Une tâche planifiée ne peut pas vous poser une question de clarification en cours d'exécution, elle doit donc être *entièrement spécifiée à l'avance*. C'est la plus grande différence par rapport à l'usage interactif. 2. **La cadence** — quotidienne, hebdomadaire, horaire, jours ouvrés uniquement, une heure précise dans votre fuseau horaire. Faites-la correspondre à la vitesse à laquelle la chose sous-jacente évolue réellement ; un digest « quotidien » d'une source mise à jour chaque semaine, c'est des exécutions gaspillées. 3. **La livraison** — où atterrit le résultat (une notification, un fichier, un message, un brouillon). Décidez-en à l'avance pour que le résultat soit utile dès son arrivée. ## Les modèles qui en valent vraiment la peine - **Le digest matinal.** « Chaque jour ouvré à 7h, récupère les dernières infos sur [sujets], résume les trois points importants et envoie-moi un brief de 5 bullets. » Remplace 20 minutes de veille manuelle. - **Le rapport hebdomadaire.** « Chaque lundi, compile [métriques] en un résumé d'une page avec ce qui a changé et pourquoi. » Transforme une corvée récurrente en une revue. - **Le travailleur nocturne.** Une routine de code qui exécute un travail long et bien spécifié pendant que vous dormez — un refactor, un tour de tests, un nettoyage de données — pour que vous vous réveilliez avec un résultat à réviser. - **Le moniteur.** « Toutes les heures, vérifiez [chose] ; ne me contactez que si [condition] est vraie. » Les meilleures automatisations sont majoritairement silencieuses et ne parlent que quand c'est important. ## Conseils de configuration tirés de l'usage en production - **Sur-spécifiez le prompt.** Aucune question de clarification n'est possible en cours d'exécution. Indiquez le format, les sources, les contraintes et quoi faire dans les cas limites. - **Commencez par un test manuel.** Exécutez le prompt exact une fois à la main. S'il produit ce que vous voulez de façon interactive, planifiez-le. Sinon, corrigez d'abord le prompt — planifier un mauvais prompt ne produit que de mauvais résultats de façon fiable. - **Faites correspondre la cadence au taux de changement.** Ne lancez pas une exécution horaire sur quelque chose qui se met à jour chaque semaine. - **Gardez les résultats en brouillon quand les enjeux sont élevés.** Pour tout ce qui sort dans le monde — un post publié, un email envoyé — faites en sorte que la tâche produise un *brouillon* pour votre révision, pas une action en direct. Réservez le « fais-le simplement » entièrement autonome pour le travail peu risqué et réversible. - **Surveillez les premières exécutions.** Les tâches planifiées dérivent — une source change de format, un flux se tait. Vérifiez les premiers journaux d'exécution, puis faites-lui confiance. ## Tâches planifiées Claude — FAQ 2026 ### Que sont les tâches planifiées de Claude ? Ce sont des travaux récurrents : vous définissez un prompt ou un workflow d'agent ainsi qu'un calendrier de type cron, et Claude l'exécute automatiquement — quotidiennement, hebdomadairement, toutes les heures — en livrant le résultat sans que vous soyez au clavier. Elles existent dans les applications Claude grand public (pour les prompts personnels récurrents), dans Claude Code (sous forme de routines cloud) et dans la Claude API (sous forme de déploiements Managed Agents). ### Faut-il être développeur pour les utiliser ? Non. L'application Claude prend en charge les tâches récurrentes sans code — juste un prompt enregistré et une cadence. Les routines Claude Code et les déploiements Managed Agents sont les versions destinées aux développeurs pour automatiser les workflows de code et de produit. ### En quoi une tâche planifiée diffère-t-elle d'un chat Claude normal ? Un chat normal est interactif — vous êtes là pour répondre aux questions de suivi. Une tâche planifiée est autonome et récurrente, donc le prompt doit être entièrement spécifié à l'avance ; Claude ne peut pas faire une pause pour vous poser une question en cours d'exécution. Elle se déclenche selon le calendrier, effectue le travail et vous remet le résultat. ### Quelle est une bonne première tâche planifiée ? Un digest matinal. « Chaque jour ouvré à 7h, résume les dernières informations sur [vos sujets] en cinq bullets. » C'est peu risqué, facile à vérifier et remplace immédiatement une corvée manuelle récurrente — le modèle parfait pour apprendre le workflow avant d'automatiser quelque chose de plus important. ### Une tâche planifiée peut-elle prendre des actions réelles, comme envoyer des emails ? Oui, mais soyez délibéré. Pour un travail réversible et peu risqué, laissez-la agir. Pour tout ce qui est tourné vers l'extérieur ou difficile à annuler, faites en sorte que la tâche produise un brouillon que vous approuvez plutôt qu'un déclenchement automatique — surtout lors des exécutions sans surveillance. La réversibilité est le bon critère pour déterminer l'autonomie à accorder. **Lecture connexe :** [Le guide du débutant sur les agents IA](https://alejandrorioja.com/ai-agents-for-beginners-cowork-codex-guide/) · [Comment Anthropic gagne de l'argent](https://alejandrorioja.com/how-does-anthropic-make-money/) · [Comment être cité dans les réponses de ChatGPT](https://alejandrorioja.com/how-to-get-cited-in-chatgpt-answers/) --- **Vous voulez un système d'agents planifiés pour gérer vos travaux récurrents ?** C'est exactement ce que je construis — [contactez-moi](https://alejandrorioja.com/contact/). --- ## Le Calcul du Coût des Agents IA : Quand Haiku Bat Sonnet (et Quand Non) Source: https://alejandrorioja.com/fr/ai-agent-cost-math-when-haiku-beats-sonnet/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Choisir Claude Haiku plutôt que Sonnet peut réduire considérablement le coût par appel, mais seulement quand la tâche tolère un taux de réussite plus faible. La vraie métrique n'est pas le coût par appel — c'est le coût par résultat réussi, en incluant les nouvelles tentatives et le nettoyage humain. Je route par tâche, pas par défaut. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** Choisir Claude Haiku plutôt que Sonnet peut réduire le coût par appel d'un ordre de grandeur, mais seulement quand la tâche tolère le taux de réussite plus faible de Haiku. La métrique qui compte est le **coût par résultat réussi** — coût de l'appel plus les nouvelles tentatives plus le nettoyage humain — pas le prix affiché par token. Je route par tâche, et une part significative de mes étapes à fort volume tourne sur Haiku tandis que les décisions de jugement restent sur Sonnet. **Lecture de l'opérateur :** Je gère plus de 100 agents, et l'inférence est un poste de dépense réel. Mais j'ai vu des équipes « économiser » en forçant tout sur le modèle le moins cher, puis payer la facture en nouvelles tentatives, escalades et clients mécontents. Le calcul de coût ne fonctionne que quand on mesure tout l'entonnoir. Le modèle le moins cher n'est pas celui qui a le prix par token le plus bas. C'est celui qui a le coût total le plus bas pour faire le travail correctement. Ce sont des chiffres différents, et l'écart entre eux est là où la plupart des décisions de coût d'agents dérapent. ## L'économie des tokens, dite simplement Anthropic facture Claude au million de tokens, l'entrée et la sortie étant facturées séparément, la sortie coûtant plusieurs fois plus cher que l'entrée. Les chiffres exacts évoluent avec le temps, alors vérifiez les tarifs actuels d'Anthropic — mais c'est la **structure** qui guide la décision : - **Haiku** est le palier bon marché et rapide — de loin le coût par token le plus bas de la famille. - **Sonnet** se situe au milieu — nettement plus cher que Haiku, nettement moins cher qu'Opus. - **Opus** est le palier premium pour le raisonnement le plus difficile. Deux choses en découlent. D'abord, les tokens de sortie dominent le coût sur les tâches génératives, donc un modèle verbeux coûte plus cher même au même prix par token. Ensuite, l'écart de prix par token entre Haiku et Sonnet est suffisamment grand pour qu'à une étape à fort volume il se voie absolument sur la facture. C'est l'argument *en faveur* de Haiku. Maintenant l'argument contre. ## La métrique qui compte vraiment : le coût par résultat réussi Le coût par appel est un chiffre de vanité. Voici la formule que j'utilise réellement : ``` cout_par_succes = (cout_appel × tentatives) + cout_nettoyage ÷ taux_de_reussite ``` Où `tentatives` tient compte des nouvelles tentatives, et `cout_nettoyage` est le coût attendu d'un humain corrigeant les échecs qui passent au travers. Regardez ce que cela fait à la comparaison. Supposons que Haiku coûte environ un dixième de Sonnet par appel. Si Haiku réussit 80 % du temps sur une tâche et Sonnet 98 %, les économies par appel paraissent énormes. Mais si chaque échec de Haiku déclenche une nouvelle tentative et qu'1 sur 10 nécessite encore un humain qui coûte de l'argent réel, le terme de nettoyage peut engloutir les économies de tokens. Sur une tâche à faible enjeu et fort volume, le calcul favorise Haiku de façon écrasante. Sur une tâche où un échec envoie un e-mail au mauvais client, il peut s'inverser complètement. Vous ne pouvez pas trancher sans mesurer le taux de réussite par modèle — ce qui est exactement ce que vous donne un [banc d'évaluation](/the-eval-harness-i-use-to-ship-ai-agents/). Exécutez le même jeu d'évaluation contre les deux modèles et lisez les taux de réussite sur le même étalon. ## Là où Haiku gagne de façon décisive Haiku est le bon choix quand la tâche est **étroite, structurée et vérifiable** : - **Classification et routage** — « ce message entrant est-il une réservation, une réclamation ou du spam ? » Trois catégories, facile à vérifier, tourne en continu. Haiku toute la journée. - **Extraction avec un schéma** — extraire une date, un nom, un montant d'un texte, validé avec Zod. Si la sortie se parse, elle est presque certainement correcte. - **Réécritures courtes et formatage** — ajustements de ton, résumer une entrée connue comme bonne, normaliser des données. - **Filtrage de premier passage** — Haiku trie, et seuls les cas ambigus sont escaladés vers Sonnet. C'est le pattern à plus fort levier. Le fil commun : le coût d'une erreur de Haiku est faible et l'erreur est bon marché à détecter. Quand la vérification est bon marché et l'enjeu faible, le modèle bon marché gagne. ## Là où Sonnet mérite son prix Sonnet (et parfois Opus) en vaut la peine quand la tâche est **ouverte, multi-étapes ou coûteuse à rater** : - **Boucles d'agent multi-outils** où un mauvais appel d'outil se propage en cascade. Une plus grande fiabilité de raisonnement se cumule à travers les étapes — les patterns d'orchestration que je couvre dans [l'orchestration multi-agents](/multi-agent-orchestration-patterns-queues-state-handoffs/) reposent sur le fait que le modèle ne perde pas le fil. - **Génération face au client** où une mauvaise sortie coûte la confiance, pas seulement une nouvelle tentative. - **Tout ce où la vérification est elle-même difficile.** Si vous ne pouvez pas dire à bas coût si la sortie est correcte, vous ne pouvez pas vous permettre un modèle qui se trompe souvent. Un échec ici ne coûte pas une nouvelle tentative — il coûte un remboursement, un client perdu, ou mon temps. Face à cela, la prime par token est une erreur d'arrondi. ## La règle de routage que je déploie réellement Je ne choisis pas un modèle par agent. Je route par **tâche** à l'intérieur de l'agent, généralement avec un classificateur bon marché qui décide quel modèle en aval traite le travail : ```typescript function pickModel(task: Task): string { // Bon marché, vérifiable, fort volume → Haiku if (task.type === "classify" || task.type === "extract") { return "claude-haiku"; } // Ouvert ou face au client → Sonnet if (task.customerFacing || task.steps > 2) { return "claude-sonnet"; } return "claude-sonnet"; // par défaut, le choix sûr } ``` Deux principes encodés ici. **Par défaut, le modèle sûr**, pas le bon marché — on optimise le coût *vers le bas* depuis une base qui fonctionne, jamais la fiabilité *vers le haut* depuis une base cassée. Et **escaladez, ne pariez pas** : laissez Haiku gérer les 80 % faciles et confiez les 20 % difficiles à Sonnet. Cet hybride bat presque toujours le fait de tout faire tourner sur l'un ou l'autre modèle seul. Il y a aussi le cache de prompts à ajouter par-dessus : si votre prompt système est volumineux et réutilisé, le cache réduit substantiellement le coût d'entrée quel que soit le palier, ce qui rend parfois Sonnet assez bon marché pour que la question de Haiku devienne sans objet. ## Un exemple travaillé issu de mon propre stack Prenez une étape de triage de messages entrants à fort volume. Elle tourne des milliers de fois, la tâche est une classification à trois voies, et une erreur signifie simplement que l'élément atterrit dans une file de revue — bon marché à détecter, faible enjeu. C'est une tâche Haiku de manuel, et la sortir de Sonnet a réduit significativement le coût de cette étape sans impact mesurable sur le résultat qui comptait. Maintenant prenez l'étape qui rédige la vraie réponse au client. Volume plus faible, ouverte, et un mauvais brouillon qui part coûte la confiance. Celle-là reste sur Sonnet. Même agent, deux modèles, routés par enjeu. Je surveille le coût par exécution et les métriques de réussite des deux, comme je le décris dans [comment je mesure si un agent IA fonctionne vraiment](/how-i-measure-whether-an-ai-agent-is-actually-working/) — et je ne fais descendre une étape d'un palier qu'après que l'évaluation a dit que le modèle moins cher maintient le taux de réussite. ## FAQ ### Claude Haiku est-il toujours moins cher que Sonnet en pratique ? Par token, oui — de loin. Par résultat réussi, pas toujours. Si le taux de réussite plus faible de Haiku déclenche des nouvelles tentatives et du nettoyage humain, le coût total peut dépasser celui de Sonnet sur des tâches où les erreurs sont coûteuses à détecter ou corriger. ### Comment décider entre Haiku et Sonnet pour une tâche donnée ? Notez la tâche sur deux axes : à quel point la sortie est vérifiable et à quel point une erreur est coûteuse. Le travail bon marché à vérifier, à faible enjeu et fort volume va à Haiku ; le travail ouvert, face au client ou difficile à vérifier va à Sonnet. Routez par tâche, pas par agent. ### Quelle est l'unique métrique de coût que je dois suivre ? Le coût par résultat réussi — coût de l'appel multiplié par les tentatives plus le coût de nettoyage attendu, divisé par le taux de réussite. Le prix par appel seul cache les nouvelles tentatives et le temps humain, là où les modèles bon marché deviennent discrètement chers. ### Puis-je utiliser les deux modèles dans un seul agent ? Oui, et vous devriez généralement le faire. Le pattern le plus fort est un premier passage bon marché (Haiku classe ou filtre) qui n'escalade que les cas ambigus vers Sonnet. Cet hybride bat typiquement le fait de tout faire tourner sur un seul palier. --- ## Comment Déboguer un Agent IA en Production (Guide de Terrain) Source: https://alejandrorioja.com/fr/how-to-debug-an-ai-agent-in-production/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Déboguer un agent IA en production consiste surtout à isoler la couche qui a échoué — prompt, outil, modèle ou orchestration. Je journalise chaque étape avec un ID de trace, je rejoue les entrées exactes et je dichotomise. Dans mes agents, ~70 % des 'bugs IA' s'avèrent être des bugs de tuyauterie, pas du modèle. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** Déboguer un agent IA en production consiste surtout à isoler la couche qui a échoué — prompt, appel d'outil, sortie du modèle ou orchestration. Je journalise chaque étape avec un ID de trace, je rejoue les entrées exactes et je dichotomise à partir de là. Dans mes agents, environ 70 % de ce qui ressemble à un « bug IA » s'avère être de la tuyauterie : un résultat d'outil malformé, une entrée tronquée, une exception silencieusement avalée. **Lecture de l'opérateur :** J'exploite plus de 100 agents en production — flux de réservation pour Pickleland, pipelines de contenu, tri de boîtes de réception. Ils cassent comme tout logiciel casse, plus quelques nouvelles façons. Voici le guide de terrain que j'aurais aimé avoir : comment trouver la couche défaillante sans fixer un mur de tokens. Quand un agent se comporte mal en production, l'instinct est de blâmer le modèle. « Claude a halluciné. » Parfois vrai. Généralement non. Le modèle est une couche dans une pile de cinq ou six, et le bug est bien plus souvent dans la couche que vous avez écrite que dans celle qu'Anthropic a livrée. Cet article décrit la manière systématique dont je le trouve. ## Rendez chaque exécution traçable avant de déboguer quoi que ce soit Vous ne pouvez pas déboguer ce que vous ne pouvez pas voir. La chose la plus efficace que vous puissiez faire — avant qu'un bug spécifique n'apparaisse — est d'attacher un ID de trace à chaque exécution de l'agent et de journaliser chaque étape qu'il franchit. Une « étape » est tout ce qui traverse une frontière : le déclencheur entrant, chaque appel au modèle (avec le tableau complet des messages), chaque appel d'outil (avec les arguments), chaque résultat d'outil et la sortie finale. Journalisez-les sous forme de JSON structuré indexé par l'ID de trace. ```typescript function logStep(traceId: string, step: string, payload: unknown) { console.log(JSON.stringify({ traceId, step, // "trigger" | "model_call" | "tool_call" | "tool_result" | "output" ts: Date.now(), payload, })); } ``` Sur Cloudflare Workers, je les envoie vers une file d'attente et dans une table ; en local, ils vont vers stdout. La règle est absolue : si une étape n'est pas journalisée, elle n'a pas eu lieu du point de vue du débogage. Cela reflète l'instrumentation que je décris dans [la stack d'agents que j'utilise](/the-agent-stack-i-use-to-run-30-production-agents-no-python/) — l'ID de trace est la colonne vertébrale à laquelle tout le reste est accroché. ## Isolez la couche : prompt, outil, modèle ou orchestration Une fois que vous avez une trace, le débogage devient une dichotomie. Il y a quatre couches et le bug réside dans exactement l'une d'entre elles la plupart du temps. ### 1. La couche d'entrée (le coupable le plus fréquent) Extrayez le tableau `messages` exact qui est entré dans l'appel au modèle défaillant. Pas une reconstruction — le payload littéral du journal. Puis lisez-le comme le ferait un inconnu. La moitié de mes bugs « le modèle a ignoré les instructions » sont en réalité : - Un résultat d'outil revenu sous la forme `"[object Object]"` parce que quelque chose a été mal converti en chaîne. - Une entrée tronquée en plein milieu d'une phrase parce qu'elle a fait exploser la fenêtre de contexte et qu'un découpage naïf l'a coupée. - Une variable interpolée en `undefined` qui a silencieusement empoisonné le prompt. Si l'entrée est mauvaise, le modèle a parfaitement fait son travail sur des déchets. Réparez la tuyauterie. ### 2. La couche outil Si l'entrée semble propre, vérifiez si un outil a renvoyé une erreur que l'agent a traitée comme un succès. Un classique : une API renvoie `200` avec un corps `{ "error": "rate limited" }`, votre wrapper d'outil ne vérifie pas le corps, et l'agent agit avec assurance sur un message d'erreur. Journalisez les résultats d'outil bruts et vérifiez leur forme. ### 3. La couche modèle Ce n'est qu'après avoir écarté 1 et 2 que je soupçonne le modèle. Même alors, « bug du modèle » signifie généralement « mon prompt est ambigu ». Prenez l'entrée exacte défaillante, déposez-la dans un script ponctuel contre le même modèle et la même température, et voyez si cela se reproduit. Si c'est le cas, la solution est un travail de prompt ou une [eval plus serrée](/the-eval-harness-i-use-to-ship-ai-agents/), pas un changement frénétique de modèle. ### 4. La couche d'orchestration Si une seule étape fonctionne en isolation mais que l'exécution multi-étapes échoue, le bug est dans le passage de relais — état perdu entre les étapes, condition de concurrence, nouvelle tentative qui a réexécuté une action non idempotente. Ce sont les plus pernicieux et je couvre les patrons dans [les patrons d'orchestration multi-agents](/multi-agent-orchestration-patterns-queues-state-handoffs/). ## Reproduisez le non-déterminisme au lieu de le combattre Ce qui rend les agents apparemment indéboguables, c'est le non-déterminisme : la même entrée produit une sortie différente selon les exécutions. Vous pouvez le dompter. D'abord, **figez ce que vous pouvez.** Mettez `temperature: 0` pendant le débogage. Cela ne rendra pas Claude totalement déterministe, mais cela réduit fortement la variance pour que vous puissiez distinguer un vrai bug du bruit d'échantillonnage. Ensuite, **exécutez-le N fois.** Si une défaillance se reproduit 1 fois sur 20, bouclez l'entrée exacte 50 fois et capturez chaque sortie. Vous avez maintenant un échantillon, pas une anecdote. Un bug qui se déclenche 5 % du temps est un vrai bug — il vous faut juste du volume pour le voir. ```bash for i in $(seq 1 50); do node replay.mjs --trace=abc123 >> runs.jsonl done # puis comptez les échecs grep -c '"status":"fail"' runs.jsonl ``` Troisièmement, **comparez les exécutions réussies et échouées.** Avec la température figée et la même entrée, une différence de sortie signifie une différence d'entrée que vous n'avez pas encore repérée — un horodatage dans le prompt, un résultat d'outil qui varie, un document récupéré qui a changé. ## Construisez un harnais de rejeu pour cesser de déboguer en production Déboguer en redéclenchant l'agent en direct est lent et risqué — il envoie de vrais e-mails, réserve de vrais terrains. À la place, capturez la trace et rejouez-la hors ligne. Le harnais de rejeu charge une trace journalisée, reconstruit les entrées exactes de n'importe quelle étape et réexécute uniquement cette étape contre le modèle. Comme vous avez journalisé le tableau complet `messages`, vous n'avez pas du tout besoin du système en amont. Cela transforme un aller-retour de 10 minutes en production en une boucle locale de 2 secondes, et c'est la plus grande accélération de mon flux de débogage. Un bon harnais de rejeu vous permet aussi de **muter et réexécuter** : changez une ligne du prompt système, rejouez les mêmes 50 traces défaillantes et voyez combien passent désormais. C'est le pont entre le débogage et l'eval — une fois que vous avez un corpus de traces défaillantes, vous avez le début d'une suite de régression. ## Surveillez les métriques qui prédisent réellement les pannes Certaines défaillances ne lèvent jamais d'exception. L'agent s'exécute, renvoie quelque chose de plausible et fait silencieusement la mauvaise chose. Pour les attraper, vous surveillez des métriques comportementales, pas seulement des taux d'erreur : - **Taux de réussite des appels d'outil** par outil. Une baisse ici précède souvent une défaillance visible. - **Validité du schéma de sortie** — quel % des sorties parsent contre la structure attendue. Je valide chaque sortie avec Zod et j'alerte quand la validité baisse. - **Longueur de boucle** — nombre moyen d'étapes par exécution. Un pic soudain signifie généralement que l'agent est coincé à réessayer. - **Coût par exécution** — une boucle incontrôlée apparaît comme un pic de coût avant d'apparaître comme une plainte. (Quand le coût compte, les [calculs Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet) valent la peine d'être connus.) Je suis ces métriques comme je suis tout le reste — voir [comment je mesure si un agent IA fonctionne réellement](/how-i-measure-whether-an-ai-agent-is-actually-working/). La métrique qui attrape une défaillance silencieuse en vaut dix qui attrapent les bruyantes. ## La checklist de triage de 5 minutes Quand un agent casse et que je suis contre la montre, je déroule ceci dans l'ordre : 1. **Récupérez l'ID de trace** de l'exécution défaillante. 2. **Lisez l'entrée exacte** de l'étape défaillante. Est-elle bien formée ? (Résout ~50 % des cas ici.) 3. **Vérifiez les résultats d'outil** dans cette trace pour des erreurs déguisées en succès. 4. **Rejouez l'étape hors ligne** à `temperature: 0`. Se reproduit-elle ? 5. **Si elle se reproduit,** c'est un problème de prompt/modèle — corrigez et réexécutez le corpus de traces. **Sinon,** c'est du non-déterminisme ou un bug d'état/orchestration — bouclez-le 50× pour le caractériser. Une isolation disciplinée bat un prompting astucieux à tous les coups. Le modèle est rarement le problème ; le système autour de lui l'est généralement. ## FAQ ### Comment déboguer un agent IA qui n'échoue que parfois ? Capturez l'entrée exacte d'une trace journalisée et rejouez-la plus de 50 fois à température 0. Les défaillances intermittentes sont de vrais bugs à faible taux de déclenchement — le volume transforme l'anecdote en un échantillon reproductible que vous pouvez comparer et corriger. ### Le bug est-il généralement dans le modèle ou dans mon code ? Dans mes agents de production, environ 70 % des apparents « bugs IA » sont de la tuyauterie : résultats d'outil malformés, entrées tronquées, exceptions avalées ou état perdu entre les étapes. Écartez les couches d'entrée et d'outil avant de soupçonner le modèle. ### Quel est le minimum de journalisation nécessaire pour déboguer des agents ? Un ID de trace sur chaque exécution, plus des journaux structurés du déclencheur, de chaque appel au modèle (tableau complet des messages), de chaque appel d'outil et de son résultat brut, et de la sortie finale. Si une étape n'est pas journalisée, vous ne pouvez pas la déboguer. ### Comment cesser de déboguer contre la production en direct ? Construisez un harnais de rejeu qui charge une trace journalisée et réexécute n'importe quelle étape unique hors ligne en utilisant les entrées capturées. Il transforme un aller-retour lent et risqué en production en une boucle locale rapide et devient la graine de votre suite de régression. --- ## Comment Mesurer si la Recherche par IA vous Envoie Vraiment du Trafic Source: https://alejandrorioja.com/fr/how-to-measure-ai-search-traffic/ Published: 2026-06-08 Tags: GEO, Analytics TL;DR: La majorité du trafic de la recherche par IA apparaît comme un filet de références venant de chatgpt.com, perplexity.ai et claude.ai — mais l'effet le plus important est sombre : les gens lisent la réponse de l'IA et ne cliquent jamais. Je mesure les deux, en utilisant les référents pour les clics et la hausse des recherches de marque pour l'influence. ## Table des matières _Mis à jour en juin 2026._ **TL;DR :** La majorité du trafic de la recherche par IA arrive comme un mince flux de références venant de `chatgpt.com`, `perplexity.ai` et `claude.ai` — facile à compter une fois que vous savez où regarder. Mais l'effet le plus important est **sombre** : les gens lisent la réponse de l'IA, absorbent votre marque et ne cliquent jamais. Je suis les clics avec des segments de référent et l'influence avec la hausse des recherches de marque, les variations du trafic direct et la surveillance des citations. Ne compter que les clics sous-estime gravement la recherche par IA. **Lecture de l'opérateur :** Je gère un moteur de contenu et je surveille ses analyses quotidiennement. La question « est-ce que la recherche par IA m'envoie du trafic ? » a une réponse frustrante : oui, mais l'essentiel de la valeur n'apparaît pas dans votre rapport de sessions. Voici comment je mesure la partie visible et déduis celle qui ne l'est pas. Tout le monde veut un seul chiffre : « combien de trafic ChatGPT m'envoie-t-il ? ». La réponse honnête est que la recherche par IA produit deux effets très différents, et il vous faut deux mesures distinctes. Confondez-les et soit vous paniquerez (les clics paraissent minuscules), soit vous vous illusionnerez (vous manquerez l'impact réel). ## Effet 1 : Références directes — comptables, et plus faibles qu'on l'espérerait Quand quelqu'un clique sur une citation à l'intérieur de ChatGPT, Perplexity ou une réponse de Claude, votre analytique enregistre un référent. Ce sont des sessions réelles et attribuables. Dans GA4 ou tout outil d'analyse, construisez un segment qui capte les moteurs d'IA : ``` session source matches any of: chatgpt.com chat.openai.com perplexity.ai claude.ai gemini.google.com copilot.microsoft.com ``` Enregistrez-le comme un canal « Recherche par IA » et observez-le dans le temps. Quelques mises en garde qui piègent les gens : - **Les référents fuient.** Certaines surfaces d'IA suppriment ou altèrent le référent, donc une partie des clics IA authentiques atterrissent dans « Direct » à la place. Votre décompte de références est un plancher, pas la vérité. - **Le volume est faible par rapport aux impressions de la réponse.** Les moteurs d'IA répondent à la question sur la page ; seule la minorité curieuse clique. Une poignée de références quotidiennes peut correspondre à bien plus de personnes qui vous ont vu cité. Le segment de références est donc nécessaire mais insuffisant. Il vous dit que la recherche par IA envoie *un peu* de trafic. Il sous-estime gravement l'influence. ## Effet 2 : Influence sombre — la moitié la plus grande et la plus difficile à voir La véritable action est sans clic. Quelqu'un pose une question à ChatGPT, votre marque apparaît dans la réponse comme source recommandée, et il ne clique jamais — il se souvient simplement de vous. Cela se manifeste plus tard sous forme de **recherche de marque** ou de **visite directe**, attribuée à rien. C'est la même dynamique qui rendait les extraits optimisés frustrants à mesurer, amplifiée. Vous ne pouvez pas mesurer l'influence sombre directement, mais vous pouvez la trianguler : 1. **Volume des recherches de marque.** Suivez les recherches de votre nom/marque dans Google Search Console au fil du temps. Si vous commencez à être cité par les moteurs d'IA et que vos impressions de marque augmentent sans campagne correspondante, cette hausse est une empreinte de l'influence de l'IA. 2. **Tendance du trafic direct.** Une hausse soutenue des sessions « Direct » qui ne suit aucune campagne reflète souvent des références IA dépouillées de leur référent, plus des gens qui vous tapent directement après une mention de l'IA. 3. **Conversions assistées.** Regardez si les sessions de recherche par IA, même rares, apparaissent comme le *premier* contact dans des parcours qui convertissent. Un canal minuscule au dernier clic peut être significatif au premier contact. Aucun de ces éléments n'est un chiffre propre. Ensemble, ils vous disent si la moitié sombre bouge. ## Suivez les citations, pas seulement les clics Voici la métrique qui m'importe le plus pour la recherche par IA, et elle n'est pas du tout dans votre analytique : **suis-je cité, et pour quelles requêtes ?** Maintenez une liste des 20 à 40 requêtes qui comptent pour votre activité et passez-les dans ChatGPT, Perplexity et Claude de façon planifiée — une fois par semaine suffit largement. Notez, pour chaque requête et moteur : êtes-vous cité, et à quelle position ? C'est l'équivalent GEO du suivi de positions, et c'est l'indicateur avancé. Les citations bougent *avant* le trafic en aval et la hausse de marque, donc c'est là que vous voyez si votre [travail GEO pour les commerces locaux](/geo-for-local-business-getting-a-brick-and-mortar-cited-by-ai-search/) porte ses fruits. J'ai construit un petit agent qui exécute ces vérifications et enregistre les résultats — le genre de chose qui devient trivial une fois que vous avez une pile d'agents. Si vous préférez le faire à la main, un tableur et une passe hebdomadaire de 30 minutes fonctionnent bien pour commencer. La méthodologie reflète mon [test de citations ChatGPT vs Google](/chatgpt-search-vs-google-50-term-test/), exécuté en continu plutôt qu'une seule fois. ## Construisez le tableau de bord : quatre chiffres, chaque semaine Je ne me noie pas dans les métriques. Pour la recherche par IA, je surveille quatre choses et je les passe en revue chaque semaine : 1. **Sessions de référence IA** — les clics comptables du segment de référent. Tendance, pas valeur absolue. 2. **Couverture des citations** — % de mes requêtes suivies où je suis cité sur les trois moteurs. L'indicateur avancé. 3. **Impressions de recherche de marque** — depuis Search Console, comme proxy de l'influence sombre. 4. **Conversions issues de l'IA** — même si elles sont rares, savoir si les sessions IA initient parfois un parcours qui convertit. Si la couverture des citations augmente alors que les sessions de référence restent plates, ce n'est *pas* un échec — cela signifie généralement que la moitié sombre grandit et que le chiffre des recherches de marque devrait suivre. Si la couverture des citations baisse, c'est une alerte précoce pour agir avant qu'un chiffre de trafic ne bouge. C'est la même discipline du « mesurer l'indicateur avancé » que j'applique aux agents dans [comment je mesure si un agent d'IA fonctionne vraiment](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Que faire des chiffres La mesure n'est utile que si elle change ce que vous faites. Le plan de jeu : - **Couverture de citations faible pour une requête qui vous tient à cœur ?** C'est un problème de contenu + [schema](/schema-markup-for-ai-engines-the-types-that-punch-above-their-weight/). La page soit n'existe pas, soit n'est pas structurée pour l'extraction, soit n'est pas assez faisant autorité pour être intégrée à la réponse. - **Cité mais sans trafic de référence ?** Attendu et très bien — la recherche par IA fait du travail de marque, pas du travail de clic. Ne le « réparez » pas en courant après les clics ; misez sur le fait d'être la source citée. - **Des références d'un moteur mais pas des autres ?** Les moteurs divergent fortement sur les sources (j'ai mesuré ~40 % de chevauchement entre ChatGPT et Google). Être cité par l'un ne vous obtient pas les autres — travaillez la couverture de chaque moteur séparément. ## Une note sur l'honnêteté de l'attribution Résistez à l'envie de revendiquer une précision que vous n'avez pas. La mesure de la recherche par IA en 2026 est de la triangulation, pas de l'attribution. Quiconque vous vend un chiffre propre du genre « ChatGPT vous a rapporté X dollars » exagère ce qui est connaissable, car les référents fuient et l'effet le plus important est sans clic par conception. La bonne posture : comptez ce que vous pouvez compter, surveillez les proxies pour ce que vous ne pouvez pas, et décidez sur la tendance. La tendance est fiable même quand le chiffre absolu ne l'est pas. ## FAQ ### Comment voir le trafic de ChatGPT ou Perplexity dans GA4 ? Construisez un canal/segment correspondant aux domaines des moteurs d'IA — chatgpt.com, chat.openai.com, perplexity.ai, claude.ai, gemini.google.com, copilot.microsoft.com — comme source de session. Cela capte les références issues des clics, bien que certaines soient dépouillées en « Direct », donc traitez le décompte comme un plancher. ### Pourquoi mon trafic de référence de recherche par IA est-il si faible ? Parce que la recherche par IA est surtout sans clic — le moteur répond sur la page et seule une minorité clique. Les faibles décomptes de références coïncident souvent avec des impressions de citations bien plus grandes. Mesurez les citations et la hausse des recherches de marque pour voir la partie que les références manquent. ### Quel est le meilleur indicateur avancé pour la recherche par IA ? La couverture des citations : le pourcentage de vos requêtes critiques pour l'activité, suivies, où vous êtes cité sur ChatGPT, Perplexity et Claude. Elle bouge avant le trafic et la hausse de marque, donc elle vous dit tôt si votre travail GEO porte ses fruits. ### Puis-je obtenir une attribution exacte des revenus de la recherche par IA ? Non, pas de façon fiable en 2026. Les référents fuient vers Direct et l'essentiel de l'impact est sans clic par conception. Traitez la mesure de la recherche par IA comme une triangulation — comptez les clics, surveillez les proxies de recherche de marque et de trafic direct, et décidez sur la tendance, pas sur un chiffre en dollars faussement précis. --- ## Patterns d'Orchestration Multi-Agents : Files, État et Transferts Source: https://alejandrorioja.com/fr/multi-agent-orchestration-patterns-queues-state-handoffs/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Les systèmes multi-agents fiables ne reposent pas sur des prompts astucieux — ils reposent sur l'ennuyeuse discipline des systèmes distribués : des files durables entre agents, un état conservé hors du modèle et des transferts idempotents qui survivent aux réessais. Le modèle est l'ouvrier ; la file est la colonne vertébrale. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** Les systèmes multi-agents fiables ne se gagnent pas avec des prompts astucieux — ils se gagnent avec l'ennuyeuse discipline des systèmes distribués. Placez une **file** durable entre les agents, conservez l'**état hors du modèle** et rendez chaque **transfert idempotent** pour qu'un réessai ne puisse pas agir deux fois. Le modèle est l'ouvrier ; la file est la colonne vertébrale. Réussissez ces trois points et l'orchestration cesse d'être effrayante. **Lecture de l'opérateur :** La plupart de mes plus de 100 agents sont à étape unique. Ceux qui ne le sont pas — les pipelines qui classent, puis enrichissent, puis agissent — ne sont devenus fiables que lorsque j'ai cessé de penser « chaîne de prompts » et commencé à penser « file de tâches avec des ouvriers LLM ». C'est de l'architecture, pas de l'ingénierie de prompts. « Multi-agents » donne l'impression que les agents se parlent entre eux. En pratique, la version fiable est l'inverse : les agents ne communiquent pas directement du tout. Ils déposent des messages sur une file et récupèrent du travail dans une file, et l'orchestration vit dans la plomberie entre eux. Voici les patterns qui tiennent en production. ## Pattern 1 : Placez une file durable entre chaque agent Le premier réflexe est d'appeler l'agent B directement depuis l'agent A. Ne le faites pas. Les appels directs couplent les deux : si B est lent, A se bloque ; si B échoue, le travail de A est perdu ; si vous devez mettre B à l'échelle, vous ne le pouvez pas sans toucher à A. À la place, A termine son travail et **met un message en file** pour B. B est un ouvrier séparé qui vide la file à son propre rythme. ```typescript // L'agent A termine et transfère via la file — pas d'appel direct à B await env.ENRICH_QUEUE.send({ traceId, type: "enrich", payload: classifierResult, }); // Le travail de A est fait. B le récupérera de manière indépendante. ``` Sur Cloudflare j'utilise Workers Queues exactement pour cela — les mêmes primitives derrière [la stack d'agents que j'utilise](/the-agent-stack-i-use-to-run-30-production-agents-no-python/). La file vous offre quatre choses gratuitement : le **buffering** (B peut être hors service sans perdre de travail), les **réessais** (les messages en échec sont redélivrés), la **contre-pression** (un pic se met en file au lieu de planter) et le **découplage** (mettez à l'échelle ou redéployez B sans toucher à A). Chacune de ces choses est quelque chose que vous devriez sinon construire à la main et rater. ## Pattern 2 : Conservez l'état hors du modèle, toujours Le bug multi-agents le plus courant est de supposer que le modèle se souvient de quoi que ce soit entre les étapes. Ce n'est pas le cas. Chaque appel de modèle est sans état ; la seule mémoire est ce que vous mettez dans le prompt. Donc la source de vérité pour « où en est cette tâche dans le pipeline » doit vivre dans une base de données, pas dans une conversation. Je conserve un seul enregistrement de tâche que chaque agent lit et met à jour : ```typescript interface JobState { traceId: string; stage: "classified" | "enriched" | "acted" | "done" | "failed"; data: Record; attempts: number; updatedAt: number; } ``` Chaque agent effectue la même boucle : **lire** l'état de la tâche, faire son travail, **écrire** le nouvel état, mettre en file l'étape suivante. Le modèle ne détient jamais l'état — il reçoit la tranche pertinente en entrée et renvoie un résultat. C'est ce qui rend le système redémarrable : si un ouvrier meurt en pleine tâche, l'enregistrement d'état indique toujours exactement où en étaient les choses, et le message de file redélivré reprend à partir de là. Cela rend aussi le débogage gérable, car la table d'état est un enregistrement interrogeable du parcours de chaque tâche — le même état d'esprit d'instrumentation que dans [comment je mesure si un agent fonctionne](/how-i-measure-whether-an-ai-agent-is-actually-working/). ## Pattern 3 : Rendez chaque transfert idempotent Les files garantissent une livraison *au moins une fois*, pas exactement une fois. Cela signifie qu'un message peut être livré deux fois — coupures réseau, réessais, redéploiements. Si l'action de votre agent n'est pas idempotente, une double livraison agit deux fois : deux e-mails de confirmation, deux réservations, deux débits. C'est la classe de bug d'orchestration la plus pernicieuse, et c'est celle que les équipes découvrent en production. La solution est de rendre les actions idempotentes avec une clé : ```typescript async function handleEnrich(msg: QueueMessage, env: Env) { const job = await getJob(env, msg.traceId); if (job.stage !== "classified") { // Déjà traité au-delà de cette étape — c'est une livraison en double. Ignorer. return; } const result = await enrich(job.data); await advanceJob(env, msg.traceId, "enriched", result); await env.ACT_QUEUE.send({ traceId: msg.traceId, type: "act" }); } ``` La vérification d'étape rend l'opération sûre à exécuter deux fois : la seconde livraison voit que la tâche a déjà avancé et ne fait rien. Pour les effets de bord externes (envoyer un e-mail, débiter une carte), passez une clé d'idempotence à l'API en aval pour qu'*elle* déduplique aussi. Supposez que chaque message sera livré deux fois et concevez de sorte que ce soit inoffensif — car tôt ou tard ce sera le cas. ## Pattern 4 : Orchestrateur vs chorégraphie — choisissez délibérément Il y a deux façons de câbler le flux, et le bon choix dépend de la complexité. **Chorégraphie** (ce que j'utilise par défaut) : chaque agent ne connaît que l'étape suivante et la met en file. Le flux émerge de la chaîne. Simple, décentralisée, facile à étendre — ajoutez une étape en insérant une file. L'inconvénient est qu'aucun endroit unique ne décrit le flux entier, donc un pipeline complexe peut devenir difficile à appréhender. **Orchestration** (un coordinateur central) : un orchestrateur possède le flux, appelle chaque agent à tour de rôle et décide de la suite en fonction des résultats. Tout le flux vit dans un endroit unique et lisible, et la logique de branchement est explicite. Le coût est un composant central qui doit lui-même être durable — si l'état propre de l'orchestrateur n'est pas externalisé (Pattern 2), il devient le point unique de défaillance. Ma règle : **la chorégraphie jusqu'à ce que le branchement devienne complexe, puis un orchestrateur durable.** Un pipeline linéaire à trois étapes, c'est de la chorégraphie. Un flux avec routage conditionnel, fan-out parallèle et jointures veut un orchestrateur dont l'état vit dans la base de données pour qu'il puisse reprendre après un plantage. ## Pattern 5 : Fan-out, fan-in sans perdre de pièces Quand une tâche engendre N sous-tâches parallèles (enrichir 50 enregistrements, résumer 20 documents) et que vous devez toutes les attendre avant de continuer, il vous faut une **jointure** (join). L'astuce est un compteur dans l'état de la tâche : 1. Le parent met en file N messages enfants et écrit `expected: N, completed: 0` dans l'enregistrement de la tâche. 2. Chaque enfant fait son travail et **incrémente atomiquement** `completed`. 3. L'enfant qui porte `completed` à égaler `expected` met en file l'étape suivante. L'incrément atomique est crucial — sans lui, deux enfants qui terminent simultanément peuvent tous deux croire qu'ils ne sont pas le dernier, et la jointure ne se déclenche jamais. Utilisez un compteur que le datastore peut incrémenter atomiquement, ou une transaction. Ce pattern vous permet de paralléliser le milieu coûteux d'un pipeline (souvent du travail bon marché pour Haiku — voir les [calculs de coût Haiku vs Sonnet](/ai-agent-cost-math-when-haiku-beats-sonnet)) tout en gardant une jointure propre à la fin. ## Ce que j'éviterais Vous n'avez pas besoin d'un framework d'agents lourd pour faire tout cela. Les files, une table d'état et les clés d'idempotence sont des primitives que toute plateforme possède déjà. J'ai vu des équipes se tourner vers des frameworks multi-agents élaborés pour obtenir des fonctionnalités qu'une file leur offre gratuitement, et hériter d'une boîte noire plus difficile à déboguer que la plomberie qu'elle remplaçait. Commencez par les ennuyeuses primitives. Tournez-vous vers un framework seulement quand vous avez ressenti une douleur précise qu'il résout. Le résumé : les agents sont des ouvriers sans état, les files sont la colonne vertébrale durable, l'état vit dans une base de données et chaque transfert est sûr à exécuter deux fois. C'est tout le jeu. ## FAQ ### Les agents doivent-ils s'appeler directement ou passer par une file ? Par une file. Les appels directs couplent les agents — l'échec ou la lenteur de l'un se propage à l'autre, et vous ne pouvez pas mettre à l'échelle ni redéployer de manière indépendante. Une file durable vous offre buffering, réessais, contre-pression et découplage gratuitement. ### Où l'état multi-agents doit-il vivre ? Hors du modèle, dans une base de données, sous forme d'enregistrement de tâche que chaque agent lit et met à jour. Les appels de modèle sont sans état, donc la source de vérité pour la progression du pipeline doit être externe — c'est ce qui rend le système redémarrable après un plantage. ### Comment empêcher un agent d'agir deux fois sur la même tâche ? Rendez les transferts idempotents. Vérifiez l'étape de la tâche avant d'agir et ne faites rien si elle a déjà avancé, et passez des clés d'idempotence aux API externes. Les files livrent au moins une fois, donc supposez que chaque message peut arriver deux fois et concevez de sorte que les doublons soient inoffensifs. ### Ai-je besoin d'un framework multi-agents ? Généralement non. Des files durables, une table d'état et des clés d'idempotence couvrent la plupart des besoins de production avec des primitives que votre plateforme fournit déjà. N'adoptez un framework que lorsque vous rencontrez un problème concret qu'il résout de manière unique, pas par défaut. --- ## Le Harness d'Évals que J'Utilise pour Déployer des Agents IA Sans Peur Source: https://alejandrorioja.com/fr/the-eval-harness-i-use-to-ship-ai-agents/ Published: 2026-06-08 Tags: AI Agents, Operations TL;DR: Déployer des agents sans peur tient à une seule chose : un harness d'évals. Un ensemble fixe de cas de test notés, scorés automatiquement (assertions plus un juge LLM), exécuté avant chaque changement de prompt ou de modèle. Si le score tient, on déploie. Le jeu de tests est construit à partir d'échecs réels en production. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** La raison pour laquelle je peux changer un prompt ou échanger un modèle sur un agent en production sans retenir mon souffle tient à une seule chose : un **harness d'évals**. Un ensemble fixe de cas de test notés, scorés automatiquement — des assertions strictes là où je peux les écrire, un juge LLM là où je ne peux pas — exécuté avant chaque changement. Le score tient, je déploie. Le score baisse, je m'abstiens. Le jeu de tests n'est pas synthétique ; il est construit à partir d'échecs réels en production, donc chaque bug devient un test de régression permanent. **Lecture de l'opérateur :** Sur plus de 100 agents, la différence entre ceux que je touche avec confiance et ceux qui me font peur, c'est de savoir s'ils ont des évals. Pas de harness d'évals signifie que chaque ajustement de prompt est un pari. Un harness d'évals transforme « je pense que c'est mieux » en « c'est mesurablement 4 points de mieux et ça n'a rien cassé ». C'est tout le déverrouillage. Tu ne déploierais pas du code sans tests. Les gens déploient des agents sans évals en permanence, puis se demandent pourquoi un « minuscule ajustement de prompt » a cassé la production. Un harness d'évals est la suite de tests pour les logiciels non déterministes. Voici celui que j'exécute réellement. ## Commence avec un jeu de tests construit à partir d'échecs réels Le harness ne vaut que ses cas de test, et les meilleurs cas de test viennent de la production, pas de ton imagination. Chaque fois qu'un agent échoue dans la nature, je capture l'entrée exacte (je journalise chaque exécution avec un ID de trace — voir [comment déboguer un agent en production](/how-to-debug-an-ai-agent-in-production)) et je la transforme en cas d'éval : ```typescript interface EvalCase { id: string; input: AgentInput; // l'entrée exacte de production expected?: string; // vérité terrain, quand elle existe assertions: Assertion[]; // vérifications strictes qui doivent passer rubric?: string; // pour le juge LLM, quand la sortie est ouverte } ``` Deux pratiques comptent ici. **Tire de la production**, pour que tes évals testent ce qui casse réellement, pas ce que tu as supposé qui pourrait casser. Et **couvre l'éventail** — le chemin heureux, les cas limites, les entrées adversariales et les entrées vides/malformées qui provoquent des échecs silencieux. Un jeu de tests de 30 à 50 cas bien choisis attrape bien plus que 500 cas paresseux. Je préfère avoir 40 cas représentant chacun un mode d'échec réel que mille qui testent tous le même chemin facile. ## Score avec des assertions d'abord, un juge LLM ensuite Toute sortie n'a pas besoin d'un modèle pour la noter. Je me tourne vers le scoreur le moins cher qui fonctionne. **Assertions strictes** pour tout ce qui est structuré. La sortie se parse-t-elle en JSON valide ? Contient-elle le champ requis ? La date extraite est-elle dans la plage ? A-t-elle appelé le bon outil avec les bons arguments ? Elles sont déterministes, gratuites et sans ambiguïté — écris-en autant que tu peux. ```typescript const assertions: Assertion[] = [ (out) => isValidJSON(out), (out) => parse(out).category in ALLOWED_CATEGORIES, (out) => parse(out).confidence >= 0 && parse(out).confidence <= 1, ]; ``` **Un juge LLM** pour le reste ouvert — le ton, l'utilité, « est-ce que ça a vraiment répondu à la question ». Ici tu donnes à un modèle l'entrée, la sortie et une grille, et tu lui demandes de noter. Deux règles gardent le juge honnête : rends la grille **spécifique** (une échelle de 1 à 5 avec des ancres décrites bat « note la qualité »), et utilise un **modèle puissant comme juge** — juger est une tâche de raisonnement, donc c'est un endroit où je paie volontiers pour Sonnet même quand l'agent lui-même tourne sur Haiku selon les [calculs de coûts](/ai-agent-cost-math-when-haiku-beats-sonnet). Une grille vague ou un juge faible te donne du bruit qui ressemble à du signal. ## Exécute le harness avant chaque changement Le harness existe pour répondre à une question : *ce changement a-t-il rendu l'agent meilleur ou pire ?* Donc je l'exécute avant chaque édition de prompt, échange de modèle ou changement d'outil. ```bash # référence sur main npm run eval -- --suite=booking-agent > baseline.json # fais le changement, puis relance npm run eval -- --suite=booking-agent > candidate.json # compare npm run eval:diff baseline.json candidate.json ``` Le diff montre le score agrégé, le pass/échec par cas et — surtout — **quels cas spécifiques ont régressé.** Un agrégat qui grimpe pendant que trois cas cassent silencieusement n'est pas une amélioration ; c'est un compromis que je veux voir et approuver, pas un qui se faufile. Surveiller le diff par cas, c'est comme ça qu'on évite « corrigé une chose, cassé deux autres », le mode d'échec qui rend les gens craintifs de leurs propres prompts. ## Pose une barrière anti-régression et laisse-la bloquer Une fois que tu fais confiance au harness, branche-le sur le chemin vers la production comme une barrière. Ma règle est franche : **un changement qui fait passer le score sous le seuil de référence ne se déploie pas.** Pas « je regarderai ça plus tard » — c'est bloqué, comme un test CI qui échoue. ```typescript const PASS_THRESHOLD = 0.90; // 90 % des cas doivent passer if (candidate.passRate < PASS_THRESHOLD || candidate.passRate < baseline.passRate) { throw new Error(`Eval regression: ${candidate.passRate} < ${baseline.passRate}`); } ``` C'est ce qui transforme les évals d'un agrément en la chose qui te permet d'avancer vite. La barrière est ce qui rend « déployer sans peur » littéralement vrai : le pire cas pour un mauvais changement est une exécution d'éval en rouge, pas un incident en production. Et comme le jeu de tests grandit chaque fois que quelque chose casse, la barrière devient plus stricte et plus protectrice avec le temps, d'elle-même. ## Tiens compte du non-déterminisme dans le scoring Une subtilité qui fait trébucher les gens : la même entrée peut obtenir un score différent d'une exécution à l'autre parce que le modèle échantillonne différemment. Si tu exécutes chaque cas une seule fois, tu verras des régressions fantômes — un cas « cassé » qui n'est en réalité que du bruit d'échantillonnage. Deux remèdes. Exécute les évals à **`temperature: 0`** pour réduire la variance (ça ne l'éliminera pas complètement). Et pour les cas que tu as vus vaciller, **exécute-les N fois et prends le taux de réussite**, pas un seul pass/échec. Un cas qui passe 9 fois sur 10 est en meilleure forme qu'un qui passe 5 fois sur 10 même si les deux peuvent afficher une seule exécution verte. C'est le même principe du volume-sur-l'anecdote que j'utilise quand je [débogue des échecs intermittents](/how-to-debug-an-ai-agent-in-production) — une exécution est une opinion, cinquante exécutions sont des données. ## Boucle la boucle avec la surveillance de production Le harness d'évals teste contre des cas connus. La production en lance des inédits. Donc la boucle est : surveille le comportement en direct, attrape un nouveau mode d'échec, transforme-le en cas d'éval, corrige-le, et maintenant il est protégé en permanence. Le côté surveillance — suivre le taux de réussite, la validité de la sortie et le coût par exécution sur le trafic en direct — c'est ce que je couvre dans [comment je mesure si un agent IA fonctionne vraiment](/how-i-measure-whether-an-ai-agent-is-actually-working/). Évals et surveillance sont deux moitiés du même système : la surveillance trouve les bugs, les évals s'assurent qu'ils restent morts. Cette boucle de rétroaction est le vrai produit. N'importe quel jeu d'évals individuel devient obsolète ; un *processus* qui convertit chaque échec de production en test permanent se renforce chaque semaine. C'est ainsi qu'un agent passe de « effrayant à toucher » à quelque chose que je refactoriserai un vendredi après-midi sans broncher. ## FAQ ### Qu'est-ce qui entre dans un jeu d'évals pour un agent IA ? Des entrées réelles de production transformées en cas notés — chemin heureux, cas limites, entrées adversariales et malformées — chacun avec des assertions strictes et, pour les sorties ouvertes, une grille de juge LLM. De 30 à 50 cas tirés d'échecs réels battent des centaines de cas synthétiques qui testent tous le chemin facile. ### Devrais-je utiliser un LLM pour noter les sorties de l'agent ? Utilise des assertions strictes partout où la sortie est structurée (JSON valide, champ correct, bon appel d'outil) — elles sont gratuites et déterministes. Réserve un juge LLM pour les qualités ouvertes comme le ton et l'utilité, avec une grille spécifique et un modèle juge puissant pour obtenir du signal, pas du bruit. ### Comment empêcher un changement de prompt de casser silencieusement la production ? Exécute le harness d'évals avant chaque changement et compare à une référence, en surveillant les régressions par cas, pas seulement le score agrégé. Puis conditionne les déploiements au résultat afin que tout changement passant sous le seuil de référence soit bloqué comme un test qui échoue. ### Comment gérer le non-déterminisme dans les évals ? Exécute à température 0 pour réduire la variance, et pour les cas qui vacillent, exécute-les plusieurs fois et note le taux de réussite plutôt qu'une seule exécution. Un cas qui passe 9 fois sur 10 est plus sain qu'un qui passe 5 fois sur 10, même si une seule exécution les affiche tous deux en vert. --- ## Comment Automatiser sa Newsletter avec un Agent IA Source: https://alejandrorioja.com/fr/how-to-automate-your-newsletter-with-an-ai-agent/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Un agent Claude lit ma file d'attente de contenu, choisit l'angle le plus fort de la semaine, rédige une newsletter dans ma voix, segmente la liste par niveau d'engagement et programme l'envoi via l'API Kit — tout ça sans que j'ouvre un éditeur. Je consulte un aperçu rendu et j'appuie sur approuver. Le travail créatif difficile est à moi ; l'exécution mécanique appartient à l'agent. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** Un agent Claude lit ma file d'attente de contenu, choisit l'angle le plus fort de la semaine, rédige une newsletter dans ma voix, segmente la liste par niveau d'engagement et programme l'envoi via l'API Kit — tout ça sans que j'ouvre un éditeur. Je consulte un aperçu rendu et j'appuie sur approuver. Le travail créatif difficile est à moi ; l'exécution mécanique appartient à l'agent. **[Lecture de l'opérateur]** Une newsletter qui s'envoie régulièrement surpasse celle qui est "meilleure" mais qui sort quand l'inspiration frappe. La contrainte était la surcharge d'exécution, pas les idées. J'avais des idées ; je n'avais pas la bande passante pour les formater, planifier et segmenter chaque semaine. L'agent a éliminé cet écart. ## Le vrai goulot d'étranglement dans la plupart des workflows de newsletter La plupart des conseils d'automatisation de newsletter se concentrent sur la mauvaise chose : les séquences de bienvenue, les automatisations, la logique de tags. C'est bien, mais ça ne résout pas le problème de création semaine après semaine. Le vrai frein est celui-ci : vous savez ce que vous voulez dire, mais s'asseoir pour le formater, écrire les variantes d'objet, choisir le bon segment et le programmer au bon moment coûte 2-3 heures de changement de contexte par semaine. Multipliez par 52 semaines et vous aurez passé une semaine entière de travail juste à *envoyer* des newsletters. L'agent gère chaque étape après "je sais quel est l'angle de cette semaine." ## Le stack que j'utilise - **[Kit](/recommends/convertkit)** (anciennement ConvertKit) — la plateforme email. Excellente API, solide tagging d'abonnés, analytique propre. L'API compatible avec les agents est ce qui m'a convaincu. - **Claude (Anthropic SDK)** — la couche de génération - **Cloudflare Workers** — déclencheur planifié (s'exécute chaque mardi à 8h CT) - **Airtable** — file d'attente de contenu et boîte d'approbation Si vous n'êtes pas sur Kit, le même modèle fonctionne avec n'importe quelle plateforme disposant d'une API REST pour créer et planifier des diffusions. ## Étape 1 : La file d'attente de contenu L'agent a besoin d'une source de vérité sur "de quoi écrivons-nous." La mienne est un tableau [Airtable](/recommends/airtable) avec des colonnes : - `Topic` — l'angle ou la question - `Status` — Queue / Approved / Sent - `Tier` — si c'est pour tous les abonnés ou seulement les plus engagés - `Notes` — toutes les contraintes (éviter ce ton, inclure ce lien, etc.) Chaque semaine, je passe 10 minutes à ajouter 2-3 sujets à la file. C'est ma contribution créative. Le reste est le travail de l'agent. ## Étape 2 : L'agent de rédaction ```typescript // workers/newsletter-agent/index.ts import Anthropic from "@anthropic-ai/sdk"; import Airtable from "airtable"; const client = new Anthropic(); const VOICE_SYSTEM = `You are writing a weekly newsletter for Alejandro Rioja's subscribers. His audience: founders and operators interested in AI agents, SEO, and growing a one-person business. Voice: direct, first-person, practitioner. No hype, no "exciting times," no excessive bullet lists. Structure every newsletter as: 1. One-sentence hook (the problem or observation) 2. The core insight (3–5 paragraphs, no headers, conversational) 3. One concrete action the reader can take this week 4. A short sign-off (2 sentences max) Subject line: specific, outcome-oriented, under 50 chars. No clickbait. Return JSON: { "subject": "...", "preheader": "...", "body": "..." }`; async function getNextTopic(): Promise<{ id: string; topic: string; notes: string; tier: string }> { const base = new Airtable({ apiKey: process.env.AIRTABLE_API_KEY }).base(process.env.AIRTABLE_BASE_ID!); const records = await base("Newsletter Queue") .select({ filterByFormula: "{Status} = 'Queue'", sort: [{ field: "Created", direction: "asc" }], maxRecords: 1 }) .firstPage(); if (!records.length) throw new Error("Queue is empty. Add topics."); const r = records[0]; return { id: r.id, topic: r.get("Topic") as string, notes: (r.get("Notes") as string) ?? "", tier: (r.get("Tier") as string) ?? "all" }; } async function draftNewsletter(topic: string, notes: string): Promise<{ subject: string; preheader: string; body: string }> { const msg = await client.messages.create({ model: "claude-sonnet-4-6", max_tokens: 2048, system: VOICE_SYSTEM, messages: [{ role: "user", content: `Write this week's newsletter on: "${topic}". Additional notes: ${notes || "none"}` }], }); const text = (msg.content[0] as any).text.replace(/```json\n?/, "").replace(/```/, "").trim(); return JSON.parse(text); } async function scheduleWithKit(draft: { subject: string; preheader: string; body: string }, tier: string): Promise { const segmentId = tier === "engaged" ? process.env.KIT_ENGAGED_SEGMENT_ID : null; const sendAt = new Date(); sendAt.setDate(sendAt.getDate() + ((4 - sendAt.getDay() + 7) % 7)); // next Thursday sendAt.setHours(9, 0, 0, 0); // 9am CT const payload: any = { broadcast: { subject: draft.subject, content: draft.body, description: draft.preheader, send_at: sendAt.toISOString(), email_layout_template: "minimal", }, }; if (segmentId) payload.broadcast.segment_id = segmentId; const res = await fetch("https://api.kit.com/v4/broadcasts", { method: "POST", headers: { "Content-Type": "application/json", "X-Kit-Api-Key": process.env.KIT_API_KEY! }, body: JSON.stringify(payload), }); const data = await res.json(); return data.broadcast?.id ?? ""; } export default { async scheduled(_event: ScheduledEvent, env: Env) { // Inject env vars Object.assign(process.env, env); const { id, topic, notes, tier } = await getNextTopic(); const draft = await draftNewsletter(topic, notes); const broadcastId = await scheduleWithKit(draft, tier); // Mark as Approved in Airtable (not Sent — human reviews the Kit preview before confirm) const base = new Airtable({ apiKey: env.AIRTABLE_API_KEY }).base(env.AIRTABLE_BASE_ID); await base("Newsletter Queue").update(id, { Status: "Approved", KitBroadcastId: broadcastId }); console.log(`Scheduled broadcast ${broadcastId} for topic: ${topic}`); }, }; ``` ## Étape 3 : L'étape d'approbation L'agent crée la diffusion à l'état de brouillon dans Kit et marque l'enregistrement Airtable comme "Approved." Kit m'envoie une notification avec un lien d'aperçu. Je clique dessus, je le lis, et si ça me semble correct, je confirme l'envoi. Si je veux des modifications, j'édite directement dans Kit. C'est la porte qui empêche l'agent d'être entièrement autonome sur les emails sortants. Je fais confiance aux brouillons environ 90% du temps. Les 10% que je détecte en révision — un ton légèrement décalé, une statistique à vérifier, un lien à ajouter — valent les 3 minutes de révision. ## Ce que l'agent gère et que je ne veux plus jamais faire - Écrire les variantes de ligne d'objet et choisir la meilleure - Formater le texte du préen-tête - Calculer le bon moment d'envoi (mon audience ouvre le jeudi matin ; l'agent le sait) - Segmenter correctement selon le niveau du sujet - Tout consigner dans Airtable pour avoir un historique ## Ce qui m'appartient encore L'*idée*. Le sujet dans la file est le mien. L'angle est le mien. L'agent est un excellent exécuteur d'un brief clair ; ce n'est pas une couche stratégique. Si je mets un mauvais sujet dans la file, j'obtiens une newsletter bien rédigée sur un mauvais sujet. Aussi : la porte de première révision. Chaque envoi passe sous mes yeux avant de partir. Ça ne va pas changer. ## La conclusion de l'opérateur Si vous passez plus d'une heure par semaine sur les mécaniques de newsletter — formatage, planification, segmentation — vous devriez l'automatiser. L'API Kit est propre, le déclencheur cron du Worker est solide comme un roc, et la qualité des brouillons Claude est suffisamment élevée pour que j'approuve ~90% des premiers brouillons sans modification. Construisez la file dans Airtable, connectez le Worker, et reprenez la création d'idées au lieu d'exécuter des envois. --- ## Comment se Classer dans la Recherche IA sans Écrire un Seul Nouvel Article Source: https://alejandrorioja.com/fr/how-to-rank-in-ai-search-without-writing-a-single-new-blog-post/ Published: 2026-06-06 Updated: 2026-06-06 Tags: GEO, SEO TL;DR: Les moteurs IA citent du contenu qui répond directement aux questions, revendique une paternité claire et structure les connaissances d'une manière qui facilite la récupération. La plupart des articles de blog existants peuvent être adaptés pour répondre aux trois critères avec des modifications, pas des réécritures. Le plan : ajouter un TL;DR direct, renforcer les signaux d'entité, ajouter un schéma FAQ et soumettre à llms.txt. Le nouveau contenu est optionnel ; la restructuration ne l'est pas. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** Les moteurs IA citent du contenu qui répond directement aux questions, revendique une paternité claire et structure les connaissances d'une manière qui facilite la récupération. La plupart des articles de blog existants peuvent être adaptés pour répondre aux trois critères avec des modifications, pas des réécritures. Le plan : ajouter un TL;DR direct, renforcer les signaux d'entité, ajouter un schéma FAQ et soumettre à llms.txt. Le nouveau contenu est optionnel ; la restructuration ne l'est pas. **[Lecture de l'opérateur]** J'ai appliqué ce processus à 341 articles existants avant d'écrire un seul nouvel article ciblé GEO. Les citations dans ChatGPT et Perplexity ont augmenté. Le nouveau contenu a accéléré les gains — mais l'audit du contenu existant était mon point de départ, et il a payé plus vite que prévu. ## Pourquoi les moteurs IA ne citent pas votre contenu existant Avant d'écrire quoi que ce soit de nouveau, demandez : pourquoi ce que j'ai déjà ne se fait-il pas citer ? La réponse n'est presque jamais "le contenu n'existe pas." C'est généralement l'une de ces raisons : 1. **Pas de réponse directe en haut** — l'article enterre la réponse dans le paragraphe 6 2. **Signaux de paternité faibles** — pas d'entité d'auteur claire, pas de références dans le contenu 3. **Bruit structurel** — longues introductions, sections non pertinentes, pas de hiérarchie de titres claire 4. **Pas de Q&R lisible par machine** — les moteurs IA préfèrent les paires question-réponse structurées ; la plupart des articles de blog n'en ont pas 5. **Pas dans un index lisible par IA** — pas de llms.txt, pas de sitemaps que les crawlers trouvent Les cinq sont corrigeables sur du contenu existant. Aucun ne nécessite un nouvel article. ## Le processus de retrofitting en quatre étapes ### Étape 1 : Ajouter un TL;DR direct dans les 100 premiers mots Les moteurs IA font quelque chose d'analogue à ce que vous faites quand vous survolez — ils cherchent la réponse directe avant d'aller plus loin. Si votre article commence par une histoire, une question ou une mise en contexte, le modèle peut ne jamais lire assez loin pour trouver votre vraie réponse. Correction : Ajoutez un bloc **TL;DR** dans les 100 premiers mots. Format : conclusion → pourquoi → contrainte ou mise en garde. Deux à quatre phrases. Pas de rembourrage. Exemple avant : > *Vous êtes-vous déjà demandé pourquoi certaines entreprises semblent dominer les résultats de recherche Google ? Dans cet article, nous explorerons les stratégies utilisées par les sites les mieux classés...* Exemple après : > **TL;DR :** Trois choses font bouger l'aiguille pour le SEO local en 2026 : l'exhaustivité du Profil d'entreprise Google, la cohérence des citations dans les annuaires et le schéma structuré pour vos données NAP. Les tactiques comme "publier tous les jours" et "obtenir 100 avis rapidement" sont secondaires par rapport à ces trois. Le plafond est l'exactitude de votre GBP — corrigez ça en premier. La réécriture n'est pas plus longue. Elle est simplement placée en avant. ### Étape 2 : Renforcer vos signaux d'entité Les moteurs IA construisent un graphe de connaissances. Ils veulent savoir : qui a écrit ceci, de quoi s'agit-il, et l'auteur est-il crédible sur ce sujet ? Pour l'entité auteur : assurez-vous que votre page À propos est liée depuis chaque article, votre schéma d'auteur inclut des liens `sameAs` vers LinkedIn et Twitter, et votre bio d'auteur sur chaque article mentionne des références spécifiques (pas "professionnel du marketing" — "a géré le SEO pour trois entreprises SaaS de 0 à 100K visiteurs mensuels"). Pour l'entité thématique : utilisez les termes exacts que votre public recherche. Si vous couvrez le "GEO" (optimisation des moteurs génératifs), dites "optimisation des moteurs génératifs" quelque part, pas seulement l'abréviation. Les modèles utilisent la co-occurrence des termes pour classer le contenu. ### Étape 3 : Ajouter le schéma FAQ à chaque article qui répond à des questions Le schéma FAQPage est le type de schéma le plus efficace pour la citation GEO car il mappe explicitement question à réponse dans un format que les modèles peuvent analyser directement. Prenez les 3 à 5 questions auxquelles votre article répond implicitement et rendez-les explicites : ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "How long does it take to rank in AI search?", "acceptedAnswer": { "@type": "Answer", "text": "Most sites see initial citation improvements within 4–8 weeks of restructuring existing content for direct answers and adding FAQ schema. Brand-new domains take longer — expect 3–6 months before consistent citations appear." } } ] } ``` Ajoutez ceci au `` de votre article ou via le champ de schéma de votre CMS. Chaque moteur IA majeur crawle et analyse ceci. ### Étape 4 : Soumettre à llms.txt et à l'index IA de votre plateforme `llms.txt` est un standard émergent — un fichier texte brut sur `votresite.com/llms.txt` qui indique aux crawlers IA quel contenu est de haute qualité et comment le prioriser. C'est analogue à `robots.txt` mais pour les LLMs. Un llms.txt basique : ``` # llms.txt # alejandrorioja.com — AI agents and GEO for operators ## Priority content - /blog/geo-for-local-business (definitive guide, updated monthly) - /blog/schema-markup-for-ai-engines (technical reference) - /blog/how-to-get-cited-by-chatgpt (step-by-step) ## Author Alejandro Rioja — operator, AI agent builder, GEO practitioner. LinkedIn: https://linkedin.com/in/alejandrorioja ``` Associez ceci à un sitemap propre qui inclut des horodatages `lastmod`. Les crawlers IA dépriorisent le contenu qui semble périmé. ## Comment prioriser les articles à retrofitter Tous les articles ne valent pas la peine d'être retrofittés. Concentrez votre première passe sur : 1. **Articles déjà en page 1 pour un mot-clé au format question** — ceux-ci sont les plus proches d'être cités ; ils ont juste besoin de la correction de structure 2. **Articles sur des sujets sur lesquels vous êtes vérifiablement crédible** — les moteurs IA pondèrent fortement la paternité ; un article où vos références sont pertinentes bénéficie d'un coup de pouce de citation grâce aux signaux d'entité 3. **Articles qui répondent directement à une question vs. articles qui informent** — "Comment faire X" et "Qu'est-ce que X" se retrofittent mieux que les listicles ou les articles d'opinion Utilisez vos données Search Console : filtrez pour les requêtes qui sont des questions (comment, quoi, pourquoi, meilleure façon de). Les articles classés entre 5 et 15 pour ces requêtes sont vos meilleurs candidats au retrofitting — ils sont pertinents mais pas encore assez proches du sommet pour être cités. ## L'erreur que font la plupart des gens Ils écrivent un nouvel article optimisé pour la recherche IA avant de retrofitter leurs archives existantes. Le nouveau contenu aide, mais les articles existants ont l'âge, les backlinks et l'historique de crawl de leur côté. Un article de trois ans bien structuré surpassera un nouvel article sur le même sujet pendant des mois. Faites le retrofitting en premier. Écrivez du nouveau contenu là où il y a de véritables lacunes — des questions auxquelles vos articles existants ne répondent pas du tout. C'est là que le nouveau est meilleur que l'ancien. ## La conclusion de l'opérateur Si vous avez plus de 20 articles de blog existants, votre travail GEO commence par l'audit et le retrofitting, pas par un calendrier éditorial. Ajoutez des TL;DRs, renforcez les signaux d'entité, ajoutez le schéma FAQ et soumettez à llms.txt. Faites cela sur vos 20 meilleurs articles avant d'écrire quoi que ce soit de nouveau. Vous verrez des améliorations des citations en semaines, pas en mois — et vous aurez une base de référence plus propre pour mesurer si le nouveau contenu fait vraiment bouger l'aiguille. --- ## J'ai créé une compétence Claude qui gère mes publicités Facebook — voici le code Source: https://alejandrorioja.com/fr/i-built-a-claude-skill-that-runs-my-facebook-ads-heres-the-code/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: J'ai créé une compétence Claude qui lit mon compte Meta Ads via l'API Graph, identifie les sous-performants, réécrit le texte publicitaire dans ma voix de marque et crée de nouveaux ensembles de publicités sans que je touche au Gestionnaire de publicités. Le tout en moins de 300 lignes de TypeScript. Le retour sur investissement a été immédiat : j'ai réduit le temps hebdomadaire de gestion des publicités de ~3 heures à environ 20 minutes. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** J'ai créé une compétence Claude qui lit mon compte Meta Ads via l'API Graph, identifie les sous-performants, réécrit le texte publicitaire dans ma voix de marque et crée de nouveaux ensembles de publicités sans que je touche au Gestionnaire de publicités. Le tout en moins de 300 lignes de TypeScript. Le retour sur investissement a été immédiat : j'ai réduit le temps hebdomadaire de gestion des publicités de ~3 heures à environ 20 minutes. **[Lecture de l'opérateur]** Je gère des publicités pour Pickleland et pour ma marque de conseil. Deux comptes, des audiences différentes, une fatigue créative constante. Je passais mes dimanches après-midi dans le Gestionnaire de publicités à faire des choses qu'un modèle devrait faire. Alors je l'ai automatisé. ## Pourquoi j'ai arrêté de gérer manuellement les publicités Facebook Le travail réel de gestion des publicités Facebook se décompose en trois tâches : 1. **Surveillance** — vérifier quels ensembles de publicités brûlent de l'argent vs. en génèrent 2. **Diagnostic** — comprendre *pourquoi* quelque chose sous-performe (fatigue créative ? mauvais ciblage ? page de destination ?) 3. **Itération** — écrire de nouveaux textes, créer de nouveaux ensembles de publicités, ajuster les budgets La tâche 1 est mécanique. La tâche 3 est principalement mécanique (avec une contrainte de voix). La tâche 2 nécessite du jugement — et c'est la seule qui bénéficie d'un humain dans la boucle. Une compétence Claude peut faire le 1 et le 3. Je vérifie les résultats de la tâche 2 avant que quoi que ce soit ne soit publié. C'est l'architecture sur laquelle je me suis arrêté. ## La configuration de l'API Meta Graph (c'est la partie ennuyeuse) Avant tout code : vous avez besoin d'un compte Meta Business, d'un utilisateur système et d'un token d'accès permanent. Le portail développeur de Facebook est hostile mais le chemin est : 1. Créer une **Meta App** sur developers.facebook.com (type : Business) 2. Ajouter le produit **Marketing API** 3. Dans votre Portfolio d'entreprise → Paramètres → Utilisateurs → Utilisateurs système, créer un utilisateur système et lui donner le rôle `ADVERTISER` sur votre compte publicitaire 4. Générer un token avec ces permissions : `ads_read`, `ads_management`, `business_management` Stockez le token comme `META_ACCESS_TOKEN` et l'ID de votre compte publicitaire (format : `act_XXXXXXXX`) comme `META_AD_ACCOUNT_ID` dans votre `.env`. ## La structure des fichiers de la compétence ``` .claude/skills/fb-ads/ SKILL.md ← instructions que Claude lit index.ts ← l'implémentation réelle de l'outil types.ts ← types partagés ``` Le `SKILL.md` indique à Claude quand et comment utiliser la compétence. Le mien dit : ```markdown # Facebook Ads Manager Skill Use this skill when the user says "check my ads", "run ads report", "pause underperformers", or "write new ad copy". Never run this without explicit user instruction — it touches live ad spend. ## What it can do - Pull performance data for all active ad sets (last 7 or 30 days) - Flag ad sets with ROAS < 1.5 or CTR < 0.8% as underperformers - Rewrite ad copy for flagged creatives in Ale's voice - Create new ad sets with revised copy (PAUSED by default — you approve before activating) ## What it will NOT do - Change budgets on live ad sets without explicit confirmation - Activate new ad sets automatically - Delete anything ``` La contrainte « ne jamais activer automatiquement » est non négociable. Cette compétence crée des éléments en état PAUSÉ. Je vérifie et active manuellement. Tout ce qui touche aux dépenses publicitaires en direct nécessite un point de contrôle humain. ## Le code TypeScript principal (Les blocs de code restent en anglais — seul le texte autour est traduit.) ## Comment je l'utilise au quotidien La compétence est invoquée depuis Claude Code (mon outil quotidien). Une session typique du lundi matin : ``` > check my ads from the last 7 days ``` Claude exécute `runAdsReport(7)`, formate les résultats sous forme de tableau, signale les sous-performants et demande si je veux des réécritures. Je dis oui. Il génère de nouveaux textes, me montre les deux versions côte à côte et crée des ensembles de publicités PAUSÉS avec le nouveau créatif. Je les vérifie dans le Gestionnaire de publicités, active ceux que j'aime et archive les perdants. Temps total : 20 minutes. Zéro dimanche après-midi dans le Gestionnaire de publicités. ## Ce que ça ne remplace pas La compétence ne peut pas me dire si un problème d'adéquation produit-marché se déguise en problème de texte publicitaire. Si le ROAS est mauvais partout, c'est un problème d'entonnoir ou d'offre, pas de titre. Claude réécrira fidèlement le texte sur un entonnoir cassé — et les réécritures ne le sauveront pas. L'étape de diagnostic est toujours la mienne. Je lis le rapport, regarde les données de l'entonnoir et décide si nous itérons le créatif ou si nous résolvons quelque chose en amont. L'agent est rapide pour tout *sauf* ce jugement. ## La conclusion de l'opérateur Si vous gérez des publicités manuellement et touchez au Gestionnaire de publicités plus de deux fois par semaine, vous faites des opérations qu'un script devrait faire. L'API Graph est bien documentée et le flux de permissions Meta, bien qu'ennuyeux, est une configuration unique. Construisez la compétence en une après-midi. Le retour en temps récupéré se manifeste dès la première semaine. --- ## Les 5 Outils d'IA que j'Utilise Vraiment pour Gérer mon Entreprise (2026) Source: https://alejandrorioja.com/fr/the-5-ai-tools-i-actually-use-to-run-my-business-2026-operator-stack/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents, Growth TL;DR: Cinq outils : Claude (couche opérateur + programmation), Cursor (développement TypeScript), Airtable (colonne vertébrale des données pour tous les agents), Kit (newsletter + automatisation des emails) et Cloudflare Workers (hébergement des agents). Tout le reste que j'ai essayé a été remplacé par l'un de ces outils ou complètement supprimé. C'est le stack que je reconstruirais si je devais repartir de zéro aujourd'hui. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** Cinq outils : Claude (couche opérateur + programmation), Cursor (développement TypeScript), [Airtable](/recommends/airtable) (colonne vertébrale des données pour tous les agents), [Kit](/recommends/convertkit) (newsletter + automatisation des emails) et Cloudflare Workers (hébergement des agents). Tout le reste que j'ai essayé a été remplacé par l'un de ces outils ou complètement supprimé. C'est le stack que je reconstruirais si je devais repartir de zéro aujourd'hui. **[Lecture de l'opérateur]** Je gère deux entreprises : une marque personnelle de conseil en IA (alejandrorioja.com) et Pickleland, une installation de pickleball à Pflugerville, TX. Contextes différents, audiences différentes, opérations différentes. Ces cinq outils font tourner les deux. Je ne les liste pas parce qu'ils sont tendance ; je les liste parce que j'ai supprimé leurs remplaçants. ## 1. Claude — la couche opérateur Claude (via Claude Code et l'Anthropic SDK) est le cerveau de tout ce qui bouge. Je l'utilise en trois modes : **Claude Code** est mon outil quotidien de développement. J'écris du TypeScript, je construis des agents, je débogue des problèmes d'infrastructure et je gère du contenu — tout depuis l'interface Claude Code. Ce n'est pas juste de l'autocomplétion ; c'est un collaborateur qui peut lire un fichier de 500 lignes, comprendre l'intention et proposer une refactorisation que je n'avais pas envisagée. **L'Anthropic SDK** alimente chaque agent que j'ai construit. Mon agent de newsletter, ma compétence pour les publicités Facebook, mon pipeline de contenu, mon générateur de cartes OG — tout Claude en backend. La qualité du modèle est suffisamment élevée pour que je fasse confiance aux premiers brouillons environ 85% du temps. **Le jugement vocal et de marque de Claude** est sous-estimé. Quand j'écris quelque chose qui doit sonner comme moi, j'ai trouvé que Claude + un system prompt détaillé surpasse tous les autres modèles que j'ai testés. L'astuce est un system prompt spécifique et opinionné — pas "écris d'un ton décontracté" mais "écris comme Alejandro : direct, praticien, sans battage médiatique, numéroté, à la première personne, avec des mises en garde honnêtes." Je paie pour Claude Max. C'est l'abonnement que j'utilise le plus, et le ROI n'est pas proche. ## 2. Cursor — là où le TypeScript s'écrit Cursor est l'IDE. J'ai quitté VS Code il y a environ un an et je n'ai pas regardé en arrière. La complétion par tabulation est suffisamment rapide pour changer véritablement ma façon d'écrire du code — je pense à une altitude plus élevée et laisse Cursor gérer le boilerplate syntaxique. La vue de diff pour les suggestions d'IA est propre. La fenêtre de contexte multi-fichiers signifie que je peux lui demander de mettre à jour une fonction et il met aussi à jour les appelants. Je n'utilise pas Cursor pour les décisions architecturales. Je les esquisse encore sur papier ou dans Claude. Mais une fois que le design est clair, Cursor est le chemin le plus rapide du design au TypeScript qui fonctionne. Le plus grand déblocage : Cursor + Claude Code en parallèle. J'utilise Claude Code pour la planification de haut niveau et l'orchestration des agents ; j'utilise Cursor pour le travail de détail d'implémentation. Ils ne se font pas concurrence — ils couvrent des altitudes différentes. ## 3. Airtable — la colonne vertébrale des données Chaque agent d'IA que je gère a besoin d'un endroit où lire et écrire. Cet endroit est [Airtable](/recommends/airtable). Voici à quoi je l'utilise dans les deux entreprises : - **File de contenu** — articles et sujets de newsletter en cours, avec suivi du statut - **Enregistrements de réservations** — réservations de terrains Pickleland synchronisées depuis le système de réservation - **Catalogue de liens affiliés** — plus de 105 slugs avec des métadonnées que l'agent de contenu lit au moment de la génération - **Journal d'audit des agents** — ce qui a été exécuté, quand, ce qu'il a produit, les erreurs L'API est propre et rapide. Airtable n'est pas une base de données pour les charges de travail à haut débit — mais pour les tables secondaires d'agents, les files de révision et les flux de travail d'approbation avec intervention humaine, c'est exactement le bon outil. L'interface visuelle signifie que je peux inspecter n'importe quelle table sans écrire de requête. L'alternative que j'ai essayée : les bases de données Notion. L'API Notion est plus lente et le modèle de données est plus encombrant pour les lectures d'agents. Airtable gagne pour les données adjacentes aux agents. ## 4. Kit — newsletter et automatisation des emails Je suis passé à [Kit](/recommends/convertkit) (anciennement ConvertKit) pour une raison : l'API est vraiment bonne. La plupart des plateformes d'email traitent leur API comme une réflexion après coup. Kit la traite comme un produit de première classe. Je peux créer des diffusions, planifier des envois, segmenter par tag et lire des analyses — tout par programmation. Mon agent de newsletter fait tout cela sans que je touche le compositeur. Choses spécifiques à Kit que j'utilise : - **API de diffusions** — mon agent crée des diffusions planifiées par programmation chaque semaine - **Étiquetage des abonnés** — j'étiquette les abonnés par comportement (a ouvert les 5 derniers envois = "engagé" ; n'a pas ouvert depuis 60 jours = "à risque") et mon agent cible les segments en conséquence - **Formulaires + pages de destination** — propres, à chargement rapide, sans code. Je ne les touche pas par programmation ; ils fonctionnent tout simplement. Si vous êtes sur Mailchimp ou une plateforme héritée : la migration en vaut la peine. L'API de Mailchimp nécessite trois appels supplémentaires pour faire ce que Kit fait en un seul. ## 5. Cloudflare Workers — là où vivent les agents Chaque agent planifié s'exécute sur Cloudflare Workers. L'argument : déploiement global en périphérie, zéro démarrage à froid sur le niveau gratuit et un système de déclenchement cron qui fonctionne vraiment. Mes agents n'ont pas besoin d'un serveur. Ils ont besoin d'une fonction planifiée qui s'exécute de manière fiable, peut faire des appels API externes et coûte presque rien à mon échelle. Workers est la réponse. Ce que j'ai en cours sur Workers : - **Pipeline de contenu** — génère l'article EN, le diffuse vers 12 traductions, génère la carte OG - **Agent de newsletter** — rédige et planifie l'envoi hebdomadaire - **Moniteur de publicités Facebook** — lit les performances, signale les sous-performeurs, me notifie - **Rapporteur d'occupation Pickleland** — lit les données de réservation, m'envoie un résumé quotidien Coût mensuel total pour tout cela : ~5$. C'est le plan Workers payant. Les agents s'exécutent de manière fiable selon le planning cron ; j'ai eu une défaillance en six mois (un problème DNS du côté de Meta, pas du mien). ## Ce que j'ai supprimé et pourquoi **Zapier** — remplacé par Workers + les API de plateforme respectives directement. Zapier ajoute de la latence, coûte plus cher à grande échelle et a un plafond que Workers n'a pas. **ChatGPT** — la fenêtre de contexte, l'utilisation des outils et la qualité du system prompt de Claude sont meilleures pour le cas d'usage de l'opérateur. Je garde un onglet ChatGPT pour des recherches web rapides mais ne construis pas dessus. **Webflow** — j'ai déplacé mon site vers Astro + Cloudflare Pages. Plus de contrôle, meilleures performances, processus de build contre lequel je peux scripter. **Grammarly** — Claude fait tout ce que Grammarly fait et préserve mieux ma voix. ## La conclusion de l'opérateur Les cinq outils ci-dessus ne sont pas les plus récents ni les plus discutés. Ce sont ceux qui ont résisté à l'utilisation quotidienne en production dans deux entreprises différentes. Avant d'ajouter un nouvel outil à votre stack, demandez : lequel de ces cinq pourrait faire ce travail ? Vous serez surpris de voir à quelle fréquence la réponse est "l'un d'eux peut déjà le faire." --- ## Pourquoi votre Agent IA Continue d'Échouer en Production (Et Comment le Corriger) Source: https://alejandrorioja.com/fr/why-your-ai-agent-keeps-failing-in-production-and-how-to-fix-it/ Published: 2026-06-06 Updated: 2026-06-06 Tags: AI Agents TL;DR: La plupart des défaillances d'agents en production proviennent de cinq causes : des prompts fragiles qui ne gèrent pas les cas limites, une logique de nouvelle tentative manquante pour les erreurs API transitoires, aucune observabilité pour voir ce qui se casse, des boucles incontrôlables sans condition de sortie et des définitions d'outils suffisamment ambiguës pour que le modèle choisisse le mauvais. Les cinq sont corrigeables sans changer de modèle ni de framework. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** La plupart des défaillances d'agents en production proviennent de cinq causes : des prompts fragiles qui ne gèrent pas les cas limites, une logique de nouvelle tentative manquante pour les erreurs API transitoires, aucune observabilité pour voir ce qui se casse, des boucles incontrôlables sans condition de sortie et des définitions d'outils suffisamment ambiguës pour que le modèle choisisse le mauvais. Les cinq sont corrigeables sans changer de modèle ni de framework. **[Lecture de l'opérateur]** Je gère plus de 30 agents en production. J'ai eu toutes ces défaillances. Celles qui m'ont fait perdre le plus de temps n'étaient pas les exotiques — c'étaient les défaillances d'infrastructure ennuyeuses que je pensais avoir gérées. ## Défaillance 1 : Prompts fragiles qui se cassent sur des entrées en cas limites Un prompt qui fonctionne sur vos cas de test échouera sur des entrées que vous n'avez pas anticipées. Ce n'est pas une limitation du modèle — c'est un problème de rédaction d'instructions. **Symptômes :** L'agent produit une sortie absurde, appelle le mauvais outil ou génère un JSON malformé quand l'entrée est légèrement différente de ce que vous avez testé. **Cause principale :** Votre system prompt décrit uniquement le chemin heureux. Il ne dit pas au modèle quoi faire quand les données sont manquantes, malformées ou ambiguës. **Correction :** Ajoutez une gestion explicite des cas limites à votre system prompt : ``` If the input data is missing a required field, return: { "status": "error", "reason": "missing_field", "field": "" } Do NOT attempt to infer or hallucinate missing values. If you are uncertain which tool to call, call no tool and return: { "status": "clarification_needed", "question": "..." } ``` Le modèle suit des instructions explicites pour les cas limites de manière fiable. L'erreur est de supposer qu'il généralisera les instructions du chemin heureux pour gérer les cas désordonnés. ## Défaillance 2 : Aucune logique de nouvelle tentative pour les erreurs API transitoires Chaque API externe que votre agent appelle échouera à un moment donné. L'API de Claude, la Meta Graph API, votre base de données — toutes renvoient des erreurs 5xx, expirent ou limitent le débit. Si votre agent n'a pas de logique de nouvelle tentative, une erreur transitoire tue toute l'exécution. **Symptômes :** Les exécutions d'agents échouent aléatoirement à différentes étapes. Les journaux montrent un 503 ou 429 sans tentative de suivi. **Correction :** Enveloppez chaque appel externe dans une nouvelle tentative avec retrait exponentiel : ```typescript async function withRetry(fn: () => Promise, retries = 3, baseDelayMs = 500): Promise { for (let attempt = 0; attempt <= retries; attempt++) { try { return await fn(); } catch (err: any) { const isTransient = err.status === 429 || err.status >= 500 || err.code === "ECONNRESET"; if (!isTransient || attempt === retries) throw err; const delay = baseDelayMs * Math.pow(2, attempt) + Math.random() * 100; await new Promise((r) => setTimeout(r, delay)); } } throw new Error("unreachable"); } // Usage const result = await withRetry(() => client.messages.create({ ... })); ``` Trois tentatives avec retrait exponentiel gère ~99% des défaillances transitoires. Ajoutez ceci à chaque appel externe et la moitié de vos défaillances aléatoires disparaîtront. ## Défaillance 3 : Aucune observabilité — vous ne pouvez pas voir ce qui se casse C'est le mode de défaillance le plus courant en production et celui qui coûte le plus de temps à déboguer : l'agent échoue silencieusement ou produit une sortie incorrecte, et vous n'avez aucune idée où dans la chaîne ça a mal tourné. **Symptômes :** Vous savez que quelque chose va mal mais ne pouvez pas identifier l'étape. Vous ajoutez des déclarations `console.log` et ré-exécutez manuellement en essayant de reproduire. **Correction :** Journalisation structurée à chaque étape, avec un ID d'exécution qui trace toute l'exécution : ```typescript function createLogger(runId: string, agentName: string) { return { step: (step: string, data: object) => console.log(JSON.stringify({ runId, agent: agentName, step, ts: new Date().toISOString(), ...data })), error: (step: string, err: unknown) => console.error(JSON.stringify({ runId, agent: agentName, step, error: String(err), ts: new Date().toISOString() })), }; } const log = createLogger(crypto.randomUUID(), "newsletter-agent"); log.step("fetch_topic", { topicId: topic.id, topic: topic.name }); // ... do work ... log.step("draft_complete", { subject: draft.subject, wordCount: draft.body.split(" ").length }); ``` Si vous êtes sur Cloudflare Workers, ces journaux vont dans Logpush ou Workers Tail. Si vous tournez localement ou sur un VPS, canalisez-les vers un agrégateur de journaux. Le JSON structuré signifie que vous pouvez filtrer par `runId` pour voir exactement ce qui s'est passé dans une seule exécution. ## Défaillance 4 : Boucles incontrôlables sans condition de sortie Les boucles agentiques — où le modèle appelle des outils et itère jusqu'à ce qu'une condition soit remplie — peuvent s'exécuter indéfiniment si cette condition n'est jamais remplie ou si le modèle l'identifie mal. **Symptômes :** L'agent dépense des centaines de dollars en coûts API avant d'expirer. Ou il exécute le même appel d'outil encore et encore sans progresser. **Correction :** Ayez toujours un plafond d'itération strict et une vérification de progression : ```typescript const MAX_ITERATIONS = 10; let iterations = 0; let lastToolCallName = ""; let sameToolCallCount = 0; while (true) { iterations++; if (iterations > MAX_ITERATIONS) { log.error("loop", { reason: "exceeded_max_iterations" }); break; } const response = await client.messages.create({ ... }); // Detect stuck loops: same tool called 3x in a row const toolCall = response.content.find(b => b.type === "tool_use"); if (toolCall?.name === lastToolCallName) { sameToolCallCount++; if (sameToolCallCount >= 3) { log.error("loop", { reason: "stuck_loop", tool: toolCall.name }); break; } } else { sameToolCallCount = 0; lastToolCallName = toolCall?.name ?? ""; } if (response.stop_reason === "end_turn") break; } ``` Cela capture à la fois les modes de défaillance "a tourné trop longtemps" et "a tourné en rond". Le plafond doit être suffisamment généreux pour le chemin heureux mais suffisamment serré pour limiter le rayon d'explosion. ## Défaillance 5 : Définitions d'outils ambiguës que le modèle résout mal Si vous donnez au modèle deux outils avec des descriptions qui se chevauchent, il appellera parfois le mauvais. C'est particulièrement courant avec des outils comme `search_database` vs `get_record` ou `send_email` vs `create_draft`. **Symptômes :** Le modèle appelle la bonne catégorie d'outil mais choisit le mauvais spécifique. Ou il appelle un outil dans le mauvais contexte (utilisant un outil d'écriture alors que seule la lecture était appropriée). **Correction :** Rendez les descriptions d'outils mutuellement exclusives et ajoutez explicitement "quand NE PAS utiliser ceci" : ```typescript const tools = [ { name: "get_subscriber", description: "Fetch a single subscriber record by email. Use ONLY when you have a specific email address. Do NOT use for searching or listing subscribers.", input_schema: { ... } }, { name: "search_subscribers", description: "Search subscribers by tag, segment, or status. Use when you need to find subscribers matching a criteria — NOT when you have a specific email address.", input_schema: { ... } } ]; ``` La clause "ne PAS utiliser quand X" est la partie que la plupart des gens ignorent. C'est la partie la plus importante. Les modèles sont meilleurs pour suivre des contraintes négatives explicites que pour les inférer à partir de descriptions positives. ## Encore une chose : testez vos agents sur de mauvaises entrées La plupart des agents sont testés uniquement sur des entrées propres en chemin heureux. La production a des entrées sales : chaînes vides, champs nuls, cas limites Unicode, réponses d'API qui renvoient 200 mais avec un schéma inattendu. Ajoutez une suite de tests qui exercice explicitement : - Entrées vides ou nulles - Entrées à la longueur maximale que vous attendriez - Entrées avec des caractères spéciaux ou du texte non-ASCII - APIs externes renvoyant des formes de réponse inattendues Si votre agent se casse sur l'une d'elles, corrigez-la avant qu'elle ne soit mise en production. L'environnement de production trouvera chaque hypothèse que vous avez faite. ## La conclusion de l'opérateur La plupart des défaillances d'agents en production sont des problèmes d'infrastructure se faisant passer pour des problèmes de modèle. Avant de changer de modèle, ajoutez des nouvelles tentatives, une journalisation structurée, des plafonds de boucle et une gestion explicite des cas limites à vos prompts. Corrigez les définitions d'outils ambiguës. Puis testez sur de mauvaises entrées. Faites tout cela avant de blâmer le modèle — dans mon expérience, le modèle est généralement la dernière chose qui doit changer. --- ## Comment Construire Votre Premier Agent IA en 15 Minutes Source: https://alejandrorioja.com/fr/how-to-build-your-first-ai-agent-in-15-minutes/ Published: 2026-06-02 Updated: 2026-06-02 Tags: AI Agents TL;DR: Vous n'avez pas besoin d'un framework, d'une formation ni d'un doctorat. Vous avez besoin de Node.js, du SDK Anthropic et de 25 lignes de TypeScript. Ce tutoriel construit un agent réel et fonctionnel — un résumeur de contenu structuré que vous pouvez déployer sur Cloudflare dans la même session. Le seul prérequis est une clé d'API gratuite. ## Table des matières _Mis à jour juin 2026._ **TL;DR :** Vous n'avez pas besoin d'un framework, d'une formation ni d'un doctorat. Vous avez besoin de Node.js, du SDK Anthropic et de 25 lignes de TypeScript. Ce tutoriel construit un agent réel et fonctionnel — un résumeur de contenu structuré que vous pouvez déployer sur Cloudflare dans la même session. Le seul prérequis est une clé d'API gratuite. **[Lecture de l'opérateur]** Ce que j'entends le plus souvent de la part des fondateurs qui veulent automatiser avec l'IA, c'est « je dois d'abord en apprendre davantage ». C'est faux. Le pattern d'agent est simple, et le moyen le plus rapide de le comprendre est d'en construire un. Voici le chemin exact que je prendrais si je repartais de zéro aujourd'hui. ## Pourquoi la plupart des tutoriels « construisez un agent IA » vous laissent tomber Soit ils utilisent Python (parfait pour les ingénieurs ML, source de friction pour tous les autres), soit ils cachent le vrai code derrière un framework comme LangChain, soit ils construisent quelque chose de trop abstrait pour le relier à votre travail réel. Ce tutoriel fait trois choses différemment : 1. **TypeScript uniquement** — si vous avez déjà écrit du JavaScript, vous pouvez suivre 2. **Sans framework** — vous verrez chaque ligne de code qui touche le modèle 3. **Un résultat utile** — vous construirez un résumeur structuré que vous pourrez réellement utiliser sur des e-mails clients, des avis ou des notes de réunion ## Ce que vous allez construire Un **agent résumeur de contenu** : collez n'importe quel bloc de texte, et recevez en retour un résumé structuré dans un format cohérent. Une requête HTTP en entrée, un résumé propre en sortie. Pourquoi celui-ci comme premier projet : le pattern — prompt système + entrée utilisateur → sortie structurée — est le fondement de chaque agent que j'exécute. Changez le prompt système et vous obtenez un répondeur de questions, un réécrivain de ton, un classificateur ou un générateur de brouillons. Apprenez ceci une fois et vous aurez appris 80 % de ce que font réellement les agents en production. ## Prérequis (2 minutes) - **Node.js 18+** — vérifiez avec `node --version`. Installez depuis nodejs.org si nécessaire. - **Une clé d'API Anthropic** — inscrivez-vous sur [Claude](/recommends/claude), récupérez une clé depuis la console. Le palier gratuit fonctionne. - Un terminal et un éditeur de texte. Pas de Docker. Pas d'environnement virtuel. Pas de `pip install` quoi que ce soit. ## Étape 1 : Créer le projet (2 minutes) ```bash mkdir my-first-agent && cd my-first-agent npm init -y npm install @anthropic-ai/sdk npm install -D tsx typescript ``` Ajoutez un script à `package.json` pour pouvoir exécuter l'agent facilement : ```json { "scripts": { "agent": "tsx agent.ts" } } ``` ## Étape 2 : Écrire l'agent (5 minutes) Créez `agent.ts` et collez ceci : ```typescript import Anthropic from "@anthropic-ai/sdk"; const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY, }); const SYSTEM_PROMPT = `You are a precise content summarizer. When given any block of text, return a structured summary in this exact format: **One-line summary:** **Key points:** - - - **Action item (if any):** Be specific. No filler. Under 150 words total.`; async function summarize(text: string): Promise { const message = await client.messages.create({ model: "claude-haiku-4-5", max_tokens: 512, system: SYSTEM_PROMPT, messages: [{ role: "user", content: text }], }); const block = message.content[0]; if (block.type !== "text") throw new Error("Unexpected response type"); return block.text; } const sample = ` Hey team — following up on the Q2 review meeting. We agreed to push the launch to July 15th instead of June 30th due to the payment integration delay. Marketing needs the new landing page copy by June 20th or we can't start the email campaign. Budget for the launch campaign is confirmed at $8,000. Please confirm receipt. `; const result = await summarize(sample); console.log(result); ``` ## Étape 3 : L'exécuter (1 minute) ```bash ANTHROPIC_API_KEY=sk-ant-... npm run agent ``` Sortie attendue : ``` **One-line summary:** Launch pushed to July 15th due to payment delay; landing page copy needed by June 20th to unblock email campaign. **Key points:** - Launch date moved from June 30th to July 15th - Landing page copy deadline: June 20th (blocks email campaign) - Campaign budget confirmed at $8,000 **Action item (if any):** Confirm receipt and deliver landing page copy by June 20th. ``` Voilà un agent IA fonctionnel. Entrée réelle, prompt système personnalisé, sortie structurée. Le tout fait 30 lignes de code. ## Étape 4 : Personnalisez-le pour votre cas d'usage Le prompt système est la seule chose qui rend cet agent vôtre. Voici trois alternatives prêtes à l'emploi : **Classificateur d'avis clients :** ```text Classify this customer review as POSITIVE, NEGATIVE, or MIXED. Then extract the main complaint or praise in one sentence. Format: SENTIMENT: