Titre original : What to Learn, Build, and Skip in AI Agents (2026)
Auteur original : Rohit
Traduction : Peggy, BlockBeats

Préface : Le domaine des agents IA entre dans une phase d’explosion d’outils, avec peu de consensus.

Chaque semaine voit apparaître de nouveaux cadres, nouveaux modèles, nouveaux benchmarks et de nouveaux produits « 10 fois plus efficaces », mais la vraie question n’est plus « comment suivre tous ces changements », mais « lesquels valent vraiment la peine d’être investis ».

L’auteur pense qu’à une époque où la pile technologique est constamment réécrite, ce qui peut réellement produire des intérêts composés à long terme n’est pas la poursuite des derniers cadres, mais des capacités plus fondamentales : ingénierie du contexte, conception d’outils, systèmes d’évaluation, mode orchestrator-subagent, pensée sandbox et harness. Ces compétences ne deviennent pas rapidement obsolètes avec le renouvellement des modèles, mais constituent plutôt la base pour construire des agents IA fiables.

L’article va plus loin en soulignant que les agents IA changent aussi la signification de « séniorité ». Autrefois, diplômes, niveaux hiérarchiques et années d’expérience étaient des passeports pour entrer dans le secteur ; mais dans un domaine où même les géants expérimentent encore en public, le CV n’est plus la seule preuve. Ce que vous avez fait, ce que vous avez livré, devient de plus en plus important.

Ainsi, cet article ne discute pas seulement de ce qu’il faut apprendre, utiliser ou éviter en 2026 pour les agents IA, mais rappelle aussi qu’en période de bruit croissant, la compétence la plus rare est la capacité à juger ce qui vaut la peine d’être appris, et à continuer à produire des choses vraiment utiles.

Voici le texte original :

Chaque jour, un nouveau cadre, un nouveau benchmark, un nouveau produit « 10 fois plus efficace » apparaît. La question n’est plus « comment suivre », mais : quels sont les signaux vrais, et quels ne sont que du bruit déguisé en urgence.

Chaque roadmap, un mois après sa publication, peut devenir obsolète. Le cadre que vous maîtrisiez le trimestre dernier est déjà dépassé. Le benchmark que vous avez optimisé est rapidement remplacé après avoir été « battu » par un nouveau. Autrefois, nous étions entraînés à suivre une voie traditionnelle : une pile technologique, une série de rôles et de niveaux ; une expérience professionnelle, des années et des titres ; à gravir lentement l’échelle. Mais l’IA a redessiné cette toile. Aujourd’hui, avec des prompts bien formulés et un sens esthétique affûté, une seule personne peut livrer en une sprint ce qu’il fallait à un ingénieur avec deux ans d’expérience pour faire.

Les compétences professionnelles restent cruciales. Rien ne peut remplacer l’expérience d’avoir vu un système s’effondrer, d’avoir corrigé une fuite mémoire à 2h du matin, ou d’avoir choisi, contre l’avis général, une solution ennuyeuse mais correcte, qui s’est avérée juste. Ce genre de jugement croît en intérêts composés. Mais ce qui ne croît plus comme avant, c’est la familiarité avec « l’API du dernier cadre tendance » : dans six mois, ça aura changé. Deux ans plus tard, ceux qui auront vraiment réussi seront ceux qui auront choisi tôt des capacités fondamentales durables, et laissé passer le bruit.

Depuis deux ans, je construis des produits dans ce domaine, j’ai reçu plusieurs offres supérieures à 250 000 dollars par an, et je travaille aujourd’hui dans une société discrète en charge de la technique. Si quelqu’un me demande : « Qu’est-ce qu’il faut vraiment suivre maintenant ? » — c’est ce que je lui enverrais.

Ce n’est pas une roadmap. Le domaine des agents n’a pas encore de destination claire. Les grands laboratoires expérimentent aussi en public, remettant la question de la régression directement à des millions d’utilisateurs, puis écrivent des bilans et font des corrections en ligne. Si l’équipe derrière Claude Code publie une version qui cause une régression de 47 %, et ne s’en rend compte qu’après que la communauté l’a découverte, alors l’idée qu’il existe une « carte stable en dessous » est une fiction. Tout le monde tâtonne encore. La chance des startups, c’est que même les géants ne savent pas la réponse. Des non-codeurs collaborent avec des agents, livrant vendredi ce que des doctorants en ML pensaient impossible mardi.

