KARWISOFT¶

Manuel de livraison des solutions SaaS, DME, IA et médecine personnalisée¶

Version : 1.0
Statut : Document de travail interne
Propriétaire : Karwisoft
Périmètre : Solutions hospitalières, KarwiCare B2C et plateforme de médecine personnalisée Pharma

1. OBJECTIF DU MANUEL¶

Ce manuel définit le processus standard utilisé par Karwisoft pour concevoir, développer, intégrer, déployer et maintenir ses solutions numériques de santé et d'intelligence artificielle.

L'objectif est de permettre à Karwisoft de :

livrer ses projets de manière reproductible;
réduire les risques de projet;
améliorer la qualité des déploiements;
clarifier les responsabilités;
protéger les données de santé;
assurer une validation adéquate des fonctionnalités IA;
faciliter le passage d'un projet vers les opérations et le support;
mesurer la qualité et la performance des solutions.

Le processus doit être adapté au niveau de risque, à la taille du client et à la nature de la solution.

2. PORTFOLIO KARWISOFT¶

2.1 DME — Dossier médical électronique¶

Solution destinée principalement aux établissements de santé et aux hôpitaux.

Elle peut notamment couvrir :

gestion des dossiers patients;
informations administratives;
informations cliniques;
accès des professionnels;
consultation et saisie d'informations;
workflows cliniques;
intégrations avec les systèmes existants;
échanges de données;
recherche et consultation;
fonctions d'aide à la décision ou d'IA lorsque celles-ci sont prévues.

Le déploiement d'un DME doit être considéré comme un projet critique : une interruption ou une mauvaise configuration peut avoir des conséquences importantes sur les opérations de l'établissement.

3. KARWICARE — MÉDECINE PRÉVENTIVE B2C¶

KarwiCare est destiné directement aux patients/consommateurs.

Le processus doit mettre l'accent sur :

simplicité d'utilisation;
onboarding;
expérience utilisateur;
protection des données;
consentement;
personnalisation;
recommandations;
notifications;
qualité des informations;
sécurité;
support utilisateur;
mesure de l'engagement.

Les fonctionnalités présentant des recommandations médicales ou utilisant l'IA doivent être soumises à une validation spécifique avant leur mise à disposition.

4. PLATEFORME DE MÉDECINE PERSONNALISÉE — PHARMA¶

Cette solution est destinée aux compagnies pharmaceutiques et autres partenaires professionnels.

Le processus doit notamment couvrir :

définition du cas d'utilisation;
données disponibles;
gouvernance des données;
intégrations;
modèles analytiques ou IA;
validation;
traçabilité;
sécurité;
contrôle des accès;
reporting;
exigences contractuelles;
propriété intellectuelle;
déploiement et support.

Les objectifs scientifiques, cliniques, commerciaux et réglementaires du client doivent être clairement séparés et documentés.

5. CYCLE DE VIE STANDARD D'UN PROJET¶

Chaque projet Karwisoft suit autant que possible le cycle suivant :

SOP-001 — Qualification ↓
SOP-002 — Discovery ↓
SOP-003 — Analyse des besoins ↓
SOP-004 — Proposition et cadrage ↓
SOP-005 — Conception ↓
SOP-006 — Architecture ↓
SOP-007 — Développement / Configuration ↓
SOP-008 — Intégration des données et systèmes ↓
SOP-009 — Tests ↓
SOP-010 — Validation client ↓
SOP-011 — Préparation Go-Live ↓
SOP-012 — Déploiement ↓
SOP-013 — Hypercare ↓
SOP-014 — Passage au support ↓
SOP-015 — Exploitation et amélioration continue

6. SOP-001 — QUALIFICATION DU PROJET¶

Objectif¶

Déterminer si le projet correspond aux capacités, aux objectifs et au niveau de risque acceptable pour Karwisoft.

Étapes¶

Enregistrer le prospect.
Identifier le secteur.
Identifier les utilisateurs.
Comprendre le problème principal.
Identifier les fonctionnalités recherchées.
Identifier les données nécessaires.
Identifier les systèmes à intégrer.
Identifier les contraintes de sécurité.
Identifier les contraintes réglementaires applicables.
Évaluer la complexité.
Estimer les ressources nécessaires.
Déterminer si une Discovery est nécessaire.

Questions essentielles¶

