Le code IA a changé de statut sans que personne ne s'en aperçoive. Il n'est plus un autocomplete, il est un contributeur. Sonar (enquête 1 100 devs, janvier 2026) : le code IA représente 42% du code committé, 96% des devs ne lui font pas entièrement confiance, et seulement 48% le vérifient systématiquement avant de committer.

Relis ce triptyque : un tiers du code vient d'une machine, presque personne ne lui fait confiance, et la moitié entre en prod sans vérification. Dans n'importe quel autre domaine d'ingénierie, ce serait un rapport d'audit pré-incident.

La seule règle écrite que ton équipe connaît tient dans la doc de l'éditeur lui-même. GitHub pose noir sur blanc dans ses "responsible use" : utiliser Copilot code review pour compléter les revues humaines, pas pour les remplacer. Quand le vendeur te rappelle que le code machine exige un humain, c'est que le contrat manque quelque part.

Ce vide a un coût documenté. Harness (700 praticiens, mai 2026) : 81% des équipes passent plus de temps en code review depuis l'IA, et ~31% du temps dev part dans du travail invisible (relire le code IA, fixer les bugs, changer d'outil). Sonar : 38% disent que revoir le code IA demande plus d'effort que revoir le code humain. Le gain d'écriture est en train de se payer en temps de relecture, sans que personne n'ait décidé de cet arbitrage.

La gouvernance n'est pas un comité d'éthique. C'est un document d'une page, écrit par le lead, que l'équipe connaît. Trois clauses suffisent.

Clause 1 : l'usage déclaré.

Chaque PR indique si le code est IA-généré et à quel degré. Pas pour la police, pour la revue : un reviewer ne lit pas de la même façon un refactor écrit à la main et 800 lignes générées en une session. La transparence remplace la devinette.

Le contre-modèle existe : Mitchell Hashimoto (créateur de Ghostty, fondateur de HashiCorp) a changé sa politique de contribution en janvier 2026. Son constat : le coding agentique a supprimé le backpressure naturel qui limitait les contributions à faible effort, "il est désormais trop facile de créer de grandes quantités de mauvais contenu". Sa règle : contributions IA seulement sur les issues acceptées, par les mainteneurs, drive-by PRs IA fermées immédiatement. "Ce n'est pas une position anti-IA. Ghostty est écrit avec beaucoup d'assistance IA."

Clause 2 : la revue proportionnée au risque.

Toutes les lignes IA ne valent pas le même contrôle. La règle de Homebrew (équipement de Mike McQuaid) est le meilleur exemple public : "ne demande pas à d'autres humains de revoir ton code généré par IA avant de l'avoir relu toi-même", et la revue renforcée est réservée aux zones critiques (installation, sécurité, téléchargements). Chez toi : auth, paiement, accès données = revue obligatoire ligne par ligne. Boilerplate, styles, tests = revue standard. L'écart entre les deux, c'est là que la gouvernance devient soutenable.

Homebrew a aussi posé la règle d'attribution la plus nette : "l'IA n'est pas responsable de son output, c'est toi qui es responsable de l'output des outils que tu utilises". Et pas de trailer Co-authored-by: AI dans les commits : un commit a un humain responsable, point.

Clause 3 : le gate exécutable.

Une règle qui n'est pas vérifiable automatiquement est une opinion. Anthropic le formule dans sa doc Claude Code : "donne à Claude un check qu'il peut exécuter : un test, un build, un screenshot à comparer", et la boucle se ferme toute seule. Tes gates doivent être du même type : lint strict, tests obligatoires sur les zones IA-sensibles, tripwire sur la duplication.

Ce dernier point est documenté par les données. GitClear (623 millions de changements analysés, 2023-2026) : le refactoring s'est effondré de 21% à 3,8% des lignes changées, la duplication a bondi de 81%, la maintenance du code existant a chuté de 74%. Leur phrase résume le contrat manquant : "le plus gros risque n'est pas que l'IA écrive du code que ton équipe ne peut pas maintenir, c'est qu'elle l'écrive plus vite que jamais, et que la facture arrive quand tu peux le moins te le permettre". Leur remède : un budget de refactoring explicite et un tripwire automatique sur les blocs dupliqués.

Le risque n'est pas de trop gouverner, c'est de gouverner trop tard. Upsun le formule bien : "l'adoption arrive d'abord, la gouvernance devient une réaction, pas une donnée de design". Et le contre-chiffre existe : METR a mesuré (RCT, devs expérimentés) que le gain d'IA est contextuel et mal perçu, +19% de temps réel là où les devs croyaient gagner 24%. Une équipe qui maximise l'adoption sans contrat optimise une métrique qu'elle ne mesure pas.

La règle d'équilibre : le contrat doit tenir sur une page, se vérifier en CI, et protéger le prototypage rapide. Pas de comité, pas de formulaire, pas de quiz IA trimestriel. Si ta gouvernance met plus de 30 secondes à s'expliquer à un nouveau, elle est trop lourde.

Le lead dev est le seul rôle qui peut écrire ce contrat : il connaît les zones sensibles, il possède le code review, il tient la CI. Et l'argument est simple à porter en next comité : Google, Shopify et Homebrew ont écrit leurs règles. La seule équipe sans contrat est la tienne.

Commence petit : une page, trois clauses, une rétro dans 30 jours. Ce que la gouvernance doit produire, ce n'est pas de la conformité, c'est la capacité de dire "ce code, on sait qui l'a écrit, qui l'a relu, et pourquoi il est sûr".

Le CODEOWNERS de ton repo, détourné en contrat : les zones IA-sensibles (auth, paiement, données) exigent un reviewer nommé, les autres passent en revue standard. C'est une config de 10 lignes, vérifiée par GitHub lui-même à chaque PR, et ça transforme la clause 2 en mécanique. Zéro outil nouveau, zéro budget : 10 lignes et une conversation d'équipe pour poser les zones. La gouvernance qui marche est celle que la CI vérifie à ta place.

Réponds-moi. Et si tu veux le template d'une page pour poser les 3 clauses avec ton équipe, réponds "contrat" et je te l'envoie.