Data Engineering : architectures modernes pour l'intégration des LLM en production

Pourquoi les architectures ETL classiques ne suffisent plus

Un pipeline ETL classique (Extract-Transform-Load) repose sur trois postulats qui volent en éclats avec les LLM.

Postulat 1 : la transformation est déterministe

Avec SQL ou Python, 2 + 2 donne toujours 4. Un LLM peut donner 4, le résultat est 4, quatre ou parfois je ne sais pas selon la température et le prompt. L’architecture doit tolérer une certaine variance.

Postulat 2 : la latence est prévisible

Une transformation Spark sur 1 million de lignes prendra 12 minutes, plus ou moins 10 %. Un appel LLM peut prendre 200 ms comme 8 secondes, selon la charge du fournisseur, la longueur du contexte et la complexité de la génération.

Postulat 3 : le coût est lié au calcul, pas aux données

Dans l’ETL classique, le coût dépend du temps CPU/GPU. Avec les LLM, le coût dépend du volume de tokens — qui varie selon la longueur des documents d’entrée et la verbosité des réponses. Une même requête peut coûter 5x plus cher si le LLM décide de développer sa réponse.

Les trois patterns d’architecture LLM en production

Trois patterns architecturaux dominent les déploiements 2026. Le choix dépend de votre contrainte principale.

Pattern 1 : Batch processing asynchrone (volume)

Cas d’usage : scorer 10 millions de commentaires clients une fois par nuit.

Architecture :

• Source : BigQuery / Cloud Storage (documents stockés)
• Orchestrateur : Cloud Composer (Airflow) qui déclenche un job Dataflow
• Traitement : Dataflow Beam lit les documents, les découpe en batches, appelle l’API Vertex AI (LLM) de manière asynchrone via des requêtes parallélisées contrôlées
• Sink : résultats réécrits dans BigQuery

Contrôle de flux : utilisez rated_requests sur l’API LLM pour ne pas dépasser les quotas. Pour Gemini, la limite par défaut est 300 requêtes par minute. Au-delà, implémentez une file d’attente interne.

import apache_beam as beam
from apache_beam.utils.retry import with_retry

class CallLLMDoFn(beam.DoFn):
    def __init__(self, project_id, location, model_name):
        self.project_id = project_id
        self.location = location
        self.model_name = model_name
        self.client = None

    def start_bundle(self):
        from google.cloud import aiplatform
        aiplatform.init(project=self.project_id, location=self.location)
        self.client = aiplatform.gapic.PredictionServiceClient()

    @with_retry(max_retries=3, backoff_factor=2.0)
    def process(self, element):
        # Implémenter un rate limiter (ex: token bucket)
        response = self.client.predict(
            endpoint=f"projects/{self.project_id}/locations/{self.location}/publishers/google/models/{self.model_name}",
            instances=[{"content": element['text']}]
        )
        return [{'id': element['id'], 'prediction': response.predictions[0]}]

Pattern 2 : Streaming événementiel (latence)

Cas d’usage : analyser en quasi-temps réel des conversations de support client.

Architecture :

• Source : Pub/Sub (messages entrants)
• Processor : Dataflow streaming, fenêtrage fixe de 5 secondes, agrégation, appel LLM sur la fenêtre
• Sink : résultat vers BigQuery (analyse historique) + Pub/Sub (alerte si détection d’insatisfaction)

Spécificités : l’état (state) de Dataflow est crucial pour agréger les messages avant appel LLM. Utilisez beam.WindowInto(FixedWindows(5)) et beam.CombineGlobally().

Pattern 3 : Workflow agentique (complexité)

Cas d’usage : assistant IA qui doit interroger une base SQL, appeler une API métier, puis synthétiser.

Architecture : le LLM orchestrate lui-même les appels via un framework agentique (LangChain, Semantic Kernel, Vertex AI Agent Builder). Le pipeline de données devient dynamique : le chemin d’exécution dépend des décisions du LLM.

Piège fréquent : ne pas mettre de garde-fous (guardrails). Un agent peut boucler indéfiniment ou appeler une API de suppression en production. Implémentez un maximum d’étapes et des validateurs de sécurité.

Orchestration : Airflow, Dataflow, ou les deux ?

La question récurrente : “Dois-je utiliser Airflow (Cloud Composer) ou Beam (Dataflow) pour mon pipeline LLM ?”

Réponse : les deux, mais pas pour les mêmes tâches.

