Manus’ ex-lead dropped function calling — what it changes for e-commerce

Last updated: 3 April 2026 · Reading time: 11 min

Why did an AI agent expert abandon function calling?

Le 12 mars 2026, le backend lead de Manus — un des projets d’agents IA les plus suivis — a publié un post sur r/LocalLLaMA qui a secoué la communauté technique. Après 2 ans à construire des agents avec function calling, il a expliqué pourquoi il abandonne cette approche. Résultat : 1 927 upvotes et 409 commentaires en quelques jours.

Pour comprendre l’ampleur de ce pivot, il faut comprendre ce qu’est le function calling. C’est le mécanisme standard par lequel un LLM (modèle de langage) interagit avec le monde extérieur. Le modèle dispose d’un catalogue de fonctions prédéfinies — par exemple search_product(query, category, price_max) — et génère un appel structuré avec les bons paramètres.

Ce modèle domine l’écosystème depuis 2023. OpenAI, Anthropic, Google : tous les fournisseurs de LLM proposent le function calling comme méthode principale pour construire des agents. Les frameworks comme LangChain, CrewAI et AutoGen sont bâtis autour de ce paradigme.

Les limites identifiées par le lead de Manus

L’observation du développeur est précise : après des milliers d’itérations en production, le function calling présente des frictions structurelles :

• Rigidité du schéma : chaque nouvelle capacité exige la définition d’une nouvelle fonction, avec ses paramètres typés, sa documentation, ses tests. L’agent est limité au catalogue de fonctions que le développeur a anticipé
• Explosion combinatoire : quand un agent e-commerce doit gérer filtrage, tri, comparaison, calcul de remise, vérification de stock et recommandation, le nombre de fonctions nécessaires croît de façon exponentielle
• Latence cumulée : chaque appel de fonction représente un aller-retour entre le LLM et le système hôte. Un parcours complexe peut exiger 8 à 12 appels séquentiels
• Perte de contexte : entre deux appels, le LLM doit reconstruire le contexte de la conversation. Les résultats intermédiaires sont sérialisés puis désérialisés, avec une perte d’information à chaque étape

Le mot-clé de son analyse : le function calling transforme le LLM en dispatcher. Il choisit quelle fonction appeler et avec quels paramètres, mais il est incapable de composer des actions originales. C’est un standardiste téléphonique dans un monde qui exige un développeur.

Comment fonctionne l’alternative : le code eval ?

L’alternative proposée par le lead Manus est radicale par sa simplicité : au lieu de définir un catalogue de fonctions, on laisse le LLM générer du code qui s’exécute directement. Le modèle écrit en Python (ou JavaScript), le code tourne dans un environnement contrôlé, le résultat revient au LLM.

Un exemple concret : la recherche produit

Avec le function calling classique, un agent e-commerce doit appeler une série de fonctions :

With the eval code, the LLM writes directly:

Un bloc de code remplace trois appels de fonction. Le LLM compose sa logique librement au lieu de la découper en appels atomiques.

Validation communautaire

La réaction sur r/LocalLLaMA a été immédiate. Massive. Le commentaire le plus upvoté (211 upvotes) rapportait une expérience convergente :

Another very popular comment went further:

Les LLMs excellent à générer du code. Leur demander d’écrire du code exécutable est plus naturel que de les forcer à piocher dans un menu de fonctions prédéfinies. On exploite leur force première : la génération de texte structuré.

Why it works: The theory behind code eval

Function calling enferme le LLM dans un espace d’actions discret : il choisit parmi N fonctions. Le code eval ouvre un espace d’actions continu : il compose librement ses instructions. La différence est fondamentale. Un agent avec 50 fonctions prédéfinies exécute 50 actions. Un agent avec un interpréteur Python ? Combinaisons infinies.

Concrètement, un agent e-commerce en code eval peut :

