La sécurité chez Kodo

Infrastructure

Kodo tourne sur Vercel pour l'hébergement et le calcul, avec une base de données Postgres managée (Neon) pour les données applicatives. Quand on a besoin de stockage objet (par exemple les rapports PDF sur les plans Gagner), on utilise Vercel Blob. Notre région de déploiement principale est les États-Unis. Vercel gère le trafic en périphérie, la terminaison TLS et l'atténuation DDoS au niveau réseau. Neon gère la réplication de base de données, la récupération à un instant T et les sauvegardes managées.

Les deux prestataires publient leur propre documentation de sécurité, que tu peux lire directement : vercel.com/security et neon.tech/security. Les deux sont certifiés SOC 2 Type II.

Chiffrement

Tout le trafic entre ton navigateur et Kodo est chiffré avec TLS 1.2 ou supérieur. On n'accepte pas les connexions en HTTP en clair. Les connexions à la base de données depuis nos serveurs applicatifs vers Postgres sont aussi chiffrées en TLS. Les données au repos dans la base de données sont chiffrées en AES-256 par le fournisseur de la base. Les sauvegardes managées sont chiffrées avec le même standard.

On ne stocke pas les mots de passe. L'authentification est gérée par Clerk, qui utilise un hachage de mot de passe standard de l'industrie et prend en charge les options modernes sans mot de passe (passkeys, magic links, connexion sociale).

Authentification et accès

L'authentification des utilisateurs finaux est gérée par Clerk. Clerk prend en charge l'authentification multi-facteur (MFA) pour les comptes qui l'activent, et on recommande de l'activer. Les sessions utilisent des cookies sécurisés en HTTP-only avec les drapeaux Secure et SameSite activés.

L'accès interne aux systèmes de production est limité à la petite équipe d'ingénieurs qui en a besoin pour faire tourner le service. Chaque membre de l'équipe se connecte aux consoles des prestataires via une connexion unique avec MFA requise. L'accès à la base de données de production est journalisé. On fait tourner les identifiants selon un planning régulier et immédiatement quand le rôle d'un membre de l'équipe change.

Sécurité applicative

L'application suit les pratiques de sécurité web standard :

• En-têtes Content Security Policy pour limiter quels scripts et ressources le navigateur va charger.
• Strict Transport Security (HSTS) pour que les navigateurs refusent de parler à Kodo en HTTP en clair.
• Cookies sécurisés, HTTP-only, SameSitepour tout état de session.
• Requêtes de base de données paramétréesvia notre ORM. On ne construit pas de SQL par concaténation de chaînes, ce qui ferme la porte à l'injection à la source.
• Validation des entrées côté serveur sur chaque endpoint API, avec des bibliothèques de validation de schéma.
• Limitation de débit sur les endpoints publics (y compris la vérif gratuite) pour ralentir les abus et les tentatives de credential-stuffing.
• Analyse de dépendances sur chaque pull request pour qu'on remarque quand une bibliothèque qu'on utilise a une vulnérabilité connue.

Sous-traitants tiers

On utilise une courte liste de prestataires pour livrer le produit. Chacun a été choisi parce que sa posture de sécurité est bien documentée et adaptée aux données qu'il traite :

• Vercel pour l'hébergement, le calcul en périphérie et TLS.
• Neon pour Postgres managé, les sauvegardes et la récupération à un instant T.
• Clerk pour l'authentification des utilisateurs finaux et la gestion des sessions.
• Stripe pour le traitement des paiements. Stripe est certifié PCI-DSS Niveau 1. On ne voit ni ne stocke jamais de numéros de carte complets ; Stripe gère tout ça sur sa propre infrastructure.
• Resend pour les emails transactionnels (ton rapport, les mises à jour mensuelles, les notifications de sécurité).
• APIs des assistants IA d'OpenAI, Anthropic, Google et xAI, utilisées pour lancer les vérifs qu'on promet. On envoie les questions publiques qu'un client poserait (par exemple "meilleur coiffeur à Belleville"). On n'envoie pas de données de compte ni d'infos personnelles.

La liste complète des prestataires et ce que chacun traite vit dans notre politique de confidentialité.

Surveillance et réponse aux incidents

On surveille la production pour repérer les schémas de trafic inhabituels, les pics d'erreurs et les tentatives d'authentification échouées. Les alertes critiques appellent l'ingénieur d'astreinte. On revoit les logs chaque semaine et après tout incident notable.

Si on découvre un incident de sécurité qui affecte les données des utilisateurs, on préviendra les utilisateurs affectés sans délai indu, et dans tous les cas dans les 72 heures après confirmation de l'incident. Ça correspond au délai de notification RGPD. L'avis te dira ce qui s'est passé, quelles données étaient concernées, ce qu'on a fait à ce sujet et ce que (s'il y a quelque chose) tu devrais faire de ton côté.

Sauvegardes et récupération

La base de données est sauvegardée quotidiennement par le fournisseur Postgres managé, avec récupération à un instant T sur les 7 derniers jours. Les sauvegardes sont chiffrées et stockées dans la même région que la base principale. On teste la procédure de restauration chaque trimestre sur un environnement de staging pour savoir qu'elle marche vraiment avant d'en avoir besoin.

Confidentialité et minimisation des données

On collecte le minimum nécessaire pour lancer la vérif et livrer le rapport : le nom de ton commerce, la ville où tu es et (sur les plans payants) l'adresse email où on envoie les mises à jour. On ne demande pas ta carte sur la vérif gratuite. On ne vend pas de données. On ne partage pas les infos de ton compte avec d'autres clients.

Le détail complet de ce qu'on collecte, combien de temps on le garde et comment demander la suppression vit dans la politique de confidentialité.

Ce qu'on ne fait pas encore

Être honnête sur les trous compte autant que lister les pratiques. Voici ce qu'on n'a pas aujourd'hui :

• Certification SOC 2. On suit les pratiques qu'un audit SOC 2 cherche, mais on n'est pas encore certifié. On prévoit de viser SOC 2 Type II au fur et à mesure qu'on grandit.
• Programme de bug bounty formel. On ne fait pas de bounty payée pour l'instant. On accepte et on répond aux rapports de vulnérabilité à [email protected] (voir plus bas).
• Questionnaires de sécurité personnalisés pour les achats entreprise. On se concentre sur les petits commerces, pas sur les cycles d'achat entreprise. Si tu as besoin d'une revue de sécurité poussée pour une grande organisation, Kodo n'est pas encore le bon choix.
• Rapports de tests d'intrusion à la demande. On fait des revues de sécurité internes à chaque sortie majeure. Les tests d'intrusion par un tiers sont sur la feuille de route.

Signaler une vulnérabilité

Si tu penses avoir trouvé un problème de sécurité dans Kodo, écris à [email protected]. Inclus les étapes pour reproduire, l'impact que tu penses que ça a et toute preuve de concept que tu es à l'aise de partager. On répond dans les 5 jours ouvrés, en général dans 1.

On n'engagera pas de poursuites contre la recherche en sécurité de bonne foi, tant que tu n'accèdes pas aux données utilisateur au-delà de ce qu'il faut pour prouver le problème, que tu ne dégrades pas le service pour les autres utilisateurs et que tu nous donnes une fenêtre raisonnable pour corriger le problème avant toute divulgation publique.

Dernière mise à jour : 28 mai 2026. Kodo est une petite équipe. Cette page décrit nos pratiques actuelles, pas une certification. On la met à jour au fur et à mesure que le produit évolue.