On pense souvent que 2 + 2 font 4, point final. Or, dès que l'on sort de l'arithmétique élémentaire pour entrer dans le monde réel ou numérique, les choses se compliquent diaboliquement. Vous allez voir pourquoi votre ordinateur vous ment parfois sur la véracité d'une égalité, et comment éviter les pièges classiques qui font trébucher même les développeurs seniors.
Pourquoi la définition de l'égalité change tout le reste
Avant de plonger dans la vérification technique, il faut s'arrêter sur ce qu'on entend par "égal". C'est là que tout se joue. Si vous ne définissez pas le cadre, vous ne pourrez jamais valider l'égalité. C'est un peu comme essayer de mesurer une distance sans avoir décidé si on parle de kilomètres ou de pas.
Dans le langage courant, l'égalité est une notion vague. On dit que deux personnes sont égales en droits. Mais en mathématiques, l'égalité est une relation stricte. Elle implique que deux expressions désignent exactement le même objet. Pas "presque" le même. Pas "équivalent" dans 99% des cas. Le même.
L'identité mathématique versus l'équivalence
En algèbre, distinguer l'identité de l'équation est fondamental. Une identité est vraie pour toutes les valeurs des variables. Prenez $(a+b)^2 = a^2 + 2ab + b^2$. C'est vrai, toujours, partout. C'est une vérité structurelle.
Mais une équation comme $x + 5 = 10$ n'est vraie que pour une valeur précise. Si vous remplacez $x$ par 3, l'égalité s'effondre. Elle devient fausse. C'est une condition, pas une loi universelle. Beaucoup d'étudiants confondent ces deux concepts et cherchent à "prouver" une équation comme si c'était une identité, ce qui mène à des erreurs de raisonnement grossières.
Le problème, c'est que dans la vie réelle, on utilise souvent le mot égalité pour parler de proportionnalité ou de corrélation. "Le prix est égal à la quantité multipliée par le taux". Sauf que si le taux change, l'égalité tient toujours structurellement, mais la valeur numérique change. Il faut donc toujours se demander : parle-t-on de la forme ou du fond ? De la structure ou du résultat ?
La sémantique dans le langage naturel
Quand on quitte les chiffres, ça devient encore plus glissant. "La vitesse est égale à la distance divisée par le temps". C'est une définition physique. Mais si vous mesurez la distance avec un mètre ruban et le temps avec un vieux chronomètre, votre égalité sera fausse numériquement à cause des erreurs de mesure. Pourtant, la loi physique reste vraie.
C'est là que la notion de précision entre en jeu. Une égalité peut être théoriquement vraie mais pratiquement invérifiable. Les scientifiques le savent bien : aucune mesure n'est parfaite. On travaille toujours avec des intervalles de confiance. Dire qu'une égalité est vraie en physique, c'est souvent dire qu'elle est vraie "à une certaine incertitude près". C'est une nuance capitale que les puristes des maths détestent, mais qui est indispensable dans le monde concret.
La méthode rigoureuse pour valider une égalité mathématique
Revenons sur le terrain solide des mathématiques. Comment prouver qu'une égalité tient la route ? On ne peut pas se contenter de tester quelques valeurs. C'est une erreur classique. Tester $x=1$, $x=2$ et $x=10$ ne prouve rien pour l'infini des nombres réels.
Il faut utiliser la déduction. On part d'un côté de l'égalité et on applique des transformations autorisées jusqu'à tomber sur l'autre côté. C'est le principe de la démonstration par transformation. Chaque étape doit être réversible ou logiquement impliquer la suivante sans perte d'information.
La substitution et le développement
La technique la plus basique, c'est le développement. Si vous avez $(x-1)(x+1)$ d'un côté et $x^2 - 1$ de l'autre, vous développez le premier terme. Vous obtenez $x^2 + x - x - 1$. Les $x$ s'annulent. Il reste $x^2 - 1$. Bingo. L'égalité est vérifiée.
Mais attention aux domaines de définition. C'est le piège numéro un. L'égalité $ rac{x^2}{x} = x$ semble vraie. On simplifie par $x$. Sauf que si $x = 0$, le terme de gauche n'existe pas (division par zéro), tandis que le terme de droite vaut 0. Donc l'égalité est fausse pour $x=0$. Elle n'est vraie que sur l'ensemble des réels sauf zéro. Oublier cette condition, c'est invalider toute la démonstration.
Je trouve que les gens négligent trop souvent ces conditions d'existence. On veut aller vite, on simplifie, et boum, on tombe sur une absurdité. Prenez le temps de vérifier où votre expression est définie avant de crier victoire.
Le raisonnement par l'absurde
Parfois, la transformation directe est impossible. C'est là qu'intervient le raisonnement par l'absurde. On suppose que l'égalité est fausse, c'est-à-dire que le membre de gauche est différent du membre de droite. On suit les conséquences logiques de cette hypothèse.
Si on arrive à une contradiction flagrante (du type $1 = 0$ ou "un nombre est à la fois pair et impair"), alors notre hypothèse de départ était fausse. Conclusion : l'égalité est vraie. C'est une méthode puissante, souvent utilisée en théorie des nombres ou en géométrie, mais qui demande une rigueur absolue dans l'enchaînement des implications.
Et puis il y a la récurrence. Pour les égalités qui dépendent d'un entier naturel $n$ (comme des sommes de suites), c'est l'arme fatale. On vérifie pour $n=0$, puis on suppose que c'est vrai pour $n$ et on prouve que ça reste vrai pour $n+1$. Si la première marche tient et que l'escalier est solide, on monte à l'infini.
Comment les ordinateurs vérifient (et ratent) les égalités
C'est ici que ça devient fascinant et terrifiant à la fois. En programmation, l'égalité n'est pas ce que vous croyez. Un ordinateur ne "comprend" pas les maths comme nous. Il manipule des bits. Et cette traduction du monde réel vers le binaire crée des artefacts bizarres.
Si vous demandez à Python si 0.1 + 0.2 == 0.3, il vous répondra False. Quoi ? En primaire, on apprend que ça fait 0.3. Pourquoi la machine dit non ? Parce que les nombres à virgule flottante sont stockés en binaire, et que 0.1 n'a pas d'écriture binaire finie (c'est comme 1/3 en décimal). Il y a une erreur d'arrondi microscopique.
Le cauchemar des nombres flottants
Le standard IEEE 754 gère ces nombres. Il est partout. Dans votre calculatrice, dans Excel, dans les langages de code. Le problème, c'est la précision limitée. Un float sur 64 bits ne peut pas tout représenter exactement. Quand vous faites des opérations en chaîne, les erreurs d'arrondi s'accumulent.
Résultat : comparer deux flottants avec l'opérateur d'égalité strict est une très mauvaise idée. C'est un bug en puissance. La bonne pratique, c'est de vérifier si la différence entre les deux nombres est inférieure à un seuil de tolérance (epsilon). On ne demande pas "est-ce égal ?", on demande "est-ce assez proche pour qu'on s'en fiche ?".
Ça change la donne dans la finance ou l'ingénierie. Si vous codez un algorithme de trading qui compare des prix à la milliseconde près avec des flottants, vous allez perdre de l'argent à cause de ces micro-différences invisibles. Les banques utilisent des types décimaux fixes pour éviter ça, mais ça coûte plus cher en calcul.
Égalité de référence vs égalité de valeur
En programmation orientée objet, la confusion est encore plus grande. Prenons Java ou C#. Si vous créez deux objets "Personne" avec le même nom et le même âge, sont-ils égaux ?
Si vous utilisez l'opérateur == sur des objets, vous comparez souvent les références mémoire. C'est-à-dire l'adresse où l'objet est stocké dans la RAM. Même si le contenu est identique, si les adresses sont différentes, l'égalité est fausse. C'est comme si vous aviez deux exemplaires du même livre : le contenu est identique, mais ce sont deux objets physiques distincts.
Pour comparer le contenu, il faut utiliser une méthode spécifique, souvent appelée equals() ou isEqual(). Cette méthode va comparer champ par champ. C'est ce qu'on appelle l'égalité sémantique. Mais attention, si vous ne redéfinissez pas cette méthode, votre objet utilisera par défaut la comparaison de référence. Et là, vous passez à côté de la logique métier.
C'est un piège classique pour les débutants. Ils créent deux listes identiques, les comparent avec ==, obtiennent "Faux", et passent deux heures à déboguer avant de comprendre que l'ordinateur compare les adresses et pas le contenu. Autant dire que ça fait mal aux yeux quand on le voit arriver en production.
Comparatif : Égalité stricte, faible et approximative
Il n'existe pas une seule façon de vérifier une égalité. Selon le contexte, la rigueur attendue change. Voyons les différences entre les approches pour bien choisir la bonne stratégie selon votre besoin.
L'égalité stricte (===)
C'est la plus dure. En JavaScript, le triple égal === vérifie la valeur ET le type. 5 === "5" est faux. Le nombre 5 n'est pas la chaîne de caractères "5". C'est logique, mais ça peut bloquer des conversions implicites utiles. C'est l'approche "sécurité maximale". On ne veut aucune ambiguïté.
Dans les bases de données SQL, c'est similaire. Un entier et un texte ne sont pas comparables directement sans cast explicite. Cette rigueur évite des erreurs de jointure silencieuses qui pourraient corrompre vos rapports d'analyse. Si vous cherchez la précision absolue, c'est le seul chemin.
L'égalité faible (==)
À l'inverse, le double égal == en JavaScript tente de convertir les types pour les rendre compatibles. 5 == "5" devient vrai car la chaîne est convertie en nombre. C'est pratique pour l'écriture rapide, mais dangereux. 0 == "" est vrai en JS. Zéro est égal à une chaîne vide ? Logiquement, c'est discutable. Mais pour la machine, après conversion, oui.
Cette souplesse permet du "duck typing" (si ça marche comme un canard, c'est un canard), mais elle rend le code imprévisible. Un changement de type invisible peut faire passer un test de vrai à faux sans que vous modifiiez la logique. Je reste convaincu qu'il faut éviter l'égalité faible dans les systèmes critiques.
L'égalité approximative (Tolérance)
On l'a vu avec les flottants, mais ça s'applique aussi aux mesures physiques ou aux données statistiques. Deux moyennes sont-elles égales ? Probablement pas au dixième décimale. Mais sont-elles statistiquement indifférenciables ? C'est la question du test d'hypothèse (test t de Student par exemple).
Ici, l'égalité devient une probabilité. On dit "il y a 95% de chances que ces deux groupes soient égaux". Ce n'est plus une vérité binaire, c'est une zone grise. C'est essentiel en science des données. Vouloir une égalité parfaite sur des données bruitées est une quête vainue.
Les 4 erreurs fatales qui faussent vos vérifications
Même avec les meilleures intentions, on se trompe. Voici les pièges récurrents qui transforment une vérification simple en catastrophe logique.
Ignorer la précision des types de données
On stocke un prix dans un float, on le multiplie, on le compare. Erreur. Les flottants perdent des bits. Pour de l'argent, il faut utiliser des types décimaux (Decimal en Python, BigDecimal en Java) ou stocker les valeurs en centimes (entiers). Un centime perdu sur un million de transactions, ça fait un trou dans la caisse.
Confondre affectation et comparaison
En C ou en PHP, une erreur de frappe classique : écrire if (x = 5) au lieu de if (x == 5). Le premier cas affecte la valeur 5 à x et retourne "Vrai" (car 5 est truthy). Le second compare. Résultat : votre condition est toujours vraie, et votre variable est corrompue. C'est vicieux car le code compile sans erreur.
Négliger l'ordre des opérations
Dans les expressions complexes, la priorité des opérateurs peut changer le résultat. a + b == c + d n'est pas la même chose que a + (b == c) + d selon le langage. Les parenthèses sont vos amies. Ne faites jamais confiance à la mémoire sur les priorités implicites.
Oublier les valeurs nulles (Null)
Le null est l'ennemi de l'égalité. En SQL, NULL == NULL est faux (ou plutôt inconnu). Un champ vide n'est pas égal à un autre champ vide car on ne sait pas ce qu'il y a dedans. En code, comparer un objet null sans vérification préalable plante l'application (NullPointerException). Il faut toujours gérer le cas nul avant de comparer le contenu.
Questions fréquentes sur la validation des égalités
Peut-on prouver une égalité avec des exemples ?
Non, jamais. Un exemple ne prouve qu'un cas particulier. Il peut servir à prouver qu'une égalité est fausse (un contre-exemple suffit), mais il ne peut jamais prouver qu'elle est vraie universellement. C'est une règle d'or en logique.
Pourquoi 0.1 + 0.2 ne fait pas 0.3 en informatique ?
C'est un problème de représentation binaire. Comme 1/3 ne peut pas s'écrire exactement en décimal (0.3333...), 0.1 ne peut pas s'écrire exactement en binaire. La somme accumule ces micro-erreurs de représentation. C'est inhérent au standard IEEE 754 utilisé par presque tous les processeurs.
Quelle est la différence entre identité et équation ?
L'identité est vraie pour toutes les valeurs des variables (ex: trigonométrie). L'équation n'est vraie que pour certaines valeurs inconnues qu'il faut trouver (les solutions). Confondre les deux mène à des erreurs de résolution.
Comment comparer deux objets complexes en code ?
Il faut implémenter une méthode de comparaison profonde (deep equality) qui vérifie récursivement toutes les propriétés des objets, et pas juste leur adresse mémoire. La plupart des langages modernes offrent des librairies pour ça (comme Lodash en JS).
Verdict : La vérité est une question de contexte
Alors, comment savoir si une égalité est vraie ? La réponse courte est : ça dépend de votre outil et de votre exigence. En maths pures, c'est une démonstration logique sans compromis. En code, c'est une gestion minutieuse des types et de la mémoire. Dans le monde réel, c'est une affaire de tolérance et de mesure.
Mon conseil ? Ne faites jamais confiance à l'évidence. Même $1+1=2$ demande à être défini dans un système axiomatique cohérent. Quand vous codez ou calculez, assumez que l'égalité stricte est l'exception, pas la règle. Vérifiez les types, gérez les arrondis, et surtout, demandez-vous toujours ce que vous comparez vraiment : des valeurs, des références, ou des concepts ?
Finalement, savoir si une égalité est vraie, c'est moins une question de calcul qu'une question de définition. Si vous définissez mal vos termes, aucune vérification ne sauvera votre raisonnement. C'est peut-être ça, la leçon la plus importante : avant de chercher la réponse, assurez-vous de poser la bonne question.