La liste de contrôle juridique avant le lancement
Avant de publier un site web ou une application, évaluez ces huit points : un inventaire honnête des données personnelles que vous collectez, une politique de confidentialité correspondant à cet inventaire, un consentement géré correctement pour le suivi, des conditions d'utilisation fonctionnelles, des contrôles réels des droits sur les données (suppression et exportation), des pages accessibles, une tarification claire et une procédure d'annulation si vous facturez, et une transparence appropriée pour les fonctionnalités d'IA destinées aux utilisateurs. Rien de tout cela ne nécessite un avocat pour commencer. Votre développeur IA peut vous aider à mettre en place les contrôles, mais la finalisation dépend des intégrations, des décisions commerciales et des tests. L'ordre importe plus que tout autre élément sur cette page. L'échec juridique le plus courant dans les produits « vibe-coded » n'est pas une politique manquante ; c'est une politique qui contredit le code. L'IA rédige volontiers une belle politique de confidentialité mentionnant des services que vous n'utilisez pas et omettant le script d'analyse qu'elle a ajouté il y a trois prompts. Donc : auditez d'abord, puis rédigez la politique à partir de l'audit. Jamais l'inverse. Commencez par votre lieu d'implantation, les marchés que vous ciblez et ce que fait réellement votre produit. Les lois étrangères sur la confidentialité et la protection des consommateurs peuvent s'appliquer, mais le simple fait qu'un site soit accessible depuis un pays ne constitue pas en soi un déclencheur juridique universel. Par exemple, le champ d'application territorial du RGPD inclut le traitement dans le contexte d'un établissement dans l'UE, ou celui d'une entreprise hors UE offrant des biens ou des services à des personnes dans l'UE ou surveillant leur comportement sur ce territoire. Évaluez chaque loi séparément. Ce guide couvre la couche quasi universelle, puis renvoie vers les analyses approfondies par pays pour les États-Unis, l'Union européenne et le Brésil.
Points clés à retenir
- Évaluez ensemble l'établissement, les marchés ciblés, le traitement, le secteur et les seuils. Une langue ou une visite fortuite depuis l'étranger ne constitue pas un test de juridiction complet.
- Auditez avant de rédiger. Demandez à votre constructeur d'inventorier chaque champ, cookie et tiers d'abord — une politique écrite par imagination est pire qu'une absence de politique, car il s'agit d'une fausse déclaration documentée.
- Les droits sur les données doivent être de la plomberie, pas de la prose. « Vous pouvez demander la suppression » n'est pas conforme si rien dans l'application ne peut réellement supprimer un compte.
- Le consentement est une question de timing : rien de non essentiel ne doit se charger avant que l'utilisateur ne choisisse. C'est un comportement de code, pas un design de bannière.
- L'accessibilité est désormais une exigence légale dans l'UE et un aimant à litiges aux États-Unis. Le WCAG 2.1 AA est le standard de travail presque partout.
- L'IA est un bon ingénieur de conformité et un mauvais conseiller en conformité. Utilisez-la pour construire les mécanismes ; utilisez un humain pour les décisions critiques.
Ceci n'est pas un conseil juridique
Ce guide est écrit pour les fondateurs et les petites équipes publiant leur premier produit, et il explique quelles sont les obligations courantes afin que vous puissiez poser de meilleures questions. Il s'agit d'informations générales, non de conseils juridiques, et il ne remplace pas un avocat qualifié dans votre juridiction. Les lois changent — les dates et les seuils indiqués ici ont été révisés en septembre 2026. Voir quand engager un avocat ci-dessous pour les situations où le faire vous-même est une très mauvaise idée.
Ce qui détermine les lois qui s'appliquent à vous
Cinq questions, par ordre d'importance sur votre réponse :
- Où l'entreprise est-elle établie, et qui cible-t-elle ou surveille-t-elle ? La simple accessibilité ne suffit pas pour le test de ciblage du RGPD. Examinez votre marketing, vos clients, votre couverture de livraison et votre surveillance comportementale.
- Que collectez-vous ? Un site vitrine peut quand même traiter des adresses IP via les logs d'hébergement, les intégrations et les analyses. Ajoutez un champ email et vous avez les devoirs d'un responsable de traitement. Ajoutez des données de santé, biométriques, de localisation précise, financières ou concernant des enfants et vous passez à un niveau beaucoup plus strict.
- Encaissez-vous de l'argent ? Les paiements entraînent le droit de la protection des consommateurs : transparence des prix, droits de remboursement et de rétractation, règles d'abonnement et d'annulation, enregistrement fiscal.
- Les utilisateurs créent-ils du contenu ou se parlent-ils entre eux ? Le contenu généré par les utilisateurs entraîne des devoirs de modération, des mécanismes de notification et de retrait, et des règles de responsabilité.
- Des mineurs pourraient-ils l'utiliser ? Pas « est-ce pour les enfants » — un enfant de 12 ans pourrait-il raisonnablement s'inscrire. Les règles pour les enfants sont les plus strictes, les moins indulgentes et les plus coûteuses en cas d'erreur.
Les seuils et exceptions sont spécifiques à chaque loi. Certaines lois étatiques sur la confidentialité utilisent des tests de volume ou de revenus ; d'autres règles dépendent de l'activité ou du type de données. Consultez le guide du pays concerné plutôt que de considérer la taille de l'entreprise comme une exemption universelle.
Les dix choses dont presque chaque produit a besoin
1. Une identité visible. Qui est légalement derrière cela ? Un nom d'entreprise, une méthode de contact réelle, et dans une grande partie de l'Europe, une adresse et un numéro d'enregistrement. Les sites commerciaux anonymes sont non conformes dans plusieurs pays et indignes de confiance dans tous.
2. Une politique de confidentialité qui correspond au code. Ce que vous collectez, pourquoi, combien de temps vous le conservez, avec qui vous le partagez, quels droits les utilisateurs ont, et comment vous joindre.
3. Un consentement géré au bon moment. Analyses, pixels, widgets de chat, vidéos intégrées, polices personnalisées chargées depuis un CDN tiers — tout cela peut définir des cookies ou fuiter des adresses IP avant que l'utilisateur n'ait accepté quoi que ce soit.
4. Des conditions d'utilisation. Le contrat : ce que le service fait, ce que les utilisateurs ne peuvent pas faire, le paiement et l'annulation, les limites de responsabilité, les tribunaux du pays qui tranchent les litiges. Le droit de la protection des consommateurs prime sur toute clause inéquitable que vous insérez ici, alors ne surchargez pas juridiquement.
5. Des droits sur les données opérationnels. Accès, correction, suppression, exportation et le droit de s'opposer au marketing. Construisez les boutons.
6. Les bases de la sécurité. Mots de passe hashés, secrets non présents dans le code côté client, routes d'administration réellement protégées, règles de base de données qui n'autorisent pas l'utilisateur A à lire les enregistrements de l'utilisateur B. Demandez explicitement à votre développeur — les applications « vibe-coded » sont livrées avec des règles de base de données permissives plus souvent que toute autre chose sur cette liste.
7. Accessibilité. Navigation au clavier, contraste des couleurs, étiquettes de formulaire, texte alternatif, titres sensés. WCAG 2.1 niveau AA est la norme de référence, et c'est désormais une exigence légale pour de nombreux services tournés vers l'UE.
8. Commerce honnête. Prix total incluant la taxe avant le bouton de paiement, dates de renouvellement indiquées dès le départ, annulation aussi facile que l'inscription, et un reçu.
9. Enfants. Si des mineurs peuvent raisonnablement y accéder, vous avez besoin d'un filtrage par âge et d'une posture de données différente — généralement pas de publicité comportementale, pas de profilage, et un consentement parental en dessous d'un seuil qui varie selon le pays.
10. Divulgation de l'IA. Si un utilisateur parle à un bot, génère du contenu ou est évalué par un modèle, dites-le. Les devoirs de divulgation dépendent du système, de l'utilisation et de la juridiction ; ne laissez pas entendre que le codage assisté par IA déclenche seul ces devoirs.
Ce que votre développeur IA peut et ne peut pas faire
Il est vraiment bon pour : inventorier son propre code, lister chaque appel tiers, construire une bannière de consentement qui bloque réellement les scripts, câbler les flux de suppression/exportation, effectuer une vérification d'accessibilité, ajouter du texte de divulgation, renforcer les règles de base de données et rédiger une politique à partir de faits que vous lui donnez.
Il échouera à : savoir dans quelle juridiction vous vous trouvez, connaître le nom de votre entité juridique ou vos périodes de conservation, juger si « l'intérêt légitime » s'applique, ou vous dire quand vous avez basculé dans un territoire réglementé. Il va aussi — et c'est le point dangereux — rédiger une politique confiante et professionnelle pleine de spécificités inventées si vous lui demandez d'« ajouter une politique de confidentialité ». Ce document est une déclaration publique sur votre entreprise. Traitez tout ce qu'il génère comme un brouillon avec des espaces réservés, pas comme un document juridique fini.
Deux choses qu'il ne peut pas faire du tout : signer un accord de traitement des données avec vos fournisseurs en votre nom, et prendre des responsabilités. Classez chaque fournisseur par son rôle réel : sous-traitant, responsable de traitement indépendant ou parfois responsable de traitement conjoint. Un sous-traitant a besoin des termes de traitement appropriés ; un fournisseur n'est pas automatiquement votre sous-traitant.
La séquence de prompts (exécutez-les dans l'ordre)
Vous pouvez les adapter pour Base44, Lovable, v0 ou tout constructeur basé sur le chat. Exécutez-les dans l'ordre — chacun dépend de la sortie du précédent.
1. Inventaire de ce que vous avez réellement
Audit this application and produce a DATA INVENTORY as a table. For every place personal data is collected, stored, or sent, list:
1. The field name and exactly where it is collected (page, form, component).
2. Why it exists, and whether any code in the app actually reads it.
3. Where it is stored (which table or collection) and any retention logic.
4. Every third party it reaches: analytics, error tracking, email, payments, maps, fonts, embeds, AI providers. Name the service and what data it receives.
5. Whether it is sensitive data: health, biometric, precise location, financial, government ID, data about children, or race/religion/political/sexual-orientation data.
Then list separately every cookie, every localStorage/sessionStorage key, every tracking script, and every asset loaded from a third-party domain.
Report only what exists in the code. If you are unsure whether something collects personal data, list it as UNKNOWN rather than guessing. Do not write a privacy policy yet.
2. Collectez moins
Using the data inventory above, propose a minimization pass. For each field, mark KEEP (and state the specific reason it is required), MAKE OPTIONAL, or REMOVE. Flag every field we collect but never read anywhere in the application. Do not change anything yet — give me the table and wait for my approval, then implement the approved changes one at a time.
3. Rédigez les pages juridiques à partir de l'inventaire
Create three pages — Privacy Policy, Terms of Service, and Cookie Policy — and link all three in the footer of every page and in the signup flow.
Rules:
- Base the Privacy Policy strictly on the data inventory you produced. Do not add categories of data we do not collect. Do not name services we do not use.
- Wherever a fact must come from me, insert a clearly marked placeholder such as [[LEGAL ENTITY NAME]], [[BUSINESS ADDRESS]], [[CONTACT EMAIL]], [[RETENTION PERIOD]], [[GOVERNING LAW]] — never invent one.
- Add a visible "Last updated" date to each page.
- Write in plain language a non-lawyer can read.
When you are done, list every placeholder you inserted, and list anything in these documents you are not confident about.
4. Faites en sorte que le consentement se comporte correctement
Implement consent for tracking with these rules, and treat them as behaviour, not design:
- No non-essential cookie, analytics script, advertising pixel, chat widget or third-party embed loads before the user makes a choice.
- "Accept all" and "Reject all" are equally prominent on the first screen — same size, same colour weight, same position priority — plus a "Manage preferences" option with granular categories.
- Nothing is pre-selected except strictly necessary cookies.
- The choice persists across pages and sessions, and can be changed at any time from a permanent link in the footer.
- Store each choice with a timestamp and the version of the consent text shown.
Then report: which scripts are now blocked before consent, and confirm that a fresh visit fires no analytics or advertising request until a choice is made.
5. Construisez de vrais droits sur les données
Add working user data controls — actual functionality, not policy text:
1. "Download my data": exports the approved scope of that user’s personal information in a machine-readable file, excluding other people’s data, secrets and privileged material. Verify identity and authorization server-side.
2. "Delete my account": deletes or irreversibly anonymizes the user's records, and before confirming, shows the user exactly what will be retained and why (for example invoices kept for tax law).
3. A way for users to correct their own profile data.
4. An internal log of each request with its date and outcome.
All three must be reachable in at most two clicks from account settings. Then tell me exactly which tables each action touches — and, importantly, what it does NOT reach: backups, logs, analytics, and any third-party service holding a copy. I need the gaps listed explicitly.
6. Verrouillez les failles de sécurité évidentes
Review this app for the security issues that create legal exposure, and report findings before fixing anything:
- Database rules: can any authenticated user read or write another user's records? Show me the rule for each table.
- Are any API keys, secrets or credentials present in client-side code or in the repository?
- Are admin routes and admin-only actions enforced on the server, or only hidden in the UI?
- Are passwords hashed, and are password reset and session expiry handled properly?
- Is any personal data written to logs or error tracking?
- Is real personal data present in seed, demo or test data?
List each finding with its severity and location. Then fix them one group at a time, starting with the database rules.
7. Effectuez un passage d'accessibilité
Audit the entire application against WCAG 2.1 Level AA and report the findings grouped by severity, with the file or component for each. Check at minimum: colour contrast, keyboard-only navigation and visible focus states, form labels and error messages, alt text on meaningful images, heading order, link text that makes sense out of context, and behaviour at 200% zoom and on small screens. Do not fix anything yet.
Ensuite, après l'avoir lu : Réparez les problèmes d'accessibilité critiques et sérieux, un groupe à la fois, en commençant par la navigation au clavier et les étiquettes de formulaire. Après chaque groupe, dites-moi ce qui a changé et ce qui reste en suspens.
8. Divulguez l'IA
Find every place in this app where AI generates or influences what the user sees or what happens to them: chat, recommendations, scoring or ranking, auto-replies, generated text or images, content moderation. For each one, tell me whether the user is currently told it is AI.
Then add a clear disclosure at the first point of interaction wherever it is missing, and add a section to the privacy policy stating which AI provider processes user input and what happens to that input. If you do not know whether inputs are retained or used for training by that provider, say so explicitly rather than guessing.
9. Gérez correctement les flux d'argent
Review every paid flow and make these true:
- The total price including taxes and any recurring charge, its frequency, and the next renewal date are all visible before the payment button.
- The payment button itself states that it creates a payment obligation.
- Accepting the terms requires an explicit action; nothing is pre-ticked.
- Cancellation is available from the account area in at most two clicks, with no retention offer, survey or phone call in the way.
- An email confirmation is sent containing the order details and the cancellation instructions.
List every screen you changed, and list any flow where you could not implement one of these and why.
10. Vérification pré-lancement
Run a pre-launch compliance check. Report as a checklist with PASS, FAIL or UNKNOWN for each item — answer UNKNOWN rather than guessing:
1. Privacy Policy, Terms of Service and Cookie Policy exist, are linked in the footer of every page, and contain no unfilled placeholders.
2. Business identity and a working contact method appear on the site.
3. No analytics or advertising request fires before consent, and consent can be withdrawn.
4. Account deletion and data export work end to end.
5. Every form states, at the point of collection, what the data will be used for.
6. No test or demo data, no real personal data in seed data, no secrets in client-side code.
7. Every marketing email includes an unsubscribe link and a postal contact.
8. AI features disclose that they are AI.
9. The documented children’s-scope assessment has been implemented; any age assurance is proportionate and minimizes identity data.
10. Legal pages, consent UI and error messages exist in every language the product is offered in.
For every FAIL and UNKNOWN, tell me what would fix it.
Comment les trois régions diffèrent, en un tableau
| États-Unis | Union européenne | Brésil | |
|---|---|---|---|
| Ce qui vous met dans le champ d'application | Vendre à ou cibler des résidents d'états spécifiques, généralement au-dessus des seuils de volume/revenus | Offrir des biens ou services à des personnes dans l'UE, ou les surveiller — pas de seuil de taille | Traiter des données de personnes au Brésil, ou offrir des biens ou services au Brésil |
| Loi principale sur la confidentialité | Lois étatiques complètes plus règles fédérales et sectorielles étatiques | RGPD | LGPD |
| Consentement au suivi | Principalement opt-out ; plusieurs états exigent d'honorer les signaux opt-out du navigateur (GPC) | Opt-in avant le suivi des appareils non exempté | Consentement pour les cookies non essentiels ; l'ANPD attend des boutons accepter/rejeter égaux |
| Enfants | COPPA moins de 13 ans (conformité totale depuis le 22 avril 2026) plus lois étatiques sur l'âge des app-stores | RGPD âge de consentement 13–16 par état membre, plus devoirs DSA | ECA Digital (Lei 15.211/2025) en vigueur depuis le 17 mars 2026 |
| Accessibilité | Pas de règle fédérale web pour les entreprises privées, mais litiges ADA lourds ; WCAG 2.1 AA est le standard de fait | European Accessibility Act depuis le 28 juin 2025 ; EN 301 549 / WCAG 2.1 AA | LBI (Lei 13.146/2015) plus ABNT NBR 17225:2025 |
| Vente en ligne | ROSCA plus ~30 lois étatiques sur le renouvellement automatique ; nexus de taxe de vente par état | Droit de rétractation de 14 jours ; fonction de rétractation pour les contrats couverts depuis le 19 juin 2026 | Droit de regret de 7 jours CDC ; devoirs de divulgation Décret 7.962/2013 |
| Règles IA | Pas de loi fédérale unique ; règles FTC sur la tromperie plus statuts IA étatiques | Article 50 de l'IA Act transparence depuis le 2 août 2026 | Pas encore de loi complète sur l'IA ; projet de loi en attente |
| Qui applique | Procureurs généraux des états, FTC et poursuites privées | Autorités nationales de protection des données ; amendes jusqu'à 4% du chiffre d'affaires mondial | ANPD, Procon et tribunaux de consommation |
Chaque ligne est un résumé — les analyses approfondies expliquent les seuils et les exemptions : États-Unis · Union européenne · Brésil.
Quatre autres marchés, chacun avec sa particularité : le Royaume-Uni, où des analyses statistiques limitées peuvent se qualifier pour une exemption de consentement et le champ d'application du Online Safety Act a des exemptions ; le Canada, où la LSPC reconnaît le consentement exprès et le consentement implicite admissible, et le Québec ajoute ses propres règles de confidentialité et de langue ; l' Australie, où une petite entreprise peut encore se trouver en dehors de la Privacy Act alors que la divulgation des décisions automatisées et le développement du code pour enfants ont des jalons en décembre 2026 ; et Israël, où l'amendement 13 a étendu l'application de la confidentialité et où les règles sur le spam et l'accessibilité comptent également.
Droits sur le contenu, avis et relations d'affiliation
Gardez une trace de l'autorisation ou de la licence pour les photos, polices, vidéos et autres actifs. Utilisez de vrais témoignages avec l'autorisation appropriée et n'inventez pas de résultats clients, de pièces de portfolio ou d'avis. L'amélioration par IA de votre propre travail réel peut améliorer la présentation ; ne générez pas de travail ou de preuves avant-après qui n'ont jamais existé.
Si une recommandation génère une commission ou un autre avantage, divulguez cette relation clairement près de la recommandation. Une politique en pied de page seule peut ne pas expliquer une connexion matérielle au point où les lecteurs s'y fient. Voir le guide de recommandation de la FTC.
Pour les téléchargements d'utilisateurs, séparez la licence que vos conditions demandent de votre processus de signalement et de retrait. Ne supposez pas que rédiger « les utilisateurs sont responsables » résout vos propres devoirs.
Quand engager réellement un avocat
Faites-le vous-même avec les prompts ci-dessus si vous construisez un site vitrine, un portfolio, un formulaire de réservation, un petit SaaS avec des données de compte ordinaires, ou un outil interne. Impliquez un professionnel — correctement, avant le lancement — si l'un de ces points est vrai :
- Vous gérez des données de santé, biométriques, financières ou de localisation précise, ou tout ce qui concerne les enfants.
- Vous construisez dans un secteur réglementé : santé, finance, assurance, services juridiques, jeux de hasard, alcool, dossiers éducatifs.
- La fonction principale de votre produit est le profilage, la notation ou les décisions automatisées concernant les personnes — crédit, embauche, logement, assurance, éducation.
- Vous prenez des investissements, ou vos flux de données sont une question de diligence raisonnable.
- Vous traitez des données personnelles à grande échelle, ou agissez comme une place de marché entre d'autres parties.
- Vous avez reçu une lettre de mise en demeure, une demande d'un régulateur ou une plainte d'une personne concernée — arrêtez et obtenez de l'aide immédiatement, ne répondez pas à partir d'un modèle.
Une révision de deux heures d'un brouillon que vous avez déjà préparé est radicalement moins chère qu'un avocat commençant à partir d'une page blanche. C'est le vrai retour sur l'exécution de la séquence de prompts : vous arrivez avec un inventaire de données et un brouillon, pas avec une question.
Maintenance : ce n'est pas une tâche unique
Chaque fois que vous ajoutez une fonctionnalité qui collecte quelque chose de nouveau, ajoutez un service ou activez une nouvelle intégration, votre inventaire change et votre politique est maintenant légèrement erronée. Le rythme sain : réexécutez le prompt 1 chaque fois que vous publiez quelque chose qui touche aux données, et réexécutez le prompt 10 avant toute version significative. Deux fois par an, relisez votre propre politique en tant qu'étranger et vérifiez qu'elle décrit toujours votre produit.
Ce que les vérifications de construction établissent
Les prompts sont des demandes d'implémentation, pas une certification juridique. Les contrôles en deux clics et les défauts axés sur le consentement sont des choix de conception pratiques, pas des exigences légales universelles. Confirmez la juridiction, les exceptions, la conservation et les contrats des fournisseurs séparément. Vérifiez les contrôles avec des comptes de test et le comportement réel du navigateur/réseau ; un RÉUSSI du constructeur basé uniquement sur l'inspection du code est une preuve incomplète.
Sources officielles et portée de la révision
Mis à jour le 14 septembre 2026. Les sources liées soutiennent la portée et les corrections discutées ici ; il s'agit d'une revue éditoriale, pas d'un avis juridique exhaustif ou d'une certification de votre produit. Vérifiez la règle opérationnelle en agissant.
Lancez-vous légalement, pas par chance. Exécutez les dix prompts ci-dessus avant de connecter votre domaine, puis lisez l'analyse approfondie pour votre plus grand marché : États-Unis, Union européenne, Royaume-Uni, Canada, Australie, Brésil, Israël. Et si vous n'avez pas encore construit la chose, commencez par De l'idée à l'application en direct. Vous pouvez construire cela.