Quel algorithme cet outil utilise-t-il ?

Un diff ligne par ligne fondé sur la LCS (Longest Common Subsequence, plus longue sous-séquence commune), calculée par programmation dynamique. diff(1) sous Unix, git diff et la plupart des outils de revue de code résolvent ce même problème de plus longue sous-séquence commune, avec des algorithmes plus rapides (git diff utilise par défaut celui de Myers). Les lignes présentes dans les deux textes sont affichées comme inchangées ; les lignes présentes uniquement dans l’original sont marquées comme supprimées (en rouge) ; les lignes présentes uniquement dans le texte modifié sont marquées comme ajoutées (en vert).

Mon texte est-il envoyé sur un serveur ?

Non. La comparaison s’exécute entièrement dans votre navigateur, en JavaScript. Votre texte ne quitte jamais votre appareil, et l’outil fonctionne hors ligne une fois la page chargée.

Puis-je comparer du code ?

Oui. L’outil compare n’importe quel texte brut : code source, fichiers de configuration, JSON, CSV, prose ou Markdown. Il n’applique pas de coloration syntaxique, mais le diff au niveau des lignes gère correctement l’indentation et la ponctuation.

Quelle taille de texte puis-je comparer ?

L’algorithme LCS utilisé ici a une complexité en O(n×m), en temps comme en mémoire : les très gros fichiers (plusieurs milliers de lignes) peuvent donc être lents. Pour des documents de quelques centaines de lignes, la comparaison est instantanée. Pour de gros fichiers, préférez un outil de diff de bureau (diff, vimdiff, la comparaison de VS Code).

À quoi sert l’option « Ignorer les espaces en début et en fin de ligne » ?

Quand elle est cochée, les espaces en début et en fin de chaque ligne sont retirés avant la comparaison : une ligne dont seule l’indentation a changé est donc considérée comme inchangée (elle s’affiche telle qu’elle figure dans le texte d’origine). Les espaces à l’intérieur d’une ligne restent comptés. C’est proche de l’option diff -b d’Unix, sans lui être identique : diff -b tient pour équivalentes des suites d’espaces de longueurs différentes, mais pas une ligne sans indentation et la même ligne indentée. Utile pour comparer du code reformaté ou réindenté.

Comparer deux textes

Collez votre texte d’origine et votre texte modifié, puis cliquez sur Comparer pour voir ce qui a changé. Les lignes ajoutées apparaissent en vert, les lignes supprimées en rouge et les lignes inchangées en gris. Tout se passe dans votre navigateur — rien n’est envoyé sur un serveur.

Texte d’origine

Texte modifié

Saisissez du texte dans les deux champs, puis cliquez sur « Comparer ».

Comment utiliser l’outil de comparaison de textes

Collez votre texte d’origine dans le cadre de gauche et le texte modifié dans celui de droite.
Si seuls les changements de contenu vous intéressent, et non l’indentation, cochez Ignorer les espaces en début et en fin de ligne.
Cliquez sur Comparer. Le résultat s’affiche en dessous : les lignes vertes ont été ajoutées, les lignes rouges ont été supprimées, les lignes sans marque n’ont pas changé.

Qu’est-ce qu’un diff de texte ?

Un « diff » (abréviation de l’anglais difference) montre l’ensemble minimal de modifications nécessaires pour passer d’une version d’un texte à une autre. Les diffs servent dans la gestion de versions (git, SVN), la revue de code, la comparaison de documents (versions d’un contrat, révisions d’un article) et la validation de données (comparaison de fichiers CSV exportés ou de fichiers de configuration).

L’algorithme utilisé ici repose sur la LCS (Longest Common Subsequence, plus longue sous-séquence commune) : il cherche la plus longue suite de lignes commune aux deux textes, puis marque tout le reste comme ajouté ou supprimé. Cet outil la calcule avec la méthode classique de programmation dynamique, un tableau de n×m cases. diff(1), git diff et la plupart des vues de diff des outils de revue de code résolvent ce même problème, mais avec des algorithmes plus rapides, comme celui de Myers présenté plus bas.

De Hunt et McIlroy à Myers : une brève histoire de diff

