Un cluster de recherche, raconté

Ceci est le récit d’ingénierie d’un cluster Kubernetes de recherche hyperconvergé : pourquoi il existe, comment il est bâti, et ce qu’il produit. Il se lit comme un article — contexte, objectif, données, méthode, trajectoire, résultats — et s’adresse à un lecteur néophyte. Les termes techniques sont des liens : un mot-clé renvoie à sa définition (le glossaire), à la décision qui le fonde (un ADR) ou à la brique concernée (composants).

🔰 Comprendre vs faire. Ce récit explique (le pourquoi, l’ensemble). Pour faire pas à pas — installer, opérer — suivez le parcours de démarrage.

Valeurs génériques (ADR 0023). Les hôtes, IP et noms cités (cp1, node1, 10.0.0.0/22…) sont des exemples : ce dépôt est un catalogue de topologies réutilisables, pas l’infrastructure d’un déploiement particulier. Les briques nommées (Ceph, Cilium, Dagster…) sont en revanche les vraies décisions techniques.

[[toc]]

Contexte et état de l’art

🔰 Lecteur pressé ? Cette section pose le pourquoi (paysage des menaces, état de l’art académique) et compte une trentaine de références. Pour aller droit au but, sautez directement à Objectif : ce que ce cluster vise concrètement. Le contexte ci-dessous éclaire les décisions, il n’est pas un prérequis pour comprendre la suite.

Un laboratoire de recherche produit et consomme des données : il faut les stocker, les transformer, les tracer, et faire tourner du calcul à côté. Or ces gestes se déroulent aujourd’hui dans un environnement bien plus hostile et disputé qu’il y a dix ans. Le paysage des menaces s’est intensifié : sur la période juillet 2023 – juin 2024, l’ENISA a recensé plus de 11 000 incidents de cybersécurité dans l’Union européenne, le rançongiciel et le déni de service en représentant à eux seuls plus de la moitié [1] ; le coût moyen mondial d’une violation de données atteignait 4,88 millions de dollars en 2024, en hausse de 10 % sur un an [2]. La recherche n’est pas un dommage collatéral mais une cible : Microsoft la classe deuxième secteur le plus visé par les acteurs étatiques en 2024 [3], et en France l’ANSSI note que l’enseignement supérieur représente 12 % des victimes de rançongiciels qu’elle a connues en 2024 [4]. La chaîne d’approvisionnement logicielle est elle-même devenue un vecteur : la porte dérobée glissée dans la bibliothèque xz/liblzma début 2024, notée au score de gravité maximal (CVSS 10,0), n’a été découverte que par chance avant d’atteindre les distributions stables [5].

L’intelligence artificielle amplifie ce mouvement des deux côtés. Comme arme, elle abaisse la barrière d’entrée des attaquants et augmente le volume et l’impact des attaques — le centre britannique NCSC le juge « quasi certain » à l’horizon de deux ans [6]. Comme moteur, elle fait exploser la demande de calcul : le calcul d’entraînement des modèles de pointe croît d’un facteur d’environ 4 à 5 par an, soit un doublement tous les cinq à six mois [7] ; et le stock de texte public exploitable pour entraîner ces modèles pourrait être épuisé entre 2026 et 2032 [8], ce qui fait des corpus de données une ressource convoitée.

Cette demande de calcul nourrit une compétition mondiale sur les data centers, dont l’enjeu est autant énergétique que géopolitique. En 2024, les data centers consommaient environ 1,5 % de l’électricité mondiale (415 TWh), une consommation que l’Agence internationale de l’énergie voit plus que doubler d’ici 2030 [9] ; l’investissement mondial dans ces infrastructures a quasi doublé depuis 2022 pour approcher 500 milliards de dollars en 2024 [9]. Cette capacité est très concentrée : les États-Unis pèsent 45 % de la consommation électrique des data centers, devant la Chine (25 %) et l’Europe (15 %) [10]. Surtout, trois fournisseurs américains captent désormais 70 % du marché cloud européen, tandis que la part des acteurs européens est retombée de 29 % (2017) à 15 % (2022) [11]. Or l’hébergement chez un opérateur de droit américain n’échappe pas au CLOUD Act, qui l’oblige à livrer les données qu’il contrôle « qu’elles soient situées à l’intérieur ou à l’extérieur des États-Unis » [12] — la localisation des serveurs en Europe ne suffit donc pas.

