Catégoriser

Classe le mail dans les catégories que vous définissez et l’envoie sur la branche correspondante. Chaque catégorie est une sortie du nœud.

Catégoriser est un routeur : chaque catégorie que vous déclarez dessine sa propre sortie sur le canvas, et le modèle décide laquelle le mail emprunte. Utilisez-le pour trier le courrier entrant (devis, factures, réclamations, newsletters) et brancher une suite différente derrière chaque catégorie.

Préférez Extraire quand vous avez besoin de valeurs tirées du mail plutôt que d’une décision, et Résumer quand vous voulez un texte court. Quand la règle de tri est déterministe (un expéditeur, un mot dans l’objet), un Aiguillage ou une Condition (Si) ne coûtent rien et n’hésitent jamais.

En bref

• Type : ai.categorize · version 1
• Catégorie : IA
• Nature : Étape — s’exécute pendant une exécution
• Effet : Sans effet externe (none) — rien n’est écrit hors de Mankomail ; rejouable sans risque
• Exige un mail porteur : Non
• Connexion : Aucune
• Entrées : main
• Sorties : Calculées depuis les paramètres (avec les paramètres par défaut : other)
• Ports de service : model (llm.model, facultatif)

Paramètres

categories

Catégories — Chaque catégorie donne son nom à une sortie du nœud. La description est lue par le modèle : c’est elle qui fait la qualité du tri.

• Type : Liste d’éléments (collection)
• Requis : Oui
• De 1 à 20 éléments
• Chaque élément a :
  • name — Nom
    • Type : Texte (string)
    • Requis : Oui
    • 120 caractères au plus
    • Exemple : Demande de devis
    • Expressions : {{ }} refusé
  • description — Description. Ce qui doit entrer dans cette catégorie, et ce qui n’y entre pas.
    • Type : Texte long (text)
    • Requis : Non
    • Défaut : "" (vide)
    • 1000 caractères au plus

prompt

Consignes système — Les consignes générales données au modèle. La valeur par défaut est en anglais — c’est la langue dans laquelle les modèles sont les plus fiables — mais vous pouvez le réécrire dans la vôtre : la réponse suit le mail, pas la consigne. La liste des catégories, le format de sortie et les règles de sécurité sont ajoutés automatiquement.

• Type : Texte long (text)
• Requis : Oui
• 5000 caractères au plus
• Rangé sous « Avancé » dans l’éditeur
• Expressions : {{ }} refusé
  Valeur par défaut

  You are an email triage assistant for a company.
  Classify the email into the categories below, using only its content and the description of each category.
  
  Rules:
  - Rely on the actual intent of the message, not on the presence of any particular word.
  - Use only the categories provided: never invent one, never rename one.
  - When in serious doubt, prefer the fallback over an approximate classification.

inputTemplate

Contenu à traiter — Ce que le modèle voit du mail. Par défaut l’objet et le corps texte.

• Type : Texte long (text)
• Requis : Oui
• 10000 caractères au plus
• Rangé sous « Avancé » dans l’éditeur
• Expressions : {{ }} accepté
  Valeur par défaut

  {{ email.subject }}
  
  {{ email.bodyText }}

multiLabel

Plusieurs catégories possibles — Le mail sort sur la première catégorie vraie, mais toutes les catégories reconnues sont disponibles dans les données (categories).

• Type : Oui / non (boolean)
• Requis : Non
• Défaut : false

fallback

Si aucune catégorie ne convient

• Type : Un choix (options)
• Requis : Oui
• Défaut : other
• Options :
  • other — Sortir sur « Autre » : Une branche supplémentaire reçoit les mails non classés.
  • discard — Arrêter proprement : L’exécution se termine sans erreur : rien ne part en aval.

Sorties

Calculées depuis les paramètres.

• other — Présent seulement quand le repli est réglé sur « Sortir sur “Autre” ». Emprunté quand le modèle n’a marqué aucune catégorie comme vraie.
• cat:<category> — Un port par catégorie déclarée, nommé cat: suivi du nom de la catégorie tel que saisi (par exemple cat:Factures). Le mail sort par la première catégorie que le modèle a marquée comme vraie, dans l’ordre de déclaration des catégories.

Données produites

Ce que ce nœud ajoute aux données de l’exécution, et comment le lire dans une expression. <step> désigne la clé de l’étape : le nom du nœud ramené à un identifiant (voir Données et expressions).

• {{ data.<step>.category }} — string or null. Le nom de la catégorie par laquelle le mail est sorti (la première catégorie vraie dans l’ordre de déclaration). null quand aucune catégorie ne convient.
• {{ data.<step>.categories.<category> }} — object of booleans. Un booléen par catégorie déclarée, indexé par le nom de la catégorie. Contient toutes les catégories reconnues : c’est ce qui rend le mode multi-catégories exploitable.
• {{ data.<step>.matched }} — array of string. Les noms de toutes les catégories marquées comme vraies, dans l’ordre de déclaration. Vide quand aucune catégorie ne convient.
• {{ data.<step>.multiLabel }} — boolean. La valeur du réglage « Plusieurs catégories possibles » pour cette exécution.
• {{ data.<step>.discarded }} — boolean. true quand aucune catégorie ne convenait et que le repli est réglé sur « Arrêter proprement » : la branche s’est terminée sans erreur.
• {{ data.<step>.simulated }} — boolean. true quand la sortie a été fabriquée au lieu de venir d’un modèle (essai sur une instance sans fournisseur d’IA utilisable). false pour une vraie réponse de modèle.

