UDENTIVA grave dans l'architecture elle-même la maturité de processus recherchée pour le logiciel de santé. Cette page expose, avec preuves à l'appui, notre cycle de vie de développement, nos niveaux de capacité SPICE / ISO-IEC 15504, nos mécanismes de journalisation continue des erreurs et de contrôle, nos critères de version et de sécurité, ainsi que notre historique de développement.
Fondement : Règlement relatif aux systèmes de gestion de l'information de santé (MevzuatNo 39682), art. 6 et art. 20 — exigence de certification de la qualité logicielle (CMMI/SPICE).
La définition des processus, leur mise en œuvre et les produits de travail traçables sont structurés ; les mécanismes de mesure quantitative, de prévention des défauts et d'amélioration continue sont exploités en production. La déclaration officielle du niveau de capacité est soumise à une évaluation indépendante (appraisal).
SPICE évalue les processus selon un niveau de capacité allant de 0 à 5. UDENTIVA est structurée pour répondre aux attentes des niveaux 1 à 3 au regard de la définition des processus, de leur mise en œuvre et des produits de travail traçables ; pour les niveaux 4-5, des mécanismes de mesure quantitative et d'amélioration continue sont en fonctionnement. La déclaration officielle de niveau est soumise à une évaluation indépendante.
Les mécanismes de contrôle quantitatif et d'amélioration continue relevant des niveaux 4-5 sont mis en œuvre ci-dessous avec leurs preuves (mesure en direct, registre des défauts/CAPA, journaux de déploiement).
Chaque domaine de processus correspond à une mise en œuvre concrète dans UDENTIVA et à une preuve auditable. Le processus n'est pas un document, c'est du code en fonctionnement.
| Domaine de processus | Application UDENTIVA | Preuve |
|---|---|---|
| ENG.1 Élicitation des exigences | Feuille de route des phases + définition des exigences par tranche verticale (vertical slice) ; le contrat de projet UDENTIVA.md verrouille les exigences. | UDENTIVA.md (RÈGLES D'OR), spécification technique 02_tech_spec/, feuille de route phases/modules |
| ENG.4 Conception logicielle | Monolithe modulaire ; les paquets de contexte (context) ne partagent pas leurs tables ; communication par interface ; service externe = adapter. | règle de frontière internal/{identity,patient,billing,export,...} ; ADR-001..008 |
| ENG.5 Construction logicielle | SQL explicite (sqlc, sans ORM) ; le context est le premier paramètre de chaque fonction ; encapsulation des erreurs %w ; argent = numeric. | override de type sqlc.yaml (numeric→string), db/queries/*.sql, gofmt/golangci-lint |
| ENG.6 Intégration logicielle | Chaîne loopback PHP (BFF) ↔ Go ↔ PostgreSQL ↔ Redis ; unique surface publique. | web/core/ApiClient, /healthz santé des composants (db+redis) |
| ENG.7 Tests logiciels | Test d'isolation cross-tenant (le plus critique), idempotence, conflits de rendez-vous, précision monétaire, 2FA/OTP, vecteur TOTP RFC6238, QR (vérification OpenCV+ISO). | internal/integration/*_test.go, platform/totp/totp_test.go, go test ./... |
| SUP.1 Assurance qualité | Chaque PR doit respecter les RÈGLES D'OR ; lint propre ; si le test d'isolation est rouge en CI, pas de merge. | golangci-lint, Definition of Done kontrol listesi |
| SUP.8 Gestion de la configuration | Contrôle de version Git (branche core) ; versionnement de schéma séquentiel goose ; les artefacts de build sont sauvegardés. | git, goose_db_version tablosu, .tools/deploy yedekleri |
| SUP.9 Résolution de problèmes | Journal d'audit en ajout seul (append-only) + outbox e-mail/SMS (enregistrement de chaque envoi) + discipline de sauvegarde/rollback de déploiement. | audit_log, email_outbox/sms_outbox, bin/server.exe.bak-* rollback |
| SUP.10 Gestion des demandes de changement | Chaque changement de schéma est une nouvelle migration numérotée ; réversible (goose Down) ; approbation du classifier de déploiement. | db/migrations/0001..0027, +goose Up/Down |
| MAN.3 Gestion de projet | Livraison par tranche verticale (chaque tranche fonctionne de bout en bout) ; notes de passation de session. | super-devam.md, faz tablosu (DoD per dilim) |
| MAN.6 Mesure | Contrôle de santé, mesure de capacité, métriques d'envoi e-mail/SMS, volume d'audit, télémétrie d'événements en direct. | /healthz, tableau de bord Supervision des processus & Qualité (événement/erreur/déploiement/KPI) |
Les responsabilités sont réparties en couches ; l'autorité du domaine est centralisée en un point unique et isolée par loopback. Le navigateur ne voit que la fine BFF et n'accède jamais directement à la couche domaine ni à la couche de données.
| Couche | Responsabilité & Sécurité | Localisation |
|---|---|---|
| Sunum (BFF) | PHP 8.4 — BFF léger : session, rendu, CSRF, routage. Aucune règle métier / DB. Unique surface publique (IIS:443). | web/ |
| Uygulama / Domain | Monolithe modulaire Go — l'UNIQUE autorité du domaine. RBAC, règles métier, transactions. Écoute uniquement 127.0.0.1. | api/internal/ |
| Veri | PostgreSQL — chaque table possède tenant_id + RLS FORCE ; SQL explicite (sqlc), paramétré. Argent en numeric. | api/db/ |
| Cache / File d'attente | Redis — session, idempotence, verrou distribué, file asynq (SMS/e-Fatura). | platform/redisx |
| Nesne Depolama | Compatible S3 — gros fichiers (radiographies) en presigned/stream ; le blob n'est jamais dans la DB. | platform/storage |
| Service externe (adapter) | e-Fatura, SMS (NetGSM), e-mail (SMTP), (à terme e-Nabız/MEDULA/DICOM) — abstraits derrière une interface. | internal/notify |
La mesure n'est pas une déclaration, c'est un système en fonctionnement. Toutes les opérations sont comptées en direct (succès/échec), les erreurs de production sont capturées dans un registre permanent et le cadre de KPI ci-dessous est relié à des actions périodiques. Les sources de données sont des tables réelles : event_counter (compteur d'opérations en direct), error_log (registre permanent des erreurs), deploy_log (registre des déploiements).
| Domaine de mesure | KPI | Objectif | Source de données | Période | Action |
|---|---|---|---|---|---|
| Sécurité de l'isolation des tenants | cross-tenant test fail | 0 | CI / izolasyon testi | her PR | Blocage de merge |
| Erreur de production | erreur explicite (5xx/panic) | 0 | error_log (persistant) | continu / en direct | RCA + CAPA zorunlu |
| Taux de réussite des opérations | success / toplam event | ≥ 99 % | event_counter (en direct) | continu / en direct | Cause racine en cas de baisse |
| Délai de résolution | MTTR (résolution moy.) | ↓ tendance décroissante | error_log (resolved) | mensuel | Trend incelemesi |
| Fiabilité du déploiement | taux de rollback | < %5 | deploy_log | 30 jours | Rollback review |
| Sécurité de l'identité | 2FA/OTP kritik olay | 0 | audit + event_counter | mensuel | Durcissement |
| Fiabilité de la messagerie | SMS/e-posta failure | ↓ faible | *_outbox | journalier | review fournisseur |
| Préparation de la restauration | réussite du test de restauration | %100 | DR test (hedef) | trimestriel | Mettre à jour le runbook |
Chaque erreur de production passe par un cycle standard d'analyse des causes racines (RCA) et d'actions correctives/préventives (CAPA) ; la récurrence de la même erreur est évitée par un contrôle de non-régression et un suivi des tendances.
Les erreurs de production (5xx/panic) sont capturées automatiquement → error_log persistant (count++ à chaque répétition de la même signature, tendance des défauts).
Le niveau (error/panic), l'impact et le nombre de répétitions sont déterminés ; la prévalence est mesurée par les compteurs d'événements en échec.
L'analyse de cause racine est réalisée et enregistrée dans le tableau de bord de Supervision des processus.
Une action corrective + une action préventive (code, test, règle de migration, contrôle de sécurité) sont définies et enregistrées.
Un test/une règle empêchant la récurrence de la même erreur est ajouté ; suivi par télémétrie continue.
Les tendances des KPI (MTTR, taux d'erreur, rollback) sont évaluées périodiquement ; pour les erreurs récurrentes, une action au niveau du processus est ouverte.
L'essence de SPICE niveau 5 : journalisation continue des erreurs, maintien sous contrôle, prévention des défauts et amélioration continue. UDENTIVA met ces mécanismes en œuvre en production.
Le journal audit_log immuable (append-only) enregistre de manière persistante chaque opération critique ; email_outbox/sms_outbox enregistrent chaque envoi (status, attempts, error). Aucun événement ne se perd silencieusement.
Enveloppe d'erreur cohérente {error:{code,message}} ; l'erreur interne / la stack n'est jamais divulguée. Avant chaque déploiement, sauvegarde du binary + web ; en cas d'incident, rollback en quelques secondes via bin/server.exe.bak-*.
Architecture fail-closed : 0 ligne si le contexte RLS est absent ; l'idempotence empêche le double traitement ; l'argent en numeric rend impossible l'erreur de float ; la whitelist (export dataset) prévient l'injection SQL. Les erreurs sont empêchées dès la conception.
Les composants critiques sont vérifiés par deux méthodes indépendantes : vecteur de test TOTP RFC6238, décodage OpenCV cv2 + codeword de référence ISO/IEC 18004 pour le QR, test d'isolation cross-tenant.
À chaque session : audit de sécurité → constats → durcissement (ex. RBAC phase2/phase3 ajouté, 2FA, Export API). La mémoire institutionnelle est préservée par les notes de processus (super-devam.md).
Une nouvelle exigence réglementaire (Vue VEM) est directement transformée en fonctionnalité produit et en preuve ; les évolutions réglementaires sont surveillées en continu et reportées sur la carte de conformité.
Un seul socle de code, restriction par indicateur — pas de fork.
Version traçable au niveau du schéma, de la source, du déploiement et de l'API.
Tout le processus de développement est sous contrôle de version ; chaque déploiement est réversible (rewind/rollback).
La sécurité n'est pas une fonctionnalité, c'est l'architecture elle-même. Des règles non négociables dont la violation entraîne le rejet de la PR :
Le système, construit par tranches verticales fonctionnant chacune de bout en bout. Ci-dessous figurent les phases et la chronologie des travaux récents de sécurité/réglementation.
pgx+sqlc, goose, test RLS fail-closed, WithTenantTx, middleware de session, login+RBAC, audit, loopback PHP↔Go, base asynq, health.
CRUD Patient + test d'isolation cross-tenant → Rendez-vous (exclusion constraint + verrou Redis) → Odontogramme/Plan de traitement (FDI, append-only) → Encaissement/Compte courant/Caisse (dérivé, idempotent) → adapter e-Fatura (fast-follow) → Stock → Radiographie (S3) → Rappel SMS (asynq backoff).
Tier opérateur-plateforme (super-admin) (X-Platform-Key, plan d'identité distinct) ; gestion des tenants, modèle d'abonnement/facturation, mesure de capacité, éditeur de version légale, reCAPTCHA, paramètres NetGSM.
i18n (20 dil, key-based, RTL); 20 tema + klinik public site (/s/{slug}) + lead-booking; demo klinik siteleri.
Primitive OTP partagée ; réinitialisation de mot de passe + magic-link + activation de compte (SMTP réel) ; cœur SMS NetGSM ; auth publique multi-tenant ; gestion des utilisateurs de la clinique.
TOTP (RFC6238) + codes de secours ; QR OBLIGATOIRE (indépendant de tout externe, qr.js sans CSP ; vérifié indépendamment avec OpenCV+ISO) ; vérification du téléphone par SMS (consentement KVKK).
Vue VEM (Modèle de données minimum) 12 export views + Export API (défini par SuperUser, verrouillé par tenant, fail-closed) ; carte Réglementation & Conformité ; révision des contrats légaux 100 % conforme à la réglementation.
Centre de support avec suivi de tickets ; documentation de processus SPICE (cette page) ; audit de sécurité continu + durcissement.
Pour des informations détaillées sur l'architecture, la sécurité et la conformité réglementaire, contactez notre équipe.
We use cookies necessary for core functionality; analytics and marketing cookies are enabled only with your consent. Politique de cookies