Charte éthique — OmbrysWeb

• Version : 1.0.0
• Date : 2026-04-24
• Issue GitHub : #8
• Références : cahier des charges § 7
• Statut : Brouillon pour revue collective — à ratifier par l'ensemble des membres fondateurs avant publication.

Qui nous sommes

OmbrysWeb est la plateforme d'un collectif de hackers. Le terme « hacker » s'entend ici dans son sens historique et technique : quelqu'un qui comprend les systèmes en profondeur, expérimente, cherche leurs limites, et partage ce qu'il apprend. Nous ne confondons pas curiosité technique et nuisance. Cette charte existe pour le dire clairement, et pour poser des limites que nous nous imposons à nous-mêmes.

Nos engagements

1. Sécurité et confidentialité des membres

• Nous construisons la plateforme selon un modèle Zero-Knowledge : le serveur n'accède jamais en clair au contenu privé des membres. Les clés de déchiffrement restent dans les authenticators des membres.
• Nous refusons les mécanismes de « backdoor » gouvernementaux ou privés. Une plateforme accessible à un tiers sous contrainte n'est plus la nôtre.
• Nous publions un warrant canary mensuel signé ; son absence de signature est un signal.

2. Transparence

• Le code source est publié en miroir public read-only sur GitHub. Le code est auditable par toute personne.
• Nous publions un transparency report trimestriel (requêtes légales reçues, réponses données, dans la mesure où la loi nous permet d'en parler).
• Les décisions techniques structurantes sont documentées dans les ADR versionnées du dépôt.
• Les incidents de sévérité 1 ou 2 impactant les membres font l'objet d'un post-mortem public.

3. Éthique du hacking

Nous distinguons trois catégories d'activité :

Légitimes, soutenues par le collectif :

• Recherche en sécurité sur nos propres systèmes ou sur des systèmes dont les propriétaires nous ont autorisés par écrit (scope, règles d'engagement, délais de divulgation).
• Participation à des compétitions CTF (Capture The Flag).
• Red team contractuel pour des clients consentants, avec périmètre documenté.
• Bug bounty public ou privé respectant le programme du propriétaire.
• Audit / code review de logiciels open source.
• Divulgation responsable (coordinated disclosure) : vendor contacté, délai raisonnable (90 jours par défaut), publication à l'échéance ou sur accord.
• Recherche académique avec conformité éthique (IRB, comité d'éthique selon le cas).
• Développement d'outils défensifs et offensifs éducatifs (pentests, honeypots, frameworks d'analyse) publiés sous licence libre.

Ambigües, soumises à discussion collective cas par cas :

• Vulnerability brokering (vente de 0-day) : réservé aux programmes officiels de bug bounty ou aux canaux coordonnés. Pas de vente sur marchés gris ni à des acteurs dont les intentions sont opaques.
• Tests d'intrusion sur des systèmes publics sans autorisation explicite (même si l'intention est « positive ») : interdits par défaut, sauf cadre légal clair du pays concerné (ex : programme gouvernemental explicite).
• Recherche sur des malwares / botnets actifs : tolérée pour la compréhension, pas pour la participation.
• Analyse de données fuitées publiquement : tolérée pour la recherche, pas pour l'exploitation personnelle.

Interdites, incompatibles avec le collectif :

• Tout accès non autorisé à un système tiers avec intention de nuisance, de profit personnel, ou de chantage.
• Ransomware, extorsion, doxxing.
• Vol d'identité, fraude financière, carding.
• Harcèlement, surveillance non consentie (y compris stalkerware).
• Développement d'outils destinés à nuire à des personnes (surveillance d'État liberticide, spyware commercial contre journalistes/militants, deepfake non-consensuel).
• Compromission de chaîne d'approvisionnement (commit malveillant sur un projet dont on a la confiance).
• Attaques contre des infrastructures essentielles (hôpitaux, énergie, eau, transports critiques, ONG humanitaires, journalistes, défenseurs des droits humains).
• Collaboration avec des régimes pratiquant la répression numérique contre leurs populations.

