Le laboratoire
JSON impeccable, réponse complètement fausse
Trois portes à franchir : syntaxe, schéma et fidélité au document. Une seule ne suffit pas.
Expérience construite · sans modèle exécuté
La situation · Extraire la bonne information
Une équipe organise une réunion avec un client. Son message mentionne le siège à Paris et le rendez-vous à Lyon. L’assistant doit remplir automatiquement la ville de réunion dans le dossier ; une erreur enverrait l’équipe au mauvais endroit.
Ce que vous allez apprendre
Comprendre pourquoi un format exploitable et une information correcte sont deux exigences distinctes.
Votre mission
Examinez la réponse proposée, modifiez-la et identifiez exactement le contrôle qui échoue. Expliquez pourquoi Paris est une réponse plausible mais incorrecte.
À la fin de cette activité. Vous saurez écrire un contrat d’extraction et séparer les erreurs de syntaxe, de structure et de sens.
À vous de jouer
Le siège est à Paris. La réunion aura lieu à Lyon.
Extraire uniquement la ville de réunion dans le champ meeting_city (texte ou null). Aucun autre champ. null seulement si la ville est absente.
Paris est bien présent dans le document, mais joue le mauvais rôle. Une sortie contrainte peut garantir une forme ; elle ne prouve pas que la bonne information a été extraite.
Pourquoi nous avons choisi ce document
Le texte est volontairement court : nous voulons que vous puissiez déterminer la bonne réponse sans l’aide d’un modèle. Les deux villes ne sont pas interchangeables. Paris est associé au siège, tandis que Lyon est associé à la réunion. Une extraction correcte doit reconnaître cette relation. Repérer simplement un nom de ville ne suffit donc pas.
Le premier résultat affiché contient Paris. Regardez les trois contrôles avant de le corriger. Les deux premières réussites ne sont pas contradictoires avec le dernier échec : elles portent sur d’autres propriétés de la réponse. Le JSON est lisible et le type de la valeur convient, mais le sens ne correspond pas à la demande.
Comprendre ce que vérifie chaque porte
Le contrôle syntaxique joue le rôle d’un lecteur très strict : il attend les guillemets, accolades et séparateurs exigés par JSON. Le contrôle du schéma regarde ensuite l’organisation de l’objet. Il refuse, par exemple, un tableau de villes ou un nombre, même si ces formes sont du JSON valide. Enfin, le contrôle de fidélité compare la valeur à notre référence.
Un contrôle en aval n’est pas évalué lorsque le contrôle précédent ne fournit pas une structure exploitable. Cette distinction est utile pour le diagnostic : une sortie impossible à lire ne doit pas être présentée comme si l’on avait déjà vérifié son sens.
Dans un projet réel, la référence doit venir du document et d’une règle d’annotation explicite. La réponse attendue est ici connue à l’avance pour rendre le raisonnement visible. La capsule ne prétend donc pas vérifier automatiquement la vérité de n’importe quel texte.
Trois portes, trois questions
Le premier contrôle demande si le texte peut être lu comme du JSON. Le deuxième impose un objet avec exactement un champ meeting_city, de type texte ou null. Le troisième compare la valeur à la ville de réunion de notre document : Lyon.
Sabotez votre réponse
Enlevez un guillemet pour casser la syntaxe. Remplacez la ville par 42 pour casser le schéma. Écrivez Paris pour passer les deux premiers contrôles et échouer au dernier. Puis essayez null : le format est acceptable, mais la réponse reste fausse ici puisque la ville est donnée.
La limite de la capsule
La comparaison utilise une référence connue et une égalité exacte. Un véritable système doit prévoir les variantes de noms, les documents ambigus et les informations absentes. Il doit distinguer absence, incertitude et valeur hors du catalogue. Aucun modèle ne génère les réponses de cette expérience.