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

Note de l’éditeur : Le domaine des agents IA entre dans une phase d’explosion d’outils, de consensus insuffisant.

Chaque semaine, de nouveaux cadres, nouveaux modèles, nouveaux benchmarks et nouveaux produits « 10 fois plus efficaces » apparaissent, mais la question vraiment importante n’est plus « comment suivre tous ces changements », mais « quels changements 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 capacités 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, rangs 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 publiquement, 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 sauter en 2026 dans le domaine des agents IA, mais aussi de cette réalité : dans une époque 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 : qu’est-ce qui constitue un vrai signal, et qu’est-ce qui n’est que du bruit déguisé en urgence.

Chaque feuille de route, 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é surpassé. Autrefois, nous étions entraînés à suivre une voie traditionnelle : une pile technologique, correspondant à un ensemble de thèmes et de niveaux ; une série d’expériences professionnelles, correspondant à des années et des titres ; à gravir lentement l’échelle. Mais l’IA a réécrit 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 importantes. Rien ne peut remplacer l’expérience d’avoir vu un système s’effondrer, d’avoir ajusté la mémoire à deux heures du matin, ou d’avoir choisi un plan ennuyeux mais correct, qui s’est avéré 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 cadre tendance de la semaine ». Dans six mois, cela aura changé. Deux ans plus tard, ceux qui réussiront seront ceux qui ont choisi tôt des capacités fondamentales durables, et qui laissent 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 suis maintenant responsable de la technique dans une société discrète. 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 feuille de route. Le domaine des agents n’a pas encore de destination claire. Les grands laboratoires expérimentent publiquement, remettant la question à des millions d’utilisateurs, puis écrivent des bilans et font des corrections en ligne. Si l’équipe derrière Claude Code peut publier une version qui cause un recul de 47 % de performance, et que ce problème n’est découvert qu’après que la communauté l’a remarqué, alors l’idée qu’il existe une « carte stable en dessous » est fictive. Tout le monde tâtonne encore. La chance des startups, c’est que même les géants ne savent pas la réponse. Ceux qui ne savent pas coder collaborent avec des agents, livrant vendredi ce que des doctorants en apprentissage automatique pensaient impossible mardi.

Ce moment est particulièrement intéressant car il modifie notre conception de la « séniorité ». La voie traditionnelle valorise : diplômes, postes juniors, postes seniors, niveaux de responsabilité, et une progression lente. Quand le domaine ne change pas radicalement à la base, cela se tient. Mais aujourd’hui, le terrain sous nos pieds 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 seulement par dix ans de maîtrise technique. Ces deux personnes font face à la même toile blanche. Pour eux, la véritable croissance en intérêts composés concerne la volonté de livrer constamment, et cette petite partie de capacités fondamentales qui ne deviennent pas obsolètes en un trimestre.

C’est le cœur de toute cette reconstruction. Ensuite, je vais proposer une méthode pour juger : quelles capacités 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.

Un filtre vraiment efficace

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

Au cours des 18 derniers mois, cinq questions ont toujours été valides. Avant d’intégrer une nouvelle chose à votre stack, passez-les en revue.

Dans deux ans, cela sera-t-il encore important ?
Si c’est juste une couche supplémentaire sur un modèle de pointe, un paramètre CLI, ou une version « Devin » spécifique, 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 produits emballés ont une demi-vie courte, les primitives fondamentales peuvent durer des années.

Une personne que vous respectez a-t-elle déjà construit un vrai produit basé dessus, et en a-t-elle honnêtement partagé l’expérience ?
Les articles marketing ne comptent pas, les revues de production oui. Un blog intitulé « Nous avons testé X en production, et voici ce qui a posé problème » vaut plus que dix annonces. Les signaux vraiment utiles dans ce domaine 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 existants ?
Si oui, c’est une tentative de faire de ce cadre une plateforme. Or, une telle plateforme a 90 % de chances d’échouer. Les bons primitives fondamentales doivent s’intégrer à votre système existant, pas vous forcer à tout migrer.

