# Centre de confiance

> Choisir qui va construire et protéger vos systèmes devrait se décider sur des preuves plutôt que sur des adjectifs. Cette page rassemble ce qu'un acheteur sérieux vérifie avant de signer : qui nous sommes, qui répond du travail, comment il est produit, ce qui vous appartient à la fin, et ce qui se passe quand quelque chose tourne mal.

**URL:** https://www.regenbyte.com/fr/trust

## Vos comptes. Votre infrastructure. Votre code.

C'est un engagement permanent et non une position de négociation. Une agence qui détient votre domaine, votre hébergement ou votre dépôt est une agence que vous ne pouvez pas quitter, et cet arrangement nous profite à vos dépens.

- **Le code source vous appartient:** Tout ce qui est écrit pour vous est à vous, dans votre dépôt, sous une licence qui ne dépend pas de nous. Aucun framework propriétaire à continuer de payer.
- **Les comptes sont créés à votre nom:** Chaque fois que c'est praticable, le domaine, l'hébergement, le DNS, le cloud, le dépôt, l'analytique, le prestataire de paiement et les services tiers sont ouverts dans vos propres comptes, avec nous en collaborateur et non en propriétaire.
- **Les accès sont transférables, pas retenus:** Identifiants de déploiement, variables d'environnement et accès d'administration sont documentés et transmis. Nous retirer nos accès doit prendre un après-midi, pas une négociation.
- **Une documentation écrite pour un successeur:** Notes d'architecture, procédures d'exploitation et décisions sont rédigées pour qu'une autre équipe compétente puisse reprendre le système sans nous parler d'abord.
- **Aucune dépendance forcée:** Nous utilisons des technologies répandues et bien documentées et évitons les choix dont le principal effet serait de nous rendre difficiles à remplacer. Rester avec nous doit être un jugement sur le travail.
- **La maintenance est facultative:** Le support continu existe parce que les systèmes en ont besoin, pas parce que votre site s'arrête sans nous. Certains clients reprennent la main en interne, et nous transmettons la documentation exactement pour cela.

## Comment le travail est réellement produit.

- **Gestion de versions et revue:** Tout le travail est suivi dans Git et arrive par pull request. Les changements sont relus avant d'atteindre une branche de production, et l'historique explique pourquoi quelque chose a changé, pas seulement que cela a changé.
- **Intégration continue:** Vérification de types, analyse statique et suite de tests s'exécutent à chaque changement. Une branche qui échoue ne fusionne pas : un état cassé se détecte en minutes plutôt qu'après déploiement.
- **Des tests automatisés là où ils comptent:** Les tests se concentrent sur la logique coûteuse à rater : authentification, autorisation, paiements, intégrité des données. Nous ne courons pas après un pourcentage de couverture pour lui-même.
- **Revue des dépendances et de la configuration:** Les paquets tiers sont audités et mis à jour dans le cadre de la maintenance courante. Les composants vulnérables connus sont la faiblesse la plus exploitée du web précisément parce que leur exploitation est automatisée.
- **Des secrets hors du code:** Les identifiants vivent dans la configuration d'environnement, jamais dans le dépôt. Les clés sont limitées à un usage unique pour qu'une exposition ne devienne pas un accès total.
- **Une performance tenue par budget:** Les Core Web Vitals et les budgets de poids de page sont tenus pendant la construction plutôt que rattrapés à la fin, et nous vous montrons les mesures de votre propre site plutôt que des chiffres génériques.
- **Une accessibilité vérifiée, pas supposée:** Sémantique, navigation au clavier, ordre de focus et contrastes sont vérifiés pendant le développement, avec des contrôles automatisés doublés de passes manuelles sur les parcours qui comptent.
- **Des déploiements réversibles:** Les mises en production sont atomiques et peuvent revenir à la version saine précédente. Pouvoir annuler vite vaut mieux que la certitude de ne jamais en avoir besoin.
- **Des sauvegardes déjà restaurées:** La restauration est testée, pas supposée. Une sauvegarde que personne n'a jamais restaurée est une hypothèse, et le moment où vous en avez besoin est le mauvais moment pour le découvrir.

## Comment nous traitons nos systèmes, et les vôtres.

- En-têtes de sécurité, HTTPS et durcissement du transport appliqués au niveau du framework, donc valables pour toutes les routes
- Moindre privilège pour les comptes, jetons et identifiants de service, et interfaces d'administration non exposées publiquement sans raison
- Modélisation des menaces dès la conception, tant que l'architecture peut encore changer à faible coût
- Des tests menés uniquement sous autorisation écrite de la partie habilitée à l'accorder, prospects compris
- Des constats classés selon l'impact métier réel plutôt que la sévérité brute d'un scanner, avec accompagnement de remédiation et nouveau test
- Une politique de divulgation responsable publiée et un fichier security.txt lisible par machine à l'emplacement prévu par la RFC 9116

