Peux-tu signaler ce vélo endommagé ?

Du langage naturel à l’action contrôlée : sorties structurées, outils et modèles spécialisés

Introduction — Expliquer n’est pas agir

Stéphane : Le vélo VL-2048 est encore affiché comme disponible, mais sa roue arrière est bloquée. Peux-tu le signaler ?
Assistant Bikaroo : Je peux préparer le signalement. Pour modifier réellement l’état du vélo, l’application doit toutefois utiliser une capacité du système de flotte.

Les chapitres précédents ont progressivement enrichi l’assistant Bikaroo. Le LLM peut formuler une réponse, la recherche sémantique peut retrouver une procédure et le RAG peut insérer cette procédure dans son contexte.

Au chapitre 2, l’Assistant Bikaroo pouvait déjà observer une photographie et décrire les dommages visibles sur un vélo. Nous franchissons maintenant une étape supplémentaire : transformer une observation ou une demande en signalement contrôlé dans le système de flotte.

Une limite demeure pourtant : une phrase ne modifie aucun système.

Le modèle peut écrire :

response
Le vélo VL-2048 doit être marqué comme indisponible.

Mais tant qu’un composant externe n’a pas effectué l’opération dans le système de flotte, le vélo reste disponible.

Pour traiter correctement la demande de Stéphane, la solution doit :

• comprendre son intention ;
• identifier sans ambiguïté le vélo concerné ;
• choisir une capacité autorisée ;
• produire des paramètres structurés ;
• valider ces paramètres et les droits de l’utilisateur ;
• demander une confirmation lorsque le risque l’exige ;
• exécuter l’opération dans le système métier ;
• rapporter honnêtement le résultat ou l’échec.

Ce chapitre explique cette chaîne complète. Il montre aussi comment une application peut appeler des modèles spécialisés afin de produire une image, un fichier audio ou un document, sans confondre le LLM conversationnel avec le composant qui crée réellement l’artefact. Le fil directeur reste cependant le même : transformer une demande en capacité contrôlée, sans confier au modèle les responsabilités de validation, d’autorisation ou d’exécution métier.

Ce que vous allez apprendre

À la fin de ce chapitre, vous pourrez :

• distinguer une réponse textuelle, une consultation et une action réelle ;
• expliquer la différence entre sortie structurée, appel d’outil et API ;
• concevoir le cycle de sélection, validation, exécution et réinjection d’un résultat ;
• adapter confirmations, autorisations, idempotence et gestion des erreurs au niveau de risque ;
• positionner les modèles spécialisés et les artefacts qu’ils produisent dans l’architecture.

Distinguer réponse, consultation et action

Trois niveaux de capacité

Une application fondée sur un LLM peut offrir trois niveaux très différents.

Répondre

Question
→ LLM
→ texte généré

Exemple :

prompt
Que prévoit la procédure lorsqu’un vélo est endommagé ?

Le LLM peut répondre à partir d’une procédure fournie par RAG. Aucun système opérationnel n’est consulté ou modifié.

Consulter

Question
→ outil de lecture
→ système métier
→ résultat actuel
→ réponse

Exemple :

prompt
Quel est le statut actuel du vélo VL-2048 ?

L’application doit lire le système de flotte, qui reste la source de vérité.

Agir

Demande
→ outil d’écriture
→ validation et autorisation
→ système métier
→ modification réelle
→ résultat

Exemple :

prompt
Signale le vélo VL-2048 comme endommagé.

Cette fois, la solution modifie l’état du monde. Le niveau de contrôle doit donc être plus élevé.

Répartition des responsabilités

Le LLM

Le LLM travaille sur le langage : il interprète la demande, identifie l’intention, choisit une capacité parmi celles qu’on lui présente, propose des arguments structurés, réclame les informations manquantes, puis interprète et explique le résultat.

L’application ou l’orchestrateur

L’application, elle, garde le contrôle : c’est elle qui décide quels outils sont exposés, vérifie leur disponibilité, valide les arguments, résout les identifiants, applique l’authentification, l’autorisation et les règles de risque, demande une confirmation, exécute ou refuse l’appel, gère les erreurs et les reprises, journalise l’opération, et ne réinjecte dans le contexte qu’un résultat contrôlé.

