Développeurs NELSE
Intégrez NELSE sans deviner le contrat.
Cette page est destinée aux équipes qui implémentent NELSE API : forme des appels, états métier, versionnement, erreurs, idempotence, observabilité et modes d’intégration. Pour les cas d’usage et la proposition commerciale, commencez par la page NELSE API.
Le contrat
Un appel doit vous dire plus qu’un oui ou non.
Le résultat utile à un système n’est pas seulement une conclusion. Il doit aussi indiquer ce qui s’applique, ce qui manque, les actions attendues, l’intervention humaine requise et la référence permettant d’examiner la décision.
Traçabilité de décision
Une décision réglementaire doit pouvoir être parcourue de la source jusqu’à la preuve.
NELSE ne renvoie pas seulement une conclusion. Le contrat d’intégration conserve les références nécessaires pour examiner comment le résultat a été produit, où l’humain est intervenu et quelle preuve permet de le relire plus tard.
Texte, référentiel ou politique et sa version.
Exigence formalisée retenue dans le corpus exécuté.
Valeur confirmée, manquante ou à revoir dans le contexte.
État, exigence, action, délai ou contrôle produit.
Validation, modification, refus ou arbitrage lorsque requis.
Référence permettant d’examiner la décision dans son contexte historique.
Contrat de reproductibilité
Dans le périmètre formalisé : même contexte confirmé, même corpus, même version et même configuration produisent la même exécution normative. Une donnée absente reste absente ; elle n’est pas transformée silencieusement en réponse négative.
Démarrage rapide
Voyez la forme d’un appel avant de lire cent pages de documentation.
Les exemples ci-dessous montrent les six primitives publiques. Le contrat versionné précise ensuite les schémas exacts, les erreurs, les limites et les profils d’assurance.
POST /v1/qualify{
"context": {
"jurisdiction": "FR",
"domain": "medtech",
"effective_at": "2026-09-24"
},
"facts": {
"intended_use": "clinical_decision_support",
"personal_data": true
}
}{
"status": "human_review_required",
"applicable_requirements": [
"…"
],
"missing_facts": [],
"actions": [
"…"
],
"human_review": {
"required": true
},
"evidence": {
"replayable": true
}
}Exemple simplifié destiné à montrer la forme d’intégration. La référence API versionnée fixe les champs, erreurs et contrats exacts du périmètre utilisé.
Contrats d’intégration
Prévisible pour le développeur. Explicite pour l’auditeur.
Le droit peut changer sans obliger vos applications à réinventer leur architecture. Les versions normatives évoluent ; le contrat d’intégration reste gouverné.
Jetons de service, identité utilisateur et droits restent séparés. Les appels sont refusés si le contexte d’accès n’est pas suffisant.
Les opérations critiques peuvent être rejouées côté transport sans créer silencieusement une seconde décision.
L’appel conserve la version du corpus et le contexte d’exécution nécessaires à l’explication et au rejeu.
READY, REVIEW_REQUIRED, MISSING_FACTS ou BLOCKED sont des états métier visibles — pas des erreurs transformées en succès.
Validation, autorisation, version, données manquantes et indisponibilité sont distinguées pour que votre produit sache quoi faire.
Identifiants de requête, version, décision, événements et références de preuve permettent de suivre le parcours sans ouvrir le moteur.
Modèles d’intégration
Du parcours synchrone à l’agent, sans changer de socle.
Un même corpus et une même logique de preuve peuvent être consommés par plusieurs architectures. Le mode de transport change, pas la responsabilité sur le résultat.
Synchrone
Une application appelle NELSE pendant un parcours et récupère les exigences, actions et validations à traiter.
Événementiel
Un changement de fait, d’état ou de règle déclenche un événement consommable par vos processus.
Traitement par lots
Un portefeuille de dossiers est réévalué avec une version déclarée et des résultats corrélables.
Agents & MCP
Un agent peut demander à NELSE ce qui est applicable ou nécessaire sans transformer le modèle de langage en moteur de décision normative.
Versionner sans casser
Votre code appelle une capacité. NELSE porte l’évolution réglementaire.
Une application ne devrait pas contenir en dur chaque évolution d’un texte. Elle doit pouvoir appeler une capacité stable et savoir précisément quelle version normative a produit le résultat.
Votre produit envoie le contexte et les faits nécessaires.
Cas de référence, erreurs et scénarios de validation sont exécutés avant promotion.
La nouvelle version peut être observée sans remplacer silencieusement celle en service.
La version retenue devient explicite, réversible et rattachée aux décisions qu’elle produit.
Le point important pour vos équipes
Une mise à jour du droit ne doit pas devenir un projet de refonte applicative. NELSE sépare le contrat technique consommé par votre logiciel du corpus versionné qui porte les exigences.