L’utilitaire diff a été écrit aux Bell Labs et livré avec Unix au milieu des années 1970. Son algorithme a été publié en juin 1976 par James W. Hunt et M. Douglas McIlroy dans un rapport technique des Bell Labs (Computing Science Technical Report) intitulé « An Algorithm for Differential File Comparison ». Hunt a construit le prototype ; McIlroy l’a affiné. Ce fut l’un des premiers outils de comparaison de fichiers non heuristiques, et il a posé le problème comme le fait encore aujourd’hui tout outil de diff : trouver la plus longue sous-séquence commune (LCS) des deux fichiers, puis signaler tout ce qui se trouve en dehors de cette colonne vertébrale commune comme ajouté ou supprimé.

Une décennie plus tard, en 1986, Eugene W. Myers a publié « An O(ND) Difference Algorithm and Its Variations » dans la revue Algorithmica. L’algorithme de Myers est plus rapide et plus simple à analyser ; il est devenu l’algorithme par défaut de Git et d’innombrables éditeurs et outils de revue. Le diff que vous voyez sur cette page repose sur le même socle — la LCS — que ces deux articles ont établi.

Le diff comme plus court script d’édition : l’algorithme de Myers

Myers a reformulé la comparaison comme un problème de recherche de chemin dans un graphe d’édition (edit graph). Imaginez le fichier d’origine disposé le long du bord supérieur d’une grille et le fichier modifié le long du bord gauche. Un pas vers la droite supprime une ligne, un pas vers le bas insère une ligne, et un pas en diagonale conserve une ligne présente dans les deux. Le meilleur diff est le chemin du coin supérieur gauche au coin inférieur droit qui fait le plus de pas en diagonale — autrement dit, celui qui compte le moins d’insertions et de suppressions. Cette suite minimale d’insertions et de suppressions est le plus court script d’édition (shortest edit script).

L’algorithme s’exécute en temps et en espace O(ND), où N est la longueur cumulée des deux entrées et D la distance d’édition — la taille de ce plus court script d’édition. La propriété décisive est que c’est D, et non N, qui domine : quand deux fichiers sont presque identiques (petit D), le diff est quasi linéaire et semble instantané, ce qui est précisément le cas courant en gestion de versions. Un raffinement décrit dans le même article ramène la mémoire à O(N) grâce à une technique « diviser pour régner » (en espace linéaire), si bien que même de gros fichiers n’épuisent pas la mémoire.

Distance LCS ou distance de Levenshtein

La « distance d’édition » désigne une famille de mesures, et la différence entre deux d’entre elles explique l’allure du résultat d’un diff. La distance de Levenshtein compte le nombre minimal d’insertions, de suppressions et de substitutions d’un seul caractère nécessaires pour transformer une chaîne en une autre. La distance LCS — le modèle derrière le diff par lignes — n’autorise que les insertions et les suppressions ; il n’existe pas d’opération de substitution.

Cette seule restriction explique pourquoi un diff n’affiche jamais une ligne comme « modifiée sur place ». Il montre l’ancienne ligne comme supprimée et la nouvelle comme ajoutée — deux opérations au lieu d’une. L’exemple classique transforme kitten en sitting : la distance de Levenshtein vaut 3 (remplacer k par s, remplacer e par i, insérer g), mais la distance LCS vaut 5, car chaque substitution doit s’exprimer comme une suppression plus une insertion. Les outils qui veulent surligner les modifications à l’intérieur d’une ligne lancent un second diff, plus fin, dans la ligne modifiée — mais la décision au niveau des lignes relève de la LCS pure.

Les quatre algorithmes de diff de Git

Git vous laisse choisir l’algorithme avec --diff-algorithm. Les quatre produisent un diff correct ; ils diffèrent par l’alignement qu’ils retiennent parmi plusieurs alignements également valides, ce qui change la lisibilité du résultat.

Algorithme	Fonctionnement	Idéal pour
Myers (par défaut)	Recherche gloutonne du plus court script d’édition dans le graphe d’édition.	Usage général ; rapide et presque toujours suffisant.
Minimal	Désactive les raccourcis heuristiques de la recherche de Myers pour garantir le diff le plus petit possible.	Petites entrées où le minimum absolu compte ; plus lent.
Patience	N’apparie que les lignes uniques dans les deux fichiers, s’ancre sur leur plus longue sous-séquence croissante, puis procède récursivement.	Refactorisations et réordonnancements, où Myers aligne les mauvaises accolades ou lignes vides.
Histogram	Extension de patience qui gère aussi les lignes communes peu fréquentes ; d’une rapidité comparable.	Une bonne alternative par défaut ; résultat net quand des fonctions sont déplacées.