Ce moment est particulièrement intéressant car il modifie notre conception de la « séniorité ». La voie traditionnelle valorise l’expérience : diplômes, postes juniors, seniors, niveaux, et progression lente. Quand le domaine ne change pas radicalement, c’est logique. Mais aujourd’hui, le terrain bouge à la même vitesse pour tous. Un jeune de 22 ans qui publie une démo d’agent, et un ingénieur expérimenté de 35 ans, ne se différencient plus par dix ans de maîtrise technique. Ils font face à la même toile blanche. La vraie croissance en intérêts composés, pour eux, c’est la volonté de livrer constamment, et cette petite partie de compétences fondamentales qui ne deviennent pas obsolètes en un trimestre.

Voici le cœur de l’article : une nouvelle façon de juger. Voici une méthode pour décider quelles compétences fondamentales méritent votre attention, et quelles publications peuvent être ignorées. Ce qui vous convient, prenez-le. Ce qui ne vous convient pas, laissez tomber.

Le filtre vraiment efficace

Vous ne pouvez pas suivre chaque nouvelle publication hebdomadaire, et ce n’est pas souhaitable. Ce dont vous avez besoin, ce n’est pas un flux d’informations, mais un filtre.

Au cours des 18 derniers mois, cinq questions ont toujours été efficaces. Avant d’intégrer un nouveau composant à votre stack, passez-les en revue.

Dans deux ans, cela restera-t-il important ?
Si c’est juste une couche superficielle d’un modèle de pointe, un paramètre CLI, ou une version « Devin » d’un logiciel, la réponse est presque toujours non. Si c’est une primitive fondamentale, comme un protocole, un mode de mémoire, ou une méthode sandbox, la réponse est plus probablement oui. Les couches superficielles ont une durée de vie courte, les primitives fondamentales peuvent durer des années.

Une personne respectée a-t-elle déjà construit un vrai produit basé dessus, et en a-t-elle écrit une expérience honnête ?
Les articles marketing ne comptent pas. Les bilans, oui. Un blog intitulé « Nous avons testé X en production, voici ce qui a cassé » a plus de valeur que dix annonces. Dans ce domaine, les signaux utiles viennent toujours de ceux qui ont perdu un week-end à expérimenter.

L’adopter implique-t-il de renoncer à vos mécanismes de traçage, de réessai, de configuration ou d’authentification ?
Si oui, c’est une plateforme. Et une plateforme, c’est à haut risque : 90 % de chances de mourir rapidement. Les bonnes primitives doivent s’intégrer à votre système existant, pas vous forcer à tout changer.

Si vous passez six mois sans l’utiliser, quel sera le coût ?
Pour la plupart des nouveautés, il n’y en a pas. Six mois plus tard, vous en saurez plus, et la version gagnante sera plus claire. Ce test vous permet de passer 90 % des nouveautés sans souci, car leur absence ne vous met pas en retard. La peur de passer à côté est souvent illusoire.

Pouvez-vous mesurer si cela améliore vraiment votre agent ?
Sinon, vous ne faites que deviner. Sans évaluation, votre équipe fonctionne à l’intuition, et le problème revient en production. Avec évaluation, vous pouvez laisser les données vous dire si GPT-5.5 ou Opus 4.7 est meilleur pour votre workload cette semaine.

Si vous ne retenez qu’une seule habitude de cet article, c’est celle-ci : chaque fois qu’une nouveauté sort, écrivez ce que vous devez voir dans six mois pour croire qu’elle est vraiment importante. Et revenez vérifier. La plupart du temps, la réponse est déjà là, et votre attention sera dirigée vers ce qui peut vraiment produire des intérêts composés.

Les capacités derrière ces tests sont plus difficiles à nommer que chaque test lui-même. C’est une capacité à « ne pas suivre la mode ». La tendance qui fait fureur cette semaine sur Hacker News aura une équipe de supporters dans deux semaines, qui paraissent très intelligents. Mais la moitié de ces cadres seront abandonnés dans six mois, et leurs supporters se seront tournés vers le prochain buzz. Ceux qui ne participent pas économisent leur attention, pour se concentrer sur ce qui, après la mode, reste « ennuyeux » mais solide. La maîtrise consiste à résister, à observer, à dire « je saurai dans six mois » — c’est la vraie compétence professionnelle dans ce domaine. Tout le monde lit les annonces, mais peu savent ne pas y réagir.

Ce qu’il faut apprendre

Les concepts, les modèles, la forme des choses. Ce qui produit réellement des intérêts composés, ce sont ces éléments. Ils traversent le changement de modèles, de cadres, de paradigmes. En les comprenant profondément, vous pouvez maîtriser n’importe quel nouvel outil en un week-end. Les ignorer, c’est rester à apprendre en surface indéfiniment.

