Comment un pionnier français des LLM a co-construit un ETL capable d’ingérer 50 millions de sources de données ?
Une scale-up qui construit des modèles de langage ne manque presque jamais d’ambition. Elle manque, en revanche, presque toujours de temps pour bâtir l’infrastructure qui nourrit ces modèles. C’est ce paradoxe qui a conduit une jeune pousse parisienne, pionnière sur les grands modèles de langage, à repenser entièrement la façon dont elle collectait, structurait et exploitait ses données.
Le sujet n’est pas anecdotique. Dans l’IA générative, la qualité d’un modèle ne dépend pas seulement de son architecture : elle dépend d’abord de la donnée qu’on lui donne à apprendre. Or la majorité des entreprises qui se lancent dans l’IA sous-estiment le chantier de Data Engineering nécessaire pour transformer des sources brutes, hétérogènes et souvent non structurées, en un socle exploitable. Beaucoup construisent leur pipeline de données au fil de l’eau, sans anticiper le passage à l’échelle. Cela fonctionne à un million de documents. Cela s’effondre à cinquante millions.
C’est précisément le point où cette scale-up nous a sollicités.
« We think deep, to build right. »
Code & Scale
Le défi : transformer un chaos de sources brutes en socle exploitable
L’entreprise disposait déjà d’un actif précieux : un volume massif de documents accumulés au fil de ses activités : publications, rapports, filings réglementaires, contenus web, PDFs techniques.
Au total, plus de 50 millions de sources, représentant des pétaoctets de données non structurées. Un gisement considérable, mais inexploitable en l’état pour entraîner et opérer des modèles de langage fiables.
Les symptômes classiques d’un pipeline de données arrivé à ses limites étaient réunis :
- des scripts d’ingestion développés au cas par cas, sans architecture commune ;
- une extraction de contenu depuis les PDFs peu fiable, sensible à la mise en page et aux formats hétérogènes ;
- l’absence de data lake structuré, rendant toute traçabilité et toute réutilisation coûteuses ;
- des temps de traitement croissant plus vite que le volume de données lui-même ;
- une équipe data engineering concentrée sur la maintenance plutôt que sur la valeur ajoutée.
Ce constat n’a rien d’exceptionnel. Il est même le passage obligé de la plupart des entreprises qui basculent d’un usage expérimental de l’IA à un usage industriel.
Le vrai risque n’est pas technique mais stratégique. Un pipeline de données qui ne tient pas la charge retarde les mises en production, fragilise la qualité des modèles, et immobilise des équipes d’ingénierie sur des tâches à faible valeur.
Dans un marché où la vitesse d’itération conditionne l’avance concurrentielle, ce coût est rarement visible en amont et toujours élevé en aval.
Les analystes rappellent d’ailleurs que les exigences de qualité propres à l’IA diffèrent fondamentalement des standards traditionnels de gestion de la donnée.
Une co-conception, pas une prestation
Nous n’avons pas répondu à cette mission avec une équipe livrée clé en main, mais avec une équipe intégrée. C’est une nuance importante : dans un projet de cette ampleur, la connaissance métier de l’équipe interne sur les spécificités des sources, les usages en aval, les contraintes de latence des modèles, est aussi critique que l’expertise technique elle-même. Notre rôle a été de structurer cette expertise, pas de nous y substituer.
Concrètement, nous avons travaillé en binômes mixtes, avec des ingénieurs data basés en France et une équipe étendue en nearshore, pilotée selon les mêmes standards d’exigence et de revue de code. Ce modèle de data engineering nearshore a permis d’absorber la charge de développement sans diluer la qualité, tout en maintenant une capacité de décision rapide côté produit. La co-conception s’est traduite par des points d’architecture hebdomadaires, une documentation partagée dès le premier sprint, et des choix techniques validés collectivement plutôt qu’imposés.
Ce qui différencie une intervention de ce type d’une prestation classique, c’est la temporalité. Nous n’avons pas cherché à livrer un pipeline figé, mais une architecture capable d’évoluer avec les usages du modèle.
Un ETL pensé pour l’IA n’est jamais un projet fermé : c’est une infrastructure vivante, appelée à absorber de nouveaux types de sources, de nouveaux formats, de nouveaux volumes.
Architecture du Data Lake
La première décision structurante a consisté à sortir d’une logique de stockage ad hoc pour construire un Data Lake maison, avec une organisation en zones raw, cleaned et curated, permettant de séparer clairement l’ingestion, la transformation et l’exposition des données.
Cette approche en couches limite la propagation des erreurs : une anomalie détectée en aval ne remet pas en cause l’ensemble du pipeline, elle est isolée et corrigée à la source.
Pour une entreprise qui entraîne des modèles sur ces données, ce niveau de traçabilité n’est pas un confort technique : c’est une condition de fiabilité du produit final.
Extraction de signaux dans des pétaoctets de PDFs
Le PDF reste, paradoxalement, l’un des formats les plus difficiles à exploiter à grande échelle. Sa structure visuelle prime sur sa structure logique : tableaux imbriqués, colonnes multiples, mise en page non standardisée.
Extraire une valeur fiable, un chiffre, une entité ou une clause depuis des millions de documents hétérogènes exige une chaîne d’extraction robuste, capable de gérer l’exception plutôt que de la subir. Nous avons conçu cette chaîne pour combiner extraction structurelle et validation automatisée, réduisant la part de traitement manuel à la portion réellement irréductible.
Le gain n’est pas seulement opérationnel : c’est la qualité même du signal transmis aux modèles qui en dépend.
Industrialisation et scalabilité de l’ETL
Un ETL LLM conçu pour quelques centaines de milliers de documents ne se comporte pas comme un ETL conçu pour cinquante millions.
Le passage à l’échelle impose de repenser le parallélisme des traitements, la gestion des files d’attente et la résilience face aux échecs partiels. Un document corrompu ne doit jamais bloquer un batch entier.
Nous avons donc privilégié une architecture orientée événements, dans laquelle chaque étape du pipeline peut être rejouée indépendamment.
Le bénéfice pour l’équipe produit est immédiat. Les temps de traitement ne sont plus un facteur limitant pour la fréquence de mise à jour des modèles.
Gouvernance et qualité de la donnée
Ingérer davantage de données n’a de sens que si leur qualité est mesurable. Nous avons mis en place des contrôles de cohérence à chaque étape du pipeline : complétude, doublons, dérive de format, afin que les équipes en charge de l’entraînement des modèles disposent d’indicateurs clairs plutôt que d’une confiance implicite.
Cette gouvernance a également permis de documenter la provenance de chaque source, un enjeu qui devient central à mesure que se renforcent les exigences réglementaires, notamment les fiches pratiques de la CNIL sur l’IA.
Collaboration et transfert de compétences
Un pipeline de données, aussi robuste soit-il, n’a de valeur durable que si l’équipe interne peut le faire évoluer sans dépendance externe.
Cette dimension a été pensée dès le départ : documentation continue, revues de code croisées, montée en compétence progressive des ingénieurs internes sur les choix d’architecture. L’objectif d’une co-création data France n’est pas de livrer un outil, mais de transférer une capacité.
En résumé
Contexte : une scale-up parisienne pionnière des LLM, ayant réalisé une levée de fonds significative, disposant d’un volume massif de sources brutes hétérogènes.
Mission : concevoir et industrialiser un pipeline de données (ETL) capable d’ingérer, structurer et exposer 50 millions de sources, incluant l’extraction de valeurs depuis des pétaoctets de PDFs.
Approche : co-conception en équipe mixte France / nearshore, architecture en data lake par zones, chaîne d’extraction robuste, industrialisation orientée événements.
Technologies : pipeline data engineering, traitement distribué de documents non structurés, data lake maison, contrôles qualité automatisés.
Valeur créée : une infrastructure de données capable d’accompagner la montée en charge du produit et l’évolution continue des usages IA, avec une équipe interne montée en compétence sur l’architecture.
Mission en cours, menée dans le cadre d’un partenariat continu depuis 2023. Les éléments présentés sont anonymisés à la demande du partenaire.
Notre vision
Nous pensons qu’un pipeline de données n’est jamais un sujet purement technique. C’est une décision d’architecture qui engage la trajectoire d’une entreprise sur plusieurs années. Aller vite sur ce type de chantier, sans réflexion préalable, conduit presque toujours à un coût plus élevé par la suite, qu’il s’agisse de dette technique, d’instabilité produit ou d’une perte de confiance dans les données.
C’est pourquoi nous privilégions systématiquement une compréhension approfondie du contexte métier avant toute décision d’architecture. Un pipeline data pour l’IA conçu sans cette compréhension dépasse rarement le stade du prototype.
Nous croyons également à la valeur d’un partenariat dans la durée : les meilleures architectures ne résultent pas d’une livraison ponctuelle, mais d’une collaboration continue entre une équipe interne qui maîtrise son métier et une équipe externe qui apporte une expérience éprouvée sur ce type de projets.
Cette exigence guide chacune de nos missions, quelle que soit leur envergure.
Conclusion
Le passage à l’échelle d’un pipeline de données pour l’IA générative n’est pas qu’une question de volume : c’est une question d’architecture, de gouvernance et de collaboration. Les entreprises qui réussissent ce virage sont celles qui traitent leur data engineering comme un actif stratégique, et non comme une fonction support.
Questions fréquentes
Qu’est-ce qu’un ETL LLM ?
Un ETL LLM est un pipeline de données (Extract, Transform, Load) conçu spécifiquement pour préparer, structurer et qualifier les données destinées à l’entraînement ou à l’exploitation de grands modèles de langage.
Pourquoi le passage à l’échelle d’un pipeline de données est-il si complexe ?
Parce que les architectures conçues pour de petits volumes ne supportent pas la charge, la diversité des formats et les temps de traitement imposés par des millions de sources hétérogènes.
Comment extraire des données fiables depuis des PDFs à grande échelle ?
En combinant une extraction structurelle robuste avec des mécanismes de validation automatisée, capables de gérer les exceptions de mise en page sans intervention manuelle systématique.
Qu’est-ce qu’un data lake maison et pourquoi le construire ?
C’est une infrastructure de stockage organisée en zones (brute, intermédiaire, consolidée) qui permet de tracer, transformer et exposer la donnée de façon fiable et évolutive.
Qu’apporte le data engineering nearshore par rapport à une équipe interne seule ?
Une capacité de développement supplémentaire, mobilisable rapidement, sans diluer la qualité grâce à des standards de revue partagés avec l’équipe interne.
Comment garantir la qualité des données utilisées pour entraîner un modèle IA ?
Par des contrôles de cohérence à chaque étape du pipeline (complétude, doublons, dérive de format) et une documentation systématique de la provenance des sources.
Quels sont les signaux qu’un pipeline de données a atteint ses limites ?
Des scripts d’ingestion développés au cas par cas, un temps de traitement qui croît plus vite que le volume de données, et une équipe mobilisée sur la maintenance plutôt que sur la valeur ajoutée.
