Politique de confidentialité

Nous collectons le strict nécessaire pour exécuter un audit et vous en rendre compte. Rien n’est collecté à des fins publicitaires ou de revente.

• Compte : adresse email, mot de passe haché en scrypt (jamais conservé en clair), nom d’affichage, organisation de rattachement. Si vous vous inscrivez via GitHub ou GitLab, l’identifiant public du compte et l’adresse email associée.
• Dépôts importés : nom, propriétaire, identifiant, visibilité, branche par défaut, URL de clonage. Ce sont des métadonnées, pas du contenu.
• Jetons d’accès VCS : jeton d’installation de la GitHub App, ou jetons OAuth GitLab (accès et rafraîchissement). Ils sont stockés chiffrés, jamais en clair.
• Findings : titre, description, règle déclenchée, gravité, chemin de fichier, numéros de ligne, extrait de preuve caviardé, explication et remédiation rédigées pour vous.
• Rapports générés et métadonnées de run : date, durée, piliers exécutés, versions des moteurs, statut, score.
• Journaux d’exécution des scanners et journaux techniques : horodatage, identifiant de run, code de sortie, messages d’erreur. Ils servent au diagnostic et à la détection d’abus.

Nous ne posons aucun cookie publicitaire, n’intégrons aucun traceur tiers et n’utilisons aucun outil externe de mesure d’audience. Nous ne construisons donc aucune donnée de navigation, et aucun profil publicitaire n’existe chez nous — il n’y a rien à vous montrer parce qu’il n’y a rien à collecter.

C’est le point le plus important de cette politique, alors soyons précis sur le cycle de vie du clone.

• Au démarrage d’un run, le dépôt est cloné dans un répertoire éphémère, créé pour ce run et pour lui seul.
• Les moteurs d’analyse lisent ce répertoire en lecture seule, depuis des conteneurs isolés et sans accès réseau.
• À la fin du run — qu’il réussisse, échoue ou soit annulé — le répertoire est détruit.
• Le code source n’est jamais écrit dans le stockage objet durable. Il n’existe aucune sauvegarde de votre code chez nous, donc rien à restituer et rien à fuiter.

Ce qui survit au run, ce sont les findings, les rapports générés, les métadonnées de run et les journaux d’exécution des scanners. Un finding contient un chemin de fichier, des numéros de ligne et un extrait de preuve caviardé : assez pour retrouver le problème dans votre dépôt, pas assez pour reconstituer votre code.

Chaque traitement repose sur une base légale explicite au sens de l’article 6 du RGPD.

• Fournir le service — créer votre compte, importer vos dépôts, exécuter les audits, produire les rapports : exécution du contrat qui nous lie.
• Sécuriser le service — journaux techniques, détection d’abus, limitation de débit, attestations de propriété de domaine avant tout scan réseau : intérêt légitime à protéger l’infrastructure, nos utilisateurs et les tiers qui pourraient être visés à tort.
• Communications de service — nous n’envoyons à ce jour aucun courriel automatique : ni vérification d’adresse, ni réinitialisation de mot de passe, ni notification de fin de relevé. Le service ne comporte pas de mécanisme d’envoi. Votre adresse identifie le compte, sert à confirmer une suppression, et nous permet de vous joindre à la main s’il le faut. Le jour où un envoi automatique existera, ce paragraphe sera corrigé avant sa mise en service.
• Obligations comptables et réponse à une réquisition régulière d’autorité : obligation légale.
• Toute finalité sortant de ce cadre, par exemple une lettre d’information produit, repose sur votre consentement, donné par un acte positif et révocable à tout moment sans justification.

Le service est gratuit dans sa phase actuelle : nous n’effectuons aucun traitement à finalité de facturation, et ne détenons aucune donnée de paiement.

Nous n’avons aucun intérêt à garder des données au-delà de leur utilité : chaque donnée conservée est une donnée à protéger. Les durées sont les suivantes.

