Classification de texte dans Airtable : étiqueter les enregistrements automatiquement avec une automatisation Run a script et Jev

Les bases Airtable accumulent souvent du texte libre que quelqu’un trie à la main : réponses de formulaires, demandes clients, retours, candidatures à un programme, idées de contenu. Classer, c’est lire le texte d’un champ de texte long et remplir une catégorie issue d’une liste courte et fixe, pour que vues, filtres et automatisation suivante fonctionnent sans qu’une personne lise d’abord chaque ligne. Une table pratique compte quatre champs : le texte source (Long text), Category (sélection unique dont les options correspondent exactement à vos ID de labels, par exemple billing, bug, feature_request, other), Confidence (nombre à deux décimales) et Needs review (case à cocher). Gardez une liste courte et exclusive, avec toujours other, pour que le modèle ait une issue honnête quand rien ne convient. Si l’urgence compte aussi, posez-la à part en oui/non au lieu d’ajouter urgent à la liste ; les mélanger dégrade les deux réponses. Ce guide traite une catégorie par enregistrement. Si un enregistrement peut relever de plusieurs catégories, utilisez un champ à sélection multiple et lisez d’abord le guide multi-label.

Cinq étapes. 1) Créez les quatre champs ci-dessus et ajoutez chaque ID de label comme option de sélection unique avant la première exécution ; le script écrit l’option par son nom, les noms doivent donc correspondre. 2) Dans Automations, créez une automatisation avec le déclencheur « When a record matches conditions » et deux conditions : le champ texte n’est pas vide et Category est vide. Elle se déclenche quand un enregistrement entre dans cet état, par exemple à l’arrivée d’une réponse de formulaire, et écrire Category fait sortir l’enregistrement de la condition : l’automatisation ne boucle pas sur sa propre mise à jour. 3) Ajoutez l’action « Run a script ». Dans le panneau des variables d’entrée, ajoutez recordId associé à l’ID d’enregistrement Airtable du déclencheur et text associé au champ texte. 4) Créez une clé API JevModel dans Console → API keys avec un compte à e-mail vérifié, et ajoutez-la dans l’onglet Secrets de l’éditeur sous JEVMODEL_API_KEY ; le script la lit avec input.secret("JEVMODEL_API_KEY"). Airtable réserve la modification des scripts utilisant des secrets aux personnes qui y ont accès et masque les secrets dans la sortie console. 5) Testez l’action sur un enregistrement d’exemple, consultez l’historique et le journal d’exécution, puis activez l’automatisation. Un appel Jev en échec doit laisser Category vide et cocher Needs review, pour qu’une erreur passagère n’étiquette jamais mal un enregistrement.

Côté Airtable, le centre d’aide liste les limites de l’action Run a script : un délai de script documenté à 30 secondes (porté temporairement à 120 secondes au moment de la rédaction), 30 secondes par fetch, 12 secondes pour les appels à l’API de scripting, 512 Mo de mémoire, 50 requêtes fetch et 30 requêtes selectRecords par exécution, et jusqu’à 15 mutations par seconde, chacune portant sur 50 enregistrements au plus. L’action existe sur tous les plans avec des limites variables, mais pas pendant un essai du plan Team. Un enregistrement par exécution, comme dans l’exemple, reste très en deçà. Côté JevModel, la requête entière (state plus questions) doit tenir en 8 000 caractères : coupez le texte long avant l’envoi ; l’exemple garde les 6 000 premiers caractères. Une requête pose de 1 à 8 questions ; un Choice a de 2 à 12 options dont les ID commencent par une minuscule et n’utilisent que minuscules, chiffres et tirets bas, et un Score a de 2 à 10 niveaux ordonnés. Il n’y a ni champ model ni clé d’idempotence : relancer l’automatisation sur un enregistrement crée une nouvelle requête, facturée à nouveau. Les exécutions en échec sont remboursées. Chaque enregistrement étiqueté est une requête API ordinaire facturée en tokens sur votre solde ; les comptes vérifiés démarrent avec 100 000 tokens offerts, et les packs payants figurent sur la page des tarifs.

Les trois envoient la même question Jev ; elles diffèrent par l’endroit où vit la logique et la façon dont les résultats reviennent dans la base. Le tableau compare la forme du flux, pas la précision, et aucune ligne n’est un benchmark.

