Lean-15 : Hommage a Alexandre Grothendieck – Le langage grothendieckien dans Mathlib 4

Navigation : << Lean-14 Finiteness-Derivatives | Lean-16b Conway Tribute >> | Index

Kernel : Python 3 (Mathlib excerpts shown via subprocess -> WSL lean)


On peut tout faire pourvu qu’on prenne le temps de comprendre les choses. – A. Grothendieck

Introduction : pourquoi Grothendieck dans une serie Lean ?

Alexandre Grothendieck (1928-2014) a refonde la geometrie algébrique entre 1958 et 1970 autour de l’IHES (Bures-sur-Yvette), en collaboration avec Jean Dieudonne et un nombre considerable d’eleves. Son langage – catégories, foncteurs, foncteurs derives, sites, faisceaux, schemas, topos – a transforme l’ensemble des mathematiques. Les milliers de pages des EGA (Éléments de Geometrie Algébrique) et SGA (Seminaire de Geometrie Algébrique du Bois-Marie) sont la trace ecrite de ce programme.

Cet hommage ne pretend pas formaliser EGA ou SGA. Le but est plus modeste, mais réel : montrer comment une partie du langage grothendieckien est déjà accessible dans Mathlib 4. Si vous suivez la serie Lean (Lean-2 a Lean-6, Lean-10 LeanDojo), vous avez vu les fondations : types dependants, propositions, tactiques, Mathlib. On va voir maintenant que ces fondations donnent acces a Grothendieck.

Ce que vous saurez a la fin

  1. Reconnaitre les structures categoriques de Mathlib qui implementent les idees de Grothendieck (cribles, sites, topologies de Grothendieck, faisceaux).
  2. Localiser dans Mathlib les définitions de schema (AlgebraicGeometry.Scheme), de spectre (Spec), du site de Zariski et des propriétés locales de morphismes (etale, lisse, separe).
  3. Distinguer ce qui est déjà la (exploitable pedagogiquement), ce qui est partiel (utile avec precautions), et ce qui est hors-scope Mathlib 4 actuel (cohomologie etale ℓ-adique, motifs, six opérations, GRR).
  4. Lire les enonces des théorèmes grothendieckiens dans la syntaxe Lean 4 / Mathlib.

Prerequis

  • Familiarite avec Lean 4 et Mathlib (cf Lean-1 a Lean-6).
  • Notions de base de théorie des catégories (objet, morphisme, foncteur, transformation naturelle). Aucune connaissance prealable de geometrie algébrique n’est requise pour comprendre les enonces.
  • Sympathie pour le projet de comprendre une chose en la plongeant dans le contexte le plus général qui la rend naturelle (la phrase est de Grothendieck).

Duree estimée : 60 minutes

Note technique sur l’exécution

Ce notebook utilise un kernel Python 3. Les sources Lean sont lues directement depuis le projet grothendieck_lean/ qui accompagne ce notebook (même repertoire). Ce projet Lake contient des modules sous Grothendieck/ formalisant des tours pedagogiques de Mathlib (catégories, cribles, schemas, Zariski, calibration, mais aussi faisceaux, faisceautisation, cohomologie par Ext, Mayer-Vietoris et Cech). Le build (lake build Grothendieck) est lance en WSL via subprocess, avec vérification de l’absence de sorry. Ce pattern est emprunte aux notebooks Lean-13/16 (Kochen-Specker/Conway).

Pour les exercices interactifs, run_lean(snippet) ecrit un snippet temporaire et l’exécute dans l’environnement Lake du projet, ce qui donne acces a tout Mathlib.

La mer qui monte : la méthode Grothendieck

La mer qui monte, montant, montant encore, decomposant les structures les plus solides, les reduisant peu a peu en un liquide de plus en plus fluide, jusqu’a ce qu’elles se dissolvent dans l’ocean. – Alexandre Grothendieck, Recoltes et Semailles (1986)

La mer qui monte, ou l’art de dissoudre le problème

La metaphoric de la mer qui monte resume la méthode de Grothendieck. Face a un problème tenace (un “rocher” qui resiste), l’instinct classique est de forcer la noix avec un marteau – trouver la bonne astuce, lafeu le bon coup de genie. Grothendieck nous propose une autre voie : laisser la mer monter. La mer, ce sont les concepts. Plus on généralise, plus on dissout le problème dans un contexte assez vaste pour qu’il perde sa substance. Ce qui etait un obstacle devient un cas particulier evident d’une théorie plus profonde.

Je n’ai pas force la noix. J’ai attendu que la mer monte assez pour la dissoudre. – Grothendieck, paraphrasant sa propre pratique

Le style Grothendieck : generalite qui eclaire vs marteau qui force

Le style grothendieckien se distingue par la recherche systématique du bon niveau de generalite. La generalite n’est pas un but en soi : c’est un outil qui rend les théorèmes profonds presque triviaux une fois bien encadres. Trois traits caractéristiques :

  1. Plonger le problème dans un contexte plus vaste. Un théorème sur les varietes devient un théorème sur les schemas, puis sur les topos. A chaque generalisation, le contenu de la preuve originelle se dissout dans des arguments structurels plus simples.
  2. Inventer le langage qui rend la preuve inevitable. Avant Grothendieck, on “faisait” de la geometrie algébrique. Après lui, on parle une langue dans laquelle les enonces deviennent tautologiques. La topologie de Grothendieck, les cribles, les sites ne sont pas des “outils” au sens du marteau : ce sont des terres gagnees sur la mer.
  3. Renoncer a la vertu de la difficulte. Un théorème difficile est souvent un théorème mal place. La difficulte signale qu’on n’a pas encore trouve le bon point de vue.

Ce que ca veut dire en pratique (pour nous, avec Lean)

Quand on formalise en Lean / Mathlib, on pratique une forme de cette méthode :

  • Trouver la bonne structure (le bon type) : dire “soit C une catégorie avec limites”, pas “soit un ensemble avec telle opération”.
  • Enoncer le théorème a la bonne generalite : le lemme de Yoneda s’applique a toute catégorie locale, pas seulement a un cas particulier.
  • Laisser le contexte faire le travail : une fois la bonne topologie de Grothendieck choisie, les faisceaux, la cohomologie, les morphismes etales viennent “naturellement”.

Le notebook qui suit est un hommage depuis Lean : il montre que la langue de Grothendieck (catégories, sites, schemas) est assez naturelle dans Mathlib 4 pour qu’on puisse s’y promener pedagogiquement.

Pourquoi “Recoltes et Semailles”

Le titre Recoltes et Semailles (1985-1986, manuscrit de 9000 pages) est la meditation retrospective de Grothendieck sur sa propre méthode. La metaphoric agricole est explicite :

Les idees fécondes se sement, se cultivent, et se recoltent ; le mathematicien est d’abord un agriculteur patient.

Cette patiente est l’oppose du coup de force. Le present notebook pretend modestement illustrer la semence – non la recolte.


La marée montante, dans la correspondance elle-même — deux témoignages du dialogue Serre–Connes (« À propos de la correspondance Grothendieck-Serre », dialogue J.-P. Serre / Alain Connes, Fondation Hugot du Collège de France, 2019 (YouTube pOv-ygSynPI)) :

« Et Grothendieck, je pense que c’était la première fois que Grothendieck appliquait sa méthode, que Serre a décrite comme étant, pour résoudre des problèmes, il faut les laisser se dissoudre dans une marée montante de théorie générale. C’était un sujet qui était un peu bouché quand même. On a eu l’impression qu’il avait résolu à peu près toutes les questions faites, pas tout à fait vrai. Il y avait des contre-exemples à trouver. » (Connes, 01:14 — la première mise en œuvre de la méthode : la thèse sur les espaces vectoriels topologiques)

« Tu décris quelque part ton approche des maths où l’on n’attaque pas un problème de front, mais où on l’enveloppe et le dissout dans une marée montante de théories générales. […] ce que tu as fait montre que cela marche effectivement, du moins pour les EVT et la géométrie algébrique. » (lettre de Serre à Grothendieck, lue par Connes à 34:34)

(transcription automatique, noms propres corrigés : Grothendieck, Dieudonné, Banach). La métaphore de la mer qui monte n’est pas une image posthume : c’est ainsi que Serre décrivait à Grothendieck sa propre méthode, dès la thèse sur les espaces vectoriels topologiques — et la suite de ce carnet (faisceaux, sites, topologie de Grothendieck) est précisément cette marée, montée.

Les limites de la marée : trois fragilités, trois leçons pour ce dépôt

La lettre que Serre adresse à Grothendieck à la réception de Récoltes et Semailles (1986) — lue par Alain Connes dans l’entretien du Collège de France — décrit la méthode de la marée montante de l’extérieur, et en montre les limites. Pour un dépôt placé sous ce parrainage, ces fragilités ne sont pas des ragots biographiques : chacune nomme un risque que nos propres règles existent pour fermer.

1. L’œuvre portée à bout de bras. Serre : « Tu t’étonnes et tu t’indignes de ce que tes anciens élèves n’aient pas continué. […] Mais tu ne te poses pas la question la plus évidente, celle à laquelle tout lecteur s’attend à ce que tu répondes. Pourquoi, toi, tu as abandonné l’œuvre en question ? » (lettre lue à [31:35] de l’entretien). La marée montante exigeait une énergie que même Grothendieck n’a pas pu soutenir : l’œuvre portée seule, des milliers de pages. Leçon dépôt : la vérification se partage (CI, reviews, gates) précisément pour ne pas dépendre de l’énergie d’un seul porteur.

2. Affirmer sans preuve. Serre décrit l’état « plutôt désastreux » de SGA5 : un rédacteur « s’excuse de ne pas avoir été capable de vérifier la commutativité du diagramme », commutativités « essentielles pour la suite » ; et de conclure : on peut détecter une erreur, « mais ça ne veut pas dire qu’on a une démonstration » [33:02–34:12]. Leçon dépôt : la cellule de vérification juste en dessous — zéro sorry dans les modules — est la réponse institutionnelle exacte à cette dérive : ce qui n’est pas vérifié n’est pas démontré, fût-il « évidemment vrai vu les résultats ».

