Centre de confiance

CheckFox est édité par Crofte Studio S.à r.l.-S, Luxembourg (RCS B310079), et opéré par une seule personne. Je l'écris clairement parce que cela doit orienter vos questions : il n'y a derrière cette page ni équipe de sécurité, ni astreinte, ni organisme de certification. Ce qu'il y a à la place est listé ci-dessous, et chaque point peut être vérifié.

• L'infrastructure est gérée par des prestataires établis (base de données, hébergement, réseau), et non par des serveurs montés à la main.
• Vos audits peuvent être exportés depuis l'interface à tout moment, sans me le demander.
• Les engagements qui dépendent de la disponibilité d'une seule personne sont publiés comme objectifs, avec leurs limites, dans les niveaux de service.

Le contenu de vos audits est stocké dans l'Union européenne. Les prestataires utilisés pour le paiement, l'e-mail, les analyses automatisées, les fonctions d'IA et la mesure d'audience sont listés avec leurs garanties dans le registre des sous-traitants.

• Les mots de passe sont stockés uniquement sous forme de hachages salés.
• Authentification à deux facteurs optionnelle. Une fois activée, elle est imposée par la base de données elle-même : une session qui n'a pas passé le second facteur ne peut pas lire les données protégées, même en dehors de l'interface.
• Les actions sensibles redemandent le mot de passe : création d'une clé d'API, changement de rôle d'un membre, modification de la facturation, suppression du compte.
• Changer de mot de passe déconnecte toutes les autres sessions.
• Chaque membre d'un espace de travail a un rôle (Propriétaire, Modérateur, Éditeur, Lecteur), et le moindre privilège s'applique par défaut.
• Sécurité au niveau des lignes sur chaque table contenant des données utilisateur : la base refuse de renvoyer les lignes d'un autre espace de travail, même si l'application a un bogue.
• Les champs sensibles, comme les identifiants de facturation et les jetons d'intégration, ne peuvent jamais être lus ni modifiés depuis le navigateur.

• Chaque requête est authentifiée, puis contrôlée sur la ressource précise qu'elle touche. Une ressource que vous ne pouvez pas voir répond « introuvable », pour ne pas révéler son existence.
• Les entrées sont validées, et les écritures n'acceptent qu'une liste explicite de champs.
• Limites de fréquence sur la connexion, les invitations, les vérifications de mot de passe, les analyses et les requêtes d'IA.
• Les requêtes serveur vers des adresses que vous fournissez (par exemple une page à analyser) ne peuvent pas atteindre des réseaux internes ou privés.
• Le contenu que vous rédigez dans les rapports, notes et déclarations est assaini avant affichage, et les images téléversées sont débarrassées de tout contenu actif.
• Une politique de sécurité du contenu (CSP) appliquée, la sécurité de transport stricte (HSTS) et les en-têtes de protection habituels sur chaque page.
• Les webhooks de paiement sont vérifiés par signature, et une offre ne change qu'une fois le paiement confirmé par le prestataire.
• Les jetons d'intégration et vos propres clés de fournisseur d'IA sont stockés chiffrés, utilisables uniquement par le serveur, et jamais renvoyés au navigateur.
• Les clés d'API sont stockées hachées, portent des permissions explicites et expirent au bout d'un an.

• Chaque requête d'IA passe par le serveur, qui vérifie d'abord le compte, l'espace de travail et l'offre. Le navigateur ne détient jamais de clé de fournisseur de modèle.
• Votre contenu n'est pas utilisé pour entraîner des modèles d'IA.
• Le texte que vous saisissez et le code des pages auditées sont transmis au modèle comme des données, jamais comme des instructions.
• Un espace de travail peut utiliser sa propre clé de fournisseur d'IA ; les requêtes partent alors vers ce fournisseur, dans le cadre de votre propre contrat avec lui.

