Protection et sécurité des données

01Principes

• Rien n’est effacé en silence. Un document se retire par archivage, une version refusée reste refusée, une réserve levée garde sa trace. Le journal du projet est complet ou il n’est rien.
• On ne voit que ce qu’on a le droit de voir. Le cloisonnement est fait dans la base, par dossier et par niveau ; un document interdit n’apparaît nulle part, pas même par son nom.
• Le moins possible. La plateforme ne charge aucune ressource tierce à l’usage, ne pose aucun traceur, ne conserve aucun mot de passe en clair.
• Dire ce qui est. Les mesures ci-dessous sont celles en place à la date de ce document ; ce qui est prévu et non encore fait est dit comme tel.

02Hébergement

Les données ne quittent pas la région de Francfort pour le service. L’hébergeur publie ses certifications (ISO 27001, SOC 1/2/3, C5) pour cette région ; nous nous appuyons sur elles pour l’infrastructure physique et le réseau, et répondons de ce qui est au-dessus.

03Chiffrement

• En transit : TLS sur toute la plateforme, certificats renouvelés automatiquement ; les anciennes adresses redirigent vers waslplateforme.com. Les téléchargements et les dépôts de fichiers passent par des adresses signées à durée de vie courte, jamais par un accès public au stockage.
• Au repos : la base de données est chiffrée par l’hébergeur (AES-256), ainsi que ses sauvegardes automatiques ; le compartiment de fichiers applique le chiffrement AES-256 par défaut à chaque objet et refuse tout accès public (blocage des accès publics activé à tous les niveaux).
• Mots de passe : jamais conservés · seule une empreinte Argon2id est stockée ; une adresse inconnue et un mauvais mot de passe coûtent le même temps de réponse, pour ne rien révéler.
• Jetons : les liens d’invitation, de réinitialisation et de session sont conservés sous forme hachée (SHA-256) ; un jeton volé en base ne sert à rien.

04Contrôle des accès

L’accès aux documents est accordé par l’administrateur du projet, dossier par dossier, à trois niveaux, consulter, modifier, administrer, le plus souvent au travers de niveaux d’accès nommés qu’il définit une fois et attribue à chaque intervenant. Ce cloisonnement est appliqué dans les requêtes elles-mêmes : le registre, la boîte de réception, la recherche, les exports et le fil d’activité lisent tous le même filtre de visibilité, et un document interdit n’est jamais listé, compté ni nommé.

Les délégations (référentiel qualité, circuits de validation) sont explicites et journalisées ; le transfert de l’administration est une action distincte, confirmée et irréversible pour celui qui la fait. Un compte révoqué perd l’accès immédiatement, ses sessions comprises.

Les accès d’exploitation de notre équipe passent par les outils de l’hébergeur, avec authentification forte, et sont journalisés par lui.

05Authentification et sessions

• Mot de passe de douze caractères au moins, avec les règles affichées au moment du choix et vérifiées côté serveur par le même module.
• Sessions de 14 jours au plus, portées par un cookie inaccessible aux scripts, transmis en HTTPS seulement, propre au domaine ; révoquées à la déconnexion et à la révocation du compte.
• Réinitialisation par lien valable une heure et à usage unique ; invitation par lien valable 7 jours. Les formulaires répondent de la même façon qu’une adresse soit connue ou non.
• L’authentification à deux facteurs et l’identification par annuaire d’entreprise (SSO) ne sont pas encore proposées ; elles sont prévues et seront annoncées ici.

06Journalisation et intégrité

Chaque action qui compte, dépôt, nouvelle version, soumission, visa, refus, remarque, réserve, changement d’accès, invitation, révocation, import de planning, export, est inscrite au journal du projet avec son auteur, son objet et son horodatage, dans la base de données, en ajout seul : l’application n’a pas d’écran pour modifier ou effacer une ligne de journal.

