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.
## 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)