Fonction DGET dans Excel — extraire un seul enregistrement, et échouer bruyamment quand il n'y en a pas

L'essentiel — DGET(database, field, criteria) renvoie la valeur unique d'une colonne là où votre plage de critères correspond à exactement une ligne. Sa signature, c'est qu'il génère une erreur volontairement : #NUM! quand plus d'une ligne correspond, #VALUE! quand aucune ne correspond. Tout le monde les rencontre comme des bugs ; ce sont pourtant la fonctionnalité. Là où VLOOKUP renvoie en silence le premier de plusieurs doublons, DGET refuse et vous signale que votre clé « unique » ne l'est pas. Et parce que les conditions vivent dans une table de critères, DGET fait des recherches multicolonnes (Region et Product) sans colonne auxiliaire. Tournez-vous vers lui quand il devrait y avoir exactement une correspondance et que vous voulez qu'Excel le prouve. Fonctionne dans toutes les versions d'Excel.

=DGET(A1:E200, "Amount", H1:H2)      ' le Amount de l'unique ligne correspondant à H1:H2
=DGET(A1:E200, "Rep", H1:I2)         ' deux conditions (H1:I2) = une recherche ET, sans colonne auxiliaire
=IFERROR(DGET(A1:E200, "Amount", H1:H2), "pas unique / introuvable")   ' sûr en production

VLOOKUP et XLOOKUP sont conçus pour être indulgents : donnez-leur une clé, ils renvoient la première chose qui correspond et ne cherchent jamais plus loin. C'est généralement ce que vous voulez — et parfois une catastrophe, car une clé en double renvoie une mauvaise réponse plausible sans le moindre avertissement. DGET a le tempérament inverse. Il suppose que la correspondance est unique et s'arrête sur une erreur dès l'instant où c'est faux. Une fois que vous voyez cela comme sa raison d'être plutôt que comme un défaut, il devient la recherche la plus tranchante d'Excel pour valider des données.

Remarque : dans une interface Excel en français, cette fonction s'appelle BDLIRE (DGET). Équivalents : VLOOKUP = RECHERCHEV, XLOOKUP = RECHERCHEX, INDEX = INDEX, MATCH = EQUIV, DCOUNT = BDNB, IFERROR = SIERREUR. Les codes d'erreur #NUM! et #VALUE! s'affichent #NOMBRE! et #VALEUR! en français ; les formules ci-dessous utilisent les noms anglais et le comportement est identique.

Ce que vous allez apprendre

Le modèle mental : une recherche qui affirme l'unicité au lieu de deviner
Les trois arguments, et comment DGET réutilise l'idée de la plage de critères
#NUM! contre #VALUE! — les deux erreurs qui vous disent réellement quelque chose
Les recherches multicritères (Region et Product) sans astuce de concaténation
Quand DGET l'emporte sur XLOOKUP — et les cas où c'est le mauvais outil
L'envelopper sans risque, sans masquer ce que les erreurs signifient

Le modèle mental : la recherche qui refuse de deviner

Voyez DGET comme une recherche assortie d'un contrat : « Il existe exactement une ligne qui correspond. Donne-m'en un champ. » Si le contrat tient, vous obtenez la valeur. S'il ne tient pas — zéro correspondance, ou deux — DGET ne cherchera pas à le camoufler. Ce seul choix de comportement est ce qui le distingue de toute autre recherche.

' bloc de critères H1:H2 — une condition :
'   H1: OrderID
'   H2: 10248
=DGET(A1:E200, "Amount", H1:H2)      ' -> le Amount de la commande 10248, SI cet ID est unique

VLOOKUP renverrait volontiers la première commande 10248 même si l'ID apparaît trois fois. DGET, lui, renvoie #NUM! — ce qui, lorsque OrderID est censé être une clé primaire, est exactement l'alarme souhaitée. Il transforme « recherche ceci » en « recherche ceci et confirme que ma clé est vraiment unique », gratuitement.

Les trois arguments (la même forme que toute la famille)

=DGET(database, field, criteria) — identique à DSUM et DCOUNT :