Si vous sautez cette publication six mois, quel sera le coût ?
Pour la plupart des releases, 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 releases sans souci. Mais c’est aussi la règle que beaucoup refusent, car sauter une étape donne l’impression d’être en retard. En réalité, ce n’est pas le cas.

Pouvez-vous mesurer si cela améliore vraiment votre agent ?
Si non, vous ne faites que deviner. Sans évaluation, votre équipe fonctionne à l’intuition, et le problème de régression finit en ligne. Avec évaluation, les données vous disent si GPT-5.5 ou Opus 4.7 est meilleur pour cette charge de travail spécifique.

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

Les capacités derrière ces tests sont plus difficiles à nommer que n’importe quelle règle. C’est une capacité à « ne pas suivre la mode ». La tendance qui explose sur Hacker News cette semaine aura une équipe de supporters dans quatorze jours, qui paraissent très intelligents. Mais la moitié de ces cadres seront abandonnés dans six mois, et ces supporters se seront tournés vers le prochain sujet à la mode. Ceux qui ne participent pas économisent leur attention, la réservant à ce qui, après la mode, reste « ennuyeux » mais solide. La maîtrise consiste à se retenir, observer, et dire « dans six mois, je saurai ». C’est une vraie compétence professionnelle dans ce domaine. Tout le monde lit les annonces, mais peu savent ne pas 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, et de paradigmes. En les comprenant profondément, vous pouvez maîtriser n’importe quel nouvel outil en un week-end. En les ignorant, vous passerez votre vie à réapprendre des mécanismes superficiels.

Ingénierie du contexte

Le changement le plus important des deux dernières années est 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 vous devez assembler un contexte opérationnel à chaque étape. Ce contexte inclut à la fois des instructions système, des schémmas d’outils, des documents récupérés, des sorties précédentes, un scratchpad, et un historique compressé. Le comportement de l’agent résulte de l’émergence de tout ce que vous mettez dans la fenêtre de contexte.

Il faut internaliser cette idée : le contexte, c’est l’état. Chaque token inutile dégrade la qualité du raisonnement. La dégradation du contexte est une panne réelle. Lorsqu’on atteint la huitième étape d’une tâche en dix, la cible initiale peut être noyée dans la sortie des outils. 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 approche du 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 de la première étape, puis celui de la septième. Compter combien de tokens sont encore actifs. La première fois, cela peut être embarrassant. Ensuite, vous corrigerez, et le même agent, sans changer de modèle ni de prompt, deviendra nettement plus fiable.

Si vous ne l’avez pas encore fait, lisez Anthropic « Effective Context Engineering for AI Agents ». Leur revue sur la recherche multi-agent montre avec des chiffres à quel point l’isolation du contexte devient cruciale à mesure que le système s’agrandit.

Conception d’outils

Les outils sont le point de contact entre l’agent et votre activité. Le modèle choisit l’outil selon son nom et sa description, et décide comment réessayer en fonction des erreurs. La compatibilité de la conception de l’outil avec la façon dont le LLM s’exprime détermine le succès ou l’échec du modèle.

Cinq à dix 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, quand ne pas l’utiliser. Les messages d’erreur doivent fournir un retour exploitable par le modèle, par exemple : « Limite de 500 tokens dépassée, 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 le message d’erreur, elle avait réduit de 40 % le nombre de tentatives de réessai.

« Writing tools for agents » d’Anthropic est une excellente introduction. Après lecture, ajoutez des observations sur vos propres outils, et analysez leur mode d’utilisation réel. La fiabilité de l’agent s’améliore presque toujours du côté des outils. Beaucoup de gens ajustent leur prompt sans réaliser que c’est là que se trouve le vrai levier.

Mode orchestrator-subagent

