Vous savez ce qui m’a toujours ennuyé avec git blame ? C’est qu’à chaque refactoring, chaque reformatage de code, chaque déplacement de fichier, tous les noms disparaissent pour être remplacés par celui de la personne qui a fait ces modifications. Du coup, impossible de savoir qui a vraiment écrit le code original. Heureusement, un développeur nommé Sinclair Target vient de sortir un outil qui résout ce problème.

git-who (c’est son nom) fait donc exactement ce que git blame aurait dû faire depuis le début à savoir analyser qui a vraiment contribué à votre codebase, et pas juste qui a touché les lignes en dernier. Au lieu de se contenter d’une analyse ligne par ligne comme git blame, git-who analyse les patterns de contribution sur des fichiers entiers, des dossiers, voire des composants complets.

L’installation est simple comme bonjour. Si vous êtes sur Mac avec Homebrew, un petit brew install git-who et c’est réglé. Pour les autres, vous pouvez passer par Go avec go install github.com/sinclairtarget/git-who@latest ou compiler depuis les sources si vous aimez les défis. Docker est aussi supporté pour ceux qui préfèrent…

Ce qui rend git-who vraiment intéressant, c’est ses trois modes d’analyse. Le mode table (par défaut) vous donne un tableau récapitulatif des contributions par auteur, triable par nombre de commits, lignes de code, fichiers touchés ou date de modification. C’est pratique pour identifier rapidement qui sont les principaux contributeurs d’un projet. Le mode tree affiche l’arborescence du projet avec le contributeur principal annoté pour chaque fichier et dossier. Et le mode hist génère une timeline de l’activité des commits avec le top contributeur par période.

Pour vous donner une idée concrète, Sinclair Target a fait une démo sur le projet Vim pour analyser les patterns de maintenance après le décès de Bram Moolenaar. L’outil a permis d’identifier rapidement qui avait pris le relais sur différentes parties du code. C’est quelque chose qu’il aurait été impossible à voir clairement avec un git blame classique.

La différence fondamentale donc avec git blame, c’est que git-who “comprend” le contexte. Si quelqu’un déplace un fichier ou fait un reformatage massif, git blame lui attribuera toutes les lignes alors git-who, lui, va chercher plus loin dans l’historique pour identifier les véritables auteurs du code. Il respecte même les fichiers .mailmap pour consolider les identités multiples d’un même développeur et prend en compte le fichier .git-blame-ignore-revs pour ignorer certains commits de maintenance.

Pour utiliser git-who, il suffit de faire un git who à la racine de votre projet afin d’obtenir l’analyse de base. Vous pouvez filtrer par chemin avec git who Parser/ pour analyser seulement un dossier spécifique. Le tri est customisable avec des options comme -l pour trier par lignes de code ou -m pour la date de dernière modification. Et pour une vue historique entre deux versions, git who hist v3.10.9..v3.11.9 fait le job.

Bien sûr, git-who n’est pas le seul dans sa catégorie. GitLens pour VS Code reste l’extension la plus populaire, offrant une intégration visuelle directement dans l’éditeur. Git Quick Stats est aussi une autre alternative en ligne de commande qui propose des statistiques détaillées sur les repositories. Mais aucun ne va aussi loin que git-who dans l’analyse de la véritable propriété du code.

Qui maintient réellement cette partie critique du code ? Quelle équipe a le plus contribué à ce module ? Comment les contributions ont évolué au fil du temps ? Git-who vous aide à répondre à ces questions essentielles sur la gestion de votre projet, les audits de code ou simplement pour comprendre l’histoire d’un projet open source.

Bref, j’ai trouvé ça cool… Et qui sait, peut-être qu’un jour git-who sera intégré directement dans Git ?

Pendant que vous lisez cet article, Jules pourrait être en train de corriger les bugs présent dans votre code. Non, c’est pas une blague, c’est le nouveau délire de Google qui vient de sortir de beta. Jules, c’est un agent IA qui code vraiment tout seul, et franchement, après l’avoir testé, je commence à me demander si le métier de dev a encore un avenir.

Vous créez une issue GitHub avec le label “jules”, vous partez boire un café (ou vous taper une petite sieste), et quand vous revenez, hop, une pull request toute propre vous attend. Tests écrits, dépendances mises à jour, et bugs corrigés. Jules a tout fait pendant que vous vous tourniez les pouces.

Ce qui rend Jules différent de Copilot et consorts c’est qu’il ne se contente pas de compléter votre code ou de suggérer des snippets. Non, non. C’est un véritable agent autonome qui clone votre repo dans une VM Google Cloud sécurisée et se met au boulot tout seul. Sous le capot c’est Gemini 2.5 Pro, donc il comprend le contexte global de votre projet et peut enchaîner plusieurs tâches complexes.

L’intégration GitHub est particulièrement soignée. Jules peut créer ses propres branches, ouvrir des pull requests avec des commits propres et même générer des changelogs audio. C’est fou ça, des changelogs audio. Faut croire que lire en 2025 c’est has been…

Pour l’utiliser, c’est simple comme bonjour. Vous vous connectez sur jules.google.com (avec votre compte Google, évidemment), vous liez votre GitHub, et c’est parti. Le bouton “Give a plan” lance le processus de réflexion de Jules qui vous soumettra alors son grand projet pour vous. Et si ça vous convient, vous validez et il se met au travail.

Comme Jules fonctionne de manière totalement asynchrone, vous pourriez être en train de jouer à Baldur’s Gate 3 qu’il continuerait tranquillement de refactoriser votre code tout pourri.

Les fonctionnalités qui tuent c’est d’abord, les mises à niveau de version. Terminées les heures passées à vérifier la compatibilité et à ajuster le code pour la dernière version d’une lib. Jules s’en charge. L’écriture de tests, cette tâche aussi cruciale que chiante, Jules la fait. Et en plus, il le fait bien, le bougre.

Niveau langages supportés, c’est du lourd : Node.js, Python, Go, Java et Rust. Par contre, pas de PHP pour l’instant. Désolé les warriors du web de 2005. Google promet d’autres langages bientôt, mais on connaît leurs promesses…

Bon, parlons fric maintenant. Google a sorti trois forfaits. Y’a le plan gratuit qui vous donne 15 tâches par jour et 3 simultanées. C’est déjà pas mal pour tester. Le Pro multiplie les limites par 5, et l’Ultra par 20 pour les gros projets avec du multi-agent.

Un truc important sur la privacy, c’est que si votre repo est public, Google peut utiliser vos données pour entraîner l’IA. Et si c’est privé, rien n’est envoyé. En tout cas, c’est ce qu’ils disent.

Google est tellement confiant qu’ils vont l’utiliser sur leurs propres projets.

Alors est-ce que Jules va remplacer les développeurs ? Non, je crois pas, mais il va clairement changer notre façon de travailler car au lieu de passer des heures sur des tâches répétitives, on pourra se concentrer sur l’architecture, la créativité, les vrais problèmes complexes. Et lui s’occupera du sale boulot.

Par contre, si vous êtes le genre de dev qui se contente de copier-coller du Stack Overflow, là oui, commencez à chercher une reconversion. Car Jules fait ça mieux, plus vite, et il ne se plaint jamais du montant de ses tickets resto.

Merci à Lorenper pour la découverte !

Une vaste campagne malveillante cible depuis plusieurs mois les gamers, hackers amateurs et chercheurs en cybersécurité en diffusant sur GitHub des outils piégés contenant des portes dérobées. L’opération, révélée par les chercheurs de Sophos, se distingue par son ampleur et ses méthodes sophistiquées.