Ces contraintes orientent déjà l’architecture. Trois besoins — stocker (conserver de gros volumes durablement et de façon résiliente), calculer (exécuter des traitements près des données) et faire transiter (déplacer les données sans les exposer) — peuvent être servis par plusieurs modèles : le cloud public (élastique mais externalisé et soumis à une juridiction étrangère), le cloud souverain de confiance (qualifié mais au catalogue restreint et plus coûteux), l’on-premise (maîtrise complète contre charge d’exploitation) ou l’hybride / edge. Aucun de ces problèmes — menace, dépendance, coût du calcul, fragilité de la chaîne — n’est neuf pour la recherche : ils structurent depuis vingt ans des champs entiers de l’informatique, dont la suite de cette section résume comment ils les abordent et quelles perspectives ils dégagent.

Stocker de façon résiliente. Le champ s’est construit sur une tension théorique — le théorème CAP, conjecturé par Brewer puis prouvé par Gilbert et Lynch [18], établit qu’un système distribué ne peut garantir simultanément cohérence, disponibilité et tolérance au partitionnement. Les systèmes fondateurs ont tranché ce compromis différemment, de Google File System [19] à Dynamo chez Amazon [20], tandis que Ceph introduisait un placement déterministe sans annuaire central [21]. La tension pratique — durer sans payer 200 % de surcoût de réplication — a relancé la recherche sur l’erasure coding : les codes régénérants de Dimakis et al. [22] caractérisent le compromis entre stockage et bande passante de réparation, et les Local Reconstruction Codes déployés à grande échelle [23] en réduisent le coût. Une synthèse récente de plus de 280 travaux [24] montre que les perspectives se déplacent vers les approches hybrides réplication + codage et vers la minimisation de la bande passante de réparation, y compris sur des architectures de mémoire désagrégée.

Tracer et reproduire. Deux lignées convergent : une lignée bases de données / workflows scientifiques, qui formalise la provenance (le modèle W3C PROV [25], précédé des cadres fondateurs de Buneman et al. [26]), et une lignée science computationnelle, qui érige la reproductibilité en standard de publication [27]. Les principes FAIR [28] ont donné un cadre mondial à la gestion des données réutilisables, étendu depuis au logiciel et aux workflows. Les chercheurs soulignent toutefois un écart persistant entre « artefact disponible » et « résultat réellement reproduit », et la dette technique propre aux pipelines de données [29]. La perspective active est la capture automatique et de bout en bout de la provenance dans des pipelines hétérogènes [30] — l’enjeu même du lineage de ce projet.

Sécuriser et rester souverain. La souveraineté numérique est traitée par les sciences sociales comme un concept contesté, sans définition juridique stable [31], dont les initiatives concrètes (Gaia-X, International Data Spaces) révèlent la tension entre souveraineté et interopérabilité [32]. Côté cryptographie, les fondations existent mais restent coûteuses : le chiffrement homomorphe de Gentry [33] et le calcul multipartite sécurisé [34] permettent en théorie de calculer sans révéler les données, au prix d’un surcoût qui freine encore le passage à l’échelle. Sur le plan opérationnel, le zero-trust — concept né chez un analyste, puis formalisé par le NIST [13] — et la sécurité de la chaîne d’approvisionnement logicielle [35] déplacent l’enjeu du théorique vers l’adoption : une garantie vérifiable n’a de valeur que si producteurs et consommateurs l’implémentent.

