Statut officiel
OfficinaOS est un démonstrateur technique. Aucun usage avec données patient réelles, ordonnances réelles ou caisse de production n'est autorisé tant que le Compliance & Conflict-of-Interest Gate n'est pas levé par écrit.
01 — Résumé exécutif
Un laboratoire technique pour les officines modernes
OfficinaOS explore une infrastructure logicielle moderne pour la gestion d'officines : inventaire, caisse, achats, prescriptions en simulation, rapports, audit logs, API publique et intégrations. La version actuelle constitue une base de simulation technique et de discussion produit pour valider progressivement les workflows, l'architecture et les principes d'interopérabilité.
02 — Proposition de valeur
Répondre à la fragmentation des outils
Outils fragmentés
ERP modulaire, API-first
Vision unifiée des opérations
Stock peu traçable
Lots, expirations, FEFO, dashboard
Meilleure lecture des risques stock
Intégration difficile
API publique, webhooks, scopes
Base pour connecter des outils tiers
Manque de cadre projet
STATUS, NOTICE, Gate conformité
Réduction du risque de confusion
03 — Vision produit
Quatre piliers non négociables
Infrastructure ouverte
API, webhooks, documentation et modules clairement séparés pour favoriser l'interopérabilité.
Simulation responsable
Pas de données réelles, pas de claims de conformité, pas de pilote sans Gate validé.
Contexte africain francophone
Adaptation aux besoins de terrain : multi-sites, reporting et connecteurs adaptés.
Engineering mature
CI, Docker, tests, metrics, logs structurés, backups, scans sécurité.
04 — Périmètre
Ce qu'est OfficinaOS, et ce qu'il n'est pas
Un projet personnel open source
Un laboratoire technique ERP officinal
Une base de simulation avec données synthétiques
Un outil pour explorer l'harmonisation
Un support de discussion produit et technique
Une solution homologuée ou certifiée
Un produit ARP ou institutionnel
Un outil autorisé pour données patients réelles
Un POS de pharmacie prêt à l'usage réel
Une preuve de conformité juridique
05 — Modules fonctionnels
Six blocs opérationnels
Opérations cœur
Catalogue · Stock lots · FEFO · Mouvements · POS & caisse
Achats & fournisseurs
Bons de commande · Réception partielle · Valorisation · Reporting
Simulation patient
Fiches synthétiques · Ordonnances démo · Consentement simulé
Pilotage & audit
Dashboard · Rapports CSV · Audit logs · Logs structurés
Intégration
API publique · Clés scopées · Webhooks · Journaux d'intégration
Infra technique
Docker · Prometheus · Health checks · Backup/restore · Runbooks
06 — Architecture technique
Monorepo TypeScript, API-first, conteneurisé
API
NestJS + Fastify
RBAC · API publique
Database
PostgreSQL
Prisma · Migrations
Identity
Keycloak
JWKS · Rôles
Infra
Redis · MinIO
Docker · Metrics
Séparation des logs — Logs applicatifs et audit logs strictement séparés
Correlation ID — Rédaction des secrets dans tous les logs
Health checks — Liveness, readiness, dépendances optionnelles
Runtime guard — Production bloquée sans COMPLIANCE_GATE_PASSED=true
07 — Interopérabilité
Poser les bases d'un langage opérationnel commun
API publique
Lecture sécurisée de produits, stock et rapports via scopes contrôlés
Webhooks
Notifications d'événements vers outils externes
Exports CSV
Rapports pour analyses et intégrations tierces
FHIR-like
Cartographie conceptuelle vers des standards santé, sans claim de conformité
08 — Sécurité & gouvernance
Trois axes de contrôle
STATUS.md / NOTICE.md
Compliance Gate
Runtime guard
Pilot-0 docs
RBAC + Keycloak + API keys scopées
Rédaction logs, no secrets
Audit logs séparés
Backups, restore drills, scans
Position écrite ARP ou avis juridique
DPO / registre de traitement
Hébergement & responsabilités pro
Accord pilote & annexe données
09 — Roadmap
Six versions, un cap discipliné
actuel
v0.1
Fondations ERP & gouvernance
Structure, modèles, CI, Docker, garde-fous de simulation.
v0.2
Inventaire & caisse
Catalogue, stock, lots, expirations, sessions caisse, POS, dashboard.
v0.3
Multi-officines
Stock multi-site, rôles par branche, achats et reporting consolidé.
v0.4
Interopérabilité
API publique, webhooks, OpenAPI, connecteurs simulés.
v0.5
Tests métier internes
Données synthétiques, revue pharmacien-dev, rapport de gaps.
v1.0
Candidat évaluation prod
Sécurité renforcée, audit, supervision, release artefacts, revue externe.
Condition permanente
L'usage réel en pharmacie reste bloqué tant que le Compliance & Conflict-of-Interest Gate n'est pas validé — indépendamment du niveau de maturité technique atteint.
10 — Prochaines étapes
Priorité immédiate : stabiliser v0.1, préparer v0.2
01Merger & CI — Merger proprement les changements UI/branding et vérifier la CI main.
02Assets — Optimiser les logos SVG pour réduire le poids des assets web et Keycloak.
03Captures — Ajouter des captures propres avec données synthétiques uniquement.
04Scénario démo — Documenter : réception produit → stock → vente → caisse → rapport.
05Seed synthétique — Renforcer pour une journée officinale crédible sans données réelles.
06POS workflow — Construire le workflow POS dédié et le ticket/reçu de simulation.
07Revue interne — Organiser avec un pharmacien-dev et un développeur, sans données réelles.
Definition of Done v0.2
Un pharmacien-dev peut simuler une journée simple : réception produit, stock, vente, caisse et rapport — sans données réelles et sans intervention du maintainer.
Conclusion
OfficinaOS est aujourd'hui une base technique solide pour explorer l'harmonisation des opérations officinales. Sa valeur vient de l'association entre architecture moderne, gouvernance prudente et ambition d'interopérabilité. La suite doit rester disciplinée : renforcer le cœur inventaire/caisse, tester uniquement avec données synthétiques et ne jamais confondre simulation technique avec autorisation d'usage réel.
OfficinaOS est un projet personnel open source en simulation technique. Il explore une infrastructure logicielle interopérable pour les officines modernes, sans claim de certification, d'homologation ou d'approbation institutionnelle.