Ingénierie du contexte

Le changement le plus important des deux dernières années a été la transformation de « Prompt Engineering » en « Context Engineering ». Ce changement est réel, pas juste un changement de nom.

Les modèles ne sont plus de simples récepteurs d’instructions intelligentes. Ils deviennent des entités auxquelles il faut assembler un contexte opérationnel à chaque étape. Ce contexte inclut des instructions système, des schémmas d’outils, des documents récupérés, des sorties précédentes, un scratchpad, et une compression de l’historique. Le comportement de l’agent émerge de tout ce qui est dans la fenêtre de contexte.

Il faut internaliser cette idée : le contexte, c’est l’état. Chaque token inutile réduit la qualité du raisonnement. Un contexte mal géré, c’est une panne réelle. Au huitième pas d’une tâche à dix étapes, l’objectif initial peut être noyé dans la sortie d’outil. Les équipes capables de livrer des agents fiables savent résumer, compresser, et couper le contexte. Elles gèrent les versions des descriptions d’outils, mettent en cache les parties statiques, et refusent de mettre en cache ce qui change. Leur vision de la fenêtre de contexte est celle d’un ingénieur expérimenté qui gère la mémoire.

Une façon concrète de ressentir cela : ouvrir le trace complet d’un agent en production. Regarder le contexte du premier pas, puis celui du septième. Compter combien de tokens sont encore actifs. La première fois, cela peut être embarrassant. Ensuite, on corrige. Et le même agent, sans changer de modèle ni de prompt, devient nettement plus fiable.

Si vous ne l’avez pas encore fait, lisez « Effective Context Engineering for AI Agents » d’Anthropic. Leur étude sur la recherche multi-agent montre avec des chiffres à quel point l’isolation du contexte devient cruciale à grande échelle.

Conception d’outils

Les outils sont le point de contact entre l’agent et votre activité. Le modèle choisit ses outils selon leur nom et leur description, et décide comment réessayer en cas d’erreur. La compatibilité de leur contrat avec la façon dont le LLM s’exprime détermine le succès ou l’échec.

Une dizaine de bons outils, bien nommés, valent mieux que vingt outils médiocres. Le nom doit ressembler à une phrase verbale en anglais naturel. La description doit préciser quand l’utiliser ou non. Les messages d’erreur doivent fournir un retour exploitable par le modèle : « dépassement de 500 tokens, veuillez résumer puis réessayer » est bien meilleur que « Error: 400 Bad Request ». Une équipe de recherche a rapporté qu’en réécrivant simplement ces messages, elle avait réduit de 40 % le nombre de réessais.

« Writing tools for agents » d’Anthropic est une excellente introduction. Après lecture, il faut ajouter des observations sur l’utilisation réelle des outils. La fiabilité d’un agent s’améliore presque toujours grâce à une meilleure conception des outils. Beaucoup se concentrent sur le prompt, mais la vraie levée de levier est là.

Mode orchestrator-subagent

Les débats sur les agents multiples en 2024-2025 ont convergé vers une solution intégrée aujourd’hui adoptée par tous. Un système naïf d’agents parallèles écrivant dans un état partagé échoue catastrophiquement, car les erreurs se cumulent. La seule forme d’agent multiple qui fonctionne en production, c’est celle où un orchestrator délègue des tâches limitées et en lecture seule à des subagents isolés, puis synthétise leurs résultats.

Les systèmes d’Anthropic fonctionnent ainsi. Les subagents de Claude Code aussi. Spring AI et la plupart des frameworks en production standardisent cette approche. Les subagents ont un contexte petit et ciblé, sans pouvoir modifier l’état partagé. La mise à jour est gérée par l’orchestrator.

Les articles « Don’t Build Multi-Agents » de Cognition et « How we built our multi-agent research system » d’Anthropic semblent opposés, mais parlent en réalité de la même chose avec des mots différents. Les deux méritent d’être lus.

On privilégie d’abord un seul agent. Ce n’est que lorsque ses limites sont atteintes — par exemple, la taille de la fenêtre de contexte, la latence due à la séquence d’appels, ou la nécessité de gérer des tâches hétérogènes — qu’on envisage l’orchestrator et les subagents. Construire cette architecture trop tôt, avant d’en ressentir le besoin, ne fait qu’ajouter de la complexité inutile.

Évaluations et jeux de données d’or

