Article
Comparer du code sans l'envoyer sur un serveur
Chaque fois que vous collez deux fichiers dans un outil de diff en ligne, ce code quitte votre machine. Fichiers de configuration, requêtes SQL, clés API enfouies dans un extrait .env : tout cela transite vers un serveur que vous ne contrôlez pas. Cet article explique comment fonctionnent les algorithmes de diff, ce que signifient les options de granularité en pratique, et pourquoi il est préférable de garder la comparaison en local.
Ce que calcule un diff
Un outil de diff prend deux textes et trouve l'ensemble minimal de modifications pour convertir l'un en l'autre. L'idée centrale est la plus longue sous-séquence commune, ou LCS : la séquence la plus longue de lignes (ou de tokens) présente dans les deux textes dans le même ordre, même si elles ne sont pas adjacentes. Tout ce qui ne fait pas partie de cette sous-séquence commune est soit un ajout dans la nouvelle version, soit une suppression dans l'ancienne. L'algorithme classique est celui de Myers (1986), qui trouve le script d'édition le plus court en O((N+M)D), où N et M sont les longueurs des deux textes et D est le nombre de modifications. En pratique, la plupart des outils ajoutent une étape de prétraitement pour ignorer les lignes communes en début et en fin de fichier, ce qui réduit le problème à la région modifiée. Le résultat est un patch : une suite de hunks, chacun décrivant un bloc contigu de lignes de contexte, de suppressions et d'ajouts. C'est le format utilisé par diff Unix, Git et la plupart des outils de revue de code.
Granularité ligne, mot et caractère
La granularité d'un diff détermine ce qui constitue une unité de comparaison. Le diff par ligne est le mode par défaut dans la plupart des outils : chaque ligne est traitée comme un token unique. C'est rapide et produit une sortie facile à lire en contexte, mais une ligne entière est marquée comme modifiée même si un seul mot a changé. Le diff par mot découpe chaque ligne en mots avant d'appliquer le LCS. Cela donne une image plus fine de ce qui a changé à l'intérieur d'une ligne, ce qui est utile pour du texte en prose, des valeurs de configuration ou du JSON. Le diff par caractère va plus loin et peut mettre en évidence une seule lettre modifiée dans un long identifiant. La gestion des espaces introduit du bruit. Une ligne se terminant par CRLF et la même ligne se terminant par LF apparaîtront comme différentes lors d'une comparaison octet par octet. La plupart des outils proposent une option pour normaliser les fins de ligne avant le diff. De même, les espaces de fin de ligne, l'indentation par tabulation ou par espaces, et les lignes vides peuvent tous produire des différences parasites. Activer la normalisation des espaces est généralement le bon choix par défaut pour comparer du code provenant d'éditeurs ou de systèmes d'exploitation différents.
Le risque pour la vie privée des outils de diff en ligne
Les services de diff et de pastebin en ligne sont pratiques : on ouvre une URL, on colle deux extraits, on obtient une sortie colorée. Le problème est que le texte collé est transmis à un serveur tiers. Selon le service, ce texte peut être journalisé, indexé, conservé indéfiniment ou partagé avec des prestataires d'analyse. Cela devient critique quand le code contient des données sensibles. Des identifiants codés en dur, des noms d'hôtes internes, de la logique métier propriétaire ou des données à caractère personnel peuvent se retrouver dans un paste. Même sans secret explicite, la structure d'un code interne peut révéler des décisions d'architecture que vous préféreriez garder confidentielles. Le risque n'est pas théorique. Des chercheurs en sécurité ont régulièrement trouvé des identifiants et des tokens internes dans des pastes publics. Certains services conservent les pastes même après leur suppression par l'utilisateur, car des copies existent dans des caches ou des sauvegardes. Il n'existe aucun moyen de vérifier ce qu'un service distant fait du texte une fois qu'il lui est parvenu. La seule protection fiable est de garder le diff en local, c'est-à-dire de l'exécuter dans un outil qui n'envoie jamais le texte sur le réseau.
Utilisations pratiques d'un diff local
Un diff ne sert pas uniquement à la revue de code. Quelques cas courants où un diff local est utile : Revoir les modifications apportées à un document ou à un fichier de configuration avant de les valider. Comparer deux versions d'un Dockerfile, d'une configuration Nginx ou d'un manifeste Kubernetes pour comprendre précisément ce qui a changé entre deux déploiements. Détecter une dérive de configuration entre environnements. Si les configurations de production et de staging sont censées être identiques sauf pour les noms d'hôtes et les secrets, un diff révèle immédiatement toute divergence non prévue. Comparer des réponses d'API lors d'un débogage. Coller deux charges JSON d'une API REST ou GraphQL et lancer un diff par mot permet d'identifier les champs ajoutés, les valeurs modifiées ou les clés supprimées, sans parcourir des centaines de lignes manuellement. Revoir du code généré par un LLM par rapport à une version de référence. Quand un modèle réécrit une fonction, un diff par ligne montre quelle logique a changé et laquelle est restée identique, plus rapidement que lire les deux versions indépendamment. Dans tous ces cas, le texte impliqué peut être sensible, et le garder hors d'un serveur distant est le choix évident.
Comparer dans le navigateur, sans envoyer de données
L'outil text-diff de ce site effectue l'intégralité du calcul de diff dans votre navigateur, en JavaScript. Vous collez deux textes dans les deux panneaux et le diff s'affiche immédiatement, ligne par ligne, jusqu'à 3000 lignes par côté. Rien n'est envoyé à un serveur. Le texte ne quitte pas votre appareil. L'implémentation utilise un algorithme standard basé sur le LCS, appliqué aux lignes : chaque ligne est un token, et l'outil détermine si elle est inchangée, ajoutée ou supprimée en trouvant la plus longue sous-séquence commune entre les deux versions. Les lignes inchangées s'affichent sans surbrillance, les lignes ajoutées en vert, les lignes supprimées en rouge, à côté d'un compteur du nombre d'ajouts et de suppressions. Il n'y a pas aujourd'hui de mode par mot ou par caractère ni de bascule de normalisation des espaces, donc une ligne qui ne diffère que par des espaces de fin de ligne ou un style de fin de ligne s'affiche quand même comme modifiée. Parce que le calcul s'exécute côté client, l'outil fonctionne hors connexion. Il n'y a pas de compte, pas d'historique, pas de conservation des données. Vous pouvez comparer un fichier de configuration local avec un modèle, revoir un patch avant de l'appliquer, ou vérifier deux réponses d'API sans qu'aucun de ces textes n'atteigne un tiers.
Outils mentionnés dans cet article
Questions fréquentes
Le diff par ligne ou le diff par mot est-il préférable pour du code ?
Pour la plupart des tâches de revue de code, le diff par ligne est la norme et le plus facile à lire, car le code est structuré par lignes. Le diff par mot peut aider quand les lignes sont longues et qu'une petite partie seulement a changé, comme dans une valeur JSON sur une seule ligne, mais cet outil compare uniquement au niveau de la ligne ; dans ce cas, utilisez la ligne surlignée comme repère et repérez à l'œil la petite différence qu'elle contient.
Pourquoi les outils de diff en ligne posent-ils un risque même s'ils utilisent HTTPS ?
HTTPS protège le texte en transit contre l'espionnage, mais pas une fois qu'il est arrivé sur le serveur. L'opérateur du service a un accès complet au contenu collé et peut le journaliser, le conserver ou le partager. TLS concerne la sécurité du transport, pas ce que le destinataire fait des données.
L'outil text-diff conserve-t-il un historique des comparaisons passées ?
Non. L'outil n'a pas de backend et n'effectue aucune requête réseau. Une fois que vous fermez ou rechargez l'onglet, le texte est perdu. Il n'y a pas de compte, pas d'historique sauvegardé, et pas de journal côté serveur.