Authentification et secrets ERP

L'intégration ERP repose sur des échanges machine à machine entre Epayment et le serveur REST de la régie. Les credentials ne transitent jamais par le navigateur citoyen ni par le portail ministry.

Stockage des secrets

Propriété	Valeur
Stockage	Chiffrement au repos, hors base relationnelle
Exposition GET config	Indicateur « credentials présents » sans valeur
Révélation	Action dédiée super-admin / officer autorisé, une fois par rotation

L'adaptateur sandbox (fake) ne requiert aucun credential.

Modes d'authentification REST

Configurés dans les credentials chiffrés (auth_mode) :

Mode	Champs credentials	Comportement HTTP
none	Aucun	Pas d'en-tête d'authentification
api_key_header	api_key, header_name (défaut X-Api-Key)	Clé envoyée dans l'en-tête nommé
bearer	bearer_token	Authorization: Bearer {token}
basic	username, password	Authorization: Basic {base64}
custom_headers	custom_headers (map)	En-têtes arbitraires ajoutés à chaque requête

En-têtes non secrets

Le bloc mapping.additional_headers permet d'ajouter jusqu'à dix paires clé/valeur (clé 1-64 caractères, valeur max 200 caractères). Usage typique : identifiant tenant côté ERP, version d'API, correlation id statique.

Ces en-têtes sont stockés en clair dans la configuration tenant et apparaissent dans le journal communications (valeurs non masquées sauf si la clé ressemble à un secret).

Rotation

1. Générer de nouveaux secrets côté ERP.
2. Mettre à jour les credentials dans Intégration ERP → Connexion.
3. Enregistrer : l'horodatage de dernière rotation est mis à jour.
4. Lancer Tester la connexion pour valider immédiatement.
5. Révoquer l'ancien secret côté ERP après validation.

Epayment n'effectue pas de double écriture : la bascule est instantanée à l'enregistrement.

Séparation des secrets ministry et ERP

Secret	Portée	Usage
sk_ application / plateforme	Ministry, eGouv	POST /checkout/sessions, verify-completion, webhooks entrants
Credentials ERP	Régie uniquement	GET dues, GET disbursements, POST confirmations vers l'ERP

Ne jamais réutiliser une clé ministry pour authentifier l'ERP, ni exposer les credentials ERP au front citoyen.

Journal et audit

Chaque requête HTTP sortante vers l'ERP est enregistrée dans le journal des communications :

• Direction sortante (Epayment → ERP)
• Système erp:rest (ou erp:fake pour le sandbox journalisé)
• Corps requête/réponse avec secrets redactés
• Code HTTP et latence

En cas d'échec d'authentification (401, 403), consulter le journal avant de modifier la configuration.

Bonnes pratiques

• Restreindre l'accès réseau ERP aux plages IP Epayment en production.
• Préférer bearer ou api_key_header à basic sur TLS 1.2+.
• Limiter la durée de vie des tokens côté ERP ; prévoir une procédure de rotation documentée.
• Ne pas logger les credentials dans les applications métier amont.