Nicolas Cantu
e93b10a719
**Motivations:** - Compilation du livre à partir des chapitres v0 - Création de la structure v1 avec chapitres et correctifs **Evolutions:** - v0/compile_livre.py : script de compilation - v0/livre.md : livre consolidé généré - Modifications des chapitres v0 (1-32), introduction, fermeture, plan_total_ouvrage, references, analyses critiques - v1 : abstract, chapitres 1-16, correctifs chapitres 17-32, introduction, fermeture, plan_total_ouvrage, references **Pages affectées:** - v0/ : compile_livre.py (nouveau), livre.md (nouveau), chapitre1-32.md, introduction.md, fermeture.md, plan_total_ouvrage.md, references.md, analyse_critique_ouvrage*.md - v1/ : abstract.md, chapitre1-16.md, correctifs/chapitre17-32.md, introduction.md, fermeture.md, plan_total_ouvrage.md, references.md (nouveaux) Co-authored-by: Cursor <cursoragent@cursor.com>
211 lines
9.5 KiB
Markdown
211 lines
9.5 KiB
Markdown
---
|
||
livre: "Théorie des futurs accessibles"
|
||
version: v1
|
||
auteur: Nicolas Cantu
|
||
chapitre: 28
|
||
type: correctif
|
||
---
|
||
|
||
# Correction dédiée : maîtriser la plasticité induite par la multiplicité des `Comp_type`
|
||
|
||
## Introduction
|
||
|
||
Le chapitre 19 a correctement identifié un point méthodologique central : l’admissibilité et la compatibilité ne peuvent pas rester implicites. Le texte y impose une hygiène terminologique (admissible « au sens des axiomes ») et typifie la compatibilité par des opérateurs `Comp_type`, tout en signalant une limite fondamentale : selon la nature des contraintes, la satisfaisabilité peut être coûteuse, voire indécidable, et il faut l’assumer plutôt que la masquer.
|
||
|
||
Cette clarification est indispensable pour éviter l’infalsifiabilité. Toutefois, une fois la compatibilité typée, un risque résiduel apparaît : la multiplicité des `Comp_type` peut rendre le système à nouveau trop plastique. Si, à chaque difficulté, un nouveau `Comp_type` est introduit, alors presque tout résultat peut être “récupéré” en changeant d’opérateur, et la théorie perd son pouvoir discriminant.
|
||
|
||
Ce chapitre corrige ce risque en introduisant une discipline de classification, d’axiomatisation minimale et d’étiquetage des résultats :
|
||
|
||
- résultats invariants valables pour une famille d’opérateurs satisfaisant un petit nombre d’axiomes clairement énoncés ;
|
||
- résultats spécifiques valables seulement pour un opérateur ou une sous‑famille, explicitement marqués comme dépendants du choix.
|
||
|
||
L’objectif est de conserver la généralité sans sacrifier la réfutabilité.
|
||
|
||
## Diagnostic : comment la plasticité revient
|
||
|
||
### Mécanisme de plasticité
|
||
|
||
Le système devient plastique si l’on peut, pour un même cadre, choisir `Comp` de manière à produire presque n’importe quel comportement :
|
||
|
||
- faire converger ou non les contraintes ;
|
||
- produire ou éliminer des cycles ;
|
||
- renforcer ou affaiblir le verrouillage ;
|
||
- changer les attracteurs accessibles.
|
||
|
||
Dans ce cas, les résultats ne décrivent plus un phénomène ; ils décrivent un espace de paramétrage, sans hiérarchie ni invariants.
|
||
|
||
### Symptômes typiques
|
||
|
||
- absence de noyau d’axiomes partagés entre les `Comp_type`
|
||
- introduction opportuniste de variantes de `Comp`
|
||
- absence de séparation entre théorèmes “pour tout Comp satisfaisant …” et conclusions “pour ce Comp précis”
|
||
- non déclaration de la dépendance à la représentation (granularité, projection) dans `Comp`
|
||
|
||
## Principe directeur : deux niveaux de résultats
|
||
|
||
Règle P0 (bifurcation des statuts)
|
||
Toute propriété démontrée doit être classée dans l’un des deux niveaux :
|
||
|
||
- niveau invariant : valable pour toute `Comp` dans une classe `𝒞` définie par un petit nombre d’axiomes
|
||
- niveau dépendant : valable seulement pour un `Comp` particulier ou une sous‑classe plus étroite, et explicitement indexée
|
||
|
||
Cette règle empêche de “glisser” un résultat dépendant en résultat général.
|
||
|
||
## Correction A : définir des classes canoniques d’opérateurs de compatibilité
|
||
|
||
### A1. Définition générale
|
||
|
||
Un opérateur de compatibilité est une application :
|
||
|
||
- `Comp : 𝒦 → 𝒦`
|
||
|
||
où `𝒦` est l’espace des ensembles de contraintes, typiquement `𝒫(𝔠)`.
|
||
|
||
Le rôle de `Comp` est de maintenir un certain prédicat de satisfaisabilité `Sat` (global ou local) en modifiant `K`.
|
||
|
||
### A2. Classes canoniques proposées
|
||
|
||
Le livre doit limiter explicitement le nombre de classes et les nommer.
|
||
|
||
Classe 𝒞_closure (fermetures monotones)
|
||
`Comp` est un opérateur de fermeture au sens de l’ordre :
|
||
- monotonie
|
||
- idempotence
|
||
- extensivité (selon convention)
|
||
|
||
Usage
|
||
- indispensable pour appliquer des théorèmes de point fixe (Tarski) et structurer l’auto‑stabilisation.
|
||
|
||
Classe 𝒞_repair_min (réparation minimale)
|
||
`Comp` supprime un minimum de contraintes pour rétablir `Sat` selon un critère de minimalité (inclusion, cardinalité, coût déclaré).
|
||
|
||
Usage
|
||
- modélise une “réparation” plutôt qu’une fermeture ; introduit un choix, donc un biais potentiel à déclarer.
|
||
|
||
Classe 𝒞_local_r (cohérence locale)
|
||
`Comp_r` maintient `Sat_r` (satisfaisabilité locale) plutôt que `Sat`.
|
||
|
||
Usage
|
||
- nécessaire lorsque `Sat` est intractable ; statut affaibli à déclarer.
|
||
|
||
Classe 𝒞_choice (sélection parmi satisfaisables)
|
||
`Comp` choisit un élément dans un ensemble de solutions satisfaisables.
|
||
|
||
Usage
|
||
- très puissant, donc très dangereux : toute propriété peut dépendre de ce choix ; doit être fortement encadré.
|
||
|
||
Le point essentiel est de déclarer que ces classes ne sont pas interchangeables : chacune implique un régime théorique différent.
|
||
|
||
## Correction B : noyau d’axiomes minimal pour les résultats invariants
|
||
|
||
Le livre doit proposer un noyau d’axiomes `A0` aussi petit que possible, et déclarer : “tout résultat dit invariant dans l’ouvrage dépend uniquement de A0”.
|
||
|
||
### B1. Axiomes recommandés
|
||
|
||
A0.1 (bien-typed)
|
||
`Comp` agit sur `𝒦` et retourne un élément de `𝒦`.
|
||
|
||
A0.2 (compatibilité déclarée)
|
||
Il existe un prédicat `Sat` tel que `Sat(Comp(K))` est garanti, ou bien un prédicat local `Sat_r` dans le cas approximatif.
|
||
|
||
A0.3 (monotonie optionnelle, mais explicitement requise quand utilisée)
|
||
Si un résultat utilise un point fixe, il doit exiger explicitement :
|
||
- monotonie de `Comp`
|
||
- ou monotonie de l’opérateur global `F(K) = Comp(K ∪ Φ(K))`
|
||
|
||
A0.4 (idempotence optionnelle)
|
||
Idempotence est requise pour certains résultats de fermeture, mais ne doit pas être présumée.
|
||
|
||
A0.5 (stabilité sous projection déclarée)
|
||
Si un résultat prétend être invariant par changement de granularité, il doit expliciter l’hypothèse : `Comp` commute (ou presque) avec la projection pertinente.
|
||
|
||
Ces axiomes sont volontairement minimaux : le but est que peu de choses soient “invariantes” et beaucoup soient clairement indexées.
|
||
|
||
### B2. Étiquetage obligatoire des résultats
|
||
|
||
Règle B2.0
|
||
Chaque proposition/théorème doit être marqué :
|
||
|
||
- [Invariant sous A0]
|
||
ou
|
||
- [Dépend de 𝒞_closure]
|
||
ou
|
||
- [Dépend de 𝒞_repair_min, critère = …]
|
||
ou
|
||
- [Dépend de 𝒞_local_r, rayon r = …]
|
||
ou
|
||
- [Dépend de 𝒞_choice, politique = …]
|
||
|
||
Sans ce marquage, le résultat est considéré non validé éditorialement.
|
||
|
||
## Correction C : empêcher l’introduction opportuniste de nouveaux `Comp_type`
|
||
|
||
### C1. Politique de création
|
||
|
||
Règle C1.0
|
||
Un nouveau `Comp_type` ne peut être introduit que s’il satisfait l’une des conditions :
|
||
|
||
- il appartient à une des classes canoniques déjà listées
|
||
- ou il justifie l’ajout d’une nouvelle classe par une motivation structurale et par au moins un résultat invariant non trivial
|
||
|
||
Sinon, il doit être traité comme une instanciation ad hoc dans un appendice, pas comme un élément du noyau.
|
||
|
||
### C2. Politique de paramétrisation
|
||
|
||
Si un `Comp` dépend de paramètres (rayon r, budget, poids), il doit être décrit comme une famille `Comp_θ` et ses résultats doivent être :
|
||
- robustes sur un intervalle de θ, ou
|
||
- explicitement indexés par θ.
|
||
|
||
## Correction D : conséquence directe sur les chapitres 13–16 (verrouillage, sélection, auto-stabilisation, connaissance)
|
||
|
||
La correction n’est pas confinée à 19 ; elle protège les chapitres aval.
|
||
|
||
### D1. Verrouillage (13)
|
||
|
||
Le verrouillage induit par contraintes dépend de `Comp` :
|
||
- toute quantification doit être indexée par la classe de `Comp` si non invariant.
|
||
|
||
### D2. Sélection (14)
|
||
|
||
Si `Comp` choisit, alors `Comp` est une source de biais de sélection :
|
||
- le chapitre 14 doit distinguer `Comp_sat` et `Comp_choice`.
|
||
|
||
### D3. Auto-stabilisation (15)
|
||
|
||
Les théorèmes de point fixe exigent la monotonie :
|
||
- les passages de 15 qui invoquent stabilisation doivent porter l’étiquette [Dépend de 𝒞_closure] ou équivalent.
|
||
|
||
### D4. Connaissance minimale (16)
|
||
|
||
Si la “connaissance” est définie via contraintes stabilisées, alors la stabilité dépend de `Comp` :
|
||
- la notion doit être robuste sur une classe de `Comp` ou explicitement indexée.
|
||
|
||
## Correction E : protocole de robustesse pour `Comp`
|
||
|
||
La théorie doit rendre testable la sensibilité à `Comp`.
|
||
|
||
Règle E0
|
||
Lorsqu’un résultat est dépendant, il doit être accompagné d’un protocole de robustesse sur une famille `Comp_θ` ou sur plusieurs classes canoniques.
|
||
|
||
Exemples de tests
|
||
- comparer `Comp_closure` vs `Comp_repair_min`
|
||
- varier `r` dans `Comp_r` et observer la persistance du phénomène
|
||
- varier une politique de choix dans `Comp_choice` et mesurer l’amplitude des effets
|
||
|
||
Critère
|
||
Un phénomène peut être déclaré “structurel” s’il persiste sur plusieurs classes ou sur un ensemble non trivial de paramètres.
|
||
|
||
## Conclusion
|
||
|
||
Le chapitre 19 a correctement ouvert la voie en explicitant admissibilité et compatibilité. La correction proposée ici vise à éviter un retour de plasticité via la prolifération des `Comp_type`.
|
||
|
||
La solution repose sur une discipline standard :
|
||
|
||
- définir un petit nombre de classes canoniques d’opérateurs `Comp` ;
|
||
- isoler un noyau d’axiomes minimal pour les résultats dits invariants ;
|
||
- étiqueter systématiquement chaque résultat comme invariant ou dépendant d’une classe/politique/paramètre ;
|
||
- empêcher l’introduction opportuniste de nouveaux `Comp_type` sans justification structurale ;
|
||
- rendre la dépendance à `Comp` testable via un protocole de robustesse.
|
||
|
||
Ainsi, la théorie conserve son universalité formelle tout en restant réfutable et discriminante : elle ne devient pas un catalogue de paramétrages, mais un cadre où l’on sait précisément ce qui tient “pour tous” et ce qui dépend d’un choix.
|