EN
Copied
Concepts

Registre des modules

Une source de vérité unique décrit chaque module — ses entrées, sorties, catégorie et son emplacement dans l'UI.

Chaque module exposé par outsend est déclaré dans un registre unique. Il alimente la grille de modules du dashboard, le sélecteur de nouveau job, l'éditeur de pipeline et le listing landing.

Garanties : un module visible au dashboard a un endpoint (et réciproquement) ; un snapshot lisible par machine est publié ; les catégories sont des indices, tandis que slug, needs et produces sont stables.

L'endpoint

GET /api/modules-registry

Renvoie le registre complet en JSON. Chaque entrée :

{
  "slug": "scrap",
  "category": "extraction",
  "label": { "fr": "Scrap Google Maps", "en": "Scrape Google Maps" },
  "needs": null,
  "produces": "poi_list",
  "pipelinable": true,
  "is_on_demand": false,
  "coming_soon": false,
  "api_endpoint": "/api/jobs/scrap"
}
Champ Signification
slug Identifiant stable, utilisé dans URLs et chemins d'API
category extraction | enrichment | intelligence | verification | pipeline | meta
label Libellés d'affichage par langue
needs Forme d'entrée (poi_list, csv_rows, …) — null si produit à partir de rien
produces Forme de sortie
pipelinable Utilisable comme nœud d'un pipeline
is_on_demand Si true, pas de backend — déclenche une conversation avec l'équipe
coming_soon Si true, listé pour visibilité seulement ; intérêt votable
api_endpoint Raccourci pour démarrer un job de ce type

Correspondance souple des entrées

needs et produces décrivent des noms de colonnes canoniques (nom, telephone, site_web, email, lien_google_maps, …). Vous n'avez jamais à formater vos données pour les coller exactement : les entrées sont résolues via une table partagée d'alias acceptés, de sorte que des colonnes nommées Website, url, e-mail, name ou raison sociale sont mappées vers le bon champ canonique. Les fichiers sans en-tête sont détectés automatiquement et les colonnes déduites de leur contenu.

Chaque job le signale en clair. Chaque exécution renvoie une notice non bloquante (bannière d'info sur la page du job, ⓘ discret au dashboard) décrivant ce qui a été auto-mappé, deviné ou ignoré — par exemple les lignes écartées faute de site web. Un job n'échoue que lorsqu'une colonne requise est réellement absente (ex : un enrichissement qui a besoin de site_web ne la trouve sur aucune ligne), et cette erreur nomme explicitement les alias acceptés pour que vous sachiez quel en-tête fournir.

Catégories

Catégorie Rôle Exemples
extraction Produit des données depuis des sources publiques scrap
enrichment Enrichit les lignes existantes avec de nouveaux champs emails, socials, legal_ids
intelligence Calcule des signaux sur les lignes existantes pricing, techstack, ads_intelligence
verification Valide ou score les lignes existantes verify_emails, delivery_check
pipeline Utilitaires d'orchestration import, filter, sort
meta N'est pas un job — décrit pipelines ou veilles (aucun endpoint API)

Cycle de vie d'un module

  1. Coming soon — landing uniquement, pas de backend, intérêt votable
  2. On-demand — listé au dashboard, le CTA ouvre une conversation, exécuté manuellement
  3. Active — entièrement supporté par un endpoint
  4. Disponible (gelé en alpha) — construit et présenté comme un module actif sur toutes les surfaces, mais non lançable pendant l'alpha : l'UI affiche un bandeau maintenance avec bouton « Lancer » désactivé, et l'endpoint de création renvoie 503. Contrairement à coming soon, ce n'est pas un placeholder et il ne porte pas de vote d'intérêt — c'est un module fini, retenu uniquement par la capacité serveur de l'alpha.
  5. Deprecated — toujours appelable mais signalé

Les changements de phase apparaissent dans le registre via coming_soon, is_on_demand, alpha_unavailable et deprecated_at.

Ajouter un module (contributeurs)

Ajouter un module = 2 fichiers dans le codebase : une entrée registre JS (surfaces UI) et une entrée registre Python (API + dispatcher worker). Le runtime branche ensuite le module partout automatiquement.

La suite