4. Divulgation responsable

Quand nous découvrons une vulnérabilité dans un système tiers (dans le cadre d'une activité légitime) :

1. Contact vendor en premier. Canal chiffré préféré (PGP, Signal, formulaire sécurisé).
2. Délai de 90 jours par défaut, extensible en cas de coopération active et de correctif complexe.
3. Publication technique détaillée à l'échéance, en minimisant les détails immédiatement exploitables si une partie du parc reste vulnérable.
4. Si la vulnérabilité est activement exploitée dans la nature, le délai peut être raccourci d'un commun accord.
5. Nous ne revendiquons jamais de CVE à la place du vendor. Nous acceptons d'être cités si c'est leur souhait.

5. Respect des membres et des tiers

• Pas de harcèlement ni de discrimination fondée sur l'origine, le genre, l'orientation, la religion, la classe sociale, le handicap, ou toute autre caractéristique protégée.
• Désaccord technique ≠ attaque personnelle. Les critiques portent sur les idées, le code, les décisions — pas sur les personnes.
• Confidentialité des échanges internes : ce qui se dit dans le collectif reste dans le collectif, sauf consentement explicite contraire.

6. Gouvernance et responsabilité

• Les décisions structurantes (éthique, architecture majeure, nouveau membre) sont prises par consensus du core team. En cas de désaccord persistant, un vote à majorité des 2/3 des membres actifs.
• La présente charte est amendable par le même processus. Les modifications sont versionnées, publiques, et accompagnées d'une justification.
• Un membre peut être exclu du collectif pour violation caractérisée de cette charte. Procédure : saisine du core team, instruction contradictoire, décision motivée publiée.
• DPO désigné (Data Protection Officer) parmi les membres, point de contact pour toute demande RGPD ou question de conformité.
• Point de contact sécurité dédié via la page Contact chiffré, répondant sous 72 h ouvrées.

7. Juridique

• Nous nous conformons au RGPD : registre des traitements tenu à jour, Privacy Impact Assessment pour chaque feature traitant des données personnelles.
• Nous répondons aux demandes légales valides dans les limites strictes de la loi applicable et de cette charte. Le modèle Zero-Knowledge rend techniquement impossible la fourniture de données privées en clair ; nous ne chercherons jamais à contourner cette protection à la demande d'un tiers, quel qu'il soit.
• Nous documentons les demandes reçues dans le transparency report trimestriel, dans la mesure où la loi nous le permet.

8. Conflits d'intérêts

• Tout membre ayant un lien professionnel ou personnel susceptible d'affecter son jugement sur une décision déclare ce conflit avant la discussion.
• Un membre ne peut pas auditer ou approuver son propre travail sensible (crypto, sécurité, éthique) sans au moins un second reviewer indépendant.

Ce que cette charte n'est pas

• Elle n'est pas un contrat entre le collectif et un tiers. C'est un engagement que nous prenons entre nous et vis-à-vis du public qui nous lit.
• Elle n'est pas exhaustive. Les zones grises existent ; elles se tranchent en discussion collective, pas par application littérale d'une règle.
• Elle n'est pas figée. Elle évolue avec nos erreurs, avec l'écosystème, avec les débats qui traversent la communauté sécurité.

Pour nous contacter

• Contact chiffré public : https://<domaine>/contact (formulaire chiffré côté client, voir § 4.1 du cahier des charges).
• Sécurité / divulgation responsable : même canal, mention explicite [SECURITY] dans le premier message.
• Presse / journalistes : même canal, mention [PRESS].
• Clé publique du collectif : publiée sur la page de contact, fingerprint signé par le core team dans les transparency reports.

Changelog

• 2026-04-24 : brouillon initial v1.0.0. À soumettre à revue collective avant ratification et publication.