Todou AI
ENConnexionCommencer
Navigation
CGUConfidentialitéMentions légalesEN · English
info@todoustudio.com+225 07 05 13 27 64
ConnexionCommencer
← Tous les exemples

Tool calling

Consulter une commande avec une fonction exécutée par votre application. JavaScript · Node.js 22+. Modèle : todou-fast.

Entrée fictive

Où en est ma commande ORD-1001 ?

Résultat illustratif · préenregistré

La commande ORD-1001 est expédiée. La livraison est estimée au 12 octobre 2026.
Lire le guideGuide dans la documentationCréer un compteOuvrir le playground authentifié

Dossier autonome : examples/todou-tool-calling-js. Les liens publics seront disponibles après publication.

npm run demo
Copier

Du choix de l’outil à la réponse

Séquence fictive préenregistrée : votre serveur exécute la fonction, puis transmet son résultat à Todou.

  1. 1. Le modèle propose un outil

    get_order_status({"order_id":"ORD-1001"})

  2. 2. Le serveur valide et consulte les données fictives

    {"order_id":"ORD-1001","found":true,"status":"expédiée","estimated_delivery":"2026-10-12"}

  3. 3. Le serveur renvoie le résultat au modèle

    {"role":"tool","tool_call_id":"call_demo_1","content":"…résultat JSON…"}

  4. 4. Le modèle formule la réponse

    La commande ORD-1001 est expédiée. La livraison est estimée au 12 octobre 2026.

Guide d’intégration

Ce que vous construisez

Un assistant JavaScript en ligne de commande qui demande à l’application de consulter une commande. Todou propose un appel `get_order_status` ; votre code valide et exécute la fonction, puis renvoie son résultat au modèle pour obtenir une réponse lisible. Les commandes de `orders.json` sont fictives. Aucune action métier n’est exécutée.

Prérequis

Node.js 22 ou supérieur. Aucune dépendance npm, aucun SDK supplémentaire. Modèle proposé : `todou-fast`. Vérifiez avec `GET /v1/models` que le modèle actif annonce la capacité `tools`. Les identifiants et le mécanisme sont ceux du backend existant, pas un endpoint ajouté pour cet exemple.

Compte et clé

Créez votre compte sur https://console.todou.dev/signup, puis un projet et une clé sur `/app/api-keys`. La clé reste dans le processus Node.js côté serveur. Les pages publiques ne demandent aucune clé et n’appellent pas l’API.

Installation et démonstration sans frais

Depuis ce dossier :

npm run demo
npm test
Copier

`demo` utilise exclusivement `demo.json` : son message et ses deux réponses sont préenregistrés et explicitement annoncés comme MOCK. Aucune requête réseau, aucun compte, aucune clé API et aucune consommation réelle ne sont nécessaires. L’exécution de la fonction sur `orders.json` et la validation sont bien réalisées.

Variables d’environnement et lancement réel

cp .env.example .env
# Renseignez .env avant la commande suivante :
npm start -- "Où en est ma commande ORD-1001 ?"
Copier

`TODOU_API_BASE_URL` inclut `/v1` : http://127.0.0.1:8000/v1 pour votre backend local, ou https://api.todou.dev/v1 pour l’API déployée. `TODOU_API_KEY` est votre clé privée, `TODOU_MODEL` vaut `todou-fast` par défaut. Ne commitez jamais `.env`. La commande `start` effectue jusqu’à deux appels réels potentiellement facturables.

Les quatre étapes de l’appel API

1. L’application envoie `POST /v1/chat/completions` avec `tools`, la définition JSON de `get_order_status`, et `tool_choice` qui sélectionne cette fonction. 2. Le modèle répond avec `choices[0].message.tool_calls`. `function.arguments` est une chaîne JSON non fiable : le serveur valide le nom et les arguments. 3. Le serveur consulte le fichier fictif et ajoute au dialogue le message assistant avec ses `tool_calls`, puis un message `role: tool`. Son `tool_call_id` reprend exactement l’identifiant de l’appel reçu ; `content` contient le résultat JSON. 4. Un second appel avec `tool_choice: none` demande la réponse finale. Le serveur refuse toute nouvelle demande d’outil et ne boucle pas.