Quel problème doit être résolu?
Qui utilisera la solution?
Combien d'utilisateurs sont concernés?
Quelles données seront utilisées?
S'agit-il de données de santé?
Où les données sont-elles actuellement stockées?
Quels systèmes doivent être intégrés?
Une IA est-elle nécessaire?
Quelle décision ou action la solution doit-elle supporter?
Quel est le niveau de criticité?
Quelles sont les attentes du client concernant la disponibilité?
Quelles sont les exigences de sécurité?

Critère de sortie¶

Le projet est :

Accepté pour Discovery / Mis en attente / Refusé.

7. SOP-002 — DISCOVERY¶

Objectif¶

Comprendre précisément le besoin avant de concevoir la solution.

La Discovery doit être documentée.

Participants¶

Selon le projet :

équipe Karwisoft;
responsable projet;
équipe technique;
experts métier;
représentants du client;
professionnels de santé;
responsables TI;
sécurité;
responsables données;
représentants réglementaires lorsque nécessaire.

Activités¶

7.1 Cartographie du processus actuel¶

Documenter :

Processus actuel → Problèmes → Besoin → Solution proposée

7.2 Identification des utilisateurs¶

Créer une liste des personas :

administrateur;
médecin;
infirmier;
professionnel de santé;
patient;
chercheur;
analyste;
responsable Pharma;
équipe TI.

7.3 Identification des données¶

Documenter :

source;
type;
format;
propriétaire;
sensibilité;
fréquence de mise à jour;
destination;
durée de conservation applicable;
contrôles d'accès.

7.4 Identification des intégrations¶

Pour chaque intégration :

système;
propriétaire;
méthode d'intégration;
API;
fréquence;
données échangées;
authentification;
gestion des erreurs;
monitoring.

8. SOP-003 — REQUIREMENTS¶

Chaque projet doit posséder un document d'exigences approuvé.

8.1 Exigences fonctionnelles¶

Exemple :

REQ-F-001

L'utilisateur autorisé doit pouvoir rechercher un dossier patient selon les critères autorisés.

8.2 Exigences non fonctionnelles¶

Exemples :

performance;
disponibilité;
sécurité;
évolutivité;
auditabilité;
compatibilité;
accessibilité.

8.3 User Story¶

Format recommandé :

En tant que [utilisateur], je veux [fonction] afin de [objectif].

8.4 Critères d'acceptation¶

Chaque fonctionnalité importante doit posséder des critères mesurables.

Exemple :

utilisateur autorisé;
action réalisée;
résultat attendu;
comportement en cas d'erreur.

9. SOP-004 — GESTION DU PÉRIMÈTRE¶

Tout changement important après validation des exigences doit être documenté.

Change Request¶

Chaque demande doit préciser :

numéro;
demandeur;
date;
description;
raison;
impact fonctionnel;
impact technique;
impact sécurité;
impact données;
impact IA;
impact calendrier;
impact coût;
approbation.

Aucun changement important ne doit être considéré comme automatiquement inclus dans le projet initial.

10. SOP-005 — CONCEPTION DE LA SOLUTION¶

La conception doit transformer les exigences en solution réalisable.

Elle doit couvrir :

architecture;
interface;
workflows;
données;
APIs;
intégrations;
authentification;
autorisations;
IA;
monitoring;
sauvegarde;
reprise après incident.

Un diagramme d'architecture doit être produit lorsque la complexité du projet le justifie.

11. SOP-006 — ARCHITECTURE SaaS¶

Chaque solution doit distinguer autant que nécessaire :

Environnement de développement¶

Utilisé pour développer et expérimenter.

Environnement de test¶

Utilisé pour les validations.

Environnement de production¶

Utilisé par les utilisateurs réels.

Les données réelles de santé ne doivent pas être utilisées dans un environnement de développement ou de test sans justification, contrôles et autorisations appropriés.

12. SOP-007 — DÉVELOPPEMENT ET CONFIGURATION¶

Avant développement¶

exigences approuvées;
architecture validée;
backlog défini;
critères d'acceptation définis;
dépendances identifiées.

Pendant développement¶

contrôle de version;
revue de code;
tests;
documentation;
gestion des secrets;
gestion des accès;
suivi des anomalies.

Avant livraison¶

code revu;
tests réalisés;
anomalies critiques résolues;
documentation mise à jour.

13. SOP-008 — INTÉGRATION DES DONNÉES¶

Étapes¶

Identifier les sources.
Définir les données nécessaires.
Définir le mapping.
Définir les transformations.
Effectuer les tests.
Valider les résultats.
Effectuer la migration lorsque nécessaire.
Réconcilier les données.
Documenter les résultats.

Contrôles¶

La migration doit vérifier notamment :

nombre d'enregistrements;
champs obligatoires;
formats;
doublons;
valeurs invalides;
relations;
intégrité.

