← Retour au projet Redline Specs Voir la démo →
// ÉTUDE DE CAS TECHNIQUE

Redline Specs

Sur la fiche projet, j'explique ce que fait Redline Specs. Ici, je détaille comment : comment une requête traverse l'API et Groq à chaque changement de filtre, et pourquoi le filtre est construit dans cet ordre précis plutôt qu'un autre.

Aperçu Redline Specs

Architecture : API + IA

Redline Specs n'a pas de base de données. L'API custom fournit les données brutes ; quand un champ manque ou qu'un modèle mérite plus de contexte, c'est Groq qui complète jamais l'inverse. Ce choix évite d'avoir à maintenir une base à la main pendant que la source d'origine continue d'évoluer.

Interface (Next.js) marque · permis · type · modèle · année Route API interne orchestre la requête API custom données brutes, parfois incomplètes Groq AI complète les champs manquants + enrichit le contexte modèle Fusion des données brut + complété → une fiche Affichage résultats rejoué à chaque filtre, sans cache
Donnée d'origine (API) Complétée par l'IA
 

Pourquoi ce filtre, dans cet ordre

Marque, permis, type, modèle, année : l'ordre n'est pas celui des colonnes dans la donnée, c'est celui dans lequel un acheteur de moto raisonne réellement du plus large au plus précis, avec la seule contrainte légale placée dès que la marque est choisie.

Chaque filtre relance un appel serveur plutôt que de trier une liste déjà chargée côté client. Charger le catalogue entier (15 marques et plus) au premier chargement pour gagner en rapidité sur le deuxième clic n'était pas un bon compromis : la liste passe en état de chargement dès le clic, pour que l'attente se lise comme une réponse en cours et non comme un gel de l'interface.

Next.js API custom GROQ AI Vercel