Le diff patience a été inventé par Bram Cohen, le créateur de BitTorrent. Son idée : les lignes uniques — une signature de fonction caractéristique plutôt qu’une accolade fermante — sont les ancres les plus significatives ; les aligner d’abord, puis traiter récursivement les intervalles entre elles, produit un diff qui correspond à la façon dont un humain lit la modification. Histogram affine la même idée et donne souvent le résultat le plus sobre sur les grosses refactorisations.

Granularité : ligne, mot ou caractère

Les algorithmes de diff comparent une suite de jetons (tokens), et c’est vous qui décidez de ce qu’est un jeton. Le choix le plus courant — et celui de cet outil — est la ligne. La ligne est une unité naturelle pour le code source et la configuration : elle a un sens, il y a bien moins de lignes que de caractères (le travail de comparaison, en O(ND) chez Myers et en O(n×m) ici, reste donc réduit), et un résultat ligne par ligne se parcourt facilement.

Le diff au niveau des mots découpe le texte sur les espaces et convient à la prose, où la modification d’un seul mot dans un long paragraphe ne devrait pas signaler toute la ligne. Le diff au niveau des caractères est le grain le plus fin, utile pour surligner les lettres exactes qui ont changé dans un mot, mais il devient bruité dès que le texte s’allonge. Beaucoup d’éditeurs combinent les deux : un diff par lignes pour repérer les zones modifiées, puis un diff par mots ou par caractères dans chaque zone pour surligner la modification précise.

Lire le format diff unifié

Le diff unifié (unified diff) est le format que vous voyez dans git diff, les patchs et les demandes de fusion (pull requests). Il commence par deux en-têtes de fichier — l’original marqué --- et le nouveau marqué +++ — puis regroupe les modifications en blocs (hunks). Chaque bloc commence par un en-tête de la forme @@ -l,s +l,s @@, où la première paire donne la ligne de départ et le nombre de lignes dans le fichier d’origine, et la seconde paire la même chose pour le nouveau fichier.

Dans un bloc, chaque ligne porte un préfixe d’un caractère : une espace pour une ligne de contexte inchangée, un moins pour une ligne supprimée de l’original et un plus pour une ligne ajoutée dans la nouvelle version. Par défaut, quelques lignes de contexte inchangées (généralement trois) entourent chaque modification, pour qu’un patch s’applique encore après un léger décalage du fichier. L’ancien format diff contextuel (context diff) transmettait la même information, mais imprimait séparément les blocs avant et après et marquait les lignes modifiées par ! ; le format unifié est plus compact parce qu’il entrelace les deux côtés, et il s’est imposé comme format par défaut.

Fusion à trois voies et conflits

Un simple diff à deux voies ne peut pas dire lequel de deux fichiers différents est « le bon ». Une fusion à trois voies (three-way merge) ajoute l’ancêtre commun comme référence. Des outils comme diff3 comparent les deux versions à cette base : une modification faite d’un seul côté est appliquée automatiquement, tandis qu’une zone modifiée différemment des deux côtés est signalée comme conflit de fusion — les marqueurs bien connus <<<<<<< / ======= / >>>>>>> de Git. Comprendre qu’un conflit signifie simplement « les deux côtés ont modifié les mêmes lignes par rapport à l’ancêtre » rend leur résolution bien moins mystérieuse.

Où l’on utilise le diff en pratique

Revue de code. Chaque pull request est un diff ; les relecteurs lisent les lignes ajoutées et supprimées au lieu de relire des fichiers entiers.
Comparaison de documents et de contrats. Comparer deux révisions d’un accord, d’une politique ou d’un article pour voir précisément quelle formulation a changé.
Dérive de configuration. Comparer la configuration en production d’un serveur à la version de référence pour repérer les modifications involontaires.
Analyse de journaux et de données. Comparer deux exports, deux instantanés CSV ou deux fichiers journaux pour isoler exactement ce qui a changé entre deux exécutions.
Détection de plagiat et de similarité. La taille de la sous-séquence commune mesure directement à quel point deux documents se ressemblent.

