Un matin, un agent IA prépare un commit à ma demande. Il a modifié les fichiers, exécuté les vérifications et s’apprête à enregistrer son travail dans Git, le logiciel qui conserve l’historique du projet.
Mais au moment de signer le commit, il s’arrête. Ma clé GPG est stockée sur une YubiKey, une clé physique protégée par un code PIN. Sans mon intervention, il ne peut pas terminer cette opération.
Cette interruption me paraît d’abord contraignante. Puis j’y vois un intérêt : l’agent prépare le changement, mais il lui manque mon accord pour l’enregistrer avec ma signature.
Quelques commits plus tard, pourtant, le PIN n’est plus demandé. Une seule saisie a permis plusieurs signatures.
Le point de contrôle existe donc, mais sa portée dépend du paramétrage.
Une signature ou plusieurs : un choix à assumer
Je peux demander une nouvelle intervention à chaque signature ou permettre à l’agent de poursuivre après une première autorisation.
Dans le premier cas, chaque commit crée une pause. Je peux regarder les modifications avant de laisser l’agent les enregistrer. C’est plus contraignant, parfois franchement barbant, mais cette interruption peut être utile.
Dans le second, le travail avance plus librement. Si je suis déjà les modifications au fil de leur production, revenir systématiquement à la clé peut ajouter de la friction sans améliorer mon contrôle.
Les deux choix se défendent. Ce qui me paraît problématique, c’est de croire que je valide chaque commit alors que mon autorisation couvre plusieurs signatures.
Et même avec une intervention systématique, rien ne garantit que j’examine réellement le travail. Je peux saisir le PIN ou toucher la clé machinalement. Le geste crée une occasion de vérifier ; il ne constitue pas la vérification.
La signature permet de vérifier l’utilisation d’une clé et l’intégrité du contenu signé. Elle ne prouve ni la relecture du code ni la qualité des tests.
Je pensais avoir compris la portée de cette protection. Un autre incident m’en a montré la limite.
L’agent n’avait pas besoin de ma clé
Alors que deux agents travaillaient sur le même dépôt, l’un a enregistré directement ses modifications sur main, la branche qui contient la version de référence du projet.
L’autre travaillait encore depuis mon poste sur une version devenue obsolète. Il a fallu remettre son travail à jour, mais une question m’a surtout arrêté : comment le premier avait-il créé ce commit sans solliciter ma YubiKey ?
Il avait emprunté un autre chemin.
Au lieu d’utiliser Git sur mon ordinateur, il avait écrit directement dans le dépôt distant avec le connecteur GitHub. Ma configuration locale de signature ne s’appliquait pas à cette opération.
L’agent n’avait pas forcé l’accès à ma clé. Il n’en avait simplement pas eu besoin.
J’avais protégé la signature sur mon poste, mais cette protection ne contrôlait pas toutes les manières de modifier le projet.
Ce constat changeait la question. Il ne suffisait plus de choisir à quelle fréquence je voulais intervenir. Il fallait aussi regarder où cette intervention devenait nécessaire.
Laisser produire, puis décider de l’intégration
Une branche de travail permet de garder les modifications de l’agent séparées de main. Il peut y expérimenter, tester et enregistrer des étapes intermédiaires sans modifier immédiatement la version de référence.
La pull request devient ensuite une proposition d’intégration : elle rassemble les changements, les résultats des contrôles et les échanges nécessaires à leur revue.
Ce fonctionnement me permet de déplacer mon attention. Plutôt que d’intervenir sur chaque commit préparatoire, je peux examiner l’ensemble du changement avant son intégration.
Mais la pull request ne rend pas, à elle seule, mon accord obligatoire. Si le dépôt autorise encore une écriture directe sur main, cette étape reste évitable. Et si l’agent dispose des droits nécessaires pour fusionner seul, il peut aussi franchir le passage que je pensais me réserver.
Le contrôle dépend donc des règles appliquées au dépôt et des permissions accordées à l’agent : passage obligatoire par une pull request, vérifications requises et accès à la fusion.
Il y a ici une limite à reconnaître : si l’agent agit avec mon compte et mes droits, la plateforme ne distingue pas automatiquement sa décision de la mienne. Une consigne donnée à l’agent peut organiser notre collaboration, mais elle n’équivaut pas à une restriction technique.
Ce que je veux garder entre mes mains
Je ne cherche pas à intervenir devant chaque opération. L’intérêt de l’agent est précisément de pouvoir lui confier un travail et le laisser avancer.
En revanche, je veux distinguer ce qu’il peut préparer seul de ce qui exige mon accord. La signature physique peut créer ce passage dans un fonctionnement local ; les règles de revue et de fusion peuvent le placer au niveau du dépôt.
Ces deux expériences m’ont donc amené à une question plus précise :
Mon accord est-il réellement nécessaire pour intégrer le travail, quel que soit le chemin utilisé par l’agent ?
C’est à cette question que mon organisation et mes réglages doivent répondre. Sinon, je risque de conserver la sensation du contrôle tout en ayant laissé un autre passage ouvert.
Réglages pratiques : Git et YubiKey
Activer la signature des commits dans Git
Pour reproduire ce fonctionnement, il faut distinguer deux réglages : Git demande la signature, tandis que GPG et la clé physique déterminent les conditions dans lesquelles elle peut être produite.
Avec une clé OpenPGP déjà configurée dans GPG, voici les commandes à exécuter depuis le dépôt :
git config --local gpg.format openpgp
git config --local user.signingkey EMPREINTE_DE_LA_CLE
git config --local commit.gpgsign true
Il faut remplacer EMPREINTE_DE_LA_CLE par l’empreinte de sa clé de signature. L’option --local limite ces réglages au dépôt courant ; --global les applique par défaut à tous les dépôts de l’utilisateur.
Git demande alors une signature pour chaque commit créé avec ce réglage. Cela ne signifie pas qu’il demandera le PIN ou un contact physique à chaque fois. Ce réglage est aussi une préférence locale, pas une règle de dépôt empêchant tout commit non signé.
Pour vérifier la signature du dernier commit :
git verify-commit HEAD
Choisir l’intervention demandée par la YubiKey
Avec YubiKey Manager (ykman) installé et une YubiKey compatible OpenPGP, on peut consulter la configuration :
ykman openpgp info
La politique du PIN propose deux modes alternatifs :
# Vérification du PIN à chaque signature
ykman openpgp access set-signature-policy always
# Vérification du PIN une fois par session de la carte
ykman openpgp access set-signature-policy once
Ces commandes règlent la vérification du PIN par la carte. La saisie effectivement demandée à l’écran dépend aussi de GPG et de sa gestion du PIN : elle ne doit pas être confondue avec un geste physique.
Pour exiger un contact avec la YubiKey à chaque utilisation de la clé de signature :
ykman openpgp keys set-touch sig on
Cette politique reste distincte de celle du PIN. Elle permet de conserver un déverrouillage pratique tout en exigeant un geste pour chaque signature. Ces réglages concernent aussi les autres signatures produites avec cette clé, pas seulement Git ; les commandes de modification peuvent demander le PIN administrateur.