Utiliser l'API Veille dans une entreprise autonome Paperclip

Paperclip est une plateforme open-source pour faire tourner des entreprises autonomes pilotées par des IA. Vous définissez un objectif, recrutez des agents - Claude, Codex, OpenClaw ou n'importe quel bot compatible HTTP - organisez-les dans un org chart, et les laissez travailler. Les heartbeats réveillent les agents selon un calendrier. Les tickets tracent chaque décision. Les budgets limitent ce que chaque agent peut dépenser.

Quand ces agents touchent des données utilisateurs - inscriptions, leads, paiements, prospection - ils doivent valider ce qu'ils reçoivent. Un workflow de qualification de leads piloté par une IA qui traite des emails non vérifiés ne produira que du bruit. Un agent de facturation qui accepte des IBAN sans les vérifier génèrera des transactions échouées. Une automatisation d'inscription qui ignore les adresses email jetables gonfle vos métriques de conversion avec de faux comptes.

Cet article montre comment connecter l'API Veille aux agents Paperclip pour ajouter des contrôles de qualité des données à chaque étape d'une entreprise autonome.

Où Veille s'intègre dans une entreprise Paperclip

Veille fournit quatre endpoints de validation :

Endpoint	Ce qu'il valide
`GET /v1/intelligence/email`	Détection des adresses jetables, score de risque, vérification SMTP
`GET /v1/intelligence/domain`	Âge du domaine, DNS, signaux de menace
`GET /v1/intelligence/ip`	VPN/proxy/Tor, score de menace, géolocalisation
`GET /v1/vat/iban`	Validité de l'IBAN, BIC, nom de la banque, appartenance à la zone SEPA

Chaque endpoint accepte un seul paramètre de requête et retourne une réponse JSON structurée. Tout agent Paperclip capable de faire une requête HTTP GET - y compris le type d'agent HTTP intégré - peut les appeler directement.

Le schéma le plus naturel est un Agent de Qualité des Données dédié, placé entre les entrées brutes (soumissions de formulaires, imports CRM, événements webhook) et les agents qui agissent sur ces données (prospection, facturation, provisionnement). Voyez-le comme une couche de filtrage dans votre org chart.

Cas d'usage 1 - Qualification de leads

Scénario : Votre agent CMO pilote des campagnes sortantes. Les leads arrivent via des formulaires, des fichiers CSV importés ou des intégrations tierces. Avant de transmettre un lead à l'agent de prospection, un contrôle de qualité des données élimine les adresses qui ne convertiront jamais.

Position dans l'org chart : Entre l'étape d'import CRM et l'agent de prospection.

Appels Veille :

GET /v1/intelligence/email?query={{email}} - vérifier disposable et risk_score
GET /v1/intelligence/domain?query={{domain}} - vérifier domain_age_days pour les domaines récemment enregistrés

Logique de décision :

IF email.disposable == true        → rejeter le lead
IF email.risk_score >= 75          → rejeter le lead
IF domain.domain_age_days < 30     → signaler pour révision manuelle
ELSE                               → transmettre à l'agent de prospection

Config heartbeat : Exécutez le contrôle comme un heartbeat sur l'Agent de Qualité des Données à chaque arrivée de nouveaux leads, ou selon un calendrier (toutes les 4 heures, chaque nuit avant que le batch de prospection se lance).

Flux de tickets :

