vipink1203/app-compliance

Conformité de l'application

Toute application franchit ces portes avant d'atteindre les utilisateurs réels, et continue de les franchir à chaque modification. Une porte est une obligation avec une règle, ce qu'il faut construire, et une vérification fait quand. Le statut de chaque porte figure dans le registre de conformité du projet, afin que rien ne soit laissé à la mémoire ou aux bonnes intentions.

Il s'agit d'ingénierie fondée sur la loi recherchée, pas d'un conseil juridique. Les règles proviennent des notes sourcées dans research/, datées du 31 octobre 2026 : 01 vie privée et consentement, 02 commerce et allégations et 03 accessibilité, PI et IA. Lorsqu'une note a plus de 6 mois au moment de l'exécution, revérifiez les sources primaires citées dans les sections sur lesquelles vous vous appuyez (avec une compétence de recherche, si vous en avez une) avant de considérer ses dates et seuils comme actuels.

Principes

• Une seule construction pour tout le monde. Construisez selon la norme commune la plus stricte (RGPD pour la vie privée, Californie pour les abonnements et les prix, WCAG 2.2 AA pour l'accessibilité) pour chaque utilisateur, sans bifurquer par pays.
• La carte des données est la vérité. Les pages juridiques, les invites de consentement et la liste des fournisseurs décrivent ce que le code et l'application en ligne font réellement, découvert en lisant le code et en capturant le trafic, jamais ce qu'un modèle suppose. Lorsque l'application change, les pages changent dans le même commit.
• Preuve ou rien. Chaque allégation, badge, logo, avis et chiffre dans l'application pointe vers une entrée de preuve dans le registre.
• Le propriétaire décide, l'agent rédige. L'agent écrit les pages, le code et les tests ; les signatures, les enregistrements, les autorisations et le jugement juridique sont des actions du propriétaire, et l'agent ne marque jamais une action comme terminée pour le compte du propriétaire.

Étapes

1. Cartographier les données. Construisez la carte des données dans le registre de conformité à partir du code et d'une exécution en direct : chaque champ de formulaire et entrée API avec des données personnelles, chaque colonne de base de données ou stockage les contenant, chaque cookie et clé localStorage/sessionStorage/IndexedDB, chaque domaine appelé par l'application (capturez un HAR Playwright de chaque route, et une capture proxy comme mitmproxy d'une nouvelle installation mobile), chaque SDK dans l'arbre des dépendances, et chaque e-mail envoyé par l'application. Pour chaque élément : objectif, base légale, où il est stocké, période de conservation, et quel fournisseur le reçoit. Fait quand la recherche de code et le HAR ne montrent rien d'absent de la carte.
2. Définir le périmètre. Répondez dans le registre : Qui sont les utilisateurs (consommateurs, entreprises, enfants possibles) ? Où (États-Unis, UE/ROYAUME-UNI, ailleurs) ? Quelle est la taille de l'entreprise (effectifs, chiffre d'affaires) ? Accepte-t-elle des paiements ou des abonnements ? Envoie-t-elle des e-mails marketing ? Stocke-t-elle du contenu fourni par les utilisateurs (messages, commentaires, fichiers, profils, avatars) ? Affiche-t-elle des résultats IA ou un chat IA ? Gère-t-elle des données de santé, financières, biométriques ou de localisation précise ? Un « oui » pour les données sensibles ou les enfants ajoute une révision par un avocat aux actions du propriétaire.
3. Parcourir chaque porte. Lisez chaque fichier de porte ci-dessous et attribuez à chaque porte un statut : pass, fail, n/a (avec la réponse de périmètre qui l'exclut), ou owner (en attente d'une action du propriétaire).
   • gates/privacy.md : avis de confidentialité, minimisation, conservation, demandes d'accès et de suppression, enfants, entraînement IA sur les données utilisateur, fournisseurs, DPAs et sous-traitants (PRIV).
   • gates/consent-and-tracking.md : bannière de cookies, blocage des traceurs avant consentement, signaux de refus, consentement marketing séparé (CONSENT).
   • gates/terms-and-payments.md : acceptation des conditions et son enregistrement, prix complets, remboursements, renouvellement automatique, annulation, droit de rétractation UE (TERMS, PAY).
   • gates/marketing-and-claims.md : allégations, badges de sécurité, avis, logos, disponibilité, urgence, motifs sombres, coordonnées de l'entreprise, e-mail marketing (CLAIM, UX, BIZ, EMAIL).
   • gates/accessibility.md : analyse WCAG 2.2 AA, contraste, texte alternatif, clavier, focus, minutage et cibles, déclaration d'accessibilité UE (A11Y).
   • gates/licenses-and-content.md : licences de code, polices, images et icônes, signalement et retrait de contenu utilisateur (LIC, UGC).
   • gates/ai.md : divulgation du chat IA, étiquetage et marquage du contenu généré (IA).
4. Corriger et prouver. Construisez ce dont chaque fail a besoin, puis exécutez sa vérification « fait quand » : des vérifications automatisées sous forme de tests dans la suite du projet pour qu'elles continuent à s'exécuter, des vérifications manuelles enregistrées avec date et résultat. Fait quand chaque porte est pass, n/a ou owner, sans aucun fail restant.
5. Transmettre. Écrivez la liste des actions du propriétaire en haut du registre et informez le propriétaire dans la session, une ligne par action : quoi faire, pourquoi et où.

Lors d'une modification ultérieure, répétez les étapes 1 et 3 à 5 pour les fichiers de porte concernés par la modification, et mettez à jour le registre dans le même commit.

Le registre de conformité

Chaque application conserve un registre dans docs/compliance.md de son dépôt, mis à jour sur place, construit à partir de record-template.md. Il contient les réponses de périmètre, la carte des données, le statut et la preuve de chaque porte, les entrées de preuve, le registre des actifs, et les actions du propriétaire. Une application n'est lancée que lorsque son registre ne montre aucun fail et que le propriétaire a approuvé ou explicitement accepté chaque action ouverte du propriétaire.