Audit de sécurité vibe coding : du code IA sûr en production
Avec Lovable, Cursor ou Claude Code, une application voit le jour en quelques jours. Personne ne vérifie sa sécurité. Souvent, chaque visiteur voit les données. Avant la mise en production, nous vérifions code, base de données, application en ligne et protection des données. Après cinq ou dix jours ouvrables, vous recevez un rapport avec des correctifs pour votre outil.
Prix fixe convenu dès CHF 3'900Correctifs sous forme de prompt ou de diff de codeRapport dès 5 jours ouvrables
Gratuit et sans engagement · 30 minutes · confidentiel sous NDA · un accès en lecture et des comptes de test suffisent
Droit et technique dans un seul mandat : revue de code, test RLS et checklist de lancement protection des données dans un seul rapport.
Pour fondateurs, PME, agences et investisseurs
Rapport dès 5 jours ouvrables
Launch Check 5, Go-Live Review 10 jours ouvrables
RLS, secrets, auth vérifiés à la main
OWASP Top 10:2025, au-delà du scanner
Dr. iur., LL.M., CIPP/E
Check de lancement protection des données selon LPD et RGPD
Confidentiel, audit réalisé en Suisse
NDA, secret professionnel, aucune copie de votre code chez des tiers
Direction technique de ce mandat
Oliver Stutz
Co-Founder · InfoSec & Cybersecurity Expert · Bachelor of IT (Bond University)
Oliver Stutz est co-fondateur et dirige le centre de développement SIDD pour la sécurité technique de l'information et la sécurité cloud. Il développe lui-même avec l'IA générative. Son équipe lit votre code, teste l'application en ligne et rédige les correctifs. S'y ajoute l'équipe du Dr. Dominic Staiger, LL.M., Dr. iur., CIPP/E, Attorney at Law (New York) et Solicitor (UK). Elle traite la checklist de lancement protection des données.
Qu'est-ce qu'un audit de sécurité pour projets issus du vibe coding ?
Définition succincte
L'audit de sécurité vibe coding vérifie la sécurité et la protection des données d'applications écrites par une IA, selon la LPD et le RGPD. Nous vérifions le code, la configuration et l'application en ligne. La référence est l'OWASP Top 10:2025, la liste des failles web les plus fréquentes. Pour chaque constat, le rapport indique la gravité, les étapes de reproduction et un correctif. On parle aussi d'audit de vibe code ou de revue de code IA.
Andrej Karpathy a forgé le terme vibe coding en février 2025 : on suit l'IA et on ne lit plus le code. Le code naît en quelques heures et passe les tests. Mais personne ne vérifie sa sécurité.
Le navigateur dialogue ici souvent directement avec la base de données. Chaque visiteur voit la clé publique nécessaire. La seule protection est la politique RLS : une règle qui fixe qui peut voir quelle ligne de table. Si elle manque ou est erronée, n'importe qui peut lire et écrire des données. L'audit répond donc à trois questions : Qui a le droit de faire quoi ? Où se trouvent les clés ? Qu'advient-il des données personnelles ?
Avez-vous besoin d'un audit de sécurité vibe coding ?
L'audit se justifie pour toute application IA avec de vraies données personnelles, des paiements ou des utilisateurs externes. Dès le 09.12.2026, la nouvelle responsabilité du fait des produits (directive (UE) 2024/2853) couvre aussi les logiciels nouvellement mis sur le marché. Après le lancement, chaque constat coûte plus cher : changer les clés, informer les clients, le cas échéant annoncer la violation.
1
Mise en production avec données clients, connexion ou paiement : dès le premier enregistrement de données personnelles, la LPD et l'OPDo s'appliquent. Avant le lancement, vous clarifiez : des utilisateurs tiers peuvent-ils lire des données ? La clé de service, clé maîtresse de la base de données, se trouve-t-elle dans le code du navigateur ?
2
Un client grand compte, un investisseur ou le client de votre agence pose la question : un questionnaire de sécurité ou une due diligence exige un auditeur nommé avec une qualification juridique. Le scan de la plateforme n'est qu'un début.
3
Un outil interne avec des données RH ou financières : des collaborateurs le construisent sans l'IT. En mai 2026, RedAccess a recensé environ 380'000 assets de vibe coding accessibles publiquement, dont quelque 5'000 sans protection par login. L'inventaire et les règles relèvent de l'AI Governance Check.
4
Un incident ou une alerte : un chercheur en sécurité ou Supabase signale des tables ouvertes. Nous clarifions alors : jusqu'où l'accès est-il allé ? Une annonce au PFPDT ou à une autorité de contrôle de l'UE est-elle due ?
5
L'application a des fonctions d'IA : la clé d'IA se trouve souvent dans le navigateur, sans plafond de coûts. Depuis le 02.08.2026, le règlement IA exige qu'un chatbot destiné à des utilisateurs de l'UE indique qu'il est une IA. Nous le vérifions aussi. Pour les agents en production, nous recommandons l'audit AI Security.
Ce qui nous rend uniques
Trois disciplines pour du code écrit par une IA
Nos ingénieurs vérifient le code et nos juristes qualifient chaque constat sur le plan juridique. Ni un pur cabinet d'avocats ni un cabinet de conseil classique ne peuvent offrir cette combinaison. Le rapport montre les correctifs au développeur et indique à la direction si elle peut mettre en production.
01
Une expertise juridique approfondie
C'est le rôle de l'équipe du Dr. Dominic Staiger, LL.M., Dr. iur., CIPP/E, Attorney at Law (New York) et Solicitor (UK). Elle vérifie sous sa responsabilité la déclaration de protection des données et un contrat de sous-traitance avec un prestataire, en général le fournisseur backend. Nous vérifions les autres contrats en régie. S'y ajoutent les données sur des serveurs hors de Suisse et le processus en cas de violation de données.
02
Nos propres ingénieurs logiciels
SIDD développe la Plateforme Priverion dans son propre centre de développement. Nos ingénieurs connaissent donc les briques des projets Lovable ou Cursor comme React, Postgres et Stripe. Ils lisent eux-mêmes les politiques RLS et le code de connexion.
03
Développement d'IA en interne
Nous développons nos propres systèmes LLM et construisons nous-mêmes avec des agents de codage. Nous connaissons donc leurs raccourcis sous la pression du temps : clé de service côté navigateur, politique sur true, validation manquante.
Que vérifions-nous ?
Nous nous concentrons sur les frontières de confiance. Là, les données passent entre navigateur, serveur et services tiers. C'est là que le code IA échoue le plus souvent.
Threat Model light (STRIDE) : une page nomme assets, rôles, cas d'abus et frontières de confiance. Il en résulte la matrice de test : qui a le droit de faire quoi ?
Revue de code manuelle plus SAST : avec le SAST, un outil comme Semgrep recherche automatiquement les erreurs dans le code source. Nous lisons à la main connexion, autorisation, accès aux données, téléversements et paiement.
Secrets et clés : gitleaks cherche des clés secrètes et des mots de passe dans l'historique Git et le code du navigateur. Nous cherchons surtout les clés de service, qui contournent toute règle de la base de données. Vous remplacez les clés trouvées le jour même.
Autorisation et row-level security : nous lisons chaque politique RLS, règle Firestore et Edge Function. Dans le Go-Live Review, nous testons de préférence sur le staging avec des comptes de test : anonyme, utilisateur A, utilisateur B, admin. Nous cherchons l'escalade de privilèges, les IDOR et le mass assignment. Avec un IDOR, un numéro modifié affiche les enregistrements d'autrui. Avec le mass assignment, un utilisateur modifie par exemple son rôle ou son solde.
Dépendances et SBOM : le SBOM liste tous les paquets logiciels intégrés. Nous vérifions pour chaque paquet les failles connues et s'il existe vraiment. Selon Spracklen et al., USENIX Security 2025 , jusqu'à un paquet sur cinq proposé par l'IA était inventé en 2025. Churilov, arXiv 2605.17062 en trouve encore plusieurs pour cent avec les modèles actuels. Les attaquants enregistrent ces noms : c'est le slopsquatting.
Configuration du backend et de l'hébergement : le backend est le serveur avec la base de données et la connexion. Chez Supabase, nous vérifions la RLS sur chaque table, les politiques de stockage, les Edge Functions et l'authentification. Chez Firebase, nous vérifions les règles Firestore et Storage ainsi qu'App Check. Pour l'hébergement, nous vérifions les variables à préfixe client, la protection des previews, les en-têtes de sécurité et le CORS.
Test dynamique de l'application déployée (Go-Live Review) : nous testons l'application en ligne par DAST et à la main selon l'OWASP Web Security Testing Guide. Nous couvrons l'OWASP Top 10:2025, dont l'injection, le XSS, le CSRF et le rate limiting. S'y ajoutent les signatures de webhooks, le contournement de paywall et la manipulation de prix.
Fonctions d'IA, le cas échéant : nous vérifions clés d'IA, plafonds de coûts et prompt injection selon l'OWASP Top 10 for LLM Applications 2025. Pour les agents avec accès à des outils, nous recommandons l'audit AI Security.
Checklist de lancement protection des données : dans le Launch Check, nous dérivons du code la cartographie des données et la liste des sous-traitants. Dans le Go-Live Review, l'équipe du Dr. Staiger vérifie aussi la déclaration de protection des données et les mentions légales. Elle vérifie en profondeur un contrat de sous-traitance (art. 9 LPD ou art. 28 RGPD), souvent celui du fournisseur backend. Nous vérifions les autres contrats en régie. S'y ajoute la communication de données à l'étranger selon l'art. 16 s. LPD ou les art. 44 ss RGPD. Il s'agit de serveurs hors de Suisse. De même le processus de notification (art. 24 LPD) et le déclencheur d'AIPD (art. 22 LPD). Pour les fonctions d'IA destinées à des utilisateurs de l'UE, nous vérifions la transparence selon l'art. 50 du règlement IA.
Correction et re-test : vous recevez chaque correctif sous forme de prompt pour votre outil ou de diff de code. La direction reçoit une recommandation de mise en production d'une page. Sur demande, nous livrons sur offre préalable des pull requests pour les constats Critical et High. Le re-test confirme la correction et est consigné à titre de preuve dans la Plateforme Priverion.
Ne sont pas inclus un SOC managé, une astreinte de réponse aux incidents et la mise en place d'un pipeline DevSecOps. Il n'existe pas de garantie de conformité. Quand votre équipe dépasse le stade du MVP, l'étape suivante est la revue d'architecture de sécurité.
Constats typiques dans les apps issues du vibe coding
Nous trouvons ces failles sur toutes les plateformes, classées par fréquence et par dommage :
1. Autorisation absente ou erronée : des tables n'ont pas de politique RLS ou une politique qui laisse passer tout le monde. Des fonctions serverless utilisent la clé de service sans vérifier elles-mêmes l'habilitation.
2. Secrets dans le code du navigateur ou dans l'historique Git : par exemple la clé de service Supabase, les clés Stripe ou LLM.
3. Réglages par défaut non sûrs du backend et de l'hébergement : buckets de stockage et déploiements de preview publics. Google indexe des applications de production sans connexion.
4. IDOR et BOLA dans le code CRUD généré : accès aux enregistrements d'autrui par ID.
5. Validation des entrées absente : cela ouvre la porte au XSS et à l'injection. Les téléversements arrivent sans contrôle dans des buckets publics.
6. Pas de rate limiting : inscriptions, codes à usage unique et appels d'IA sont possibles sans limite.
7. Dépendances inventées ou obsolètes : des paquets n'existent pas ou ne sont plus maintenus depuis des années.
8. Routes d'administration, de debug et de test en production : leurs messages d'erreur révèlent trop de détails.
9. Signatures de webhooks non vérifiées et paywalls uniquement dans le navigateur : l'application ne vérifie pas la signature Stripe et contrôle le paiement seulement dans le navigateur.
10. Pas de journalisation, pas de sauvegardes, pas de séparation des environnements : le log contient des données personnelles ou manque totalement. Les sauvegardes n'ont jamais été restaurées à titre de test. Souvent, un agent d'IA a accès à la production.
Il manque en outre souvent le contrat de sous-traitance avec Supabase, Vercel ou OpenAI. Manquent aussi souvent une déclaration de protection des données adaptée et un processus de notification des violations.
Les chiffres qui justifient l'audit
Trois chiffres datés et vérifiables tirés d'études depuis 2025 :
45 %
des exemples de code générés par IA ont choisi la variante non sûre. Le test portait sur 80 tâches et plus de 100 modèles de langage. Les modèles récents n'ont pas fait mieux. Source : Veracode GenAI Code Security Report , 30.07.2025.
16'326
bases de données Supabase montraient leur table d'utilisateurs à quiconque disposait de la clé publique du code du navigateur. Plus de la moitié contenaient des données personnelles. Source : UpGuard , 25.09.2026. Le remède : la RLS sur chaque table.
91 %
de 200 applications déployées, construites avec Claude Code et Lovable, présentaient au moins une vulnérabilité. Deux tiers des 1'186 constats étaient Critical ou High. Source : préprint arXiv 2606.23130, version du 14.09.2026.
Forfaits et prix
Tous les prix s'entendent hors TVA. Nous convenons du prix fixe après un premier entretien de cadrage. Les prix d'entrée couvrent une application avec un dépôt et un backend, le serveur avec base de données et connexion.
Launch Check
Prix fixe convenu dès CHF 3'900 1 app · rapport en 5 jours ouvrables
Pour une application jusqu'à environ 10'000 lignes de code IA. Adapté avant le premier utilisateur externe, pour les outils internes sans données sensibles et pour la réception d'une livraison d'agence.
Connexion, sessions et toutes les règles d'accès comme les politiques RLS
Secrets comme les clés dans le code du navigateur et l'historique Git, droits de stockage, Edge Functions et webhooks Stripe
Dépendances, y compris les paquets inventés par l'IA
A01 à A03 de l'OWASP Top 10:2025, pour les fonctions d'IA aussi la prompt injection
Prix fixe convenu dès CHF 6'900 recommandé · rapport en 10 jours ouvrables
Pour les applications avec données personnelles ou paiements, en usage d'entreprise ou avant la réception par un client. Tout le Launch Check, plus des tests avec connexion et l'infrastructure. L'équipe du Dr. Staiger qualifie la checklist protection des données complète. Le prix d'entrée couvre jusqu'à environ 25'000 lignes de code IA et 25 endpoints ou tables. Nous clarifions deux backends, un client mobile ou un périmètre plus large lors du cadrage.
Matrice d'autorisation avec un compte de test par rôle contre le staging ou l'API live. Nous cherchons les IDOR, c'est-à-dire l'accès aux données d'autrui en changeant un numéro. S'y ajoutent séparation des tenants et escalade de rôles.
Paiements avec signatures de webhooks Stripe et manipulation de prix, téléversement de fichiers, flux e-mail et OTP
Infrastructure : réglages d'hébergement, sauvegardes avec test de restauration, journalisation, séparation des environnements et contact incident
Session de threat model de 45 minutes avec votre équipe : qui pourrait attaquer quoi ?
Contrôle d'un contrat de sous-traitance, les autres en régie. Communication à l'étranger vers des serveurs hors de Suisse. Déclaration de protection des données, mentions légales et processus de notification des violations. Qualification juridique par l'équipe du Dr. Staiger.
Correctifs sous forme de code ou de prompt, dossier de preuves dans la Plateforme Priverion, un re-test des constats Critical et High dans les 60 jours
Prix fixe convenu dès CHF 10'500 3–5 apps ou 1 app en profondeur
Pour les investisseurs avant le tour seed, les agences et les groupes avec plusieurs applications non validées par l'IT. Durée de trois à quatre semaines.
Tout le Go-Live Review, pour les portefeuilles sur l'application la plus risquée
Synthèse d'architecture comme base pour la revue d'architecture de sécurité
Licences et propriété intellectuelle du code IA et des dépendances
Carte des lieux de données et des sous-traitants ultérieurs, transparence IA pour les chatbots avec utilisateurs de l'UE
Responsabilité du fait des produits selon la directive (UE) 2024/2853 dès le 09.12.2026. S'y ajoute le CRA pour les produits comportant des éléments numériques dans l'UE.
Mémo de risques, sur demande présentation devant la direction ou les investisseurs
Quel forfait convient à votre application, nous le clarifions lors du premier entretien en 30 minutes.
Déroulement de l'audit en cinq ou dix jours ouvrables
Les jours valent pour le Launch Check. Dans le Go-Live Review, le rapport suit après dix jours ouvrables. Vous n'avez besoin ni d'installation ni de votre propre développeur, seulement d'une personne de contact.
Jour 0 : cadrage en 30 minutes
Vous nous montrez l'application, ses données et ses groupes d'utilisateurs. Nous convenons du prix fixe après un premier entretien de cadrage. Vous donnez un accès en lecture au dépôt, l'URL de l'application en ligne et un compte de test par rôle. Pour le backend, une adhésion temporaire avec un minimum de droits suffit.
Jour 1 : Threat Model light et scans
Nous recensons les données à protéger, les rôles et les frontières de confiance. Les données y passent entre d'autres mains, par exemple vers un service d'IA. Nous en tirons la matrice de test : quel rôle peut faire quoi ? Trois scans en parallèle : SAST pour les erreurs de code, scan de secrets Git et SBOM comme liste des paquets.
Jours 2–3 : revue manuelle et tests
Nous lisons à la main le code de connexion, d'accès aux données, de paiement et d'IA. Nous vérifions une à une chaque politique RLS. Dans le Go-Live Review, nous testons la matrice des rôles avec les comptes de test. Nous le faisons contre le staging ou après accord contre l'application en ligne. S'y ajoute un test dynamique selon l'OWASP WSTG.
Jours 3–4 : contrôle protection des données
Du code, nous tirons une cartographie des données et une liste des prestataires. Dans le Launch Check, le quick check protection des données s'arrête là. Dans le Go-Live Review, l'équipe du Dr. Staiger vérifie la checklist protection des données complète. Cela comprend le contrôle d'un contrat de sous-traitance, les autres en régie.
Jour 5 : rapport et débriefing
Chaque constat reçoit un correctif sous forme de modification de code ou de prompt pour votre outil. La direction reçoit une recommandation de mise en production d'une page. Lors du débriefing, nous clarifions l'ordre et les responsables.
Dans les 30 à 60 jours : re-test et preuve
Nous revérifions les constats Critical et High corrigés et répétons les scans. Nous déposons le résultat comme dossier de preuves dans la Plateforme Priverion . Sur demande, nous livrons une suite de tests RLS pour votre CI. Ainsi, la prochaine table sans politique est repérée.
Pourquoi SIDD
Ce que les trois disciplines apportent à votre application :
Nous construisons nous-mêmes avec l'IA
Nous travaillons chaque jour avec des agents de codage. Une table Supabase créée par migration démarre par exemple sans politique RLS. Rien ne règle alors qui voit quelle ligne. Nous vérifions ces points en premier.
Droits d'accès vérifiés à la main
Nous vérifions à la main si chaque politique correspond à vos rôles. Dans le Go-Live Review, nous testons chaque rôle avec des comptes de test.
Décision de mise en production avec base juridique
Chaque constat indique l'obligation LPD ou RGPD qu'il touche. La direction sait ainsi si elle peut mettre en production.
Des correctifs que vous pouvez coller
Les développeurs reprennent le diff de code ligne par ligne. Sans développeur, un prompt pour Lovable ou Cursor suffit.
Confidentiel, audit réalisé en Suisse
L'analyse tourne sur notre infrastructure en Suisse, sans copie de votre code chez des tiers. Nous n'utilisons des outils d'IA qu'avec votre accord et sans utilisation pour l'entraînement. Pour la qualification juridique sous la responsabilité du Dr. Staiger, le secret de l'avocat (art. 321 CP) s'applique aussi.
Une preuve auditable
Constats, état des corrections et re-test sont consignés de façon auditable dans la Plateforme Priverion. Vous présentez cette preuve aux clients, aux investisseurs et à l'auditeur ISO 27001. Si nous écrivons nous-mêmes des correctifs, le rapport l'indique. Si un client exige un contrôle indépendant, nous séparons les mandats.
Scanner, audit et test d'intrusion : comparaison
Un scanner signale les schémas connus. Un test d'intrusion attaque un système mature depuis l'extérieur. L'audit se situe entre les deux et cherche les erreurs typiques du code généré par IA.
Scanner automatique
Audit de sécurité vibe coding
Test d'intrusion classique
Objet : code ou application en ligne, schémas connus
Objet : code, configuration du backend et application en ligne
Objet : application en ligne, réseau, API
Logique RLS : trouve la RLS manquante, pas les règles fausses
Logique RLS : lit chaque politique, la teste par rôle
Logique RLS : teste seulement de l'extérieur
Secrets : code actuel, historique en partie
Secrets : tout l'historique Git plus le code du navigateur
Secrets : code du navigateur, historique Git rarement
Protection des données : contrats, communication à l'étranger, annonce des violations non vérifiés
Protection des données : checklist de lancement par des juristes, contrôle d'un contrat de sous-traitance
Protection des données : hors du test
Correctifs : indications générales
Correctifs : diff de code ou prompt par constat, re-test inclus
Correctifs : recommandation de correction, re-test sur accord
Durée : quelques minutes
Durée : 5 à 10 jours ouvrables
Durée : 3 à 10 jours-testeur sur 2 à 4 semaines, forfait d'entrée 5 jours
Prix : gratuit ou crédits de plateforme
Prix : prix fixe convenu dès CHF 3'900
Prix : forfait d'entrée dès CHF 1'490, projets web app CHF 12'000–25'000
Convient pour : chaque modification du code, comme alerte précoce
Convient pour : mise en production, livraison, investisseur, shadow IT
Convient pour : systèmes matures, certification, FINMA
Pourquoi nous travaillons avec LexCommand, notre propre IA juridique suisse
LexCommand est notre IA juridique interne, adossée à des citations, pour le droit de la Suisse, de l'Allemagne, de l'Autriche et de l'UE. Développée et exploitée de manière souveraine en Suisse par Priverion GmbH, l'entreprise derrière SIDD. Nous ne faisons pas que prôner la souveraineté des données et la traçabilité, nous les avons intégrées dans notre propre outil, en complément de la Plateforme Priverion.
01
Souverain en Suisse
L'IA fonctionne en auto-hébergement sur une infrastructure suisse, sans LLM cloud externes. En tant qu'entreprise suisse indépendante sans société mère étrangère, nous traitons vos documents dans un environnement que nous maîtrisons.
02
Pas de citation, pas d'affirmation
Chaque affirmation juridique renvoie à une source primaire consultable, sinon elle n'apparaît pas. Nos recommandations deviennent ainsi vérifiables et auditables, au lieu de seulement paraître plausibles.
03
De l'effort au jugement
LexCommand prend en charge la recherche, le recoupement et le sourcing. Cela réduit les délais et libère nos conseillers seniors pour le jugement et l'échange avec le client, sans rien céder sur la rigueur.
04
Trois disciplines, une seule vue
Nous examinons la protection des données, la sécurité de l'information et la sécurité de l'IA sur une base de sources partagée avec un crosswalk de référentiels. Vous voyez ainsi les obligations qui se recoupent dans une vue consolidée, au lieu de trois analyses isolées.
Concrètement pour cet audit : LexCommand étaye chaque constat avec l'obligation de la LPD, du RGPD ou du règlement IA. Il rédige la liste des sous-traitants et le processus de notification avec sources.
Déterministe dans le temps (à la date du jour ou à toute date de référence), avec cloisonnement des juridictions (CH/DE/AT/EU) et un vérificateur de citations à la fin de chaque réponse.
Questions fréquentes
Combien coûte l'audit de sécurité pour projets issus du vibe coding ?
Launch Check : prix fixe convenu dès CHF 3'900, rapport en cinq jours ouvrables. Go-Live Review : prix fixe convenu dès CHF 6'900, rapport en dix jours ouvrables. Due Diligence et portefeuille : prix fixe convenu dès CHF 10'500, tous les prix hors TVA. Nous convenons du prix fixe après un premier entretien de cadrage.
Avez-vous besoin du code source, et quelles plateformes vérifiez-vous ?
Il nous faut un accès en lecture au dépôt, l'URL en ligne et un compte de test par rôle. Pour le backend, une adhésion temporaire ou un export du schéma, des politiques et des règles suffit. Nous vérifions des applications issues de Lovable, Bolt, Replit, v0, Base44, Cursor, Windsurf, Claude Code et GitHub Copilot. S'y ajoutent des backends comme Supabase, Lovable Cloud ou Firebase, des hébergeurs comme Vercel ou Netlify et d'autres stacks après accord.
Nous n'avons pas de développeur. Qui corrige les constats ?
Chaque constat est livré avec un correctif pour votre outil : un prompt ou un diff de code, ligne par ligne. Nous corrigeons sur demande les constats critiques par pull request, avec un accès en écriture spécifique et une offre préalable en régie. Un re-test confirme et documente ensuite la correction.
En quoi cela diffère-t-il du test d'intrusion et de l'audit AI Security ?
Notre offre de test d'intrusion attaque l'application uniquement de l'extérieur, dès CHF 1'490 avec rapport en cinq jours. Les projets de trois à dix jours-testeur sur deux à quatre semaines se justifient avec des clients grands comptes et une infrastructure propre. Le Launch Check coûte plus, car il vérifie aussi le code, l'historique Git, chaque politique RLS, la protection des données et un éventuel chatbot. AI Security teste le système d'IA lui-même dès CHF 8'000 par application et se justifie pour les agents en production.
Lovable propose un scanner et un pentest. Cela ne suffit-il pas ?
Les deux sont un bon début et devraient tourner après chaque release majeure. Le scanner ne voit pas si une politique convient à vos rôles et à vos flux de données. Aucun outil de plateforme ne vérifie les contrats avec les sous-traitants, la déclaration de protection des données ou le processus de notification. L'audit s'appuie sur le scan et donne aux clients grands comptes et aux investisseurs un second avis d'un auditeur nommé.
Testez-vous sur notre production ? Cela met-il l'exploitation en danger ?
Nous testons de préférence sur un environnement de test, en production uniquement avec nos propres comptes et données de test. Nous n'envoyons pas de payloads destructifs et suivons des rules of engagement convenues par écrit. Nous vérifions les paiements en mode test Stripe et supprimons ensuite nos données de test. Le Launch Check n'attaque de toute façon pas l'application et lit seulement le code, la configuration et les secrets, comme les mots de passe.
Avons-nous seulement le droit de mettre en production avec des données clients ?
Oui, dès que la sécurité des données, la déclaration de protection des données, les contrats avec les prestataires et le processus de notification sont en place (art. 7–9, 19 et 24 LPD, art. 1–6 OPDo). Qui ignore intentionnellement les exigences minimales de l'OPDo risque, sur plainte, une amende personnelle jusqu'à CHF 250'000 (art. 61 let. c LPD). La checklist de lancement indique les points ouverts, avec la liste des sous-traitants et le contrôle d'un contrat de sous-traitance, les autres en régie. Ensuite, le mandat de conseiller externe à la protection des données ou le projet conformité LPD prend le relais.
Que se passe-t-il si des constats sont critiques ?
Les constats critiques, nous les signalons immédiatement avec un correctif, avant même le rapport. Vous corrigez ainsi le jour même des tables ouvertes ou une clé maîtresse dans le code du navigateur. Si des données personnelles étaient effectivement accessibles, l'équipe du Dr. Staiger examine l'obligation d'annonce. L'annonce irait au PFPDT (art. 24 LPD) ou à une autorité de contrôle de l'UE (art. 33 RGPD, 72 heures).
Et après le lancement ?
Chaque release faite avec l'IA peut ajouter des tables sans politique, des endpoints et des dépendances. Après des changements importants, nous recommandons un nouveau Launch Check. Si l'application devient un produit pour grands comptes, la revue d'architecture de sécuritésuit : prix fixe convenu dès CHF 6'900. Elle livre une architecture cible et un modèle de menaces : qui pourrait attaquer quoi. Pour les fournisseurs SaaS s'y ajoutent les contrats avec les sous-traitants .
Cette page ne remplace pas un conseil juridique au cas par cas.
Savoir ce qui reste ouvert avant la mise en production
Nous convenons du prix fixe après un premier entretien de cadrage. Vous recevez votre rapport dès cinq jours ouvrables. Vous connaissez ensuite chaque faille ouverte et disposez d'une preuve pour vos clients et investisseurs.