14. SOP-009 — INTELLIGENCE ARTIFICIELLE¶

Toute fonctionnalité IA doit être documentée.

Fiche IA¶

Chaque fonctionnalité doit préciser :

objectif;
modèle utilisé;
version;
fournisseur;
données utilisées;
contexte fourni au modèle;
prompts/instructions;
outils accessibles;
limites;
niveau d'autonomie;
contrôle humain;
méthode d'évaluation;
seuils de qualité;
méthode de monitoring;
procédure en cas d'erreur.

Validation IA¶

Les tests doivent inclure, selon le cas :

cas normaux;
cas incomplets;
cas ambigus;
cas limites;
informations contradictoires;
demandes hors périmètre;
réponses potentiellement dangereuses;
problèmes de confidentialité;
tentatives de manipulation des instructions;
comportement lorsque les données nécessaires sont absentes.

Une fonctionnalité IA ne doit pas être considérée comme validée uniquement parce qu'elle produit une réponse plausible.

15. SOP-010 — TESTS¶

Niveaux de test¶

Tests unitaires¶

Validation des composants individuels.

Tests d'intégration¶

Validation des interactions entre composants.

Tests fonctionnels¶

Validation des exigences.

Tests de sécurité¶

Validation des accès, permissions et protections.

Tests de performance¶

Validation du comportement sous charge.

Tests IA¶

Validation spécifique des résultats générés ou assistés par IA.

UAT¶

Le client valide que la solution répond aux besoins métier définis.

16. SOP-011 — VALIDATION DME HÔPITAL¶

Pour un DME, ajouter notamment :

validation des workflows cliniques;
validation des rôles;
validation des permissions;
validation des recherches;
validation des intégrations;
validation de la migration;
validation des interfaces;
tests de disponibilité;
tests de reprise;
formation;
procédure d'urgence.

Les scénarios critiques doivent être identifiés avant le Go-Live.

17. SOP-012 — VALIDATION KARWICARE¶

Pour KarwiCare :

création du compte;
onboarding;
consentements;
profil;
parcours utilisateur;
recommandations;
notifications;
gestion des erreurs;
confidentialité;
expérience mobile/web;
support;
suppression ou gestion du compte selon les règles applicables.

Les recommandations médicales doivent être validées selon leur nature et leur niveau de risque.

18. SOP-013 — VALIDATION PLATEFORME PHARMA¶

Valider notamment :

données;
accès;
analyses;
modèles;
résultats;
traçabilité;
exports;
rapports;
intégrations;
performance;
sécurité;
exigences spécifiques du client.

Toute sortie utilisée à des fins scientifiques, cliniques ou réglementaires doit avoir un processus de validation adapté à son utilisation prévue.

19. SOP-014 — SECURITY & PRIVACY GATE¶

Avant production, effectuer une revue de sécurité.

Checklist¶

[ ] Authentification configurée
[ ] Autorisations vérifiées
[ ] Comptes administrateurs contrôlés
[ ] Secrets protégés
[ ] Chiffrement vérifié
[ ] Logs configurés
[ ] Données sensibles identifiées
[ ] Accès minimisés
[ ] Sauvegardes configurées
[ ] Procédure d'incident disponible
[ ] Fournisseurs externes documentés
[ ] Flux de données documentés

Les exigences légales et réglementaires applicables doivent être identifiées selon la juridiction du client.

20. SOP-015 — GO-LIVE READINESS¶

Un Go-Live ne doit être autorisé que lorsque les conditions définies sont satisfaites.

Go-Live Checklist¶

Produit¶

[ ] Fonctionnalités terminées
[ ] Tests terminés
[ ] UAT approuvé

Technique¶

[ ] Production prête
[ ] Monitoring actif
[ ] Sauvegarde vérifiée
[ ] Rollback défini

Sécurité¶

[ ] Accès vérifiés
[ ] Sécurité validée
[ ] Données validées

Client¶

[ ] Formation réalisée
[ ] Documentation remise
[ ] Contacts support confirmés
[ ] Approbation Go-Live obtenue

21. SOP-016 — DÉPLOIEMENT¶

Le déploiement doit suivre un plan documenté.

Plan¶

Vérification pré-déploiement.
Sauvegarde.
Déploiement.
Migration éventuelle.
Vérifications techniques.
Smoke tests.
Validation fonctionnelle.
Activation des utilisateurs.
Surveillance.
Confirmation du Go-Live.

Rollback¶

Chaque déploiement critique doit définir :