Les débats sur les agents multiples en 2024 et 2025 ont convergé vers une solution intégrée aujourd’hui adoptée par tous. Un système naïf d’agents multiples, où plusieurs agents écrivent en parallèle dans un état partagé, échoue de façon catastrophique, car les erreurs se cumulent. La seule forme d’agent multiple qui fonctionne en production 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 de recherche d’Anthropic fonctionnent ainsi. Les subagents de Claude Code aussi. Spring AI et la plupart des frameworks de production standardisent cette approche. Les subagents ont un contexte petit et ciblé, et ne peuvent pas modifier l’état partagé. La mise à jour est assuré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 en réalité ils parlent de la même chose avec des termes différents. Les deux méritent d’être lus.

Utilisez par défaut un seul agent. N’attendez pas que la limite du contexte soit atteinte pour envisager l’orchestrator et les subagents : par exemple, en cas de pression sur la fenêtre de contexte, de latence due à la séquence d’appels d’outils, ou de tâches hétérogènes qui bénéficieraient d’un contexte ciblé. Construire cette architecture avant d’en ressentir le besoin ne fait que compliquer inutilement.

Évaluations et jeux de données d’or

Toute équipe capable de livrer un agent fiable dispose d’évaluations. Sans évaluation, il est difficile de produire un agent fiable. C’est la pratique la plus efficace en termes de levier dans ce domaine, et aussi celle que je vois le plus sous-estimée dans toutes les entreprises.

Une pratique efficace consiste à collecter les traces en production, à annoter les échecs, et à en faire un ensemble de régressions. À chaque nouvelle erreur en production, on l’ajoute. La partie subjective est gérée par un LLM en tant que juge, le reste par des vérifications exactes ou automatisées. Avant tout changement de prompt, modèle ou outil, on exécute la batterie de tests. Le blog de Spotify Engineering indique que leur couche de jugement intercepte environ 25 % des mauvaises sorties avant qu’elles n’atteignent l’utilisateur. Sans cela, une mauvaise sortie sur quatre arriverait en production.

Le vrai mental de cette démarche : l’évaluation est un test unitaire, qui garantit qu’en dépit des changements constants, l’agent reste fidèle à sa mission. Les nouvelles versions de modèles, les changements destructeurs dans le framework, ou la dépréciation d’un endpoint, doivent tous passer par cette évaluation. Sans évaluation, on écrit un système dont la validité dépend d’une cible mouvante.

Les frameworks d’évaluation comme Braintrust, Langfuse evals, ou LangSmith sont très bons, mais ce n’est pas là le vrai goulot d’étranglement. Le plus important, c’est d’avoir un jeu de données annoté dès le départ. Commencez dès le premier jour. 50 échantillons, une après-midi pour les annoter. Il n’y a aucune excuse.

Considérez le système de fichiers comme un état, et adoptez la boucle Think-Act-Observe

Pour tout agent qui exécute un vrai processus multi-étapes, l’architecture durable est : réfléchir, agir, observer, répéter. Le système de fichiers ou le stockage structuré sont la source de vérité. Chaque action est enregistrée et peut être rejouée. Claude Code, Cursor, Devin, Aider, OpenHands, Goose convergent vers cette approche, ce n’est pas un hasard.

Le modèle lui-même est sans état. Le cadre d’exécution doit être avec état. Le système de fichiers est une primitive d’état que tout développeur comprend. En adoptant cette approche, toute la discipline harness se déploie naturellement : checkpoints, résilience, validation de sous-agents, sandboxing.

Une autre leçon plus profonde : dans tout agent de production digne de payer pour sa puissance de calcul, le harness fait plus que le modèle. Le modèle choisit la prochaine action, le harness la vérifie, l’exécute dans un sandbox, capture la sortie, décide quoi renvoyer, quand arrêter, quand faire un checkpoint, quand générer un sous-agent. En remplaçant le modèle par un autre de même qualité, un bon harness livrera toujours un produit. En utilisant un harness médiocre, même le meilleur modèle produira un agent qui oublie ce qu’il fait au hasard.

Si votre système est plus complexe qu’un simple appel d’outils, la priorité doit être le harness. Le modèle n’est qu’un composant.

Comprendre MCP en profondeur

