Architecture pipeline d'enrichissement : passer de 1k à 100k lignes/mois (2026)

La plupart des équipes veulent batch ET temps réel dès le jour 1. Le piège, c'est que la bonne architecture pour chacun est vraiment différente. Le batch-first optimise le throughput et le coût — il traite des dizaines de milliers de records en une passe nocturne, est idempotent par design, et peut retry les lookups failed pendant la nuit sans que personne le remarque. Le real-time-first optimise la latence — il vise du sub-2-secondes sur un record unique, peut pas se permettre de retry, et a besoin de fallbacks degraded-mode quand un provider est lent.

Vous pouvez layer du real-time au-dessus d'un système batch-first (request → si caché, return ; sinon queue + return placeholder). Vous pouvez pas facilement faire l'inverse sans réécrire la logique de queue. Choisissez le mode qui colle à 80% de votre trafic, buildez pour, puis layerez l'autre par-dessus si besoin.

Comment Derrick le gère : notre intégration Sheet est batch-first par défaut (colonnes entières enrichies d'un coup), avec du real-time on-demand dispo via l'API/MCP pour les lookups single-row. Même waterfall, deux pipelines sous le capot.

La première version de chaque script d'enrichissement utilise une boucle for avec `requests.get()` — et ça marche bien, jusqu'à ce que ça marche plus. Le point de rupture est fiable autour de 5 000 records : à ce volume, même avec un provider rapide, vous passez 30+ minutes sur des lookups qui devraient prendre 5 minutes en parallèle. Le script Python bouffe la mémoire parce qu'il garde toutes les réponses en scope, le connection pool s'épuise, et un provider lent bloque tous les autres.

Le fix c'est l'async (asyncio + httpx en Python, ou une worker queue). Mais le piège c'est les rate limits provider. La plupart des API d'enrichissement autorisent 10-50 requêtes concurrentes ; passez au-dessus, vous prenez des 429 par vagues. Pattern réel : async avec un semaphore à 80% de la limite de concurrence documentée du provider, plus exponential backoff sur 429. Ça donne 5-10x de throughput vs sync, tout en restant dans les bonnes grâces du provider.

Comment Derrick le gère : on batche et parallélise les requêtes par provider avec concurrence adaptative — quand les 429 spike, on throttle automatiquement. L'user Sheet voit une seule progress bar, pas les dizaines de worker processes en-dessous.

Le waterfall naïf classe les providers par coût : essaye le moins cher d'abord, descends vers les plus chers seulement si besoin. Ça sonne rationnel. C'est activement mauvais.

La raison : le coût d'enrichissement est pas dominé par le prix per-record — il est dominé par le match rate × la latence × le coût des calls qui échouent. Un provider à 0,02 € avec 25% de match rate vous coûte 0,08 € par match plus 4x la latence d'un provider à 75% à 0,05 € qui l'aurait trouvé du premier coup. Le cheap-first gâche à la fois l'argent et le temps.

La règle correcte : classez les providers par taux de match attendu sur VOS données, avec le coût comme tiebreaker. Faites un benchmark 500 records par provider sur un échantillon représentatif avant de décider de l'ordre. La plupart des équipes découvrent que l'ordre qu'elles auraient deviné est faux d'au moins une position.

Comment Derrick le gère : notre waterfall par défaut est classé par match rate observé sur notre base client, puis ré-optimisé par cluster ICP en arrière-plan. Vous touchez pas l'ordre — le système apprend des résultats.

Chaque pipeline production finit par avoir un provider qui tombe au milieu d'un run. Sans idempotency, ça veut dire re-runer tout le batch — re-payer pour les records qui avaient déjà réussi. Avec idempotency, vous re-runez en sécurité et seuls les records failed sont re-tentés.

L'implem est simple : taggez chaque requête d'enrichissement avec une clé déterministe (ex. `sha256(email + provider + bucket_date)`) et faites en sorte que votre client d'enrichissement check un cache local avant le network call. Les records failed vont dans une retry queue séparée avec exponential backoff (1s, 4s, 16s, 64s, puis dead-letter). Le lundi matin, la dead-letter queue vous dit exactement quels records ont besoin d'attention manuelle.

Les équipes qui skippent ça le découvrent généralement après le troisième « oh non, le script a crashé au record 8 400 — on re-rune tout ? » du samedi soir. Buildez-le en semaine 1, économisez-vous cinquante heures sur l'année.

Comment Derrick le gère : tous les enrichissements sont cachés par (input, provider, fenêtre de fraîcheur) — re-runer un enrichissement sur un Sheet inchangé renvoie instantanément sans re-facturer. Les records failed sont flaggés dans le Sheet et retryables en 1 clic.

Un pipeline que vous pouvez pas mesurer est un pipeline que vous pouvez pas fixer. 3 métriques, trackées sur fenêtres glissantes de 7 jours, vont attraper 95% de ce qui va de travers :

1. Match rate par provider — si un provider chute de plus de 10 points week-over-week, ils ont changé leur sourcing ou vous avez changé votre ICP. Enquêtez avant que la facture s'empile.
2. Latence p95 par provider — la moyenne cache la queue lente qui défonce votre SLO real-time. Trackez le p95, alertez à 2x du baseline.
3. Coût par match vérifié — la vraie unit economics. Si ça monte alors que le match rate est plat, les providers deviennent plus chers ou votre data devient plus dure. Dans tous les cas, faut le savoir.

Ces 3 se plug dans n'importe quel monitoring stack (Datadog, Grafana, même un Sheet refresh nocturne). Les équipes qui avancent à l'aveugle finissent par les redécouvrir après un trimestre de dépassements de coût inexpliqués.

Comment Derrick le gère : ces 3 vivent dans le dashboard in-Sheet, refresh en temps réel pendant que les enrichissements tournent. Pas de monitoring stack à setup, pas d'abo supplémentaire à payer.