Centre de confiance

Registre des sous-traitants

Accord de sous-traitance (DPA)

Localisation des données

Réversibilité et sortie

Intelligence artificielle

Inventaire des données par connecteur

Notre propre évaluation ReCyF

Nous conduisons sur notre propre structure le diagnostic ReCyF que nous demandons à nos clients de mener — les vingt objectifs, dans le périmètre d'une entité essentielle, et non les quinze auxquels notre taille nous permettrait de nous limiter. Nous sommes sous les seuils de taille de la directive NIS 2 et ne sommes donc pas une entité réglementée : la démarche est volontaire. Elle s'accompagne d'une politique de sécurité, d'une analyse de risque, d'un plan de continuité et d'un comité de sécurité trimestriel.

Mesures de sécurité

Chaque ligne ci-dessous décrit le code qui tourne en production, et chacune est tenue par un test automatisé qui échoue si le code cesse d'en être la description. Les en-têtes, vous pouvez les vérifier vous-même, depuis votre navigateur, sans nous demander la permission.

• —En-têtes de sécurité en production : HSTS d'un an (max-age=31536000, includeSubDomains), refus d'intégration de nos pages dans un autre site (frame-ancestors « none » et X-Frame-Options : DENY), nosniff, et une Permissions-Policy qui refuse la caméra, le microphone, la géolocalisation, le paiement et l'USB — que la plateforme n'utilise jamais.
• —Une politique de sécurité du contenu qui restreint les origines : base-uri et form-action limités au site, object-src à « none », et un connect-src limité au site et à notre prestataire de paiement — un script ne peut donc pas ouvrir de connexion vers un domaine arbitraire. Elle autorise en revanche les scripts en ligne, dont le rendu de Next.js dépend, et les images depuis n'importe quel domaine HTTPS : ce n'est donc ni une protection contre l'injection de script, ni une barrière étanche à l'exfiltration, et nous préférons l'écrire plutôt que de laisser le mot « stricte » le suggérer.
• —Mots de passe hachés avec argon2id, l'algorithme recommandé aujourd'hui.
• —Double authentification : application d'authentification (TOTP, RFC 6238) ou code à usage unique envoyé par e-mail, au choix de chaque membre, avec des codes de récupération remis une seule fois à l'enrôlement. Elle est obligatoire par défaut pour toute agence créée depuis le 2026-09-28 ; pour celles qui existaient avant, c'est un réglage à activer, parce que l'imposer rétroactivement aurait enfermé tous leurs membres dans un écran d'enrôlement du jour au lendemain. Là où elle s'applique, elle s'applique à toute l'agence et non aux seuls volontaires : tant qu'un membre n'a pas enrôlé son facteur, sa session n'atteint rien d'autre que l'écran d'enrôlement.
• —Identifiants des connecteurs chiffrés en base avec AES-256-GCM.
• —Les connecteurs qui lisent vos outils sont en lecture seule, et le refus est appliqué au niveau du transport, non laissé au bon vouloir de chaque intégration : hormis s'authentifier et fermer leur propre session, ils n'écrivent rien. La seule écriture sortante du produit est le ticket que vous poussez vous-même vers votre PSA ou votre RMM, décrite à l'article 8 de l'accord de sous-traitance.
• —Cloisonnement entre agences vérifié par 23 tests automatisés rejoués à chaque modification du code : une agence qui tente de lire, de modifier ou de supprimer les données d'une autre reçoit « introuvable », et l'export RGPD ne contient aucune ligne appartenant à un autre client.
• —Limitation de débit sur toute l'API, avec des compteurs plus stricts encore sur les pages d'authentification.
• —Journal d'audit exportable en CSV.
• —Sauvegardes automatiques toutes les 24 heures, conservées 30 jours. La restauration a été vérifiée de bout en bout le 2026-09-16 : instance restaurée et prête en 4,5 minutes, 53 tables comparées à la production, et les 13 tables non vides retrouvées avec des comptes de lignes identiques. Rien ne planifie ce test : la date ci-dessus est celle du dernier, pas la promesse d'un rythme.
• —Chaque modification passe l'intégration continue avant d'atteindre la production : typage, lint, audit des dépendances, parité des traductions et la suite de tests, dont les 23 tests de cloisonnement ci-dessus. Un audit qui trouve une faille critique arrête la mise en production au lieu de l'assortir d'un avertissement. Dependabot surveille les dépendances en continu : le 2026-09-16, 2 failles critiques d'exécution de code à distance ont été corrigées le jour de leur signalement. Chaque image porte l'empreinte du commit qui l'a produite, donc toute version mise en ligne peut être retrouvée et rejouée à l'identique.
• —Aucune mesure d'audience ni aucun suivi d'erreurs tiers, nulle part. L'audience est mesurée par Umami, auto-hébergée et servie depuis vigicap.fr : le script vient de notre domaine, pas de celui d'un tiers. Les erreurs sont collectées par GlitchTip, auto-hébergé lui aussi et joignable uniquement depuis le réseau privé Scaleway. Aucune donnée d'usage ni de diagnostic ne part vers un service américain de mesure d'audience ou de suivi d'erreurs. Le seul script tiers du produit est celui de Stripe, chargé sur l'écran de paiement de votre abonnement et nulle part ailleurs — nos pages publiques n'en chargent aucun. Nous le nommons plutôt que d'écrire « aucun script tiers », qui serait plus court et faux.
• —En cas de violation de données à caractère personnel, notification sous 48 heures. C'est un engagement contractuel, plus court que les 72 heures de l'article 33 du RGPD, précisément pour vous laisser le temps d'y notifier l'autorité.

Vérifier nos en-têtes vous-mêmeVoir l'état des services en directSignaler une failleFiche sécurité fournisseur

Qui sommes-nous

Une page de confiance qui ne dit pas qui la publie n'en est pas une. Ces éléments viennent du registre et s'y vérifient.

• NEXTLAB SAS
• SIREN 108 181 421
• 2 avenue d'Iéna, Résidence Les Jardins de Chaillot, 75116 Paris
• Code d'identification participant (Commission européenne) : 861319164
• Contact : Laurent Bertière — contact@vigicap.fr