Le partage n’est pas un détail d’implémentation : c’est la frontière de sécurité. Le modèle propose, l’application dispose.

Le système métier

Le système métier conserve :

• l’état de référence ;
• les règles transactionnelles ;
• les contraintes d’intégrité ;
• les autorisations métier ;
• la trace opérationnelle définitive.

Chez Bikaroo, il peut s’agir du système de flotte, du CRM, du système de ticketing ou de la plateforme de paiement.

De la phrase libre à une demande structurée

Pourquoi une structure est nécessaire

Un programme ne peut pas exécuter de manière fiable une formulation libre comme :

prompt
Je pense qu’il faudrait probablement rendre indisponible le vélo signalé par Stéphane.

Il lui faut une intention explicite et des paramètres identifiables :

{
  "tool": "report_damaged_bike",
  "arguments": {
    "bikeId": "VL-2048",
    "issue": "rear_wheel_blocked"
  }
}

Sortie structurée et appel d’outil

Une sortie structurée impose ou encourage un format exploitable par un programme, par exemple un objet JSON conforme à un schéma.

Un appel d’outil (tool calling) utilise cette capacité pour exprimer :

quel outil utiliser
+
avec quels arguments

Le modèle pourrait produire un objet parfaitement conforme comme :

{
  "tool": "report_damaged_bike",
  "arguments": {
    "bikeId": "STEPHANE",
    "issue": "rear_wheel_blocked"
  }
}

La structure est valide, mais STEPHANE n’est pas un identifiant de vélo.

Le modèle génère une intention, pas une transaction

Même lorsqu’une API de modèle fournit un mécanisme natif de tool calling, le modèle n’exécute généralement pas lui-même l’opération métier.

LLM
→ produit une demande structurée

Application
→ vérifie et exécute éventuellement cette demande

Cette frontière permet à l’application de conserver le contrôle.

Définir un outil utilisable par le modèle

Anatomie d’un outil

Un outil, ou tool dans la terminologie des plateformes LLM, expose une capacité externe de manière compréhensible pour le modèle et contrôlable par l’application.

Un outil n’est pas seulement une fonction : c’est un contrat entre le modèle et un système. Il possède généralement :

• un nom stable ;
• une description métier ;
• un schéma d’entrée ;
• éventuellement un schéma de sortie ;
• une implémentation ;
• des règles d’autorisation ;
• une politique de confirmation ;
• des caractéristiques opérationnelles comme le timeout et l’idempotence.

Exemple conceptuel :

{
  "name": "report_damaged_bike",
  "description": "Signale un vélo Bikaroo endommagé et le rend indisponible après validation.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "bikeId": {
        "type": "string",
        "description": "Identifiant Bikaroo du vélo, par exemple VL-2048"
      },
      "issue": {
        "type": "string",
        "enum": [
          "rear_wheel_blocked",
          "flat_tire",
          "brake_failure",
          "other"
        ]
      },
      "comment": {
        "type": "string"
      }
    },
    "required": ["bikeId", "issue"]
  }
}

Une bonne description précise :

• quand utiliser l’outil ;
• ce qu’il fait réellement ;
• ses effets ;
• ce qu’il ne fait pas ;
• les informations obligatoires.

Outil, fonction et API

Ces termes décrivent des niveaux différents.

Function calling

Le terme historique function calling décrit la production d’une structure ressemblant à un appel de fonction :

report_damaged_bike(
  bikeId="VL-2048",
  issue="rear_wheel_blocked"
)

Appel d’outil (tool calling) L’appel d’outil est plus général. L’outil demandé peut encapsuler :

• une fonction locale ;
• une API distante ;
• une requête vers une base de données ;
• un workflow ;
• un moteur de recherche ;
• un autre modèle spécialisé ;
• une génération de document ou de média.

API

L’API est l’interface technique utilisée pour dialoguer avec le système réel :

POST /fleet/bikes/VL-2048/damage-reports

