Note : Ceci est une note de recherche complétant le livre L’ère de la post-pénurie, désormais disponible à l’achat. Ces notes approfondissent les concepts du texte principal. Commencez ici ou procurez-vous le livre.

L’architecture MOSAÏQUE : comment gérer une civilisation sans étiquette de prix

Pour les ingénieurs logiciels sceptiques que la coordination post-monnaie puisse passer à l’échelle

---

Pourquoi c’est important maintenant

Nous approchons d’un point d’inflexion. Les systèmes IA deviennent capables d’effectuer la plupart du travail cognitif. L’énergie de fusion promet une puissance propre quasi illimitée. La fabrication automatisée peut produire des biens physiques avec un minimum d’intervention humaine. Pour la première fois dans l’histoire, nous avons la capacité technique de fournir des vies confortables à tous sur Terre.

Mais nos systèmes de coordination supposent la rareté. Les marchés allouent les ressources par le prix, ce qui signifie que quiconque a de l’argent est servi en premier. Les institutions démocratiques se déplacent à la vitesse de la législation, ce qui signifie qu’elles ne peuvent pas s’adapter au changement technologique exponentiel. Les entreprises optimisent pour les rendements des actionnaires, ce qui signifie qu’elles automatiseront les travailleurs hors de leurs emplois sans fournir d’alternatives.

La question n’est pas de savoir si nous pouvons produire l’abondance. Nous le pouvons. La question est de savoir si nous pouvons la distribuer sans les mécanismes de coordination sur lesquels nous nous sommes appuyés pendant des siècles : l’argent, les marchés, et la menace implicite de la pauvreté.

Cet article fournit la réponse d’ingénierie.

---

« Vous ne pouvez pas coordonner une économie complexe sans prix. »

Chaque économiste, expert politique, et oncle libertarien l’a dit. Friedrich Hayek a construit toute une carrière en prouvant que les prix sont le seul moyen d’agréger les connaissances distribuées. Les marchés sont la façon dont l’univers dit « comprenez-le, nerds ».

Voici la vérité inconfortable : Nous avons déjà prouvé que Hayek avait tort — à plusieurs reprises.

Google Maps coordonne 154 millions d’utilisateurs quotidiens sans que personne ne paie pour le routage prioritaire. Wikipédia produit l’encyclopédie la plus complète de l’humanité avec 200 000 modifications quotidiennes — aucun échange d’argent. Linux fait fonctionner la plupart des serveurs du monde par coordination volontaire. Votre e-mail va de New York à Tokyo par des protocoles fédérés que personne ne possède.

La question n’est pas peut-on coordonner sans prix. La question est : Peut-on étendre ces schémas de l’information aux ressources physiques ?

Cet article fournit la réponse d’ingénierie.

---

L’erreur de catégorie que tout le monde fait

Quand vous entendez pour la première fois « civilisation sans argent », votre cerveau atteint immédiatement deux mauvais modèles :

Mauvais modèle #1 : « Donc c’est blockchain ? »

Non. La blockchain résout le problème d’atteindre un consensus parmi des étrangers mutuellement méfiants qui ont besoin d’un ordre de transaction strict. C’est brillant pour « qui possède ce Bitcoin ? » et catastrophiquement sur-conçu pour « devrions-nous construire un hôpital ici ? »

La blockchain suppose l’anonymat adversarial. La MOSAÏQUE suppose une coopération consciente de l’identité parmi des communautés fédérées avec des objectifs alignés. Problème différent, architecture différente.

La preuve de travail de blockchain a du sens quand :

• Les participants sont anonymes et potentiellement hostiles
• L’ordre des transactions doit être globalement cohérent
• Le transfert de valeur financière est le cas d’usage principal
• Brûler l’énergie d’un petit pays est un compromis acceptable

La MOSAÏQUE a besoin :

• Consensus conscient de l’identité (vous êtes responsable, pas anonyme)
• Coordination finalement cohérente (nous n’avons pas besoin de précision atomique)
• Flux de ressources multidimensionnels (logement ≠ santé ≠ calcul)
• Efficacité énergétique (nous gérons la civilisation, pas un casino de spéculation)

Mauvais modèle #2 : « Donc il y a une base de données centrale ? »

Également non. Les bases de données centrales créent des points uniques de défaillance (technique), des points uniques de capture (politique), et des points uniques de « oups, l’autoritaire vient de saisir la salle des serveurs ».