Toute équipe capable de livrer un agent fiable possède une évaluation. Sans évaluation, on ne peut pas garantir la fiabilité. C’est la pratique la plus efficace, et aussi celle que je vois le plus sous-estimée.

Une méthode efficace : collecter les traces en production, annoter les échecs, et en faire un jeu de régression. À chaque nouvelle erreur, l’ajouter. Utiliser un LLM comme juge pour la partie subjective, et des vérifications précises ou automatisées pour le reste. Avant tout changement de prompt, modèle ou outil, faire tourner la suite de tests. Spotify rapporte que leur couche de jugement intercepte environ 25 % des mauvais résultats avant déploiement. Sans cela, un mauvais résultat sur quatre arriverait en production.

Le vrai modèle mental ici : l’évaluation, c’est comme un test unitaire, qui garantit que l’agent reste dans son rôle malgré la volatilité. Les nouvelles versions de modèles, les changements de frameworks, ou la dépréciation d’API, peuvent tout faire évoluer. L’évaluation est la seule chose qui vous dit si l’agent fonctionne encore comme prévu. Sans évaluation, vous construisez un système dont la fiabilité dépend d’une cible mouvante.

Les frameworks d’évaluation comme Braintrust, Langfuse, LangSmith sont bons, mais pas le vrai goulot d’étranglement. Le plus important, c’est d’avoir un jeu de données annoté dès le début, avant d’étendre. 50 échantillons, une après-midi pour les annoter. Il n’y a aucune excuse.

Utiliser le système de fichiers comme état, et la boucle Think-Act-Observe

Pour tout agent qui doit faire plusieurs étapes, une architecture robuste repose sur : réfléchir, agir, observer, répéter. Le stockage structuré ou le système de fichiers sont la source de vérité. Chaque action doit être enregistrée et réplicable. Claude Code, Cursor, Devin, Aider, OpenHands, Goose convergent tous vers cette idée, ce n’est pas un hasard.

Le modèle est sans état. La gestion de l’exécution doit être avec état. Le système de fichiers est une primitive connue de tous. En l’adoptant, toute discipline de harness se déploie naturellement : checkpoints, reprise, validation de subagents, sandboxing.

Une autre leçon : dans tout agent de production, le harness fait plus que le modèle. Le modèle décide de la prochaine étape, le harness la vérifie, l’exécute dans un sandbox, capture la sortie, décide de la rétroaction, de l’arrêt, du checkpoint, ou de la création d’un subagent. Changer de modèle ou de fournisseur ne change rien si le harness est bien conçu. Un mauvais harness, même avec le meilleur modèle, produira un agent qui oublie ce qu’il fait.

Si votre système est plus complexe qu’un simple appel d’API, le vrai investissement doit aller dans le harness. Le modèle n’est qu’un composant.

Comprendre le MCP conceptuellement

Ne vous contentez pas d’apprendre à appeler le serveur MCP. Comprenez son modèle. Il sépare clairement capacités, outils et ressources, et fournit une couche d’authentification et de transmission évolutive. Une fois cette architecture comprise, tous les autres « cadres d’intégration agent » ressemblent à des versions allégées de MCP, et vous gagnez du temps en ne les évaluant pas un par un.

La Linux Foundation héberge MCP. La plupart des grands fournisseurs de modèles le supportent. On peut le comparer à « l’USB-C de l’IA » : c’est une réalité plus qu’une critique.

La sandboxing, une primitive fondamentale

Tout agent de production doit fonctionner dans un sandbox. Tous les agents de navigateur ont été confrontés à des injections de prompt indirectes. Tous les agents multi-tenant ont connu des bugs de permissions. La sandboxing doit être vue comme une primitive d’infrastructure, pas comme une option à ajouter après coup.

Il faut apprendre : isolation des processus, contrôle des sorties réseau, gestion des clés, frontières d’authentification entre agent et outils. Les équipes qui attendent que la sécurité soit validée par le client, puis ajoutent ces protections en dernier, risquent de perdre leur marché. Celles qui l’intègrent dès la première semaine, passent plus facilement le processus d’achat.

Ce qu’il faut utiliser comme base

Voici les choix concrets à faire d’ici 2026 avril. Ces choix évolueront, mais pas trop vite. Sur ce niveau, privilégiez la stabilité « ennuyeuse mais fiable ».

Niveau orchestration

