Les services web

Jusqu’ici, l’agent ne sait que ce que disent ses prompts, plus ce que l’action de démarrage de la leçon 14 lui apporte. Pour chercher une réparation, lire des créneaux ou enregistrer un message pendant l’appel, il lui faut des actions : des appels vers l’outil du client, déclarés une fois pour toutes. Cette leçon les déclare et les teste. Les trois suivantes les branchent sur le workflow.

Un service, des actions

• Le service web, c’est l’outil du client vu par Manivox : une « URL de base » et une façon de s’identifier. On le déclare une fois par compte.
• Une action, c’est une opération précise sur ce service : lire une fiche, créer une ligne. Chaque action a une méthode, un chemin, des paramètres et, si besoin, un « Mapping de réponse » vers des variables.
• Les services se déclarent dans le compte, pas dans l’éditeur : « Comptes » → votre compte de formation → onglet « Connexions » → section « Services Web ». Tous les agents du compte peuvent ensuite s’en servir.
• Déclarer une action ne fait rien tout seul. Elle sert quand un nœud Agent la reçoit comme outil (leçon 16), quand un nœud « Appel API » l’appelle (leçon 17), ou en fin d’appel (leçon 18).

Échauffement : les jours fériés

Premier service, sans clé ni compte : l’API publique des jours fériés.

1. « Comptes » → votre compte de formation → onglet « Connexions ». Dans « Services Web », cliquez sur « Service web ». La fenêtre « Nouveau service web » s’ouvre.
2. « Nom » : Jours fériés. « URL de base » : https://calendrier.api.gouv.fr. « Type d’authentification » : « Sans authentification ». Cliquez sur « Créer ».
3. Sur la carte du service, cliquez sur « Actions (0) », puis « Ajouter une action ».
4. « Nom de l’action » : Jours fériés de l'année. « Méthode » : GET. « Chemin » : /jours-feries/metropole/2026.json (mettez l’année en cours). « Description » : Liste les jours fériés de l'année en France métropolitaine.
5. Cliquez sur « Enregistrer les actions ».
6. Dans l’en-tête de l’action, cliquez sur le petit bouton lecture (« Tester l’action »), puis « Lancer le test ».

La « Réponse » liste les dates, du 1er janvier au 25 décembre, avec le « Statut » 200. Vous venez de déclarer et de tester une action. Gardez ce service ou supprimez-le : la suite n’en a pas besoin.

Déclarez le service de votre scénario

Votre scénario garde ses données dans la base Baserow de la leçon 14, avec le même jeton. Commencez par y importer les deux autres fichiers de votre scénario, exactement comme à la leçon 14 (une table par fichier CSV, première ligne = en-têtes, colonnes en texte).

Puis, dans Manivox :

1. Dans « Services Web », cliquez sur « Service web ».
2. « Nom » : celui de votre scénario, ci-dessous. « URL de base » : https://api.baserow.io/api/database/rows/table
3. « Type d’authentification » : « Paramètres personnalisés ». Sous « Paramètres d’authentification », remplissez une ligne :
   • « Nom du paramètre » : Authorization · « Valeur » : Token VOTRE_JETON · emplacement : « En-tête ».
4. « Ajouter un paramètre », deuxième ligne :
   • « Nom du paramètre » : user_field_names · « Valeur » : true · emplacement : « Query ».
5. « Créer ».

La première ligne vous identifie : Baserow attend le mot Token, un espace, puis votre jeton. La seconde est envoyée avec chaque requête du service et demande à Baserow de parler avec les noms de colonnes (statut, nom) plutôt qu’avec des numéros internes.

Notez l’identifiant de chaque table

Chaque action vise une table, par son identifiant : le nombre qui suit table/ dans l’adresse de la table ouverte, comme à la leçon 14. Dans les chemins ci-dessous, remplacez ID_… par ce nombre et gardez la barre oblique finale : /612345/, pas /612345.

Les actions de lecture

Sur la carte de votre service, « Actions (0) », puis « Ajouter une action ». Les champs « Conserver la réponse complète » et « Mapping de réponse » sont sous « Avancé ».

search est le nom que Baserow attend : il cherche le texte dans toutes les colonnes. Baserow répond par une liste results ; $.results[0].statut veut dire « le champ statut de la première ligne trouvée ». Si rien n’est trouvé, la variable reste vide.

Les actions d’écriture

Le « Nom du paramètre » doit être exactement le nom de la colonne Baserow. En écriture, Baserow renvoie la ligne créée, avec son numéro id : le mapper dans une variable vous donnera une preuve que l’écriture a eu lieu.

Cliquez sur « Enregistrer les actions ».

Testez chaque action

1. Sur la carte du service, vérifiez que vos actions sont enregistrées : le test utilise la version enregistrée.
2. Bouton lecture de l’action (« Tester l’action »). Un champ apparaît par paramètre.
3. Remplissez-les avec une valeur de vos données d’exercice, puis « Lancer le test ».
4. Lisez le résultat : le « Statut » (200 ou 201 : réussi), la « Requête envoyée » et la « Réponse ».

Supprimez ensuite dans Baserow les lignes créées par vos tests.

Ce que l’IA verra de vos actions

Quand une action devient un outil d’un nœud Agent (leçon 16), le modèle de langage ne voit ni le chemin ni la méthode. Il voit :

• la « Description » de l’action : c’est elle qui lui dit quand s’en servir. Écrivez-la comme une consigne ;
• chaque paramètre, avec son type, sa description et s’il est requis : c’est ce qu’il doit obtenir de l’appelant ;
• après l’appel, la réponse : seulement les champs mappés quand « Conserver la réponse complète » est désactivé, la réponse entière sinon. Une longue réponse brute noie l’agent : mappez ce qui sert.

Vérifiez

Point d’étape

Le canevas n’a pas changé : vos actions attendent dans « Connexions », testées. Les leçons 16 et 17 les branchent sur l’agent.