Toutes les fonctionnalités du connecteur, documentées service par service.

Pour chaque contrôle du référentiel sélectionné (ex: A.5.1 sur ISO 27001:2022), on crée ou met à jour une Evidence côté CISO Assistant avec :

• Nom stable : Humanix · <control_ref> · <control_name>
• Description Markdown en 2 blocs : « Métadonnées audit » (ISO 27001 §7.5 : référentiel, contrôle, responsable, période, version Humanix, ré-évaluation) puis « Données Humanix » (score, statut, source).
• Statut mappé sur l'enum CISO Assistant : compliant→approved, partial→in_review, non_compliant→rejected, not_assessed→draft.
• Lien direct vers la page Humanix qui prouve la mesure (chiffres en clair, drill-down par groupe).
• Date d'expiration à +12 mois (réaudit annuel par défaut).

Crée un AppliedControl « Programme de sensibilisation Humanix Académie · <framework> » avec sémantique NIST CSF 2.0 :

• category: process
• csf_function: protect (sensibilisation = protection comportementale)
• priority: 3, effort: L (programme continu)
• eta: +12 mois — date du prochain audit

À la fin du sync, on lie M2M les 7 evidences à cet AppliedControl (champ evidences). Le RSSI a un point de bascule unique dans l'arbre GRC.

Pour chaque contrôle en partial ou non_compliant, on crée un Finding sous un FindingsAssessment dédié « Audit sensibilisation Humanix Académie · <framework> » (catégorie self_identified) :

• Priorité : P1 si non_compliant, P2 si partial
• Statut : confirmed (non_compliant) ou identified (partial)
• ETA & due_date : +12 mois
• Lien vers l'AppliedControl agrégateur (M2M)
• Owner : User CISO Assistant correspondant à l'ownerEmail du tenant (si toggle owner actif)

Triggers déclenchés à l'analyse du bundle :

• > 30% des contrôles non_compliant
• ≥2 contrôles partial
• Déclenchement précoce : 2+ contrôles affaiblis (partial OU non_compliant)

On crée un RiskAssessment Humanix puis un RiskScenario avec treatment=mitigate, current_proba=2, current_impact=2 (compatible matrices 3×3 et 5×5). Nécessite qu'une RiskMatrix soit chargée côté CISO Assistant.

Pas une déclaration formelle d'incident — c'est un constat d'écart automatique pour la traçabilité audit ISO 27001 §10.1 / NIS2 §21.2.g :

• status: new, severity: 3 (Moderate), detection: internally_detected
• reported_at + occurred_at = now (ISO datetime)
• ref_id : humanix-<framework>-YYYY-MM-DD (idempotent par jour)
• owners : User CISO Assistant si syncOwnerAsActor actif

Pour chaque sync, on push 6 séries temporelles via le module Metrology natif de CISO Assistant :

• humanix.tenant_score — score maturité 0-100 (Score)
• humanix.completion_rate — taux complétion 0-100% (Percentage (%))
• humanix.phishing_report_rate — taux signalement phishing 0-100% (Percentage (%))
• humanix.evidences_compliant_count — N contrôles conformes (Count)
• humanix.evidences_non_compliant_count — N non conformes (Count)
• humanix.evidences_partial_count — N partiels (Count)

Chaque MetricDefinition est créée avec son unité résolue dynamiquement (lookup /api/terminologies/?field_path=metric_definition.unit), son provider Humanix Académie, et les 3 filtering_labels standards (humanix, sensibilisation, <framework>).

Un Dashboard « Cockpit Humanix Académie · <framework> » avec 6 widgets pointant sur les MetricInstances :

• Gauge — Score maturité cyber humaine
• KPI card — Taux de complétion sensibilisation
• KPI card — Taux signalement phishing
• Line chart 90 jours — Évolution score
• Sparkline — Tendance contrôles non conformes
• Sparkline — Tendance contrôles conformes

Layout 12-col propre. Nécessite pushMetrologySamples actif (sinon les widgets n'ont pas de cible).

Si l'ownerEmail du tenant est renseigné, on appelle resolveOwnerUser(email) qui :

1. Cherche l'utilisateur par email côté CISO Assistant
2. Le crée s'il n'existe pas (POST /api/users/ { email, is_active: true, is_third_party: false })
3. Retourne le User UUID (pas Actor UUID — le schéma OpenAPI confirme que les champs owner attendent des User refs)

Le User est ensuite injecté dans le champ owner (singulier) sur les evidences, applied controls, findings, risk scenarios, metric instances et asset workforce, et dans owners (pluriel) sur les incidents.

Pour chaque Group Humanix actif (isActive: true), on crée une Team CISO Assistant nommée Humanix · <Group.name> dans le folder. Idempotent par nom.

Description auto-générée : « Équipe Compta (12 membres) synchronisée automatiquement depuis Humanix Académie. »

Les membres ne sont pas pushés automatiquement — c'est le RSSI qui assigne nominativement (besoin d'un User CISO Assistant par membre, hors scope du connecteur).

