Automatiser un pipeline complet avec un agent
Vous avez un agent IA qui répond à des questions. C'est bien. Mais le vrai pouvoir des agents, c'est de les mettre au travail sur des pipelines de production complets — des chaînes d'opérations qui transforment une idée brute en livrable final, automatiquement, sans intervention humaine.
Dans cet article, on construit ensemble un cas concret : un pipeline de production vidéo automatisé par un agent IA. De l'idée initiale jusqu'à l'upload sur YouTube, en passant par la génération du script, des images et du montage. On couvre l'architecture, la gestion d'erreurs, le retry, et l'orchestration avec cron + agent + base de données.
🎯 Le cas concret : pipeline vidéo automatisé
Voici le pipeline qu'on va construire :
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ IDÉE │───▶│ SCRIPT │───▶│ IMAGES │───▶│ VIDÉO │───▶│ UPLOAD │
│ │ │ │ │ │ │ │ │ │
│ Sujet + │ │ Texte + │ │ Visuels │ │ Montage │ │ YouTube │
│ angle │ │ narrat° │ │ par │ │ auto │ │ + meta │
│ │ │ │ │ scène │ │ │ │ │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
Chaque étape peut échouer. L'agent doit :
- Orchestrer les outils dans le bon ordre
- Détecter les erreurs et réessayer intelligemment
- Persister l'état pour reprendre après un crash
- Notifier en cas de problème bloquant
🏗️ Architecture globale
Les trois piliers
L'architecture repose sur trois composants qui collaborent :
┌───────────────────────────────────────────────┐
│ CRON │
│ Déclenche le pipeline à intervalles réguliers │
│ Ex: tous les jours à 8h │
└──────────────────────┬────────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ AGENT IA │
│ Orchestre les outils, gère la logique │
│ Prend les décisions, gère les erreurs │
└──────────────────────┬────────────────────────┘
│
▼
┌───────────────────────────────────────────────┐
│ BASE DE DONNÉES │
│ Stocke l'état de chaque tâche │
│ Historique, statuts, résultats intermédiaires │
└───────────────────────────────────────────────┘
Pourquoi cette architecture ?
| Composant | Rôle | Pourquoi c'est nécessaire |
|---|---|---|
| Cron | Déclencheur | L'agent ne tourne pas 24/7, le cron le réveille |
| Agent | Cerveau | Prend les décisions, s'adapte aux erreurs |
| BDD | Mémoire | Survit aux crashes, permet le suivi et le debug |
Sans la BDD, un crash = tout recommencer. Sans le cron, il faut lancer manuellement. Sans l'agent, c'est un script rigide qui casse au moindre imprévu.
💾 Modèle de données
Commençons par la base de données. On utilise SQLite pour la simplicité, mais le concept s'applique à PostgreSQL ou tout autre SGBD.
Le schéma comprend trois tables principales : une table pipelines pour suivre l'état global (statut, nombre d'erreurs, retries max), une table pipeline_steps pour persister chaque étape individuelle avec ses données d'entrée/sortie, ses tentatives et sa durée, et une table pipeline_logs pour le debug. Des index sont posés sur les colonnes fréquemment interrogées (statut, ordre des étapes, date de log) pour garantir des performances correctes même lorsque l'historique grandit.
Pourquoi persister chaque étape ?
Imaginez que la génération d'images fonctionne (étape 3) mais que le montage vidéo échoue (étape 4). Sans persistance, il faut tout refaire — y compris les images qui ont coûté des crédits API. Avec la BDD, l'agent vérifie l'état à chaque démarrage : si une étape est marquée "completed", il passe directement à la suivante. Si une étape est en échec mais n'a pas atteint son nombre max de tentatives, il la relance. Sinon, il notifie un humain et stoppe le pipeline.
🤖 L'agent orchestrateur
Structure du code
L'agent orchestrateur est une classe Python qui embarque une connexion à la base de données, un client LLM et un dictionnaire d'outils (génération d'images, TTS, assemblage vidéo, upload YouTube). Ses méthodes principales permettent de créer un pipeline avec ses étapes, de le lancer (ou de le reprendre s'il a crashé), et d'exécuter chaque étape avec un système de retry et de backoff exponentiel. À chaque action, un log est inséré en base pour garantir la traçabilité. En cas d'échec définitif d'une étape, le pipeline est marqué "failed" et l'erreur est consignée.
Les étapes du pipeline
Chaque étape correspond à une méthode dédiée de l'agent :
- Générer l'idée : envoie un prompt au LLM avec la thématique et l'audience cibles pour obtenir un titre, un hook, un angle et des points clés. Le résultat est validé (longueur du titre, nombre minimum de points).
- Écrire le script : prend l'idée générée et demande au LLM un script structuré en scènes, chacune contenant une narration, une description visuelle et une durée estimée. Une validation vérifie que la durée totale dépasse un seuil minimum.
- Générer les images : pour chaque scène, l'agent construit un prompt de génération d'image (en anglais, adapté à Stable Diffusion ou DALL-E) puis appelle l'outil de génération d'images avec les paramètres de style et de taille définis dans la config.
- Créer la vidéo : génère la narration audio via un outil TTS pour chaque scène, puis assemble les images et les pistes audio en une vidéo finale (typiquement via FFmpeg) à la résolution et framerate demandés.
- Upload et publication : envoie la vidéo sur YouTube avec le titre, la description, les tags et la miniature, en mode privé par défaut pour permettre une review humaine avant publication.
⚡ Gestion intelligente des erreurs
La gestion d'erreurs est ce qui différencie un pipeline amateur d'un pipeline de production. Voici les stratégies clés.
Pour aller plus loin sur ce sujet, consultez notre guide MCP, Function Calling, Tool Use : le guide complet.
Retry avec backoff exponentiel
La fonction de retry implémente un backoff exponentiel avec jitter aléatoire pour éviter de saturer les API en cas de rate limit (erreur 429). Pour les erreurs réseau (timeout, connexion), le délai entre les tentatives croît linéairement. En revanche, les erreurs de validation (problème logique dans les données) ne sont pas retryées : elles remontent directement.
Catégories d'erreurs
Toutes les erreurs ne se traitent pas de la même façon :
| Type d'erreur | Action | Retry ? |
|---|---|---|
| Rate limit (429) | Backoff exponentiel | ✅ Oui |
| Timeout réseau | Retry rapide | ✅ Oui |
| Erreur API (500) | Retry avec délai | ✅ Oui |
| Contenu invalide | Re-générer avec un prompt ajusté | ✅ Oui (avec adaptation) |
| Auth expirée (401) | Rafraîchir le token | ✅ Oui (1 fois) |
| Erreur de validation | Corriger la logique | ❌ Non |
| Quota dépassé | Notifier l'humain | ❌ Non |
| Fichier manquant | Vérifier l'étape précédente | ❌ Non (re-run étape précédente) |
L'agent qui s'adapte
L'avantage d'utiliser un agent IA (plutôt qu'un script) pour l'orchestration, c'est qu'il peut raisonner sur les erreurs. Lorsqu'une étape échoue, l'agent reçoit le contexte (nom de l'étape, message d'erreur, données accumulées) et décide d'une stratégie parmi cinq options : RETRY (réessayer tel quel), RETRY_MODIFIED (réessayer avec des paramètres ajustés), SKIP (sauter si non critique), ROLLBACK (revenir à l'étape précédente) ou ABORT (arrêter et alerter un humain). Cette décision est journalisée en base pour le debug.
Exemples concrets d'adaptation
Scénario 1 : Image générée de mauvaise qualité
Erreur: "Image quality score below threshold (0.3/1.0)"
→ Agent décide: RETRY_MODIFIED
→ Modification: reformuler le prompt en ajoutant "high quality, detailed, 4K"
Scénario 2 : API de TTS temporairement indisponible
Erreur: "503 Service Unavailable"
→ Agent décide: RETRY avec backoff
→ Si 3 échecs: tente un TTS alternatif (fallback)
Scénario 3 : Vidéo trop longue pour YouTube
Erreur: "Video exceeds 15 minute limit for unverified accounts"
→ Agent décide: RETRY_MODIFIED
→ Modification: couper la vidéo en 2 parties
⏰ Orchestration avec Cron
Configuration du cron
Le cron déclenche le pipeline selon un planning défini. Avec une plateforme d'orchestration, on configure directement un schedule (par exemple "lundi-vendredi à 8h") associé à une tâche descriptive. Pour un cron système classique, on ajoute une ligne dans la crontab qui pointe vers le script Python de lancement, avec redirection des logs.
Le script de lancement
Le script exécuté par le cron suit trois étapes : d'abord, il vérifie s'il existe un pipeline en échec avec des retries restants, et si oui il le relance. Ensuite, il vérifie qu'aucun pipeline n'a déjà été créé pour le jour en cours (pour éviter les doublons). Enfin, il crée un nouveau pipeline avec une configuration journalière — par exemple, une rotation de thématiques (nouveautés IA le lundi, tutoriel Python le mardi, etc.) — et le lance. En fin d'exécution, une notification est envoyée selon le résultat (succès ou échec).
📊 Monitoring et dashboard
Un pipeline de production a besoin de visibilité. Voici les métriques essentielles à suivre.
Requêtes de monitoring
Trois requêtes SQL couvrent les besoins de surveillance : le taux de succès sur les 30 derniers jours (ratio completed/total), la durée moyenne par étape (avec min/max et nombre d'échecs), et la liste des pipelines ayant nécessité des retries (avec le détail des étapes relancées et le nombre de tentatives).
Dashboard simple
Un dashboard texte affiche en console un résumé sur les 7 derniers jours : nombre total de pipelines, succès, échecs, pipelines en cours, et taux de réussite. En dessous, les cinq pipelines les plus récents sont listés avec leur statut (icône), leur identifiant, leur nom et leur durée d'exécution.
🔒 Bonnes pratiques de production
1. Idempotence
Chaque étape doit être idempotente : l'exécuter deux fois produit le même résultat. C'est crucial pour le retry. Par exemple, avant de générer des images, l'étape vérifie si les fichiers existent déjà dans le répertoire de sortie. Si le nombre de fichiers correspond au nombre attendu, elle retourne directement les chemins existants sans appeler l'API — économisant du temps et des crédits.
2. Timeouts sur tout
Chaque appel externe (API de génération, TTS, assemblage vidéo) doit être encapsulé dans un timeout. En Python, on peut utiliser les signaux système (SIGALRM) pour interrompre une fonction qui dépasse un délai défini (par exemple 120 secondes pour une génération d'image). Sans timeout, un appel bloquant peut figer tout le pipeline indéfiniment.
3. Nettoyage des fichiers temporaires
Après un pipeline terminé, les fichiers intermédiaires (images temporaires, audio par scène) doivent être supprimés pour éviter la saturation du disque. Le nettoyage garde uniquement le livrable final (la vidéo) et supprime tout le reste. Si le pipeline a échoué et qu'on ne veut rien conserver, le répertoire entier est supprimé.
4. Notifications intelligentes
Le système de notification filtre le bruit : un succès déclenche une notification normale avec l'URL de la vidéo, un échec déclenche une notification urgente avec le nom de l'étape en cause et un extrait de l'erreur. En revanche, les statuts "running" ne génèrent aucune notification — trop de bruit pour peu de valeur.
🚀 Aller plus loin
Parallélisation des étapes indépendantes
Si certaines étapes sont indépendantes, vous pouvez les paralléliser. En Python avec asyncio, on crée une tâche asynchrone par étape et on les lance simultanément avec asyncio.gather. Si une tâche lève une exception, elle remonte immédiatement et les résultats des autres tâches sont quand même récupérés dans le contexte.
Pipeline conditionnel
L'agent peut décider de modifier le pipeline en cours de route. Par exemple, une étape de contrôle qualité analyse la vidéo produite : si le score audio est trop bas, une étape de nettoyage audio est ajoutée dynamiquement après le montage. Si le score visuel est insuffisant, l'agent identifie les scènes problématiques et déclenche une régénération ciblée des images.
Intégration avec une plateforme d'orchestration
Une plateforme d'orchestration multi-agent comme ruflo est parfaitement adaptée pour orchestrer ce type de pipeline grâce à ses cron jobs natifs et son accès aux outils via MCP. L'avantage : l'agent a accès à tous les outils (shell, web, BDD, API) nativement, et le cron est géré par la plateforme. Pas besoin de scripts de lancement complexes.