Calculer à la bonne échelle. Face à la centralisation cloud, la recherche déplace le curseur vers la périphérie : l’edge computing [36] et le fog computing rapprochent le calcul de la donnée pour la latence, la vie privée et la résilience hors-ligne. La notion industrielle de data gravity — la donnée « attire » les traitements et devient coûteuse à déplacer — trouve sa traduction savante dans le problème du placement des données. Enfin, la soutenabilité devient un objet de recherche à part entière : après une recalibration des estimations de consommation [37], des travaux sur l’ordonnancement carbon-aware [38] montrent qu’on peut décaler les charges flexibles selon l’intensité carbone du réseau électrique.

Une convergence. Ces champs partagent un dénominateur : le contrôle — juridique sur la donnée (souveraineté), sur sa durabilité (résilience), sur le comment d’un résultat (provenance), sur l’empreinte (soutenabilité). Deux ponts ressortent. D’abord, « garder le calcul près de la donnée » sert à la fois la latence, la conformité et la soutenabilité — c’est le point de convergence le plus net. Ensuite, la provenance vérifiable est une même idée appliquée à deux objets : tracer comment un résultat scientifique est produit (reproductibilité) et comment un artefact logiciel est construit (sécurité de la chaîne). Une plateforme souveraine, résiliente et reproductible n’est donc pas une juxtaposition de briques, mais la réponse cohérente à un faisceau de questions que la recherche traite ensemble.

Objectif

Plutôt que de louer ces capacités dans un nuage public, ce projet construit une plateforme souveraine sur quelques serveurs : on en garde la maîtrise (coût, confidentialité, juridiction, disponibilité) au prix d’avoir à l’opérer soi-même. L’objectif n’est pas de livrer « un cluster » mais de démontrer une plateforme de données reproductible, dont chaque décision est tracée et chaque résultat rejouable. Concrètement, le projet vise à :

1. Fournir un socle complet — calcul, stockage distribué (bloc, fichier, objet), réseau, exposition de services, observabilité — utilisable par des développeurs qui n’ont pas à connaître l’infrastructure sous-jacente.
2. Porter une chaîne DataOps de bout en bout : orchestration de pipelines, base de données managée, traçabilité de l’origine des données (lineage).
3. Rester un catalogue réutilisable, pas une instance unique : plusieurs topologies déclarées, une activée par déploiement, valeurs génériques (ADR 0023).
4. Prouver, pas affirmer : un résultat ne compte que s’il est reproductible à partir du code seul — principe-chapeau du dépôt (ADR 0052).

La frontière est nette : ce dépôt fournit le contenant (le socle générique) ; le contenu métier (pipelines, jeux de données d’un projet) vit ailleurs, dans le dépôt applicatif.

Données

Pour donner corps à la plateforme, prenons quatre sources de données ouvertes, représentatives par leur diversité de volumétrie et de cadence (chiffres relevés en juin 2026 ; ces sources grandissent en continu).

• OpenAlex — catalogue bibliographique ouvert (successeur de Microsoft Academic Graph). Environ 316 millions d’œuvres, 118 millions d’auteurs ; le snapshot complet pèse ~330 Go compressés (~1,6 To décompressés) en JSON Lines, et le snapshot public gratuit est rafraîchi trimestriellement (flux mensuels et changements quotidiens en offre payante) [14].
• Wikipedia — dumps de la Wikimedia Foundation. ~7,2 millions d’articles pour la seule édition anglaise (~68 millions tous langages confondus). Le dump des révisions courantes fait ~25 Go compressés (>105 Go décompressés) ; le dump avec historique complet atteint ~31 To décompressés. Cadence mensuelle [15].
• GDELT — base mondiale d’événements médiatiques, mise à jour toutes les 15 minutes, 24h/24. Un audit officiel de 2021 dénombrait ~564 millions d’enregistrements d’événements et plus de 8 000 milliards de datapoints cumulés, en CSV et via BigQuery [16].
• OpenData ESR — données ouvertes de l’Enseignement supérieur et de la Recherche français. Quelques centaines de jeux tabulaires (effectifs, diplômes, insertion, brevets…), de volumétrie modeste (du Ko à quelques dizaines de Mo), mis à jour majoritairement une fois par an, exposés via une API OpenDataSoft [17].