• Combiner des filtres que tu n’avais pas prévus : « Tous les manteaux avec un ratio avis/prix au-dessus de la médiane catégorie »
• Générer des analyses dynamiques : calculer un score de pertinence personnalisé pour chaque produit en temps réel
• Adapter sa stratégie au contexte : écrire un workflow différent selon la complexité de la requête utilisateur

Quels avantages pour les agents e-commerce ?

Pour un e-commerçant, le passage de function calling au code eval change directement la qualité de l’expérience agent et la vitesse de développement.

1. Des recommandations produit radicalement plus fines

Un agent function calling recommande un produit parce qu’il correspond à des critères prédéfinis — catégorie, prix, note. Un agent en eval code compose une logique de recommandation sophistiquée en temps réel : pondère la note par la fraîcheur des avis, croise la disponibilité avec le délai de livraison, intègre l’historique de navigation du client. Le tout dans un seul bloc de code généré à la volée.

2. Une réduction massive de la latence

Au lieu de 8 à 12 appels séquentiels pour un parcours de recommandation complet, l’agent génère un seul bloc de code qui exécute toute la logique. La latence perçue par l’utilisateur chute. Pour un chatbot e-commerce, c’est la différence entre une réponse en 3 secondes et une réponse en 800 millisecondes.

3. Coût de maintenance réduit

Function calling impose de maintenir un catalogue de fonctions documentées, testées, versionnées. Chaque nouvelle fonctionnalité — un nouveau filtre, un nouveau critère de tri, une nouvelle règle promo — exige du code côté serveur. Avec le code eval, le LLM s’adapte au contexte disponible. Tu exposes les données et une API basique ; il invente le reste.

4. Adaptation instantanée aux demandes imprévues

Cas classique : un client demande « Compare ces 3 produits en tenant compte des retours gratuits et de l’éco-responsabilité des matériaux ». Avec function calling, cette requête échoue si aucune fonction compare_products_with_return_policy_and_sustainability n’existe. Avec eval code, l’agent écrit le code de comparaison à la volée, en interrogeant les données structurées disponibles.

Quels sont les risques de cette approche ?

Sur r/LocalLLaMA, 409 commentaires. Le débat était vif. La communauté a pointé des risques réels. Un commentaire très partagé résumait tout :

Le ton provoque. Le fond compte.

Sécurité : surface d’attaque élargie

Avec le function calling, l’agent appelle des fonctions que vous avez écrites, testées, validées. Le périmètre d’action est défini à l’avance. Avec l’eval code, le LLM génère du code que vous n’avez jamais vu. Les risques sont concrets :

• Injection de code malveillant : un utilisateur manipule le prompt, l’agent génère du code destructeur
• Accès non autorisé : le code tente d’atteindre des ressources système (fichiers, réseau, bases) hors périmètre
• Exfiltration de données : prix fournisseurs, marges, données clients expédiés vers un endpoint externe

La réponse : sandboxing

La solution technique est le sandboxing : exécuter le code généré dans un conteneur isolé, permissions strictes. Bonnes pratiques identifiées par la communauté :

• Conteneur éphémère : chaque exécution tourne dans un conteneur détruit après usage
• Permissions minimales : lecture seule sur les données produits, aucun accès réseau sortant
• Timeout strict : 5 secondes maximum pour bloquer les boucles infinies
• Validation de l’output : le résultat du code est validé (type, taille, format) avant renvoi au LLM
• Allowlist d’imports : seuls les modules autorisés (pandas, json, math) peuvent être importés

Fiabilité : le LLM peut se tromper

Un LLM génère du code qui semble correct mais contient des erreurs subtiles. Un calcul de remise avec arrondi incorrect, un filtre qui exclut des produits valides, une requête qui ignore les précommandes. En function calling, les fonctions sont testées individuellement. En eval code, chaque exécution est potentiellement unique.

La mitigation : des tests de validation automatiques sur l’output du code. Si le résultat d’une recommandation produit est vide alors que le catalogue contient 2 000 références, le système bascule sur une logique déterministe.

Observabilité : déboguer l’imprévisible

