Votre historique Git fait foi : maîtrisez l’attribution de l’IA avant qu’elle ne vous maîtrise

Vous avez sans doute vu la polémique : des rapports indiquant que VS Code insérait « Co‑Authored‑by: Copilot » dans des commits, même lorsque les développeurs n’avaient pas explicitement opté pour cette option. Beaucoup d’équipes ont haussé les épaules. Ne le faites pas. Votre historique Git n’est pas qu’un contrôle de versions ; c’est une preuve. C’est ce que votre acquéreur, votre auditeur et les mainteneurs en amont liront lorsqu’ils demanderont : « Qui a écrit ceci, à quelles conditions, et pouvez‑vous le prouver ? »

Ce n’est pas un réquisitoire anti‑IA. C’est une question de contrôle. Si l’attribution à l’IA se glisse dans les métadonnées de commit sans intention ni cohérence, cela peut casser les vérifications DCO, brouiller la propriété intellectuelle, déclencher des refus liés aux politiques upstream et compliquer les pistes d’audit SOC 2/ISO 27001. Si vous dirigez l’ingénierie d’une startup ou d’une scale‑up, vous avez besoin d’une posture de gouvernance qui maintienne la vitesse de livraison tout en faisant de votre historique Git un atout, pas un passif.

Ce qui est réellement en jeu quand l’IA apparaît dans les métadonnées de commit

• Ruptures du DCO et des politiques de contribution : De nombreuses organisations et projets open‑source conditionnent les fusions au Developer Certificate of Origin (DCO). Des trailers ambigus comme « Co‑Authored‑by » provenant d’un outil d’IA peuvent faire échouer des vérifications automatisées ou faire tiquer les mainteneurs. Voir le texte du DCO sur developercertificate.org.
• Ambiguïtés sur la propriété intellectuelle et le droit d’auteur : Certaines juridictions traitent différemment les contenus générés par l’IA. Si vos métadonnées suggèrent un co‑auteur non humain, vous invitez des questions indésirables lors des diligences.
• Provenance de la supply chain brouillée : Les pratiques SLSA, Sigstore et SBOM supposent une traçabilité des auteurs et des étapes de build. Des trailers non maîtrisés réduisent le signal nécessaire à la provenance et aux attestations. Voir slsa.dev et sigstore.dev.
• Dérive des politiques côté upstream et client : Certains dépôts en amont exigent une divulgation explicite de l’assistance IA ; d’autres interdisent explicitement les patchs générés par IA. Vos métadonnées peuvent vous placer involontairement du mauvais côté des deux.

Traduction : une seule ligne de trailer « utile » ajoutée par un outil peut transformer une fusion routinière en une alerte de 1 à 2 jours entre juridique, sécurité et ingénierie — multipliée par le nombre d’équipes.

Où ce risque s’infiltre

• Paramètres et extensions des IDE : Les IDE, extensions et agents ajoutent parfois des trailers automatiquement. Les développeurs ne le remarquent souvent que lorsqu’une branche protégée rejette un push.
• Modèles de commit partagés ad hoc : Un ingénieur bien intentionné définit un modèle de commit global qui inclut des lignes « Co‑Authored‑by: » pour le pair programming, et cela se propage à tous les dépôts.
• Comptes bots et automatisation : Renovate, Dependabot, des bots de release et des scripts internes peuvent ajouter des trailers supplémentaires qui interagissent mal avec vos contrôles.
• Machines nearshore/contractors : Les environnements hétérogènes amplifient la dérive : IDE, modèles et language servers différents entre macOS, Windows et Linux.

Le cadre de décision d’un CTO : quatre couches de contrôle

Vous ne résolvez pas cela avec un seul hook malin. Vous le résolvez en couches — discipline locale, application côté serveur, clarté de la politique et provenance de la supply chain. Voici le modèle que nous déployons chez nos clients.

Couche 1 : Contrôles en développement local (faire de la « bonne voie » le défaut)

