Nodes Sort et Limit n8n : trier et plafonner vos items (guide complet)

Trier une liste et n'en garder qu'une partie sont deux opérations si banales qu'on les néglige — jusqu'au jour où un « top 10 des leads » remonte les moins bons, ou qu'un workflow de test envoie 4 000 items à une API facturée à l'appel. n8n propose deux nodes dédiés, Sort (n8n-nodes-base.sort) et Limit (n8n-nodes-base.limit), qui se configurent en trente secondes et se combinent naturellement. Ce guide détaille leurs paramètres réels, le pattern Sort + Limit, et les pièges de typage qui expliquent la plupart des tris « bizarres ».

Deux nodes, un même terrain : la liste d'items

Comme Filter, Split Out et Aggregate ou Merge, Sort et Limit appartiennent à la famille des nodes de transformation : ils ne parlent à aucun service externe, ils remodèlent le tableau d'items qui circule entre deux nodes.

• Sort conserve tous les items mais change leur ordre ;
• Limit conserve l'ordre mais réduit le nombre d'items.

Les deux travaillent sur l'ensemble du lot d'un coup, contrairement à Filter qui évalue chaque item isolément. C'est important : un node Sort placé à l'intérieur d'une boucle Loop Over Items ne trierait que le batch courant, pas la totalité des données.

Le node Sort et ses trois modes

Le paramètre principal du node s'appelle Type et propose trois modes : Simple, Random et Code.

Mode Simple : champs et ordre

C'est le mode par défaut. Vous ajoutez un ou plusieurs critères via le bouton Add Field To Sort By, chacun composé de :

• Field Name : le nom du champ à comparer (score, date_creation, client.nom en dot notation) ;
• Order : Ascending (croissant) ou Descending (décroissant).

Le tri multi-champs suit l'ordre de déclaration : le premier critère décide, le second départage les ex æquo, et ainsi de suite. Pour classer des commandes par client puis par montant décroissant, déclarez client en Ascending, puis montant en Descending.

Une option mérite d'être connue : Disable Dot Notation. Tant qu'elle est désactivée, client.nom est interprété comme « la propriété nom de l'objet client ». Si vos données contiennent un champ dont le nom comporte littéralement un point, activez-la pour que n8n cesse de découper la chaîne.

Mode Random : l'échantillon aléatoire

Le mode Random mélange les items sans autre paramètre. Combiné à un Limit, il produit un échantillon : trois lignes tirées d'un fichier de 4 000 pour valider un prompt IA, dix contacts d'une base pour tester un envoi. C'est le réflexe à avoir avant de lancer un workflow coûteux sur l'intégralité d'un jeu de données.

Attention toutefois : ce tirage n'est pas reproductible d'une exécution à l'autre, et il suppose que tous les items sont déjà chargés en mémoire. La littérature sur l'échantillonnage traite précisément ce cas : dans « Random Sampling with a Reservoir », publié en 1985 dans ACM Transactions on Mathematical Software, Jeffrey S. Vitter décrit des algorithmes capables de tirer un échantillon uniforme en une seule passe et en mémoire constante, sans connaître à l'avance la taille de la population (voir sur Google Scholar). C'est exactement l'inverse du mode Random de n8n, qui exige d'avoir tout récupéré avant de choisir — d'où l'intérêt d'échantillonner côté source (une clause LIMIT SQL, un paramètre d'API) quand le volume devient sérieux.

Mode Code : une fonction de comparaison sur mesure

Le mode Code attend une fonction de comparaison JavaScript, avec la même signature que le comparateur natif de Array.sort() : deux items a et b, et une valeur de retour négative si a doit passer avant b, positive dans le cas inverse, zéro s'ils sont équivalents. Les champs se lisent via a.json.<champ>.

// Trier par priorité métier, puis par date la plus récente
const rang = { urgent: 0, normal: 1, bas: 2 };
const d = rang[a.json.priorite] - rang[b.json.priorite];
if (d !== 0) return d;
return new Date(b.json.date).getTime() - new Date(a.json.date).getTime();

Ce mode couvre ce que Simple ne sait pas faire : un ordre métier arbitraire, une normalisation avant comparaison (accents, casse, espaces), un score calculé à la volée. Si la logique devient longue, mieux vaut basculer sur un vrai node Code et faire le tri là-bas.

La documentation n8n précise un point décisif : le tri s'appuie sur le comportement JavaScript par défaut, où les éléments sont convertis en chaînes avant comparaison. C'est la source du piège numéro un, détaillé plus bas.

Le node Limit : Max Items et Keep

Le node Limit n'a que deux paramètres :

• Max Items : le nombre maximum d'items conservés. Si l'entrée en contient moins, rien n'est supprimé ;
• Keep : First Items (garder les N premiers) ou Last Items (garder les N derniers).