La MOSAÏQUE est fédérée, pas centralisée. Pensez DNS, pas Oracle Database. Pensez à la pile de protocoles internet, pas Amazon Web Services.

Le bon modèle : TCP/IP pour la civilisation

La MOSAÏQUE (Communautés Modulaires, Autonomes et Interconnectées) est à la coordination des ressources ce que TCP/IP est à la transmission de données.

TCP/IP ne contrôle pas internet — il permet aux réseaux indépendants d’interopérer. De même :

• La MOSAÏQUE ne contrôle pas l’allocation des ressources
• Elle fournit des protocoles pour que les communautés (Communs) se coordonnent
• Chaque Commun maintient son autonomie
• Les protocoles partagés permettent l’interopérabilité
• La transparence permet la responsabilité

Le Maillage Civique est la couche protocolaire. La MOSAÏQUE est la civilisation qui tourne dessus.

---

Les cinq structures de données qui remplacent l’argent

L’argent fait une chose : réduire la valeur multidimensionnelle en un seul scalaire. C’est pratique pour l’échange, mais c’est un algorithme de compression avec perte pour la contribution humaine.

Le Maillage Civique opère sur cinq structures de données plus riches.

1. Journaux de contribution (append-only, distribués)

Objectif : Enregistrer qui a contribué quoi, quand, dans quel contexte, et ce que cela a permis.

JournalContribution {
  id: UUID
  contributeur: IdentiteHandle
  horodatage: ISO8601
  type_contribution: Enum[Travail, Ressource, Coordination, Connaissance, Soin]
  domaine: String  // e.g., "sante", "logement", "energie"
  verification: {
    temoins: [IdentiteHandle]  // validateurs pairs qui l'ont vu se produire
    score_diversite: Float       // métrique Preuve-de-Diversité
    piste_audit: Merkle_root     // détection de falsification
  }
  contexte: {
    mission: MissionID           // quelle Guilde ou projet
    activation: VecteurImpact     // qu'est-ce que cela a rendu possible ?
    ressources_consommees: VecteurRessource  // qu'est-ce que cela a coûté au système ?
  }
}

Pourquoi cela bat un chèque de paie :

Un chèque de paie dit « vous avez travaillé 40 heures ». Un Journal de contribution dit « vous avez mentoré trois ingénieurs en conception de réacteur à fusion, ce qui a accéléré le projet d’Osaka de deux mois, validé par six pairs sur trois continents ».

L’un est un nombre. L’autre est une histoire.

Schéma de stockage : Table de hachage distribuée avec stockage adressé par contenu (comme IPFS). Chaque contribution est immuable, avec des références formant un graphe acyclique dirigé de « qui a permis quoi ». Pensez à l’historique de commit de Git — décentralisé, auditable, évident de falsification, sans surcharge blockchain.

2. Demandes de ressources (signaux de demande)

Objectif : Faire remonter ce dont les gens ont besoin sans exiger de paiement.

DemandeRessource {
  id: UUID
  demandeur: IdentiteHandle
  type_ressource: Enum[Logement, Sante, Equipement, Calcul, etc.]
  quantite: VecteurRessource  // multidimensionnel, pas juste un compte
  contexte: {
    mission: MissionID        // qu'est-ce que cela permet ?
    urgence: Enum[Routine, Priorite, Urgence]
    alternatives_considerees: [RessourceID]  // avez-vous essayé des substituts ?
    duree: Plage_temps        // temporaire ou permanent ?
  }
  prevision_impact: {
    permet: [DescriptionResultat]  // qu'est-ce que cela rendra possible ?
    necessite: VecteurRessource       // chaîne de dépendance complète
    cout_opportunite: VecteurRessource  // que pourraient faire ces ressources d'autre ?
  }
}

Pourquoi cela bat une transaction de marché :

Les marchés ne voient que la demande effective — ce pour quoi vous pouvez payer. Ils sont aveugles au chercheur brillant qui ne peut pas se permettre l’équipement de laboratoire, à la communauté qui a besoin d’une clinique mais n’a pas d’argent, à l’innovation qui meurt dans la tête de quelqu’un parce qu’il ne pouvait pas quitter son emploi pour la poursuivre.

Les Demandes de ressources font remonter le besoin réel avec contexte. Le système voit « Maria a besoin d’accès à la fabrication pour prototyper un filtre à eau qui pourrait servir 10 000 personnes » — pas juste « Maria a 0 $ ».

