Tout ingénieur qui a déjà tenté de relire une grosse pull request sur GitHub connaît ce moment : la vue de diff se fige, les boîtes de commentaires lagguent, et la mémoire du navigateur explose pour les dix prochaines minutes. Plus la PR est grosse, pire est l'expérience. Sur mobile, le navigateur plante carrément dès quelques milliers de lignes.
Le 20 mai 2026, une petite équipe nommée Pierre Computer Company a discrètement publié la réponse : DiffsHub. En vingt-quatre heures, le tweet de lancement dépassait 52 000 posts, le dépôt GitHub franchissait les 4 500 étoiles, et la timeline des développeurs traitait le moteur de diff natif de GitHub de "skill issue". L'argument est désarmant : prenez l'URL GitHub que vous regardez déjà, remplacez github.com par diffshub.com, et regardez un diff d'un million de lignes s'afficher presque instantanément.
C'est l'un de ces rares lancements de produit développeur qui sont à la fois un coup marketing et un vrai morceau d'ingénierie. Voici ce qui se passe réellement sous le capot, pourquoi cela compte pour vos équipes, et comment intégrer la bibliothèque sous-jacente dans vos propres produits.
L'astuce d'une seule ligne
La magie côté utilisateur est une simple réécriture d'URL. N'importe quel diff GitHub public, qu'il s'agisse de pull request, de commit, de comparaison ou de patch, peut s'ouvrir sur diffshub.com en modifiant exactement un mot dans l'URL.
https://github.com/oven-sh/bun/pull/12345
https://diffshub.com/oven-sh/bun/pull/12345
C'est tout. Pas de connexion, pas d'extension, pas de configuration. DiffsHub récupère les mêmes données publiques que GitHub expose, puis les affiche via les composants de Pierre. Quelques heures après le lancement, la communauté avait déjà sorti une extension Chrome qui fait la redirection automatiquement, et un adaptateur GitLab qui branche la même interface sur les merge requests GitLab.
Pour les dépôts privés, l'histoire est différente. DiffsHub est un service public, il ne peut pas franchir votre SSO. Le mouvement intéressant pour les équipes est d'intégrer directement la bibliothèque sous-jacente — ce que Pierre encourage explicitement.
Ce que Pierre a réellement construit
DiffsHub est en réalité une mince application web posée au-dessus d'une bibliothèque open source bien plus intéressante : @pierre/diffs, actuellement en version 1.2.1 sur npm. Elle fait partie du monorepo pierrecomputer/pierre sur GitHub et alimente exactement le même moteur que le produit hébergé de Pierre.
La bibliothèque repose sur trois idées que le moteur de rendu actuel de GitHub n'optimise pas :
- Défilement virtualisé. Seules les lignes visibles dans la fenêtre sont montées dans le DOM. Un diff d'un million de lignes ne crée pas un million d'éléments, il en crée quelques centaines et les recycle pendant le défilement.
- CSS Grid plus Shadow DOM. Les vues côte à côte et unifiée utilisent CSS Grid pour aligner ajouts et suppressions, tandis que Shadow DOM isole les styles du diff de la page hôte. Cette isolation est ce qui permet de poser le composant dans une app Next.js, Remix ou Vite sans qu'il n'hérite de la moitié des styles globaux.
- Shiki pour la coloration syntaxique. Les thèmes ne sont pas figés. Les diffs s'adaptent à n'importe quel thème Shiki, ce qui veut dire que vos tokens de marque actuels arrivent directement dans la vue diff.
Au-dessus de cette base, la bibliothèque ajoute des annotations et commentaires n'importe où sur le diff, la sélection de lignes au clic-glisser, des callbacks au survol des tokens pour des tooltips, le surlignage inline au niveau du caractère, et une interface de résolution de conflits de merge. Elle est aussi explicite sur le fait qu'elle n'est pas limitée à Git : on peut lui donner n'importe quelle paire de fichiers et elle affichera la comparaison.
L'ingénierie derrière un diff d'un million de lignes
Si la vue diff de GitHub s'étouffe sur les grosses PR, ce n'est pas par paresse, c'est par dépendance historique. GitHub rend chaque ligne, chaque boîte de commentaire, chaque bouton blame et chaque appel API inline dans le DOM d'un seul coup. Pour un diff de 200 lignes, c'est sans souci. Pour un refactoring de 200 000 lignes, c'est une bombe à mémoire.
La bibliothèque de Pierre inverse le modèle. Le diff est traité comme un flux de lignes étiquetées en tokens, alimenté à travers une liste virtuelle qui ne monte que ce qui est à l'écran. La coloration est faite paresseusement par ligne visible avec Shiki, pas avidement sur l'ensemble du blob. La couche d'annotations est découplée de la couche de rendu, donc les commentaires ne bloquent pas la peinture initiale.
Le résultat est ce que les développeurs ont vraiment remarqué : ouvrir une comparaison entre deux versions du noyau Linux dans DiffsHub ressemble plus à ouvrir une page statique qu'à lancer une application web lourde. Un développeur sur X a résumé : GitHub "fourre chaque ligne, boîte de commentaire et appel API lourd dans votre navigateur d'un coup" alors que DiffsHub "simplifie la page de rendu et utilise le défilement virtuel, n'affichant que ce qui est réellement à l'écran."
Pourquoi cela compte pour votre organisation d'ingénierie
DiffsHub en soi est un jouet amusant. C'est la bibliothèque qui constitue la vraie histoire pour les équipes qui construisent des plateformes développeurs internes, des produits de revue de code, ou des outils d'ingénierie pilotés par IA.
- Outils de revue internes. Si votre équipe plateforme maintient une interface de revue maison au-dessus de GitHub ou GitLab,
@pierre/diffsest un moteur prêt à brancher qui vous donne la qualité visuelle GitHub sans ses problèmes de performance. - Agents de codage IA. Les outils de codage agentiques comme Cursor, Claude Code et la nouvelle vague de réviseurs autonomes de PR doivent présenter leurs diffs à des humains pour validation. Une bibliothèque qui affiche des diffs générés par agent de n'importe quelle taille, avec annotations et commentaires inline, supprime toute une catégorie de travail UI.
- Vues d'audit et de conformité. Les équipes sécurité et conformité doivent souvent lire des diffs massifs générés automatiquement — mises à jour de dépendances, migrations de bases de données, plans d'infrastructure-as-code. Un moteur qui ne plante pas à 100 000 lignes change ce qui devient relisable.
- Documentation et formation. Expliquer comment un changement a façonné une base de code est nettement plus facile quand le diff lui-même est rapide, thématisable et intégrable dans n'importe quel site MDX ou doc.
La posture de licence compte aussi. Le dépôt est authentiquement open source, le package est sur npm, et l'équipe derrière vient de Cloudflare, Stripe et GitHub. Ce n'est pas un SaaS fermé qui pourrait retirer l'échelle, c'est une primitive sur laquelle on peut bâtir.
Comment l'essayer en cinq minutes
La voie la plus rapide est l'astuce d'URL. Choisissez une PR publique qui vous intéresse, par exemple les comparaisons Bun, Node.js ou Linux mises en avant sur la page d'accueil de DiffsHub, et changez le domaine. Faites défiler. Notez l'absence de saccades.
Pour brancher la bibliothèque dans votre propre produit, l'installation tient en une ligne :
bun i @pierre/diffs
# ou
pnpm add @pierre/diffsÀ partir de là, vous pouvez monter le composant CodeView, lui passer une paire de contenus de fichier, et choisir un thème Shiki. Le README du monorepo pierrecomputer/pierre détaille les layouts côte à côte et unifié, l'API d'annotations et le mode de résolution de conflits de merge.
Le signal de l'écosystème Pierre
DiffsHub est l'une des trois pièces que Pierre place en open source : Diffs (la bibliothèque de rendu), Trees (primitives d'arbre de fichiers), et Code Storage. Chacune est le genre de fondation peu glamour que la plupart des équipes réinventent mal. Les publier en open source, et les mettre en scène avec une démo grand public virale qui prouve qu'elles tiennent à l'échelle extrême, est une stratégie délibérée. Elle gagne la confiance, embarque les primitives dans des milliers de chaînes d'outils en une semaine, et amorce le marché pour ce que Pierre facturera ensuite.
Pour les responsables d'ingénierie, la leçon dépasse DiffsHub. Les lancements d'outils développeurs les plus à effet de levier de 2026 suivent le même playbook : ouvrir la primitive en open source, sortir une démo virale qui prouve qu'elle marche à l'extrême, et laisser la communauté la porter partout avant que les concurrents ne réagissent. On l'a vu avec shadcn/ui pour les composants. On l'a vu avec Shiki pour la coloration. Pierre le fait pour la revue de code.
Ce que nous en retenons chez Noqta
Chez Noqta, nous réfléchissons beaucoup à ce dont les agents de codage IA ont besoin pour s'intégrer nativement dans les workflows d'entreprise. La plupart de nos pilotes enterprise butent sur le même mur : les agents génèrent de gros diffs corrects plus vite que les humains ne peuvent les relire. Le goulot d'étranglement est la surface de revue, pas le modèle.
Des bibliothèques comme @pierre/diffs sont exactement le type de brique qui ferme cet écart. Associez un moteur de diff rapide et embarquable à un agent qui explique ses propres changements inline, et l'étape "human-in-the-loop" cesse d'être la partie la plus lente du pipeline. C'est la direction que doit prendre le codage agentique pour atterrir dans des environnements régulés à grosses bases de code.
DiffsHub est un petit lancement avec une astuce d'une ligne. La bibliothèque derrière est une mise à jour silencieuse de l'une des surfaces les plus communes et les plus douloureuses de l'ingénierie logicielle. Si vous n'y avez pas encore ouvert une PR de 100 000 lignes, faites-le avant votre prochaine revue de code — puis regardez sérieusement ce que votre propre plateforme développeur pourrait faire avec la même primitive.