Catalogue des modules d'intégration

URL : /services • Menu : Suivi des activités ▸ Services • Permission requise : service_read (+ service_update pour basculer le statut Activé)

Catalogue des modules d'intégration publiés par la plateforme. Un module = un flux métier standardisé qu'une organisation peut activer.

Le compteur en haut affiche le nombre de modules trouvés (ex. « 3 éléments trouvés »). Une barre Rechercher un élément ici permet le filtrage rapide par code module ou nom. À droite, les icônes habituelles sélecteur de colonnes + rafraîchir.

Colonnes

Colonne	Signification
Code module	Identifiant technique (mi-consultation-droits, mi-adjudication, mi-transmission…). Affiché en badge cliquable.
Nom	Libellé fonctionnel (Module Adjudication, Module Consultation des Droits, Module Transmission de Données…).
Statut	Actif (🟢), Maintenance (🟠), Déprécié (⚪).
Version	Version contractuelle de l'API exposée (ex. 1.0.0).
Date enregistrement	Horodatage de publication du module sur la plateforme.
Webhooks	Badge « N types » : nombre d'événements webhook déclarés par le module — vert si le catalogue est synchronisé avec la passerelle, rouge sinon ; - si le module n'en déclare aucun. Voir la section dédiée.
Activé	Bascule on/off — voir l'encadré ci-dessous.
Actions	📄 Voir le contrat API — ouvre le volet Contrat API (cf. plus bas).

Bascule Activé — passage en maintenance

La bascule Activé dans la dernière colonne pilote le statut du module au niveau plateforme. Cliquer sur le toggle (qui porte le tooltip « Mettre le module en maintenance ») bascule le statut vers Maintenance : les services qui consomment ce module sont coupés le temps de la bascule, les flux entrants reçoivent une erreur de service indisponible.

C'est une action sensible (impact transversal). Réservée aux administrateurs plateforme avec la permission service_update. Prévenez les organisations concernées avant de basculer.

Statuts

Libellé UI	Code interne	Signification
Actif 🟢	ACTIVE	Module en production, disponible pour activation sur de nouvelles organisations.
Maintenance 🟠	MAINTENANCE	En maintenance temporaire — les flux dépendants sont coupés. À utiliser pour les opérations de mise à niveau planifiées.
Déprécié ⚪	DEPRECATED	Déprécié — ne doit plus être activé sur de nouvelles organisations. Les services existants continuent de fonctionner.

Modules couramment déployés

Code	Description
mi-consultation-droits	Vérification en temps réel des droits d'un assuré (ayants droit, plan, taux de couverture). ResourceCode : rights.
mi-adjudication	Décision de prise en charge d'actes de soin, acte par acte. Expose deux endpoints : /claims (resourceCode claim) pour la décision, /invoices (resourceCode invoice) pour la facturation de clôture.
mi-transmission	Envoi en lot (batch) de données inter-organisations — principalement la base d'adhérents (POPULATION). Asynchrone, via REST + URL pré-signée S3 ou SFTP, au format NDJSON ou CSV. Pattern fan-out : 1 émetteur → N destinations.

Contrat d'un module

Chaque module publie un contrat qui décrit :

• connectors[] — connecteurs disponibles : code (REST_SYNC, REST_ASYNC, SFTP_OUTBOUND…), direction (INBOUND = entrant dans la plateforme / OUTBOUND = sortant de la plateforme), protocole (REST / SFTP), types d'authentification supportés, champs requis et optionnels, capacités.
• supportedResourceCodes — codes de ressources acceptés. Dépend du module : rights pour la consultation des droits, claim et invoice pour l'adjudication, POPULATION (ou d'autres codes libres) pour la transmission. * signifie « toutes les ressources ».
• baseUrl — URL de base du module.
• healthEndpoint — endpoint de santé.
• contractHash — empreinte du contrat, change à chaque évolution.

C'est ce contrat qui alimente les listes déroulantes du formulaire d'ajout de service.

Colonne Webhooks et synchronisation du catalogue

Chaque module déclare, à son enregistrement sur la plateforme, le catalogue d'événements webhook qu'il émet (aujourd'hui : 6 événements batch.* déclarés par mi-transmission — voir Webhooks). Ce catalogue est stocké en base (source de vérité) puis miroité vers la passerelle de webhooks ; c'est lui qui alimente le sélecteur de filtres des endpoints.

• Seuls les modules Actif ou Maintenance contribuent leurs événements. Un passage en Inactif / Déprécié archive les types correspondants dans la passerelle ; la réactivation les restaure.
• La colonne Webhooks reflète l'état de synchronisation : badge vert = catalogue synchronisé, rouge = écart détecté.
• Le bouton d'en-tête « Synchroniser les webhooks » force une réconciliation manuelle. Toast de résultat : « Catalogue webhook synchronisé — N event types actifs. », ou un avertissement si un écart subsiste.

La synchronisation est aussi déclenchée automatiquement (enregistrement d'un module, changement de statut, redémarrage du service) — le bouton n'est utile qu'en rattrapage.

Volet de détail — Contrat API

Cliquez sur l'icône 📄 « Voir le contrat API » dans la colonne Actions (ou sur la ligne) pour ouvrir le volet « Contrat API ». Ce volet affiche la spécification OpenAPI 3.0 complète du module — telle que publiée par le micro-service.

L'en-tête affiche : nom du module (ex. AdjudicationServiceAPI v1 OAS 3.0), URL de base et liste des serveurs disponibles :

http://mi-adjudication:8290     — Production (réseau Kubernetes interne)
http://mi-adjudication-dev:8290 — Développement
http://localhost:8290           — Local

Le contenu est organisé par regroupements (tags) :

• Flux Métier — endpoints fonctionnels (ex. POST /claims pour l'adjudication, POST /invoices pour la facturation, POST /rights/check pour la consultation, POST /transmission/dispatch pour l'envoi batch).
• Administration — endpoints d'exploitation : GET /health (santé), métriques, statut des dépendances.

Pour chaque endpoint sont listés : verbe HTTP, chemin, libellé court, description, paramètres, schéma de requête et de réponse, codes d'erreur.

Boutons disponibles :

• Authorize — déclare un credential (clé API ou jeton OAuth2) pour tester depuis l'interface.
• Ouvrir dans un nouvel onglet — bascule vers la spec en mode plein écran (Swagger UI standalone).
• Fermer — ferme le volet.

Pour exposer le contrat aux partenaires

La spec OpenAPI affichée ici est aussi exportable au format JSON / YAML par le bouton Ouvrir dans un nouvel onglet. Elle peut être partagée à un partenaire technique pour générer son client (Java, .NET, Postman…).

Actions accessibles

Le catalogue est alimenté automatiquement par les MI eux-mêmes au démarrage (auto-déclaration). Les seules actions disponibles depuis la console sont :

• Bascule Activé (toggle de la colonne) — passe le module en Maintenance ou le réactive en Actif. Voir l'avertissement plus haut.
• Voir le contrat API (icône 📄) — affiche la spec OpenAPI complète.
• Synchroniser les webhooks (bouton d'en-tête) — réconcilie le catalogue d'événements webhook avec la passerelle. Voir la section dédiée.

Pour activer un module sur une organisation précise, voir :

• Activer un service pour une organisation — parcours dédié.
• Organisations — Fiche ▸ Services — référentiel de l'onglet.

Voir aussi

• Activer un service pour une organisation
• Organisations — Fiche