L’ex-lead de Manus a abandonné le function calling — ce que ça change pour le e-commerce
Pourquoi un expert des agents IA a-t-il abandonné le function calling ?
Le 12 mars 2026, le backend lead de Manus — l’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 passés à construire des agents avec le function calling, il a expliqué pourquoi il avait abandonné cette approche. Résultat : 1 927 upvotes et 409 commentaires en quelques jours.
Pour comprendre la portée de ce virage, il faut saisir 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
Le constat du développeur est précis : 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 manière 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 nécessiter 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 opérateur de standard téléphonique dans un monde qui demande un développeur.
Comment fonctionne l’alternative : le code eval ?
L’alternative proposée par le lead de Manus est radicale dans sa simplicité : au lieu de définir un catalogue de fonctions, on laisse le LLM générer du code qui est exécuté directement. Le modèle écrit du Python (ou du JavaScript), le code tourne dans un environnement contrôlé, et 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 :
search_products(query= »manteau imperméable », category= »homme »)
filter_results(min_rating=4.0, max_price=150)
sort_results(field= »price », order= »asc »)
Avec le code eval, le LLM écrit directement :
results = db.query(« SELECT * FROM products
WHERE category = ‘homme’
AND description LIKE ‘%imperméable%’
AND rating >= 4.0
AND price <= 150
ORDER BY price ASC »)
Un seul bloc de code remplace trois appels de fonction. Le LLM compose librement sa logique au lieu de la découper en appels atomiques.
La validation de la communauté
La réaction sur r/LocalLLaMA a été immédiate et massive. Le commentaire le plus upvoté (211 upvotes) rapportait une expérience convergente :
Un autre commentaire très populaire allait plus loin :
L’idée est puissante : les LLM sont déjà des générateurs de code performants. Leur demander de générer du code exécutable est plus naturel que de leur demander de choisir dans un menu de fonctions prédéfinies. C’est utiliser leur force première : la génération de texte structuré.
Pourquoi ça fonctionne : la théorie derrière le code eval
Le function calling force le LLM à opérer dans un espace d’actions discret : il choisit parmi N fonctions. Le code eval lui ouvre un espace d’actions continu : il compose librement des instructions. La différence est fondamentale. Un agent avec 50 fonctions prédéfinies peut réaliser 50 actions. Un agent avec un interpréteur Python peut réaliser une infinité de combinaisons.
En pratique, cela signifie qu’un agent e-commerce en code eval peut :
- Combiner des filtres que le développeur n’avait pas prévus : « Tous les manteaux avec un rapport avis/prix supérieur à la médiane de la 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 du function calling au code eval a des implications directes sur la qualité de l’expérience agent et sur la vitesse de développement.
1. Des recommandations produit radicalement plus fines
Un agent en function calling recommande un produit parce qu’il correspond à des critères prédéfinis (catégorie, prix, note). Un agent en code eval peut composer des logiques de recommandation sophistiquées en temps réel : pondérer la note par la récence des avis, croiser la disponibilité avec le délai de livraison, et intégrer 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 de fonction séquentiels pour un parcours de recommandation complet, l’agent génère un seul bloc de code qui exécute l’ensemble de la logique. La latence perçue par l’utilisateur diminue significativement. 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. Un coût de maintenance réduit
Le function calling exige de maintenir un catalogue de fonctions documentées, testées et versionnées. Chaque nouvelle fonctionnalité — un nouveau filtre, un nouveau critère de tri, une nouvelle règle promo — implique du code côté serveur. Avec le code eval, le LLM s’adapte au contexte disponible. Il suffit de lui exposer les données et une API de base ; il compose le reste.
4. Une adaptation instantanée aux demandes imprévues
Le cas typique : un client demande « Compare ces 3 produits en tenant compte des retours gratuits et de l’éco-responsabilité des matériaux ». Avec le function calling, cette requête échoue si aucune fonction compare_products_with_return_policy_and_sustainability n’existe. Avec le code eval, 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 ?
Le débat sur r/LocalLLaMA a été vif, et la communauté a identifié des risques réels. L’un des commentaires les plus partagés était direct :
Le ton est provocateur, mais le fond est pertinent. Laisser un LLM générer et exécuter du code en production soulève des questions sérieuses.
La sécurité : surface d’attaque élargie
Avec le function calling, l’agent appelle des fonctions que vous avez écrites, testées et validées. Le périmètre d’action est défini à l’avance. Avec le code eval, le LLM peut générer du code que vous n’avez jamais vu. Les risques sont concrets :
- Injection de code malveillant : un utilisateur qui manipule le prompt peut amener le LLM à générer du code destructeur
- Accès non autorisé : un code généré pourrait tenter d’accéder à des ressources système (fichiers, réseau, bases de données) hors périmètre
- Exfiltration de données : le code pourrait envoyer des données sensibles (prix fournisseur, marges, données client) vers un endpoint externe
La réponse : le sandboxing
La solution technique est le sandboxing : exécuter le code généré dans un conteneur isolé avec des permissions strictes. Les 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 : accès en lecture seule aux données produit, aucun accès réseau sortant
- Timeout strict : 5 secondes maximum d’exécution pour bloquer les boucles infinies
- Validation de l’output : le résultat du code est validé (type, taille, format) avant d’être renvoyé au LLM
- Allowlist d’imports : seuls les modules autorisés (pandas, json, math) peuvent être importés
La 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 un arrondi incorrect, un filtre qui exclut des produits valides, une requête qui ignore les produits en précommande. En function calling, les fonctions sont testées unitairement. En code eval, 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 déclenche un fallback vers une logique déterministe.
L’observabilité : déboguer l’imprévisible
Un avantage du function calling : chaque appel est tracé, logué, reproductible. Avec le code eval, le code généré est différent à chaque exécution. Déboguer un problème rapporté par un client revient à chercher un code qui n’existe plus. La solution : logger systématiquement le code généré, ses inputs, ses outputs et sa durée 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 le code eval en production e-commerce.
Que signifie « construire des apps pour un monde qui change » ?
Parallèlement au débat sur le function calling, un autre fil Reddit a frappé la communauté e-commerce. Sur r/vibecoding, un post avec 234 upvotes et 521 commentaires posait la question frontalement : « We’re building apps for a world that’s about to stop using them. »
L’idée est que 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’interpose entre le consommateur et le catalogue, ces interfaces deviennent secondaires. L’agent interagit directement avec les données, pas avec la mise en page.
L’interface invisible : quand l’agent remplace le navigateur
Un agent IA en code eval interagit avec 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, Google Merchant Feed)
- 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 les avis, les spécifications et les conditions de vente en une réponse unique pour l’utilisateur
Cela signifie que l’investissement dans le design de pages produit, aussi important soit-il pour le trafic humain, est complété par un investissement dans la couche données. Les deux sont nécessaires. 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 rankera bien » ont été dépassés par ceux qui comprenaient la technique SEO : balisage sémantique, maillage interne, performance. En 2026, le même décalage se produit : les sites structurés pour les agents prennent l’avantage sur les sites conçus uniquement pour les yeux.
Le post r/vibecoding a généré 521 commentaires — le double du fil sur Manus. La question touche un nerf : une partie significative de la communauté technique réalise que l’architecture logicielle va être repensée autour de l’interaction agent, et que ce virage est déjà en cours.
Comment appliquer ces leçons à votre stack e-commerce ?
Le virage function calling vers code eval a des leçons directes pour tout e-commerçant qui intègre ou prévoit d’intégrer des agents IA dans son parcours client. Voici les 5 actions concrètes.
Un agent en code eval compose ses propres requêtes. Plus vos données sont complètes et structurées (Schema.org Product, Offer, AggregateRating), plus l’agent peut construire des recommandations pertinentes. Chaque attribut manquant est un critère de comparaison perdu face à un concurrent qui le fournit.
Si vous disposez d’une API REST (WooCommerce, Shopify, PrestaShop), documentez-la clairement dans votre fichier llms.txt. Indiquez les endpoints, les formats de réponse et les paramètres de filtrage. Un agent qui comprend votre API peut écrire du code optimal pour interroger votre catalogue.
Adoptez une approche hybride : function calling pour les opérations critiques (paiement, modification de commande, gestion de stock) et code eval pour les opérations exploratoires (recherche, comparaison, recommandation). Les transactions financières restent dans un périmètre contrôlé.
Les agents en code eval exploitent les flux de données (Google Merchant Center, Meta Product Feed) comme source primaire. Enrichissez vos flux avec tous les attributs disponibles : matière, certifications, délai de livraison, politique de retour, taille normalisée. Un flux complet est le meilleur investissement pour la visibilité agentique.
Les agents IA laissent des traces : user-agent spécifique (GPTBot, ClaudeBot, PerplexityBot), patterns de requêtes caractéristiques, séquences d’accès rapides. Mettez en place un monitoring dédié pour comprendre comment les agents utilisent votre catalogue : quelles pages, quelles données, quelle fréquence.
L’approche hybride : la stratégie recommandée
Le débat sur Reddit n’est pas un choix binaire. La réalité en production e-commerce est un spectre :
- Opérations critiques (paiement, stock, données client) : function calling avec validation stricte
- Opérations exploratoires (recherche, recommandation, comparaison) : code eval avec sandbox
- Opérations analytiques (reporting, tendances, segmentation) : code eval en batch, hors temps réel
Cette segmentation permet de profiter de la flexibilité du code eval là où elle crée de la valeur, tout en maintenant le contrôle là où la sécurité l’exige.
Ce que ça signifie pour votre stratégie digitale
Le virage du lead de Manus est un signal fort : les agents IA évoluent vers plus d’autonomie. Ils sont capables de générer leur propre logique d’interaction avec votre catalogue. Les e-commerçants qui se préparent gagnent un avantage structurel : leurs données sont exploitées en profondeur, leurs produits sont recommandés en priorité, leur catalogue devient la référence que les agents consultent.
Le function calling a dominé la construction d’agents pendant 3 ans. Le code eval ouvre un nouveau chapitre. Pour le e-commerce, la leçon est la même qu’en SEO : la meilleure stratégie est de rendre vos données tellement complètes et structurées que tout agent, quel que soit son fonctionnement interne, trouve ce qu’il cherche chez vous en premier.
Préparez votre catalogue pour les agents IA
Audit gratuit de votre stack e-commerce : données structurées, flux produit, API, visibilité agentique. Résultats en 48 h.
Réserver un audit gratuitQuestions fréquentes
Qu’est-ce que le function calling en IA ?
Le function calling est un mécanisme où un modèle de langage (LLM) génère un appel structuré à une fonction prédéfinie avec des paramètres typés. L’agent dispose d’un catalogue de fonctions disponibles et choisit laquelle appeler selon le contexte. C’est le mode dominant de construction d’agents IA depuis 2023.
Qu’est-ce que le code eval comme alternative ?
Le code eval consiste à laisser le LLM générer directement du code exécutable (Python, JavaScript) au lieu d’appeler des fonctions prédéfinies. Le code est ensuite exécuté dans un environnement contrôlé (sandbox). Cette approche offre plus de flexibilité car l’agent compose librement ses actions.
Le code eval est-il plus risqué que le function calling ?
Le code eval introduit une surface d’attaque plus large : le LLM peut potentiellement générer du code malveillant ou inattendu. Le sandboxing (conteneurs isolés, permissions restreintes) est indispensable. En production e-commerce, des couches de validation supplémentaires permettent de contrôler chaque exécution.
Comment cette évolution impacte-t-elle le SEO e-commerce ?
Les agents IA deviennent plus autonomes dans leur façon d’interagir avec les catalogues. Un agent en code eval peut écrire ses propres requêtes de filtrage et d’agrégation. Les sites avec des données structurées complètes (Schema.org, API REST, flux produit) sont mieux exploités par ces agents.
Faut-il reconstruire ses agents e-commerce avec du code eval ?
L’approche hybride est recommandée : conserver le function calling pour les opérations critiques (paiement, gestion de stock) et utiliser le code eval pour les tâches exploratoires (comparaison de produits, analyse de tendances). Le choix dépend du niveau de contrôle requis par chaque opération.
Que signifie « construire des apps pour un monde qui change » en e-commerce ?
Un post sur r/vibecoding (234 upvotes) alertait : les interfaces classiques (pages catégorie, filtres à facettes, paniers) pourraient être contournées par des agents IA qui interagissent directement avec les données. Les e-commerçants gagnent à exposer leurs données via des API et des formats structurés, en complément de l’interface visuelle.
