Organisme de formation français
Un programme de formation en entrée, une formation eLearning complète en sortie.
54+
formations livrées
10
étapes pipeline automatisées
FLUX.2 · Chatterbox
modèles auto-hébergés
En bref
- Le problème
- Produire à la main une formation eLearning complète coûte plusieurs milliers d'euros et plusieurs semaines de travail, un prix incompatible avec le volume qu'un organisme doit livrer pour rentabiliser son agrément.
- La décision
- Une chaîne de production automatisée qui transforme un programme de formation en formation prête à diffuser, avec les modèles d'images et de voix hébergés sur notre propre serveur et un moteur de contenu interchangeable, pour garder la main sur le coût d'une formation.
- Le résultat
- En production depuis plus d'un an : les formations partent vers la plateforme de diffusion du client, en mode documents par défaut, la vidéo et la voix complète étant générées à la demande.
Le contexte
Une formation eLearning produite de façon traditionnelle coûte plusieurs milliers d'euros et plusieurs semaines, un prix que le volume du marché Qualiopi/CPF ne supporte pas.
Le marché français de la formation Qualiopi/CPF est sensible au volume : un organisme de formation doit livrer beaucoup de formations à un coût unitaire faible pour rentabiliser son agrément. La production traditionnelle d'une formation eLearning complète (script, illustrations, voix professionnelle, vidéo, QCM, livret imprimable) coûte plusieurs milliers d'euros et plusieurs semaines de travail humain. À l'échelle nécessaire pour rester compétitif, ce coût ne tient pas.
Le pipeline construit pour un organisme de formation français automatise la chaîne complète : un programme de formation au format PDF ou DOCX entre, et une formation prête à diffuser sort : illustrations originales, narration vocale en français naturel, vidéos 4K avec transitions, QCM par module, livret PDF imprimable. Le tout est consommé directement par la plateforme de diffusion du client, qui assemble et délivre les formations générées.
La difficulté n'était pas de faire fonctionner l'IA, mais de descendre le coût d'une formation à un niveau qui rende l'opération rentable.
L'enjeu n'était pas « faire fonctionner l'IA ». Chaque modèle individuel marche tout seul, c'est ce que vendent OpenAI, Anthropic, ElevenLabs, Stability. L'enjeu était de descendre le coût marginal par formation à un niveau qui rende l'opération économiquement saine. La première version, entièrement adossée à des API tierces, plaçait ce coût hors d'atteinte du volume visé. Chaque phase depuis déplace une charge lourde des API vers une infrastructure auto-hébergée, et la trajectoire de coût est le critère qui arbitre ces choix.
Les décisions d'architecture
Les modèles lourds d'images et de voix tournent sur notre propre serveur plutôt que sur des API facturées à l'usage, avec bascule automatique vers ces API si le serveur est indisponible.
Inférence GPU auto-hébergée pour les modèles lourds (FLUX.2 klein 4B images, Chatterbox TTS voix), pas Pipeline 100 % API (OpenAI Imagen + ElevenLabs). Une formation de quatre heures consomme environ 120 illustrations et 80 minutes de narration. Aux tarifs API du marché, le coût marginal par formation devient le poste dominant, non viable au volume mensuel visé. Auto-héberger FLUX.2 (variante klein 4B, choisie pour tenir dans 32 Go de RAM sans saturer la mémoire) et Chatterbox (voix clonée à partir de 10 secondes de référence) ramène ce coût à quelques centimes d'électricité plus l'amortissement matériel.
Trade-off assumé : Le serveur GPU devient une dépendance opérationnelle de production. Expirations de connexion SSH à gérer, saturation mémoire avec les variantes plus grosses (résolu en passant à la variante klein 4B), qualité voix légèrement en deçà d'ElevenLabs Pro sur les passages chiffrés. Le pipeline conserve des API de repli (OpenAI Imagen, ElevenLabs, Edge TTS) automatiquement activées si le serveur GPU n'est pas disponible : la formation se génère plus cher, mais elle se génère.
L'orchestration est faite maison, avec un point de reprise enregistré à chaque étape : un incident tard dans la chaîne ne fait pas rejouer les heures déjà produites.
Orchestration sur mesure avec point de reprise persistant par étape, par formation (state.json), pas Orchestrateur distribué (Temporal, BullMQ, cron). Une formation prend plusieurs heures sur dix étapes pipeline. Un crash à l'étape 8 sur 10 du module 5 d'un lot de 54 formations doit pouvoir reprendre où il s'est arrêté, et non re-rejouer sept heures de travail. Le principe d'un state.json par formation épouse exactement le domaine : la résilience cherchée est « reprendre là où on était », non « garantie d'exécution unique répartie sur plusieurs machines ». La résilience et l'automatisation complète étaient l'objectif explicite dès le départ, non une réponse a posteriori à des crashes.
Trade-off assumé : Pas d'orchestration multi-machines, pas de file de tâches partagée entre exécuteurs. Chaque formation tourne sur une machine dans un processus. Acceptable pour le volume visé (lots de 50 à 100 formations). Une migration vers un orchestrateur distribué resterait possible si le volume change d'ordre de grandeur.
Le moteur qui rédige le contenu est interchangeable, pour que le coût d'une formation ne reste pas figé au tarif d'un seul fournisseur.
Abstraction du moteur de génération de contenu : Claude API · Claude Max CLI · Ollama (à venir), pas Choisir un fournisseur de génération de contenu et s'y coupler en dur. Le coût marginal d'une formation dépend directement du moteur de contenu utilisé. En production actuelle, Claude Max CLI permet d'exploiter le quota mensuel inclus dans un abonnement à coût fixe, sans facture variable par formation. Quand le quota est épuisé, le pipeline bascule sur l'API Anthropic payante avec une comptabilité explicite (budget journalier maximum). Quand Ollama sera intégré (cible Phase 3), les formations de R&D ou de prévisualisation pourront tourner à zéro euro variable.
Trade-off assumé : Trois moteurs à tester et à maintenir. Les sessions Claude Max ont des limites de débit explicites : l'orchestrateur de production lit les messages « Reset in X hr Y min » et applique une temporisation dynamique. La complexité s'amortit sur la flexibilité économique : un changement de tarif côté Anthropic ne casse pas le modèle économique du pipeline.
L'exécution
Le travail est réparti sur deux machines : un poste de travail produit les textes et les documents, un serveur dédié exécute les calculs lourds d'images et de voix.
Le pipeline tourne sur deux machines en réseau local : un poste de travail orchestre les étapes CPU (génération de contenu via Claude, Typst pour les PDFs, FFmpeg pour les vidéos, Mermaid pour les diagrammes) et un serveur GPU dédié exécute les inférences lourdes (FLUX.2 pour les illustrations, Chatterbox pour la voix, Whisper pour la validation). La communication entre les deux passe par SSH avec maintien de connexion configuré pour absorber les latences d'inférence longues.
Chaque formation laisse un journal complet de ses étapes, ce qui permet de reprendre exactement là où elle a échoué plutôt que de tout relancer.
L'observabilité s'appuie sur un journal exhaustif par formation : chaque étape écrit son état dans state.json, ses logs dans un fichier dédié, ses artefacts dans un répertoire de travail isolé. Une formation qui échoue laisse derrière elle suffisamment de traces pour reprendre manuellement à l'étape exacte qui a posé problème, sans avoir à rejouer les sept étapes précédentes.
Deux lots en parallèle possibleUn lot se déroule sans surveillance humaine : reprises bornées, limites de quota absorbées, dépense plafonnée par jour sur les services de secours.
L'orchestrateur de production gère la résilience opérationnelle complète : reprises bornées par étape, gestion des limites de session Claude Max avec temporisation dynamique, budget journalier maximum sur les API de repli, plusieurs exécutions en parallèle grâce à des répertoires d'état séparés (deux lots peuvent tourner sur des sous-files dédiées sans se télescoper).
Les leçons
Leçon 1Le coût d'une formation n'est pas une donnée fixe : il se déplace à mesure que les modèles ouverts rattrapent les modèles propriétaires, à condition d'avoir prévu de changer de fournisseur.
La première leçon vient de la trajectoire de coût marginal. La version initiale du pipeline tournait en mode « tout-API » : Anthropic pour le contenu, OpenAI pour les images, ElevenLabs pour la voix. Les images et la voix dominaient très largement la facture, et le coût par formation était le poste qui décidait à lui seul de la viabilité du volume.
La Phase 2 a déplacé la production vers un mode « documents seuls » : PDF, diapositives, QCM, scripts de narration générés systématiquement ; vidéo et voix devenues des artefacts sur demande, générés uniquement quand un client le requiert. Combinée avec Claude Max CLI pour le contenu (quota mensuel inclus, zéro coût variable) et un modèle d'image API à bas coût pour les illustrations, la Phase 2 fait chuter le coût observé sans dégrader le livrable.
La cible Phase 3, chaîne entièrement locale (Ollama pour le contenu, FLUX.2 pour les images, Chatterbox pour la voix, Whisper pour la validation), vise à le réduire encore. La leçon plus large : dans un pipeline IA, le coût marginal n'est pas une donnée fixe ; c'est une variable d'optimisation continue, qui se déplace au fur et à mesure que les modèles ouverts rattrapent les modèles propriétaires. Construire un pipeline qui ne sait pas changer de moteur revient à figer son coût marginal au tarif du fournisseur du jour.
Leçon 2Le contrôle automatique de la voix générée est devenu un avertissement et non un verrou : en bloquant, il arrêtait la production sur des fichiers pourtant utilisables.
La seconde leçon porte sur la validation des artefacts générés par l'IA. La voix synthétique produite par Chatterbox est ré-écoutée par Whisper en STT, et le texte reconnu est comparé au script original. Un Word Error Rate de plus de 10 % déclenche un signal dans le journal.
Notre première implémentation faisait du WER un blocage : au-delà du seuil, l'audio était rejeté et l'étape relancée. En pratique, le blocage coûtait plus en temps d'attente qu'il ne corrigeait : la plupart des dépassements de WER venaient de chiffres, d'acronymes ou de prononciations ambiguës que Whisper ne reconnaissait pas mais qui étaient cosmétiquement acceptables. Le rejet bloquant générait des boucles infinies sur des artefacts en réalité valides.
Nous avons reculé : le WER devient un avertissement, jamais un verrou. Le pipeline produit l'audio, le journalise avec son WER, et continue. Le relecteur humain regarde la liste des avertissements en fin de lot et décide ce qui mérite régénération. La leçon : dans un pipeline IA, la validation automatique doit être informative, jamais bloquante. Les modèles produisent des artefacts dont la qualité varie naturellement, et un seuil rigide convertit cette variation naturelle en arrêt de production.
En production aujourd'hui
Le pipeline tourne en production depuis plus d'un an. Cinquante-quatre formations ont été livrées via la couche de productisation du client, qui assemble et délivre les formations générées. Le mode Phase 2 (documents seuls, Claude Max + OpenAI Imagen) est le mode standard ; le mode complet (vidéo + voix) est invoqué sur demande client, en lot différé.
La feuille de route court terme finalise l'intégration Ollama pour franchir le seuil Phase 3, et un mécanisme de génération différée pour les vidéos qui permet de répondre « vidéo prête sous 48h » plutôt que d'imposer la génération synchrone au moment de la commande.
Un système à concevoir, déployer ou reprendre en main ?
Avec ou sans cahier des charges : décrivez votre situation, nous répondons par écrit sous 48 h ouvrées.