Si votre application extrait encore du JSON depuis de la prose modèle avec une regex et une boucle de reprise, vous résolvez un problème qu'Amazon Bedrock résout désormais au niveau du décodage. Les sorties structurées, disponibles en général sur Bedrock depuis février 2026, contraignent le modèle à un JSON Schema pendant qu'il génère des tokens, si bien que la réponse se conforme à votre forme par construction plutôt que par espoir. La regex n'a jamais été la solution. Elle était le symptôme de demander à un modèle de « retourner du JSON s'il vous plaît » puis de nettoyer quand il ne le faisait pas.

L'approche par parsing échoue de manières agaçantes précisément parce qu'elles sont rares. Quelque chose comme quatre-vingt-dix pour cent des réponses se parsent. Le reste enveloppe le JSON dans un bloc markdown, ajoute une phrase amicale avant, laisse traîner une virgule, ou hallucine un champ. Votre parseur plante alors en production, sur l'entrée que vous n'avez pas testée, au pire moment. Le décodage contraint élimine toute cette classe d'échec car le token invalide n'est jamais émis en premier lieu.

Trois façons d'obtenir de la structure, par ordre de force

Demander et prier

Vous demandez du JSON dans le system prompt, donnez peut-être un exemple, et parsez le texte. Cela fonctionne jusqu'à ce que ça ne fonctionne plus. Il n'y a aucune garantie, aucune application, et son taux d'échec est exactement la queue de distribution qui n'apparaît jamais dans une démo. Chaque heure passée à durcir le parseur est une heure passée sur un problème que la plateforme peut éliminer.

L'usage d'outils comme schéma

Bien avant les sorties structurées natives, l'astuce fiable consistait à définir un outil dont le schéma d'entrée est la forme voulue, puis à lire les arguments de l'appel d'outil au lieu du texte du message. Le modèle remplit les entrées de l'outil, et vous obtenez un objet structuré. C'est encore un bon modèle quand le même appel doit aussi réellement invoquer des outils. Sur Bedrock, vous pouvez maintenant ajouter strict: true à une définition d'outil pour que le nom de l'outil et ses entrées soient validés contre le schéma plutôt que simplement suggérés par lui.

Sorties structurées natives

La voie directe consiste à déclarer la forme de réponse comme un JSON Schema et à laisser Bedrock l'imposer pendant la génération. Cela utilise JSON Schema Draft 2020-12 et le décodage contraint, si bien que le modèle ne peut physiquement pas émettre un token qui casserait le schéma. Sur l'API Converse, le champ est outputConfig.textFormat, et le schéma a besoin d'un name. C'est disponible sur Converse, ConverseStream, InvokeModel et InvokeModelWithResponseStream pour Anthropic Claude 4.5 et un ensemble de modèles à poids ouverts.

// Converse: enforce the shape instead of parsing for it
outputConfig: {
  textFormat: {
    jsonSchema: {
      name: "extraction",
      schema: {
        type: "object",
        properties: {
          invoice_id: { type: "string" },
          total_cents: { type: "integer" },
          currency: { type: "string", enum: ["USD", "EUR", "GBP"] }
        },
        required: ["invoice_id", "total_cents", "currency"],
        additionalProperties: false
      }
    }
  }
}

Ce que l'application vous apporte

Le gain évident est que la sortie se parse. Le gain plus grand est ce que vous pouvez supprimer : la boucle de reprise sur invalide, la bibliothèque de réparation JSON, le re-prompt défensif qui dit « vous avez retourné du JSON invalide, réessayez », et l'alerte qui se déclenche quand tout cela échoue quand même. Chacun de ces éléments compensait une sortie probabiliste. Une fois le schéma imposé pendant le décodage, la compensation devient du code mort. Moins de reprises signifie aussi moins de tokens et une latence plus basse, car vous ne payez pas un second appel pour réparer le premier.

Définissez additionalProperties: false et marquez les champs required pour que le schéma soit strict. Un schéma lâche qui autorise des clés supplémentaires vous rend une partie de la garantie que vous venez d'acheter, car le modèle peut encore attacher des champs que votre code n'attend pas.

Où cela ne s'applique pas

La sortie structurée est faite pour des réponses lisibles par machine : extraction, classification, routage, arguments de fonction, tout ce qu'un système en aval consomme. C'est le mauvais outil pour la prose qu'un humain lit, où un schéma rigide va à l'encontre du but. Et cela contraint la forme, pas la vérité. Un schéma garantit que total_cents est un entier, pas que c'est le bon entier. La validation des valeurs, des plages et des règles métier reste votre travail. Le schéma supprime le mode d'échec du parsing. Il ne supprime pas le besoin de vérifier que le modèle a donné la bonne réponse.

À retenir

Le parsing astucieux est un effort dépensé à contourner une garantie que le modèle ne vous a jamais donnée. Les sorties structurées Bedrock déplacent la garantie dans le décodeur : déclarez un JSON Schema, et la réponse est valide par construction. Utilisez les sorties structurées natives pour les données pures, les schémas d'usage d'outils quand le même appel agit aussi, et gardez la validation au niveau des valeurs dans tous les cas. Puis supprimez la regex, la boucle de réparation et la reprise. C'était de l'échafaudage pour un problème que vous n'avez plus.

À lire ensuite

Pour le côté plateforme et livraison de la fiabilisation de ce processus, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.