EZOUEU
Achats · Sécurité · DPO

Questionnaire fournisseur prérempli

Chaque réponse renvoie vers une preuve publique et porte sa date de vérification. Une absence est conservée comme réponse, pas remplacée par une promesse.

16 réponsesVérifiées le

1. Qui fournit le service ?

BoredGeekSociety SASU, société française immatriculée au RCS de Paris sous le numéro 919 737 593, siège au 60 rue François Ier, 75008 Paris.

Source : Mentions légalesVérifié le

2. Où se trouve l’infrastructure directe ?

Le calcul, l’Object Storage et PostgreSQL managé sont déclarés chez Scaleway en région parisienne. OVH opère le domaine et le DNS ; Brevo les emails ; Mollie le paiement. Les prestataires directs listés sont établis dans l’UE ou l’EEE.

Source : Registre des prestataires directsVérifié le

3. La chaîne ultérieure est-elle entièrement européenne ?

Non démontré. La revue directe ne couvre pas encore complètement les sous-traitants ultérieurs, accès support, télémétries et mécanismes de transfert de chaque fournisseur.

Source : État de diligenceVérifié le

4. Quel est le rôle RGPD d’EZOU.EU ?

BoredGeekSociety est responsable des traitements de compte, sécurité, facturation et support. Pour le contenu publié selon les instructions du Client, EZOU.EU agit comme sous-traitant dans le périmètre du DPA.

Source : Politique de confidentialitéVérifié le

5. Un DPA Article 28 est-il disponible ?

Oui. Le texte public, son annexe et la version sont consultables avant paiement. La signature en ligne du DPA enregistre la version, l’empreinte SHA-256 et la liste des prestataires.

Source : DPA publicVérifié le

6. Quels contrôles d’accès existent ?

URL non listée, mot de passe haché avec Argon2id et accès restreint par domaine email. Les sessions et liens temporaires sont signés. La séparation fine des rôles administrateur/membre n’est pas encore complète.

Source : Mesures techniques et organisationnellesVérifié le

7. Le contenu est-il scanné ?

Une analyse DLP, demandée à la publication ou imposée par la règle du compte, couvre des formats texte et certains PDF. Elle n’est pas appliquée par défaut. Les détecteurs bloquants analysent le fichier entier, sans plafond de taille. NIR valides et secrets pris en charge bloquent toujours ; le mode block étend le refus aux avertissements. Archives et OCR ne sont pas couverts ; les PDF volumineux et la détection de noms restent partiels, et chaque fichier concerné est nommé dans le rapport de scan.

Source : Documentation DLPVérifié le

8. Comment les fichiers sont-ils supprimés ?

La suppression retire les objets du stockage principal, appelle le purger configuré — aucun CDN actif — puis signe et journalise une attestation Ed25519. Elle ne couvre pas les copies téléchargées ou systèmes tiers.

Source : Architecture d’effacementVérifié le

9. Les attestations sont-elles vérifiables ?

Oui pour l’intégrité et l’attribution à une clé publique connue. Le format, l’ordre JSON et l’algorithme Ed25519 sont documentés. L’historique public de rotation des anciennes clés reste à durcir.

Source : Format de l’attestationVérifié le

10. Quels logs et compteurs sont conservés ?

Les logs HTTP minimisent IP, user-agent et chemins d’artefact. L’IP de publication est tronquée puis purgée à J+7 ; celles liées à un événement de sécurité suivent le journal de sécurité : 30 jours en clair, puis empreinte réseau, 12 mois. Les compteurs d’une publication (pages par chemin, provenances, navigateur, système, terminal, pays, robots) ne mesurent pas les visiteurs uniques : aucun cookie, aucune empreinte, aucune adresse IP conservée. Rétention : 13 mois, le détail d’une publication étant effacé avec elle.

Source : Politique de confidentialitéVérifié le

11. Votre mesure oblige-t-elle mes visiteurs à voir un bandeau de consentement ?

Non. Aucun cookie n’est déposé, rien n’est inscrit ni lu dans le terminal du visiteur : la mesure est faite par le serveur, dans les critères d’exemption de la mesure d’audience. Si le contenu publié charge lui-même une ressource tierce, cette obligation-là ne dépend pas de nous.

Source : Politique de confidentialitéVérifié le

12. Le service publie-t-il un SLA, RPO ou RTO ?

Non. L’architecture utilise une instance de calcul unique. La configuration de sauvegarde et un test réel de restauration ne sont pas publiés ; aucun chiffre contractuel n’est annoncé.

Source : Disponibilité et sauvegardesVérifié le

13. Comment signaler un incident ou une vulnérabilité ?

Les abus et vulnérabilités se signalent à abuse@ezou.eu ; les sujets de données personnelles à dpo@ezou.eu. Aucun délai public garanti de réponse ou de correction n’est annoncé.

Source : Politique de signalementVérifié le

14. Quelles certifications et quels pentests sont disponibles ?

Aucune certification HDS, SecNumCloud, ISO 27001 ou SOC 2 n’est revendiquée. Aucun résultat de pentest public n’est disponible à cette date.

Source : Security briefVérifié le

15. Quelle réversibilité est disponible ?

Le registre des publications est exportable en CSV et les attestations en JSON. Il n’existe pas encore d’export en masse de tous les fichiers et métadonnées. Le Client doit conserver ses sources.

Source : RéversibilitéVérifié le

16. Les données fortement réglementées sont-elles acceptées ?

L’offre self-service n’est pas présentée pour les données exigeant HDS, PCI DSS ou SecNumCloud. Les catégories particulières et traitements à haut risque demandent une qualification et une validation contractuelle préalables.

Source : Périmètre des données réglementéesVérifié le

Validation

Ce questionnaire décrit le service public à une date donnée. Une exigence contractuelle, un contrôle d’exploitation ou une preuve confidentielle doit être confirmé avant signature ; cette page ne vaut ni certification, ni audit indépendant.