Manus racheté par Meta pour 300 M$ dévoile ses principes fondamentaux de développement d'agents avec LangChain

L’acquisition de Manus par Meta pour 300 millions de dollars fait couler beaucoup d’encre, mais le vrai sujet se trouve ailleurs : dans ce que Manus a révélé lors d’une présentation conjointe avec LangChain. Cette conférence a mis à nu les principes essentiels pour construire des agents IA qui fonctionnent réellement - et a tracé une ligne nette entre les erreurs classiques de startups et les stratégies qui produisent des résultats.

Le paradoxe de la dégradation de contexte

Les agents ont besoin d’outils. Plus d’outils signifie plus de capacités. Mais voici le piège : plus un agent utilise d’outils, plus son contexte grossit - et les performances se dégradent en conséquence directe.

Manus appelle cela le Context Rot (dégradation de contexte). C’est le paradoxe au coeur du développement d’agents : ce qui rend votre agent plus puissant le rend aussi plus bête.

La solution s’appelle le Context Engineering - ne montrer au modèle que l’information dont il a besoin pour l’étape suivante, rien de plus.

Manus a détaillé six techniques concrètes :

• Offload (décharger) - Transférer les données lourdes en tokens vers le système de fichiers au lieu de les garder dans le contexte
• Reduce (réduire) - Supprimer agressivement les informations obsolètes
• Compact (compacter) - Compresser de manière réversible les données récupérables (par exemple, supprimer le contenu d’un fichier mais garder son chemin)
• Summarize (résumer) - Compresser de manière irréversible, mais toujours via un schéma structuré
• Retrieve (récupérer) - Fournir l’information à la demande par la recherche
• Isolate (isoler) - Utiliser des sous-agents avec leurs propres contextes séparés

L’enseignement clé : la gestion du contexte n’est pas une optimisation accessoire. C’est une décision architecturale fondamentale qui détermine si votre agent passe à l’échelle ou s’effondre sous son propre poids.

Ne fine-tunez pas avant le product-market fit

L’une des erreurs de startup les plus courantes pointées par Manus : construire des modèles spécialisés avant d’avoir trouvé son product-market fit.

Le raisonnement est simple. Un modèle généraliste combiné à un context engineering solide permet des cycles d’itération bien plus rapides. Quand on fine-tune trop tôt, on se verrouille sur des hypothèses de comportement utilisateur qui n’ont pas encore été validées.

Le point le plus percutant : la vitesse à laquelle vous pouvez améliorer votre modèle fixe le plafond de votre vitesse d’innovation produit. Le fine-tuning ralentit ce cycle. Le context engineering le maintient rapide.

Gardez le fine-tuning pour quand le produit a fait ses preuves. Avant cela, c’est de l’optimisation prématurée dans sa version la plus coûteuse.

Patterns multi-agents : deux approches distinctes

Manus a identifié deux patterns multi-agents fondamentaux, chacun adapté à un type de travail différent :

Pattern par communication - Les sous-agents démarrent avec une page blanche. L’agent principal envoie une requête ciblée, le sous-agent la traite de manière indépendante et renvoie le résultat. Idéal pour les tâches à faible contexte et parallélisables comme la recherche dans le code ou la récupération de données.

Pattern à mémoire partagée - Les sous-agents partagent l’historique complet de la conversation mais fonctionnent avec des prompts et des jeux d’outils différents. Idéal pour les tâches complexes et interdépendantes comme la recherche approfondie où chaque étape s’appuie sur les résultats précédents.

Le choix entre les deux ne porte pas sur les capacités - il porte sur les besoins en contexte. Si la sous-tâche est autonome, utilisez le pattern par communication. Si elle a besoin de la vue d’ensemble, utilisez la mémoire partagée. Se tromper ici, c’est soit gaspiller des tokens sur du contexte inutile, soit priver les agents d’informations dont ils ont besoin.

Un espace d’actions à trois couches pour éviter la surcharge d’outils

Trop d’outils embrouillent le modèle. La réponse de Manus est une architecture en couches qui limite ce que le modèle voit à chaque instant :

Couche atomique - 10 à 20 capacités de base : lecture, écriture, shell, navigateur. Elles sont toujours disponibles et le modèle les utilise directement.

Utilitaires sandbox - Outils CLI pré-installés comme des convertisseurs, linters et formateurs. Le modèle les invoque via le shell plutôt que comme des outils dédiés.

Packages et API - Scripts Python avec des clés API pré-authentifiées. Ils gèrent les interactions avec les services externes sans exposer toute la surface API au modèle.

Ce découpage en couches garde l’espace de décision du modèle gérable. Au lieu de choisir parmi 200 outils, il sélectionne parmi 15 actions de base et délègue le reste via le shell. Résultat : une sélection d’outils plus fiable et moins d’appels confus ou hallucinés.

Repenser les métriques d’évaluation

Les benchmarks publics comme GAIA ne reflètent pas les préférences réelles des utilisateurs. La position de Manus est directe : le standard de référence, ce sont les évaluations des utilisateurs sur les sessions terminées, notées de 1 à 5.

Trois principes d’évaluation se dégagent :

1. Tests d’exécution plutôt que tests de questions-réponses - L’agent est-il capable de compléter la tâche dans un sandbox ? C’est plus parlant que de savoir s’il peut répondre à des questions sur la tâche.
2. La qualité subjective exige une revue humaine - La finition visuelle, le ton et la cohérence d’ensemble ne se notent pas automatiquement. Il faut qu’un humain regarde le résultat.
3. Les scores de benchmark sont nécessaires mais insuffisants - Ils prouvent une capacité de base. Ils ne prouvent pas que le produit est bon.

La leçon centrale

La sur-ingénierie est l’ennemi.

Les plus gros gains de performance ne viennent pas de l’ajout de complexité - ils viennent de sa suppression. Ne rendez pas le travail du modèle plus difficile. Rendez-le plus simple.

C’est sans doute la raison pour laquelle Meta a payé 300 millions de dollars pour Manus. Pas pour des fonctionnalités tape-à-l’oeil, mais pour une philosophie de conception centrée sur l’essentiel. Supprimer ce qui n’est pas nécessaire, gérer le contexte sans pitié et construire des systèmes où le modèle peut se concentrer sur la tâche au lieu de se noyer dans son propre état.

Les agents qui fonctionnent en production ne sont pas ceux qui ont le plus de capacités. Ce sont ceux qui font compter chaque capacité.