Comparaison & fusion de textes, gratuit

Comment ça marche

1. Collez deux textes : saisissez le texte original dans le panneau de gauche et le texte révisé dans celui de droite.
2. Consultez les différences : les lignes modifiées sont mises en évidence, vert pour les ajouts, rouge pour les suppressions, et jaune pour les modifications.
3. Parcourez le diff : faites défiler les changements en couleur et copiez ou capturez en image les parties dont vous avez besoin.

Brève histoire du diff

La comparaison de texte moderne est née aux Bell Labs. Douglas McIlroy (le même McIlroy qui a inventé les tubes Unix) et James W. Hunt ont écrit le diff Unix original au début des années 1970 ; il a été livré dans la 5e édition d'Unix en 1974. L'algorithme a été documenté dans le Bell Laboratories Computing Science Technical Report n°41 (juin 1976), un rapport interne intitulé « An Algorithm for Differential File Comparison ». L'algorithme de Hunt-McIlroy est construit sur le problème de la plus longue sous-séquence commune (LCS), trouver la plus longue séquence de lignes qui apparaît, dans l'ordre, dans les deux entrées, et tout ce qui n'est pas dans cette séquence est soit une suppression, soit une insertion. Une décennie plus tard, Eugene W. Myers a publié « An O(ND) Difference Algorithm and Its Variations » dans Algorithmica, Vol 1 numéro 2 (1986). Myers a reformulé le problème comme une recherche de plus court chemin sur un « graphe d'édition » et a montré qu'il pouvait être résolu en temps et espace O(ND), où N est la taille de l'entrée et D la taille du script d'édition minimal. Pour des entrées typiques, des fichiers qui ne diffèrent qu'à quelques endroits, D est petit, donc l'algorithme est rapide en pratique. L'article de Myers est devenu la base d'une implémentation Unix diff plus rapide qui s'exécutait deux à quatre fois plus vite que son prédécesseur et produisait une sortie de meilleure qualité. Patience diff (Bram Cohen, 2008) est un raffinement LCS qui privilégie les lignes d'ancrage uniques, produisant des diffs plus lisibles autour des blocs déplacés. Le défaut actuel dans git diff est l'algorithme histogramme dans LibXDiff, généralement considéré comme plus rapide que le Myers de base et produisant des diffs plus lisibles en présence de blocs déplacés (il est devenu le défaut de Git dans la 2.11, sortie le 29 novembre 2016). Les fondements mathématiques vont encore plus loin : la distance de Levenshtein (Vladimir Levenshtein, 1965) est le cousin au niveau caractère du problème LCS, et la solution de programmation dynamique de Wagner-Fischer (1974) est ce que chaque bibliothèque de « correspondance floue » implémente encore en interne.

Comment un diff est rendu