Schéma de stockage : Bases de données de séries temporelles avec agrégation préservant la vie privée. Les demandes individuelles sont éphémères ; les schémas de demande agrégés persistent. Similaire à Google Analytics — les vues de page disparaissent, les schémas de trafic permettent un routage intelligent.

3. Profils de réputation (déclinant, spécifique au domaine)

Objectif : Distinguer le signal du bruit sans créer de hiérarchies permanentes.

ProfilReputation {
  identite: IdentiteHandle
  domaines: {
    [nom_domaine]: {
      score_actuel: Float       // décline exponentiellement
      contributions_recentes: [ContributionID]
      approbations_pairs: {
        [approbateur]: Float        // pondéré par réputation de l'approbateur
      }
      echecs: [JournalEchec]     // les erreurs comptent
      bonus_diversite: Float     // poids supplémentaire pour travail inter-domaine
      derniere_mise_a_jour: ISO8601
      taux_declin: Float          // Axiome IV des Cinq Lois : Le pouvoir doit décliner
    }
  }
}

La fonction de déclin :

reputation(t) = reputation_base × e^(-λ × t)

Où :
  λ = constante de déclin (configurée par domaine)
  t = temps depuis la contribution
  reputation_base = valeur de contribution validée par pairs

Pourquoi le déclin compte :

Sans déclin, la réputation se compose en oligarchie. La personne qui a fait du bon travail en 2025 ne devrait pas automatiquement dominer les décisions en 2045. Le déclin impose l’Axiome IV des Cinq Lois (Le pouvoir doit décliner) — vous devez continuellement gagner l’influence.

Contrairement à votre indice h, qui vous piège dans votre passé pour toujours, la réputation ici ressemble plus à un classement de tennis : la performance récente compte le plus.

4. Comptes de points d’impact (non transférables, déclinants)

Objectif : Coordonner l’accès aux 10 % d’Ascension (extension de vie, missions interstellaires, exploration de conscience) sans créer de marchés.

ComptePointsImpact {
  identite: IdentiteHandle
  solde: Float              // IMP actuel
  gagne: {
    [id_contribution]: {
      montant: Float
      gagne_a: ISO8601
      expire_a: ISO8601     // IMP déclinent et expirent
      domaine: String
      valide_par: [IdentiteHandle]
    }
  }
  depense: [Transaction]        // à quoi les avez-vous utilisés ?
  calendrier_declin: FonctionDeclin // déclin annuel de 10 % (Axiome IV)
}

Contraintes critiques :

• Non transférable : Vous ne pouvez pas vendre d’IMP. Vous ne pouvez pas donner d’IMP. Si vous le pouviez, ils deviendraient monnaie. Les marchés se formeraient. La spéculation commencerait. Nous serions de retour là où nous avons commencé.

• Déclinant : Déclin annuel de 10 %, demi-vie de ~7 ans. Sans déclin, les contributeurs précoces deviennent des élites permanentes. Le déclin assure que le pouvoir est re-gagné chaque génération.

Fonction de déclin :

IMP_restant(t) = IMP_initial × e^(-0,1 × t)

Richard Castellano, le milliardaire de la logistique du chapitre 8, obtient des Crédits fondateurs par le Protocole EXIT — mais même ceux-ci déclinent à 5 % annuellement. Ses petits-enfants n’héritent rien à moins qu’ils ne le gagnent eux-mêmes.

5. Ensembles de validateurs Preuve-de-Diversité (sélectionnés aléatoirement, validés statistiquement)

Objectif : Empêcher la capture en s’assurant que les décisions majeures nécessitent un consensus de groupes véritablement divers.

EnsembleValidateur {
  id_decision: UUID
  criteres_selection: {
    dimensions_min: Int  // e.g., 5
    entropie_requise: {
      geographique: Float   // bits d'entropie de Shannon
      economique: Float
      culturel: Float
      generationnel: Float
      professionnel: Float
    }
    validateurs_min: Int   // typiquement 7
  }
  selectionnes: {
    [identite]: {
      attributs_diversite: Map[String, String]
      probabilite_selection: Float
      vote: Enum[Approuver, Rejeter, Abstention]
      raisonnement: Text       // pourquoi ?
    }
  }
  score_diversite: Float  // entropie de Shannon agrégée
  seuil: Float        // e.g., 0,67 supermajorité
}

L’algorithme de sélection assure que vous ne pouvez pas remplir un panel avec vos amis. Les validateurs sont sélectionnés aléatoirement pour maximiser la diversité à travers plusieurs dimensions. Même si vous contrôlez 20 % de chaque catégorie démographique (géographique, économique, culturelle, générationnelle, professionnelle), la probabilité de capturer un panel divers de 7 personnes est :