[Agent d'Import CRM]
  crée un ticket → "Nouveau batch de leads : 240 entrées"
        ↓
[Agent de Qualité des Données]
  valide chaque email via l'API Veille
  crée un ticket → "Batch nettoyé : 198 retenus, 42 rejetés"
        ↓
[Agent de Prospection]
  traite 198 leads vérifiés

Un seul ticket Paperclip enregistre chaque appel à l'API Veille et son résultat. Le journal d'audit montre exactement quel lead a été rejeté et pourquoi - disposable: true, risk_score: 91, ou domain_age_days: 3.

Cas d'usage 2 - Détection de fraude à l'inscription

Scénario : Votre plateforme offre un essai gratuit. Un agent d'automatisation des inscriptions provisionne les nouveaux comptes. Sans étape de validation, les emails jetables et les IP via VPN peuvent créer un nombre illimité de faux comptes, épuiser les ressources d'essai et fausser les métriques d'activation.

Position dans l'org chart : Entre le récepteur de webhooks et l'agent de provisionnement.

Appels Veille :

GET /v1/intelligence/email?query={{email}} - vérifier disposable, risk_score, smtp_valid
GET /v1/intelligence/ip?query={{ip}} - vérifier is_vpn, is_proxy, threat_score

Logique de score composite :

composite = (
    email["risk_score"] * 0.60
    + ip["threat_score"] * 0.40
)

if email["disposable"] or composite >= 75:
    action = "reject"
elif composite >= 50:
    action = "flag_for_review"
else:
    action = "provision"

Cette logique s'exécute à l'intérieur de l'Agent de Qualité des Données avant qu'un ticket de provisionnement soit créé. L'agent poste le résultat en commentaire de ticket avec la réponse complète de l'API jointe pour la traçabilité.

Pour un guide complet de ce schéma de détection, voir Bloquer les emails jetables dans OpenClaw - les mêmes endpoints Veille fonctionnent dans n'importe quel agent capable d'HTTP, y compris OpenClaw dans Paperclip.

Cas d'usage 3 - Validation financière

Scénario : Votre agent de facturation ou de paiement traite des IBAN et des numéros de TVA lors de l'onboarding B2B. Les IBAN invalides provoquent des virements échoués. Les numéros de TVA inactifs créent des problèmes de conformité fiscale.

Position dans l'org chart : L'agent de facturation appelle Veille directement avant d'écrire les données de paiement.

Appels Veille :

GET /v1/vat/iban?query={{iban}} - vérifier valid, in_sepa_zone, bank_name
GET /v1/vat?query={{vat_number}} - vérifier valid, company_name, country_code

Logique de décision :

IF iban.valid == false               → rejeter la configuration de paiement, notifier le COO
IF iban.in_sepa_zone == false        → signaler : virement non-SEPA nécessite une approbation manuelle
IF vat.valid == false                → appliquer le taux de TVA local, ne pas appliquer l'autoliquidation
IF vat.country_code != customer.country → signaler pour révision de conformité
ELSE                                 → procéder à l'onboarding

Exemple de ticket :

#1087 - Onboard new customer: Acme GmbH
Billing Agent - In Progress

IBAN: DE89370400440532013000
  → valid: true, in_sepa_zone: true, bank_name: Commerzbank

VAT: DE123456789
  → valid: true, company_name: Acme GmbH, country_code: DE

Result: onboarding approved, reverse charge applied.

Chaque résultat de validation fait partie du fil de tickets et du journal d'audit immuable. Si un contrôle de conformité nécessite un jour la preuve qu'un numéro de TVA était actif au moment de l'onboarding, la donnée est là.

Mise en place de l'agent HTTP

Paperclip prend en charge tout agent capable de recevoir un heartbeat. Pour les appels à l'API Veille, la configuration la plus simple utilise un agent Bash ou HTTP.

SKILLS.md pour l'Agent de Qualité des Données :

# Data Quality Agent

## Role
Validate email addresses, IP addresses, and financial identifiers before
they are passed to other agents in the org.

## Veille API
Base URL: https://api.veille.io/v1
Authentication: x-api-key header (use the VEILLE_API_KEY environment variable)

## Endpoints available
- Email validation: GET /v1/intelligence/email?query={email}
- Domain validation: GET /v1/intelligence/domain?query={domain}
- IP validation: GET /v1/intelligence/ip?query={ip}
- IBAN validation: GET /v1/vat/iban?query={iban}
- VAT validation: GET /v1/vat?query={vat_number}

## Decision thresholds
- email.disposable == true → discard
- email.risk_score >= 75 → discard
- email.risk_score 50–74 → flag for review
- ip.is_vpn or ip.is_proxy → flag for review
- ip.threat_score >= 75 → discard
- iban.valid == false → reject
- vat.valid == false → do not apply reverse charge

## Output
Post results as a ticket comment with the full API response.
Create a summary line: "Validated: {result} - {reason}".

Exemple d'appel d'agent Bash :

#!/bin/bash
# Run by the Data Quality Agent on heartbeat

EMAIL=$1
API_KEY=$VEILLE_API_KEY

response=$(curl -s \
  "https://api.veille.io/v1/intelligence/email?query=${EMAIL}" \
  -H "x-api-key: ${API_KEY}")

disposable=$(echo "$response" | jq -r '.disposable')
risk_score=$(echo "$response" | jq -r '.risk_score')

if [ "$disposable" = "true" ] || [ "$risk_score" -ge 75 ]; then
  echo "REJECT: disposable=${disposable}, risk_score=${risk_score}"
  exit 1
else
  echo "PASS: risk_score=${risk_score}"
  exit 0
fi

Le code de sortie indique à Paperclip s'il faut continuer le workflow (0) ou s'arrêter et créer un ticket de révision (1).

Schéma d'org chart

Une entreprise Paperclip qui utilise la validation Veille dans plusieurs workflows pourrait ressembler à ceci :

CEO (Claude)
├── CMO (OpenClaw)
│   ├── Lead Import Agent
│   └── Outreach Agent
├── CTO (Cursor)
│   ├── Data Quality Agent ← calls Veille API
│   └── Provisioning Agent
└── CFO (Claude)
    └── Billing Agent ← calls Veille IBAN/VAT

L'Agent de Qualité des Données sert plusieurs équipes : il valide les leads pour le pipeline de prospection du CMO et valide les inscriptions pour le flux de provisionnement du CTO. Un seul agent, une seule ligne budgétaire, une logique de validation centralisée.

Visibilité des coûts

Paperclip suit le coût par agent. Les appels à l'API Veille ont un coût prévisible par requête, vous pouvez donc estimer le budget mensuel de l'Agent de Qualité des Données en fonction du volume attendu.

Par exemple, si votre plateforme traite 10 000 inscriptions par mois et que vous appelez deux endpoints Veille par inscription (email + IP), vous savez exactement combien de requêtes API prévoir dans le budget. Définissez la limite de dépenses mensuelles de l'agent dans Paperclip en conséquence. Quand l'agent atteint la limite, il s'arrête automatiquement - pas de dépassement.

Utiliser l'API Veille dans une entreprise autonome Paperclip

Où Veille s'intègre dans une entreprise Paperclip

Cas d'usage 1 - Qualification de leads

Cas d'usage 2 - Détection de fraude à l'inscription

Cas d'usage 3 - Validation financière

Mise en place de l'agent HTTP

Schéma d'org chart

Visibilité des coûts

Articles connexes

Articles similaires

Liste des domaines emails jetables : comment les bloquer

Bloquer les emails jetables dans OpenClaw

Comment on a construit un dataset anti-emails jetables