Excel renvoie #N/A sur une RECHERCHEV entre deux exports CSV quand les valeurs semblent identiques à l'écran mais ne le sont pas en mémoire. L'une des colonnes stocke la clé comme texte, l'autre comme nombre, date sérielle ou chaîne avec des caractères invisibles. RECHERCHEV compare la valeur stockée, pas l'affichage.

Ce n'est pas un problème de formule. C'est un problème d'import. Les fichiers CSV ne transportent pas les types de données Excel. À l'ouverture, Excel décide lui-même comment interpréter chaque colonne. Deux cellules qui s'affichent de façon identique peuvent donc stocker deux valeurs différentes.

Pourquoi la correspondance échoue même quand les valeurs paraissent identiques

C'est pour cette raison que mettre une colonne au format Nombre ou Date ne change souvent rien. Le format modifie l'affichage. Il ne modifie pas toujours la valeur stockée.

C'est le problème classique de RECHERCHEV qui ne trouve pas une valeur texte-nombre. La fonction fait une comparaison stricte, et stricte veut dire stricte.

Examinez la première ligne défaillante avant de modifier tout le fichier

Trouvez une ligne qui devrait correspondre et ne correspond pas. Testez-la dans des colonnes auxiliaires avant de toucher à la feuille entière.

Si ces vérifications ne révèlent aucune différence de format, le problème est ailleurs : la clé de recherche est incorrecte, la plage de recherche commence sur la mauvaise colonne, le quatrième argument de RECHERCHEV est absent, ou la valeur est simplement inexistante.

Corriger les colonnes texte et nombre sans détruire les identifiants

Si la colonne doit être numérique, convertissez-la dans une colonne auxiliaire. Ne modifiez pas d'abord la colonne brute du CSV.

La distinction à retenir : certaines valeurs doivent devenir des nombres, d'autres doivent rester du texte. Si la clé est 000731, la convertir en 731 règle un problème et en crée un autre.

Pour qu'un identifiant complété reste comparable, forcez les deux côtés en texte au lieu de convertir l'un d'eux en nombre. Si un fichier stocke 000731 en texte et l'autre 731 en nombre, donnez aux deux le même masque de largeur fixe :

=TEXTE(A2,"000000")

Faites la correspondance sur le résultat. La largeur du masque doit égaler la longueur réelle de la référence, sinon vous complétez un côté plus que l'autre et recréez l'incompatibilité. Si les identifiants n'ont pas une largeur fixe, ne complétez pas. Importez plutôt les deux colonnes en texte, avant qu'Excel ne supprime les zéros.

Données > Convertir > Terminer est une correction rapide quand toute une colonne numérique ou de dates a mal été importée. Cela force Excel à réinterpréter les valeurs. Utilisez-le sur les montants et les dates. Ne l'utilisez pas sur les identifiants qui dépendent des zéros de tête.

Supprimer les espaces et les caractères invisibles quand seulement certaines lignes échouent

Un espace en fin de cellule suffit pour que RECHERCHEV renvoie #N/A. Idem pour un espace insécable copié depuis un export web, une tabulation ou un saut de ligne dans la cellule.

Confirmez d'abord quel caractère vous avez. La correction en dépend. =CODE(DROITE(A2,1)) renvoie 32 pour un espace normal, 160 pour un espace insécable et 9 pour une tabulation. Un espace normal cède à SUPPRESPACE(). CAR(160) non, car SUPPRESPACE() ne retire que l'espace standard. Les espaces insécables viennent des pages web et des exports via navigateur, et ils survivent à chaque SUPPRESPACE() jusqu'à ce que vous les substituiez.

Pour les fichiers CSV, la formule auxiliaire la plus sûre est :

=SUPPRESPACE(EPURAGE(SUBSTITUE(A2,CAR(160)," ")))

Appliquez-la sur les deux fichiers, puis pointez la recherche sur les colonnes nettoyées plutôt que sur l'export brut. Si la correspondance échoue encore, le caractère n'est pas en fin de cellule. Parcourez la valeur avec =CODE(STXT(A2,n,1)) pour trouver un espace insécable ou une tabulation inséré à l'intérieur. INV puis CAR(160) puis 1007 ne correspondra jamais à INV-1007, quel que soit le nombre d'espaces de fin que vous retirez. Si les échecs se concentrent sur un seul fichier source, pourquoi les espaces masqués cassent la correspondance dans les fichiers CSV approfondit l'origine de ces caractères invisibles.

