Charte du vibe coding — Dernier Cri (gabarit à forker pour votre organisation)

A developer has published a template charter for 'vibe coding' that defines constraints and best practices for organizations building with coding agents. The charter covers secrets management, code versioning, data processing compliance under GDPR, and default technology stack choices, with rules applying to both human developers and AI agents.

Gabarit à adapter à votre organisation : remplacez les éléments entre crochets par vos propres choix forge, hébergeur, stack, outils, canaux, annuaire . Les principes, eux, valent partout. Cette charte définit les contraintes et les bonnes pratiques de l'organisation pour construire avec des agents de codage. Elle s'adresse à deux lecteurs à la fois : l'agent et l'humain. L'agent y trouve ce qu'il doit faire, produire et vérifier ; l'humain, les concepts à comprendre et les responsabilités qu'il assume. Sauf mention contraire, chaque règle s'applique aux deux. Les rares passages introduits par Agent : ou Humain : ne concernent que ce lecteur-là. Humain : au démarrage d'un projet, transmettez la charte complète à l'agent copier-coller , accompagnée de tout le contexte important : sensibilité des données, contraintes contractuelles, hébergement, deadlines. Agent : une fois la charte lue, produis un AGENTS.md propre et minimal trame en annexe . Le fichier généré est relu et validé par un humain avant d'être utilisé. Ces règles ne se négocient pas, quel que soit le délai. Secrets : clés, tokens et données de prod ne sont jamais commités, versionnés, ni collés dans un prompt, un log ou un fichier de contexte. Ils transitent au minimum par des variables d'environnement — .env non versionné en local, gestionnaire de variables de l'hébergeur en déploiement. Code : versionné sur la forge de l'organisation, dans des dépôts privés. Étanchéité clients : le code, les données et les secrets d'un client ne sont ni mélangés ni reproduits dans un autre projet, et aucune donnée ne part vers un endpoint qui n'a pas été explicitement fourni. Privilège minimal : tout ce que l'agent peut atteindre l'est via des tokens aux droits les plus restreints possible. Dès qu'un projet manipule des données personnelles ou sensibles, les traitements sont consignés dans un registre versionné à la racine du projet nom recommandé : DATA PROCESSING REGISTER.md . Ce fichier tient lieu de registre des traitements au sens de l'article 30 du RGPD — l'organisation y intervient selon les cas comme responsable de traitement ou comme sous-traitant de ses clients. Chaque traitement y précise au minimum : les catégories de données, la finalité, la base légale, la durée de conservation et les destinataires sous-traitants tiers compris . L' AGENTS.md du projet référence l'existence et l'emplacement de ce registre, pour que chacun — agent comme humain — sache que ces données sont sous obligation de traçabilité. Au moindre doute sur le caractère personnel ou sensible d'une donnée : on demande, on ne suppose pas. Ces choix sont des défauts, pas des obligations : un projet peut en dévier si la raison est documentée dans son AGENTS.md . Connaître le socle sert justement à repérer les déviations volontaires — et à en garder la trace. L'agent détecte et documente le gestionnaire de paquets, les commandes de build/test/lint, le runtime et les versions, puis s'y tient. Défauts recommandés à définir selon votre organisation : - Backend : … - Frontend : … - Composants d'interface : … - Base de données : … - Couche d'authentification : … L'accès à la base passe par un ORM qui gère les migrations de schéma. Les modifications de schéma restent non destructives autant que possible : on privilégie les ajouts nouvelle colonne, nouvelle table aux suppressions et renommages directs, qui cassent le code en place et compromettent le rollback. Le vibe coding suppose des plateformes simples : configuration minimale, déploiement par git push , rollback intégré. C'est ce qui évite à l'agent — et à l'humain — de s'enliser dans l'infra. Plateforme recommandée par défaut : votre PaaS . Quel que soit le choix, l'hébergeur est consigné dans l' AGENTS.md et validé avec un ops via votre canal de support ops . Pour les outils destinés à l'organisation elle-même : Authentification : OAuth contre le domaine de l'organisation. Les identifiants propres au projet s'obtiennent par ticket auprès de l'équipe ops. Agent : ne fabrique pas, ne code pas en dur et ne stubbe pas d'identifiants OAuth — signale qu'un ticket ops est nécessaire et attends les identifiants. Gestion des droits : RBAC calqué sur les groupes de l'annuaire existant Google Workspace, Entra ID… — un rôle applicatif = un groupe. On ne réinvente pas de référentiel d'identités. Erreurs et performance sont suivies par un outil dédié ex. Sentry , instrumenté dès le démarrage de tout nouveau projet. La DSN suit la règle secrets du §2 : variable d'environnement, jamais en dur. L'IA est un collaborateur puissant, pas une autorité de confiance. Concrètement : - les modifications passent par des commits granulaires ; - les décisions et les points ouverts sont documentés au fil de l'eau ; - les tests sont ajoutés ou mis à jour avec le code qu'ils couvrent. La responsabilité de la sécurité, de la confidentialité et de la conformité reste humaine. L'automatisation des prises de contact directes avec l'extérieur est proscrite. En particulier : pas d'e-mails rédigés et envoyés automatiquement à des clients ou prospects au nom d'un humain. Trame minimale que l'agent génère et que l'humain relit. Principe : n'y mettre que ce que l'agent ne peut pas déduire seul. {{Nom du projet}} Règles permanentes - Secrets clés, tokens, données de prod : jamais commités, jamais dans un prompt, un log ou un fichier de contexte. Variables d'environnement uniquement — .env non versionné en local, variables de l'hébergeur en déploiement. - Ce projet appartient à {{client / interne}}. N'y introduis ni code, ni données, ni secrets venant d'un autre projet, et n'envoie aucune donnée vers un endpoint absent de ce fichier ou du code existant. - Tokens et accès au privilège minimal. - Aucune prise de contact extérieure automatisée e-mails à des clients ou prospects au nom d'un humain, etc. . Maintenance de ce fichier Ce fichier se met à jour dans le même commit que le changement qui le rend obsolète. - Une commande listée ici échoue ou a changé → corrige-la ici, dans la tâche en cours. - Piège découvert → ajoute-le à « Pièges connus » append-only : un piège + son contournement . - Décision qui dévie de ce fichier → documente-la dans la section concernée, avec la raison. - TODO humain : ne l'invente jamais — signale-le et attends. Stack - Langages / frameworks / versions : TODO - Décisions notables et leur raison : TODO Commandes < -- Copiables telles quelles. -- - Installer : TODO - Dev : TODO - Tests : TODO - Lint : TODO - Build : TODO Avant de clore une tâche : tests + lint doivent passer. Déploiement - Plateforme : TODO humain - Procédure : TODO - Rollback : TODO Données personnelles - Le projet en manipule-t-il ? TODO — à évaluer en inspectant schéma, code et logs comptes, e-mails, adresses, IP, identifiants, tracking… . Liste ce que tu détectes. - Si oui : crée le registre DATA PROCESSING REGISTER.md à la racine et renseigne ce que tu peux constater catégories de données, destinataires, sous-traitants tiers . La qualification juridique — finalité, base légale, durée de conservation — est validée par un humain : TODO humain - Tu ajoutes un champ, une table ou un flux contenant des données personnelles → mets à jour cette section et le registre dans le même commit. Conventions < -- Uniquement ce qui dévie des défauts du framework. -- TODO Pièges connus - aucun pour l'instant