Dans chaque cas, la question est celle à laquelle Hunt, McIlroy et Myers ont répondu : quel est l’ensemble de modifications le plus petit et le plus clair qui fait passer du premier texte au second ?

Les limites du diff par lignes : blocs déplacés et résultat bruité

Un diff par lignes répond à une question précise — la plus courte suite d’insertions et de suppressions de lignes entre deux fichiers — et ce cadrage a de vrais angles morts qu’il vaut la peine de comprendre. Le plus courant est le code déplacé : si vous coupez une fonction en haut d’un fichier pour la coller en bas, un diff de base n’a aucune notion de « déplacement ». Il signale le bloc comme supprimé à un endroit et ajouté à un autre, ce qui double la taille apparente de la modification. Certains outils ajoutent une détection des déplacements dans une passe séparée, par-dessus le diff ; le résultat LCS sous-jacent traite malgré tout les deux copies indépendamment.

Une deuxième limite est l’ambiguïté d’alignement. Quand un fichier contient beaucoup de lignes identiques — lignes vides, accolades fermantes, code passe-partout répété —, plusieurs diffs différents peuvent être tout aussi minimaux, et une recherche gloutonne de Myers peut en choisir un qui associe une accolade à la mauvaise accolade, si bien qu’une modification nette paraît éparpillée. C’est exactement le problème que visent les algorithmes patience et histogram en s’ancrant d’abord sur les lignes uniques. Une troisième limite : le diff par lignes est aveugle aux changements à l’intérieur d’une ligne. Modifiez un seul caractère d’une longue ligne et toute la ligne est signalée ; c’est pourquoi une passe au niveau des mots aide souvent à comparer de la prose.

Rien de tout cela ne rend le diff par lignes faux — c’est le bon choix par défaut pour le code et la configuration —, mais connaître ses hypothèses explique pourquoi deux outils peuvent présenter « la même » modification différemment, et pourquoi changer d’algorithme ou de granularité transforme parfois un diff confus en diff évident.

Questions fréquentes

Quel algorithme cet outil utilise-t-il ?: Un diff ligne par ligne fondé sur la LCS (Longest Common Subsequence, plus longue sous-séquence commune), calculée par programmation dynamique. diff(1) sous Unix, git diff et la plupart des outils de revue de code résolvent ce même problème de plus longue sous-séquence commune, avec des algorithmes plus rapides (git diff utilise par défaut celui de Myers). Les lignes présentes dans les deux textes sont affichées comme inchangées ; les lignes présentes uniquement dans l’original sont marquées comme supprimées (en rouge) ; les lignes présentes uniquement dans le texte modifié sont marquées comme ajoutées (en vert).
Mon texte est-il envoyé sur un serveur ?: Non. La comparaison s’exécute entièrement dans votre navigateur, en JavaScript. Votre texte ne quitte jamais votre appareil, et l’outil fonctionne hors ligne une fois la page chargée.
Puis-je comparer du code ?: Oui. L’outil compare n’importe quel texte brut : code source, fichiers de configuration, JSON, CSV, prose ou Markdown. Il n’applique pas de coloration syntaxique, mais le diff au niveau des lignes gère correctement l’indentation et la ponctuation.
Quelle taille de texte puis-je comparer ?: L’algorithme LCS utilisé ici a une complexité en O(n×m), en temps comme en mémoire : les très gros fichiers (plusieurs milliers de lignes) peuvent donc être lents. Pour des documents de quelques centaines de lignes, la comparaison est instantanée. Pour de gros fichiers, préférez un outil de diff de bureau (diff, vimdiff, la comparaison de VS Code).
À quoi sert l’option « Ignorer les espaces en début et en fin de ligne » ?: Quand elle est cochée, les espaces en début et en fin de chaque ligne sont retirés avant la comparaison : une ligne dont seule l’indentation a changé est donc considérée comme inchangée (elle s’affiche telle qu’elle figure dans le texte d’origine). Les espaces à l’intérieur d’une ligne restent comptés. C’est proche de l’option diff -b d’Unix, sans lui être identique : diff -b tient pour équivalentes des suites d’espaces de longueurs différentes, mais pas une ligne sans indentation et la même ligne indentée. Utile pour comparer du code reformaté ou réindenté.