L’outil peut présenter une capacité métier claire :

report_damaged_bike

et masquer au modèle les détails techniques de plusieurs appels, transformations ou contrôles.

LLM
  ↓ demande d’outil
Application
  ↓ outil métier
API ou workflow
  ↓
Système de flotte

Exécuter un appel d’outil de bout en bout

Reprenons la demande de Stéphane :

prompt
Le vélo VL-2048 est encore affiché comme disponible, mais sa roue arrière est bloquée. Peux-tu le signaler ?

Comprendre la demande

Le modèle identifie conceptuellement :

intention = signaler un vélo endommagé
bikeId = VL-2048
problème = roue arrière bloquée
effet demandé = modifier le statut opérationnel

Il ne doit pas inventer un identifiant absent. Si Stéphane avait seulement écrit « ce vélo », l’application devrait exploiter un contexte fiable ou demander une précision.

Sélectionner l’outil

Parmi les capacités présentées au modèle figurent par exemple :

get_bike_status
report_damaged_bike
create_maintenance_ticket

Le modèle propose report_damaged_bike parce que la demande vise un signalement avec effet opérationnel.

Produire les arguments

{
  "bikeId": "VL-2048",
  "issue": "rear_wheel_blocked",
  "comment": "La roue arrière est bloquée."
}

Valider avant exécution

La conformité du schéma ne suffit pas : l’application vérifie sur trois plans. La forme — l’outil existe et est disponible, les arguments respectent le schéma. La réalité — VL-2048 existe vraiment et son statut permet ce signalement. Le droit — Stéphane est autorisé à demander l’opération, elle n’a pas déjà été exécutée, et une confirmation est requise ou non.

Elle peut d’abord effectuer une lecture déterministe :

get_bike_status("VL-2048")

et recevoir :

{
  "bikeId": "VL-2048",
  "status": "available",
  "lastUpdatedAt": "2026-07-01T14:22:00+02:00"
}

Demander une confirmation adaptée au risque

L’application peut présenter :

response
Je vais signaler le vélo VL-2048 pour roue arrière bloquée et le rendre indisponible. Confirmer ?

Exécuter l’opération

Après confirmation et contrôles, l’application appelle le service métier avec une clé d’idempotence :

{
  "bikeId": "VL-2048",
  "issue": "rear_wheel_blocked",
  "idempotencyKey": "damage-report-7f6b..."
}

Le service peut répondre :

{
  "reportId": "DR-95841",
  "bikeId": "VL-2048",
  "newStatus": "unavailable",
  "maintenanceTicketId": "MT-18420",
  "processedAt": "2026-07-01T14:24:18+02:00"
}

Réinjecter le résultat contrôlé

Le résultat utile est ajouté au contexte comme résultat d’outil, pas comme message utilisateur ni comme instruction souveraine.

TOOL RESULT
status = success
bikeId = VL-2048
newStatus = unavailable
reportId = DR-95841
maintenanceTicketId = MT-18420

Formuler une réponse honnête

Le modèle peut répondre :

response
Le vélo VL-2048 a été signalé pour roue arrière bloquée et marqué comme indisponible. Le signalement DR-95841 a créé le ticket de maintenance MT-18420.

Adapter les contrôles au niveau de risque

Outils de lecture et outils d’écriture

Tous les outils n’ont pas le même impact.

Lecture

Exemples :

Ils consultent une information sans modifier le système. Ils peuvent néanmoins exposer des données sensibles ou coûteuses et nécessitent donc toujours des contrôles d’accès.

get_bike_status
get_member_profile
search_orders
get_trip_details

Écriture réversible ou limitée

L’action modifie le système, mais peut parfois être annulée ou corrigée facilement.

Exemples :

create_maintenance_ticket
add_internal_comment
reserve_bike_temporarily

Écriture sensible ou critique

Ces actions peuvent avoir un impact opérationnel, financier, juridique ou sur un tiers.

Exemples :

mark_bike_unavailable
suspend_membership
issue_refund
cancel_contract

Une politique graduée

Une architecture robuste peut appliquer une politique comme :