Ne vous contentez pas d’apprendre à appeler le serveur MCP. Comprenez son modèle. Il établit une séparation claire entre capacités d’agent, outils et ressources, et fournit une authentification et un transport évolutifs. Une fois cette compréhension acquise, tous les autres « frameworks d’intégration d’agents » apparaissent comme des versions allégées de MCP, et vous gagnez du temps en évitant de les évaluer 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 », et cela devient de plus en plus une réalité plutôt qu’une simple critique.

La sandboxing est 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-locataires ont connu des bugs de permissions. La sandboxing doit être considérée comme une primitive d’infrastructure, pas comme une fonctionnalité à ajouter après coup.

Il faut apprendre les bases : 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 pour ajouter ces protections perdent du temps. Celles qui l’intègrent dès la première semaine passent plus facilement le processus d’achat en entreprise.

Que faut-il utiliser pour construire

Voici les choix concrets à partir d’avril 2026. Ces choix évolueront, mais pas trop vite. Sur ce niveau, privilégiez la stabilité et la simplicité.

Niveau d’orchestration

LangGraph est le choix par défaut en production. Environ 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, frontières conditionnelles, workflows persistants, checkpoints avec intervention humaine. Son inconvénient est la verbosité ; son avantage est qu’en production, ces contrôles sont nécessaires, et sa verbosité correspond à ces besoins.

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

Si votre équipe préfère Pydantic et veut une sécurité de type en première classe, Pydantic AI est une option raisonnable pour un greenfield. La 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 d’eux des orchestrateurs hétérogènes. Ils sont optimisés pour leurs scénarios respectifs.

Niveau de protocole

MCP, rien d’autre.

Intégrez vos outils en tant que serveur MCP. La consommation externe doit suivre la même approche. Le registre MCP a dépassé le point critique : dans la majorité des cas, vous pouvez déjà utiliser un serveur existant, sans devoir tout coder vous-même. En 2026, coder à la main votre plumbing d’outils devient une perte de temps.

Niveau de mémoire

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

Mem0 est adapté pour la personnalisation conversationnelle : préférences utilisateur, historique léger. Zep convient pour des systèmes de dialogue en production, notamment ceux avec évolution continue et suivi d’entités. Letta est pour ceux qui doivent maintenir une cohérence sur plusieurs jours ou semaines. La plupart des équipes n’en ont pas besoin, mais celles qui en ont besoin, en ont vraiment besoin.

Erreur courante : vouloir ajouter un système de mémoire avant d’avoir résolu le problème de la mémoire. Commencez par un contenu dans la fenêtre de contexte, puis ajoutez une base vectorielle. N’ajoutez un système de mémoire que lorsque vous pouvez clairement définir ses cas d’échec.

Observabilité et évaluations

Langfuse est la solution open source par défaut. Elle peut être auto-hébergée, sous licence MIT, et couvre le tracing, la gestion des versions de prompts, et l’évaluation LLM en tant que juge. Si vous utilisez LangChain, l’intégration avec LangSmith est plus fluide. Braintrust est adapté pour des workflows d’évaluation de recherche, notamment pour des comparaisons rigoureuses. OpenLLMetry / Traceloop conviennent pour une instrumentation multi-langues avec OpenTelemetry, sans vendor lock-in.

Il faut disposer à la fois de tracing et d’évaluations. Le tracing répond à « qu’a fait l’agent ? » ; l’évaluation à « l’agent s’est-il amélioré ou dégradé par rapport à hier ? » Sans ces deux, pas de déploiement. La mise en place doit commencer dès le début, à moindre coût, et être maintenue.

En runtime et sandbox

E2B est adapté pour l’exécution sandbox de code généraliste. Browserbase avec Stagehand pour l’automatisation navigateur. Anthropic Computer Use pour des scénarios nécessitant un contrôle de niveau système d’exploitation. Modal pour des tâches ponctuelles.

Ne jamais exécuter du code non sandboxé. Un agent compromis par injection de prompt, s’il est déployé en production, peut causer une explosion de risques que vous ne souhaitez pas raconter.