P(capture) = (0,2)^5 = 0,00032 (0,032 %)

Comparez cela à capturer une simple majorité : 51 %.

C’est la Garde de la Diversité en action — le pare-feu de gouvernance qui rend la tyrannie coordonnée statistiquement improbable. Voir Mathématiques de la Garde de la Diversité pour la preuve complète.

---

Preuve-de-Diversité : le mécanisme de consensus qui n’est pas blockchain

La blockchain demande : « Sommes-nous d’accord sur l’ordre des transactions ? »

La MOSAÏQUE demande : « Des perspectives diverses sont-elles d’accord que c’est une bonne idée ? »

Question différente, mécanisme différent.

Comment fonctionne la Preuve-de-Diversité (PoD)

Étape 1 : La décision déclenche la validation

Une Guilde de Logement propose : « Rediriger 10 % de la capacité de fabrication régionale des maisons unifamiliales vers des bâtiments multi-unités. »

Cela affecte plusieurs Communs → déclenche la validation PoD.

Étape 2 : Sélection aléatoire de validateurs divers

Le système sélectionne 7 validateurs nécessitant :

• Diversité géographique (urbain, suburbain, rural)
• Diversité économique (secteurs différents)
• Diversité culturelle (origines différentes)
• Diversité générationnelle (jeune, mi-carrière, senior)
• Diversité professionnelle (domaines d’expertise différents)

Étape 3 : Les validateurs examinent et votent

Chaque validateur voit :

• Texte complet de la proposition
• Prévision d’impact (qui bénéficie, qui supporte les coûts)
• Exigences en ressources
• Propositions alternatives considérées
• Précédent historique (que s’est-il passé quand nous avons fait des choses similaires ?)

Ils votent avec raisonnement :

• APPROUVER : « Cela aborde la pénurie de logements sans coût énergétique excessif »
• REJETER : « Infrastructure hydraulique insuffisante pour soutenir l’augmentation de densité »
• ABSTENTION : « Besoin de plus de données sur la capacité de transit »

Étape 4 : Détection de corrélation

Voici où cela devient intelligent. Le système exécute des tests statistiques pour détecter la capture coordonnée :

def detecter_vote_bloc(votes, attributs_validateur):
    """
    Signaler les décisions où les votes sont corrélés de manière suspecte
    avec une dimension démographique unique.
    """
    for dimension in DIMENSIONS_DIVERSITE:
        contingence = construire_table_contingence(votes, dimension)
        chi2, p_value, dof, expected = chi2_contingency(contingence)

        # p < 0,1 signifie que les votes sont suspectement corrélés
        if p_value < 0,1:
            return {
                "suspect": True,
                "dimension": dimension,
                "recommandation": "Rééchantillonner ou escalader vers revue Cinq Lois"
            }

    return {"suspect": False}

Si tous les 7 validateurs des zones urbaines votent OUI sur une politique pro-urbaine et que le test du chi-carré montre p-value = 0,03 — quelque chose est louche. Rééchantillonner ou escalader.

Étape 5 : Décision enregistrée

Si le vote passe le seuil :

• Décision implémentée
• Raisonnement des validateurs publié (Axiome II des Cinq Lois : La vérité doit être vue)
• Le suivi d’impact commence (la prévision correspondait-elle à la réalité ?)

Si rejetée :

• Décision bloquée
• Raisonnement publié
• Les proposants peuvent réviser et resoumettre

Pourquoi cela fonctionne : les mathématiques de rendre la tyrannie difficile

La Tolérance aux fautes byzantines dit : n ≥ 3f + 1, où f est le nombre de validateurs potentiellement compromis.

Pour f = 2 (tolérer 2 mauvais acteurs), n ≥ 7.

Mais avec les exigences de diversité, la probabilité que 2 mauvais acteurs soient tous deux sélectionnés d’origines diverses est multiplicativement petite :

P(attaque | PoD) = P(controle_dimension_A) × P(controle_dimension_B) × ...

Pour 5 dimensions avec 10 % de contrôle chacune :
P(attaque) = 0,1^5 = 0,00001 (0,001 %)

Comparez au vote majoritaire homogène :

P(attaque | majorite) = 0,51 (51 %)

PoD est informatiquement bon marché mais socialement coûteux à attaquer. Vous ne pouvez pas acheter votre entrée — vous devez construire un soutien véritable à travers des populations statistiquement diverses.