3. L’angle mort du cadre. La lettre : la méthode « marche effectivement, du moins pour les EVT et la géométrie algébrique », mais est « beaucoup moins claire pour la théorie des nombres » [34:42]. Et Serre, sur les formes modulaires : « Il n’avait rien compris aux formes modulaires. […] quand ça ne rentrait pas dans son cadre […] tes formes modulaires, ça n’a aucun sens » — « il ne peut pas supporter les formules » [35:02–35:41]. Ce que le cadre n’absorbe pas n’est pas pour autant dénué de sens : c’est la direction orthogonale du programme de Langlands (Epic #17969). Leçon dépôt : quand un résultat « n’a aucun sens » dans notre cadre, c’est le cadre qu’il faut interroger — culture du contre-exemple et du doute avant le rapport.

Sources primaires (transcriptions complètes timestampées, hors dépôt) : G:\Mon Drive\MyIA\IA\Bibliographie IA\NumberTheory\2019 - Serre & Connes - Correspondance Grothendieck-Serre (College de France, transcription YouTube pOv-ygSynRI).md ; première vague de distillation : PR #17943, issue #17889.

« Is Peter Scholze more like Grothendieck? » – question de l’entretien The most magical subject in math (R. Borcherds, 2026, [2:28:14]) : la relève de la marée montante se joue au même dilemme – théories générales ou voies calculées. Borcherds, lui, place Ramanujan à l’exact opposé de Grothendieck : « Ramanujan consists entirely of examples and calculations » [2:27:46].

import subprocess
import textwrap
import re
import os
import shutil
import tempfile
from pathlib import Path

# --- Path resolution: find the grothendieck_lean Lake project ---
# Must work both interactively (CWD = repo root) and under Papermill (CWD may differ).

def find_grothendieck_lean_project():
    """Find the grothendieck_lean Lake project directory.

    Searches from multiple starting points to handle both interactive use
    and Papermill exécution (where CWD may differ from notebook location).
    Returns an ABSOLUTE path.
    """
    starts = [Path.cwd().resolve()]

    nb_file = os.environ.get('NB_FILE') or globals().get('__vsc_ipynb_file__')
    if nb_file:
        starts.append(Path(nb_file).resolve().parent)

    for start in starts:
        current = start
        for _ in range(10):
            candidate = current / 'grothendieck_lean'
            if candidate.exists() and (candidate / 'lakefile.lean').exists():
                return candidate.resolve()
            current = current.parent
            if current == current.parent:
                break
    raise FileNotFoundError("grothendieck_lean/ not found -- check working directory")

def win_to_wsl(win_path: Path) -> str:
    """Convert Windows path to WSL path using drive letter."""
    p = win_path.resolve()
    drive_letter = p.drive
    if not drive_letter or len(drive_letter) < 2:
        s = str(p)
        if s.startswith('/mnt/'):
            return s
        return s
    drive = drive_letter[0].lower()
    return f'/mnt/{drive}{p.as_posix()[2:]}'

WIN_LEAN_PROJECT = find_grothendieck_lean_project()
LEAN_PROJECT = win_to_wsl(WIN_LEAN_PROJECT)

# Chemins portables dans les sorties : le prefixe absolu varie par machine
# (D:\... ou /mnt/d/...) et n'a pas sa place dans un output commite.
REPO_RELATIVE_PROJECT = '<repo>/MyIA.AI.Notebooks/SymbolicAI/Lean/grothendieck_lean'

def sanitize_lean_paths(text):
    variants = {str(WIN_LEAN_PROJECT), str(WIN_LEAN_PROJECT).replace('\\', '/'), LEAN_PROJECT}
    for v in sorted(variants, key=len, reverse=True):
        if v:
            text = text.replace(v, REPO_RELATIVE_PROJECT)
    return text
USE_NATIVE_LEAN = shutil.which('lake') is not None and os.name != 'nt'

def wsl(cmd, timeout=60):
    """Run a bash command inside WSL Ubuntu when available.

    Captures stdout/stderr via temp files rather than capture_output=True, to
    avoid the CPython ``_readerthread`` race on Windows that silently dropped
    subprocess output (the committed cells 25-27 previously showed only an
    ``Exception in thread (_readerthread)`` trace instead of Lean output).
    """
    # pipefail (#17616) : sans lui, le rc d'un pipeline bash est celui de la
    # DERNIERE commande (tail) -- un `lake build ... 2>&1 | tail -20` echoue
    # alors avec rc=0 et l'appelant affirmerait SUCCESS sur une build ratee.
    full = ['wsl', '-d', 'Ubuntu', '--', 'bash', '-lc', 'set -o pipefail; ' + cmd]
    out_f = tempfile.NamedTemporaryFile('wb', delete=False, suffix='.out')
    err_f = tempfile.NamedTemporaryFile('wb', delete=False, suffix='.err')
    out_path, err_path = out_f.name, err_f.name
    out_f.close()
    err_f.close()
    try:
        with open(out_path, 'wb') as o, open(err_path, 'wb') as e:
            r = subprocess.run(full, stdout=o, stderr=e, timeout=timeout)
        out = Path(out_path).read_text(encoding='utf-8', errors='replace')
        err = Path(err_path).read_text(encoding='utf-8', errors='replace')
        return r.returncode, out, err
    except FileNotFoundError:
        return 127, '', 'WSL executable not found'
    except subprocess.TimeoutExpired:
        return -1, '', f'TIMEOUT after {timeout}s'
    finally:
        for p in (out_path, err_path):
            try:
                Path(p).unlink()
            except OSError:
                pass

# --- Lean file reading ---

def read_lean_module(module_name):
    """Read a .lean source file from the grothendieck_lean project.

    module_name: e.g. 'CategoryAndSites' -> reads Grothendieck/CategoryAndSites.lean
    Returns the file content as a string.
    """
    path = WIN_LEAN_PROJECT / 'Grothendieck' / f'{module_name}.lean'
    if not path.exists():
        return f'[FICHIER INTROUVABLE] {REPO_RELATIVE_PROJECT}/Grothendieck/{module_name}.lean'
    return path.read_text(encoding='utf-8')

def display_lean_module(module_name, max_lines=None, highlight=None):
    """Display a .lean source file with line numbers.

    max_lines: if set, only show the first N lines
    highlight: list of line numbers to mark with '>>>' (1-indexed)
    """
    content = read_lean_module(module_name)
    if content.startswith('[FICHIER INTROUVABLE]'):
        print(content)
        return
    lines = content.splitlines()
    if max_lines:
        lines = lines[:max_lines]
    highlight = set(highlight or [])
    print(f'--- Grothendieck/{module_name}.lean ---')
    for i, line in enumerate(lines, 1):
        marker = ' >>>' if i in highlight else '    '
        print(f'{marker} {i:>3d} | {line}')
    total = len(content.splitlines())
    if max_lines and total > max_lines:
        print(f'    ... ({total - max_lines} lignes restantes sur {total} total)')
    print(f'--- fin ({total} lignes) ---')

# --- Lake build ---

def run_lake_build(targets='Grothendieck', timeout=1500):
    """Run lake build against the grothendieck_lean project."""
    if USE_NATIVE_LEAN:
        try:
            r = subprocess.run(
                ['lake', 'build', targets],
                cwd=WIN_LEAN_PROJECT,
                capture_output=True,
                text=True,
                timeout=timeout,
            )
            return r.returncode, sanitize_lean_paths(r.stdout or ''), sanitize_lean_paths(r.stderr or '')
        except subprocess.TimeoutExpired:
            return -1, '', f'TIMEOUT after {timeout}s'
    rc, out, err = wsl(
        f'source ~/.elan/env 2>/dev/null; cd {LEAN_PROJECT} && lake build {targets} 2>&1 | tail -20',
        timeout=timeout,
    )
    return rc, sanitize_lean_paths(out or ''), sanitize_lean_paths(err or '')

# --- Lean snippet exécution ---

def run_lean(snippet, timeout_s=300):
    """Run a Lean snippet against the grothendieck_lean project using lake env lean.

    The snippet is written to a temp file and executed with the project's Lake env.
    Returns combined stdout+stderr.
    """
    snippet = textwrap.dedent(snippet).strip() + '\n'
    if USE_NATIVE_LEAN:
        with tempfile.NamedTemporaryFile('w', suffix='.lean', delete=False, encoding='utf-8') as tmp:
            tmp.write(snippet)
            tmp_path = tmp.name
        try:
            r = subprocess.run(
                ['lake', 'env', 'lean', tmp_path],
                cwd=WIN_LEAN_PROJECT,
                capture_output=True,
                text=True,
                timeout=timeout_s,
            )
            return sanitize_lean_paths((r.stdout or '') + (r.stderr or ''))
        except subprocess.TimeoutExpired:
            return f'TIMEOUT after {timeout_s}s'
        finally:
            try:
                Path(tmp_path).unlink()
            except OSError:
                pass

    write_cmd = f"cat > /tmp/lean13_snippet.lean << 'LEAN_EOF'\n{snippet}LEAN_EOF"
    lean_cmd = f'cd {LEAN_PROJECT} && lake env lean /tmp/lean13_snippet.lean 2>&1'
    full_cmd = f'{write_cmd}\n{lean_cmd}'
    rc, out, err = wsl(full_cmd, timeout=timeout_s)
    if rc == -1:
        return f'TIMEOUT after {timeout_s}s'
    return sanitize_lean_paths((out or '') + (err or ''))

# --- Module inventory ---

GROTHENDIECK_MODULES = {
    'CategoryAndSites': 'Part 1: Sieves, topologies, 3 axioms',
    'SchemesTour': 'Part 2: Scheme, Spec, Gamma',
    'ZariskiSite': 'Part 3: Zariski pretopology, bridge theorem',
    'MathlibMap': 'Part 4: #check index Mathlib',
    'Calibration': 'Part 5: 4 micro-preuves P1-P4',
    'SieveLattice': 'Part 6: Pullback identities',
    'SheafBasics': 'Part 7: Sheaves, sheaf condition',
    'SieveOps': 'Part 8: Sieve lattice opérations',
    'CoverageGen': 'Part 9: Coverage generators',
    'CanonicalProps': 'Part 10: Canonical topology properties',
    'SieveGenerate': 'Part 11: Sieve generation',
    'DenseTopology': 'Part 12: Dense topology',
    'Sheafification': 'Part 13: Sheafification functor (Mathlib bridge)',
    'LeftExact': 'Part 14: Left exactness of sheafification',
    'SitePoints': 'Part 15: Points of a site',
    'Subcanonical': 'Part 16: Subcanonical topologies, Yoneda sheaves',
    'SheafHom': 'Part 17: Sheaf hom, internal hom',
    'ConstantSheaf': 'Part 18: Constant sheaf, adjunction',
    'Conservative': 'Part 19: Conservative families of points',
    'SheafCohomology/Basic': 'Part 20: Ext-based sheaf cohomology H^n',
    'MayerVietorisSquare': 'Part 21: Mayer-Vietoris squares',
    'SheafCohomology/MayerVietoris': 'Part 22: Mayer-Vietoris long exact sequence',
    'SheafCohomology/Cech': 'Part 23: Cech cohomology complex',
}

# Verify project is accessible
assert (WIN_LEAN_PROJECT / 'lakefile.lean').exists(), 'grothendieck_lean/lakefile.lean not found'
mode = 'native lake env lean' if USE_NATIVE_LEAN else 'WSL lake env lean'
print(f'Setup OK : grothendieck_lean project trouve a {REPO_RELATIVE_PROJECT}')
print(f'  Exécution Lean : {mode}')
print(f'  {len(GROTHENDIECK_MODULES)} modules Grothendieck detectes')
Setup OK : grothendieck_lean project trouve a <repo>/MyIA.AI.Notebooks/SymbolicAI/Lean/grothendieck_lean
  Exécution Lean : WSL lake env lean
  23 modules Grothendieck detectes
# Verification : le projet grothendieck_lean est accessible et build sans sorry
import re
sorry_count = 0
for mod_name in GROTHENDIECK_MODULES:
    content = read_lean_module(mod_name)
    # Remove block comments (/- ... -/) and line comments (-- ...)
    stripped_content = re.sub(r'/-.*?-/', '', content, flags=re.DOTALL)
    stripped_content = re.sub(r'--.*$', '', stripped_content, flags=re.MULTILINE)
    for line in stripped_content.splitlines():
        if 'sorry' in line.strip():
            sorry_count += 1
print(f"Verification OK : {len(GROTHENDIECK_MODULES)} modules detectes, {sorry_count} sorry en code de production")
print(f"Modules : {', '.join(GROTHENDIECK_MODULES.keys())}")
total_lines = sum(len(read_lean_module(m).splitlines()) for m in GROTHENDIECK_MODULES)
print(f"Total : {total_lines} lignes Lean")
print()

# Lake build : validation formelle complete (optionnel, ~15 min au premier build)
# De-commentez la ligne suivante pour lancer le build complet :
# rc, out, err = run_lake_build('Grothendieck', timeout=1500)
# print(f"lake build Grothendieck : returncode={rc}")
# if rc == 0:
#     print("BUILD SUCCESS : tous les modules compilent sans erreur.")
# else:
#     print(out[-500:] if len(out) > 500 else out)

print("Pour lancer le build complet (validation formelle) :")
print(f"  wsl -d Ubuntu -- bash -lc \"cd {REPO_RELATIVE_PROJECT} && lake build Grothendieck\"")
print()
print("Note : le contenu pedagogique du notebook (display_lean_module) fonctionne sans build.")
Verification OK : 23 modules detectes, 0 sorry en code de production
Modules : CategoryAndSites, SchemesTour, ZariskiSite, MathlibMap, Calibration, SieveLattice, SheafBasics, SieveOps, CoverageGen, CanonicalProps, SieveGenerate, DenseTopology, Sheafification, LeftExact, SitePoints, Subcanonical, SheafHom, ConstantSheaf, Conservative, SheafCohomology/Basic, MayerVietorisSquare, SheafCohomology/MayerVietoris, SheafCohomology/Cech
Total : 5649 lignes Lean

Pour lancer le build complet (validation formelle) :
  wsl -d Ubuntu -- bash -lc "cd <repo>/MyIA.AI.Notebooks/SymbolicAI/Lean/grothendieck_lean && lake build Grothendieck"

Note : le contenu pedagogique du notebook (display_lean_module) fonctionne sans build.

1. Catégories et foncteurs : la fondation

Tout le langage grothendieckien repose sur la théorie des catégories. Une catégorie est un type d’objets muni de morphismes composables avec identites. Un foncteur entre deux catégories preserve cette structure. Mathlib formalise ces notions dans Mathlib.CategoryTheory.*.

Le foncteur le plus important pour Grothendieck est probablement le plongement de Yoneda : il identifie chaque objet c d’une catégorie C au foncteur Hom(-, c). Cette identification, en apparence anodine, est le moteur de l’enonce “un schema est un foncteur representable sur la catégorie des anneaux” (la définition fonctorielle des schemas, parallele a la définition geometrique).

« I had no idea this was true, but functors were defined before categories. » – R. Borcherds [2:36:35] – anecdote historique pour cette fondation : les foncteurs précèdent le langage qui les théorise, exactement comme les formes modulaires précèdent leur interprétation géométrique.

# Verification : Functor et yoneda dans Mathlib
display_lean_module('MathlibMap', highlight=[1, 2, 3, 4, 5])
--- Grothendieck/MathlibMap.lean ---
 >>>   1 | /-
 >>>   2 | Copyright (c) 2026 CoursIA. All rights reserved.
 >>>   3 | Released under Apache 2.0 license as described in the file LICENSE.
 >>>   4 | 
 >>>   5 | ## Partie 4 — `Grothendieck.MathlibMap` : Cartographie Mathlib
       6 | 
       7 | Un index vivant de ce que Mathlib 4 fournit depuis le langage mathématique
       8 | de Grothendieck. Chaque `#check` vérifie que la définition existe et est
       9 | accessible depuis les imports courants.
      10 | 
      11 | Epic #1646. Tous les `sorry`s éliminés à la création.
      12 | 
      13 | ### i18n — convention #4980 ratifiée 2026-07-04
      14 | 
      15 | Ce module est jumelé avec sa version anglaise canonique dans le fichier
      16 | sibling `MathlibMap_en.lean` (modèle sibling pair, voir PR #6154 pour le
      17 | pilote sur `Utility.lean`). Les énoncés `#check @...` restent en anglais
      18 | (Mathlib 4, tactic DSL standard) ; seules les **docstrings `/-- ... -/`** et
      19 | les **commentaires `-- ...`** diffèrent entre les deux fichiers. Anti-§D
      20 | byte-identity garanti : le namespace body est préservé bit-pour-bit (les
      21 | énoncés `#check` sont identiques entre `MathlibMap.lean` et `MathlibMap_en.lean`,
      22 | seuls les commentaires diffèrent).
      23 | -/
      24 | 
      25 | import Mathlib.CategoryTheory.Sites.Grothendieck
      26 | import Mathlib.CategoryTheory.Sites.SheafOfTypes
      27 | import Mathlib.AlgebraicGeometry.Scheme
      28 | import Mathlib.Topology.Sheaves.Sheaf
      29 | 
      30 | namespace Grothendieck
      31 | 
      32 | /-!
      33 | ## Fondements de la théorie des catégories (l'héritage de Grothendieck)
      34 | 
      35 | Grothendieck a fait de la théorie des catégories le langage de la géométrie
      36 | algébrique. Mathlib 4 dispose d'une riche bibliothèque de théorie des
      37 | catégories construite sur ces idées.
      38 | -/
      39 | 
      40 | -- Le lemme de Yoneda (fondamental pour les cribles et les faisceaux)
      41 | #check @CategoryTheory.yoneda            -- C ⥤ (Cᵒᵖ ⥤ Type v)
      42 | #check @CategoryTheory.coyoneda          -- (Cᵒᵖ ⥤ Type v) ⥤ C
      43 | 
      44 | /-!
      45 | ## Cribles et précaractères (Sieves et Presieves)
      46 | -/
      47 | 
      48 | #check @CategoryTheory.Presieve          -- Presieve X
      49 | #check @CategoryTheory.Sieve             -- Sieve X (sous-foncteur de yoneda.obj X)
      50 | #check @CategoryTheory.Sieve.pullback    -- pullback d'un crible le long d'un morphisme
      51 | #check @CategoryTheory.Sieve.arrows      -- le précaractère sous-jacent
      52 | 
      53 | /-!
      54 | ## Topologies de Grothendieck
      55 | -/
      56 | 
      57 | #check @CategoryTheory.GrothendieckTopology          -- la structure de topologie
      58 | #check @CategoryTheory.GrothendieckTopology.trivial  -- topologie la plus grossière
      59 | #check @CategoryTheory.GrothendieckTopology.discrete -- topologie la plus fine
      60 | #check @CategoryTheory.GrothendieckTopology.dense    -- topologie dense
      61 | 
      62 | /-!
      63 | ## Faisceaux
      64 | -/
      65 | 
      66 | -- Faisceaux de types sur un site
      67 | #check @CategoryTheory.Presieve.IsSheaf  -- condition de faisceau pour préfaisceaux en Type
      68 | #check @CategoryTheory.Presieve.IsSeparated  -- préfaisceau séparé
      69 | 
      70 | -- Faisceaux sur un espace topologique
      71 | #check @TopCat.Sheaf                     -- faisceau bundle sur un espace topologique
      72 | 
      73 | /-!
      74 | ## Géométrie algébrique : Schémas et Spec
      75 | -/
      76 | 
      77 | open AlgebraicGeometry CategoryTheory
      78 | 
      79 | -- Le type des schémas
      80 | #check Scheme                   -- le type des schémas
      81 | 
      82 | -- La construction Spec : des anneaux vers les espaces
      83 | #check Scheme.Spec              -- CommRingCatᵒᵖ ⥤ Scheme
      84 | 
      85 | -- Sections globales : des espaces vers les anneaux
      86 | #check Scheme.Γ                 -- Schemeᵒᵖ ⥤ CommRingCat
      87 | 
      88 | -- Foncteurs d'oubli
      89 | #check Scheme.forgetToTop       -- Scheme ⥤ TopCat
      90 | #check Scheme.forgetToLocallyRingedSpace  -- Scheme ⥤ LocallyRingedSpace
      91 | 
      92 | /-!
      93 | ## Ce que Mathlib n'a PAS ENCORE (état 2026-07)
      94 | 
      95 | Les concepts fondamentaux de Grothendieck qui ne sont PAS encore dans Mathlib :
      96 |   - Cohomologie étale (site étale, cohomologie l-adique)
      97 |   - Motifs (motifs purs, catégorie DM de Voevodsky)
      98 |   - Six opérations (formalisme complet de Grothendieck) — Mathlib ne fournit
      99 |     que l'instance de base `f^* ⊣ f_*` sur les faisceaux de modules
     100 |     (`AlgebraicGeometry.Modules.Sheaf`, indexée par `DirectImage.lean`). Le
     101 |     formalisme complet reste hors de Mathlib ; au niveau préfaisceau, cette lake
     102 |     a livré le triple `f_! ⊣ f^* ⊣ f_*` (Parties 34-35,
     103 |     `ExceptionalDirect.lean` / `ExceptionalTriple.lean`), et `f^!` s'y effondre
     104 |     sur `f^*` (`exceptionalInverse_collapses_to_pullback`) — il n'existe qu'avec
     105 |     la dualité de Verdier.
     106 |   - Grothendieck-Riemann-Roch
     107 |   - Dualité de Grothendieck
     108 |   - Cohomologie cristalline
     109 |   - Géométrie anabélienne
     110 |   - Résultats profonds EGA/SGA (EGA II-IV, SGA 1-7)
     111 | 
     112 | Ces cibles restent au niveau recherche en formalisation.
     113 | -/
     114 | 
     115 | /-!
     116 | ## Théorèmes-ponts
     117 | 
     118 | La section "Théorèmes propres" initialement prévue (4 lemmes sur
     119 | `CategoryTheory.yoneda`/`coyoneda`/`GrothendieckTopology.trivial`/
     120 | `Sieve`) a été retirée en c.1301+107 v3 (Lean CI FAIL sur le
     121 | polymorphisme d'univers — voir PR #10638 historique). Les `#check`
     122 | ci-dessus suffisent à valider que les noms canoniques Mathlib sont
     123 | accessibles depuis les imports courants. Les 12 lemmes propres
     124 | subsistent dans `Equivalences.lean` (4) + `MonoidalCategories.lean`
     125 | (4 lemmes PASS en CI) + leurs siblings `_en`.
     126 | -/
     127 | 
     128 | end Grothendieck
--- fin (128 lignes) ---

Interpretation : Functor et yoneda

Symbole Lean Lecture Idee grothendieckienne
CategoryTheory.Functor C D un foncteur de C vers D un “changement de point de vue” qui preserve la composition
CategoryTheory.yoneda foncteur C -> (C^op -> Type) plonge C dans la catégorie de ses pre-faisceaux

Le foncteur de Yoneda permet le lemme de Yoneda : il y a une bijection naturelle entre les transformations naturelles Hom(-, c) -> F et les éléments de F(c). Ce lemme est l’outil de base de tout argument categorique chez Grothendieck. Dans Mathlib, il s’enonce CategoryTheory.yonedaLemma.

2. Cribles et topologies de Grothendieck

La première véritable invention grothendieckienne formalisee dans Mathlib est la topologie de Grothendieck. Avant Grothendieck, une topologie sur un espace X etait un ensemble d’ouverts. Grothendieck a généralise : une topologie sur une catégorie est la donnée, pour chaque objet X, d’une collection de cribles couvrants – des sous-objets de Yoneda qui jouent le rôle des recouvrements ouverts.

Cette generalisation permet d’avoir des “topologies” la ou il n’y a pas d’espace topologique : sur la catégorie des schemas, sur celle des anneaux commutatifs, etc. Et donc des faisceaux sur ces catégories.

Dans Mathlib : - CategoryTheory.Sieve X : un crible sur l’objet X (un sous-foncteur de Hom(-, X)) - CategoryTheory.GrothendieckTopology C : une topologie de Grothendieck sur la catégorie C

# Verification : Sieve et GrothendieckTopology dans Mathlib
display_lean_module('CategoryAndSites', max_lines=40, highlight=[1, 2, 3, 4, 5, 6, 7, 8, 9, 10])
--- Grothendieck/CategoryAndSites.lean ---
 >>>   1 | /-
 >>>   2 | ## Catégories, cribles et topologies de Grothendieck (Partie 1 — hommage Grothendieck)
 >>>   3 | 
 >>>   4 | Hommage Grothendieck — Partie 1 : catégories sous-jacentes, cribles et
 >>>   5 | axiomes des topologies de Grothendieck.
 >>>   6 | 
 >>>   7 | Alexandre Grothendieck (1928-2014).
 >>>   8 | 
 >>>   9 | Phase 2 extension (#2159, Epic #2162).
 >>>  10 | 
      11 | Ce module introductif présente la formalisation Mathlib 4 des concepts
      12 | fondamentaux de la théorie des sites de Grothendieck (SGA 4 II §1-3) :
      13 | 
      14 |   - `Sieve X` : crible sur un objet X (sous-foncteur de l'embedding de
      15 |     Yoneda en X), forme un **treillis complet** via `inferInstance`
      16 |   - `GrothendieckTopology C` : fonction assignant à chaque X un ensemble
      17 |     de cribles couvrants satisfaisant **trois axiomes** (top_mem,
      18 |     pullback_stable, transitive)
      19 |   - `GrothendieckTopology.trivial` : la topologie triviale (la plus
      20 |     grossière, **bottom** ⊥ du treillis des topologies)
      21 |   - `GrothendieckTopology.discrete` : la topologie discrète (la plus
      22 |     fine, **top** ⊤ du treillis des topologies)
      23 |   - `GrothendieckTopology.dense` : la topologie dense (S couvre X ssi
      24 |     tout morphisme Y → X admet un facteur dans S)
      25 |   - `top_covers` : axiome 1 — le crible maximal est toujours couvrant
      26 |     (stabilité par identité)
      27 |   - `pullback_cover` : axiome 2 — les cribles couvrants sont stables
      28 |     par pullback (localité, voir c.393 SieveLattice pour les axiomes
      29 |     functoriels du pullback)
      30 |   - `transitivity` : axiome 3 — caractère local (transitivité)
      31 |   - `trivial_eq_bot` / `discrete_eq_top` : la topologie triviale est le
      32 |     **bottom** ⊥ et la topologie discrète est le **top** ⊤ du treillis
      33 |     complet des topologies de Grothendieck sur C
      34 | 
      35 | L'intuition clé (le « basculement catégoriel » de Grothendieck) :
      36 | remplacer les **espaces topologiques** (au sens de Bourbaki) par des
      37 | **catégories équipées d'une topologie** définie par des cribles
      38 | couvrants. Cette généralisation a révolutionné la géométrie algébrique
      39 | en permettant de définir les **faisceaux** sur des schémas, des
      40 | champs, des topos — bien au-delà des espaces topologiques classiques.
    ... (203 lignes restantes sur 243 total)
--- fin (243 lignes) ---

Interpretation : Sieve et GrothendieckTopology

Le type Sieve : C -> Type produit, pour chaque objet X : C, le type des cribles sur X. Une topologie de Grothendieck J : GrothendieckTopology C est alors une fonction J : (X : C) -> Set (Sieve X) qui designe les cribles “couvrants”, soumise a trois axiomes :

  1. Le crible maximal est couvrant (axiome d’identite).
  2. Stabilite par image inverse (pullback_stable).
  3. Stabilite transitive (un crible obtenu en raffinant un couvrant par des couvrants est couvrant).

Mathlib fournit dans le même fichier les topologies extremes : trivial (seul le crible maximal couvre), discrete (tous les cribles couvrent), dense (cribles non vides), atomic (axiomatise par des familles couvrantes a un seul morphisme).

Observation pedagogique : la définition Lean / Mathlib epouse exactement la définition de SGA 4. Lire la définition Lean, c’est lire SGA 4 dans une syntaxe verifiable.

3. Faisceaux sur un espace topologique

Avant les sites, Grothendieck a déjà revolutionne la théorie des faisceaux dans son article de Tohoku (1957) : il a place les faisceaux dans le cadre des catégories abeliennes et a défini la cohomologie comme un foncteur derive.

Mathlib formalise les faisceaux sur un espace topologique (catégorie TopCat) avec valeurs dans une catégorie C quelconque. Un prefaisceau est un foncteur (Opens X)^op -> C, et un faisceau est un prefaisceau verifiant la condition de recollement (egaliseur).

# Verification : Presheaf et Sheaf dans Mathlib
display_lean_module('MathlibMap', highlight=[6, 7])
--- Grothendieck/MathlibMap.lean ---
       1 | /-
       2 | Copyright (c) 2026 CoursIA. All rights reserved.
       3 | Released under Apache 2.0 license as described in the file LICENSE.
       4 | 
       5 | ## Partie 4 — `Grothendieck.MathlibMap` : Cartographie Mathlib
 >>>   6 | 
 >>>   7 | Un index vivant de ce que Mathlib 4 fournit depuis le langage mathématique
       8 | de Grothendieck. Chaque `#check` vérifie que la définition existe et est
       9 | accessible depuis les imports courants.
      10 | 
      11 | Epic #1646. Tous les `sorry`s éliminés à la création.
      12 | 
      13 | ### i18n — convention #4980 ratifiée 2026-07-04
      14 | 
      15 | Ce module est jumelé avec sa version anglaise canonique dans le fichier
      16 | sibling `MathlibMap_en.lean` (modèle sibling pair, voir PR #6154 pour le
      17 | pilote sur `Utility.lean`). Les énoncés `#check @...` restent en anglais
      18 | (Mathlib 4, tactic DSL standard) ; seules les **docstrings `/-- ... -/`** et
      19 | les **commentaires `-- ...`** diffèrent entre les deux fichiers. Anti-§D
      20 | byte-identity garanti : le namespace body est préservé bit-pour-bit (les
      21 | énoncés `#check` sont identiques entre `MathlibMap.lean` et `MathlibMap_en.lean`,
      22 | seuls les commentaires diffèrent).
      23 | -/
      24 | 
      25 | import Mathlib.CategoryTheory.Sites.Grothendieck
      26 | import Mathlib.CategoryTheory.Sites.SheafOfTypes
      27 | import Mathlib.AlgebraicGeometry.Scheme
      28 | import Mathlib.Topology.Sheaves.Sheaf
      29 | 
      30 | namespace Grothendieck
      31 | 
      32 | /-!
      33 | ## Fondements de la théorie des catégories (l'héritage de Grothendieck)
      34 | 
      35 | Grothendieck a fait de la théorie des catégories le langage de la géométrie
      36 | algébrique. Mathlib 4 dispose d'une riche bibliothèque de théorie des
      37 | catégories construite sur ces idées.
      38 | -/
      39 | 
      40 | -- Le lemme de Yoneda (fondamental pour les cribles et les faisceaux)
      41 | #check @CategoryTheory.yoneda            -- C ⥤ (Cᵒᵖ ⥤ Type v)
      42 | #check @CategoryTheory.coyoneda          -- (Cᵒᵖ ⥤ Type v) ⥤ C
      43 | 
      44 | /-!
      45 | ## Cribles et précaractères (Sieves et Presieves)
      46 | -/
      47 | 
      48 | #check @CategoryTheory.Presieve          -- Presieve X
      49 | #check @CategoryTheory.Sieve             -- Sieve X (sous-foncteur de yoneda.obj X)
      50 | #check @CategoryTheory.Sieve.pullback    -- pullback d'un crible le long d'un morphisme
      51 | #check @CategoryTheory.Sieve.arrows      -- le précaractère sous-jacent
      52 | 
      53 | /-!
      54 | ## Topologies de Grothendieck
      55 | -/
      56 | 
      57 | #check @CategoryTheory.GrothendieckTopology          -- la structure de topologie
      58 | #check @CategoryTheory.GrothendieckTopology.trivial  -- topologie la plus grossière
      59 | #check @CategoryTheory.GrothendieckTopology.discrete -- topologie la plus fine
      60 | #check @CategoryTheory.GrothendieckTopology.dense    -- topologie dense
      61 | 
      62 | /-!
      63 | ## Faisceaux
      64 | -/
      65 | 
      66 | -- Faisceaux de types sur un site
      67 | #check @CategoryTheory.Presieve.IsSheaf  -- condition de faisceau pour préfaisceaux en Type
      68 | #check @CategoryTheory.Presieve.IsSeparated  -- préfaisceau séparé
      69 | 
      70 | -- Faisceaux sur un espace topologique
      71 | #check @TopCat.Sheaf                     -- faisceau bundle sur un espace topologique
      72 | 
      73 | /-!
      74 | ## Géométrie algébrique : Schémas et Spec
      75 | -/
      76 | 
      77 | open AlgebraicGeometry CategoryTheory
      78 | 
      79 | -- Le type des schémas
      80 | #check Scheme                   -- le type des schémas
      81 | 
      82 | -- La construction Spec : des anneaux vers les espaces
      83 | #check Scheme.Spec              -- CommRingCatᵒᵖ ⥤ Scheme
      84 | 
      85 | -- Sections globales : des espaces vers les anneaux
      86 | #check Scheme.Γ                 -- Schemeᵒᵖ ⥤ CommRingCat
      87 | 
      88 | -- Foncteurs d'oubli
      89 | #check Scheme.forgetToTop       -- Scheme ⥤ TopCat
      90 | #check Scheme.forgetToLocallyRingedSpace  -- Scheme ⥤ LocallyRingedSpace
      91 | 
      92 | /-!
      93 | ## Ce que Mathlib n'a PAS ENCORE (état 2026-07)
      94 | 
      95 | Les concepts fondamentaux de Grothendieck qui ne sont PAS encore dans Mathlib :
      96 |   - Cohomologie étale (site étale, cohomologie l-adique)
      97 |   - Motifs (motifs purs, catégorie DM de Voevodsky)
      98 |   - Six opérations (formalisme complet de Grothendieck) — Mathlib ne fournit
      99 |     que l'instance de base `f^* ⊣ f_*` sur les faisceaux de modules
     100 |     (`AlgebraicGeometry.Modules.Sheaf`, indexée par `DirectImage.lean`). Le
     101 |     formalisme complet reste hors de Mathlib ; au niveau préfaisceau, cette lake
     102 |     a livré le triple `f_! ⊣ f^* ⊣ f_*` (Parties 34-35,
     103 |     `ExceptionalDirect.lean` / `ExceptionalTriple.lean`), et `f^!` s'y effondre
     104 |     sur `f^*` (`exceptionalInverse_collapses_to_pullback`) — il n'existe qu'avec
     105 |     la dualité de Verdier.
     106 |   - Grothendieck-Riemann-Roch
     107 |   - Dualité de Grothendieck
     108 |   - Cohomologie cristalline
     109 |   - Géométrie anabélienne
     110 |   - Résultats profonds EGA/SGA (EGA II-IV, SGA 1-7)
     111 | 
     112 | Ces cibles restent au niveau recherche en formalisation.
     113 | -/
     114 | 
     115 | /-!
     116 | ## Théorèmes-ponts
     117 | 
     118 | La section "Théorèmes propres" initialement prévue (4 lemmes sur
     119 | `CategoryTheory.yoneda`/`coyoneda`/`GrothendieckTopology.trivial`/
     120 | `Sieve`) a été retirée en c.1301+107 v3 (Lean CI FAIL sur le
     121 | polymorphisme d'univers — voir PR #10638 historique). Les `#check`
     122 | ci-dessus suffisent à valider que les noms canoniques Mathlib sont
     123 | accessibles depuis les imports courants. Les 12 lemmes propres
     124 | subsistent dans `Equivalences.lean` (4) + `MonoidalCategories.lean`
     125 | (4 lemmes PASS en CI) + leurs siblings `_en`.
     126 | -/
     127 | 
     128 | end Grothendieck
--- fin (128 lignes) ---

Interpretation : prefaisceaux et faisceaux

Le type TopCat.Presheaf C X represente les prefaisceaux sur X a valeurs dans C. Le type TopCat.Sheaf C X ajoute la condition de faisceau (egaliseur sur les recouvrements).

Note : Mathlib a deux presentations equivalentes pour les faisceaux – l’une via les ouverts d’un espace topologique, l’autre via une topologie de Grothendieck générale. Le pont entre les deux est etabli dans Mathlib.Topology.Sheaves.Forget et Mathlib.CategoryTheory.Sites.Sheaf. Les deux presentations permettent de redire “un faisceau de groupes abeliens sur X”, mais la presentation Grothendieck est celle qui se généralise aux schemas, aux sites etales, etc.

Tout ceci est dans Mathlib aujourd’hui. C’est le langage de Grothendieck, ecrit dans Lean.

4. Schemas : remplacer les varietes par du local-affine

La définition d’un schema est l’invention centrale d’EGA I (1960). Avant Grothendieck, on faisait de la geometrie algébrique sur des varietes définies par des équations polynomiales sur un corps. Grothendieck remplace les varietes par des espaces localement anneles dont chaque ouvert est localement de la forme Spec R pour un anneau commutatif R.

Cette generalisation autorise : - des points génériques (lies aux ideaux premiers non maximaux) - des coefficients dans n’importe quel anneau (pas seulement un corps algebriquement clos) - la théorie arithmetique (Spec Z est un objet legitime, et la geometrie sur lui = théorie des nombres)

Mathlib formalise cette construction :

# Verification : Scheme et Spec dans Mathlib
display_lean_module('SchemesTour', highlight=[1, 2, 3, 4, 5])
--- Grothendieck/SchemesTour.lean ---
 >>>   1 | /-
 >>>   2 | Hommage à Grothendieck — Partie 2 : Schémas
 >>>   3 | Alexandre Grothendieck (1928-2014).
 >>>   4 | 
 >>>   5 | L'idée la plus transformatrice de Grothendieck : remplacer les variétés par
       6 | des *schémas* — des espaces localement annelés qui sont localement affines
       7 | (isomorphes à Spec R pour un anneau commutatif R). Cela fournit un cadre
       8 | unifié pour l'arithmétique et la géométrie.
       9 | 
      10 | Mathlib 4 formalise les schémas comme `AlgebraicGeometry.Scheme`, étendant
      11 | `LocallyRingedSpace` avec la condition d'affinité locale.
      12 | 
      13 | Epic #1646. Toutes les `sorry` éliminées à la création.
      14 | 
      15 | Sub-grain Phase 2+ (#2159, Epic #1646) — c.8267+3 : ajout de 6 ponts Mathlib
      16 | réutilisables à la place des `example` énoncés pédagogiques. Permet de citer
      17 | les lemmes canoniques depuis le namespace `Grothendieck` (homogénéité avec
      18 | les autres modules : `SitePoints`, `SheafBasics`, `MayerVietorisSquare`,
      19 | `Adjunction`, `Limits`, `KanExtensions`).
      20 | -/
      21 | 
      22 | /-
      23 |   `Grothendieck.SchemesTour` — Schémas (Partie 2)
      24 |   =================================================
      25 | 
      26 |   Hommage à Alexandre Grothendieck (1928-2014).
      27 | 
      28 |   L'idée la plus transformante de Grothendieck : remplacer les variétés
      29 |   par des *schémas* — des espaces annelés en anneaux locaux qui sont
      30 |   localement affines (isomorphes à Spec R pour un anneau commutatif R).
      31 |   Ce cadre unifie l'arithmétique et la géométrie.
      32 | 
      33 |   Mathlib 4 formalise les schémas comme `AlgebraicGeometry.Scheme`, qui
      34 |   étend `LocallyRingedSpace` par la condition d'affinité locale.
      35 | 
      36 |   Ce module parcourt :
      37 |     - Le type `Scheme` et sa structure de catégorie, avec ses foncteurs
      38 |       d'oubli vers les espaces topologiques et les espaces annelés en
      39 |       anneaux locaux.
      40 |     - La construction Spec, qui associe à chaque anneau commutatif un
      41 |       schéma affine ; Spec est l'adjoint à gauche du foncteur de sections
      42 |       globales Γ.
      43 |     - Les propriétés de base : un isomorphisme de schémas induit un
      44 |       homéomorphisme des espaces sous-jacents.
      45 |     - L'adjonction Spec Γ, cœur de la géométrie algébrique : pour les
      46 |       schémas affines, Spec et Γ sont des équivalences inverses.
      47 | 
      48 |   Epic #1646. Tous les `sorry`s éliminés à la création.
      49 | 
      50 | ### i18n — convention #4980 ratifiée 2026-07-04
      51 | 
      52 | Module jumelé avec sa version anglaise canonique dans le fichier sibling
      53 | `SchemesTour_en.lean` (modèle sibling pair, voir PR #6154 sur `Utility.lean`).
      54 | Seules les **docstrings `/-- ... -/`** et **commentaires `-- ...`** diffèrent ;
      55 | les énoncés de théorèmes, les noms de lemmes, les tactiques Lean et les
      56 | références Mathlib restent en anglais (Mathlib 4, tactic DSL standard).
      57 | Anti-§D byte-identity garanti : signatures et corps byte-identiques entre
      58 | `SchemesTour.lean` et `SchemesTour_en.lean`.
      59 | 
      60 | Sub-grain Phase 2+ (#2159, Epic #1646) — c.8267+3 : 6 ponts Mathlib
      61 | réutilisables dans le namespace `Grothendieck` (homogénéité avec les autres
      62 | modules Grothendieck : `SitePoints`, `SheafBasics`, `MayerVietorisSquare`,
      63 | `Adjunction`, `Limits`, `KanExtensions`). Remplace les `example` énoncés
      64 | pédagogiques par des bridges canoniques.
      65 | -/
      66 | 
      67 | import Mathlib.AlgebraicGeometry.Scheme
      68 | 
      69 | namespace Grothendieck
      70 | 
      71 | open AlgebraicGeometry CategoryTheory
      72 | 
      73 | /-!
      74 | ## Le type des schémas
      75 | 
      76 | `Scheme` est le type des schémas. Il porte une structure de catégorie.
      77 | Chaque schéma a un espace localement annelé sous-jacent, un espace
      78 | topologique, et un préfaisceau d'anneaux commutatifs.
      79 | -/
      80 | 
      81 | -- The type of schemes
      82 | #check @AlgebraicGeometry.Scheme
      83 | 
      84 | -- The forgetful functor from schemes to topological spaces
      85 | #check @Scheme.forgetToTop
      86 | 
      87 | /-!
      88 | ## Spec : des anneaux aux espaces
      89 | 
      90 | La construction Spec transforme un anneau commutatif en un schéma affine.
      91 | C'est l'adjoint à gauche du foncteur sections globales Γ.
      92 | -/
      93 | 
      94 | /-- Spec est un foncteur de CommRingCatᵒᵖ vers Scheme.
      95 |     Marqué `noncomputable` car `Scheme.Spec` est noncomputable. -/
      96 | noncomputable example : CommRingCatᵒᵖ ⥤ Scheme := Scheme.Spec
      97 | 
      98 | /-!
      99 | ## Propriétés de base
     100 | 
     101 | Les schémas ont une structure d'ordre issue de la spécialisation, et les
     102 | morphismes entre schémas respectent la structure de faisceau.
     103 | -/
     104 | 
     105 | /-- Un isomorphisme de schémas induit un homéomorphisme des espaces sous-jacents.
     106 |     Note : `Scheme.homeoOfIso` retourne `X ≃ₜ Y` (supports). -/
     107 | noncomputable example {X Y : Scheme} (i : X ≅ Y) : X ≃ₜ Y :=
     108 |   Scheme.homeoOfIso i
     109 | 
     110 | -- The forgetful functor from schemes to locally ringed spaces (fully faithful)
     111 | #check @Scheme.forgetToLocallyRingedSpace
     112 | 
     113 | -- The FullyFaithful type for the forgetful functor
     114 | #check Scheme.forgetToLocallyRingedSpace.FullyFaithful
     115 | 
     116 | /-!
     117 | ## La vue d'ensemble : des anneaux aux espaces et retour
     118 | 
     119 | L'adjonction Spec-Γ est le cœur de la géométrie algébrique :
     120 |   - Spec : CommRingCatᵒᵖ → Scheme  (anneau vers espace)
     121 |   - Γ     : Schemeᵒᵖ → CommRingCat  (espace vers anneau, sections globales)
     122 | 
     123 | Pour les schémas affines, ce sont des équivalences inverses.
     124 | -/
     125 | 
     126 | /-- Chaque schéma a des sections globales (l'anneau Γ(X)).
     127 |     Note : `Scheme.Γ` a pour domaine `Schemeᵒᵖ`. -/
     128 | example (X : Scheme) : CommRingCat :=
     129 |   Scheme.Γ.obj (Opposite.op X)
     130 | 
     131 | /-!
     132 | ## Ponts Mathlib canoniques
     133 | 
     134 | Les ponts suivants ré-exposent depuis le namespace `Grothendieck` des lemmes
     135 | Mathlib 4 (`Mathlib.AlgebraicGeometry.Scheme`, `Mathlib.AlgebraicGeometry.Spec`).
     136 | Ils servent deux objectifs :
     137 | 
     138 |   1. **Référence pédagogique** : un apprenant qui lit le namespace
     139 |      `Grothendieck` trouve les énoncés canoniques des schémas, sans avoir
     140 |      à naviguer dans la hiérarchie `Mathlib.AlgebraicGeometry.*`.
     141 |   2. **Réutilisation in-module** : les modules frères (`Subcanonical`,
     142 |      `ZariskiSite`, `Calibration`, `MathlibMap`) peuvent citer ces ponts
     143 |      au lieu de répéter la qualification `AlgebraicGeometry.Scheme.*`.
     144 | 
     145 | Les corps sont triviaux (lemmes `@[simp]` ou `rfl` dans Mathlib) — c'est la
     146 | valeur de **référencement**, pas de calcul.
     147 | -/
     148 | 
     149 | /-- **Continuité d'un morphisme de schémas.** Un morphisme de schémas
     150 |     `f : X ⟶ Y` est continu (entre les espaces topologiques sous-jacents) :
     151 |     `f : X ⟶ Y` ⇒ `Continuous f` — c'est la définition même d'un morphisme
     152 |     de schémas vu comme application continue entre les `TopCat` sous-jacents. -/
     153 | theorem scheme_hom_continuous {X Y : Scheme} (f : X ⟶ Y) : Continuous f :=
     154 |   Scheme.Hom.continuous f
     155 | 
     156 | /-- **Symétrie du homéomorphisme induit.** Si `e : X ≅ Y` est un isomorphisme
     157 |     de schémas, alors l'inverse du homéomorphisme `homeoOfIso e : X ≃ₜ Y`
     158 |     coïncide avec le homéomorphisme construit à partir de `e.symm`. C'est
     159 |     la cohérence symmétrique canonique de `Scheme.homeoOfIso`. -/
     160 | theorem scheme_homeoOfIso_symm {X Y : Scheme} (e : X ≅ Y) :
     161 |     (Scheme.homeoOfIso e).symm = Scheme.homeoOfIso e.symm :=
     162 |   Scheme.homeoOfIso_symm e
     163 | 
     164 | /-- **Coefficient du symm de homéomorphisme.** Appliquer le homéomorphisme
     165 |     construit depuis `e.symm` à un point `x` redonne `e.inv x`, c'est-à-dire
     166 |     l'image par le foncteur d'oubli vers `TopCat` de l'inverse de
     167 |     l'isomorphisme `e`. -/
     168 | theorem scheme_coe_homeoOfIso_symm {X Y : Scheme} (e : X ≅ Y) :
     169 |     ⇑(Scheme.homeoOfIso e.symm) = e.inv :=
     170 |   Scheme.coe_homeoOfIso_symm e
     171 | 
     172 | /-- **Composition des foncteurs d'oubli.** L'oubli `Scheme → TopCat` suivi
     173 |     de l'oubli `TopCat → Type` coïncide avec l'oubli direct `Scheme → Type`
     174 |     défini comme `Scheme.forget`. C'est la cohérence des deux chemins
     175 |     d'oubli vers `Type u`. -/
     176 | theorem scheme_forgetToTop_comp_forget :
     177 |     Scheme.forgetToTop ⋙ CategoryTheory.forget TopCat = Scheme.forget :=
     178 |   Scheme.forgetToTop_comp_forget
     179 | 
     180 | /-- **Compatibilité de l'image réciproque avec la composition.** L'image
     181 |     réciproque d'un ouvert `U` par un morphisme composé `f ≫ g`
     182 |     coïncide avec l'image réciproque de l'image réciproque :
     183 |     `(f ≫ g)⁻¹ᵁ U = f⁻¹ᵁ (g⁻¹ᵁ U)`. -/
     184 | theorem scheme_comp_preimage {X Y Z : Scheme} (f : X ⟶ Y) (g : Y ⟶ Z) (U : Z.Opens) :
     185 |     (f ≫ g) ⁻¹ᵁ U = f ⁻¹ᵁ (g ⁻¹ᵁ U) :=
     186 |   Scheme.Hom.comp_preimage f g U
     187 | 
     188 | /-- **Identité du foncteur Spec sur les objets.** Le morphisme de schémas
     189 |     `Spec.topMap (𝟙 R)` coïncide avec l'identité sur `Spec R` — c'est la
     190 |     loi d'identité du foncteur Spec (dans sa composante `Spec.toTop`,
     191 |     `CommRingCatᵒᵖ → TopCat`). -/
     192 | theorem spec_topMap_id (R : CommRingCat) :
     193 |     Spec.topMap (𝟙 R) = 𝟙 (Spec.topObj R) :=
     194 |   Spec.topMap_id R
     195 | 
     196 | end Grothendieck
--- fin (196 lignes) ---

Interpretation : Scheme et Spec

AlgebraicGeometry.Scheme : Type (u+1) est le type des schemas. AlgebraicGeometry.Spec : CommRingCat -> Scheme est le foncteur spectre. Concretement, pour un anneau commutatif R, Spec R est le schema dont :

  • l’espace topologique sous-jacent est l’ensemble des ideaux premiers de R, muni de la topologie de Zariski (les fermes sont les V(I) = {p : I ⊆ p} pour I ideal)
  • le faisceau structural attache a Spec R est determine par R lui-même (localisations)

Cette définition est vraiment la définition d’EGA I (1960). Pas une approximation, pas un cas particulier : c’est la même — et la même notion est reprise dans SGA 1 Exposé I (1961) avec la formulation par recollement.

Realite Mathlib 4 actuelle : la théorie des schemas dans Mathlib est en développement actif. Les définitions sont stables, beaucoup de propriétés élémentaires sont prouvees (separation, finitude, dimension dans certains cas), mais on est loin d’EGA IV. C’est pedagogiquement utile, ce n’est pas une formalisation complète d’EGA.

5. Site de Zariski : la topologie de Grothendieck sur la catégorie des schemas

La topologie de Zariski sur la catégorie des schemas est l’exemple le plus naturel de topologie de Grothendieck “non spatiale”. Elle est définie par une pretopologie : une famille de morphismes {f_i : U_i -> X} est couvrante si les f_i sont des immersions ouvertes et X est leur union ensembliste.

Mathlib fournit cette topologie dans Mathlib.AlgebraicGeometry.Sites.BigZariski. Le nom “gros site” (big site) signifie qu’on prend tous les schemas, pas seulement les ouverts d’un schema fixe.

# Verification : Zariski pretopology, topology et equivalence dans Mathlib
display_lean_module('ZariskiSite', highlight=[1, 2, 3, 4, 5, 6, 7])
--- Grothendieck/ZariskiSite.lean ---
 >>>   1 | /-
 >>>   2 | Hommage à Grothendieck — Partie 3 : Le site de Zariski
 >>>   3 | Alexandre Grothendieck (1928-2014).
 >>>   4 | 
 >>>   5 | La topologie de Zariski sur la catégorie des schémas est l'exemple fondateur
 >>>   6 | d'une topologie de Grothendieck issue de la géométrie algébrique. Une famille
 >>>   7 | de morphismes {U_i → X} est un recouvrement de Zariski ssi les U_i sont des
       8 | immersions ouvertes qui recouvrent X conjointement.
       9 | 
      10 | Mathlib 4 formalise cela via `Scheme.zariskiTopology`, dérivé de la
      11 | prétopologie des immersions ouvertes. Le théorème-pont clé est
      12 | `zariskiTopology_eq` : la topologie de Grothendieck engendrée par la
      13 | prétopologie de Zariski égale la topologie de Zariski.
      14 | 
      15 | Epic #1646. Tous les `sorry` ont été éliminés à la création.
      16 | 
      17 | Convention i18n (EPIC #4980, décision user ratifiée 2026-07-04) : ce fichier
      18 | est **FR canonique**, avec son miroir anglais dans le fichier sibling
      19 | `ZariskiSite_en.lean` (modèle sibling pair, cf `code-style.md` §Lean i18n).
      20 | Les énoncés de théorèmes/exemples, les tactiques Lean et les références
      21 | Mathlib restent en anglais (compat Mathlib 4) ; seules les docstrings et ce
      22 | bloc d'en-tête diffèrent entre les deux fichiers.
      23 | -/
      24 | 
      25 | import Mathlib.AlgebraicGeometry.Sites.BigZariski
      26 | 
      27 | universe v u
      28 | 
      29 | namespace Grothendieck
      30 | 
      31 | open AlgebraicGeometry CategoryTheory
      32 | 
      33 | /-!
      34 | ## La prétopologie de Zariski
      35 | 
      36 | Une prétopologie spécifie directement les familles de recouvrement (collections
      37 | de morphismes). La prétopologie de Zariski recouvre X par des familles
      38 | d'immersions ouvertes conjointement surjectives sur l'espace topologique sous-jacent.
      39 | -/
      40 | 
      41 | /-- La prétopologie de Zariski sur la catégorie des schémas. -/
      42 | example : Pretopology Scheme :=
      43 |   Scheme.zariskiPretopology
      44 | 
      45 | /-!
      46 | ## De la prétopologie à la topologie de Grothendieck
      47 | 
      48 | Toute prétopologie engendre une topologie de Grothendieck. La topologie de
      49 | Zariski est précisément la topologie de Grothendieck engendrée par la
      50 | prétopologie de Zariski.
      51 | -/
      52 | 
      53 | /-- La topologie de Zariski vue comme topologie de Grothendieck. -/
      54 | example : GrothendieckTopology Scheme :=
      55 |   Scheme.zariskiTopology
      56 | 
      57 | /-- Le théorème-pont : la topologie de Zariski égale la topologie de Grothendieck
      58 |     engendrée par la prétopologie de Zariski. C'est le lien clé entre les points
      59 |     de vue concret (prétopologie) et abstrait (topologie de Grothendieck). -/
      60 | theorem zariski_topology_eq :
      61 |     (Scheme.zariskiTopology : GrothendieckTopology Scheme) =
      62 |     Scheme.zariskiPretopology.toGrothendieck :=
      63 |   Scheme.zariskiTopology_eq
      64 | 
      65 | /-!
      66 | ## La topologie de Zariski est sous-canonique
      67 | 
      68 | Une topologie de Grothendieck est *sous-canonique* si tout préfaisceau
      69 | représentable est déjà un faisceau. La topologie de Zariski sur les schémas
      70 | est sous-canonique.
      71 | 
      72 | Cela signifie : pour tout schéma X, le préfaisceau `Hom(-, X)` satisfait la
      73 | condition de faisceau vis-à-vis des recouvrements de Zariski. Intuitivement,
      74 | un morphisme vers X est déterminé par ses restrictions à un recouvrement ouvert.
      75 | -/
      76 | 
      77 | /-- La topologie de Zariski est sous-canonique. -/
      78 | example : Scheme.zariskiTopology.Subcanonical :=
      79 |   inferInstance
      80 | 
      81 | /-!
      82 | ## Continuité du foncteur d'oubli
      83 | 
      84 | Le foncteur d'oubli des schémas vers les espaces topologiques est continu
      85 | vis-à-vis de la topologie de Zariski et de la topologie de Grothendieck
      86 | usuelle sur TopCat. Cela signifie : l'image réciproque d'un crible de
      87 | recouvrement de Zariski par forget est un crible de recouvrement dans TopCat.
      88 | -/
      89 | 
      90 | /-- Le foncteur d'oubli est continu vis-à-vis de la topologie de Zariski. -/
      91 | example : Scheme.forgetToTop.IsContinuous
      92 |     Scheme.zariskiTopology TopCat.grothendieckTopology :=
      93 |   inferInstance
      94 | 
      95 | /-! ## 5. Bridges Mathlib canoniques (hommage Grothendieck)
      96 | 
      97 | Ponts vers les 5 constructeurs canoniques de `Mathlib/AlgebraicGeometry/Sites/BigZariski.lean`
      98 | qui étendent le namespace `Grothendieck` avec les opérateurs fondamentaux du site de Zariski :
      99 | (5.1) la prétopologie et la topologie, (5.2) les instances Subcanonical et continuité du foncteur
     100 | d'oubli, (5.3) l'hypercover affine. -/
     101 | 
     102 | /-! ### 5.1 Pont-def : la prétopologie et la topologie de Zariski
     103 | 
     104 | Le bridge-lemma expose `zariskiPretopology` (la prétopologie sous-jacente) et `zariskiTopology`
     105 | (la topologie de Grothendieck dérivée) directement sous `Grothendieck.Scheme`. -/
     106 | 
     107 | /-- Pont-def : re-export de la prétopologie de Zariski sur la catégorie des schémas. -/
     108 | def zariskiPretopology_field : Pretopology Scheme.{u} :=
     109 |   Scheme.zariskiPretopology
     110 | 
     111 | /-- Pont-def : re-export de la topologie de Zariski (topologie de Grothendieck dérivée). -/
     112 | abbrev zariskiTopology_field : GrothendieckTopology Scheme.{u} :=
     113 |   Scheme.zariskiTopology
     114 | 
     115 | /-! ### 5.2 Pont-instance : Zariski sous-canonique et foncteur d'oubli continu
     116 | 
     117 | L'instance Subcanonical sur la topologie de Zariski (cf. Subcanonical.lean Partie 16) et
     118 | l'instance de continuité du foncteur d'oubli vers TopCat. -/
     119 | 
     120 | /-- Pont-instance : la topologie de Zariski est sous-canonique. -/
     121 | instance subcanonical_zariskiTopology_field : Scheme.zariskiTopology.Subcanonical :=
     122 |   Scheme.subcanonical_zariskiTopology
     123 | 
     124 | /-- Pont-instance : le foncteur d'oubli vers TopCat est continu vis-à-vis de Zariski. -/
     125 | instance forgetToTop_continuous_zariskiTopology :
     126 |     Scheme.forgetToTop.IsContinuous Scheme.zariskiTopology TopCat.grothendieckTopology :=
     127 |   inferInstance
     128 | 
     129 | /-! ### 5.3 Pont-def : hypercover affine (1-hypercover)
     130 | 
     131 | Pour tout schéma X, le 1-hypercover de Zariski dont tous les composantes sont affines.
     132 | C'est l'outil de base pour la cohomologie de Zariski. -/
     133 | 
     134 | /-- Pont-def : 1-hypercover de Zariski dont toutes les composantes sont affines. -/
     135 | noncomputable def affineOneHypercover_field (X : Scheme.{u}) :
     136 |     Scheme.zariskiTopology.OneHypercover X :=
     137 |   Scheme.affineOneHypercover X
     138 | 
     139 | end Grothendieck
--- fin (139 lignes) ---

Interpretation : le site de Zariski dans Lean

Trois identifiants Mathlib resument tout :

Nom Type Signification
Scheme.zariskiPretopology Pretopology Scheme la pretopologie : familles d’immersions ouvertes recouvrantes
Scheme.zariskiTopology GrothendieckTopology Scheme la topologie de Grothendieck engendree
Scheme.zariskiTopology_eq égalité atteste que la topologie est bien celle engendree par la pretopologie

Concretement, zariskiTopology = zariskiPretopology.toGrothendieck. C’est le lemme zariskiTopology_eq. La pretopologie est plus élémentaire (définition directe), la topologie de Grothendieck est plus structuree (axiomes de fermeture). Les deux sont equivalentes ici.

Au passage : Mathlib a aussi Scheme.zariskiTopology.Subcanonical, qui exprime que tous les representables Hom(-, X) sont des faisceaux pour cette topologie – propriété fondamentale qui dit que les schemas eux-mêmes “se recollent” pour la topologie de Zariski. C’est une consequence non triviale du lemme de Yoneda + recollement.

6. Propriétés locales de morphismes : etale, lisse, separe

Une autre tour de force de Grothendieck (et de son école) est la classification des propriétés locales des morphismes de schemas : etale, lisse, plat, non ramifie, separe, propre, projectif, etc. Chacune capture une nuance d’“etre regulier” et chacune correspond a une notion classique en geometrie complexe ou en arithmetique.

Mathlib formalise plusieurs de ces propriétés dans Mathlib.AlgebraicGeometry.Morphisms.*.

# Verification : Etale, Smooth, IsSeparated dans Mathlib
display_lean_module('MathlibMap', highlight=[8, 9, 10])
--- Grothendieck/MathlibMap.lean ---
       1 | /-
       2 | Copyright (c) 2026 CoursIA. All rights reserved.
       3 | Released under Apache 2.0 license as described in the file LICENSE.
       4 | 
       5 | ## Partie 4 — `Grothendieck.MathlibMap` : Cartographie Mathlib
       6 | 
       7 | Un index vivant de ce que Mathlib 4 fournit depuis le langage mathématique
 >>>   8 | de Grothendieck. Chaque `#check` vérifie que la définition existe et est
 >>>   9 | accessible depuis les imports courants.
 >>>  10 | 
      11 | Epic #1646. Tous les `sorry`s éliminés à la création.
      12 | 
      13 | ### i18n — convention #4980 ratifiée 2026-07-04
      14 | 
      15 | Ce module est jumelé avec sa version anglaise canonique dans le fichier
      16 | sibling `MathlibMap_en.lean` (modèle sibling pair, voir PR #6154 pour le
      17 | pilote sur `Utility.lean`). Les énoncés `#check @...` restent en anglais
      18 | (Mathlib 4, tactic DSL standard) ; seules les **docstrings `/-- ... -/`** et
      19 | les **commentaires `-- ...`** diffèrent entre les deux fichiers. Anti-§D
      20 | byte-identity garanti : le namespace body est préservé bit-pour-bit (les
      21 | énoncés `#check` sont identiques entre `MathlibMap.lean` et `MathlibMap_en.lean`,
      22 | seuls les commentaires diffèrent).
      23 | -/
      24 | 
      25 | import Mathlib.CategoryTheory.Sites.Grothendieck
      26 | import Mathlib.CategoryTheory.Sites.SheafOfTypes
      27 | import Mathlib.AlgebraicGeometry.Scheme
      28 | import Mathlib.Topology.Sheaves.Sheaf
      29 | 
      30 | namespace Grothendieck
      31 | 
      32 | /-!
      33 | ## Fondements de la théorie des catégories (l'héritage de Grothendieck)
      34 | 
      35 | Grothendieck a fait de la théorie des catégories le langage de la géométrie
      36 | algébrique. Mathlib 4 dispose d'une riche bibliothèque de théorie des
      37 | catégories construite sur ces idées.
      38 | -/
      39 | 
      40 | -- Le lemme de Yoneda (fondamental pour les cribles et les faisceaux)
      41 | #check @CategoryTheory.yoneda            -- C ⥤ (Cᵒᵖ ⥤ Type v)
      42 | #check @CategoryTheory.coyoneda          -- (Cᵒᵖ ⥤ Type v) ⥤ C
      43 | 
      44 | /-!
      45 | ## Cribles et précaractères (Sieves et Presieves)
      46 | -/
      47 | 
      48 | #check @CategoryTheory.Presieve          -- Presieve X
      49 | #check @CategoryTheory.Sieve             -- Sieve X (sous-foncteur de yoneda.obj X)
      50 | #check @CategoryTheory.Sieve.pullback    -- pullback d'un crible le long d'un morphisme
      51 | #check @CategoryTheory.Sieve.arrows      -- le précaractère sous-jacent
      52 | 
      53 | /-!
      54 | ## Topologies de Grothendieck
      55 | -/
      56 | 
      57 | #check @CategoryTheory.GrothendieckTopology          -- la structure de topologie
      58 | #check @CategoryTheory.GrothendieckTopology.trivial  -- topologie la plus grossière
      59 | #check @CategoryTheory.GrothendieckTopology.discrete -- topologie la plus fine
      60 | #check @CategoryTheory.GrothendieckTopology.dense    -- topologie dense
      61 | 
      62 | /-!
      63 | ## Faisceaux
      64 | -/
      65 | 
      66 | -- Faisceaux de types sur un site
      67 | #check @CategoryTheory.Presieve.IsSheaf  -- condition de faisceau pour préfaisceaux en Type
      68 | #check @CategoryTheory.Presieve.IsSeparated  -- préfaisceau séparé
      69 | 
      70 | -- Faisceaux sur un espace topologique
      71 | #check @TopCat.Sheaf                     -- faisceau bundle sur un espace topologique
      72 | 
      73 | /-!
      74 | ## Géométrie algébrique : Schémas et Spec
      75 | -/
      76 | 
      77 | open AlgebraicGeometry CategoryTheory
      78 | 
      79 | -- Le type des schémas
      80 | #check Scheme                   -- le type des schémas
      81 | 
      82 | -- La construction Spec : des anneaux vers les espaces
      83 | #check Scheme.Spec              -- CommRingCatᵒᵖ ⥤ Scheme
      84 | 
      85 | -- Sections globales : des espaces vers les anneaux
      86 | #check Scheme.Γ                 -- Schemeᵒᵖ ⥤ CommRingCat
      87 | 
      88 | -- Foncteurs d'oubli
      89 | #check Scheme.forgetToTop       -- Scheme ⥤ TopCat
      90 | #check Scheme.forgetToLocallyRingedSpace  -- Scheme ⥤ LocallyRingedSpace
      91 | 
      92 | /-!
      93 | ## Ce que Mathlib n'a PAS ENCORE (état 2026-07)
      94 | 
      95 | Les concepts fondamentaux de Grothendieck qui ne sont PAS encore dans Mathlib :
      96 |   - Cohomologie étale (site étale, cohomologie l-adique)
      97 |   - Motifs (motifs purs, catégorie DM de Voevodsky)
      98 |   - Six opérations (formalisme complet de Grothendieck) — Mathlib ne fournit
      99 |     que l'instance de base `f^* ⊣ f_*` sur les faisceaux de modules
     100 |     (`AlgebraicGeometry.Modules.Sheaf`, indexée par `DirectImage.lean`). Le
     101 |     formalisme complet reste hors de Mathlib ; au niveau préfaisceau, cette lake
     102 |     a livré le triple `f_! ⊣ f^* ⊣ f_*` (Parties 34-35,
     103 |     `ExceptionalDirect.lean` / `ExceptionalTriple.lean`), et `f^!` s'y effondre
     104 |     sur `f^*` (`exceptionalInverse_collapses_to_pullback`) — il n'existe qu'avec
     105 |     la dualité de Verdier.
     106 |   - Grothendieck-Riemann-Roch
     107 |   - Dualité de Grothendieck
     108 |   - Cohomologie cristalline
     109 |   - Géométrie anabélienne
     110 |   - Résultats profonds EGA/SGA (EGA II-IV, SGA 1-7)
     111 | 
     112 | Ces cibles restent au niveau recherche en formalisation.
     113 | -/
     114 | 
     115 | /-!
     116 | ## Théorèmes-ponts
     117 | 
     118 | La section "Théorèmes propres" initialement prévue (4 lemmes sur
     119 | `CategoryTheory.yoneda`/`coyoneda`/`GrothendieckTopology.trivial`/
     120 | `Sieve`) a été retirée en c.1301+107 v3 (Lean CI FAIL sur le
     121 | polymorphisme d'univers — voir PR #10638 historique). Les `#check`
     122 | ci-dessus suffisent à valider que les noms canoniques Mathlib sont
     123 | accessibles depuis les imports courants. Les 12 lemmes propres
     124 | subsistent dans `Equivalences.lean` (4) + `MonoidalCategories.lean`
     125 | (4 lemmes PASS en CI) + leurs siblings `_en`.
     126 | -/
     127 | 
     128 | end Grothendieck
--- fin (128 lignes) ---

Interpretation : propriétés locales

Les trois predicats Lean affichent une signature uniforme : {X Y : Scheme} -> (X ⟶ Y) -> Prop. C’est-a-dire : etant donne un morphisme f : X ⟶ Y, dire Etale f, Smooth f, IsSeparated f est une proposition.

Propriété Intuition
Etale morphisme “plat + non ramifie” : analogue d’un revetement de surface de Riemann
Smooth morphisme “plat + lisse au sens algébrique” : analogue d’une submersion lisse en geometrie differentielle
IsSeparated analogue de “separe” topologique : la diagonale est fermee

Mathlib regroupe ces propriétés sous le concept de propriété locale (locale sur la cible, sur la source, etc.) dans Mathlib.AlgebraicGeometry.Morphisms.Basic. C’est l’API qui sera utilisee pour construire le site etale – la brique manquante pour parler de cohomologie etale (cf section suivante).

Note Mathlib actuelle : les anciens noms IsEtale, IsSmooth ont ete renommes en Etale, Smooth (depreciations visibles dans les warnings).

7. Ce qui est hors-scope de cet hommage

Cet hommage est volontairement court. Il y a une raison principale : une grande partie de l’oeuvre de Grothendieck n’est pas (encore) dans Mathlib 4, et tenter d’en parler comme si elle l’etait serait malhonnete.

Hors scope cette serie (et probablement Mathlib 4 actuel)

Sujet grothendieckien État Mathlib 4 (mai 2026) Pourquoi hors-scope
Cohomologie etale ℓ-adique embryonnaire (site etale pas encore complet) très long, requiert le site etale + faisceaux constructibles + Lefschetz
Motifs (cat. dérivée des motifs) absent DM(k) requiert geometrie algébrique stable, en cours mais loin
Six opérations (f^, f_, f_!, f^!, ⊗, RHom) absent enorme machinerie, requiert catégories dérivées motiviques
Grothendieck-Riemann-Roch (GRR) absent requiert K-théorie algébrique + motifs
Dualite de Grothendieck absent requiert catégories dérivées + catégories abeliennes graduees
EGA II / III / IV (cohomologie schemas, faisceaux quasi-coherents profonds) partiel, en développement enorme, plusieurs annees de travail Mathlib
Geometrie anabelienne (Tate, pi_1 etale) absent requiert pi_1 etale + théorie des Galois
Cohomologie cristalline absent requiert cristaux + sites cristallins

Pourquoi insister sur le caractère partiel

Parce que Mathlib avance. Joel Riou a contribue d’importants travaux sur les catégories dérivées en 2024-2025. Le site etale, les faisceaux quasi-coherents, l’image directe et l’image inverse progressent. Ce notebook est un instantane (mai 2026). Dans un ou deux ans, il faudra le reactualiser.

Ce qui est solide aujourd’hui : catégories, foncteurs, sites, faisceaux, schemas, site de Zariski, premières propriétés locales. C’est déjà un programme intellectuel considerable. Le voir transcrit en Lean est, en soi, un hommage.

Ce que cet hommage NE pretend PAS faire

  1. Pas une formalisation EGA/SGA. Pour cela, il faudrait des annees-homme et un effort communautaire (cf Liquid Tensor Experiment, Polynomial Functional Calculus, et d’autres projets Mathlib).
  2. Pas une contribution upstream Mathlib. Tous les #check montres ici existent déjà dans Mathlib.
  3. Pas un cours de geometrie algébrique. Pour cela, lire EGA, Hartshorne, Stacks Project, ou plus pedagogiquement Vakil “The Rising Sea”.
  4. Pas une introduction a Lean. Pour cela, voir Lean-1 a Lean-6 dans cette serie.

C’est un hommage : court, propre, qui dit “voici la trace de Grothendieck dans Mathlib, allez voir vous-même”.

8. Exercices

Les trois exercices suivants vous font manipuler les structures Grothendieckiennes de Mathlib via le helper run_lean défini dans la cellule de setup. Ils suivent la convention C.1 (stub sans raise NotImplementedError), chacun accompagnant une section du notebook.

Exercice 1 : limites et adjonction

Objectif : explorer CategoryTheory.Limits.HasLimits et CategoryTheory.Adjunction (cf section 1 sur les foncteurs / Yoneda).

Indice : commencez par un #check @CategoryTheory.Limits.HasLimits pour voir la signature, puis cherchez l’adjonction CategoryTheory.Adjunction.adjunctionOfEquivLeft.

Exercice 2 : raffinement de cribles

Objectif : trouver dans Mathlib.CategoryTheory.Sites.Sieves le lemme qui exprime qu’un crible pullback d’un crible couvrant reste couvrant (cf section 2).

Indice : la fonction CategoryTheory.Sieve.pullback opere sur les cribles ; cherchez ensuite le lemme de stabilite d’une topologie de Grothendieck par image inverse.

Exercice 3 : Zariski pretopologie vs topologie

Objectif : mesurer l’ecart formel entre Scheme.zariskiPretopology et Scheme.zariskiTopology (cf section 5). Combien de lignes pour le lemme zariskiTopology_eq qui les met en correspondence ? Quelle tactique Lean principale ?

Indice : remplacez le #check par un #print AlgebraicGeometry.Scheme.zariskiTopology_eq pour obtenir le corps de la preuve.

# Exercice 1 : limites et adjonction
# Exploration de deux constructions categoriques centrales : limites et adjonctions.

snippet_ex1 = """
import Mathlib.CategoryTheory.Limits.Shapes.Products
import Mathlib.CategoryTheory.Adjunction.Basic

#check @CategoryTheory.Limits.HasLimits
#check @CategoryTheory.Adjunction
#check @CategoryTheory.Adjunction.adjunctionOfEquivLeft
"""

resultat_ex1 = run_lean(snippet_ex1, timeout_s=900)
print(resultat_ex1)
print("Lecture : HasLimits exprime l'existence de toutes les limites dans une categorie, tandis qu'Adjunction formalise une adjonction F ⊣ G entre deux foncteurs.")
CategoryTheory.Limits.HasLimits : (C : Type u_2) → [CategoryTheory.Category.{u_1, u_2} C] → Prop
@CategoryTheory.Adjunction : {C : Type u_3} →
  [inst : CategoryTheory.Category.{u_1, u_3} C] →
    {D : Type u_4} →
      [inst_1 : CategoryTheory.Category.{u_2, u_4} D] →
        CategoryTheory.Functor C D → CategoryTheory.Functor D C → Type (max (max (max u_3 u_4) u_1) u_2)
@CategoryTheory.Adjunction.adjunctionOfEquivLeft : {C : Type u_3} →
  [inst : CategoryTheory.Category.{u_1, u_3} C] →
    {D : Type u_4} →
      [inst_1 : CategoryTheory.Category.{u_2, u_4} D] →
        {G : CategoryTheory.Functor D C} →
          {F_obj : C → D} →
            (e : (X : C) → (Y : D) → (F_obj X ⟶ Y) ≃ (X ⟶ G.obj Y)) →
              (he :
                  ∀ (X : C) (Y Y' : D) (g : Y ⟶ Y') (h : F_obj X ⟶ Y),
                    (e X Y') (CategoryTheory.CategoryStruct.comp h g) =
                      CategoryTheory.CategoryStruct.comp ((e X Y) h) (G.map g)) →
                CategoryTheory.Adjunction.leftAdjointOfEquiv e he ⊣ G

Lecture : HasLimits exprime l'existence de toutes les limites dans une categorie, tandis qu'Adjunction formalise une adjonction F ⊣ G entre deux foncteurs.
# Exercice 2 : raffinement de cribles et stabilite par pullback
# On inspecte la signature de Sieve.pullback et le champ pullback_stable d'une topologie de Grothendieck.

snippet_ex2 = """
import Mathlib.CategoryTheory.Sites.Sieves
import Mathlib.CategoryTheory.Sites.Grothendieck

#check @CategoryTheory.Sieve.pullback
#check @CategoryTheory.GrothendieckTopology.pullback_stable
"""

resultat_ex2 = run_lean(snippet_ex2, timeout_s=900)
print(resultat_ex2)
print("Lecture : pullback_stable est exactement l'axiome SGA de stabilite des cribles couvrants par image inverse.")
@CategoryTheory.Sieve.pullback : {C : Type u_2} →
  [inst : CategoryTheory.Category.{u_1, u_2} C] → {X Y : C} → (Y ⟶ X) → CategoryTheory.Sieve X → CategoryTheory.Sieve Y
@CategoryTheory.GrothendieckTopology.pullback_stable : ∀ {C : Type u_2} [inst : CategoryTheory.Category.{u_1, u_2} C]
  {X Y : C} {S : CategoryTheory.Sieve X} (J : CategoryTheory.GrothendieckTopology C) (f : Y ⟶ X),
  S ∈ J X → CategoryTheory.Sieve.pullback f S ∈ J Y

Lecture : pullback_stable est exactement l'axiome SGA de stabilite des cribles couvrants par image inverse.
# Exercice 3 : Zariski pretopologie vs topologie
# #print expose le terme de preuve reliant la pretopologie de Zariski a la topologie engendree.

snippet_ex3 = """
import Mathlib.AlgebraicGeometry.Sites.BigZariski

#print AlgebraicGeometry.Scheme.zariskiTopology_eq
"""

resultat_ex3 = run_lean(snippet_ex3, timeout_s=900)
print(resultat_ex3)
proof_lines = [line for line in resultat_ex3.splitlines() if line.strip()]
print(f"Lignes non vides affichees : {len(proof_lines)}")
print("Lecture : la preuve est un renversement d'egalite (`Eq.symm`) applique au pont general `Precoverage.toGrothendieck_toPretopology_eq_toGrothendieck`.")
theorem AlgebraicGeometry.Scheme.zariskiTopology_eq.{u} : AlgebraicGeometry.Scheme.zariskiTopology =
  AlgebraicGeometry.Scheme.zariskiPretopology.toGrothendieck :=
Eq.symm CategoryTheory.Precoverage.toGrothendieck_toPretopology_eq_toGrothendieck

Lignes non vides affichees : 3
Lecture : la preuve est un renversement d'egalite (`Eq.symm`) applique au pont general `Precoverage.toGrothendieck_toPretopology_eq_toGrothendieck`.

Exercice 4 : le lemme de Yoneda

Objectif : explorer la formalisation Mathlib du lemme de Yoneda, pilier de la théorie des catégories et de l’approche grothendieckienne des foncteurs representables (cf section 1 sur les foncteurs et Yoneda).

Le lemme de Yoneda dit que pour tout foncteur F : C^op -> Type* et tout objet X : C, l’application qui évalue une transformation naturelle yoneda X -> F en id X est une bijection vers F.obj X. En particulier, un objet est entirement determine par les morphismes qui l’atteignent : c’est le slogan des foncteurs representables au coeur de la geometrie algébrique grothendieckienne.

Indice : un #check CategoryTheory.yoneda revele le plongement de Yoneda C -> (C^op -> Type*) qui envoie un objet X sur le foncteur representable Hom(-, X). CategoryTheory.Yoneda est la variante duale. Le lemme lui-même vit dans CategoryTheory.Yoneda.yonedaLemma.

# Exercice 4 : le lemme de Yoneda
# On inspecte le plongement de Yoneda formalise dans Mathlib.

snippet_ex4 = """
import Mathlib.CategoryTheory.Yoneda

#check CategoryTheory.yoneda
"""

resultat_ex4 = run_lean(snippet_ex4, timeout_s=900)
print(resultat_ex4)
print("Lecture : CategoryTheory.yoneda est le plongement de Yoneda C -> presheaf C "
      "(X |-> Hom(-, X)). Le lemme de Yoneda identifie les transformations naturelles "
      "depuis un foncteur representable aux elements du foncteur cible ; c'est l'outil "
      "fondateur des foncteurs representables en geometrie algebrique.")
CategoryTheory.yoneda.{v₁, u₁} {C : Type u₁} [CategoryTheory.Category.{v₁, u₁} C] :
  CategoryTheory.Functor C (CategoryTheory.Functor Cᵒᵖ (Type v₁))

Lecture : CategoryTheory.yoneda est le plongement de Yoneda C -> presheaf C (X |-> Hom(-, X)). Le lemme de Yoneda identifie les transformations naturelles depuis un foncteur representable aux elements du foncteur cible ; c'est l'outil fondateur des foncteurs representables en geometrie algebrique.

9. Pour aller plus loin

References historiques

  1. A. Grothendieck, Éléments de geometrie algébrique (avec J. Dieudonne), Publications mathematiques de l’IHES, 1960-1967 (EGA I-IV).
  2. A. Grothendieck et al., Seminaire de geometrie algébrique du Bois-Marie, plusieurs volumes, 1960-1969 (SGA 1-7).
  3. A. Grothendieck, Recoltes et Semailles, manuscrit autobiographique, 1985-1986 (publie posthume, edition Gallimard 2022).
  4. A. Grothendieck, Tohoku paper : “Sur quelques points d’algebre homologique”, Tohoku Math. J. 9 (1957), 119-221.
  5. The Stacks Project, https://stacks.math.columbia.edu/ : reference moderne, encyclopedique, mise a jour collaborative.
  6. R. Hartshorne, Algebraic Geometry, Springer GTM 52, 1977.
  7. R. Vakil, The Rising Sea: Foundations of Algebraic Geometry, draft en ligne, https://math.stanford.edu/~vakil/216blog/.

Travaux Lean recents

  • Joel Riou et al., travaux 2024-2025 sur les catégories dérivées, le foncteur dérive total, les localisations de catégories : cf Mathlib.CategoryTheory.Localization.* et Mathlib.CategoryTheory.Triangulated.*.
  • Kevin Buzzard, Adam Topaz, Patrick Massot et la communaute Mathlib, ports continus d’EGA / Stacks Project.
  • Liquid Tensor Experiment (Scholze + Commelin et al.) : exemple recent de formalisation lourde en geometrie algébrique formelle.

Liens vers d’autres notebooks de la serie

Note de scope (PR / Epic)

Le sous-projet MyIA.AI.Notebooks/SymbolicAI/Lean/grothendieck_lean/ (workspace Lake avec lakefile.lean) accompagne cet hommage. Le projet a evolue depuis sa création :

  • Modules sous Grothendieck/ (catégories, cribles, schemas, Zariski, calibration, mais aussi treillis de cribles, générateurs de coverage, propriétés canoniques, topologie dense, faisceautisation, exactitude a gauche, sous-canonicite, points d’un site, hom-faisceaux, faisceau constant, familles conservatives, cohomologie des faisceaux par Ext, carrés de Mayer-Vietoris, suite exacte longue de Mayer-Vietoris, cohomologie de Cech ; + fondamentaux catégoriels : Adjunction, Comma, Construction, Equivalences, KanExtensions, Limits, Monads, MonoidalCategories, YonedaLemma).
  • Aucun sorry comme terme de preuve.
  • Les modules originaux couverts pedagogiquement dans ce notebook : CategoryAndSites, SchemesTour, ZariskiSite, MathlibMap, Calibration, SieveLattice. Les modules supplémentaires (SheafBasics, SieveOps, CoverageGen, CanonicalProps, SieveGenerate, DenseTopology, Sheafification, LeftExact, Subcanonical, SitePoints, SheafHom, ConstantSheaf, Conservative, SheafCohomology/Basic, MayerVietorisSquare, SheafCohomology/MayerVietoris, SheafCohomology/Cech + Adjunction, Comma, Construction, Equivalences, KanExtensions, Limits, Monads, MonoidalCategories, YonedaLemma) approfondissent la théorie des faisceaux, des sites et de la cohomologie, ainsi que les fondamentaux catégoriels.

Lie a l’Epic #1646 (Grothendieck Lean side-track).

Le geste au-dela du langage

Cet hommage montre qu’une partie du langage de Grothendieck vit déjà dans Mathlib : catégories, cribles, topologies, faisceaux, schemas, site de Zariski. Mais le langage n’est pas le seul heritage. Le geste qui porte ce langage – trouver la representation ou le problème cesse d’etre dur – traverse le depot tout entier, bien au-dela de Lean.

Un même concept, dans CoursIA, se decline d’abord en simulation (calcul, experimentation, visualisation) puis, quand c’est possible, en preuve formelle (vérification mecanique, certification). Les mêmes théorèmes de choix social (Arrow, Sen) vivent en Python pedagogique et en Lean certifie. Le même Sudoku se resout par recherche, par contraintes, ou par SAT. Ce geste – changer de representation jusqu’a ce que la difficulte se dissolve – est précisément celui que Grothendieck decrit dans Recoltes et Semailles : non pas forcer la noix, mais laisser la mer monter.

La cle de lecture La mer qui monte deploye ce fil conducteur a travers l’ensemble du depot, montrant que le geste grothendieckien n’est pas reserve aux mathematiques formelles. Il est la méthode même de l’IA digne de confiance : re-representer la sortie incertaine d’un modèle dans un cadre verifiable.

Quant a la formalisation du langage de Grothendieck dans Mathlib – les schemas, les faisceaux, le site etale – elle poursuit sa route dans l’Epic #1646. Ce notebook est un hommage ; le travail continue.

Exercices supplémentaires (bonus)

Pour aller plus loin que les 3 exercices de la section 8 :

  1. #check exploratoire. Trouver dans Mathlib les définitions de CategoryTheory.Limits.HasLimits, CategoryTheory.Adjunction, et lire leur signature. Indication : utiliser le pattern run_lean de ce notebook (ALL_CHECKS consolide pour gagner du temps).
  2. Cribles et raffinements. Dans Mathlib.CategoryTheory.Sites.Sieves, identifier le lemme qui dit “raffiner un crible par un crible donne un crible” (composition de cribles).
  3. Yoneda explicite. Lire CategoryTheory.yonedaLemma dans Mathlib (le lemme de Yoneda formel). Quelle est sa conclusion ?
  4. Faisceaux et recollement. Dans Mathlib.Topology.Sheaves.Sheaf, identifier la condition de recollement qu’un Presheaf doit satisfaire pour etre un Sheaf. Que dit-elle intuitivement ?
  5. Pretopologie / topologie. Dans BigZariski.lean, lire la preuve de zariskiTopology_eq. Combien de lignes ? Quelle tactique principale ?

Navigation : << Lean-14 Finiteness-Derivatives | Lean-16b Conway Tribute >> | Index

« Do you know what a Grothendieck prime is? » – R. Borcherds [2:43:37] – l’anecdote du « nombre premier de Grothendieck » (57), rappelée avec tendresse : même l’architecte du langage calculait parfois de tête, et se trompait.

Retour au sommet