Ces quatre sources, mises côte à côte, posent des défis que toute la suite du récit cherche à relever. D’abord la volumétrie : conserver l’historique Wikipedia et plusieurs snapshots OpenAlex amène d’emblée à plusieurs dizaines de téraoctets, ce qui impose un stockage distribué et des formats colonnaires compressés. Ensuite l’hétérogénéité radicale des cadences : faire cohabiter un micro-batch toutes les 15 minutes (GDELT) avec un dump mensuel massif (Wikipedia), un snapshot trimestriel (OpenAlex) et un rafraîchissement annuel (ESR) sur un même plan d’orchestration est un piège architectural. Enfin la mise à jour incrémentale : OpenAlex publie des fusions et suppressions d’identifiants qu’un simple ajout en fin de table ignorerait, et l’historique Wikipedia n’offre aucun delta natif — chaque cycle re-télécharge des téraoctets inchangés faute d’une logique de capture des changements.

Méthode

Une plateforme qui se veut reproductible ne peut pas être bâtie n’importe comment : la méthode est elle-même un résultat. Quatre disciplines la cadrent.

Tout choix se trace, immuablement. Chaque décision de conception est consignée dans un ADR (Architecture Decision Record) au format Nygard léger — contexte, décision, statut, conséquences. Un ADR ne se réécrit pas : il est superseded quand une décision en remplace une autre, jamais effacé. Ce méta-cadre est lui-même outillé : un ADR décide (immuable), un plan met en œuvre (vivant), une issue exécute, une PR livre — quatre rôles non chevauchants (ADR 0057). On sait, des mois plus tard, pourquoi une chose est ainsi.

Le bon outil pour chaque geste. Le dépôt suit une doctrine explicite du choix d’outil par action (ADR 0049) : bash orchestre, Ansible converge de façon idempotente, jq parse, Python porte la logique non triviale (et se teste), bats et pytest éprouvent. La documentation suit Diátaxis — une page sert un besoin de lecture (apprendre, faire, vérifier, comprendre), et l’on câble plutôt que de recopier. L’historique se préserve par merge-commit (ADR 0037) ; aucune page de doc n’est orpheline (ADR 0029, contrôle automatique bloquant).

Du logiciel libre, maîtrisé. Toute la pile est open-source — choix cohérent avec l’objectif de souveraineté : pas de boîte noire ni de licence captive sur le chemin critique. Les versions sont épinglées par digest d’index multi-arch (ADR 0006), les dépendances suivies en PR dédiées, jamais auto-mergées. Le détail des briques et de leurs alternatives écartées vit dans composants.

On prouve, on n’affirme pas. C’est le principe-chapeau (ADR 0052) : un résultat n’existe que reproductible depuis le code seul. Un état complété à la main est une preuve invalide ; l’idempotence se démontre par un rejeu sans changement. Pour verrouiller ce principe, des garde-fous s’enchaînent avant que la moindre régression atteigne la production — hooks de commit, intégration continue, banc d’essai, détection de dérive sur les serveurs. L’inventaire complet est dans SAFEGUARDS.md ; leur mesure agrégée, sur la page des preuves.

Le voyage parcouru

Une plateforme ne naît pas droite du premier coup. Ce qui distingue celle-ci, c’est que chaque détour est consigné plutôt que lissé — et c’est précisément la trace de ces détours qui atteste du sérieux du processus.

La mécanique est régulière : un ADR acte une décision ; un plan la déroule en paliers ; une issue exécute un palier ; une PR le livre ; et un run de bout en bout sur banc révèle ce que ni la relecture ni le lint ne voyaient. Chacun de ces écarts — un drift — est indexé dans un registre unique (symptôme, cause, correctif, portée, statut), puis distillé en invariants réutilisables dans les leçons des runs.

Trois exemples donnent le ton. Le build de l’interface web du store de lineage saturait la mémoire à 5 Gio : il a fallu dimensionner le banc pour le pic, pas pour le repos. Un flux entre l’orchestrateur et le store de lineage échouait silencieusement faute d’une NetworkPolicy d’egress — un vrai bug du livrable, corrigé à la racine, pas contourné. Et des définitions de ressources personnalisées (CRD) que l’outil officiel acceptait étaient rejetées par le parseur d’un autre, imposant de les appliquer autrement. Aucun de ces pièges n’était visible au lint : tous passaient au vert (ADR 0034).