Dimension	Blockchain (PoW/PoS)	Preuve-de-Diversité
Objectif	Ordonner les transactions	S’assurer que des perspectives diverses sont d’accord
Paramètre de sécurité	Puissance de calcul ou mise	Diversité des validateurs
Coût énergétique	Élevé	Négligeable
Vecteur d’attaque	Attaque à 51 %	Doit contrôler toutes les dimensions démographiques
Scalabilité	Limitée	Élevée (seuls les validateurs sélectionnés votent)

---

Résolution de litiges : robots d’abord, humains pour les trucs difficiles

La plupart des conflits sont triviaux. Un conflit d’horaire n’est pas une crise philosophique. Le système gère 99 % automatiquement, n’escaladant que les cas véritablement difficiles au jugement humain.

La hiérarchie de résolution de litiges

Niveau 0 : Automatisé (99 % des cas)
├─ Conflits de ressources → Algorithmes de partage de temps
├─ Conflits d'horaire → Optimisation de calendrier
├─ Équilibrage de charge → Redistribuer à travers la capacité
└─ Anomalies de métrique → Signaler et auto-ajuster

Niveau 1 : Médiation par pairs (0,9 % des cas)
├─ Négociation Guilde-à-Guilde
├─ IA facilite en faisant remonter le contexte
├─ Résolution en 48 heures
└─ Résultat publié comme précédent

Niveau 2 : Arbitrage civique (0,09 % des cas)
├─ Panel neutre (sélectionné PoD)
├─ Audience formelle avec preuves
├─ Décision contraignante sauf appel
└─ Raisonnement publié

Niveau 3 : Revue constitutionnelle (0,01 % des cas)
├─ Questions systémiques affectant les axiomes des Cinq Lois
├─ Exigences de diversité plus élevées (15+ validateurs)
├─ Seuil de supermajorité (80 %+)
└─ Crée un précédent contraignant

Exemple : contention de ressources

Scénario : Deux Guildes veulent la même installation de fabrication en même temps.

Résolution automatisée :

def resoudre_conflit_fabrication(demande_A, demande_B, installation):
    # Vérifier l'urgence
    if demande_A.urgence == "Urgence" and demande_B.urgence != "Urgence":
        return allouer_a(demande_A), suggerer_alternative(demande_B)

    # Vérifier l'impact relatif
    impact_A = prevoir_impact(demande_A)
    impact_B = prevoir_impact(demande_B)

    if impact_A > impact_B * 1.5:  # Gagnant clair
        return allouer_a(demande_A), differer(demande_B)

    # Vérifier la flexibilité de délai
    if demande_A.echeance > demande_B.echeance:
        return differer(demande_A), allouer_a(demande_B)

    # Aucun gagnant algorithmique clair → escalader
    return escalader_vers_mediation([demande_A, demande_B])

Si escaladé vers médiation par pairs :

Les représentants se rencontrent avec facilitation IA :

• L’IA fait remonter le contexte pertinent (projets passés, schémas de consommation, précédent historique)
• Chaque Guilde explique pourquoi sa demande est urgente
• Le médiateur propose des options :
  • Partage de temps (Guilde A : matins, Guilde B : après-midis)
  • Retarder le projet de priorité inférieure de 2 semaines
  • Utiliser installation alternative avec temps de transit plus long

Les Guildes négocient. Résultat publié : « Conflit de ressources résolu par partage de temps ; aucun projet retardé. »

Détection d’échec de Guilde

Les Guildes peuvent dériver de leur mission, gaspiller des ressources, ou juste… arrêter de fonctionner. Le système détecte et répond.

class MetriquesSanteGuilde:
    derive_mission: Float      # alignement de sortie avec mission déclarée
    efficacite_ressource: Float  # ressources consommées vs. impact créé
    satisfaction_contributeur: Float  # les membres sont-ils épanouis ?
    reputation_externe: Float  # évaluations des Guildes pairs
    coherence_livraison: Float  # promesses vs. résultats

    def score_sante(self) -> Float:
        return moyenne_ponderee([
            (self.derive_mission, 0.3),
            (self.efficacite_ressource, 0.2),
            (self.satisfaction_contributeur, 0.2),
            (self.reputation_externe, 0.15),
            (self.coherence_livraison, 0.15)
        ])

Si le score de santé tombe en dessous du seuil :

