algo/v0/chapitre28.md

# 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.