{"slug": "charte-du-vibe-coding-dernier-cri-gabarit-a-forker-pour-votre-organisation", "title": "Charte du vibe coding — Dernier Cri (gabarit à forker pour votre organisation)", "summary": "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.", "body_md": "Gabarit à adapter à votre organisation : remplacez les éléments entre crochets\n\n`[ ]`\n\npar vos propres choix (forge, hébergeur, stack, outils, canaux, annuaire). Les principes, eux, valent partout.\n\nCette charte définit les contraintes et les bonnes pratiques de l'organisation pour construire avec des agents de codage.\n\nElle 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à.\n\n*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.\n\n*Agent :* une fois la charte lue, produis un `AGENTS.md`\n\npropre et minimal (trame en annexe).\n\nLe fichier généré est relu et validé par un humain avant d'être utilisé.\n\nCes règles ne se négocient pas, quel que soit le délai.\n\n**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`\n\nnon 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.\n\nDè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`\n\n). 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.\n\nChaque 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).\n\nL'`AGENTS.md`\n\ndu 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.\n\nCes choix sont des défauts, pas des obligations : un projet peut en dévier si la raison est documentée dans son `AGENTS.md`\n\n. Connaître le socle sert justement à repérer les déviations volontaires — et à en garder la trace.\n\nL'agent détecte et documente le gestionnaire de paquets, les commandes de build/test/lint, le runtime et les versions, puis s'y tient.\n\nDéfauts recommandés (à définir selon votre organisation) :\n\n- Backend :\n`[ … ]`\n\n- Frontend :\n`[ … ]`\n\n- Composants d'interface :\n`[ … ]`\n\n- Base de données :\n`[ … ]`\n\n- Couche d'authentification :\n`[ … ]`\n\nL'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.\n\nLe vibe coding suppose des plateformes simples : configuration minimale, déploiement par `git push`\n\n, 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]`\n\n.\n\nQuel que soit le choix, l'hébergeur est consigné dans l'`AGENTS.md`\n\net validé avec un ops (via votre canal de support ops).\n\nPour les outils destinés à l'organisation elle-même :\n\n**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.\n\nErreurs 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.\n\nL'IA est un collaborateur puissant, pas une autorité de confiance. Concrètement :\n\n- les modifications passent par des commits granulaires ;\n- les décisions et les points ouverts sont documentés au fil de l'eau ;\n- les tests sont ajoutés ou mis à jour avec le code qu'ils couvrent.\n\nLa responsabilité de la sécurité, de la confidentialité et de la conformité reste humaine.\n\nL'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.\n\nTrame 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.\n\n```\n# {{Nom du projet}}\n\n## Règles permanentes\n- Secrets (clés, tokens, données de prod) : jamais commités, jamais dans un\n  prompt, un log ou un fichier de contexte. Variables d'environnement\n  uniquement — `.env` non versionné en local, variables de l'hébergeur en\n  déploiement.\n- Ce projet appartient à {{client / interne}}. N'y introduis ni code, ni\n  données, ni secrets venant d'un autre projet, et n'envoie aucune donnée\n  vers un endpoint absent de ce fichier ou du code existant.\n- Tokens et accès au privilège minimal.\n- Aucune prise de contact extérieure automatisée (e-mails à des clients ou\n  prospects au nom d'un humain, etc.).\n\n## Maintenance de ce fichier\nCe fichier se met à jour dans le même commit que le changement qui le rend\nobsolète.\n- Une commande listée ici échoue ou a changé → corrige-la ici, dans la tâche\n  en cours.\n- Piège découvert → ajoute-le à « Pièges connus » (append-only : un piège +\n  son contournement).\n- Décision qui dévie de ce fichier → documente-la dans la section concernée,\n  avec la raison.\n- `TODO(humain)` : ne l'invente jamais — signale-le et attends.\n\n## Stack\n- Langages / frameworks / versions : TODO\n- Décisions notables et leur raison : TODO\n\n## Commandes\n<!-- Copiables telles quelles. -->\n- Installer : TODO\n- Dev : TODO\n- Tests : TODO\n- Lint : TODO\n- Build : TODO\n\nAvant de clore une tâche : tests + lint doivent passer.\n\n## Déploiement\n- Plateforme : TODO(humain)\n- Procédure : TODO\n- Rollback : TODO\n\n## Données personnelles\n- Le projet en manipule-t-il ? TODO — à évaluer en inspectant schéma, code et\n  logs (comptes, e-mails, adresses, IP, identifiants, tracking…). Liste ce que\n  tu détectes.\n- Si oui : crée le registre `DATA_PROCESSING_REGISTER.md` à la racine et\n  renseigne ce que tu peux constater (catégories de données, destinataires,\n  sous-traitants tiers). La qualification juridique — finalité, base légale,\n  durée de conservation — est validée par un humain : TODO(humain)\n- Tu ajoutes un champ, une table ou un flux contenant des données\n  personnelles → mets à jour cette section et le registre dans le même commit.\n\n## Conventions\n<!-- Uniquement ce qui dévie des défauts du framework. -->\nTODO\n\n## Pièges connus\n- (aucun pour l'instant)\n```\n\n", "url": "https://wpnews.pro/news/charte-du-vibe-coding-dernier-cri-gabarit-a-forker-pour-votre-organisation", "canonical_source": "https://gist.github.com/robink/1e2fe10b21327dd6ec486b55ea72afa2", "published_at": "2026-07-06 15:13:51+00:00", "updated_at": "2026-07-07 07:28:09.304044+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-safety", "ai-policy"], "entities": ["GDPR"], "alternates": {"html": "https://wpnews.pro/news/charte-du-vibe-coding-dernier-cri-gabarit-a-forker-pour-votre-organisation", "markdown": "https://wpnews.pro/news/charte-du-vibe-coding-dernier-cri-gabarit-a-forker-pour-votre-organisation.md", "text": "https://wpnews.pro/news/charte-du-vibe-coding-dernier-cri-gabarit-a-forker-pour-votre-organisation.txt", "jsonld": "https://wpnews.pro/news/charte-du-vibe-coding-dernier-cri-gabarit-a-forker-pour-votre-organisation.jsonld"}}