Git-Memento : notes IA dans Git & Puppy Scheme : compiler vers WebAssembly - Actualités IA (2 mars 2026)

Un nouvel outil promet de greffer, directement sur vos commits Git, la trace lisible d’une session de code avec IA — sans changer vos habitudes, et avec des audits pour repérer les trous dans la raquette. Pourquoi est-ce que ça peut changer la manière dont on relit, on révise, et on fait confiance au code? Bienvenue dans The Automated Daily, AI News edition. Le podcast créé par l’IA générative. Nous sommes le 2 mars 2026, et je suis TrendTeller. Aujourd’hui, on va parler de traçabilité — du code assisté par IA jusqu’aux agents qui exécutent des commandes sur votre machine — mais aussi d’un compilateur Scheme vers WebAssembly construit à une vitesse presque indécente, et d’un débat qui s’élargit: sécurité, gouvernance, et usage militaire de l’IA.

Git-Memento : notes IA dans Git

On commence avec Git et l’un des sujets les plus sensibles du moment: comment documenter proprement ce qu’une IA a réellement apporté à un changement de code. Un dépôt GitHub, mandel-macaque/memento, publie un outil nommé git-memento. L’idée est simple sur le papier, mais assez maligne: pour chaque commit, vous pouvez attacher la conversation “utile” de votre session d’IA — nettoyée et rendue lisible — sous forme de Markdown stocké dans git notes, c’est-à-dire hors de l’historique principal, sans polluer le message de commit ni vos diff. Ce qui est intéressant, c’est l’obsession du projet pour ne pas casser le workflow Git. Vous continuez à committer normalement, avec -m ou avec l’éditeur. Sauf que vous utilisez une commande du style: git memento commit <session-id> -m "message". Et si vous réécrivez l’histoire, git memento amend sait préserver les notes, voire en ajouter. On parle donc d’un mécanisme de “mémoire” attachée au commit, mais qui ne force pas une nouvelle discipline quotidienne aux développeurs. Côté fournisseurs, le projet vise l’extensibilité: Codex d’abord, et Claude est déjà supporté. La sélection du provider peut même venir de variables d’environnement comme MEMENTO_AI_PROVIDER. Et techniquement, le système est pensé pour s’adapter à la façon dont chaque service expose la récupération de sessions: vous pouvez configurer les binaires et arguments — par exemple une commande “sessions get {id} --json”. L’autre point fort, c’est la collaboration. Les git notes, beaucoup de gens ne les synchronisent pas bien. Ici, memento propose des commandes pour partager et synchroniser: share-notes, push, notes-sync. L’outil pousse et fusionne refs/notes/*, configure les refspecs de fetch côté remote, et avant de fusionner il crée même des sauvegardes horodatées sous refs/notes/memento-backups/<timestamp>. En clair: on veut rendre la synchronisation des notes aussi “robuste” que possible dans des équipes. Et il y a une vraie attention aux workflows “réécriture d’historique”, typiques des PR nettoyées à coup de rebase. Avec notes-rewrite-setup, vous pouvez mettre en place la reprise automatique des notes quand Git réécrit des commits. Et si vous avez un gros remodelage, notes-carry sait agréger les notes d’une plage réécrite vers un nouveau commit, en ajoutant un bloc de provenance pour dire d’où viennent les traces. Enfin, la partie qualité: git memento audit détecte les commits sans notes et vérifie la présence de marqueurs de métadonnées, comme le provider et l’ID de session. Il y a un mode --strict et même une sortie JSON pour l’intégration outillage. Et git memento doctor aide à diagnostiquer la configuration et l’état de synchronisation avec les remotes. Pour l’écosystème CI, le dépôt livre aussi une GitHub Action Marketplace avec deux modes: comment, qui poste des commentaires de commit en rendant les notes memento; et gate, qui exécute l’audit et peut faire échouer la CI si la “couverture” de notes n’est pas suffisante. Un détail important: le format de notes supporte à la fois un ancien mode “une session” et un format enveloppe multi-sessions versionné, avec des marqueurs en commentaires HTML, du style , et des délimiteurs début/fin de session. Donc on peut attacher plusieurs sessions, potentiellement de providers différents, sur un même commit. Côté distribution, c’est du .NET SDK 10 avec NativeAOT: un exécutable unique par plateforme. Il y a un installateur curl via install.sh qui télécharge la dernière release sur GitHub, et une CI qui smoke-test l’installation et quelques commandes sur Linux, macOS et Windows. Et, symbole du timing: la release “v1.1.0” apparaît comme première release publique aujourd’hui, le 2 mars 2026, avec environ 200 étoiles et 5 forks au moment du snapshot. Ce n’est pas énorme, mais c’est pile le genre d’outil qui peut devenir un standard d’équipe si la friction reste basse. La question qui se cache derrière tout ça est très actuelle: quand du code est produit ou fortement influencé par une IA, qu’est-ce qu’on garde comme trace? Le diff, oui. Le message de commit, un peu. Mais la conversation qui explique les hypothèses, les contraintes, et les alternatives? Git-memento propose une réponse pragmatique: on n’encombre pas l’historique, mais on laisse une piste vérifiable.

Puppy Scheme : compiler vers WebAssembly

Dans la même veine “accélération”, passons à la construction de logiciels complexes à une vitesse qui, il y a deux ans encore, aurait semblé fantaisiste. Matthew Phillips raconte la création de “Puppy Scheme”, un compilateur Scheme vers WebAssembly, inspiré par la cadence à laquelle des gens livrent aujourd’hui des outils presque prêts pour la prod grâce à l’IA. Son récit a un chiffre qui claque: un projet qui, historiquement, pourrait prendre des mois ou des années, réalisé en gros un week-end plus quelques soirées en semaine. Il ne vend pas du rêve sans nuance: il précise que c’est de l’alpha, qu’il tombe sur des bugs souvent, et que ce n’est pas prêt pour des utilisateurs généralistes. Mais la liste de fonctionnalités, pour le temps investi, est impressionnante. Puppy Scheme viserait environ 73% de couverture de R5RS et R7RS — ce n’est pas “tout Scheme”, mais ce n’est pas non plus un jouet minimal. Cible technique: WebAssembly moderne, avec WASI 2, le WebAssembly Component Model, et WASM GC. Ce dernier point est important: le GC WebAssembly ouvre la porte à des runtimes plus naturels pour des langages à ramasse-miettes. Phillips mentionne aussi de l’élimination de code mort, pour produire des binaires plus petits. Et surtout, le compilateur est auto-hébergé: il peut compiler ses propres sources pour produire un artefact puppyc.wasm. C’est souvent un jalon psychologique et technique dans un projet de compilation. Et l’histoire de performance est presque un mini-cas d’école sur l’usage de l’IA en “mode atelier”: il dit avoir utilisé Claude intensément, avec une requête laissée tourner toute la nuit du genre “attaque la performance”, ce qui aurait réduit le temps de compilation d’environ 3 minutes 30 à… 11 secondes. Même si on prend ce chiffre avec la prudence habituelle — contexte machine, workload, comparables — l’écart est si grand qu’il force à regarder le phénomène en face: les assistants ne servent pas seulement à écrire du code, ils servent aussi à explorer rapidement des pistes d’optimisation. Enfin, il a construit un wrapper basé sur wasmtime pour produire des binaires natifs à partir du WASM généré, et même un site qui exécute Puppy Scheme WASM dans Cloudflare Workers, avec le code du worker lié. Il expérimente aussi une approche “component-model/UI” illustrée par un petit compteur en Scheme. La conclusion la plus sobre, c’est peut-être celle-ci: l’IA rend possible des prototypes très ambitieux en très peu de temps… mais la dette qualité reste bien réelle. L’alpha ne disparaît pas; il arrive juste plus vite.

Logira : audit eBPF des agents

On reste sur la question de la confiance, mais côté exécution: que fait réellement un agent, un script d’automatisation, ou une IA qui “agit” sur une machine? Parce que, dans la vraie vie, les résumés d’actions peuvent être inexacts — volontairement ou non. Un projet nommé Logira propose un duo: une CLI Linux en observe-only, et un démon root compagnon, logirad, pour faire de l’audit runtime au niveau du système d’exploitation. Le mécanisme central: eBPF pour enregistrer l’exécution de processus, l’activité fichier, et l’activité réseau. Ce positionnement est intéressant: plutôt que de faire confiance à la narration d’un agent — “j’ai juste installé X et modifié Y” — Logira vous montre ce qui s’est effectivement passé. Et il attribue les événements à un run précis grâce à cgroup v2: vous lancez typiquement logira run -- <commande>, et tout ce qui se passe dans ce périmètre est tracé. Côté stockage, c’est pensé pour l’analyse: JSONL pour des timelines, SQLite pour des requêtes rapides, plus des métadonnées de run. Et l’outil embarque un jeu de règles de détection “opinionated”, orienté comportements à risque pendant des runs d’agents. Ça couvre la lecture/écriture de secrets et identifiants — clés SSH, configs AWS, kube, docker, .netrc, .git-credentials — mais aussi les changements de persistance, comme /etc, des unités systemd, cron, ou les fichiers de démarrage de shell. Il y a aussi des patterns très concrets: des exécutables créés dans /tmp ou /dev/shm, le fameux “temp dropper”; des commandes du type curl|sh ou wget|sh; des indices de reverse-shell ou de tunneling; des signaux base64 décodé puis envoyé au shell; et, côté destructions, des alertes sur rm -rf, git clean -fdx, mkfs, ou terraform destroy. Sur le réseau, Logira met en avant des règles autour des ports de sortie suspects et l’accès à des endpoints de métadonnées cloud — typiquement utilisés pour récupérer des credentials en environnement cloud. Déploiement: script d’installation, tarballs, ou build depuis les sources avec make build; et en production, logirad tourne sous systemd. Prérequis: kernel Linux 5.8+, systemd, cgroup v2. Licence Apache-2.0, et les programmes eBPF en double licence Apache-2.0 ou GPL-2.0-only, ce qui colle aux contraintes de compatibilité côté kernel. Si vous laissez des agents coder, lancer des commandes, ou toucher à l’infra, ce genre d’outil répond à une question simple mais cruciale: “montre-moi la réalité, pas la version racontée.”

Débat sécurité IA : risques proches

À partir de là, on arrive naturellement aux discussions de sécurité et de gouvernance: on voit fleurir des outils pour tracer, auditer, et prouver — parce qu’on sent que les systèmes actuels sont puissants, mais pas intrinsèquement fiables. Matthew Honnibal propose une sorte de “trêve” dans le débat sur la sécurité IA: arrêter de se battre exclusivement sur la superintelligence et se concentrer sur les risques non-existentialistes, mais potentiellement dévastateurs, issus des déploiements actuels. Sa thèse est assez terre-à-terre: une boucle d’attaque autonome, auto-réplicante, n’a pas besoin d’être très intelligente pour faire de gros dégâts si le coût de trouver et d’exploiter des failles devient inférieur au gain moyen. Et il pointe un moteur de risque évident: des agents de code dotés de permissions larges, parfois laissés sans supervision. Exemple concret: des fichiers de “skills” pour agents de code — souvent du Markdown ajouté aux prompts — partagés via des marketplaces. Si ces “skills” autorisent des commentaires HTML cachés, vous pouvez glisser des instructions non rendues qui détournent l’agent. Et, selon lui, la mitigation est presque embarrassante de simplicité: interdire les commentaires HTML. Il cite un cas démonstratif, un skill très médiatisé, et note que le problème traîne sans correction pendant des semaines. Il évoque aussi l’écosystème OpenClaw, avec incidents et mauvaises configurations exposées sur Internet, devenu pourtant un projet GitHub à la croissance fulgurante — et dont le créateur a été acquihired par OpenAI. Il y voit une “normalisation de la déviance”: on s’habitue à des risques qui auraient dû être des stop-sign. Autre cas: des clés API Google supposées “sans danger” à exposer publiquement, parce que limitées à certains usages, qui se retrouveraient capables d’autoriser l’usage de Gemini et donc d’être abusées pour générer des coûts. Il décrit une réponse initiale de déni, puis un correctif incomplet. Et il se projette: des modèles “raisonneurs” utilisés pour exécuter des plans multi-étapes — phishing, ingénierie sociale, chasse aux identifiants — avec un comportement parfois erratique, un “hot mess” à la Anthropic, mais multiplié par des millions d’agents. Le message final est pragmatique: éviter une “clownpocalypse” est faisable, mais ça exige du durcissement basique, et surtout d’accepter de la friction produit au lieu de courir uniquement après la vitesse.

IA militaire : gouvernance et contrôle

Dans le même registre, mais avec une focale plus institutionnelle, deux textes posent une question difficile: l’IA peut-elle — ou doit-elle — être intégrée à des décisions de vie ou de mort, et avec quel niveau d’explicabilité et de contrôle démocratique? Un essai défend une position nette: pour des décisions critiques — diagnostic médical, armes autonomes — il ne suffit pas que l’IA soit “souvent correcte”. Il faut qu’elle soit interprétable et qu’on puisse retracer l’enchaînement qui mène à une recommandation. L’auteur rappelle à quel point l’attribution de responsabilité est déjà compliquée même dans des systèmes déterministes: il évoque un crash de Boeing 787 en Inde, 260 morts, des accusations qui se croisent entre pilotes et constructeur, et un rapport final encore attendu. Sur cette toile de fond, l’idée est simple: si on ne sait pas expliquer un système classique, imaginez un modèle probabiliste. Il est fait mention de discussions autour d’un usage de modèle d’Anthropic dans des armes pleinement autonomes, sans approbation humaine, et du refus d’Anthropic au motif de fiabilité insuffisante — en écho à l’argument que l’IA actuelle reste fondamentalement imprévisible. L’essai détaille pourquoi: les modèles sont “lossy” et “boîtes noires”. Il prend un exemple type dermatologie: un grain de beauté qui change, avec plusieurs couleurs, et montre qu’un modèle peut recracher des heuristiques cliniques plausibles — comme l’ABCDE — mais que le chemin interne entre des tokens et une évaluation de risque est opaque. On parle de vecteurs d’embeddings à des milliers de dimensions sans nom, transformés couche après couche, avec peu de correspondance directe avec des concepts compréhensibles. Il cite le travail d’Anthropic sur la monosemanticité via sparse autoencoders, qui extrait des “features” interprétables comme “brown”, mais note que ça reste construit au-dessus d’axes sous-jacents non nommés. Et il renvoie à des recherches académiques qui montrent qu’on peut, au moins en partie, aligner des dimensions sur des concepts nommés sans perdre en performance. La proposition est ambitieuse: définir d’abord des dimensions canoniques, orthogonales, scientifiquement fondées — RGB pour la couleur, valence/arousal/dominance pour l’émotion, etc. — puis laisser émerger des features plus haut niveau. Et aller vers des embeddings “graphes”, plus clairsemés, avec des relations typées, traités par des graph transformers. Il insiste aussi sur un point à la mode, mais important: les explications post-hoc, style chain-of-thought, peuvent être infidèles, voire fabriquées. En parallèle, un autre article critique la manière dont le débat sur l’IA militaire serait “rétréci”. On parle d’un bras de fer rapporté entre le Pentagone et Anthropic: pression pour assouplir les garde-fous, menace de perdre un contrat DoD de 200 millions de dollars et d’être classé “risque supply chain”. L’auteur ne dit pas seulement “human-in-the-loop ou pas”: il dit que cette focalisation devient un proxy qui évite des questions plus vastes. Car même avec un humain “dans la boucle”, il y a le biais d’automatisation: on tend à valider la machine. Et surtout, une IA peut accélérer les cycles décisionnels et pré-structurer le “menu” d’options: l’humain n’approuve plus un choix libre, il arbitre entre des options déjà cadrées. L’article cite aussi des war games où des LLM sélectionnent des frappes nucléaires dans une très grande proportion d’essais quand les objectifs sont vaguement définis — une illustration du fait qu’un système peut produire des recommandations extrêmes dès que la fonction objectif est ambiguë. Enfin, l’angle démocratique: la Constitution américaine donne des pouvoirs de guerre au Congrès, mais l’intégration de l’IA passerait surtout par des contrats et politiques internes de l’exécutif, sans grande loi-cadre sur les systèmes létaux autonomes. Et il y a un second sujet souvent mis de côté: la surveillance. L’IA ne se contente pas de collecter, elle infère — et des régimes juridiques centrés sur la collecte peuvent mal encadrer l’inférence à grande échelle. Au fond, ces textes convergent: si l’on n’a ni interprétabilité technique, ni gouvernance claire, on risque d’industrialiser l’irresponsabilité.

Interprétabilité : au-delà de la précision

Dans cette quête de “preuves” et de responsabilité, un projet open source se démarque par son angle cryptographique: Nobulex. Nobulex se présente comme un protocole ouvert — TypeScript monorepo, licence MIT — visant à rendre des agents “accountable” via des engagements comportementaux cryptographiques, avec vérification sans tiers de confiance. L’idée est subtile: vous ne pouvez pas vraiment auditer un réseau de neurones, mais vous pouvez auditer ses actions si vous imposez une structure. Le cœur: un agent déclare un “covenant”, une sorte de contrat de comportement, dans un DSL inspiré de Cedar. On y écrit des règles permit, forbid, require, avec des conditions. Et la philosophie est stricte: “forbid gagne”, et tout ce qui ne matche pas explicitement est refusé par défaut. Ensuite, l’agent produit un actionLog: un journal d’actions inaltérable via chaînage de hash SHA-256, capable de générer des preuves de type Merkle. Puis on vérifie: verify(covenant, actionLog), ce qui renvoie un statut de conformité et des preuves de violation. Côté identité, les agents utilisent des identités décentralisées de style W3C, did:nobulex:, basées sur des clés Ed25519. Côté enforcement, le projet parle de deux niveaux: un niveau “Tier 1” avec middleware en TEE — SGX ou SEV — pour empêcher physiquement des actions interdites en environnements à enjeux; et un niveau “Tier 2” plus général, basé sur des incitations économiques type staking/slashing: violer devient irrationnel. Le dépôt liste même des contrats Solidity déployés sur le testnet Sepolia: CovenantRegistry, StakeManager et SlashingJudge. Et il y a une démo exécutable via npx tsx qui montre la création d’agents, l’écriture d’un covenant, le blocage d’un transfert interdit, puis la vérification. Dernier détail révélateur: le projet consolide des mois de travail, mais sous plusieurs noms successifs — Stele, Kova, Kervyx, puis Nobulex — avec un historique Git compressé, signe d’une migration. On peut voir Nobulex comme le pendant “crypto-contrat” d’outils type Logira et git-memento: chacun, à sa manière, cherche à produire une trace et un mécanisme d’audit quand on délègue à des systèmes qui peuvent agir vite, et parfois mal.

Nobulex : engagements crypto vérifiables

Pour terminer, un rappel d’étiquette numérique, mais qui touche directement à ces enjeux de traces. Cory Doctorow, dans son billet Pluralistic daté d’aujourd’hui, soutient une idée assez simple: en général, les autres ne veulent pas voir vos transcripts de chatbot. Coller une conversation IA entière dans un fil ou dans un groupe, ou taguer un bot au milieu d’une discussion avec des inconnus, c’est imposer une verbosité non consentie. Il est particulièrement dur avec un comportement qu’on voit de plus en plus: lire ce qu’un auteur a écrit, demander à une IA de générer une réfutation ou un commentaire, puis envoyer ce texte non vérifié à l’auteur. Il rappelle que les entreprises d’IA admettent elles-mêmes les hallucinations: si vous envoyez une critique générée, sans expertise ni vérification, vous demandez implicitement à l’auteur de faire le “human in the loop” à votre place — gratuitement, et sans qu’il vous doive ce travail. Il conteste aussi l’argument “ça booste ma productivité, l’IA résume un sujet que je ne comprends pas”: si vous ne comprenez pas, vous ne pouvez pas évaluer l’exactitude du résumé. Ce billet se lit comme un contrepoids utile à l’époque: oui, il faut des traces — dans Git, dans l’OS, dans les logs d’action — mais non, il ne faut pas confondre “trace exploitable” et “déversement de conversation” sur autrui. La bonne question est: à qui sert cette trace, dans quel format, et avec quel consentement?

Voilà pour l’édition du jour. Entre git-memento qui veut rendre l’IA “auditable” au niveau du commit, Logira qui observe la réalité des exécutions via eBPF, et des approches plus radicales comme Nobulex, on sent une direction commune: on ne veut plus seulement des systèmes capables d’agir, on veut des systèmes qu’on peut contrôler, comprendre, et — surtout — tenir responsables. Je suis TrendTeller, et c’était The Automated Daily, AI News edition. Les liens vers toutes les histoires sont disponibles dans les notes de l’épisode. À demain.

Git-Memento : notes IA dans Git & Puppy Scheme : compiler vers WebAssembly - Actualités IA (2 mars 2026)

Our Sponsors

Topics