lecture à faible risque
→ exécution automatique après autorisation

écriture limitée et réversible
→ confirmation contextuelle selon le cas

écriture sensible
→ confirmation explicite

écriture critique ou irréversible
→ approbation humaine ou workflow métier

ERREUR

La distinction ne doit pas reposer uniquement sur le verbe HTTP. Un POST peut être sans danger, tandis qu’un GET peut exposer des données très sensibles. Le niveau de risque doit être défini par l’effet métier.

Intervention humaine (human-in-the-loop)

Une intervention humaine peut être requise pour :

• confirmer l’intention ;
• vérifier une cible ambiguë ;
• approuver un montant ;
• arbitrer une règle contradictoire ;
• traiter une exception ;
• contrôler une action irréversible.

L’humain ne doit pas devenir une formalité aveugle. L’interface doit afficher clairement :

action
cible
paramètres importants
effet attendu
risques ou conséquences

Valider et sécuriser l’exécution

Plusieurs niveaux de validation

Une sortie structurée doit être contrôlée à plusieurs niveaux.

Syntaxe

Le résultat est-il lisible par le programme ?

Schéma

Les champs obligatoires sont-ils présents ?
Les types et valeurs énumérées sont-ils corrects ?

Référentiel

Le vélo VL-2048 existe-t-il ?
L’identifiant correspond-il bien à l’objet concerné ?

Règles métier

Le vélo peut-il être rendu indisponible ?
Un signalement similaire existe-t-il déjà ?
Le motif est-il accepté ?

Autorisation

L’utilisateur et l’application ont-ils le droit d’effectuer cette opération ?

Politique de risque

Le LLM peut aider à préparer des valeurs, mais les contrôles critiques doivent être déterministes ou portés par le système métier.

Une confirmation ou une approbation est-elle requise ?

Ne pas inventer les identifiants

Un identifiant opérationnel ne doit pas être déduit approximativement. Ceci ne constitue pas nécessairement un bikeId unique.

“le vélo près de Flagey”

La solution doit :

1. demander une précision ;
2. utiliser une donnée explicitement sélectionnée dans l’interface ;
3. appeler un outil de résolution ;
4. présenter les candidats à l’utilisateur.

Elle ne doit pas choisir silencieusement une cible plausible.

Prévenir les doubles exécutions

Une réponse réseau perdue peut conduire l’application à réessayer une opération déjà accomplie.

appel exécuté
→ réponse perdue
→ retry
→ risque de doublon

Une clé d’idempotence permet au service de reconnaître la même demande logique :

idempotencyKey = damage-report-7f6b...

Le service doit alors renvoyer le résultat initial ou refuser le doublon selon son contrat.

Gérer timeouts et retries

Après un timeout, l’application doit déterminer :

• si l’opération est sûre à rejouer ;
• si son statut peut être consulté ;
• si la clé d’idempotence sera reconnue ;
• si une intervention humaine est préférable.

Une politique de retry doit tenir compte :

• du type d’erreur ;
• du caractère transitoire ou permanent ;
• du nombre maximal de tentatives ;
• d’un délai progressif ;
• de la capacité du service à éviter les doublons.

Rapporter honnêtement l’état

La réponse finale doit distinguer :

succès confirmé
échec confirmé
statut incertain
opération en attente
refus d’autorisation

En cas de timeout ambigu, l’assistant ne doit répondre ni « c’est fait » ni « cela a échoué » sans preuve.

Il peut dire :

response
La demande a été envoyée, mais son résultat n’a pas pu être confirmé. Je n’effectue pas une nouvelle tentative automatique afin d’éviter un doublon.

Combiner RAG et outils

Une demande réelle peut nécessiter à la fois une connaissance documentaire et une donnée opérationnelle.

Pour signaler le vélo VL-2048, l’application peut avoir besoin de :

RAG
→ retrouver la procédure active de signalement

outil de lecture
→ vérifier le statut actuel du vélo

outil d’écriture
→ enregistrer le dommage et rendre le vélo indisponible

Exemple de séquence

