Comparer deux versions d’un texte — code, documents, fichiers de configuration ou contrats — est une tâche technique courante. Un bon outil rend la revue rapide et réduit les erreurs. La commande Unix `diff` date de 1974 ; les algorithmes modernes ont peu évolué depuis les années 1980, mais leur visualisation s’est beaucoup améliorée. Voici leur fonctionnement, les cas d’usage de la comparaison par ligne ou mot, et les situations où un outil dans le navigateur est préférable à `git diff` ou à un IDE.
Fonctionnement des algorithmes diff
Les outils de comparaison modernes reposent sur l’algorithme de la plus longue sous-séquence commune (LCS), un problème classique de programmation dynamique étudié depuis les années 1970. À partir de deux textes, l’algorithme cherche la plus longue suite de jetons (généralement des lignes ou des mots) présente dans les deux, dans le même ordre, même si d’autres jetons la séparent. Tout élément de la LCS est marqué « inchangé » ; les éléments restants sont classés comme ajout (présent uniquement dans la nouvelle version) ou suppression (présent uniquement dans l’ancienne). L’algorithme LCS a une complexité en temps et en mémoire de O(m × n), où m et n sont les nombres de jetons des entrées. Pour les documents et fichiers de code de quelques centaines ou milliers de lignes, le calcul est pratiquement instantané. Pour les très gros fichiers (100,000 lignes ou plus), des algorithmes plus sophistiqués, comme diff de Myers (utilisé par Git) ou patience diff, donnent des résultats comparables plus efficacement. L’algorithme produit un script d’édition minimal : le plus petit nombre d’ajouts et de suppressions nécessaire pour transformer une entrée en l’autre. Les outils affichent ce script différemment, mais les mathématiques sous-jacentes restent identiques. La comparaison par ligne segmente aux retours à la ligne ; la comparaison mot à mot aux espaces ; la comparaison caractère par caractère aux points de code Unicode. Chaque niveau détecte des changements différents : par ligne pour le code, mot à mot pour la prose et caractère par caractère pour les petites différences comme les fautes de frappe.
Choisir une comparaison par ligne ou mot
Le niveau de segmentation choisi change considérablement l’utilité du résultat. La comparaison par ligne traite chaque ligne comme une unité entière : elle correspond complètement ou est marquée comme modifiée. C’est efficace pour le code, où les changements importants ajoutent, suppriment ou remplacent des lignes ou blocs entiers. Git, les vues de demandes de modification GitHub, l’onglet de contrôle de version de VS Code et les outils de fusion des IDE utilisent généralement ce mode. Pour la prose, les contrats ou la documentation, ce résultat peut être déroutant : quelques mots changent dans un paragraphe presque identique, mais toute la ligne est signalée, laissant au lecteur le soin de chercher la différence. La comparaison mot à mot sépare le texte aux espaces et ne marque que les mots modifiés. Ainsi, le passage de « the quick brown fox » à « a fast brown fox » met en évidence « the » → « a » et « quick » → « fast », tout en laissant « brown fox » intact. Cela correspond à la façon dont les auteurs et réviseurs perçoivent les modifications. La comparaison caractère par caractère sert à repérer les espaces de fin, les substitutions invisibles de caractères Unicode et certaines corrections orthographiques. La plupart des outils utilisent par défaut la comparaison par ligne et proposent le mode mot à mot, comme celui-ci.
Quand préférer un outil navigateur à Git ou un IDE
Git et les IDE modernes disposent d’excellents outils de comparaison intégrés. Un outil dans le navigateur reste utile dans plusieurs situations. Pour comparer des textes qui ne sont pas dans un dépôt — contenu copié d’un courriel, réponses de deux API, configurations copiées depuis des serveurs différents ou sorties de deux exécutions d’un script —, Git et les IDE imposent de créer des fichiers dans un projet. Pour déboguer des sorties générées, comme des réponses JSON, des journaux ou des pages HTML rendues, le navigateur accepte un collage et affiche immédiatement les différences sans fichier temporaire. Il est aussi pratique pour les personnes sans Git ni IDE : gestionnaires de produit comparant des spécifications, auteurs relisant des brouillons, équipes juridiques comparant des contrats ou enseignants examinant des travaux. Pendant une réunion, on peut coller deux textes contestés et obtenir rapidement le résultat. Enfin, le traitement s’effectue entièrement dans le navigateur : les textes sensibles (politiques internes, documents RH ou configurations de sécurité) n’ont pas à être envoyés à un service distant ni enregistrés dans un dépôt local. L’outil permet aussi de partager l’URL d’une comparaison pour référencer un résultat dans une revue de code ou un rapport de bogue.