Le modèle rapide écrit le code, le modèle intelligent répare la logique : comment monter une recherche avec n8n et PostgreSQL

On écrit beaucoup sur les modèles de pointe, mais presque rien sur la façon de répartir les rôles entre un modèle rapide et un modèle « qui réfléchit » sur une tâche réelle. L'auteur de cette analyse a pris un projet professionnel et a testé cette approche en pratique.

La tâche et pourquoi pas de LLM en production

Il fallait une recherche dans un catalogue de créations originales en pierres. Sur une page Tilda protégée, le spécialiste coche des domaines (amour, argent, santé, etc.) et choisit un design : féminin, masculin ou unisexe. En retour, il obtient jusqu'à cinq fiches issues d'une table PostgreSQL de 1684 enregistrements.

L'auteur a écarté la tentation d'intercaler entre le formulaire et la base un modèle qui « comprend la demande », pour trois raisons. La première est la latence : un appel réseau n'a aucun intérêt pour une recherche sur 1684 lignes. La deuxième est le coût et la variabilité : les règles de recherche peuvent être écrites explicitement. La troisième est la source de vérité : SQL ne renvoie que ce qui figure dans le catalogue, alors qu'un modèle pourrait ajouter une propriété plausible mais inventée. Les LLM ne servent donc qu'au stade du développement.

Les rôles sont les suivants. Particle-1 dans Cline était les « mains » : il écrivait le SQL et le code des nœuds n8n, corrigeait les guillemets et les noms de champs. GPT-6 Luna Pro était le « cerveau » : on l'appelait lorsque le problème ne relevait plus de la syntaxe mais du diagnostic. Les exécutions, la vérification de la réponse HTTP et les décisions produit sont restées à la charge de l'auteur.

Une réserve s'impose : ce n'est pas un test A/B. Les sessions diffèrent par leur volume, donc comparer 0,49 USD et 0,04 USD comme le prix de résolution d'une même tâche n'a pas de sens. Les données d'OpenRouter sur la latence ne sont elles aussi qu'un repère à une date donnée.

Cinq pièges, dans l'ordre

1. L'opérateur &. Pour compter les tags communs, le modèle a utilisé & pour un text[], qui n'existe pas dans PostgreSQL. L'opérateur && répond seulement à « y a-t-il une intersection », sans compter. Solution : && dans le WHERE pour sélectionner les candidats, et un sous-requête avec unnest pour compter les correspondances.

2. Syntax error near undefined. Le nœud Code renvoyait le champ sql_query, alors que le nœud Postgres lisait un autre nom. Le nœud Code, lui, restait au vert. Leçon : comparez l'OUTPUT réel du nœud précédent avec l'INPUT du suivant, et non la belle expression dans les paramètres.

3. Le littéral de tableau. Il faut deux niveaux de guillemets : doubles à l'intérieur pour les éléments, simples à l'extérieur pour la chaîne SQL. Le modèle a perdu la couche externe. L'auteur n'a pas réussi à paramétrer le tableau via $1, mais il n'affirme pas pour autant que n8n en est incapable. Pour une nouvelle production, il aurait d'abord cherché à obtenir une requête paramétrée.

4. Cinq lignes en SQL, une seule fiche sur le site. Selon la documentation, Respond to Webhook ne s'exécute qu'une fois, sur le premier item. Le mode All Incoming Items règle le problème. Le diagnostic était brouillé par le fait qu'en tête figurait une large entrée universelle avec huit tags, ce qui donnait l'impression que SQL renvoyait toujours la même chose.

5. Genre féminin : une entrée sur 1684. Le filtre n'est pas cassé, ce sont les données qui sont déséquilibrées : presque tout est classé en unisex. L'auteur n'a pas touché à l'algorithme mais a fixé une règle produit : une demande féminine admet female et unisex, et à égalité la correspondance exacte de genre passe en premier. Déterminer s'il s'agissait d'une erreur d'import, le modèle ne pouvait pas le faire.

La faille que les modèles n'ont pas vue

Lors de la revue finale, l'auteur n'a pas demandé « pourquoi ça plante », mais « que se passe-t-il si on contourne le formulaire ». La barre oblique inverse et le guillemet double étaient échappés, mais pas le guillemet simple, alors que le littéral était justement enveloppé de guillemets simples. Avec curl, on pouvait casser la chaîne et modifier la requête. Le mot de passe de la page Tilda ne protège que le HTML, pas les requêtes vers n8n. Une clé API dans le JS côté client n'aurait rien changé non plus. Le correctif a été fait côté serveur : liste blanche des valeurs de spheres et gender, plus un échappement correct des deux niveaux.

Ce qu'il faut en retenir

La séparation « exécutant rapide plus diagnostiqueur lent » fonctionne si c'est vous qui décidez du moment du basculement : erreur de syntaxe ou de comportement du système. Le statut vert d'un nœud ne prouve pas la cohérence de l'ensemble. Un classement par cardinality(tags) n'empêche pas une entrée large de l'emporter. Et une liste de domaines vide désactive silencieusement le filtre ; dans une API publique, mieux vaut renvoyer un 400. La revue de sécurité reste un travail humain : dans ce cas, aucun des deux modèles n'a signalé l'injection.