1. Signaler pour revue par pairs (panel sélectionné PoD)
2. Le panel examine les métriques, l’historique, les témoignages de membres, les Guildes comparables
3. Décision : Restructurer ? Nouvelle direction ? Déprécier et rediriger les membres ?

Similaire aux vérifications de santé Kubernetes — surveillance automatisée, décisions humaines pour échecs complexes.

---

Vecteurs d’attaque et défenses

Tout système de coordination doit se défendre contre le détournement, la capture, et les mauvais acteurs. Voici comment la MOSAÏQUE gère les attaques classiques.

Attaque 1 : Attaques Sybil (fausses identités)

Menace : Créer des milliers de fausses identités pour manipuler le vote ou l’allocation de ressources.

Défense : L’identité n’est pas anonyme — elle est persistante et responsable.

• Modèle réseau de confiance : Les nouvelles identités nécessitent parrainage de 3+ membres établis
• Preuve de personnalité : Vérification périodique (appel vidéo, rassemblement en personne, biométrie)
• Mise en jeu de réputation : Les parrains risquent leur propre réputation en se portant garant
• Délai : Les nouvelles identités ne peuvent pas voter immédiatement

Coût pour l’attaquant : Créer une fausse identité nécessite de compromettre 3+ membres établis qui ont leur propre réputation en jeu. Créer une armée de fausses nécessite O(n) parrains compromis.

Attaque 2 : Capture (contrôler la sélection des validateurs)

Menace : Manipuler qui est sélectionné comme validateurs pour approuver des décisions favorables.

Défense : Sélection randomisée + diversité obligatoire.

• L’algorithme de sélection optimise pour l’entropie de Shannon à travers les dimensions
• Les seuils de diversité empêchent les panels homogènes
• La détection de corrélation statistique signale les schémas de vote suspects

Même avec 20 % de contrôle à travers toutes les 5 dimensions de diversité :

P(capture) = (0,2)^5 = 0,00032 (0,032 %)

Attaque 3 : Collusion (coordination à travers les validateurs)

Menace : Les validateurs acceptent secrètement de voter en bloc indépendamment du mérite.

Défense : Transparence + détection statistique.

• Tous les votes et raisonnements sont publics (pseudonymes mais auditables)
• Les tests du chi-carré détectent la corrélation entre votes et démographie
• Si p < 0,1, la décision est signalée pour revue
• La collusion répétée détruit la réputation

Attaque 4 : Loi de Goodhart (détourner les métriques)

Menace : Optimiser pour des métriques mesurées tout en ignorant les objectifs réels.

Défense : Métriques multidimensionnelles + revue par pairs.

• Aucune métrique unique ne détermine les résultats
• Les métriques sont riches en contexte (pas réductibles à un nombre)
• La revue par pairs attrape le détournement que les algorithmes ratent
• Le détournement nuit à la réputation à long terme

Exemple :

Une Guilde rapporte « impact élevé » en comptant les personnes servies. Mais les Guildes pairs remarquent : « Ils distribuent des jetons sans vérifier si quelqu’un en bénéficie. »

Revue par pairs → coup de réputation → futures demandes examinées.

---

À quoi cela ressemble réellement : la pile

┌─────────────────────────────────────────────────────────┐
│  Couche de protocole Maillage Civique (standard ouvert) │
│  - Protocole de demande de ressource (RRP)              │
│  - Protocole de validation de contribution (CVP)        │
│  - Protocole Preuve-de-Diversité (PoDP)                 │
│  - Protocole de résolution de litige (DRP)              │
└─────────────────────────────────────────────────────────┘
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│  Communs A    │ │  Communs B    │ │  Communs C    │
│  (Nœud local) │ │  (Nœud local) │ │  (Nœud local) │
└───────────────┘ └───────────────┘ └───────────────┘
        │                 │                 │
        └─────────────────┴─────────────────┘
                          │
                ┌─────────┴─────────┐
                ▼                   ▼
        ┌──────────────┐    ┌──────────────┐
        │ Stockage DHT │    │ Séries temps │
        │ (type IPFS)  │    │ (InfluxDB)   │
        └──────────────┘    └──────────────┘

Flux de données : demande de ressource

1. L’utilisateur soumet une demande via l’interface des Communs locaux → enregistrée avec horodatage, identité, contexte

2. L’IA locale analyse → Routine ? Auto-approuver et router. Inhabituel ? Signaler pour revue.

3. Si signalé, initier PoD → Sélectionner 7 validateurs divers → collecter votes + raisonnement

