DPIA — Data Protection Impact Assessment — RGPD Art. 35 — AKC PARTNERS / Objectif Santé+
| Société | AKC PARTNERS — Objectif Santé+ |
| RCS | 101 800 464 R.C.S. Nanterre |
| Adresse | 20 Rue des Petites Murailles, 92230 Gennevilliers |
| DPO | KEDDARI Imad, Gabriel — dpo@objectifsante.net |
Conformément à l'article 35 du RGPD, une DPIA est obligatoire lorsque le traitement est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes. Les critères déclencheurs présents dans ce traitement sont :
La plateforme Objectif Santé+ permet à des professionnels de santé et chargés de prévention de faire passer des questionnaires de prévention santé à leurs patients, dans le cadre du programme Mon Bilan Prévention (Assurance Maladie). Les réponses sont collectées via QR code ou interface web, puis un bilan PDF personnalisé est généré par intelligence artificielle et transmis au patient via un espace sécurisé.
| Étape | Action | Données impliquées | Acteurs |
|---|---|---|---|
| 1 | Saisie du questionnaire | Nom, prénom, DDN, NIR, données de santé | Patient → Professionnel / Sondeur |
| 2 | Soumission et chiffrement | Toutes les données + consentement RGPD | Frontend → Serveur Flask |
| 3 | Stockage chiffré | Fichier AES-256-GCM + BDD SQLCipher | Serveur OVH France |
| 4 | Génération du bilan IA | Réponses anonymisées (sans NIR/nom) | Serveur → API OpenAI |
| 5 | Envoi email patient | Email, prénom, lien sécurisé (14j) | Serveur → SMTP Gmail → Patient |
| 6 | Accès espace patient | Consultation/téléchargement du bilan | Patient → Portail sécurisé |
| Finalité | Justification | Base légale |
|---|---|---|
| Bilan de prévention santé | Programme légal Mon Bilan Prévention (Assurance Maladie). Nécessité médicale et préventive. | Art. 9.2.a — Consentement explicite |
| Génération du bilan par IA | Personnalisation médicalement pertinente. Données anonymisées transmises à l'IA. | Art. 6.1.b — Exécution du service |
| Transmission au patient | Droit du patient à accéder à son bilan. Espace personnel sécurisé. | Art. 6.1.b + 9.2.a |
| Logs de traçabilité | Sécurité du système. Exigence HDS. | Art. 6.1.c + 6.1.f |
| Donnée | Nécessaire ? | Justification |
|---|---|---|
| Nom / Prénom | Oui | Identification du patient et personnalisation du bilan |
| Date de naissance | Oui | Sélection du questionnaire adapté à la tranche d'âge |
| NIR (Sécu) | Oui | Identification unique — exigence du programme Mon Bilan Prévention |
| Optionnel | Uniquement si envoi du bilan souhaité par le patient | |
| Téléphone | Optionnel | Contact urgence — collecté uniquement si renseigné |
| Données de santé | Oui | Cœur du questionnaire de prévention. Strictement nécessaires au bilan. |
| Consentement + timestamp | Oui | Preuve de consentement RGPD Art. 7 — obligatoire |
Probabilité × Gravité → Niveau de risque
| Scénario | Source de menace | Vraisemblance | Gravité | Risque brut | Mesures existantes | Risque résiduel |
|---|---|---|---|---|---|---|
| Accès non autorisé à la BDD | Attaquant externe, injection SQL | Limitée | Maximale | Moyen | SQLCipher, RBAC, pas d'accès direct BDD exposée | Faible |
| Vol de fichiers questionnaires | Attaquant accédant au serveur | Limitée | Maximale | Moyen | Chiffrement AES-256-GCM — fichiers illisibles sans clé | Faible |
| Usurpation de compte professionnel | Phishing, credential stuffing | Importante | Maximale | Élevé | bcrypt, session timeout 15 min | Moyen |
| Accès patient par token volé | Interception email | Limitée | Importante | Moyen | Token usage unique, expiration 14j, HTTPS | Faible |
| Divulgation données via IA (OpenAI) | Fuite API, mauvaise anonymisation | Négligeable | Maximale | Moyen | Données anonymisées (sans NIR/nom), API stateless | Faible |
| Scénario | Source de menace | Vraisemblance | Gravité | Risque brut | Mesures existantes | Risque résiduel |
|---|---|---|---|---|---|---|
| Falsification d'un bilan par un utilisateur | Utilisateur malveillant interne | Limitée | Maximale | Moyen | Logs traçabilité complets, RBAC, soft-delete avec horodatage | Faible |
| Injection de données frauduleuses | Attaquant externe via formulaire | Limitée | Importante | Moyen | Validation côté serveur, authentification requise pour soumettre | Faible |
| Corruption de la BDD | Bug, erreur humaine | Limitée | Importante | Moyen | Sauvegardes 30j, SQLCipher avec intégrité | Faible |
| Scénario | Source de menace | Vraisemblance | Gravité | Risque brut | Mesures existantes | Risque résiduel |
|---|---|---|---|---|---|---|
| Perte des données (panne serveur) | Défaillance matérielle OVH | Négligeable | Maximale | Moyen | Sauvegardes OVH, soft-delete (pas de suppression définitive) | Faible |
| Suppression accidentelle par admin | Erreur humaine | Limitée | Importante | Moyen | Soft-delete avec restauration possible, logs d'audit | Faible |
| Ransomware / chiffrement malveillant | Malware sur serveur | Négligeable | Catastrophique | Moyen | Hébergement OVH HDS, sauvegardes externes | Faible |
| Mesure | Détail | Risque couvert |
|---|---|---|
| Chiffrement AES-256-GCM | Tous les fichiers questionnaires stockés chiffrés | Accès illégitime, vol de fichiers |
| SQLCipher | Base de données entièrement chiffrée | Accès illégitime à la BDD |
| Chiffrement Fernet (PII) | NIR, email, noms chiffrés en base | Exposition données personnelles |
| HTTPS / TLS | Toutes les communications chiffrées en transit | Interception réseau |
| Hachage bcrypt | Mots de passe jamais stockés en clair | Vol de credentials |
| RBAC (5 niveaux) | Super Admin, Admin, Org, User, Sondeur, Patient — cloisonnement total | Accès non autorisé interne |
| Session timeout | Expiration automatique 15-30 min d'inactivité | Usurpation de session |
| Tokens usage unique | Liens patient valides 14j, marqués "utilisés" après usage | Réutilisation de token volé |
| Soft-delete | Aucune suppression définitive — restauration possible | Disparition accidentelle des données |
| Logs d'audit complets | Toutes les actions tracées (IP, horodatage, utilisateur) | Modifications non autorisées, traçabilité |
| Anonymisation automatique | Logs anonymisés lors de la suppression d'un compte | Violation droit à l'oubli |
| Hébergement HDS (OVH) | Certifié Hébergeur Données de Santé | Exigences réglementaires santé |
| Mesure | Responsable | Statut |
|---|---|---|
| DPO désigné | KEDDARI Imad, Gabriel | En place — Mars 2026 |
| Registre des traitements (Art. 30) | DPO | En place — Mars 2026 |
| Politique de confidentialité publiée | DPO + Direction | En place — Mars 2026 |
| Consentement RGPD enregistré en BDD | Équipe technique | En place — Mars 2026 |
| Procédure de notification violation (72h CNIL) | DPO | Documentée |
| Droits patients (export, suppression, rectification) | Équipe technique | En place — Espace patient |
| Credentials isolés (.env) | Équipe technique | En place — Mars 2026 |
| Authentification multi-facteurs (MFA) | Équipe technique | À implémenter (priorité moyenne) |
| Formation du personnel au RGPD | DPO | À planifier |
| Charte informatique interne | Direction | À rédiger |
| Action | Priorité | Échéance suggérée |
|---|---|---|
| Implémenter l'authentification à deux facteurs (2FA) pour les comptes professionnels | Haute | T2 2026 |
| Mettre en place une politique de rotation des clés de chiffrement | Moyenne | T3 2026 |
| Rédiger la charte informatique et la politique de sécurité interne | Moyenne | T2 2026 |
| Former le personnel (DPO, développeurs, support) au RGPD et à la sécurité | Moyenne | T2 2026 |
| Mettre en place un rate limiting sur les endpoints de login | Haute | T2 2026 |
| Ajouter protection CSRF sur tous les formulaires | Haute | T2 2026 |
| Tester un plan de reprise d'activité (PRA) en cas de panne OVH | Moyenne | T3 2026 |
| Catégorie de risque | Risque brut | Risque résiduel |
|---|---|---|
| Accès illégitime aux données de santé | Élevé | Faible |
| Modification non désirée des données | Moyen | Faible |
| Disparition / perte des données | Moyen | Faible |
| Usurpation de compte professionnel | Élevé | Moyen |
| Alertes urgence (données sensibles extrêmes) | Élevé | Moyen |
| Transfert données hors UE (OpenAI) | Moyen | Faible |
Au regard des mesures de sécurité mises en place (chiffrement multicouche, RBAC, HDS, consentement enregistré,
logs d'audit, DPO désigné, registre des traitements), le niveau de risque résiduel est jugé
acceptable pour démarrer le traitement.
Le plan d'action (MFA, rate limiting, CSRF, formation) sera suivi et mis en œuvre avant fin T2 2026
pour ramener tous les risques au niveau Faible.
Conformément à l'art. 36 RGPD, une consultation préalable de la CNIL est requise si, après application des mesures, le risque résiduel reste élevé. En l'état actuel, cette consultation n'est pas nécessaire — les risques résiduels sont faibles à moyens.
Si un nouveau traitement venait à engendrer des risques résiduels élevés non couverts, une consultation CNIL sera lancée avant démarrage (cnil.fr).
ABSSI Ryan
Directeur Général — AKC PARTNERS
Mars 2026
KEDDARI Imad, Gabriel
DPO — AKC PARTNERS
dpo@objectifsante.net
Mars 2026
| Date | Version | Motif de révision | Réviseur |
|---|---|---|---|
| Mars 2026 | 1.0 | Création initiale — lancement de la plateforme | DPO |
| À planifier — T2 2026 | 1.1 | Après implémentation MFA, rate limiting, CSRF | DPO + Tech |
| Annuel | — | Révision annuelle obligatoire ou lors de changement de traitement | DPO |