La leçon est double. D’abord, le compteur de drifts qui se tarit run après run est la courbe de fiabilisation : la répétition n’est pas un aveu de faiblesse, c’est le processus. Ensuite, la connaissance capitalise — les pièges d’un chantier servent de spécification au suivant. Le détail daté de chaque campagne vit dans le journal des runs.

Résultats

À ce jour, la plateforme tient sa promesse centrale sur le banc : montée de zéro, sans intervention manuelle, elle assemble la chaîne complète et la prouve fonctionnelle.

La chaîne DataOps est validée de bout en bout : un run réel de l’orchestrateur émet des événements OpenLineage, qui sont ingérés et visibles dans le store de lineage — la chaîne orchestration → traçabilité → visualisation n’est pas montée « en théorie », elle a fait transiter un vrai job. Sous elle, le socle est lui aussi éprouvé : Kubernetes sur plusieurs nœuds, réseau Cilium chiffré, stockage distribué Ceph (bloc, fichier et objet S3), PostgreSQL managé avec sauvegarde vers S3, et l’observabilité (métriques + logs) sollicitée par des épreuves réelles. Le détail des combinaisons réellement montées — et la nature de chaque épreuve (unitaire, intégration de chaîne, chaos) — est dans la matrice du catalogue.

Surtout, ce qui n’est pas prouvé est dit comme tel. Tout l’existant a été validé sur une seule combinaison d’axes — architecture arm64, terrain local, trois nœuds avec un plan de contrôle unique. Restent des trous assumés : le matériel x86 (validé seulement en production cible), la haute disponibilité réelle du plan de contrôle (ha-3cp), et le multi-sites. Ces angles morts sont nommés, pas dissimulés — l’honnêteté sur la couverture fait partie de la preuve. La page des preuves consolide l’ensemble et renvoie à chaque trace brute.

La frontière reste celle posée en introduction : ce dépôt livre le contenant — un socle générique, reproductible, prouvé. Le contenu métier (les pipelines, les jeux de données réels d’un projet) se branche dessus depuis le dépôt applicatif, en suivant le guide du développeur data.

Références