Modèles

Suivre les benchmarks est fatigant et souvent peu utile. En pratique, jusqu’en avril 2026 :

· Claude Opus 4.7 et Sonnet 4.6 conviennent pour des appels d’outils fiables, la cohérence multi-étapes, et la gestion élégante des échecs. Pour la majorité des charges, 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 très avancées, ou si vous utilisez déjà l’infrastructure OpenAI.

· Gemini 2.5 et 3 sont adaptés pour des tâches à contexte long ou multimodal intensif.

· Quand le coût prime sur la performance, ou pour des tâches à frontières nettes et définition précise, 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 un avantage compétitif, mais une faiblesse. Utilisez des évaluations pour décider quel modèle déployer. Réévaluez chaque trimestre, pas chaque semaine.

Ce qu’il faut sauter

Vous serez constamment conseillé d’apprendre ou d’utiliser ces choses. En réalité, il vaut mieux les sauter. Le coût de leur omission est faible, et cela vous fait gagner beaucoup de temps.

AutoGen et AG2, à ne pas utiliser en production.
Ce framework de Microsoft est passé à une maintenance communautaire, son rythme de publication a ralenti, et son abstraction ne correspond pas aux besoins réels des équipes de production. Peut servir pour la recherche, mais pas pour le produit.

CrewAI, à ne pas utiliser pour de nouvelles constructions en production.
On le voit partout car il est pratique pour faire des démos. Mais les ingénieurs qui construisent en production migrent déjà vers autre chose. Vous pouvez l’utiliser pour prototyper, mais 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 optimisez à grande échelle des prompts.
Il a une valeur philosophique, mais un public très restreint. Ce n’est pas un cadre agent universel, et ne doit pas être choisi comme tel.

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

Promotion du type « agent autonome »

AutoGPT et BabyAGI, cette voie est morte. La vérité dans l’industrie est « engineering agentique » : supervision, limites, évaluation. Ceux qui vendent encore en 2026 un « agent autonome » qui ne nécessite plus d’intervention après déploiement, vendent en réalité une technologie de 2023.

Marketplaces et app stores d’agents

Depuis 2023, certains promettent cela, mais sans succès réel en entreprise. Les entreprises n’achètent pas d’agents préfabriqués génériques. Elles préfèrent des agents verticaux liés à des résultats précis, ou construisent eux-mêmes. Ne basez pas votre business sur un rêve d’app store.

Choix prudents pour les plateformes d’agents horizontaux

Exemples : Google Agentspace, AWS Bedrock Agents, Microsoft Copilot Studio.
Ils pourraient être utiles, mais actuellement, c’est confus, lent, et la balance « acheter ou construire » penche souvent vers la construction d’un agent spécialisé ou l’achat d’un agent vertical. Salesforce Agentforce et ServiceNow Now Assist sont des exceptions, car intégrés dans des workflows existants.

Ne pas suivre les classements SWE-bench ou OSWorld.
Selon une étude de Berkeley en 2025, presque tous les benchmarks publics peuvent être manipulés pour grimper dans le classement, sans résoudre réellement la tâche sous-jacente. Les équipes privilégient désormais Terminal-Bench 2.0 et leurs propres évaluations internes. La confiance dans un benchmark basé uniquement sur un chiffre est limitée.

Une architecture naïve de multi-agents parallèles.
Cinq agents autour d’une mémoire partagée, en démo, semblent impressionnants. En production, cela échoue. Si vous ne pouvez pas tracer clairement un diagramme orchestrator-subagent avec des frontières de lecture/écriture, ne déployez pas.

Ne pas utiliser une tarification par siège pour un nouveau produit agent.
Le marché évolue vers une tarification basée sur les résultats ou la consommation. Facturer par siège donne une impression de manque de confiance dans le produit, et réduit vos marges.