Les versions d’un document sont immuables : une nouvelle version s’ajoute, la précédente reste. Le stockage de fichiers conserve lui-même les versions antérieures d’un objet écrasé. Un certificat de visa porte un code de vérification consultable publiquement ; les documents publiés portent un QR code qui y renvoie.

Prévu : un scellement périodique du journal (empreinte chaînée horodatée) pour prouver qu’aucune ligne n’a été altérée après coup, et l’horodatage qualifié par un prestataire agréé pour les marchés qui l’exigent.

07Sauvegardes et continuité

Objectifs actuels : perte de données maximale d’une journée pour la base (au plus quelques minutes avec le journal de transactions), aucune pour les fichiers ; rétablissement du service dans la journée. Une restauration de la base est testée sur une instance séparée avant chaque migration de schéma. Prévu, et proposé aux abonnés qui le demandent : une rétention de sauvegarde étendue (trente-cinq jours) et une copie hors région.

08Suppression et restitution

Un projet dont l’abonnement s’achève passe en lecture seule pendant quatre-vingt-dix jours ; son administrateur exporte ce qu’il veut et peut demander l’export complet, documents, métadonnées et journal, dans des formats ouverts (fichiers d’origine, CSV, PDF, BCF, ICS). Passé ce délai, les données sont supprimées des systèmes actifs, puis des sauvegardes au terme de leur rotation, et une attestation de suppression est remise sur demande.

À la demande d’un abonné soumis à une obligation de conservation (garantie décennale, marché public), le projet peut rester en lecture seule au-delà, aux conditions du bon de commande.

09Incidents

Un incident de sécurité affectant des données d’un projet, accès non autorisé, perte, altération, est notifié aux administrateurs des projets concernés sans retard injustifié et au plus tard soixante-douze heures après que nous en avons pris connaissance, avec la nature de l’incident, les données concernées, les mesures prises et celles recommandées. Les autorités compétentes sont informées quand la loi l’exige.

Une faille peut nous être signalée à contact@waslplateforme.com ; nous accusons réception sous quarante-huit heures et n’engageons pas de poursuite contre qui la signale de bonne foi sans exploiter les données.

10Développement et exploitation

• Les dépendances sont vérifiées et mises à jour régulièrement ; les images de déploiement sont reconstruites à chaque version.
• Les fichiers déposés sont convertis (aperçus de pages, géométrie des maquettes) dans des processus isolés, sans exécution du contenu du fichier.
• Les environnements de test utilisent des données fictives ; aucune donnée de production n’y est copiée.
• Une suite de tests de bout en bout couvre les parcours d’accès, de dépôt, de visa et de cloisonnement avant chaque mise en production.
• Prévu : test d’intrusion indépendant annuel, dont la synthèse sera remise aux abonnés qui la demandent.

11Cadre légal

Les traitements sont soumis à la loi n° 09-08 du 18 février 2009 relative à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à ses textes d’application, sous le contrôle de la CNDP : déclaration du traitement et autorisation de transfert pour l’hébergement hors du territoire. Pour les intervenants établis dans l’Union européenne, les principes du RGPD sont appliqués et les garanties de l’hébergeur (accord de traitement, clauses contractuelles types) s’ajoutent.

La valeur probante des documents et des visas s’appuie sur la loi n° 53-05 relative à l’échange électronique de données juridiques et sur les articles 417-1 et 417-2 du Dahir formant Code des obligations et des contrats, comme dit dans les Conditions.

12Ce que nous ne faisons pas

• Nous ne lisons pas vos documents, sauf assistance demandée par un administrateur.
• Nous ne vendons, ne louons et ne partageons aucune donnée avec des tiers.
• Nous n’entraînons aucun modèle sur vos contenus.
• Nous ne posons aucun traceur et ne mesurons pas votre navigation hors de la plateforme.
• Nous ne conservons aucun mot de passe et ne pouvons pas vous le communiquer.
• Nous ne déplaçons pas vos données hors de la région de Francfort sans vous l’annoncer.