Vous êtes dev, plongé jusqu’au cou dans les sorties de LLM. Cet analyseur de sentiments ? Il vomit du JSON emballé en markdown. Ou il oublie des champs. Ou il en invente. Des heures perdues à décortiquer la bouillie. Structured Outputs d’OpenAI contre Zod règle ça — pour les vrais builders d’apps, pas les jouets de labo.
Soyons clair. Ce n’est pas de la théorie. C’est le tueur de deadlines.
Le discours d’OpenAI : intégrer la validation dès la génération. Fini les rustines après coup. Leur API oblige gpt-4o (ou la bête de 2026) à cracher un JSON Schema parfait. Champ obligatoire manquant ? Le modèle s’étouffe avant de finir. Du rêve.
Mais voilà le hic — un sac de nœuds de compromis qui commence par des menottes fournisseurs, passe par des chutes de vitesse, et atterrit sur la raison pour laquelle la plupart des devs ne mordront pas. OpenAI only. Génération plus lente à cause des contraintes. Limites du JSON Schema — pas de regex, pas de la magie Zod. Vous troquez la flexibilité contre des « garanties » qui puent la prison dorée.
Garanti pour matcher le schéma — le modèle ne peut rien générer d’autre
C’est dans la doc. Sexy. Mais les inconvénients : OpenAI seulement. Pas de Claude. Pas de Gemini. Condamné à traduire Zod en JSON Schema ? Barbant.
Pourquoi la « garantie » d’OpenAI sent le SOAP des années 2010
Vous vous souvenez de SOAP ? Les chouchous de l’entreprise juraient par des schémas rigides. Puis REST a tout explosé — JSON simple et flexible partout. Structured Outputs d’OpenAI ? Le fantôme de SOAP en tenue IA. Ils parient que vous avalerez l’enfermement pour de la fiabilité. Raté. Les devs détestent les silos.
Vérité cash : c’est plus lent. Les checks token par token ralentissent l’inférence. OK pour une analyse ponctuelle. Cauchemar à l’échelle.
Et les schémas ? Basiques. Enums, arrays, nids — d’accord. Logique custom ? Non. Zod avale ça tout cru.
Zod règle-t-il le chaos JSON LLM sans chaînes ?
Zod. Roi TypeScript aguerri. Parser après génération. Throw si invalide. Retry. Marche partout — Claude, Mistral, votre modèle llama.cpp du garage.
Extraire JSON du prose ? Regex. Raffiner avec .refine(). Transformer à la volée. Inférence de types full : z.infer. Votre IDE chante.
Inconvénients ? Oui. Le modèle peut halluciner un JSON foireux d’abord. Les retries coûtent des jetons, du fric. Mais c’est les LLM, fiston. Pas la faute de Zod.
Voici du code qui déchire :
import { z } from 'zod';
const SentimentSchema = z.object({
sentiment: z.enum(["positive", "negative", "neutral"]),
confidence: z.number().min(0).max(1),
topics: z.array(z.string()).min(1),
});
Composable. Extensible. Écosystème ? Énorme. Votre stack est probablement déjà Zodisé.
Mais les hacks d’extraction agacent. Ce raw.match(/\{[^}]*\}/) ? Fragile. Les LLM évoluent — demain Claude emballe en YAML. Super.
L’assaut furtif de l’AI SDK : le meilleur des deux mondes, sans prise de tête
Entrée en scène : l’AI SDK de Vercel. generateObject(). Filez-lui un schéma Zod. Il détecte le fournisseur — OpenAI ? Structured Outputs natifs. Claude ? Prompt + fallback Zod.
Une API. Sortie typée. Future-proof. Changer de modèle ? Le schéma suit.
Le SDK utilise automatiquement les structured outputs quand le fournisseur les supporte (OpenAI), et retombe sur une génération JSON par prompt + validation Zod pour les autres (Claude, Gemini). Une API, la meilleure stratégie par fournisseur.
De la magie. Pour les devs Next.js ? Évident. 2026 ? Ça domine. Mon pari audacieux — insight unique : d’ici 2026, attendez qu’Anthropic, Google alignent des structs natifs. L’AI SDK devient la couche d’abstraction, comme Axios sur fetch. Zod ? Le dialecte schémas. OpenAI ? Juste un backend.
Le spin PR d’OpenAI ? « 100 % garanti. » Mignon. Mais les retries dans les écosystèmes Zod tombent sous 1 % d’échecs avec de bons prompts. L
