ADR-003 : Cadre de sélection du fournisseur de compute

Statut

Accepté — 2026-04-16

Cette ADR ne tranche pas le choix de vendor. Elle fixe le cadre (critères, pondération implicite, seuils, calendrier de décision) qui servira à trancher dans une ADR-004 ultérieure, quand les PoCs et les retours de négociation auront nourri la décision.

Contexte

Le Master MaQI ouvre en septembre 2026. Le stockage est résolu : Wasabi S3 eu-central-1 (cf. docs/wasabi/, ADR-001). Reste le compute, où 7 vendors sont actuellement cartographiés dans docs/compute/ (GCP, AWS, Azure, Nebius, OVHcloud, S3NS, FluidStack).

Trois facteurs rendent cette décision non-triviale :

1. Charge mixte CPU + GPU — le besoin MaQI est majoritairement CPU (market data, time series, point-in-time), avec un filet de GPU marginal (1 cours de M2 sur les diffusion models, LLMs légers pour le textuel financier). Les fournisseurs du marché sont majoritairement GPU-first.
2. Pattern d'usage burst + long-terme — étudiants concentrés sur 1-2 semaines avant les exams (pic CPU intense), enseignants en usage régulier long (préparation, recherche). Classique dimensionnement "réservé + on-demand".
3. Dynamique de marché egress 2024-2027 — voir docs/compute/cost-model.md. Les tarifs egress sont sous pression régulatoire (EU Data Act, suppression switching charges le 12 janvier 2027) et concurrentielle (neoclouds, acteurs souverains EU). Le différentiel est matériel aujourd'hui (~€600/an pour MaQI), structurellement temporaire à l'horizon 2027.

Une semaine de tour d'horizon vendor a eu lieu 14-17 avril 2026 : Nebius (call 16/04 avec Mankaran Ahluwalia), Gradium (désambigüé — pas un vendor compute, voir docs/compute/README.md), S3NS (meeting programmé 17/04, call de confiance Polytechnique), OVHcloud (déjà utilisé en production pour le stream S&P Global via VM 135.125.134.132).

Sans cadre partagé, la décision risque de pencher vers la familiarité (OVH car déjà en prod) ou vers le branding (Nebius = provider de Yann LeCun) plutôt que vers un critère objectivé.

Décision

1. Six axes de sélection, avec priorisation explicite

Repris et élargis depuis docs/compute/README.md §Axes de décision. L'ordre exprime la priorité en cas d'arbitrage :

flowchart TB
    A1["1. Coût réseau / egress<br>(cost-model.md, ~€600/an MaQI)"]
    A2["2. Souveraineté / RGPD<br>(licence S&P non-redistribution)"]
    A3["3. Proximité Wasabi<br>(eu-central-1 Frankfurt)"]
    A4["4. Notebook-first<br>(UX étudiants, 40 comptes)"]
    A5["5. Credits recherche / OCRE<br>(enveloppe Master)"]
    A6["6. Multi-provider via Terraform<br>(cible Athena-like CAL)"]
    A1 --> A2 --> A3 --> A4 --> A5 --> A6
    style A1 fill:#ffd,stroke:#cc0
    style A2 fill:#ffd,stroke:#cc0
    style A6 fill:#eef,stroke:#448

1 — Coût réseau / egress (critère dominant 2026)

La projection annuelle MaQI est de ~8 TB d'egress côté compute (résultats étudiants vers Wasabi + téléchargements locaux). Différentiel 2026 :

• Bandwidth-included (OVH, Hetzner, Nebius) : ~€0/an
• Hyperscalers + S3NS (si GCP-like) : ~€600–680/an

Ce critère est dominant tant que nous sommes avant le 12 janvier 2027 (Data Act UE) et que les budgets Master sont contraints.

2 — Souveraineté / RGPD

Contrainte explicite de CAL (docs/cal/tech-solutions.md C1) : non-redistribution des données S&P Global, stockage et traitement dans une juridiction EU. SecNumCloud 3.2 (S3NS) apporte un atout additionnel "trust labélisé" mais n'est pas une exigence contractuelle du programme MaQI à date.

3 — Proximité Wasabi

Wasabi est en eu-central-1 (Frankfurt). Les vendors avec une région à Francfort ou Amsterdam (OVH SBG/FR, AWS eu-central-1, Azure westeurope, S3NS FR via GCP europe-west) sont préférés pour la latence de lecture S3.

4 — Notebook-first