Exemple

Une boîte commerciale partagée reçoit des demandes de devis, des factures et tout le reste. Ajoutez un nœud Catégoriser nommé Trier avec ces catégories :

categories:
  - name: Devis
    description: Un prospect ou un client demande un prix, un devis ou une estimation. Pas une facture à payer.
  - name: Factures
    description: Un fournisseur envoie une facture, une relance de paiement ou un avoir.
fallback: other
multiLabel: false

Le nœud affiche trois sorties : cat:Devis, cat:Factures et other. Pour un mail qui demande « Pourriez-vous nous faire un prix pour 200 pièces ? », le mail sort par cat:Devis et les données de l’étape sont :

{
  "category": "Devis",
  "categories": { "Devis": true, "Factures": false },
  "matched": ["Devis"],
  "multiLabel": false,
  "discarded": false,
  "simulated": false
}

En aval, {{ data.trier.category }} vaut Devis, par exemple pour remplir une colonne de table ou une notification.

Choix du modèle

Le nœud possède un port de service model. Laissé vide, l’appel utilise le modèle par défaut que l’administrateur a choisi pour l’usage « Classer » sur la page Connexions (section Intelligence artificielle) (ou le défaut de l’instance quand cet usage n’en a pas). Branchez un nœud fournisseur comme Anthropic (Claude), OpenAI (GPT) ou Mistral AI sur le port model pour faire tourner ce nœud chez ce fournisseur, avec sa connexion et son modèle. Un seul fournisseur peut être branché sur le port.

Prompt et sécurité

Le champ « Prompt système » porte les consignes générales. Il est prérempli avec un défaut en anglais et se réécrit dans la langue de votre choix. Il n’est pas templatable : les expressions {{ }} n’y sont pas acceptées. Le nœud ajoute lui-même les règles (une catégorie ou plusieurs, que faire quand rien ne convient, le format de sortie) et les consignes de sécurité.

Le contenu du mail, tel que rendu par « Contenu à traiter », n’entre jamais dans le message système. Il part dans un message utilisateur distinct, à l’intérieur d’un bloc délimité, avec la consigne explicite de le traiter comme une donnée et d’ignorer toute instruction qu’il contiendrait. Les balises de délimitation présentes dans le mail sont neutralisées : un mail ne peut pas refermer son propre bloc. La liste des catégories et leurs descriptions partent elles aussi côté utilisateur, car les descriptions sont templatables et peuvent porter du contenu écrit par un tiers.

Le modèle répond par un booléen obligatoire par catégorie (plus un pour le repli) : il ne peut donc pas inventer de catégorie, et les clés inconnues sont ignorées. Les descriptions peuvent être rédigées dans n’importe quelle langue ; le modèle les rapproche du mail par le sens.

Conseils

• Plusieurs catégories. Avec « Plusieurs catégories possibles » coché, plusieurs catégories peuvent être vraies à la fois, mais le mail ne sort que par un seul port : la première catégorie vraie dans l’ordre de déclaration. Lisez les autres dans {{ data.<step>.categories.<category> }} ou {{ data.<step>.matched }} avec une condition en aval.
• Arrêter proprement. Avec le repli « Arrêter proprement », il n’y a pas de port other. Quand rien ne convient, rien ne s’exécute en aval et l’exécution se termine sans erreur ; discarded vaut true.
• Noms de catégories dans les expressions. Les chemins d’expression n’acceptent que des segments faits de lettres non accentuées, de chiffres, de _ et de $. Une catégorie nommée Factures se lit avec {{ data.trier.categories.Factures }}, mais un nom avec espaces ou accents (Demande de devis, Réclamation) n’est pas atteignable ainsi. Le nom du port et category gardent le nom exact dans tous les cas.
• Noms uniques. Deux catégories homonymes, ou un nom vide, sont refusés à la validation du workflow. Au plus 20 catégories sont lues.
• L’ordre compte. Placez les catégories les plus précises en premier : en mode multi-catégories, la première vraie emporte l’aiguillage.
• Mails longs. Le contenu envoyé au modèle est coupé à 20 000 caractères, et le modèle est prévenu que le texte est tronqué.
• Essais. En essai, le modèle est réellement appelé (et sa consommation enregistrée) : vous voyez la catégorie qu’il choisit vraiment. Si l’instance n’a aucun fournisseur d’IA utilisable, la sortie est fabriquée à la place (la première catégorie est vraie), simulated vaut true et le détail d’exécution signale que l’IA a été sautée.
• Erreurs. Aucune catégorie exploitable donne node_invalid_param ; un contenu à traiter vide donne node_nothing_to_do. Une réponse du modèle qui n’est pas un objet JSON donne llm_invalid_output, qui est retentée. Voir Gestion des erreurs.