• Compte et données d’identification : tant que le compte est actif. La suppression, déclenchée depuis les réglages, est immédiate et définitive dans la base : le compte, l’organisation, les dépôts importés, les relevés, les findings, les rapports et les fichiers stockés associés disparaissent dans la foulée. Il n’y a ni corbeille, ni délai de grâce, ni restauration possible.
• Findings, rapports et métadonnées de relevé : 24 mois à compter du relevé, afin que vous puissiez suivre l’évolution d’un dépôt dans le temps. Passé ce délai, le relevé entier est effacé. Vous n’avez pas à attendre cette échéance : la suppression d’un relevé ou d’un dépôt est immédiate depuis l’interface.
• Journaux d’exécution des scanners et journaux techniques : 90 jours. Sont concernés la sortie brute des moteurs, les journaux de conteneur et les messages d’erreur attachés à chaque exécution.
• Jetons d’accès VCS : jusqu’à révocation, qui se fait depuis les réglages. Le chiffré est alors écrasé et la connexion supprimée. La révocation chez GitHub ou GitLab, elle, se fait chez eux : nous n’avons pas le pouvoir de désinstaller une application à votre place.
• Attestations d’autorisation des scans réseau : 24 mois, parce qu’elles constituent la preuve de l’autorisation d’un scan et protègent la cible, qui est un tiers. Elles survivent volontairement à la suppression du compte et expirent sur leur propre horloge.
• Sessions : 30 jours, la durée du cookie. Les sessions expirées sont effacées de la base par la purge quotidienne décrite ci-dessous.
• Code source cloné : la durée du run, et rien de plus. Voir la section précédente.

Ces durées ne sont pas déclaratives : une tâche automatique les applique chaque nuit, à 03h30 UTC — 04h30 à Douala. Elle efface les relevés de plus de 24 mois avec les findings, les rapports et les fichiers qui en dépendent ; les journaux d’exécution de plus de 90 jours, aussi bien les sorties des moteurs conservées comme fichiers que les messages d’erreur attachés à chaque exécution ; les fichiers dont l’échéance propre est dépassée ; les attestations d’autorisation de plus de 24 mois ; et les sessions expirées.

Deux précisions, parce qu’une purge quotidienne n’est pas une purge instantanée. La tâche passe une fois par jour : une donnée peut donc survivre à son échéance jusqu’au passage suivant, vingt-quatre heures au plus. Et si des analyses sont en cours à l’heure prévue, elle patiente pour ne pas les ralentir — deux heures au maximum, après quoi elle s’exécute quand même : une échéance de conservation ne se négocie pas contre la charge du serveur.

Chaque suppression est consignée dans le journal d’activité de votre organisation, avec le décompte de ce qui est parti, catégorie par catégorie ; un passage qui ne trouve rien à effacer chez vous n’y écrit rien. Ce journal fait partie de votre export JSON : vous pouvez donc vérifier vous-même que ces échéances sont tenues, plutôt que de nous croire sur parole.

Ce qui, en revanche, ne dépend d’aucune purge : la suppression d’un dépôt, d’un relevé, d’une connexion ou du compte est exécutée au moment où vous la demandez, dans la seconde.

Nous ne vendons aucune donnée. Nous ne transmettons à un tiers que ce qui est nécessaire au fonctionnement du service. La liste ci-dessous est complète à la date de cette version.

• Anthropic (API Claude), États-Unis — rédaction des explications et des remédiations attachées aux findings.
• OVH SAS, Roubaix, France — hébergement de l’application, des bases de données et des exécutions d’analyse.
• GitHub et GitLab — non pas destinataires, mais sources : nous lisons les dépôts que vous désignez, dans la limite des permissions que vous accordez, et vous pouvez révoquer cet accès chez eux à tout moment.

Ce qui est transmis à Anthropic, précisément : des extraits de code limités autour du finding, le titre du finding, la règle déclenchée et sa gravité. Le modèle rédige l’explication et la remédiation, dans une sortie contrainte par un schéma. Le contenu du dépôt lui est présenté comme donnée non fiable, afin qu’une instruction dissimulée dans votre code ne puisse pas détourner le traitement.

Ce qui n’est pas transmis à Anthropic : le dépôt complet, vos jetons d’accès, vos identifiants de compte, votre adresse email. Le modèle ne calcule pas le score de l’audit — le score est calculé chez nous, de façon déterministe, à partir des findings.

Le recours à Anthropic constitue un transfert de données hors Union européenne. Il est encadré par les clauses contractuelles types adoptées par la Commission européenne.

Nous ne détenons à ce jour aucune certification ISO 27001 ni rapport SOC 2. Nous préférons l’écrire noir sur blanc plutôt que de laisser le doute travailler en notre faveur.

Les mécanismes ci-dessous ne sont pas des intentions. Ils sont en place, et chacun ferme un risque précis.