Pour les workflows agentiques, ni Airflow ni Dataflow ne sont adaptés (trop rigides). Utilisez plutôt un framework agentique (LangChain, Semantic Kernel) déployé sur Cloud Run ou Vertex AI, avec Airflow pour orchestrer les traitements batch périphériques (ex. réindexation vectorielle hebdomadaire).

Implémentation détaillée sur Google Cloud

Prenons un cas réel : pipeline de classification automatique de tickets support en 5 catégories, avec 500 000 tickets par jour.

Composants

1. Source : Cloud Storage (fichiers JSON bruts) et BigQuery (table tickets_raw)
2. Orchestrateur : Cloud Composer (Airflow) — DAG déclenché toutes les 2 heures
3. Prétraitement : Dataflow job Beam — nettoie et tokenize les textes
4. Appel LLM : Vertex AI (Gemini 1.5 Flash, le modèle plus léger/rapide pour ce cas)
5. Post-traitement : Dataflow job Beam — parse les réponses JSON du LLM
6. Sink : BigQuery — tables tickets_classified et llm_traces

Extrait du DAG Airflow (Cloud Composer 3)

from airflow import DAG
from airflow.providers.google.cloud.operators.dataflow import DataflowStartFlexTemplateOperator
from airflow.providers.google.cloud.operators.bigquery import BigQueryInsertJobOperator
from airflow.providers.google.cloud.sensors.dataflow import DataflowJobStatusSensor

with DAG('llm_classification_pipeline', schedule='0 */2 * * *') as dag:
    
    preprocess = DataflowStartFlexTemplateOperator(
        task_id='preprocess_texts',
        location='europe-west1',
        project_id='iana-data',
        body={
            'launch_parameter': {
                'jobName': 'preprocess-tickets',
                'containerSpecGcsPath': 'gs://dataflow-templates/preprocess.json',
                'parameters': {
                    'input_table': 'iana-data.tickets.raw',
                    'output_gcs': 'gs://temp/tickets_clean/'
                }
            }
        }
    )
    
    wait_preprocess = DataflowJobStatusSensor(
        task_id='wait_preprocess',
        job_id="{{ task_instance.xcom_pull('preprocess')['job_id'] }}"
    )
    
    call_llm = DataflowStartFlexTemplateOperator(
        task_id='call_llm_batch',
        body={
            'launch_parameter': {
                'jobName': 'llm-inference-tickets',
                'parameters': {
                    'input_gcs': 'gs://temp/tickets_clean/',
                    'model': 'gemini-1.5-flash',
                    'project_id': 'iana-data'
                }
            }
        }
    )
    
    # Et ainsi de suite...

Gestion des erreurs et retry

Les LLM échouent de manière non déterministe (timeout, rate limit, réponse mal formée). Votre pipeline doit en tenir compte.

class LLMCallWithDLQ(beam.DoFn):
    def process(self, element):
        try:
            result = call_llm(element['text'])
            yield beam.TaggedOutput('success', {'id': element['id'], 'result': result})
        except Exception as e:
            yield beam.TaggedOutput('dead_letter', {'id': element['id'], 'error': str(e)})

Les échecs alimentent une table BigQuery dead_letter_queue pour reprise manuelle ou automatique.

Gestion des coûts : caching, batching et sélection de modèle

La facture LLM peut exploser si vous ne maîtrisez pas le volume de tokens.

Stratégie 1 : Cache sémantique vectoriel

De nombreuses requêtes sont similaires. Au lieu d’appeler le LLM, interrogez une base vectorielle (Vertex AI Vector Search, Pinecone, pgvector) pour vérifier si une question équivalente a déjà reçu une réponse.

Résultat : réduction de 40 à 70 % des appels pour les cas récurrents.

Stratégie 2 : Batching intelligent

Les LLM ont des coûts fixes par appel + coût variable par token. Grouper 10 petits documents en un seul appel peut diviser le coût par 3.

Attention : la latence augmente (le LLM doit traiter plus de tokens). Un compromis : batches de 3 à 5 documents.

Stratégie 3 : Sélection dynamique du modèle

Pour 80 % des requêtes simples (ex. classification en 3 classes), utilisez un petit modèle (Gemini 1.5 Flash, GPT-4o mini). Pour les 20 % de requêtes complexes (raisonnement multi-étapes), basculez sur un gros modèle (Gemini 3.1 Pro, Claude 4.5 Sonnet).

Implémentation : un classifieur simple (par regex ou petit modèle) décide du modèle à utiliser.

Exemple de calcul de coût