### Méthodologies suivies

Nous travaillons selon ces méthodologies publiées. Pour être précis : ce sont les référentiels que suivent nos tests et nos revues, et non des certifications détenues par l'entreprise. Nous ne revendiquons aucune accréditation formelle qui ne nous a pas été délivrée.

- OWASP Top 10 et OWASP Application Security Verification Standard (ASVS)
- OWASP API Security Top 10, pour les interfaces plutôt que les pages
- Penetration Testing Execution Standard (PTES) pour la structure des missions
- Recommandations du NIST sur le développement sécurisé et la gestion d'incidents
- CIS Benchmarks pour la configuration des plateformes et des serveurs

## Sous-traitants

Les tiers qui traitent des données pour notre compte pour ce site. Chacun est listé avec sa finalité et ce qu'il peut voir.

- **Vercel:** Hébergement applicatif, réseau de périphérie et déploiements. Métadonnées de requête, dont l'adresse IP et l'agent utilisateur.
- **Neon:** Base de données Postgres managée et sauvegardes. Contenus du site et demandes enregistrées.
- **Resend:** Remise des e-mails transactionnels de demande. Le contenu de la demande que vous envoyez, et votre adresse e-mail.

Ceci décrit regenbyte.com. Les projets clients tournent dans les comptes du client chaque fois que c'est praticable : chaque mission a donc ses propres prestataires et sa propre liste, consignée dans la documentation de ce projet plutôt qu'ici.

## Ce que ce site collecte, et pour combien de temps.

- **Ce qui est collecté:** Uniquement ce que vous saisissez dans le formulaire : nom, société, e-mail, éventuellement téléphone et pays, et ce que vous écrivez sur le projet. Ce site ne contient aucun traceur publicitaire.
- **Pourquoi c'est conservé:** Pour vous répondre et garder une trace de l'échange. Les demandes sont enregistrées avant toute tentative d'envoi, pour qu'une panne de messagerie ne puisse en perdre aucune.
- **Qui peut le consulter:** Les personnes de RegenByte qui en ont besoin pour répondre, ainsi que les sous-traitants ci-dessus, dans le cadre de l'hébergement, du stockage et de la remise du message.
- **Comment le faire supprimer:** Écrivez-nous et nous supprimerons votre demande, puis confirmerons que c'est fait. Aucune justification n'est requise et cela n'a aucune autre conséquence.
- **Données des projets clients:** Pendant une mission, nous travaillons dans vos systèmes sous vos contrôles d'accès. Nous ne copions pas de données de production sur nos machines lorsqu'un échantillon anonymisé ou synthétique fait le même travail.
- **Constats et rapports:** Les constats de sécurité relatifs à vos systèmes vous sont confidentiels. Ils ne sont ni publiés, ni réutilisés en marketing, ni partagés sans votre accord écrit.

## Réponse aux incidents et continuité.

- **Contenir:** Arrêter l'hémorragie d'abord : révoquer l'identifiant, revenir à la version précédente, retirer le chemin affecté du service. Le diagnostic vient après la limitation de l'exposition.
- **Vous prévenir:** Vous l'apprenez par nous, tôt, en langage clair, y compris ce que nous ignorons encore. Nous préférons un point d'étape incomplet à un point complet trop tardif.
- **Rétablir:** Revenir à un état sain connu depuis une sauvegarde testée ou un déploiement antérieur, et vérifier la restauration plutôt que la supposer réussie.
- **Établir les faits:** Journaux et chronologies sont conservés pour que le récit de l'incident soit reconstitué à partir de preuves et non de souvenirs.
- **Corriger la cause:** La panne immédiate et la raison qui l'a rendue possible sont traitées toutes les deux. Un correctif qui laisse la faiblesse sous-jacente en place n'est qu'une demi-correction.
- **Le consigner par écrit:** Vous recevez un compte rendu écrit : ce qui s'est passé, ce qui a été touché, ce qui a été fait, et ce qui a changé pour que cela soit moins probable. Sans blâme et sans flou.

### Continuité

- Les systèmes clients tournent dans des comptes qui leur appartiennent : notre continuité n'est jamais un point de défaillance unique pour votre activité
- Le code vit dans votre dépôt : une reconstruction complète de n'importe quel environnement est possible à partir de ce que vous détenez déjà
- La documentation de transfert est tenue à jour pendant la mission, pas rédigée à la fin
- Les sauvegardes sont assurées par la plateforme de base de données managée et la restauration est testée plutôt que supposée