condition de rollback;
responsable;
procédure;
durée estimée;
données concernées;
communication au client.

22. SOP-017 — HYPERCARE¶

Après le Go-Live, une période d'hypercare est mise en place lorsque nécessaire.

Pendant cette période :

monitoring renforcé;
traitement prioritaire des incidents;
suivi quotidien;
collecte du feedback;
analyse des erreurs;
suivi de l'adoption;
correction rapide des problèmes critiques.

À la fin de l'hypercare, le projet est transféré aux opérations/support.

23. SOP-018 — TRANSFERT AU SUPPORT¶

Le transfert doit comprendre :

architecture;
configuration;
documentation;
procédures;
contacts;
accès;
monitoring;
incidents connus;
limitations connues;
procédures de résolution;
SLA applicables.

Le support doit savoir :

quoi surveiller, quoi faire lorsqu'une alerte apparaît et quand escalader.

24. SOP-019 — GESTION DES INCIDENTS¶

Classification¶

P1 — Critique¶

Impact majeur sur le service ou une fonction critique.

P2 — Élevé¶

Impact important mais solution ou contournement possible.

P3 — Normal¶

Impact limité.

P4 — Faible¶

Question, amélioration ou problème mineur.

Chaque contrat client doit définir les délais et obligations applicables.

Processus¶

Détection → Qualification → Contention → Résolution → Validation → Communication → Post-mortem

25. SOP-020 — MONITORING¶

Surveiller selon la solution :

disponibilité;
temps de réponse;
erreurs;
utilisation;
capacité;
intégrations;
APIs;
bases de données;
sécurité;
coûts;
consommation IA;
qualité des résultats IA.

Pour l'IA, surveiller également les changements de qualité et de comportement du système.

26. SOP-021 — GESTION DES MODÈLES IA¶

Pour chaque modèle :

modèle;
fournisseur;
version;
date d'utilisation;
usage;
données;
limites;
métriques;
évaluations;
dépendances.

Lorsqu'un modèle change, effectuer une analyse d'impact.

Une nouvelle version d'un modèle ne doit pas être considérée comme équivalente automatiquement à l'ancienne.

27. SOP-022 — GESTION DES FOURNISSEURS¶

Documenter les fournisseurs critiques :

cloud;
IA/LLM;
APIs;
logiciels;
hébergement;
sécurité;
communication;
analytics.

Pour chaque fournisseur :

service fourni;
données concernées;
dépendance;
criticité;
contrat;
disponibilité;
procédure en cas d'indisponibilité.

28. SOP-023 — GESTION DES ACCÈS¶

Principe général :

Chaque utilisateur doit disposer uniquement des accès nécessaires à son rôle.

Processus :

Demande → Validation → Création → Vérification → Monitoring → Révocation

Les accès doivent être retirés lorsqu'ils ne sont plus nécessaires.

Les comptes privilégiés doivent bénéficier de contrôles renforcés.

29. SOP-024 — SAUVEGARDE ET REPRISE¶

Chaque solution critique doit définir :

quelles données sont sauvegardées;
fréquence;
durée de conservation;
emplacement;
responsable;
méthode de restauration;
objectifs de récupération;
procédure de test.

Une sauvegarde qui n'a jamais été restaurée/testée ne doit pas être considérée comme pleinement validée.

30. SOP-025 — AMÉLIORATION CONTINUE¶

Après livraison :

analyser les incidents;
analyser l'utilisation;
recueillir le feedback;
mesurer les KPI;
identifier les améliorations;
prioriser;
développer;
tester;
déployer;
mesurer le résultat.

Le SaaS doit être considéré comme un produit vivant et non comme un projet terminé au Go-Live.

31. KPI KARWISOFT¶

KPI projet¶

délai prévu vs réel;
budget prévu vs réel;
nombre de changements;
nombre d'anomalies;
nombre d'incidents post-Go-Live;
délai moyen de résolution.

KPI produit¶

utilisateurs actifs;
adoption;
utilisation des fonctionnalités;
disponibilité;
performance;
taux d'erreur.

KPI IA¶

taux de réussite;
taux d'erreur;
taux de réponses nécessitant intervention humaine;
qualité des résultats;
coût par utilisation;
latence;
incidents liés à l'IA.

KPI client¶

satisfaction;
tickets support;
renouvellement;
utilisation;
feedback;
valeur créée.

32. RACI STANDARD¶

Activité	Karwisoft	Client	IT client	Métier client
Discovery	R	A/R	C	C
Requirements	R	A	C	R
Architecture	R	C	C	C
Développement	R	I	C	I
Intégrations	R	A	R	C
UAT	C	A	C	R
Go-Live	R	A	R	C
Formation	R	C	C	R
Support	R	I	C	C