database — le tableau y compris sa ligne d'en-têtes (A1:E200). Les en-têtes sont ce par quoi le champ et les critères sont reliés aux colonnes ; omettez-les et DGET casse.
field — la colonne dont renvoyer une valeur, nommée par en-tête entre guillemets ("Amount"), par une cellule contenant l'en-tête, ou par un numéro de colonne. L'en-tête entre guillemets est le choix lisible et à l'épreuve des modifications.
criteria — la plage contenant votre bloc en-tête-et-conditions, exactement comme les autres fonctions de base de données. Mêmes règles : même ligne = ET, lignes empilées = OU, les en-têtes doivent correspondre aux données caractère par caractère.

Tout ce que vous savez de la construction d'une plage de critères se transpose directement. La seule chose qui change, c'est la promesse : DGET attend de ce bloc qu'il sélectionne une seule ligne.

#NUM! et #VALUE! sont tout l'intérêt

La plupart des fonctions ont un seul état d'erreur. DGET en a deux, et elles signifient des choses opposées — apprendre à les lire, c'est 90 % de son bon usage.

=DGET(A1:E200, "Amount", H1:H2)
'   -> la valeur        : exactement une ligne a correspondu (le cas idéal)
'   -> #NUM!            : PLUS D'UNE ligne a correspondu — votre clé n'est pas unique
'   -> #VALUE!          : AUCUNE ligne n'a correspondu — rien ne colle aux critères

#NUM! veut dire « trop ». Deux lignes ou plus satisfont vos critères. Si le champ était censé être une clé unique, vous venez de découvrir un doublon que vous ignoriez — une trouvaille réellement utile. Si vous attendiez plusieurs correspondances, DGET est tout simplement la mauvaise fonction (vous voulez une somme, un filtre, ou une recherche sur la première correspondance).
#VALUE! veut dire « aucune ». Rien n'a correspondu — une clé mal tapée, un en-tête de critère qui ne correspond pas aux données, ou une valeur absente.

Comme les deux erreurs sont diagnostiques, résistez à l'envie de les avaler toutes deux avec un IFERROR("") généralisé. « Clé en double » et « introuvable » sont des problèmes différents et méritent souvent un traitement différent.

Recherches multicritères, sans colonne auxiliaire

C'est ici que DGET surclasse discrètement VLOOKUP par sa conception. Parce que les conditions vivent dans une table de critères, ajouter une deuxième condition revient simplement à ajouter une colonne — vous obtenez une recherche ET sans clé auxiliaire concaténée.

' Trouver le Rep pour la ligne West + Widgets :
'   H1: Region    I1: Product
'   H2: West      I2: Widgets
=DGET(A1:E200, "Rep", H1:I2)         ' correspond sur les DEUX colonnes à la fois

Le contournement classique de VLOOKUP pour une clé à deux colonnes consiste à construire une colonne auxiliaire de Region&Product et à rechercher "West"&"Widgets" — fragile et encombrant. DGET n'en a pas besoin : posez deux en-têtes sur la ligne supérieure, deux conditions en dessous, et la correspondance se fait en ET sur toute la ligne. Et vous conservez la garantie d'unicité — si West + Widgets n'est pas unique, vous le saurez.

Quand DGET l'emporte sur XLOOKUP — et quand non

DGET est un spécialiste, et l'employer hors de son domaine est la source de l'essentiel de la frustration que les gens rapportent.

Tournez-vous vers DGET quand :

La correspondance devrait être unique et vous voulez que ce soit imposé — un rapprochement sur un numéro de facture, l'extraction d'une valeur de configuration, la validation d'une clé.
Vous avez besoin d'une recherche ET multicolonne et préférez ne pas bâtir de clé auxiliaire.
Les critères doivent être visibles et modifiables sur la feuille.

Utilisez plutôt XLOOKUP ou INDEX/MATCH quand :

Les doublons sont attendus et vous voulez la première correspondance (ou la dernière), pas une erreur. DGET ne fera jamais que lever #NUM! ici.
Vous recopiez la recherche sur des centaines de lignes — XLOOKUP est plus léger qu'un bloc de critères par ligne.
Vous avez besoin d'une correspondance approximative ou au plus proche. DGET ne fait que de la correspondance exacte.