Un avantage du function calling : chaque appel est tracé, loggé, reproductible. Avec l’eval code, le code généré diffère à chaque exécution. Déboguer un problème signalé par un client revient à chercher du code qui n’existe plus. La solution : logger systématiquement le code généré, ses entrées, ses sorties, son temps d’exécution.

Sur r/ArtificialIntelligence, un post avec 532 upvotes et 419 commentaires alertait sur les risques des agents IA autonomes en général : « AI agents today are far more dangerous than you think. » Ce message de prudence concerne directement l’eval code en production e-commerce.

Que signifie « construire des apps pour un monde qui change » ?

Pendant que la communauté débat du function calling, un autre thread Reddit explose sur r/vibecoding : 234 upvotes, 521 commentaires. La question posée frontalement : « We’re building apps for a world that’s about to stop using them. »

Les interfaces classiques du e-commerce — pages catégorie, filtres à facettes, fiches produit, panier — sont conçues pour des humains qui naviguent. Quand un agent IA s’intercale entre le consommateur et le catalogue, ces interfaces deviennent secondaires. L’agent dialogue directement avec la donnée, pas avec la mise en page.

L’interface invisible : quand l’agent remplace le navigateur

Un agent IA en eval code interroge votre catalogue d’une manière radicalement différente d’un visiteur humain :

• Il interroge votre API REST ou votre flux de données structurées (Schema.org, flux Google Merchant)
• Il écrit ses propres requêtes de filtrage et d’agrégation — il compose la logique métier au lieu de subir les filtres que vous avez prévus
• Il synthétise avis, spécifications et conditions de vente en une seule réponse pour l’utilisateur

L’investissement dans le design de pages produit, aussi crucial soit-il pour le trafic humain, se double désormais d’un investissement dans la couche data. Les deux comptent. Les e-commerçants qui exposent des données structurées riches, des API bien documentées et des flux produit complets sont ceux que les agents recommandent.

Le parallèle avec le SEO : du visible à l’exploitable

L’histoire se répète. En 2010, les e-commerçants qui pensaient « mon site est beau, donc il va ranker » ont été dépassés par ceux qui maîtrisaient la technique SEO : balisage sémantique, maillage interne, performance. En 2026, même basculement : les sites structurés pour les agents prennent l’avantage sur les sites conçus seulement pour les yeux.

Le post r/vibecoding a généré 521 commentaires — le double du thread sur Manus. La question touche un nerf : une partie significative de la communauté technique réalise que l’architecture logicielle va être redessinée autour de l’interaction avec les agents, et que ce shift est déjà en cours.

How can you apply these lessons to your e-commerce stack?

Le passage de function calling à code eval change la donne pour tout e-commerçant qui intègre — ou prévoit d’intégrer — des agents IA dans son parcours client. Cinq actions concrètes.

L’approche hybride : la stratégie recommandée

Le débat sur Reddit n’est pas binaire. La réalité en e-commerce production, c’est un spectre :

• Opérations critiques (paiement, stock, données client) : function calling avec validation stricte
• Opérations exploratoires (recherche, recommandation, comparaison) : eval code en sandbox
• Opérations analytiques (reporting, tendances, segmentation) : eval code batch, hors temps réel

Cette segmentation exploite la flexibilité d’eval code là où elle crée de la valeur. Elle maintient le contrôle là où la sécurité l’exige.

Ce que ça change pour votre stratégie digitale

Le virage du lead de Manus est un signal fort : les agents IA gagnent en autonomie. Ils génèrent leur propre logique d’interaction avec votre catalogue. Les e-commerçants qui se préparent prennent un avantage structurel : leurs données sont exploitées en profondeur, leurs produits recommandés en priorité, leur catalogue devient la référence que les agents consultent en premier.

Function calling a dominé 3 ans. Eval code ouvre un nouveau chapitre. Pour l’e-commerce, la leçon reste la même qu’en SEO : la meilleure stratégie consiste à rendre vos données si complètes et structurées que n’importe quel agent, quel que soit son fonctionnement interne, trouve ce qu’il cherche chez vous en premier.