Le Master cible 40 étudiants (25 M1 + 25 M2 la 3e année). L'infrastructure doit minimiser le setup. Colab (GCP), SageMaker Studio (AWS), AI Notebooks (OVH), Azure ML Studio sont les candidats natifs. FluidStack et Nebius nécessitent un déploiement JupyterHub par l'équipe infra.

5 — Credits recherche / canaux institutionnels

• GCP : Google Cloud Research program (~$5K/chercheur).
• AWS : AWS Research rolling.
• Azure : Azure for Research.
• Nebius : Academy Program (contact interne Artem, à sync après AI Day Amsterdam).
• OVHcloud : fournisseur contracté OCRE 2024 (framework européen recherche/éducation coordonné GÉANT / RENATER, 2024-2029) + Startup Program (~€100K incluant Fast Forward AI Accelerator €50K GPU).
• S3NS : pas de programme standard recherche connu ; à qualifier au meeting 17/04.

6 — Multi-provider via Terraform

Cible architecturale exprimée par CAL : une pile Athena-like server-less redéployable sur \(\geq\) 2 providers. Privilégie les stacks à API ouverte (S3-compatible, Kubernetes, Trino/Presto) sur les services propriétaires (BigQuery, Synapse, Redshift natif).

2. Contraintes d'éligibilité (non-négociables)

Reprises des docs/cal/tech-solutions.md + ADR-002 §3 :

• E1 — Juridiction EU. Tout compute manipulant les données S&P, Databento, RavenPack, CausalityLink, GDELT doit résider en UE.
• E2 — S3-compatible. Lecture Wasabi sans transformation ni copie régionale.
• E3 — Bandwidth-included OU plafond egress négocié. Sur l'horizon 2026, l'egress non-maîtrisé sort du critère de décision et devient un risque budgétaire.
• E4 — Notebook-compatible. Soit notebook natif, soit déploiement JupyterHub trivial via les templates standard.
• E5 — Facturation transparente. Pas de frais cachés, pas de sortie à péage bloquante (le Data Act UE rend ce dernier juridiquement limité, mais reste une vigilance contractuelle 2026-2027).

3. Calendrier de décision

4. Anti-patterns à éviter

• "Choisir parce que c'est celui que j'utilise déjà" — OVH est en prod pour le stream S&P mais cela n'est pas, en soi, une raison de l'étendre à l'ensemble du Master. Le stream est un usage isolé, la décision Master doit se faire sur les 6 axes.
• "Choisir par branding" — l'effet "Nebius = Yann LeCun" ou "S3NS = Thales \(\times\) Google" est un atout latéral pour le narratif Master, pas un critère opérationnel.
• "Choisir un seul vendor définitivement" — l'axe 6 (multi-provider Terraform) n'est pas une option de décor. La portabilité doit être préservée dans la décision, au moins au niveau du design. ADR-004 pourra acter un vendor principal et un vendor secondaire.
• "Optimiser pour l'egress post-2027" — au 12 janvier 2027 le Data Act UE nivelle ce critère. Décider aujourd'hui comme si l'egress restait un différentiateur éternel serait une erreur stratégique. L'axe 1 a un horizon fini et documenté.

Conséquences

Positives

• Clarté partagée entre Emmanuel, Charles-Albert, Wissal sur ce qui fera tranche et ce qui ne fera pas.
• Traçabilité entre les fiches docs/compute/<vendor>.md et la décision finale (ADR-004).
• Anti-patterns explicites = filet de sécurité contre les biais cognitifs de fin de semaine (1h avant le meeting S3NS).

Négatives

• Le critère "Coût réseau / egress" en #1 peut paraître sévère envers les hyperscalers US (GCP/AWS/Azure). Il est pondéré par l'horizon 2027 mais peut, dans un débat rapide, caricaturer la position de fond.

Action à envisager

• Ouvrir ADR-004 — Compute vendor choice fin mai, une fois les PoCs et l'enveloppe compute chiffrés.
• Formaliser le sizing compute MaQI (CPU-hours/mois par étudiant, GPU-hours par cours, RAM moyenne, stockage temp) dans un docs/compute/sizing.md dédié — pas de décision vendor sans chiffrage.

Références

• ADR-001 — Réconciliation des données primaires
• ADR-002 — Cartographie des sources de données
• docs/compute/README.md — landing page compute, 6 axes de décision
• docs/compute/vendors.yaml — source of truth machine-readable, 7 entrées
• docs/compute/cost-model.md — modèle de coût, projection S&P, dynamique de marché 2024-2027
• docs/cal/tech-solutions.md — contraintes CAL (non-redistribution, S3, Athena-like)
• docs/wasabi/state.md — état Wasabi (régions, volumes, coûts storage)