• Les moteurs d’analyse s’exécutent dans des conteneurs gVisor (runsc) éphémères : réseau coupé par défaut, système de fichiers en lecture seule, toutes les capacités Linux retirées, utilisateur non-root, images épinglées par empreinte. Un moteur compromis par un dépôt hostile n’a ni réseau pour exfiltrer, ni écriture pour persister.
• Les jetons d’accès VCS sont chiffrés par enveloppe en AES-256-GCM, la clé maîtresse ne quittant jamais un coffre (OpenBao Transit). Une copie de la base de données ne suffit donc pas à les déchiffrer.
• Le cloisonnement entre organisations est posé à deux niveaux. Chaque ligne porte l’identifiant de son organisation, et toute requête est ouverte dans une transaction qui déclare l’organisation appelante puis filtre sur elle. Des politiques de Row-Level Security PostgreSQL, en refus par défaut, sont installées sur toutes les tables concernées et constituent le filet : elles s’appliquent intégralement au processus qui exécute les analyses. Nous ne prétendons pas qu’aujourd’hui tous nos processus soient soumis à ce filet — celui qui sert l’interface se connecte encore avec un rôle qui le contourne, et son cloisonnement repose donc sur le filtrage applicatif décrit ci-dessus. Nous préférons l’écrire.
• Les mots de passe sont hachés en scrypt. Les sessions reposent sur un cookie opaque HttpOnly, SameSite=Lax, dont seul un hachage SHA-256 est conservé côté serveur : une fuite de la table de sessions ne rend aucune session rejouable.
• Avant tout scan réseau, la propriété du domaine cible doit être prouvée par un enregistrement DNS TXT. Les adresses IP sont ré-résolues et épinglées au démarrage du scan, ce qui referme la fenêtre entre la vérification et l’exécution.

Le RGPD vous reconnaît les droits suivants sur vos données personnelles.

• Accès : obtenir la confirmation qu’un traitement existe et une copie des données que nous détenons sur vous.
• Rectification : faire corriger une donnée inexacte ou incomplète.
• Effacement : demander la suppression de votre compte et des données qui s’y rattachent.
• Portabilité : recevoir vos données dans un format structuré, couramment utilisé et lisible par machine.
• Opposition : vous opposer à un traitement fondé sur notre intérêt légitime, pour des raisons tenant à votre situation particulière.
• Limitation : demander le gel d’un traitement le temps qu’une contestation soit tranchée.

Une partie de ces droits s’exerce directement depuis l’interface, sans nous écrire : export de vos données au format JSON depuis les réglages, suppression d’un dépôt et de ses relevés depuis la page Dépôts, suppression d’un relevé et de ses findings depuis la page du relevé, révocation d’une connexion et destruction du jeton chiffré depuis les réglages, suppression du compte depuis les réglages. Ces cinq actions sont exécutées immédiatement et sont irréversibles ; la suppression du compte demande la ressaisie de votre adresse e-mail, vérifiée sur nos serveurs.

Pour le reste, écrivez à privacy@auditer.brightkyefoo.cm depuis l’adresse email de votre compte. Si nous avons un doute raisonnable sur votre identité, nous pouvons demander un élément de vérification supplémentaire — et rien d’autre que ce qui est nécessaire à cette vérification.

Nous répondons dans un délai d’un mois à compter de la réception de la demande. Ce délai peut être prolongé de deux mois si la demande est complexe ou multiple ; dans ce cas, nous vous en informons avec le motif avant la fin du premier mois.

Si votre demande porte sur des données figurant dans le dépôt d’une organisation cliente, c’est cette organisation qui en est responsable de traitement, et nous ne pouvons pas décider à sa place. Nous lui transmettons votre demande sans délai et lui fournissons les moyens techniques d’y répondre.

Si vous estimez que vos droits ne sont pas respectés, écrivez-nous d’abord à privacy@auditer.brightkyefoo.cm : la plupart des différends se règlent à ce stade, et plus vite.

Vous pouvez à tout moment saisir une autorité de contrôle. Si vous résidez dans l’Union européenne, il s’agit de l’autorité de protection des données de votre pays de résidence, de votre lieu de travail, ou du lieu où la violation alléguée a eu lieu. En France, c’est la CNIL.

Saisir une autorité ne vous prive d’aucun recours juridictionnel, et n’exige pas de nous avoir écrit au préalable.

Cette politique porte un numéro de version et une date de mise à jour. Les deux figurent en tête de page, afin que vous puissiez constater qu’un texte a changé.

Toute modification substantielle — nouvelle finalité, nouveau sous-traitant, allongement d’une durée de conservation — est annoncée par email aux titulaires de compte au moins 30 jours avant son entrée en vigueur.

Les corrections de forme sont publiées directement, avec incrément du numéro de version.