Pour 500 000 tickets, avec un texte moyen de 500 tokens input et une réponse de 50 tokens output, via Gemini 1.5 Flash ($0.0375/M input, $0.15/M output) :

• Input : 500 × 500 000 = 250M tokens → coût : 250 × $0.0375 = $9.375
• Output : 50 × 500 000 = 25M tokens → coût : 25 × $0.15 = $3.75
• Total brut : ~$13.125 par 500k tickets

Avec un cache vectoriel à 60 % : $5.25 pour la même charge. Le coût marginal par ticket tombe à ~$0.00001.

Monitoring : la dérive des LLM est multidimensionnelle

Un modèle classique dérive sur la distribution des features ou la cible. Un LLM dérive sur quatre dimensions.

Dimension 1 : Dérive lexicale (distribution des tokens)

Les tokens (sous-mots) que le LLM génère peuvent changer dans le temps — sans que le sens s’altère nécessairement. Un pipeline robuste suit l’évolution de la fréquence des tokens.

Dimension 2 : Dérive sémantique

La similarité cosinus entre les embeddings de réponses sur des requêtes stables (ex. “Expliquez ce qu’est une dérive de concept”) ne doit pas chuter sous 0.85.

Dimension 3 : Dérive comportementale (latence et refus)

Suivez la latence p95 et le taux de refus (“Je ne peux pas répondre”). Une hausse peut indiquer un durcissement des garde-fous du fournisseur.

Dimension 4 : Dérive métier (hallucinations)

Sur un sous-ensemble de données annotées (200 exemples par semaine), mesurez le taux d’hallucination (affirmation non présente dans le contexte).

Implémentation sur Vertex AI Model Monitoring

Vertex AI permet de configurer des seuils d’alerte sur les dérives de features. Pour les LLM, utilisez des feature attributions spécifiques : longueur de la réponse, score de logit moyen, entropie de la distribution des tokens.

Sécurité et conformité : traçabilité et secrets

Gestion des secrets

Ne faites jamais :

# À ne PAS faire !
API_KEY = "AIzaSyD..."

Faites plutôt :

from google.cloud import secretmanager

def get_secret(secret_id):
    client = secretmanager.SecretManagerServiceClient()
    response = client.access_secret_version(name=secret_id)
    return response.payload.data.decode('UTF-8')

Injectez l’identité via Workload Identity (GKE, Cloud Run, Composer) ou les métadonnances d’instance (Compute Engine, Dataflow).

Traçabilité des appels

Pour chaque appel LLM, enregistrez dans une table llm_audit_log :

• request_id (uuid)
• user_id ou pipeline_name
• input_tokens, output_tokens, latency_ms
• model_name et model_version
• response (tronquée si PII)
• cost_estimate
• timestamp

Cette table servira pour la facturation interne, le debugging et les audits réglementaires (RGPD, AI Act).

Pour approfondir les enjeux de gouvernance des données, l’article sur la protection des données personnelles dans les pipelines IA complète ces aspects techniques.

Cas concret : pipeline de scoring de tickets support

Mettons en pratique l’ensemble des concepts avec un exemple réel.

Contexte

Une plateforme SaaS reçoit 500 000 tickets support par mois. Objectif : classifier automatiquement en 5 catégories (Facturation, Technique, Compte, Produit, Autre) avec une fiabilité > 85 %, et extraire le sentiment (positif/négatif/neutre).

Architecture retenue

• Ingestion : tickets entrants vers Pub/Sub
• Streaming : Dataflow job fenêtré (fenêtre de 5 minutes) pour prétraitement et appel Gemini 1.5 Flash
• Batch hebdomadaire : Airflow déclenche un job d’évaluation sur un échantillon de 1000 tickets annotés manuellement
• Stockage : BigQuery (tables tickets_predictions, llm_audit_log, drift_metrics)
• Monitoring : Vertex AI Model Monitoring + alertes Pub/Sub vers Slack

Résultats après 3 mois

Leçons apprises

1. Commencer avec le modèle le plus rapide : Gemini 1.5 Flash a suffi pour 80 % des cas. Les modèles “Pro” sont réservés aux 20 % restants via un routeur.
2. Le cache vectoriel a été la clé : 58 % de taux de hit après 2 semaines, divisant les coûts par 2,4.
3. La dead letter queue est indispensable : 0,3 % des appels échouent pour des raisons variées (timeout, malformé). Sans DLQ, ces tickets étaient perdus.

Articles connexes

Pour approfondir les sujets abordés dans cet article :