• Chiffrement en transit (TLS) partout, et au repos pour la base de données et le stockage de fichiers.
• Les secrets du serveur sont conservés dans les coffres des prestataires, jamais dans le code ni dans le navigateur.
• Le service qui tourne sur le serveur d'origine est isolé de tout le reste de la machine : son propre compte système, un bac à sable restreint, joignable uniquement à travers le serveur web, et incapable de modifier son propre code.

• Le fournisseur de base de données effectue des sauvegardes quotidiennes et les conserve 7 jours, dans l'Union européenne.
• CheckFox effectue sa propre sauvegarde toutes les 6 heures et conserve les 8 dernières, en France.
• Ces sauvegardes sont chiffrées avec une clé publique avant de quitter le serveur. La clé privée nécessaire pour les lire est conservée hors ligne : ni le serveur ni le prestataire de stockage ne peuvent les déchiffrer.
• Les fichiers téléversés (captures d'écran, logos, pièces jointes) sont copiés sous 15 minutes, chiffrés avec la même clé publique, en France. La copie d'un fichier supprimé est effacée 7 jours plus tard.
• Le processus de sauvegarde se connecte à la base avec un compte en lecture seule : il ne peut pas modifier la production.
• Une restauration est une opération manuelle et délibérée. Elle ne peut pas être déclenchée depuis le web.
• Une donnée supprimée disparaît de toutes les sauvegardes sous 35 jours au plus tard.

Les objectifs de reprise (perte de données maximale, délai de restauration) figurent dans les niveaux de service.

• Un environnement de préproduction séparé, avec sa propre base de données et un compte de paiement de test, où chaque changement est testé avant la production.
• Les modifications de la base de données sont écrites sous forme de migrations relues, appliquées d'abord en préproduction, puis en production.
• Tests automatisés, analyse statique et contrôle des dépendances avant chaque déploiement. Les dépendances du serveur sont figées à des versions exactes.
• Les déploiements s'exécutent avec des accès au moindre privilège et refusent un serveur dont l'identité ne correspond pas.

Des audits de sécurité complets ont été menés en mai 2026 et en octobre 2026. L'audit d'octobre a combiné une revue du code, des tests en conditions réelles sur la préproduction et la production, et une liste de contrôle point par point. Chaque problème critique ou élevé a été corrigé et vérifié en préproduction avant sa mise en production.

Ces audits sont internes. CheckFox n'a pas encore été testé par une société indépendante de tests d'intrusion. Si votre organisation l'exige, vous pouvez en commander un aux conditions de la section 12 de l'Accord de sous-traitance.

• Si une violation de données personnelles touche vos données, je vous la notifie dans les 48 heures après en avoir pris connaissance, comme prévu à la section 10 de l'Accord de sous-traitance.
• Chaque violation est consignée dans un registre interne, y compris celles qui n'exigent pas de notification.
• Les incidents de service sont communiqués comme décrit dans les niveaux de service.
• Les vulnérabilités peuvent être signalées selon la politique de divulgation de sécurité.

• Seules les données nécessaires au service sont collectées.
• Mesure d'audience sans cookie et sans stockage des adresses IP.
• Aucune vente de données personnelles, aucune publicité, aucun pistage d'un site à l'autre.
• L'export et la suppression du compte sont en libre-service.

Les prestataires sous-jacents détiennent des certifications pour les couches qu'ils opèrent, et chacun les publie :

• Supabase : SOC 2 Type 2.
• Amazon Web Services : ISO 27001, SOC 2, entre autres.
• OVHcloud : ISO 27001.
• Cloudflare : ISO 27001, SOC 2 Type 2.
• Stripe : PCI DSS niveau 1. Les numéros de carte n'atteignent jamais CheckFox.

• La documentation de sécurité détaillée, dont cette page est la synthèse publique.
• Votre questionnaire de sécurité, complété.
• Un exemplaire contresigné de l'Accord de sous-traitance.
• Une synthèse du dernier audit de sécurité et de la façon dont ses constats ont été corrigés.

Écrivez à l'adresse ci-dessous. Aucun accord de confidentialité n'est nécessaire ; je demande seulement que ces documents servent à votre évaluation et ne soient pas republiés.