{
  "role": "tool",
  "tool_call_id": "call_demo_1",
  "content": "{\"order_id\":\"ORD-1001\",\"found\":true,\"status\":\"expédiée\",\"estimated_delivery\":\"2026-10-12\"}"
}
Copier

Le résultat d’un outil ne vient pas du modèle : il vient du code de votre application. L’exemple utilise `stream: false` pour valider les appels complets avant exécution.

Entrée et résultat illustratifs

Question : « Où en est ma commande ORD-1001 ? » Résultat de fonction : statut `expédiée`, date estimée `2026-10-12`. Réponse illustrative : « La commande ORD-1001 est expédiée. La livraison est estimée au 12 octobre 2026. » Cette phrase est préenregistrée dans le mode mock. Pour ORD-1002, la date est inconnue (`null`). Pour ORD-9999, `found` vaut `false`. Le modèle doit expliquer qu’une information est indisponible, sans l’inventer.

Personnalisation et protections

Modifiez `orders.json` pour vos essais fictifs. Pour ajouter un outil, définissez explicitement son schéma, son validateur et sa fonction : aucun `eval`, commande shell, accès fichier dynamique ou URL fournie par le modèle ne doit être exécuté. La version fournie n’autorise que `get_order_status`, avec un seul champ `order_id` au format ORD-1234. Cette référence doit aussi figurer sans ambiguïté dans la question. Ce contrôle ne constitue pas une autorisation sur des données réelles : si vous raccordez votre backend métier, identifiez l’utilisateur et vérifiez côté serveur que la commande lui appartient avant de la consulter.

Limites par exécution : question de 1 000 caractères, un outil, un appel d’outil, deux appels API maximum, 256 tokens maximum par réponse, timeout de 15 secondes par requête, réponse réseau limitée à 64 Ko. Aucun retry automatique. Les messages ne peuvent pas ajouter d’outil. Les arguments supplémentaires, outils inconnus et appels multiples sont rejetés. La réponse finale reste générée par un modèle : elle peut être inexacte ; le résultat brut de l’outil est affiché à côté pour vérification. La sortie CLI est encodée en JSON, sans interprétation HTML ou shell. Aucune démonstration interactive publique ni plafond de dépense global n’est fourni.

Consommation

`usage_per_call` contient séparément la consommation des deux réponses (ou `null` si absente). Le mode mock affiche des zéros fictifs, pas une mesure de performance. Consultez aussi `/app/usage` et `/app/billing` dans la console. Calcul, à additionner pour les deux appels : `tokens_entrée / 1 000 000 × prix_entrée + tokens_sortie / 1 000 000 × prix_sortie`. Le second appel renvoie l’historique, le schéma et le résultat d’outil : ils contribuent aux tokens d’entrée. Contrat vérifié le 9 septembre 2026, modèle `todou-fast`, deux appels au maximum, sans relance. Vérifiez les tarifs effectifs dans la console ; aucun montant n’est inventé. Un timeout ne garantit pas l’annulation de la facturation.

Erreurs fréquentes et vérifications

401 : clé invalide ; 402 : crédit insuffisant ; 404 : modèle indisponible ; 422 : requête ou capacité tools refusée ; 429 : limite atteinte ; 502/503 : service ou fournisseur indisponible. Une réponse tronquée, des arguments invalides ou un nouvel appel d’outil après la restitution du résultat interrompent l’exécution. Une question sans référence ou avec plusieurs références est refusée avant tout appel. Le processus termine avec le code 1 en cas d’erreur ; code 0 en cas de succès. `npm test` vérifie le cycle avec des mocks, les refus et les erreurs. Il ne prouve pas le comportement d’un modèle déployé. Aucun test facturable n’est lancé automatiquement.

Publication et licence

Ce dossier est autonome. Aucun dépôt public n’est créé automatiquement et aucune licence applicable aux exemples n’est explicitement définie : choisir la licence avant publication. Le lien source du site reste masqué jusqu’au renseignement de `NEXT_PUBLIC_EXAMPLE_TOOLS_CODE_URL` lors de la compilation du frontend.