• Standardisez les modèles de commit par dépôt : Fournissez un modèle minimal qui n’inclut que ce que vous faites respecter : une ligne d’objet, un corps facultatif, et « Signed‑off‑by: » si vous exigez le DCO. Pas de trailers pour l’IA, les pairs ou les bots par défaut.
• Hooks prepare‑commit‑msg et commit‑msg : Livrez des hooks au périmètre du dépôt qui suppriment les trailers non autorisés et échouent les commits non conformes à la politique. Exemples de motifs interdits : lignes Co‑Authored‑by référencées à des outils (p. ex. « Copilot »), alias de bots ambigus, ou commits non signés vers des branches protégées.
• Verrouillez les réglages de l’éditeur dans les devcontainers : Si vous utilisez des devcontainers ou des devboxes managées, désactivez l’insertion automatique de trailers par des extensions. Épinglez les extensions et paramètres approuvés pour éviter que la dérive ne reparte.
• Liste d’autorisation humaine pour les co‑auteurs : Si vous autorisez une co‑signature explicite, maintenez une liste d’e‑mails humains autorisés. Tout le reste est supprimé localement avec un message d’erreur exploitable.

Les contrôles locaux empêchent la plupart des problèmes avant l’origine. Ils ne suffisent pas seuls, car les développeurs peuvent les contourner ou travailler hors de vos conteneurs. C’est pourquoi vous avez besoin des couches suivantes.

Couche 2 : Application côté serveur (les garde‑fous qui s’exécutent toujours)

• Protection des branches avec commits signés : Exigez des signatures GPG ou Sigstore keyless sur les branches protégées. C’est un seuil net : si un commit n’est pas signé par une identité autorisée, il ne passe pas. GitHub et GitLab le prennent tous deux en charge.
• Hooks côté serveur ou checks requis : Ajoutez un statut requis qui analyse les trailers des commits sur chaque PR. Rejetez les commits contenant des trailers interdits, dépourvus de « Signed‑off‑by » DCO, ou des changements effectués par des bots sur des chemins sensibles.
• CODEOWNERS partout : Rendez l’ownership explicite au niveau des répertoires afin que les revues aboutissent à des humains responsables. Si une PR contient des trailers suspects, les owners décident de l’accepter avec divulgation ou de la refuser.
• Comptes de service bots avec identités vérifiées : Lorsque vous autorisez des bots (Renovate, automatisation de release), donnez‑leur des identités et des périmètres uniques, et documentez leurs trailers. C’est l’ambiguïté qui déclenche l’emballement de conformité.

Couche 3 : Politique et formation (lever toute ambiguïté)

• Publiez une courte politique « IA dans le code » : Deux pages maximum. Définissez les outils autorisés, les exigences de divulgation, ce que « co‑autorat » signifie chez vous, et qui approuve les exceptions. Intégrez les attentes DCO.
• Grille de divulgation dans les PR : Exigez que les développeurs divulguent une assistance IA substantielle dans la description de la PR plutôt que dans les trailers de commit. La provenance reste accessible sans polluer les métadonnées Git.
• Intégration avec les achats : Reliez l’acquisition d’IDE/agents au respect de la politique. Les extensions qui insèrent des trailers automatiquement sont désactivées ou configurées lors du déploiement, pas après le premier incident.
• Stratégie upstream : Suivez les politiques de contribution IA des 20 principaux dépôts que vous ciblez. Si les mainteneurs bannissent le code IA, vous évitez de faire perdre du temps à vos équipes ; s’ils exigent une divulgation, canalisez‑la dans le texte de la PR plutôt que dans les métadonnées de commit.

Couche 4 : Provenance, SBOM et releases (prouvez ce que vous avez construit)

• Builds alignés SLSA : Générez la provenance des builds avec des signatures appuyées par OIDC (p. ex. Sigstore Fulcio) et attachez‑la aux releases. Cela prouve le qui/quoi/quand de votre pipeline de build, indépendamment des trailers de commit.
• SBOMs avec attestation de revue humaine : Produisez des SBOMs au moment du build et ajoutez une attestation signée par un responsable de release humain. Vous ne débattez pas de savoir si un outil a « co‑écrit » du code ; vous affirmez et signez qui l’a livré.
• Transparence des bots de release : Si un bot promeut des artefacts, incluez son identité dans les notes de release et la provenance. Une démarcation claire réduit les litiges futurs.

