Import

Objectif

Le module import introduit des données externes dans outsend en tant que source de pipeline. Il est interne au pipeline — voir /docs/fr/concepts/pipeline-orchestration — et produit une liste de POI normalisée que les nœuds d'enrichissement, de vérification ou de traitement en aval peuvent consommer. Contrairement à scrap, import ne consomme aucun quota d'extraction (coût EF nul).

Entrées

La configuration du nœud expose un seul discriminateur, source, avec trois modes mutuellement exclusifs.

paste — CSV en ligne

La charge utile text est parsée comme CSV par la couche de résolution partagée (app/column_map.py). Le délimiteur est auto-détecté (virgule, point-virgule ou tabulation) ; UTF-8 est attendu, avec UTF-8 BOM et Latin-1 / cp1252 acceptés en repli. Les en-têtes ne sont pas obligatoires : les noms de colonnes sont reconnus de façon souple via des alias acceptés (un en-tête Website, url, e-mail ou raison sociale est mappé vers la bonne colonne canonique), et un fichier sans en-tête est auto-détecté — ses colonnes sont alors déduites de leur contenu. Dans tous les cas l'import émet une notice (bannière d'info sur la page du job, ⓘ au dashboard) indiquant ce qui a été auto-mappé, déduit ou ignoré, pour que le mapping ne soit jamais silencieux.

url — tableur public

La charge utile url pointe vers un tableur lisible publiquement (forme typique : https://docs.google.com/spreadsheets/d/.../edit#gid=0). La feuille doit être partagée en « toute personne ayant le lien peut consulter » — outsend ne s'authentifie pas auprès de fournisseurs tiers. Le contenu récupéré est parsé selon les mêmes règles CSV que paste.

from_job — réutilisation d'un scrap récent

La charge utile from_job_id référence un job scrap antérieur. La référence est validée côté serveur à la création du job :

Lorsque la validation passe, l'import résultant hérite de toutes les colonnes produites par le scrap source.

Sorties

import produit une liste de POI normalisée, déclarée dans le registre du pipeline avec output: "pois" — la même forme que celle émise par scrap. Les nœuds en aval qui acceptent pois_any (reviews, emails, socials, dead-check, techstack, ads-intelligence, brand-assets) s'enchaînent directement. Les nœuds qui exigent pois_email (verify) ne s'enchaînent que si le CSV importé porte déjà une colonne email.

L'ensemble de colonnes est dynamique : il reflète ce que fournit la source. Le registre déclare needs: [] et produces: [] pour cette raison — le module est permissif en entrée et propage le schéma d'entrée en sortie.

Cycle de vie

Cycle de vie de job standard — voir /docs/fr/concepts/jobs-lifecycle. Le job est rattaché à son pipeline via pipeline_id et pipeline_node_id et s'exécute dès que le pipeline passe à running.

Pipeline

import est un nœud racine. Il n'accepte aucun arc amont. Tout nœud dont l'input est pois_any, any_pois ou pois_email (quand le CSV porte des emails) peut être câblé en aval.

Registre : needs: [], produces: [].

Endpoints

Le module import n'est pas exposé comme endpoint de job autonome — il est interne au pipeline (voir /docs/fr/concepts/pipeline-orchestration) et créé uniquement comme racine de pipeline. Deux endpoints adjacents sont utiles lors de l'assemblage d'un import :

La charge utile du nœud de pipeline suit cette forme :

{
  "type": "import",
  "config": {
    "source": "paste",
    "text": "nom,site_web\n...",
    "url": "",
    "from_job_id": ""
  }
}

Exactement un parmi text, url, from_job_id est lu, déterminé par source. Les champs inutilisés sont persistés sous forme de chaînes vides.

Limites

Limites globales — voir /docs/fr/concepts/limits. Spécifiques au module :

Erreurs

Et après