De l'observabilité des événements à l'architecture épistémique
Dans les systèmes déterministes classiques, le replay semble direct : un événement entre dans un service, est traité, la sortie est reproductible. Mais cette reproductibilité repose sur des hypothèses fragiles même en déterministe. Une base de données change. Une API se met à jour. La configuration se décale. L’ordre des événements dans une queue diffère. Le replay exact est souvent impossible, même déterministiquement.
Dans les systèmes probabilistes, la différence structurelle n’est pas que le replay devient impossible—c’est que la dimensionnalité de ce qui doit être préservé augmente. Formellement : D_t = f(E, S, C, M, R, T, ξ)—événement, état d’exécution, contexte, modèle, preuves récupérées, outils invoqués, variance incontrôlée.
Le replay exact n’est pas intrinsèquement impossible ; il exige de geler assez de l’environnement d’exécution—graines aléatoires, versions runtime, poids du modèle, état du corpus, réponses des outils, configuration matérielle—que la variance résiduelle devienne négligeable. Cette préservation a un coût.
La réalité architecturale : le coût de reproductibilité augmente avec la dimensionnalité. Une dimension nouvelle émerge : la profondeur épistémique. Vous devez préserver non seulement l’état d’exécution et l’environnement, mais les conditions épistémiques sous lesquelles l’assertion a été produite.
Par conséquent : le replay exact devient un choix économique, non un binaire technique. La question n’est pas « pouvons-nous faire replay ? » mais « quel niveau de reproductibilité la conséquence de cette décision justifie-t-elle ? »
Dans les systèmes classiques, l’unité d’observabilité est l’événement. Les journaux d’événements construisent l’historique.
Dans les systèmes probabilistes, une couche nouvelle émerge : l’assertion—un résultat de calcul portant l’incertitude épistémique. Nous devons maintenant distinguer soigneusement :
Événement : Ce qui s’est passé (entrée, déclencheur, message). Exécution : Comment cela a été traité (conditions, chemin computationnel). Assertion : Ce qui a été produit (résultat avec statut épistémique). Décision : Quelle action a été choisie (assertion + politique + autorité).
Chacun répond à une question distincte et porte des métadonnées distinctes. L’enveloppe d’événement capture le quoi. L’enveloppe d’exécution capture le comment. L’enveloppe d’assertion capture quel résultat et avec quel statut épistémique. L’enveloppe de décision capture quelle action avec quelle autorité.
Cette progression reproduit l’évolution classique de l’observabilité : monitoring (événement) → observabilité (assertion) → auditabilité (décision avec justification).
L’insight critique : l’assertion est l’unité épistémique. La décision est l’unité opérationnelle. Elles ne doivent pas être confondues.
Les systèmes de type classiques codent la structure (« c’est une chaîne »). Le typage sémantique a ajouté du sens (« c’est une classification de sévérité »). Le typage épistémique code maintenant comment nous savons : « cette sévérité a été inférée par SafetyClassifier_V3.0 à partir des cas [001,045] avec confiance 0,78, valide pour le domaine ambulatoire, expirant à T+90 jours ».
Le typage épistémique est une discipline architecturale (pas nécessairement un système de type formel de langage de programmation) gouvernant quels statuts épistémiques sont permis, quelles transformations sont autorisées entre statuts, quelles opérations exigent des portes de politique explicites, quand les assertions expirent ou perdent leur validité.
Les types épistémiques sont multidimensionnels : Origin × Method × TemporalStatus. Origine : capteur, humain, modèle, politique, source externe. Méthode : observé, dérivé, inféré. TemporalStatus : courant, prédit, historique.
Cela évite de forcer de faux choix entre INFÉRÉ et PRÉDIT—ce sont des axes indépendants.
Le typage épistémique active les règles formelles de transformation :
(Modèle, Inféré, Courant) + [validation_par : Humain] → (Humain, Observé, Courant) (Modèle, Inféré, Prédit) + [porte_politique : X] → (Politique, Dérivé, Prédit) Expiré(assertion) → InvalidPourDécision(assertion)
Critiquement : PAS de transformation implicite.
(Modèle, Inféré, Courant) -/→ (Humain, Observé, Courant) [SANS validation]
Cette règle prévient le blanchiment épistémique—l’effondrement non autorisé des types épistémiques. C’est précisément ce que les systèmes aval font : un SafetyModel produit « Risque=ÉLEVÉ, confiance=0,65, statut_épistémique=INFÉRÉ ». Au moment où cela atteint la décision, seul « Risque=ÉLEVÉ » subsiste. Le système croit que c’est une observation. La gouvernance d’assertion applique une vérification de type aux limites de contrat, prévenant la perte épistémique en cascade.
Le statut épistémique répond « comment le savons-nous ? » L’autorité répond « à quoi cette information est-elle autorisée à causer ? » Celles-ci sont indépendantes :
(Modèle, Inféré, Courant) + autorité : consultatif → peut informer les recommandations (Modèle, Inféré, Courant) + autorité : exécutable → peut déclencher les actions (risque plus élevé)
Le risque est multifactoriel : Risque(assertion) = RisqueÉpistémique × RisqueAutorité × RisqueIrréversibilité.
Une assertion épistémique avec autorité zéro ne pose aucun risque opérationnel, indépendamment de l’incertitude. La même assertion avec autorité exécutable devient systémique.
La reproductibilité n’est pas binaire. C’est une échelle graduée :
Idempotence d’effet : Une livraison dupliquée crée-t-elle des effets involontaires dupliqués ? Problème classique. Bon marché. Généralement requise.
Stabilité d’assertion : Avec le même contexte gelé (même version du modèle, même preuve, même état de politique), la catégorie d’assertion reste-t-elle stable ? L’amplitude peut se décaler (confiance 0,78 à 0,82), la classification (ÉLEVÉ vs BAS) reste. Coût modéré. Requise pour les décisions à risque moyen.
Reproductibilité d’exécution : Pouvez-vous obtenir exactement la même assertion en rejouant tous les (E, S, C, M, R, T) ? Dépend de la variance incontrôlée. Chère ou impossible. Requise seulement pour les décisions à haut risque ou réglementées.
Le principe architectural : achetez le niveau de reproductibilité justifié par la conséquence. L’exactitude chère n’est pas requise partout.
L’architecture événementielle apporte des avantages (asynchronie, résilience) et des coûts (incertitude d’ordre, cohérence éventuelle).
Les systèmes probabilistes ajoutent une dimension : Ω_système = Ω_distribué × Ω_épistémique
Le produit cartésien est multiplicativement plus grand. La décision résultante ne peut pas être dérivée des seuls événements ; elle dépend de l’ordre d’événements réalisé et de l’état épistémique à l’exécution.
La solution : enveloppe d’assertion plus snapshots d’état versionnés à chaque agent. Cela permet la reconstruction de causalité temporelle—vous pouvez avancer dans la séquence et comprendre pourquoi chaque agent a produit son assertion.
Plan de gouvernance (architecture d’autorité) : Capacité → Droits de décision → Autorité. Statique ou se change lentement.
Plan d’exécution (séquence runtime) : Événement → Exécution → Assertion → Décision → Effet. Ce qui advient à l’exécution.
Ce sont des structures orthogonales précédemment confondues. La gouvernance répond « qui décide ? » L’exécution répond « qu’arrive-t-il ? »
Les assertions habitent les deux : dans le plan de gouvernance (« ce type d’assertion est assigné à ce niveau d’autorité ») et dans le plan d’exécution (« ce calcul a produit une assertion avec ce statut épistémique »).
Cette séparation résout l’ambiguïté architecturale.
Les contrats épistémiques portent quatre dimensions : valeur_assertion + type_épistémique(origine, méthode, temporalité) + frontière_autorité + conditions_validité(domaine, expiration, réversibilité).
Cela transforme les systèmes distribués de « services échangeant des données » à « services échangeant des assertions avec provenance traçable et autorité bornée ».
Cela s’applique bien au-delà des agents : ML classique (sorties avec incertitude), jumeaux numériques (simulations avec statut prédit), moteurs de recommandation (scores avec statut inféré), systèmes autonomes (actions avec niveaux d’autorité), systèmes hybrides humain-IA (mélange d’assertions humaines avec inférences machine).
Le motif commun : le calcul probabiliste produit des assertions. Les assertions doivent porter leur statut épistémique et leurs frontières d’autorité. Les contrats doivent rendre cela explicite.
Les systèmes distribués avec composants probabilistes font face à une exigence architecturale nouvelle : le typage épistémique—assurer que chaque assertion porte ses conditions de crédibilité et ses frontières d’autorité.
Les principes centraux :
Où les assertions ne s’effondrent jamais implicitement en faits, et l’autorité n’est jamais supposée à partir de la seule capacité technique.
C’est ce que la gouvernance des agents probabilistes exige.
Notes doctrinales et explorations sur l’IA en systèmes régulés. Une à deux fois par mois. Désabonnement en un clic.