Développement Next.js quand le modèle doit être fiable

Le développement Next.js est l'endroit où vit la plupart de la couche d'orchestration dans les produits IA que j'ai construits. Le framework est rapide à utiliser, mais les vrais problèmes ne concernent jamais le framework lui-même. Ils concernent ce qui se passe quand un modèle de langage est un nœud dans un workflow qui ne peut pas se permettre de se tromper, et comment vous construisez la structure autour de lui pour que la sortie du modèle soit vérifiable avant de toucher à quoi que ce soit de réel.

Le pattern que j'ai rencontré à travers Fursa, ProPost AI, et Job Hunter était le même. Un modèle produit une sortie. Cette sortie alimente une écriture en base de données, un rendu de document, ou une recommandation visible par l'utilisateur. Si la sortie est malformée, ambiguë, ou hallucée, l'effet en aval n'est pas juste une mauvaise expérience utilisateur. C'est une rupture de confiance qui est difficile à récupérer.

Les sorties structurées ont changé le contrat avec le modèle

Pendant longtemps, l'ingénierie des prompts était la défense principale. Vous disiez au modèle quelle forme vous vouliez, et vous espériez. Ce n'est pas un contrat. C'est une suggestion.

Ce qui a changé l'architecture pour moi, c'est de traiter l'application des sorties structurées comme une exigence de première classe, pas une réflexion après coup. En pratique, cela signifie des schémas Pydantic sur chaque appel de modèle qui retourne des données dont l'application dépend. Le mode JSON où le fournisseur le supporte. La validation du schéma avant que toute fonction en aval ne reçoive la charge utile.

Si le modèle retourne quelque chose qui ne se conforme pas, l'appel échoue rapidement et réessaie avec un prompt resserré, ou escalade vers une file d'attente de révision humaine. Ce n'est pas élégant. Cela ajoute de la latence. Mais cela rend le comportement du système prévisible, ce qui est la seule chose qui compte en production.

Le workflow est le produit, pas le prompt

Sur Fursa, la tâche était l'éligibilité des routes de visa à travers plus de 170 pays de destination. Le modèle devait raisonner sur les combinaisons de passeports, les règles de transit, et les exigences documentaires. Aucune de ces informations n'est statique. Les règles changent. Les ambassades mettent à jour les exigences sans préavis.

Le prompt seul ne pouvait pas porter cette responsabilité. L'architecture devait le faire.

Ce que j'ai construit était un workflow où la sortie du modèle était un signal, pas la réponse finale. Le résultat d'éligibilité passait par une étape de vérification par rapport à une couche source curée et horodatée. Si la sortie du modèle et la couche source n'étaient pas d'accord au-delà d'un seuil défini, le résultat était signalé et retenu. Un examinateur humain l'approuvait avant qu'il n'atteigne l'utilisateur.

C'est la contrainte que la plupart des discussions sur les produits IA ignorent. Le modèle est rapide. Le modèle a souvent raison. Mais le coût de se tromper dans un contexte de visa est un vol manqué ou un refus d'entrée. Ce coût n'est pas acceptable. Donc le workflow doit être conçu autour du mode d'échec, pas du cas de succès.

Next.js comme shell d'orchestration

L'application Next.js est l'endroit où vivent les états du workflow. Les server actions gèrent les appels de modèle. Les route handlers gèrent les callbacks webhook des files d'attente de révision asynchrone. Le app router avec ses layouts imbriqués signifie que les résultats signalés rendent une interface différente de ceux approuvés, sans dupliquer la logique de la page.

C'est là que le framework gagne sa place. Pas dans la couche IA, mais dans la gestion d'état autour d'elle. Un résultat signalé a besoin d'une interface de révision. Un résultat approuvé a besoin d'une interface de livraison. Un appel échoué a besoin d'une surface de réessai. Ce sont des états différents des mêmes données, et le routing basé sur le système de fichiers les rend composables sans combattre l'architecture.

Sur ProPost AI, le volume était différent. Le système génère jusqu'à 365 brouillons LinkedIn par utilisateur par an. La couche d'application du schéma s'exécute à la même échelle que le modèle. La porte de révision est plus légère car le mode d'échec est un mauvais post, pas une conséquence légale. L'architecture s'ajuste au coût de se tromper. Cet étalonnage est une décision de conception, pas une valeur par défaut.

Les portes humaines ne sont pas un contournement, c'est l'architecture

Les portes d'approbation humaine sont parfois décrites comme une mesure temporaire, quelque chose que vous supprimez quand le modèle s'améliore. C'est le mauvais modèle mental.

Une porte humaine est une condition limite. Elle définit la classe de sorties dont le système n'est pas assez confiant pour passer automatiquement. À mesure que la qualité du modèle s'améliore, cette classe rétrécit. Mais elle n'atteint jamais zéro dans un domaine où le coût de l'erreur est élevé. La porte reste. Son taux d'activation change.

Sur Job Hunter, le système explore plus de 185 pages de carrière et produit des listes d'emploi structurées et des brouillons de sensibilisation. Le modèle extrait et formate. Une couche de validation vérifie les champs obligatoires, la plausibilité de la fourchette salariale, et la cohérence du nom de l'entreprise. Les sorties qui échouent la validation vont dans une file d'attente. L'utilisateur voit des listes confirmées, pas la sortie brute du modèle.

Même pattern. Domaine différent. Coût d'échec différent. Même réponse structurelle.

À quoi ressemble vraiment le stack

Pour quiconque évalue les décisions d'ingénierie, voici ce que j'ai choisi et pourquoi.

• —Pydantic v2 pour la définition et la validation du schéma. C'est rapide, les messages d'erreur sont utilisables, et cela s'intègre proprement avec les SDKs des principaux fournisseurs de modèles.
• —Sorties structurées / mode JSON au niveau du fournisseur où disponible. Cela contraint l'espace de tokens du modèle à du JSON valide, ce qui réduit mais n'élimine pas le besoin de validation en aval.
• —Files d'attente asynchrones pour tout ce qui nécessite une révision humaine. L'utilisateur obtient un état en attente. L'examinateur obtient un tableau de bord. Le système ne bloque pas.
• —Next.js server actions pour l'orchestration des appels de modèle. Garde la logique IA côté serveur, loin du bundle client, et rend simple l'ajout de middleware pour la journalisation et la limitation de débit.
• —Réponses API typées de bout en bout. Le schéma qui définit ce que le modèle doit retourner est le même schéma qui type l'écriture en base de données et les props du composant. Un changement dans l'un se propage.

L'objectif est que l'incertitude du modèle ne devienne pas l'incertitude de l'application. L'application sait toujours dans quel état elle se trouve.

Ce que cela vous dit sur le travail

N'importe qui peut brancher un appel OpenAI et rendre la sortie. Le travail consiste à décider ce qui se passe quand la sortie est mauvaise, à construire le système qui la détecte, et à rendre ce système assez rapide pour être livré.

La perspective d'ingénierie sur ce site va plus loin dans les décisions architecturales et les compromis derrière elles. L'ensemble complet des études de cas de produits IA montre le même pattern appliqué à différents domaines et différents coûts d'échec.

Si vous construisez quelque chose où le modèle doit être fiable et voulez discuter de l'architecture avant de vous y engager, le formulaire de contact est le moyen le plus rapide de commencer cette conversation.