Plan de mise en œuvre : faites‑le en semaines, pas en trimestres

Semaine 1 : Stopper l’hémorragie

• Choisissez trois dépôts critiques (service cœur, frontend, infra). Ajoutez un modèle de commit minimal. Ajoutez des hooks au périmètre du dépôt qui retirent toute ligne « Co‑Authored‑by: » ne correspondant pas à une liste d’e‑mails humains autorisés.
• Activez les commits signés pour les branches protégées. Faites tourner les clés ou adoptez le keyless avec Sigstore si possible. Rendez‑le obligatoire.
• Figez les devcontainers ou des images « golden » pour vos ingénieurs et partenaires nearshore. Désactivez tout réglage d’extension qui insère automatiquement des trailers. Documentez le réglage et sa raison d’être.

Semaine 2 : Appliquer et éduquer

• Ajoutez un contrôle des trailers dans la CI en tant que statut requis. Il inspecte tous les commits d’une PR et échoue si des trailers interdits apparaissent, si le DCO manque sur les dépôts qui l’exigent, ou si les trailers sont mal formés.
• Publiez la politique IA en deux pages avec des exemples. Montrez à quoi ressemble « divulguer dans le corps de la PR », et quand le co‑autorat explicite est approprié (p. ex. pair programming avec un autre ingénieur).
• Mettez à jour les CODEOWNERS sur l’ensemble des services pour garantir que la responsabilité humaine s’aligne avec les bons reviewers.

Semaines 3–4 : Prouvez‑le de bout en bout

• Ajoutez la provenance aux releases en utilisant des outils alignés SLSA. Stockez les attestations là où auditeurs et acquéreurs peuvent les récupérer.
• Générez des SBOMs automatiquement et faites signer un responsable de release humain, en notant les zones de code assistées par IA dans les notes de release lorsque pertinent.
• Instrumentez des métriques : suivez le pourcentage de PR échouant au contrôle des trailers, le temps médian de remédiation, et la couverture SBOM/provenance à travers les services. Attendez‑vous à un pic initial puis une stabilisation.

Réglages Git/GitHub/GitLab concrets qui fonctionnent

• Commit trailers 101 : Git traite les trailers comme des lignes structurées en fin de message de commit. Lisez le comportement canonique dans git-interpret-trailers. Exploitez‑le pour un parsing déterministe dans vos contrôles.
• Liste des trailers autorisés : Objet, corps, Signed‑off‑by, Reviewed‑by pour les reviewers humains, et un Change‑id interne si vous utilisez des IDs à la Gerrit. C’est tout. Le reste va dans la description de la PR.
• Motifs de trailers interdits : Tout Co‑Authored‑by référencé à des outils ou agents ; tout trailer sans e‑mail humain vérifiable ; doublons de Signed‑off‑by pour une même identité ; trailers exotiques ajoutés par des IDE ou des bots non présents dans votre registre.
• Protection de branche GitHub : Exigez les commits signés ; exigez les status checks (le contrôle des trailers et le DCO si utilisé) ; appliquez aux admins ; et bloquez les force pushes. Reproduisez l’équivalent dans GitLab avec des push rules et des branches protégées.
• Sigstore keyless : Adoptez la signature adossée à l’OIDC dans la CI pour que vos identités de service signent les artefacts sans clés à long terme. Cela réduit la prolifération de secrets et s’aligne avec l’état d’esprit « tuer les jetons à longue durée de vie ».

Gérer la vraie co‑signature et la transparence IA sans chaos

Vous aurez des retours si la politique ressemble à du théâtre. Restez pratique :