4. Agréger les votes → vérifier métriques de diversité → exécuter détection de corrélation → publier décision

5. Allocation de ressource → Si approuvé : router vers Guilde. Si rejeté : notifier avec raisonnement.

6. Suivi d’impact → Cela a-t-il permis les résultats attendus ? Boucle de rétroaction ajuste les modèles.

Esquisse d’API

# Demande de ressource
maillage_civique.demander_ressource(
    type_ressource="installation_fabrication",
    quantite=VecteurRessource(heures=20, energie_kwh=500),
    mission="Prototype système désalinisation eau",
    prevision_impact="Permettre test de membrane 10x plus efficace",
    echeance=datetime(2048, 3, 15)
)

# Enregistrer contribution
maillage_civique.enregistrer_contribution(
    contributeur=identite.handle,
    type_contribution="transfert_connaissance",
    domaine="systemes_eau",
    description="Mentoré 5 ingénieurs sur conception osmose inverse",
    temoins=[ing1.handle, ing2.handle, ing3.handle],
    activation="Accéléré projet désalinisation de 2 mois"
)

# Validation PoD
decision = maillage_civique.valider_decision(
    proposition="Augmenter allocation eau à l'agriculture de 15 %",
    population_affectee=["fermiers", "residents_urbains", "industrie"],
    exigences_diversite={
        "geographique": 2.0,  # bits d'entropie
        "economique": 1.5,
        "culturel": 1.8
    },
    seuil=0.67
)

---

Performance : cela peut-il vraiment passer à l’échelle ?

TL;DR : Oui. La preuve d’existence est tout autour de vous.

Scalabilité

Opération	Complexité
Enregistrement de contribution	O(1) par contribution
Routage de demande de ressource	O(log n) où n = Guildes
Sélection de validateur PoD	O(k × d) où k=7, d=5
Résolution automatisée de litige	O(1) pour la plupart des cas

Latence

Opération	Typique	Maximum
Demande de ressource routine	< 1 seconde	10 secondes
Enregistrement de contribution	< 1 seconde	5 secondes
Validation PoD (démarrage à froid)	24-48 heures	7 jours
Résolution automatisée de litige	< 10 secondes	1 minute
Médiation par pairs	1-3 jours	1 semaine
Revue constitutionnelle	2-4 semaines	90 jours

Objectifs de débit

• 1 milliard+ demandes de ressources/jour — Google Maps gère 1,5 milliard de routes quotidiennes
• 100 millions+ journaux de contribution/jour — Échelle Wikipédia : 597 millions de modifications/an à travers Wikimedia
• 1 million+ validations PoD/jour — rare ; la plupart des décisions sont routinières
• 10 000+ résolutions de litiges/jour — principalement automatisées

Stockage

• Journaux de contribution : ~100 GB/jour → ~10 TB/an actif, 100+ TB historique
• Demandes de ressources (agrégées) : ~1 TB actif (fenêtre glissante de 90 jours)
• Scores de réputation : ~10 KB × 1B identités = 10 TB
• Total actif : ~50-100 TB distribué à travers les nœuds

L’infrastructure moderne gère cela trivialement. Nous ne demandons pas de miracles — nous demandons ce que Google fait pour les pubs, mais pour la coordination des ressources.

---

Relation avec ce qui fonctionne déjà

La MOSAÏQUE n’est pas entièrement nouvelle. Elle compose des schémas éprouvés.

Ce que nous empruntons à Bitcoin

Consensus distribué, journaux évidents de falsification, validation transparente.

Ce que nous changeons

Conscient de l’identité (pas anonyme), PoD (pas PoW), multidimensionnel (pas juste transactions), économe en énergie (pas de minage).

Ce que nous empruntons à Kubernetes

Demandes de ressources déclaratives, ordonnancement automatisé, surveillance de santé, isolation d’espace de noms.

Ce que nous changeons

Coordonne humains + ressources physiques (pas conteneurs), tolérance aux fautes byzantines par diversité (pas simple majorité), pondéré par réputation (pas contrôlé par admin).

Ce que nous empruntons au DNS

Architecture fédérée, autorité hiérarchique avec autonomie locale, mise en cache, cohérence finale.

Ce que nous changeons

Coordonne flux de ressources (pas résolution de noms), PoD empêche capture (pas juste signatures), raisonnement transparent (pas juste recherches).

Ce que nous empruntons à Google Maps

Agrégation d’information en temps réel, routage augmenté par IA, prise de décision distribuée, boucles de rétroaction.