LangGraph est la référence en production. Un tiers des grandes entreprises qui déploient des agents l’utilisent. Son abstraction correspond à la réalité des systèmes d’agents : états typés, conditions, workflows persistants, vérifications humaines. C’est un peu verbeux, mais c’est précisément ce qu’il faut pour contrôler un agent en production.

Si vous utilisez principalement TypeScript, Mastra est la référence. La plus claire dans cet écosystème.

Si vous aimez Pydantic et souhaitez une sécurité de type en première classe, Pydantic AI est une option greenfield raisonnable. Sa version 1.0 est sortie fin 2025, et la dynamique est là.

Pour des cas natifs de fournisseur, comme l’utilisation de l’ordinateur, la voix, ou l’interaction en temps réel, utilisez le SDK Claude Agent ou OpenAI Agents dans un nœud LangGraph. Ne cherchez pas à faire de ces SDK le gestionnaire d’orchestration hétérogène. Ils sont optimisés pour leurs cas d’usage.

Niveau protocole

MCP, rien d’autre.

Intégrez vos outils en tant que MCP server. La consommation externe doit suivre la même approche. Le registre MCP a dépassé le point critique : dans la majorité des cas, un serveur prêt à l’emploi est disponible, évitant de tout coder à la main en 2026. Continuer à écrire des plumbing custom, c’est une perte de temps.

Niveau mémoire

Choisissez votre système de mémoire en fonction de l’autonomie de votre agent, pas de sa popularité.

Mem0 pour la personnalisation conversationnelle légère : préférences utilisateur, historique léger. Zep pour des agents de production, surtout si leur état évolue ou doit suivre des entités. Letta pour ceux qui doivent maintenir une cohérence sur plusieurs jours ou semaines. La plupart n’en ont pas besoin, mais ceux qui en ont besoin, en ont vraiment besoin.

Erreur courante : ajouter un framework mémoire sans avoir identifié le problème. Commencez par le contenu que la fenêtre de contexte peut contenir, puis ajoutez une base vectorielle. Ce n’est qu’après avoir compris le mode d’échec que vous pouvez ajouter une mémoire.

Observabilité et évaluations

Langfuse est open source, par défaut. Il couvre le tracing, la gestion des versions de prompts, et l’évaluation LLM-as-judge. Si vous utilisez LangChain, l’intégration avec LangSmith est plus fluide. Braintrust est adapté pour des évaluations de recherche rigoureuses, notamment pour des comparaisons précises. Traceloop / OpenLLMetry supportent l’instrumentation OpenTelemetry multi-langages.

Vous devez avoir à la fois tracing et évaluations. Le tracing répond à « qu’a fait l’agent ? », l’évaluation à « a-t-il progressé ou régressé ? ». Sans ces deux, pas de déploiement. Mettez en place ces outils dès le début, le coût est faible comparé à une correction après coup.

Runtime et sandbox

E2B pour l’exécution sandbox de code généraliste. Browserbase + Stagehand pour l’automatisation navigateur. Anthropic Computer Use pour des contrôles desktop système. Modal pour des tâches ponctuelles.

Ne jamais exécuter du code non sandboxé. Un agent compromis par injection de prompt, en production, peut causer une catastrophe difficile à maîtriser.

Modèles

Suivre aveuglément les benchmarks est épuisant et souvent peu utile. En pratique, d’ici avril 2026 :

• Claude Opus 4.7 et Sonnet 4.6 sont adaptés pour des appels d’outils fiables, la cohérence multi-étapes, et la récupération élégante en cas d’échec. Pour la majorité des workloads, Sonnet offre le meilleur compromis coût/performance.

• GPT-5.4 et GPT-5.5 sont idéaux pour des capacités de raisonnement CLI / terminal, ou si vous utilisez déjà l’infrastructure OpenAI.

• Gemini 2.5 et 3 conviennent pour des tâches à contexte long ou multimodal.

• Quand le coût prime sur la performance, ou pour des tâches à frontières nettes, envisagez DeepSeek-V3.2 ou Qwen 3.6.

Considérez le modèle comme un composant interchangeable. Si votre agent ne fonctionne qu’avec un seul modèle, ce n’est pas une barrière, mais un signe de mauvaise pratique. Utilisez des évaluations pour décider quand déployer tel ou tel modèle. Réévaluez chaque trimestre, pas chaque semaine.

Ce qu’il faut éviter

On vous conseillera sans cesse d’apprendre ou d’utiliser ces outils. En réalité, il vaut mieux les ignorer, car leur coût de rejet est faible, et cela vous fait gagner du temps.