1. Retrouver la procédure applicable en Belgique
2. Vérifier que VL-2048 existe et est encore disponible
3. Demander les informations manquantes
4. Présenter l’action et ses effets
5. Obtenir la confirmation requise
6. Exécuter report_damaged_bike
7. Vérifier le résultat
8. Répondre avec les références utiles

EN PRATIQUE

Il faut éviter de placer toute cette logique dans un prompt libre. Les règles stables, autorisations, validations et transitions critiques doivent être portées par l’application ou un workflow déterministe.

Produire autre chose que du texte

Des modèles spécialisés

Le LLM conversationnel n’est pas nécessairement le composant qui génère une image, une voix, une vidéo ou un document final.

Une application peut exposer des outils comme :

generate_damage_report_image
generate_voice_message
create_maintenance_pdf
render_incident_summary

Ces outils peuvent appeler :

• un modèle de génération d’images ;
• un modèle de synthèse vocale ;
• un moteur de génération vidéo ;
• un moteur de rendu PDF ;
• une bibliothèque de création de documents ;
• une chaîne de traitement spécialisée.

Le LLM peut préparer les instructions et les paramètres, tandis que le composant spécialisé produit l’artefact.

Le résultat est souvent une référence d’artefact

Un fichier binaire volumineux n’est généralement pas réinjecté intégralement dans le contexte textuel.

L’outil peut renvoyer :

{
  "artifactId": "AST-1842",
  "mimeType": "application/pdf",
  "fileName": "damage-report-VL-2048.pdf",
  "status": "created",
  "url": "/artifacts/AST-1842"
}

Un fichier généré n’est pas un simple contenu : c’est un objet à gérer. L’application doit en assurer le stockage et les droits d’accès, fixer sa durée de conservation et ses limites de taille, l’analyser du point de vue de la sécurité, conserver sa provenance et contrôler sa transmission à l’utilisateur.

Modèle spécialisé, outil ou agent ?

Ces notions ne sont pas équivalentes.

Modèle spécialisé
→ produit un type de contenu ou réalise une tâche ciblée

Outil
→ encapsule une capacité appelable par l’application

Agent
→ choisit et enchaîne plusieurs étapes ou outils selon un objectif

Un outil de génération d’image peut appeler un modèle spécialisé sans constituer un agent. Un agent peut, lui, combiner plusieurs outils, mais cette orchestration sera étudiée plus loin.

Scénario complet — Signaler le vélo endommagé

Demande

prompt
Stéphane : Le vélo VL-2048 est encore affiché comme disponible, mais sa roue arrière est bloquée. Peux-tu le signaler ?

Compréhension

intention = signalement de dommage
cible = VL-2048
symptôme = roue arrière bloquée
action avec effet réel = oui

Connaissance documentaire

Le RAG retrouve la procédure active pour la Belgique :

Un vélo présentant un défaut susceptible d’affecter la sécurité
ne doit plus être proposé à la location.
Le signalement doit créer un ticket de maintenance.

Vérification opérationnelle

get_bike_status("VL-2048")

Résultat :

{
  "bikeId": "VL-2048",
  "status": "available"
}

Préparation et confirmation

response
Je vais signaler VL-2048 pour roue arrière bloquée, le rendre indisponible et créer un ticket de maintenance. Confirmer ?

Exécution contrôlée

report_damaged_bike
→ validation
→ autorisation
→ idempotency key
→ système de flotte

Résultat

{
  "status": "success",
  "bikeId": "VL-2048",
  "newStatus": "unavailable",
  "reportId": "DR-95841",
  "maintenanceTicketId": "MT-18420"
}

Réponse finale

response
Le vélo VL-2048 a été signalé pour roue arrière bloquée et marqué comme indisponible. Le signalement DR-95841 a créé le ticket de maintenance MT-18420.

En résumé

Un LLM seul produit des tokens. Pour consulter une donnée actuelle ou modifier un système, l’application doit utiliser une capacité externe.

Une solution robuste suit la chaîne suivante :

intention comprise
→ outil sélectionné
→ arguments structurés
→ validation déterministe
→ autorisation et confirmation
→ exécution idempotente
→ résultat contrôlé
→ réponse honnête

