Données structurées avec les outils

Plus tôt dans ce cours, nous avons couvert l’extraction de données structurées avec le pré-remplissage de messages et les séquences d’arrêt. Cette approche fonctionne bien et est simple à mettre en place — mais elle reste un pari : on espère que le modèle respectera le format. Les outils offrent une extraction plus fiable : la méthode est plus complexe à implémenter, mais fournit une bien meilleure cohérence, car le format cesse d’être une consigne pour devenir une contrainte de l’API.

Pourquoi deux approches ?

Les outils nécessitent plus de configuration — un schéma à écrire, un paramètre à forcer. Avoir les deux techniques disponibles donne de la flexibilité : parfois l’approche rapide par prompt suffit — un script ponctuel, une exploration en notebook —, d’autres fois la fiabilité des outils est nécessaire — un pipeline de production qui parse la sortie sans relecture humaine. Connaître les deux, c’est choisir en connaissance de cause.

Comment ça marche

Le concept de base est un détournement astucieux : au lieu de demander à Claude de formater sa réponse en JSON, vous créez un outil dont les paramètres d’entrée correspondent exactement à la structure de données que vous voulez extraire. Claude « appelle » cet outil avec les données extraites comme arguments — et comme les arguments d’appel sont générés en conformité avec le schéma, la structure est garantie. La subtilité : l’outil n’a pas besoin d’exister. Aucune fonction derrière, aucune exécution — seuls ses arguments nous intéressent.

Le processus :

1. Écrire un schéma JSON décrivant la structure de données voulue
2. Créer un outil avec ce schéma comme spécification d’entrée
3. Envoyer vos données et le schéma à Claude
4. Forcer Claude à utiliser l’outil avec le paramètre toolChoice
5. Extraire les données structurées des arguments de l’appel d’outil

Contrôler l’utilisation de l’outil

L’étape 4 est le verrou du dispositif. Sur Bedrock, toolChoice s’exprime ainsi :

# Claude decide (defaut)
{"toolChoice": {"auto": {}}}

# Claude doit utiliser un outil, au choix
{"toolChoice": {"any": {}}}

# Claude doit utiliser cet outil precis
{"toolChoice": {"tool": {"name": "article_details"}}}

Pour l’extraction de données structurées, utilisez presque toujours la troisième option : elle force l’appel de votre outil de structuration à chaque requête, sans texte d’accompagnement possible. Les deux premières gardent leur place dans les vraies boucles d’outils — auto pour les assistants, any quand répondre sans outil n’aurait pas de sens.

Exemple pratique

Extraire le titre, l’auteur et les sujets clés d’un article :

article_details_schema = {
    "toolSpec": {
        "name": "article_details",
        "description": "Extrait les informations clés d'un article",
        "inputSchema": {
            "json": {
                "type": "object",
                "properties": {
                    "title": {
                        "type": "string",
                        "description": "Le titre de l'article"
                    },
                    "author": {
                        "type": "string",
                        "description": "Le nom de l'auteur"
                    },
                    "topics": {
                        "type": "array",
                        "items": {"type": "string"},
                        "description": "Liste des sujets clés mentionnés"
                    }
                },
                "required": ["title", "author", "topics"]
            }
        }
    }
}

Lisez ce schéma comme un contrat de sortie : trois propriétés typées — dont un tableau pour les sujets —, toutes déclarées dans required : Claude ne pourra ni en omettre, ni en inventer d’autres. La réponse contiendra une partie ToolUse dont le champ input est exactement votre structure, déjà parsée en dictionnaire — pas de json.loads, pas de nettoyage.

Avantages

Le bilan de l’approche : plus fiable que l’extraction par prompt, une structure garantie correspondant au schéma, pas besoin de pré-remplissage ni de séquences d’arrêt, et une validation intégrée via le schéma de l’outil — les types et champs requis sont contraints à la génération.

Le compromis principal est la complexité : un schéma complet à écrire là où le pré-remplissage tenait en deux lignes. Mais quand vous avez besoin de sorties structurées cohérentes et fiables — dès qu’un programme consomme la sortie sans supervision —, les outils sont la voie à suivre. Et si l’écriture des schémas devient un frein, la prochaine leçon montre une astuce pour l’alléger radicalement.

Points clés à retenir

• L’astuce : un outil fictif dont les paramètres sont la structure cible — seuls ses arguments comptent
• toolChoice: {"tool": {"name": ...}} force l’appel : plus de texte d’accompagnement possible
• required + types du schéma = validation à la génération, structure garantie
• Les données arrivent déjà parsées dans le champ input de la partie ToolUse
• Pré-remplissage pour l’exploration rapide ; outils pour la production qui exige la fiabilité