Sécurité et confiance
Comment QLAC protège données, projets, rapports et accès sans revendiquer de certifications non obtenues ni promettre le risque zéro.
Dernière mise à jour: 2026-05-11
1. Principe de sécurité
QLAC est conçu pour traiter des informations techniques de projet avec séparation console interne/Portail Client, permissions par rôle, validation d'ownership et traçabilité des actions sensibles.
2. Accès et isolation
- Backoffice réservé aux profils internes autorisés.
- Portail Client séparé par routes, layouts, policies et données filtrées.
- Les clients ne doivent voir que les projets, rapports, documents et preuves autorisés pour leur tenant.
- Téléchargements privés via contrôleurs autorisés sans exposer les chemins réels de stockage.
3. Fichiers, dépôts et preuves
Les ZIPs et fichiers de projet sont traités comme non fiables. QLAC valide format, taille, chemins dangereux, symlinks, archives imbriquées et stockage privé. Les flux client n'exécutent pas le code téléversé.
GitHub et GitLab, lorsqu'ils sont disponibles, doivent utiliser consentement explicite, permissions minimales, tokens chiffrés et révocation visible.
4. Audits et limites
Lighthouse fonctionne avec validation SSRF, files, timeouts et stockage privé des artefacts. Les résultats sont des données laboratoire et indiqués comme tels. QLAC ne présente pas Lighthouse comme certification ni comme mesure directe de l'INP réel.
5. Billing et données de paiement
Paddle agit comme fournisseur de paiement lorsque le checkout est actif. QLAC conserve statuts, plans, événements et références nécessaires à l'abonnement, mais ne stocke pas les cartes ni données bancaires.
6. Transparence
QLAC communique des mesures raisonnables, limites et responsabilités. Il n'affirme pas ISO 27001, SOC 2, OWASP certified, NIST certified ni sécurité absolue sauf certification réelle et vérifiable.