AutoGen et AG2, à éviter en production.
Leur développement est en pause, leur abstraction ne correspond pas aux besoins réels en production. Pour la recherche, oui, mais pas pour le produit.

CrewAI, à éviter pour la construction de nouveaux systèmes.
Très pratique pour des démos, mais les ingénieurs construisant en production migrent déjà vers d’autres solutions. Peut servir pour prototyper, pas pour du long terme.

Microsoft Semantic Kernel, sauf si vous êtes profondément intégrés dans l’écosystème Microsoft et que votre client y tient.
Ce n’est pas la direction que prend l’écosystème.

DSPy, sauf si vous faites de l’optimisation massive de prompts.
Il a une philosophie intéressante, mais son public est restreint. Ce n’est pas un cadre agent universel.

Utiliser un agent de code indépendant comme architecture.
Le « code as action » est une piste intéressante, mais pas la norme en production. Vous rencontrerez des problèmes d’outillage et de sécurité que vos concurrents n’auront pas.

Promotion « agent autonome ».
AutoGPT, BabyAGI, cette voie est morte. La tendance honnête est « agentic engineering » : supervision, limites, évaluation. Ceux qui vendent encore des « agents autonomes » en 2026 vendent du vent de 2023.

Marketplaces et app stores pour agents.
Depuis 2023, certains promettent, mais peu ont réussi à convaincre les entreprises. Les entreprises préfèrent des agents verticaux liés à des résultats précis ou construits en interne. Ne pas se laisser séduire par l’idée d’un app store.

Choix prudents pour les plateformes transverses.
Exemples : Google Agentspace, AWS Bedrock, Microsoft Copilot Studio. Elles peuvent avoir leur intérêt, mais aujourd’hui, la majorité préfère construire ou acheter un agent spécialisé, plutôt que des solutions génériques. Salesforce Agentforce et ServiceNow Now Assist sont des exceptions, car intégrés dans leur workflow.

Ne pas suivre aveuglément les classements comme SWE-bench ou OSWorld.
Les benchmarks publics peuvent être facilement manipulés. Se fier à des évaluations internes ou à des benchmarks privés, comme Terminal-Bench 2.0, est plus fiable.

Architecture naïve de multi-agents parallèles.
Cinq agents partageant une mémoire commune, en démo, ça paraît impressionnant. En production, ça échoue. Si vous ne pouvez pas tracer clairement l’orchestrator et les limites de lecture/écriture, ne déployez pas.

Ne pas utiliser une tarification par siège pour un agent.
Le marché évolue vers des modèles basés sur l’usage ou les résultats. La tarification par siège donne une impression de manque de confiance dans le produit.

Ce que vous verrez cette semaine sur Hacker News.
Attendez six mois. Si c’est encore important, vous le saurez. Sinon, vous aurez évité une migration inutile.

Comment avancer concrètement

Si vous ne souhaitez pas simplement « suivre l’agent », mais l’adopter réellement, voici une séquence efficace, même si elle est ennuyeuse.

Commencez par un résultat clair et important. Ne visez pas un « moonshot » ni un « agent platform » transversal. Choisissez une métrique mesurable : réduire les tickets support, rédiger une première version d’un avis juridique, filtrer des leads entrants, générer un rapport mensuel. La réussite de l’agent dépend de l’amélioration de ce résultat. C’est votre cible d’évaluation dès le départ.

Ce point est crucial, car il va orienter toutes vos décisions suivantes. Avec un résultat précis, « quel cadre utiliser » n’est plus une question philosophique, mais une question de rapidité de livraison. « Quel modèle » devient une question d’évaluation : celui qui prouve son efficacité pour cette tâche spécifique. « Faut-il une mémoire, des subagents, un harness personnalisé » n’est plus une question théorique, mais une décision à prendre uniquement si un mode d’échec précis le nécessite.

Les équipes qui sautent cette étape finiront souvent avec une plateforme générique peu utile. Celles qui la prennent au sérieux livreront un agent étroit, mais rentable en un trimestre. Et cet agent, une fois en production, leur apprendra plus que deux ans de lecture.

Avant de déployer, mettez en place tracing et évaluations. Utilisez Langfuse ou LangSmith, connectez-les. Si besoin, créez un petit dataset gold. 50 échantillons annotés, c’est suffisant pour commencer. Vous ne pouvez pas améliorer ce que vous ne pouvez mesurer. Ajouter cette étape coûte environ 10 fois moins que de le faire après coup.

