OXANN← Portfolio

CAS 04 · SYNDIC SANTÉ

Le métier doit écrire les règles avant l’écran.

Prototype métier

Un lieu de santé cumule des usages, des véhicules juridiques, des charges et des échéances qui ne se laissent pas réduire à une copropriété générique.

LE POINT DE DÉPART

Une spécialité métier ne se résume pas à changer les libellés.

Le prototype part d’un constat de modélisation : un lieu de santé peut combiner copropriété, SCI, SCM, SISA ou autres structures, des équipements mutualisés et des obligations à suivre. Le besoin est d’abord de représenter correctement ces règles.

CE QU’ON A OBSERVÉ

Une fausse conformité est plus dangereuse qu’une alerte incomplète.

ChargesRépartition multi-véhicule et clés d’usage pour les pots mutualisés.
RegistreÉchéances réglementaires sourcées ou explicitement marquées à confirmer.
GateUn artefact reste brouillon/non opposable tant que la validation humaine requise n’existe pas.

LA VRAIE QUESTION

Comment automatiser sans fabriquer une conformité ?

Le prototype traite l’automatisation comme un calcul et une préparation de dossier, pas comme une signature. Dès qu’une donnée réglementaire manque ou qu’une échéance n’est pas satisfaite, la logique doit pouvoir refuser un état « conforme ».

HYPOTHÈSE DE TRAVAIL

Un moteur spécialisé doit d’abord savoir refuser.

Le refus par défaut est ici une règle de conception : mieux vaut produire une alerte ou un brouillon que convertir une donnée manquante en assurance implicite.

LE RAISONNEMENT

Trois niveaux restent séparés.

  1. 01
    Calculer.

    Les règles de répartition et d’échéance doivent rester déterministes et testables.

  2. 02
    Conseiller.

    Le moteur peut produire des recommandations et signaler ce qui manque.

  3. 03
    Rendre opposable.

    Cette étape reste gatée par une validation humaine experte ; l’orchestrateur ne signe pas.

CE QU’ON A CONSTRUIT

Une composition de briques métier, pas un monolithe.

Le prototype assemble une logique de charges santé, un moteur d’échéances, un registre santé et un document final soumis à une validation d’expertise. Les dates sont injectées pour garder le comportement déterministe et testable.

CE QU’ON PEUT PROUVER

Les invariants sont dans le code et les tests.

Répartition
Le moteur détecte une répartition non exhaustive au lieu de masquer un montant non alloué.
refus par défaut
Une obligation manquante/en retard ou un registre vide ne devient pas « conforme » par défaut.
Déterminisme
Les dates sont injectées et les calculs évitent les valeurs non finies.
Validation humaine
Le document reste brouillon/non opposable avant validation humaine requise.

CE QU’ON NE PRÉTEND PAS

Un prototype métier n’est pas un avis réglementaire.

  • Pas de caution externe par un expert santé ou une organisation de santé.
  • Pas de garantie de conformité juridique ou réglementaire.
  • Les périodicités encore marquées à confirmer ne sont pas présentées comme acquises.
  • Pas de production ni d’opposabilité autonome.

CE QU’ON A APPRIS

La spécialisation utile commence par les invariants.

Avant de dessiner un tableau de bord vertical, il faut savoir ce que le système a le droit de conclure, ce qu’il doit calculer et dans quels cas il doit s’arrêter.

LE PROBLÈME QU’ON RETROUVE AILLEURS

Automatiser un calcul n’autorise pas à décider à la place de l’humain.

Un moteur peut calculer et alerter. Rendre un résultat opposable reste un acte humain, gardé par une règle explicite. Le cas OXANN Risk Management pose la même exigence en amont : avant de calculer quoi que ce soit, savoir qui doit décider, et quand.

OÙ EN EST LE PROJET

Prototype métier.

Les moteurs existent de façon synthétique et déterministe. Les vraies clés de charges, certaines périodicités, l’expertise et toute publication restent soumises à validation.