Les idées essentielles sont :

• une sortie structurée n’est pas encore une action ;
• un appel d’outil est une demande que l’application peut refuser ;
• un outil métier peut encapsuler une ou plusieurs API techniques ;
• le système métier reste la source de vérité ;
• les outils d’écriture exigent des contrôles proportionnés au risque ;
• les identifiants ne doivent pas être inventés ;
• l’idempotence, les timeouts et les retries sont des responsabilités d’architecture ;
• le RAG fournit les règles documentaires, tandis que les outils consultent ou modifient l’état réel ;
• un modèle spécialisé peut produire un artefact derrière un outil sans être un agent.

Vérifiez votre compréhension

Question 1 — Pourquoi la phrase « le vélo a été signalé » ne prouve-t-elle pas que l’opération a réellement eu lieu ?

Réponse : Parce qu’une phrase générée ne constitue pas une transaction. Il faut vérifier le résultat retourné par le système de flotte et, idéalement, relire l’état enregistré.

Question 2 — Quelle différence faites-vous entre sortie structurée, appel d’outil et API ?

Réponse : La sortie structurée produit un format exploitable ; l’appel d’outil exprime une capacité et ses arguments ; l’API est l’interface technique qui permet à l’application d’atteindre le système réel.

Question 3 — Quelles responsabilités doivent rester dans l’application plutôt que dans le LLM ?

Réponse : L’exposition des outils, la validation, l’authentification, l’autorisation, les confirmations, l’idempotence, la gestion des erreurs, l’audit et l’exécution réelle.

Question 4 — Pourquoi un JSON conforme au schéma peut-il encore être dangereux ?

Réponse : Le schéma garantit surtout la forme. Les identifiants peuvent être faux, l’utilisateur non autorisé, la règle métier non respectée ou l’action trop risquée.

Question 5 — Dans quel cas une confirmation humaine est-elle utile, et quelles informations doit-elle présenter ?

Réponse : Elle est utile avant une action sensible, coûteuse ou difficilement réversible. Elle doit présenter la cible, l’effet, les données essentielles et les conséquences attendues.

Question 6 — À quoi sert une clé d’idempotence ?

Réponse : Elle permet au système de reconnaître une répétition de la même demande et d’éviter une double exécution.

Question 7 — Pourquoi un timeout ne permet-il pas de conclure que l’action a échoué ?

Réponse : Le système distant peut avoir exécuté l’opération sans que la réponse soit parvenue à l’application. Il faut vérifier le statut avant de réessayer.

Question 8 — Comment RAG et outils peuvent-ils être combinés dans le scénario du vélo endommagé ?

Réponse : Le RAG fournit la procédure et les règles applicables ; les outils lisent l’état actuel du vélo et exécutent le signalement autorisé.

Question 9 — Quelle différence faites-vous entre un modèle spécialisé, un outil et un agent ?

Réponse : Un modèle spécialisé produit ou analyse un type de contenu ; un outil encapsule une capacité contrôlée ; un agent poursuit un objectif au moyen d’une boucle de décisions et d’actions bornées.

Transition vers le chapitre suivant

Nous savons maintenant transformer une demande en appel d’outil contrôlé. L’application peut sélectionner une capacité, valider ses arguments, appliquer les droits, demander une confirmation et exécuter l’opération dans le système métier.

Mais cette approche reste encore locale à une application. Si l’assistant du service à la clientèle, l’assistant des opérations, un IDE de développeur et un orchestrateur doivent tous utiliser les mêmes capacités Bikaroo, les redéfinir séparément devient fragile : descriptions divergentes, schémas incompatibles, règles appliquées différemment et maintenance dispersée.

Le chapitre suivant sera :

Chapitre 7 — Pourquoi redéfinir le même outil dans chaque application ?

MCP : standardiser l’exposition des capacités aux applications d’IA

Il introduira MCP comme une manière de standardiser l’exposition et la découverte de ces capacités, sans remplacer les API métier, les validations ni les règles d’autorisation.