R = Responsible
A = Accountable
C = Consulted
I = Informed

Ce RACI doit être adapté à chaque contrat.

33. DOCUMENTS À PRODUIRE PAR PROJET¶

Chaque projet devrait posséder un dossier structuré.

01 — Commercial¶

proposition;
contrat;
périmètre.

02 — Discovery¶

notes;
processus;
besoins.

03 — Requirements¶

exigences;
user stories;
critères d'acceptation.

04 — Architecture¶

architecture;
diagrammes;
intégrations.

05 — Data¶

inventaire;
mapping;
migration.

06 — AI¶

fiche IA;
modèles;
évaluations;
prompts/instructions;
monitoring.

07 — Testing¶

plan de test;
résultats;
anomalies;
UAT.

08 — Deployment¶

plan;
Go-Live checklist;
rollback.

09 — Operations¶

runbook;
monitoring;
support.

10 — Closure¶

approbation finale;
lessons learned;
transfert.

34. CRITÈRES DE SORTIE DES PHASES¶

Une phase ne doit passer à la suivante que si ses critères de sortie sont satisfaits.

Discovery → Requirements¶

Le problème, les utilisateurs et le périmètre sont suffisamment compris.

Requirements → Development¶

Les exigences critiques sont approuvées.

Development → Testing¶

La version est suffisamment stable pour être testée.

Testing → UAT¶

Les tests internes requis sont terminés.

UAT → Go-Live¶

Le client a approuvé les critères définis.

Go-Live → Hypercare¶

La solution est opérationnelle et le monitoring est actif.

Hypercare → Support¶

La solution est suffisamment stable pour entrer dans le fonctionnement normal.

35. CHECKLIST FINALE DU CHEF DE PROJET¶

Avant de clôturer un projet :

[ ] Périmètre livré
[ ] Exigences validées
[ ] Tests terminés
[ ] UAT approuvé
[ ] Sécurité validée
[ ] Données validées
[ ] IA validée si applicable
[ ] Documentation remise
[ ] Formation effectuée
[ ] Go-Live effectué
[ ] Support informé
[ ] Monitoring actif
[ ] Incidents critiques résolus
[ ] Contrat/SLA documenté
[ ] Lessons learned réalisées
[ ] Approbation de clôture obtenue

36. PRINCIPE DIRECTEUR KARWISOFT¶

Le principe central du processus est :

Comprendre avant de construire.
Documenter avant de déployer.
Tester avant de livrer.
Valider avant de mettre en production.
Surveiller après le Go-Live.
Améliorer continuellement.

Pour les solutions de santé et d'IA, un principe supplémentaire s'applique :

La performance technique ne suffit pas : la sécurité, la confidentialité, la qualité des données, la validation et l'utilisation prévue doivent également être prises en compte.

37. ANNEXE — TEMPLATE FICHE PROJET¶

Nom du projet :

Client :

Produit :
☐ DME
☐ KarwiCare
☐ Médecine personnalisée Pharma
☐ Autre

Responsable Karwisoft :

Responsable client :

Date de début :

Date prévue de Go-Live :

Objectif :

Utilisateurs :

Données utilisées :

Intégrations :

Fonctionnalités IA :

Niveau de criticité :

Exigences particulières :

Risques principaux :

KPI de succès :

SLA :

Statut :

38. ANNEXE — TEMPLATE GO-LIVE APPROVAL¶

Projet :

Client :

Date :

Les parties confirment que les critères définis pour le Go-Live ont été évalués.

Validation¶

Produit : ☐
Technique : ☐
Données : ☐
Sécurité : ☐
IA : ☐
UAT : ☐
Formation : ☐
Support : ☐
Monitoring : ☐
Rollback : ☐

Décision :

☐ Go-Live approuvé
☐ Go-Live reporté

Commentaires :

Responsable Karwisoft :

Responsable client :

Date :

39. ANNEXE — TEMPLATE INCIDENT¶

Numéro :

Date/heure :

Client :

Solution :

Sévérité :

Description :

Impact :

Détection :

Cause :

Actions immédiates :

Résolution :

Validation :

Communication client :

Action préventive :

Responsable :

Date de clôture :

40. VERSIONNAGE DU MANUEL¶

Toute modification importante du présent manuel doit être enregistrée.

Version	Date	Modification	Responsable
1.0	À définir	Création du manuel	Karwisoft

Fin du document