Chaque matin, tu ouvres la même pull request à reviewer. Certains diffs viennent de ton collègue à Lyon, d'autres de l'agent IA que ta boîte a activé le trimestre dernier. Le code a la même tête. Le badge vert "Verified" a la même tête. Tu cliques sur Approve, tu sirotes ton café, et tu passes à autre chose.

Mais voilà le truc : quand un commit signé embarque une faille de sécurité à 2h du mat' et que le téléphone d'astreinte sonne, quelqu'un doit assumer. La signature sur ce commit pointe vers un bot. Un bot sans raison sociale, sans adresse postale, et absolument aucune intention de participer à ta réunion post-mortem.

La Signature Tombe

Le 3 avril 2026, GitHub a déployé la signature cryptographique des commits pour son agent cloud Copilot. On a couvert les détails produit hier, avec les contrôles des runners au niveau org et les autres mises à jour. Voici la partie dont personne n'a parlé : le vide juridique en dessous.

La signature cryptographique — une preuve mathématique qu'une entité spécifique a écrit un morceau de code spécifique — était déjà le standard pour les développeurs humains dans les entreprises sérieuses. Maintenant un bot a droit au même cérémonial. GitHub avait déjà ajouté le traçage des logs de session le 20 mars, reliant chaque commit d'agent à l'historique complet de sa conversation. Combine ça avec les contrôles des runners au niveau organisation sortis le même jour que la signature, et le message aux clients entreprise est limpide : laissez le bot commiter. On a sécurisé le truc.

La demande était ouverte depuis juin 2025, avec un utilisateur entreprise qui suppliait : "Notre organisation a >1 500 contributeurs, on ne peut pas, à cette échelle, coacher et expliquer ça." GitHub les a entendus. Est-ce qu'ils ont répondu à la bonne question, ça c'est une autre histoire.

Comment Ça Marche Concrètement

Chaque commit de l'agent cloud porte désormais une signature cryptographique — même format GPG ou SSH que les humains utilisent. Sur GitHub, ça s'affiche avec le badge vert "Verified" qu'on connaît. Les métadonnées du commit listent Copilot comme auteur et l'humain qui a assigné la tâche comme co-auteur. L'URL du log de session se trouve dans une ligne trailer en bas du message de commit.

Ça a résolu un vrai problème pénible : les repos avec des règles de protection de branche ne pouvaient tout simplement pas utiliser l'agent cloud avant, parce que les commits non signés se faisaient recaler à l'entrée. Maintenant le bot passe le videur. La piste d'audit est propre, inaltérable, et techniquement identique à ce qu'un développeur humain produit.

Techniquement identique. Juridiquement ? C'est là que la comédie commence.

Le Trou Noir de la Responsabilité

C'est là que ça devient gênant. Une signature cryptographique répond à la question quoi a écrit le code. Elle ne répond pas — et ne peut pas répondre — à :

  • À qui appartient le copyright ? Le Copyright Office américain maintient toujours que le contenu généré par IA manque de paternité humaine. Si aucun humain n'a "participé de manière substantielle", il se peut qu'il n'y ait tout simplement pas de droit d'auteur. Ta boîte vient de livrer du code qui n'appartient peut-être à personne.
  • Qui porte la responsabilité d'une faille de sécurité ? La propre documentation sur les risques de GitHub liste quatre catégories de risques et exige une revue humaine pour toutes les PR — mais ne contient aucun mot sur qui est réellement responsable. Ils ont construit la piste d'audit et oublié de mettre quelqu'un au bout.
  • Qui répond lors du post-mortem ? Le co-auteur — l'humain qui a tapé "corrige le bug de login" dans une zone de texte ? Le reviewer qui a approuvé la PR à 16h47 un vendredi ? Le RSSI qui a activé l'agent pour toute l'organisation parce qu'un slide deck d'un commercial disait "productivité" ?

La piste d'audit est parfaite. La chaîne de responsabilité est vide.

Le Problème de Fragmentation

Ça empire quand tu prends du recul — et franchement, ça devient absurde. Chaque outil de coding IA majeur gère l'identité des commits comme un étudiant qui a séché la réunion de groupe et improvisé sa partie :

  • GitHub Copilot cloud agent : Signature cryptographique, Copilot comme auteur, humain comme co-auteur, URL du log de session
  • Claude Code : Ajoute un trailer Co-authored-by, pas de signature cryptographique
  • OpenAI Codex : Trailer co-auteur similaire via un git hook, pas de signature
  • Cursor, Devin : Aucune attribution standardisée — ton historique git dit juste que c'est toi qui as tout écrit

Si ta boîte utilise plus d'un de ces outils — et c'est le cas de la plupart — ton historique git contient désormais trois ou quatre schémas d'attribution incompatibles. Un article de recherche qui sera présenté à MSR '26 (13-14 avril 2026) a analysé 33 580 pull requests et a trouvé que les agents IA peuvent être identifiés avec 97,2 % de précision juste à partir des patterns de commit. Les machines sont identifiables même quand elles ne se déclarent pas. Mais aucun standard inter-plateformes n'existe pour définir à quoi cette empreinte devrait ressembler.

Ton équipe conformité vient d'hériter d'un bazar dont personne ne les a briefés. Félicitations à eux.

Ce Que Ça Change Pour Toi

Si ton organisation utilise l'agent cloud de GitHub — et avec ces contrôles entreprise, l'adoption est sur le point d'exploser — ton historique git contient déjà des commits IA signés mélangés avec des commits humains signés. Tes playbooks juridiques, tes checklists de conformité, tes procédures de réponse aux incidents traitent presque certainement chaque commit signé comme étant sous la responsabilité d'un humain. Parce que jusqu'à il y a neuf jours, c'était le cas.

Les exigences de transparence de l'Article 50 du AI Act européen entrent en vigueur le 2 août 2026. Ça te laisse quatre mois pour déterminer si un badge "Verified" d'un bot satisfait les mêmes attentes réglementaires qu'un badge "Verified" de ton ingénieur senior. Quatre mois, ça semble largement suffisant jusqu'à ce que tu te rappelles combien de temps ta dernière revue de politique interne a pris.

La Nouvelle Réalité

Pendant trente ans, le log git était un registre de paternité — qui a écrit quoi, quand, et (si tu plissais les yeux sur le message de commit) pourquoi. GitHub vient de le transformer en autre chose : un registre qui inclut la non-paternité, où le signataire est vérifiable mais pas responsable, identifiable mais pas redevable, et traçable jusqu'à une conversation qu'aucun cadre juridique ne sait interpréter.

La signature est réelle. La responsabilité derrière ne l'est pas. Et tes politiques internes n'ont pas rattrapé le coup — mais le 2 août se fiche pas mal de ton backlog.