Un Asset GRC nommé explicitement pour scoper les RiskScenarios / Findings / Incidents sur la couche humaine. Auparavant, les risques flottaient sans cible : maintenant on peut lier RiskScenario.assets: [workforce.id].

Champs envoyés :

• name : Personnel · Couche humaine Humanix Académie
• type : PR (Primary, AssetWriteTypeEnum)
• ref_id : humanix.workforce
• is_business_function : true
• owner + filtering_labels selon toggles actifs

15 Threats créés dans le folder, idempotent par ref_id :

• HUMAN-T1 — Spear phishing finance
• HUMAN-T2 — Fraude au président (FOVI)
• HUMAN-T3 — Vishing CFO
• HUMAN-T4 — Smishing
• HUMAN-T5 — Quishing
• HUMAN-T6 — Deepfake CEO audio/vidéo
• HUMAN-T10 — Réutilisation MdP
• HUMAN-T11 — Identifiants visibles
• HUMAN-T12 — Shadow IT
• HUMAN-T13 — Perte / vol device
• HUMAN-T14 — Tailgating
• HUMAN-T20 — Incident non signalé
• HUMAN-T21 — Fuite RGPD négligence
• HUMAN-T30 — Fuite secrets dev
• HUMAN-T31 — Offboarding RH bâclé

Chaque Threat est créé avec provider=Humanix Académie, description détaillée (contexte, chiffres terrain, vecteurs), et filtering_labels. Le RSSI peut ensuite les linker à ses RiskScenarios via le M2M threats.

Données dérivées du catalog public CC BY-SA 4.0.

Architecture event-driven fire-and-forget :

• Hook dans /api/progress → episode.completed
• Hook dans /api/phishing/report → phishing.reported
• Hook dans /phishing/[token] → phishing.user_clicked

Debouncer in-memory par tenantId : 50 utilisateurs qui terminent un module en 30 secondes = 1 seule sync vers CISO Assistant (pas 50).

Re-upsert des evidences uniquement (pas de PDF, pas d'extensions — trop coûteux temps réel). Skip si une sync manuelle est déjà en cours. No-op si aucun framework n'a jamais été syncé manuellement (live mode rafraîchit, n'initialise pas).

Télémétrie visible dans la console admin : lastLiveSyncAt, lastLiveSyncEvent, liveSyncCount.

Résolus une fois par sync via ensureFilteringLabel (normalisation regex ^[\w-]{1,36}$), stockés sur client.filteringLabelIds, inclus automatiquement dans toutes les opérations d'écriture.

Le RSSI peut filtrer rapidement « toutes les entités venant d'Humanix » dans la sidebar CISO Assistant, sans risque de confusion avec d'autres connecteurs ou imports manuels.

Le RSSI suit toutes ses campagnes phishing simulé / smishing dans son cockpit GRC habituel, sans replonger dans Humanix. Status mappé :

• scheduledAt > now → draft
• isActive ou scheduledAt ≤ now → in_progress
• sentAt et non actif → done

Comme CampaignWrite.frameworks et CampaignWrite.perimeters sont required côté Django, on crée automatiquement un Perimeter « Humanix Académie · scope par défaut » dans le folder, et on liste tous les Frameworks chargés. Idempotent par nom.

À chaque sync, pour chaque evidence on génère un PDF 2 pages A4 attaché :

• Page 1 : metadata d'audit (contrôle, responsable, période) + données Humanix (chiffres, capture du dashboard).
• Page 2 : manifeste d'intégrité avec signature Ed25519 du payload JSON canonique, empreinte de la clé publique, timestamp UTC, et procédure OpenSSL de vérification hors-ligne.

La clé publique Humanix est exposée sur /.well-known/humanix-pdf-pubkey.pem — un auditeur peut vérifier l'authenticité de n'importe quelle evidence sans contacter Humanix.

5 actions auditées (cf. enum Prisma AuditAction) :

• CISO_CONNECTION_CONFIGURED — sauvegarde des creds
• CISO_CONNECTION_TESTED — bouton « Tester la connexion »
• CISO_CONNECTION_DELETED — suppression des creds
• CISO_SYNC_STARTED — lancement manuel d'une sync
• CISO_LIVE_SYNC — mini-sync v2.0 déclenchée par event

Chaque entrée capture : actor (userId, email, role), tenantId, target (type=ciso_connection, label=baseUrl), outcome (SUCCESS/FAILURE), severity (INFO/WARNING), metadata (folderId, framework, ok/fail counts, durée ms).

Aucun secret en clair en base de données. La clé de chiffrement est dérivée à la volée à partir de AUTH_SECRET via HKDF SHA-256 (HMAC-Key-Derivation-Function, RFC 5869).

Avantages :

• Si la DB est dumpée, le password reste illisible (clé jamais en DB)
• Rotation simple : changer AUTH_SECRET = invalider tous les passwords stockés (à reconfigurer)
• Pas de dépendance KMS externe — on reste hébergeable on-prem