• Pair programming : Autorisez Co‑Authored‑by pour des paires humaines sur le travail de feature, limité aux e‑mails d’entreprise sur liste blanche. Supprimez‑la sur les hotfixes et branches de release pour garder des pistes d’audit propres.
• Divulgation de l’assistance IA : Exigez que les développeurs notent « Assistance IA substantielle » dans les descriptions de PR avec deux puces : le nom de l’outil et le périmètre (p. ex. création d’une suite de tests). Aucun trailer au niveau des commits.
• Contributions upstream : Suivez les règles des mainteneurs en amont. S’ils exigent une divulgation IA dans le commit lui‑même, faites‑le uniquement dans ce fork, avec une exception documentée dans la PR et votre tracker interne.
• Voie d’exception : Offrez un processus d’exception dans la journée, détenu par DevEx ou un Staff Eng. Rien ne sape plus vite une politique qu’une release bloquée sans « adulte dans la pièce ».

Réalité nearshore : standardisez l’environnement, pas la personne

Les équipes distribuées amplifient la dérive de configuration. Le correctif n’est pas plus de réunions ; c’est moins de cas particuliers.

• Devboxes managées pour les contractors : Fournissez des devcontainers préconfigurés ou des postes de travail cloud avec vos hooks, modèles et politiques d’extensions préchargés. Pour des équipes US–Brazil, vous conservez 6–8 heures de recouvrement pour résoudre les cas limites dans la journée.
• Source unique de vérité : Gardez modèles, hooks et scripts d’application dans un dépôt interne centralisé et incrémentez une version dans chaque service. Les mises à jour passent par des PR, pas par un message Slack.
• Onboarding en 90 minutes : Pendant l’onboarding nearshore, incluez un atelier pratique : déclencher le contrôle des trailers, corriger un commit en échec et signer une release factice. C’est moins cher que de le découvrir lors d’un lancement critique.

Risques, arbitrages et ROI

Certains développeurs qualifieront cela de « nannyware » ? Oui. L’antidote, c’est la vitesse et la clarté. Les hooks doivent échouer vite avec un message utile ; les exceptions doivent être possibles et rapides ; et la politique doit privilégier la divulgation au niveau de la PR plutôt que des métadonnées de commit bruyantes.

Le ROI n’est pas spéculatif. Un historique propre et des releases signées raccourcissent les diligences, fluidifient les audits et réduisent les escalades « c’est quoi exactement cette ligne Copilot ? » venues du juridique. Pour la plupart des équipes, ce sont des jours gagnés à chaque cycle d’audit et moins de chaos le week‑end avant les grosses releases. Plus important encore, vous préservez votre optionnalité : vous pouvez consommer ou contribuer à des projets open source aux politiques IA incompatibles parce que vous contrôlez la façon dont l’attribution apparaît.

Et la prochaine « surprise » de votre IDE ?

Supposez que d’autres paramètres par défaut changeront sans prévenir — les éditeurs livrent vite, et l’UX du coding assisté par IA évolue chaque semaine. C’est acceptable si vous avez bâti des couches. Les hooks et modèles locaux captent la dérive, les contrôles côté serveur fixent le plancher, la politique définit l’intention, et la provenance prouve ce que vous avez livré. Vous pouvez adopter les outils sans adopter leurs métadonnées.

Points clés

• L’historique Git est une preuve légale et de supply chain. Traitez les métadonnées de commit comme une API dont vous êtes propriétaire.
• Ne comptez pas sur la vigilance individuelle. Empilez les couches : hooks locaux, application côté serveur, politique claire, et provenance alignée SLSA.
• Tenez l’attribution hors des trailers de commit. Placez la divulgation IA dans les descriptions de PR ; réservez les trailers au DCO et aux revues humaines.
• Exigez des commits signés sur les branches protégées et vérifiez les identités des bots et des humains.
• Standardisez les environnements de dev pour les équipes nearshore afin d’éviter la dérive des réglages. Livrez la politique « dans la box ».
• Préservez une voie d’exception. La vitesse et la clarté battent les interdictions générales à chaque fois.