Collez le script dans l’action Run a script et renommez table, champs et définitions de labels selon votre base. La requête suit le contrat documenté de JevModel : POST /api/v1/systemone avec une clé Bearer d’un compte vérifié, un state et des questions nommées, ici un Choice nommé category ; une réponse réussie a code 0 et data.answers. Pas de champ model, car le site appelle toujours typesafe/jev-1.13 via OpenRouter ; JevModel est indépendant de TypeSafe AI, qui développe Jev. Le script n’envoie que le texte, ni noms, ni e-mails, ni autres colonnes. Une valeur de sélection unique s’écrit comme un objet avec name, et l’option doit déjà exister dans le champ. Les enregistrements sous le seuil d’exemple, ceux étiquetés other et les appels en échec reçoivent Needs review : une vue filtrée sur cette case devient la file humaine. 0,7 est une valeur d’attente ; fixez votre seuil sur un échantillon étiqueté.

// Illustrative only. Airtable automation → "Run a script" action.
// Input variables: recordId (Airtable record ID from the trigger), text (the long-text field).
// Secret: JEVMODEL_API_KEY (Secrets tab in the script editor).
// Fields: Category (single select), Confidence (number), Needs review (checkbox).
const { recordId, text } = input.config();
const table = base.getTable("Requests");

const res = await fetch("https://jevmodel.app/api/v1/systemone", {
  method: "POST",
  headers: {
    Authorization: "Bearer " + input.secret("JEVMODEL_API_KEY"),
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    // The whole request must stay within 8,000 characters.
    state: { text: String(text || "").slice(0, 6000) },
    questions: {
      category: {
        type: "choice",
        instructions: "Which team should handle this request submitted through our form?",
        criteria: {
          billing: "Invoices, payments, refunds, or plan changes.",
          bug: "Something is broken, shows an error, or behaves unexpectedly.",
          feature_request: "Asks for something the product does not do yet.",
          other: "Anything that fits none of the labels above.",
        },
      },
    },
  }),
});
const out = await res.json();

if (out.code !== 0) {
  // Leave Category empty and hand the record to a person.
  await table.updateRecordAsync(recordId, { "Needs review": true });
  console.log("Jev call failed: " + out.message);
} else {
  const { choice, probabilities } = out.data.answers.category;
  const p = probabilities ? probabilities[choice] : 0;
  await table.updateRecordAsync(recordId, {
    Category: { name: choice }, // the option must already exist in the field
    Confidence: p,
    "Needs review": p < 0.7 || choice === "other", // 0.7 is a placeholder
  });
}

Commencez par des enregistrements dont une personne connaît déjà la catégorie. Exportez-en quelques centaines en CSV avec le texte et le label humain, envoyez le texte dans JevModel Console → Batch avec la même question Choice et exportez les réponses par ligne. Comparez ensuite les deux colonnes par label dans un tableur ; Batch ne calcule pas la précision pour vous. Regardez quelles paires sont confondues et comment l’accord évolue quand vous montez le seuil de probabilité, réécrivez les définitions floues et relancez le même échantillon avant d’activer l’automatisation. Ce même chemin CSV est le plus simple pour étiqueter l’existant : l’automatisation ne se déclenche que pour les enregistrements qui se mettent à remplir ses conditions, et un script qui parcourt beaucoup d’enregistrements en une exécution atteint vite la limite de 50 fetch. Après le lancement, gardez une vue filtrée sur Needs review et triée par Confidence, et vérifiez chaque semaine la part de other ; une part croissante signifie que la liste ne correspond plus à ce que les gens envoient. Ne laissez aucun label supprimer, masquer ou envoyer d’e-mail avant d’avoir mesuré sa fréquence d’erreur, et laissez le champ modifiable pour les corrections.

Choisissez l’action Run a script quand le travail se fait dans la base, que vous pouvez modifier un court script et que votre plan inclut l’action. Choisissez un outil no-code s’il exécute déjà vos autres automatisations ou si le même texte doit aussi partir vers Slack, l’e-mail ou un CRM ; les guides Zapier, Make, n8n, Power Automate et Pipedream montrent la même requête Jev dans chaque outil. Choisissez CSV puis Console → Batch pour un rattrapage ponctuel ou pour tester les définitions avant toute automatisation. Si vos données sont dans Google Sheets plutôt qu’Airtable, le guide Google Sheets décrit le même schéma avec Apps Script. Checklist commune : 1) définitions de labels avec un other explicite ; 2) urgence dans une question oui/non séparée ; 3) n’envoyer que le texte, coupé sous la limite de 8 000 caractères par requête ; 4) laisser la catégorie vide et signaler l’enregistrement en cas d’échec ; 5) commencer par les labels et une vue de revue, puis ajouter des actions en aval après avoir mesuré l’accord sur un échantillon étiqueté. JevModel est limité au texte et n’est pas open source ; pièces jointes, images et audio dans Airtable ne sont pas classés par ce montage.