Commencez avec une boucle simple : un seul agent. Choisissez LangGraph ou Pydantic AI. Modèles : Claude Sonnet 4.6 ou GPT-5. Donnez-lui 3 à 7 outils bien conçus. Faites-le fonctionner avec un stockage (fichiers ou base de données). Testez avec un petit groupe d’utilisateurs, observez traces et logs.

Considérez l’agent comme un produit, pas comme un projet. Il échouera de façon imprévue, et ces échecs seront votre feuille de route. Construisez un jeu de régression à partir de traces réelles. Chaque changement de prompt, de modèle ou d’outil doit passer par une évaluation avant déploiement. La plupart sous-estiment l’investissement ici, mais c’est la clé de la fiabilité.

N’attendez pas pour augmenter la portée : quand la complexité de la fenêtre de contexte devient un frein, introduisez des subagents. Quand la taille de la fenêtre ne suffit plus, utilisez une mémoire. Quand l’API de base ne suffit pas, utilisez des outils comme computer use ou browser use. Ne prévoyez pas tout à l’avance : laissez les modes d’échec vous guider.

Privilégiez une infrastructure simple et stable : MCP pour les outils, E2B ou Browserbase pour sandbox, Postgres ou autre stockage existant. Authentification et observabilité doivent suivre ce qui est en place. La complexité inutile ne fait pas gagner, la discipline oui.

Dès le début, surveillez le coût unitaire : chaque action, cache, boucle de réessai, appel modèle. Un PoC à 0,50 $ par exécution peut devenir 50 000 $ par mois si mal surveillé. Anticipez.

Réévaluez chaque trimestre, pas chaque semaine. Fixez un trimestre, et à la fin, testez le modèle à la pointe. Si ça vaut le coup, changez. Sinon, restez stable. Vous profiterez des progrès, sans vous laisser distraire par chaque nouvelle sortie.

Comment repérer les tendances

Voici quelques signaux concrets qu’une innovation est probablement un vrai signal : un postmortem chiffré d’une équipe respectée, qui montre qu’elle a construit une primitive fondamentale, ou qu’elle a une longue histoire d’utilisation.

À l’inverse, un produit qui ne montre qu’une vidéo de démo après 30 jours, ou un benchmark qui semble trop beau pour être vrai, est probablement du bruit. Les termes « autonomous », « agent OS » ou « build any agent » dans leur pitch, ou des frameworks qui supposent que vous abandonnez votre traçage ou votre authentification, sont aussi des signaux faibles.

Un bon réflexe hebdomadaire : consacrer 30 minutes le vendredi à lire Anthropic, Simon Willison, Latent Space. Si une étude de postmortem est sortie, en lire une ou deux autres. Le reste peut attendre. L’essentiel, c’est de ne pas rater ce qui compte vraiment.

Ce qu’il faut suivre dans les prochains mois

Les deux prochains trimestres, ce ne sont pas forcément les gagnants qui comptent, mais ceux dont la « signalisation » n’est pas encore claire.

Replit Agent 4 et son modèle de fork parallèle.
C’est l’une des premières tentatives sérieuses d’un « multi-agent » qui ne se noie pas dans le partage d’état. Si ça marche à grande échelle, le mode orchestrator-subagent pourrait évoluer.

La maturité du pricing basé sur l’issue.
Sierra et Harvey ont prouvé dans des niches que ce modèle fonctionne. La question est : peut-il s’étendre à d’autres domaines ?

Les compétences comme couche d’encapsulation.
L’augmentation des répertoires AGENTS.md et skills indique une nouvelle façon d’encapsuler les capacités. Resteront-elles standardisées comme MCP ? La question reste ouverte.

Le retour d’expérience sur Claude Code 2026.
Une version qui a causé une régression de 47 %, découverte par les utilisateurs, montre que même chez les leaders, la pratique de l’évaluation en production est encore immature. Si cela pousse à plus d’investissement dans l’évaluation en ligne, c’est une bonne chose.

La voix comme interface client par défaut.
Sierra a dépassé le texte fin 2025. Si cette tendance se généralise, la conception de délais, interruptions, appels en temps réel devra évoluer, et beaucoup d’architectures devront être refaites.

Les modèles open source qui réduisent l’écart avec les propriétaires.
DeepSeek-V3.2 supporte thinking-into-tool-use, Qwen 3.6, et l’écosystème open source s’étend. La différence de coût et de performance sur des tâches étroites évolue. La domination des modèles propriétaires n’est pas une fatalité.

Chacune de ces tendances peut être traduite par une question claire : « dans six mois, qu’est-ce que je dois voir pour croire que c’est important ? » C’est le vrai test. Suivez les réponses, pas les annonces.