Ce que vous verrez cette semaine sur Hacker News, comme nouveau cadre.
Attendez six mois. S’il reste 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 vraiment l’adopter, voici une séquence efficace. Elle peut sembler ennuyeuse, mais elle fonctionne.

Commencez par un résultat important. Ne visez pas un projet « moonshot » ou une plateforme horizontale. Choisissez un objectif mesurable et pertinent pour votre activité : réduire les tickets support, rédiger une première version d’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 contraint toutes les décisions suivantes. Avec un résultat précis, « quel cadre choisir » n’est plus une question philosophique, mais une question de rapidité de livraison. « Quel modèle » devient une question d’évaluation prouvant l’efficacité pour cette tâche. « Faut-il de la mémoire, des sous-agents, un harness personnalisé » ne sont plus des expérimentations, mais des ajouts conditionnels en cas d’échec spécifique.

Les équipes qui sautent cette étape finiront souvent avec une plateforme horizontale inutile. 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 quoi que ce soit, configurez tracing et évaluations. Choisissez Langfuse ou LangSmith, et connectez-les. Si nécessaire, créez un petit dataset gold. 50 échantillons annotés suffisent pour commencer. Vous ne pouvez pas améliorer ce que vous ne pouvez mesurer. Ajouter cette étape plus tard coûte environ dix fois plus.

Commencez avec une boucle simple : un seul agent. Choisissez LangGraph ou Pydantic AI. Modèle : Claude Sonnet 4.6 ou GPT-5. Donnez-lui trois à sept outils bien conçus. Faites-le utiliser un système de fichiers ou une base de données pour l’état. Testez avec un petit groupe d’utilisateurs, en observant les traces.

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

Une fois que vous avez « gagné » la capacité d’étendre, augmentez la complexité. Quand la limite du contexte devient un goulot d’étranglement, introduisez des subagents. Quand le contenu dépasse la fenêtre, utilisez un cadre de mémoire. Quand l’API de base ne suffit pas, utilisez computer use ou browser use. Ne planifiez pas ces éléments à l’avance, laissez les modes d’échec les faire entrer.

Choisissez une infrastructure simple : MCP pour les outils, E2B ou Browserbase pour sandbox, Postgres ou votre stockage actuel pour l’état. Authentification et observabilité, utilisez vos systèmes existants. La complexité extrême n’est pas la clé, la discipline l’est.

Depuis le premier jour, surveillez le coût unitaire. Chaque action, cache, boucle de réessai, appel modèle. Un PoC à 0,50 $ par exécution peut exploser à 50 000 $ par mois si vous ne surveillez pas. La croissance de coûts inattendue est une erreur fatale.

Réévaluez chaque trimestre, pas chaque semaine. Fixez un trimestre. À la fin, exécutez votre suite d’évaluation avec le dernier modèle à la pointe. Si les données montrent qu’il faut changer, faites-le. Cela permet de profiter des progrès tout en évitant la confusion des changements hebdomadaires.

Comment repérer une tendance

Voici quelques signaux concrets qu’un phénomène est un vrai signal : une équipe respectée publie un postmortem chiffré, pas seulement une annonce ; c’est une primitive fondamentale, pas un emballage ; il peut s’interopérer avec votre système existant, pas le remplacer ; il explique ce qu’il résout comme échec, pas ce qu’il ouvre comme capacité ; il existe depuis longtemps, au point que quelqu’un ait écrit un blog « ce qui n’a pas marché ».

Voici quelques signaux que ce n’est que du bruit : 30 jours après, il n’y a que des démos vidéo, pas de cas en production ; le benchmark semble trop parfait pour être vrai ; le pitch utilise sans limite « autonome », « agent OS » ou « build any agent » ; la documentation suppose que vous abandonnez tracing, auth, config ; le nombre d’étoiles augmente vite, mais pas les commits, releases ou contributeurs ; Twitter va vite, GitHub pas autant.

Une habitude utile : consacrer 30 minutes chaque vendredi à la veille dans ce domaine. Lire trois choses : le blog d’Anthropic, les notes de Simon Willison, Latent Space. Si cette semaine il y a un postmortem, lire une ou deux autres analyses. Sinon, passer. Vous ne manquerez pas l’essentiel.