Ce que nous changeons

Ressources multidimensionnelles (pas juste temps de trajet), suivi de contribution (pas GPS anonyme), résolution de litiges (pas juste routes alternatives).

---

Questions ouvertes

Aucun système n’est complet. Voici ce qui nécessite encore du travail.

Identité sans gouvernement

La conception actuelle suppose identité cryptographique + attestation sociale. Mais :

• Comment amorcer la confiance dans un tout nouveau Commun ?
• Que faire si les réseaux d’attestation sociale sont compromis ?
• Comment gérer la perte de clé sans autorité centrale ?

Potentiel : Protocoles de récupération sociale (modèle portefeuille Argent), recours biométriques, entiercement de réputation.

Coordination inter-Communs

Chaque Commun fonctionne indépendamment. Comment interopèrent-ils sur des projets complexes multi-Communs ? Qu’en est-il des litiges entre Communs ?

Potentiel : Résolution de litiges fédérée, traités inter-Communs, couches d’infrastructure partagées.

Biais IA

Les systèmes IA héritent des biais des données d’entraînement. Comment détecter quand les recommandations IA favorisent systématiquement certains groupes ?

Potentiel : Tests adversariaux, données d’entraînement diverses, audit de modèle transparent, revue humaine.

Transition

La plupart de l’infrastructure fonctionne sur l’argent. Comment migrer les systèmes existants ? Gérer les périodes hybrides où argent et MOSAÏQUE coexistent ?

Potentiel : Zones Libres comme pilotes de Phase Zéro, systèmes à double voie, dépréciation graduelle.

Voir : La transition : EXIT ou le feu et Protocole EXIT entreprise.

---

Le résultat final : nous faisons déjà cela

Les sceptiques disent : « Vous ne pouvez pas coordonner des systèmes complexes sans marchés. »

La MOSAÏQUE répond : « Nous le faisons déjà — pour le trafic, la connaissance, le code, et le contenu. Maintenant faisons-le pour les ressources physiques. »

Google Maps coordonne les déplacements quotidiens de 154 millions de personnes sans que personne ne paie pour le routage prioritaire. Les 200 000 modifications quotidiennes de Wikipédia produisent de meilleures informations que n’importe quelle entreprise. Linux fait fonctionner 96 % des millions de serveurs web principaux du monde par coordination volontaire.

La question n’est pas de savoir si la coordination post-prix est possible.

La question est de savoir si nous la construirons avant que les systèmes de l’ère de rareté ne s’effondrent sous le poids de l’abondance technologique.

La Falaise de l’Emploi arrive dans les années 2030. La fusion devient commerciale entre 2045 et 2055. L’IA surpasse déjà les humains sur la plupart des tâches cognitives.

L’infrastructure de l’abondance existe. La question est de savoir si nous construirons la couche de coordination pour la distribuer — ou regarderons-nous être capturée par les mêmes structures qui ont créé la rareté en premier lieu.

La MOSAÏQUE est une réponse. Les schémas de code existent. L’ingénierie est traitable.

La seule question est la volonté.

---

Références et lectures complémentaires

Fondations des systèmes distribués :

• Lamport, L., Shostak, R., & Pease, M. (1982). “The Byzantine Generals Problem.” ACM Transactions
• Castro, M., & Liskov, B. (1999). “Practical Byzantine Fault Tolerance.” OSDI
• Maymounkov, P., & Mazières, D. (2002). “Kademlia: A Peer-to-Peer Information System Based on the XOR Metric”

Coordination sans marchés :

• Benkler, Y. (2006). The Wealth of Networks
• Ostrom, E. (1990). Governing the Commons
• Raymond, E. S. (1999). The Cathedral and the Bazaar

Statistiques actuelles :

• Google Maps Statistics 2025 — 154 millions d’utilisateurs actifs quotidiens, 1,5 milliard de routes calculées quotidiennement
• Wikipedia Statistics — 597 millions de modifications à travers les projets Wikimedia en 2024

Articles de la post-pénurie connexes :

• Preuve-de-Diversité : Vue d’ensemble courte
• Mathématiques de la Garde de la Diversité : Preuve statistique complète
• Mécanisme de coordination de Guilde : Comment les Guildes de Mission fonctionnent réellement
• L’IA comme arbitre, les humains comme conscience : Rôle de l’IA dans la gouvernance
• Loi de Goodhart et gouvernance IA : Prévenir le détournement de métriques

---

© 2025 Patrick Deglon. Tous droits réservés.