Les paris contre-intuitifs

Chaque cadre que vous ne choisissez pas d’adopter est une migration que vous ne faites pas. Chaque benchmark que vous ignorez est un trimestre d’attention. Les entreprises qui gagnent aujourd’hui — Sierra, Harvey, Cursor — ont choisi des objectifs étroits, instauré une discipline ennuyeuse, et laissent passer le bruit.

La voie classique : maîtriser une pile technologique, puis gravir lentement l’échelle. Quand cette pile est stable dix ans, c’est efficace. Mais aujourd’hui, la pile change chaque trimestre. Les vrais gagnants ne cherchent pas à maîtriser une technologie, mais à affiner leur goût, leurs primitives, leur vitesse de livraison. Ils construisent petit, livrent vite, et apprennent en faisant. Leur valeur, c’est leur production, pas leur CV.

Réfléchissez-y sérieusement : la majorité des modèles de travail suppose un monde stable, où la séniorité permet de faire croître la valeur. Vous allez à l’école, obtenez un diplôme, montez l’échelle. Deux ou trois ans ici, trois ou quatre là, et votre CV devient une clé. Tout repose sur l’hypothèse que le secteur est stable.

Mais dans le domaine des agents, il n’y a pas de « face » stable. Les entreprises que vous souhaitez rejoindre ont six mois, leurs frameworks ont moins d’un an, et leurs protocoles fondamentaux datent de deux ans. La moitié des articles cités il y a trois ans n’étaient même pas encore écrits. Il n’y a pas d’échelle à gravir, car le bâtiment est en perpétuelle reconstruction. Quand l’échelle ne fonctionne plus, la seule voie reste : produire, publier, laisser le monde vous découvrir. C’est une voie contre-intuitive, qui contourne la certification de séniorité. Mais dans un domaine en mouvement, c’est la seule qui permet de produire des intérêts composés.

C’est cette vision interne du changement. Même les géants publient en public, font des bilans, corrigent en ligne. Parmi les équipes qui ont livré cette année, certaines n’étaient pas dans le domaine il y a 18 mois. Des non-codeurs collaborent avec des agents pour livrer du vrai logiciel. Des doctorants en ML sont dépassés par des constructeurs qui choisissent vite leurs primitives et agissent rapidement. La porte est grande ouverte. La majorité cherche encore sa voie.

Ce que vous devez vraiment développer, ce n’est pas « agents », mais la discipline de juger ce qui peut produire des intérêts composés dans un monde en constante évolution. L’ingénierie du contexte, la conception d’outils, le mode orchestrator-subagent, l’évaluation, la discipline harness : ce sont ces compétences qui croissent en intérêts composés. Les frameworks sortis mardi ne seront pas durables. La seule vraie compétence, c’est de faire la différence entre ce qui est éphémère et ce qui est durable. Une fois que vous saurez faire cette distinction, chaque nouvelle publication ne sera plus une pression, mais un bruit à ignorer.

Vous n’avez pas besoin d’apprendre tout. Il faut apprendre ce qui croît en intérêts composés, et laisser de côté ce qui ne croît pas. Fixez un objectif : dans six mois, qu’est-ce que je dois voir pour croire que c’est important ? Faites le suivi. La réponse est souvent là, et votre attention doit aller à ce qui peut vraiment produire des intérêts composés.

Les capacités derrière ces tests sont plus difficiles à nommer que les tests eux-mêmes. C’est une capacité à « ne pas suivre la mode ». La tendance qui fait fureur cette semaine sur Hacker News aura une équipe de supporters dans deux semaines, qui paraissent très intelligents. Mais la moitié de ces cadres seront abandonnés dans six mois, et leurs supporters se seront tournés vers le prochain buzz. Ceux qui ne participent pas économisent leur attention, pour se concentrer sur ce qui, après la mode, reste « ennuyeux » mais solide. La maîtrise consiste à résister, à observer, à dire « je saurai dans six mois » — c’est la vraie compétence professionnelle dans ce domaine. Tout le monde lit les annonces, mais peu savent ne pas y réagir.

Ce qu’il faut apprendre

Les concepts, les modèles, la forme des choses. Ce qui produit réellement des intérêts composés, ce sont ces éléments. Ils traversent le changement de modèles, de cadres, de paradigmes. En les comprenant profondément, vous pouvez maîtriser n’importe quel nouvel outil en un week-end. Les ignorer, c’est rester à apprendre en surface indéfiniment.

**Ing