Toute la subtilité tient dans le fait que « premiers » et « derniers » n'ont de sens que par rapport à l'ordre courant du lot. Sans Sort en amont, cet ordre est celui que le node précédent a produit — pas forcément celui auquel vous pensez.

Le pattern Sort + Limit : le top-k

L'enchaînement Sort puis Limit est le seul moyen fiable d'obtenir un « top N » dans n8n :

1. Sort en mode Simple, champ score, Order Descending ;
2. Limit, Max Items 10, Keep First Items.

Inverser les deux nodes donne un résultat silencieusement faux : le Limit prendrait dix items dans l'ordre d'arrivée, et le Sort ne trierait que ces dix-là. L'erreur ne lève aucune exception, elle produit juste un mauvais classement — le genre de bug que le débogage de workflows met du temps à révéler.

À noter : trier puis couper est le chemin le plus simple, pas le plus efficace en théorie. Sur de très gros volumes, un algorithme de sélection récupère les k meilleurs sans trier le reste. En pratique, les moteurs modernes s'appuient sur des tris dits adaptatifs, qui exploitent l'ordre déjà présent dans les données : Vladimir Estivill-Castro et Derick Wood en dressent l'inventaire dans « A Survey of Adaptive Sorting Algorithms », publié en 1992 dans ACM Computing Surveys (voir sur Google Scholar). C'est aussi le principe de Timsort, l'algorithme derrière Array.sort() en JavaScript : sur des données déjà partiellement triées — un flux RSS, un export chronologique — le coût réel du node Sort est bien inférieur à ce que la théorie du pire cas laisse craindre.

Quatre cas d'usage concrets

• Top 10 des leads les mieux scorés : après un scoring IA façon qualification de leads entrants, Sort Descending sur score puis Limit à 10 en First Items, avant l'envoi au CRM ou à Slack ;
• Les 5 dernières actualités d'un flux RSS : le node RSS Read renvoie les entrées dans l'ordre du flux, qui n'est pas toujours chronologique. Sort Descending sur la date de publication, puis Limit à 5, sécurise la veille RSS automatisée ;
• Échantillon de test : Sort en Random + Limit à 3 en tête de workflow, le temps de valider un prompt ou une transformation sans consommer tout le jeu de données ;
• Plafonner une API payante : un Limit juste avant l'appel garantit qu'une source anormalement volumineuse ne déclenchera pas 2 000 requêtes. C'est un garde-fou, à combiner avec une vraie gestion du rate limit des API IA.

Les pièges classiques

• Le tri lexicographique sur des nombres : si score vaut "10" et "9" en chaînes, le tri ascendant place "10" avant "9". Convertissez avec un node Edit Fields (Set) et une expression {{ Number($json.score) }} avant le Sort. Le symptôme typique : un classement correct jusqu'à 9, puis n'importe quoi ;
• Les dates au mauvais format : 2026-08-25 (ISO) se trie correctement comme chaîne, 25/08/2026 non — il classerait tous les 25 du mois ensemble. Normalisez en ISO ou en timestamp en amont, à l'aide des fonctions de dates détaillées dans le guide des expressions n8n ;
• Les valeurs nulles ou absentes : un item sans le champ trié ne disparaît pas, il se retrouve à une extrémité arbitraire du classement — et peut donc squatter votre top 10. Filtrez-les avant, ou attribuez-leur une valeur plancher avec un node Set ;
• Limiter n'est pas paginer : le Limit intervient après réception des données. Si l'objectif est d'éviter de télécharger 10 000 lignes, c'est côté requête que ça se joue, via la pagination du node HTTP Request ;
• L'ordre n'est jamais garanti par défaut : certains nodes — appels parallèles, agrégations, retours d'API — ne préservent pas l'ordre d'entrée. Si l'ordre compte pour la suite (numérotation, Summarize, concaténation d'un rapport), replacez un Sort explicite juste avant plutôt que de faire confiance à l'ordre observé lors d'un test.

En résumé

Sort réordonne, Limit tronque, et leur combinaison dans le bon sens — Sort d'abord, Limit ensuite — répond à la quasi-totalité des besoins de classement dans n8n. Retenez les trois paramètres qui comptent vraiment : Order (Ascending/Descending) côté Sort, Max Items et Keep (First/Last Items) côté Limit. Et gardez en tête que le tri compare des chaînes par défaut : la moitié des tris « incohérents » se règlent par une conversion en nombre ou en date ISO placée juste avant le node Sort.

Pour aller plus loin

Ces deux nodes prennent tout leur sens dans des workflows où le volume est le vrai sujet. Le Pack Inbox IA (79 €) applique ce raisonnement au traitement d'emails : trier par priorité, plafonner le nombre de messages analysés par exécution, et ne remonter que ce qui mérite une réponse. Pour des workflows de recherche documentaire où seuls les meilleurs extraits doivent atteindre le modèle, le Pack Assistant RAG (119 €) montre le même pattern top-k appliqué aux résultats d'une base vectorielle.