Ramener les deux colonnes de dates à une clé commune

Les colonnes de dates sont l'endroit où l'incompatibilité de format entre fichiers CSV se dissimule le mieux. Un fichier ouvre 2026-05-01 comme texte. L'autre ouvre 05/01/2026 comme date Excel réelle. Même après avoir formaté les deux cellules de façon identique, la correspondance peut continuer d'échouer : l'une est du texte, l'autre est un nombre sériel.

Pour une date texte au format jj/mm/aaaa, utilisez :

=TEXTE(DATE(DROITE(A2,4),STXT(A2,4,2),GAUCHE(A2,2)),"aaaa-mm-jj")

Si la source est au format mm/jj/aaaa, inversez les positions du jour et du mois dans cette formule. L'objectif n'est pas un affichage plus propre. L'objectif est que les deux fichiers produisent exactement la même clé stockée.

Validez la correction sur une ligne réelle avant de normaliser tout le fichier

Une correction sur l'ensemble de la feuille est plus sûre quand vous pouvez montrer qu'une ligne défaillante spécifique devient une ligne correspondante pour une raison précise.

Supposons que le fichier A contient :

Et que le fichier B contient :

En comparant ces valeurs brutes directement, chaque recherche peut échouer pour une raison différente :

• l'identifiant échoue parce qu'un côté a conservé les zéros de tête et l'autre non
• la date échoue parce qu'un côté est du texte et l'autre un nombre sériel
• le montant échoue parce qu'un côté est stocké en texte avec ponctuation

La correction n'est pas une seule formule copiée aveuglément sur toutes les colonnes. Ce sont trois décisions de normalisation distinctes :

Une fois qu'une ligne correspond après la bonne normalisation, copiez la correction sur toute la colonne. Cet ordre a de l'importance : il vous évite de « corriger » 5 000 lignes avec la mauvaise règle de conversion.

La correction qui crée une deuxième incompatibilité

La mauvaise correction la plus fréquente consiste à tout convertir en nombres parce que la première ligne défaillante semblait numérique.

Cela provoque une deuxième erreur dans les cas où la clé n'est que d'apparence numérique :

L'erreur inverse existe aussi : on enveloppe toutes les clés de recherche dans TEXTE() et on transforme accidentellement des comparaisons de montants en comparaisons de chaînes de texte.

La bonne question n'est pas « comment faire paraître les deux colonnes identiques ? » La bonne question est « quel type ce champ doit-il avoir pour la correspondance ? »

Voici la règle :

• Identifiants et références : texte en général
• Dates : une clé de comparaison reconstruite en général
• Montants : nombres en général

Si une correction résout la première ligne défaillante mais crée une nouvelle incompatibilité dans la catégorie de lignes suivante, vous n'avez pas normalisé le fichier. Vous avez seulement déplacé l'erreur.

Pointez RECHERCHEV sur les colonnes normalisées, pas sur l'export brut

Une fois que chaque côté dispose d'une clé auxiliaire nettoyée, construisez la recherche sur cette clé.

Un schéma de base ressemble à ceci :

=RECHERCHEV(E2,$J$2:$K$5000,2,FAUX)

Dans cet exemple, E2 est la clé normalisée du premier fichier, et la colonne J de la table de recherche est la clé normalisée du deuxième fichier. Le FALSE est important. Sans lui, Excel peut tenter une correspondance approximative, ce qui est un problème différent.

Si les deux exports ont aussi des structures et des en-têtes différents, le vrai sujet n'est plus une seule RECHERCHEV. C'est la comparaison des fichiers elle-même. Dans ce cas, comment comparer deux fichiers CSV de relevés bancaires sans formules décrit la bonne méthode.

Quand c'est la même correction à refaire chaque mois

Ce qui ressemble à une erreur de formule de rapprochement Excel est souvent le même problème d'import qui se répète sur de nouveaux exports. Un mois, les dates s'ouvrent en texte. Le mois suivant, les identifiants de transactions perdent leurs zéros de tête. La formule prend le blâme parce que c'est là qu'apparaît l'erreur.