Le test en une ligne : plus d'une correspondance est-elle une erreur, ou une attente ? Si c'est une erreur, DGET est la seule recherche qui la traite comme telle.

L'envelopper pour la production (sans avancer à l'aveugle)

Des formules en production ne devraient pas montrer de #NUM!/#VALUE! bruts aux utilisateurs finaux, mais une capture globale jette le diagnostic à la poubelle. Distinguez les deux quand c'est important :

' Simple, quand les deux problèmes reviennent au même pour l'utilisateur :
=IFERROR(DGET(A1:E200, "Amount", H1:H2), "Aucune correspondance unique")

' Mieux, quand doublon et absence appellent des traitements différents :
=IF(DCOUNT(A1:E200, "Amount", H1:H2) = 1,
    DGET(A1:E200, "Amount", H1:H2),
    IF(DCOUNT(A1:E200, "Amount", H1:H2) = 0, "Introuvable", "Clé en double !"))

Le second motif utilise DCOUNT sur les mêmes critères pour signaler quelle défaillance s'est produite — transformant la rigueur de DGET en un message clair plutôt qu'un code d'erreur. Voilà DGET à son meilleur : non pas une recherche tatillonne, mais une recherche qui rend les données erronées impossibles à ignorer.

Comment ExcelMaster aide

DGET récompense les blocs de critères précis et punit les approximatifs, c'est-à-dire précisément la partie délicate. Dites à ExcelMaster « récupère le montant de l'unique commande West + Widgets » et il construit la table de critères à deux colonnes, fait correspondre les en-têtes à vos données, et écrit le =DGET(...). Confiez-lui un DGET qui lève #NUM! et il explique quelles lignes se télescopent — révélant la clé en double dont vous ignoriez l'existence, au lieu de simplement masquer l'erreur.

Questions fréquentes

Pourquoi DGET renvoie-t-il #NUM! ?

Parce que plus d'une ligne correspond à vos critères. DGET renvoie exactement une valeur et traite les correspondances multiples comme une erreur — souvent utile, puisqu'elle signifie qu'une clé que vous supposiez unique ne l'est pas. Si vous attendez réellement plusieurs correspondances, utilisez plutôt SUMIFS, FILTER, ou une recherche sur la première correspondance comme XLOOKUP.

Pourquoi DGET renvoie-t-il #VALUE! ?

Parce qu'aucune ligne ne correspond. Les causes habituelles sont un critère mal tapé, un en-tête de critère qui ne correspond pas exactement à un en-tête de la base de données, ou une valeur tout bonnement absente du tableau. Vérifiez d'abord l'orthographe de l'en-tête — c'est le coupable le plus fréquent de toutes les fonctions de base de données.

En quoi DGET diffère-t-il de VLOOKUP ?

VLOOKUP renvoie la première correspondance et ignore les doublons en silence. DGET exige une seule correspondance et génère une erreur (#NUM!) s'il y en a plus d'une. DGET fait aussi la correspondance sur plusieurs colonnes grâce à sa plage de critères, là où VLOOKUP réclame une clé auxiliaire concaténée. Utilisez VLOOKUP/XLOOKUP pour des recherches indulgentes sur la première correspondance ; utilisez DGET quand l'unicité doit être garantie.

DGET peut-il faire correspondre plusieurs colonnes ?

Oui — c'est une force fondamentale. Placez chaque en-tête sur la ligne supérieure de la plage de critères et chaque condition juste en dessous, sur la même ligne pour une logique ET : Region=West et Product=Widgets sur une seule ligne ne fait correspondre que les lignes satisfaisant les deux, sans colonne auxiliaire.

DGET fonctionne-t-il dans Excel 2016 et versions antérieures ?

Oui. DGET, comme le reste des fonctions de base de données, est dans Excel depuis des décennies et se comporte à l'identique dans Excel 2016, 2019, 2021 et 365. Aucun piège de disponibilité selon la version à redouter.

Testé dans

Testé dans : Excel 365 (Windows 11) — dernière vérification le 2026-07-20.

Guides associés : Excel DSUM et DCOUNT · Fonctions de base de données Excel · Excel VLOOKUP · Excel INDEX et MATCH · Excel XLOOKUP