1. ENISA, Threat Landscape 2024, 2024. https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024
2. IBM (avec Ponemon Institute), Cost of a Data Breach Report 2024, 2024. https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-data-breach-disruption-pushes-costs-to-new-highs
3. Microsoft, Digital Defense Report 2024, 2024. https://www.microsoft.com/en-us/security/security-insider/threat-landscape/microsoft-digital-defense-report-2024
4. ANSSI / CERT-FR, Panorama de la cybermenace 2024, 2025. https://cyber.gouv.fr/actualites/panorama-de-la-cybermenace-2024-mobilisation-et-vigilance-face-aux-attaquants/
5. NIST National Vulnerability Database, CVE-2024-3094 (xz/liblzma), 2024. https://nvd.nist.gov/vuln/detail/cve-2024-3094
6. UK NCSC, The near-term impact of AI on the cyber threat, 2024. https://www.ncsc.gov.uk/report/impact-of-ai-on-cyber-threat
7. Epoch AI, Training compute of frontier AI models grows by 4-5x per year, 2024. https://epoch.ai/blog/training-compute-of-frontier-ai-models-grows-by-4-5x-per-year
8. Epoch AI, Will we run out of data? Limits of LLM scaling based on human-generated data, 2024. https://epoch.ai/publications/will-we-run-out-of-data-limits-of-llm-scaling-based-on-human-generated-data
9. IEA, Energy and AI (World Energy Outlook Special Report), 2025. https://www.iea.org/reports/energy-and-ai/executive-summary
10. IEA, Energy and AI, 2025 (répartition géographique). https://www.iea.org/reports/energy-and-ai/executive-summary
11. Synergy Research Group, European cloud providers’ local market share, 2025. https://www.srgresearch.com/articles/european-cloud-providers-local-market-share-now-holds-steady-at-15
12. 18 U.S. Code § 2713 (CLOUD Act), 2018, via Legal Information Institute (Cornell Law School). https://www.law.cornell.edu/uscode/text/18/2713
13. NIST, SP 800-207 Zero Trust Architecture, 2020. https://www.nist.gov/news-events/news/2020/08/zero-trust-architecture-nist-publishes-sp-800-207
14. OpenAlex, Documentation — data snapshot, 2026. https://developers.openalex.org/download
15. Wikimedia Foundation, Data dumps, 2026. https://dumps.wikimedia.org/
16. The GDELT Project, Data, 2021-2026. https://www.gdeltproject.org/data.html
17. Ministère de l’Enseignement supérieur et de la Recherche, données ouvertes ESR, 2026. https://data.enseignementsup-recherche.gouv.fr/
18. S. Gilbert, N. Lynch, Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services, ACM SIGACT News, 2002. DOI 10.1145/564585.564601.
19. S. Ghemawat, H. Gobioff, S.-T. Leung, The Google File System, SOSP, 2003. DOI 10.1145/945445.945450.
20. G. DeCandia et al., Dynamo: Amazon’s Highly Available Key-value Store, SOSP, 2007. DOI 10.1145/1294261.1294281.
21. S. A. Weil et al., Ceph: A Scalable, High-Performance Distributed File System, OSDI, 2006.
22. A. G. Dimakis et al., Network Coding for Distributed Storage Systems, IEEE Trans. Information Theory, 2010. DOI 10.1109/TIT.2010.2054295.
23. C. Huang et al., Erasure Coding in Windows Azure Storage, USENIX ATC, 2012.
24. Z. Shen et al., A Survey of the Past, Present, and Future of Erasure Coding for Storage Systems, ACM Trans. on Storage, 2025. DOI 10.1145/3708994.
25. L. Moreau, P. Missier (éds.), PROV-DM: The PROV Data Model, W3C Recommendation, 2013. https://www.w3.org/TR/prov-dm/
26. P. Buneman, S. Khanna, W.-C. Tan, Why and Where: A Characterization of Data Provenance, ICDT, 2001. DOI 10.1007/3-540-44503-X_20.
27. R. D. Peng, Reproducible Research in Computational Science, Science, 2011. DOI 10.1126/science.1213847.
28. M. D. Wilkinson et al., The FAIR Guiding Principles for scientific data management and stewardship, Scientific Data, 2016. DOI 10.1038/sdata.2016.18.
29. D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS, 2015.
30. M. Schlegel, K.-U. Sattler, Capturing end-to-end provenance for machine learning pipelines, Information Systems, 2025. DOI 10.1016/j.is.2024.102495.
31. S. Couture, S. Toupin, What does the notion of « sovereignty » mean when referring to the digital?, New Media & Society, 2019. DOI 10.1177/1461444819865984.
32. B. Otto, M. Jarke, Designing a multi-sided data platform: findings from the International Data Spaces case, Electronic Markets, 2019. DOI 10.1007/s12525-019-00362-x.
33. C. Gentry, Fully Homomorphic Encryption Using Ideal Lattices, STOC, 2009. DOI 10.1145/1536414.1536440.
34. O. Goldreich, S. Micali, A. Wigderson, How to Play ANY Mental Game, STOC, 1987. DOI 10.1145/28395.28420.
35. S. Torres-Arias et al., in-toto: Providing Farm-to-Table Guarantees for Bits and Bytes, USENIX Security, 2019.
36. W. Shi et al., Edge Computing: Vision and Challenges, IEEE Internet of Things Journal, 2016. DOI 10.1109/JIOT.2016.2579198.
37. E. Masanet et al., Recalibrating global data center energy-use estimates, Science, 2020. DOI 10.1126/science.aba3758.
38. P. Wiesner et al., Let’s Wait Awhile: How Temporal Workload Shifting Can Reduce Carbon Emissions in the Cloud, Middleware, 2021. DOI 10.1145/3464298.3493399.