Ce qu’il faut surveiller

Les deux prochains trimestres, ce qui compte, ce n’est pas que cela gagne, mais que la question « est-ce un vrai signal » soit encore ouverte.

Le modèle de fork parallèle de Replit Agent 4.
C’est l’une des premières tentatives sérieuses de faire fonctionner plusieurs agents en parallèle sans que le partage d’état ne pose problème. Si cela fonctionne à grande échelle, le mode orchestrator-subagent pourrait évoluer.

La maturité de la tarification basée sur les résultats.
Les trajectoires de revenus de Sierra et Harvey ont déjà validé ce modèle dans des niches. La question est : peut-il s’étendre à d’autres domaines ou est-il limité à des verticales ?

Les compétences comme couche d’encapsulation des capacités.
L’augmentation des fichiers AGENTS.md et des répertoires skills sur GitHub indique une nouvelle façon d’emballer les capacités d’un agent. Sera-t-elle standardisée comme MCP ? La réponse est ouverte.

Le retour d’expérience sur la dégradation de qualité de Claude Code en avril 2026.
Un agent leader du secteur a publié une version qui a causé un recul de 47 %, et ce sont les utilisateurs qui l’ont découvert en premier, puis l’équipe interne. Cela montre que même chez les leaders, la pratique d’évaluation en production est encore immature. Si cela pousse à investir dans de meilleures évaluations en ligne, c’est une évolution saine.

La voix comme interface client par défaut.
Sierra a dépassé le texte fin 2025. Si cette tendance se généralise, la latence, les interruptions, et la conception d’outils en temps réel deviendront des enjeux majeurs, et beaucoup d’architectures devront être refaites.

Les modèles open source capables d’agir comme agents continuent de réduire l’écart.
DeepSeek-V3.2 supporte thinking-into-tool-use nativement, Qwen 3.6 et l’écosystème open source s’étendent. Le coût de tâches étroites avec ces modèles é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 vraiment important ? » C’est le test. Suivez la réponse, pas la communication.

Les paris contre l’intuition

Chaque cadre que vous ne choisissez pas d’adopter est une migration que vous ne faites pas pour l’avenir. Chaque benchmark que vous ne poursuivez pas est un trimestre de concentration. Les entreprises qui gagnent aujourd’hui — Sierra, Harvey, Cursor — ont toutes choisi des objectifs étroits, instauré une discipline ennuyeuse, et laissé passer le bruit.

La voie traditionnelle : choisir une pile technologique, la maîtriser pendant des années, puis gravir lentement l’échelle. Quand cette pile est stable dix ans, cela fonctionne. 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, et leur rapidité de livraison. Ils construisent petit, livrent vite, et apprennent par la pratique. Leur valeur, c’est leur production, pas leur CV.

Réfléchissez-y sérieusement, car c’est ce que l’article veut vraiment transmettre. La majorité d’entre nous fonctionne selon un modèle qui suppose que le monde sera stable assez longtemps pour que la séniorité produise des intérêts composés. On va à l’école, on obtient un diplôme, on grimpe l’échelle. Deux ans ici, trois ans là, et le 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 plus de « face stable ». Les entreprises que vous souhaitez rejoindre ont peut-être six mois. Leurs frameworks ont moins d’un an et demi. Les protocoles sous-jacents ont deux ans. La moitié des articles cités depuis trois ans n’étaient pas encore écrits quand leurs auteurs ont commencé. Il n’y a pas de ladder, car le bâtiment est en perpétuelle évolution. Quand l’échelle ne fonctionne plus, la seule méthode ancienne reste : produire quelque chose, le mettre en ligne, laisser le produit parler pour vous. C’est une voie contre-intuitive, car elle contourne le système de certification de séniorité. Mais dans un domaine en mouvement constant, c’est la seule voie pour produire des intérêts composés.

Voici la vision du domaine vue de