Il existe quatre conventions visuelles courantes pour afficher un diff. Côte à côte, deux colonnes, original à gauche, modifié à droite, avec les lignes correspondantes alignées. Bon pour une comparaison en un coup d'œil ; fonctionne bien aux largeurs de bureau mais devient illisible sur les viewports mobiles étroits. Diff unifié en ligne, une seule colonne montrant les lignes supprimées (généralement préfixées par - et colorées en rouge), les lignes ajoutées (+, vert) et les lignes de contexte inchangées (pas de préfixe, texte brut). La disposition que git diff utilise par défaut. S'adapte bien au mobile mais perd le parallélisme spatial du côte à côte. Diff au niveau du mot, mettant en évidence uniquement les mots qui ont changé dans les lignes modifiées. Utile pour la comparaison de prose où la majeure partie du texte est inchangée mais des phrases spécifiques ont été éditées. Diff au niveau du caractère, mettant en évidence chaque caractère modifié individuellement. Utile pour de très petits changements (une correction de faute de frappe, une édition d'un seul chiffre) où le niveau mot mettrait en évidence le mot entier. Les conventions de couleur sont remarquablement cohérentes dans l'écosystème : vert pour les ajouts, rouge pour les suppressions, jaune ou ambre pour les valeurs modifiées, gris neutre ou sans style pour inchangé. Cet outil utilise le style unifié en ligne avec mise en évidence au niveau du caractère dans les lignes modifiées, un hybride qui s'adapte bien au mobile tout en préservant la précision de la comparaison au niveau caractère pour les éditions de prose.

Fusion à trois voies, quand deux diffs doivent se combiner

Un diff à deux voies (cet outil) vous indique ce qui a changé entre la version A et la version B. Une fusion à trois voies répond à une question plus difficile : étant donné un ancêtre commun et deux révisions divergentes, quel est le résultat combiné qui incorpore les deux ensembles de changements ? C'est l'opération centrale de tout système de contrôle de version, lorsque deux développeurs éditent le même fichier indépendamment et que l'un essaie de fusionner leur travail, le système doit appliquer les deux diffs à l'original. L'algorithme diff3 formalisé par Khanna, Kunal et Pierce (2007) en est la base. La convention des marqueurs de conflit à sept caractères, <<<<<<<, =======, >>>>>>>, que Git insère dans les fichiers lorsqu'une fusion automatique échoue vient directement de cette lignée. Les outils de fusion visuels modernes (l'éditeur de fusion à trois panneaux de VS Code, par défaut depuis 1.69 en juin 2022 ; Beyond Compare de Scooter Software, depuis 1996 ; Meld ; Kaleidoscope de Black Pixel pour macOS) gèrent les fusions à trois voies avec un rendu côte à côte des trois versions plus un quatrième panneau pour le résultat de fusion proposé. Cet outil se concentre sur la comparaison à deux voies, la fusion à trois voies appartient à un véritable flux de travail de contrôle de version.

Cas d'usage courants

• Revue de code. Coller deux versions d'une fonction ou d'un module pour repérer rapidement le changement, surtout lorsqu'on travaille en dehors d'un flux Git (un extrait de l'e-mail d'un collègue, une réponse Stack Overflow contre votre code actuel).
• Comparaison de contrats juridiques. Les avocats et négociateurs de contrats comparent régulièrement deux versions d'un contrat pour voir ce que l'autre partie a changé. Le terme legal-tech est comparaison « blackline » ou « redline » ; des produits comme Draftable se spécialisent dans ce domaine.
• Édition de prose. Comparer le brouillon d'un auteur à la révision d'un éditeur, ou deux versions d'un article. Suivi des modifications de Microsoft Word fait cela en interne ; pour les brouillons en texte brut ou Markdown, un outil de diff est l'équivalent.
• Dérive de configuration. Comparer un fichier de configuration en production à la version dans le contrôle de source, l'écart est la dérive. Même flux pour les configurations spécifiques à l'environnement (dev vs staging vs production).
• Comparaison de logs. Comparer deux fichiers de logs provenant de différentes exécutions du même processus pour trouver le point de divergence.
• Revue de localisation. Les traducteurs comparent fréquemment une nouvelle source anglaise à la version précédente pour identifier exactement ce qui est nouveau et doit être traduit.

L'écosystème diff en 2026

Au-delà de git diff et Unix diff, plusieurs outils de diff spécialisés méritent d'être mentionnés. Beyond Compare (Scooter Software, 1996) est l'outil commercial de longue date de comparaison de dossiers et fichiers, populaire auprès des développeurs et professionnels IT pour le diffing cross-machine. Meld (open source, basé sur GTK) est le défaut GNOME. Kaleidoscope (Black Pixel, macOS) s'intègre avec le contrôle de version et est le choix de fait pour de nombreux développeurs Mac. L'éditeur de diff intégré de VS Code gère nativement les comparaisons à deux et trois voies ; l'éditeur de fusion à trois panneaux est devenu par défaut dans 1.69 (juin 2022). Mergely (Wayne Stidolph, 2013, sous licence MIT) est l'éditeur canonique de fusion à deux voies basé sur navigateur construit sur CodeMirror. jsdiff (Kevin Decker, ~2010) est la bibliothèque JavaScript de diff dominante, utilisée par tous les outils de diff basés sur navigateur dans lesquels vous avez déjà collé. diff-match-patch (Neil Fraser chez Google, 2006) est la bibliothèque alternative qui gère le diffing, la correspondance floue et la génération de patchs dans une seule API ; utilisée dans l'historique des révisions de Google Docs. Diffchecker est le service de diff en ligne freemium dominant, complet mais avec la confidentialité derrière un paywall (le niveau gratuit envoie le texte à leur serveur). text-compare.com est le plus ancien site de diff de texte pur sur le web, UI datée mais fonctionnel.

Confidentialité : pourquoi le tout-navigateur compte particulièrement ici

Chaque diff révèle exactement ce qui a changé entre deux versions, et ce qui a changé est souvent plus sensible que l'une ou l'autre version seule. Trois scénarios concrets où cela importe vivement. Correctifs de sécurité : comparer une version vulnérable d'une fonction à la version corrigée révèle l'emplacement et la nature précis d'un bug de sécurité, un attaquant qui trouve le correctif peut créer un exploit pour la version non corrigée (l'attaque « patch gap » documentée par Tian et al. à USENIX Security 2017). Coller un correctif de sécurité dans un outil de diff côté serveur revient essentiellement à publier la vulnérabilité. Négociation de contrat : comparer deux versions d'un contrat révèle exactement quelles clauses chaque partie souhaite, ce qui est précisément l'information que vous ne voulez pas que l'autre partie (ou quiconque surveille le réseau) ait pendant la négociation. Décisions éditoriales pré-publication : comparer un manuscrit avant et après édition révèle ce qu'un auteur et un éditeur ont décidé de couper ou de changer, souvent plus révélateur que la version finale publiée. Les outils de diff côté serveur téléversent les deux versions vers un tiers, où elles restent dans les logs. Cet outil s'exécute entièrement dans votre navigateur via JavaScript, vérifiez dans l'onglet Réseau de DevTools pendant que vous cliquez sur Comparer, ou mettez la page hors ligne (mode avion) après son chargement et l'outil fonctionne toujours.

Questions fréquentes

Puis-je comparer des fichiers de code ?

Oui. Collez n'importe quel texte, y compris du code, JSON, HTML, Markdown ou texte brut. Le diff est purement textuel, il fonctionne donc pour tout format.

Ignore-t-il les différences d'espacement ?

Activez l'option « Ignorer les espaces » pour sauter les différences qui ne sont que des espaces ou des fins de ligne. Utile pour comparer du code reformaté mais non modifié sur le fond.

Quel algorithme cela utilise-t-il ?

L'algorithme O(ND) de Myers (Eugene Myers, Algorithmica Vol 1 N° 2, 1986), le même algorithme que GNU diff a utilisé par défaut pendant des décennies et la base de la plupart des implémentations de diff de texte. Myers a reformulé le problème de la plus longue sous-séquence commune comme une recherche de plus court chemin sur un graphe d'édition, le rendant rapide en pratique pour les entrées qui ne diffèrent qu'à quelques endroits. L'algorithme histogramme plus récent (défaut actuel de Git depuis v2.11, novembre 2016) gère légèrement mieux les blocs déplacés mais est excessif pour le cas typique à deux collages que cet outil gère.

Y a-t-il une limite de taille ?

Pas de limite stricte, mais la comparaison s'exécute dans votre navigateur via JavaScript donc le plafond pratique est la mémoire disponible de votre appareil. Des dizaines de milliers de lignes fonctionnent confortablement. Des entrées très grandes (fichiers de logs de plusieurs Mo, romans entiers) fonctionneront mais peuvent prendre des secondes notables pour s'afficher. Pour des entrées vraiment énormes, utilisez le diff de Git en ligne de commande, il stream la sortie et gère les fichiers de taille arbitraire sans pression mémoire.

Peut-il faire une fusion à trois voies ou appliquer des patchs ?

Pas actuellement, cet outil se concentre sur la comparaison à deux voies (A vs B). La fusion à trois voies (l'algorithme diff3 avec marqueurs de conflit <<<<<<< / ======= / >>>>>>>) est l'opération que Git utilise lors de la fusion de branches ; elle nécessite un ancêtre commun plus deux versions divergentes. Pour la fusion à trois voies, utilisez un véritable système de contrôle de version ou un outil dédié comme l'éditeur de fusion à trois panneaux de VS Code (par défaut depuis 1.69 en juin 2022).

Mes textes sont-ils téléversés ?

Non. La comparaison s'exécute entièrement dans votre navigateur via JavaScript. Les textes que vous collez ne traversent jamais le réseau, vérifiez dans l'onglet Réseau de DevTools pendant que vous cliquez sur Comparer, ou mettez la page hors ligne (mode avion) après son chargement et l'outil fonctionne toujours. Particulièrement sûr pour comparer des correctifs de sécurité (où le diff lui-même révèle la vulnérabilité), des révisions de contrat (où le diff révèle les positions de négociation) ou des brouillons éditoriaux pré-publication.