Outils et intégrations (CSL / arXiv / gestionnaires)

Ce qui dévore vraiment du temps dans une bibliographie, ce n’est pas la saisie des entrées .bib. C’est de garder un seul et même .bib cohérent entre une thèse, trois soumissions et deux coauteurs. C’est pourquoi la plupart des outils bibliographiques de LaTeX sont conçus moins pour accélérer la saisie que pour repérer ce qui a cassé après elle. Cette page parcourt tout le trajet : récupérer des notices depuis un DOI ou arXiv, nettoyer les entrées sales, éliminer les doublons et figer les clés de citation avant de transmettre le fichier à un coauteur — avec des gestionnaires de références comme Zotero et JabRef autant qu’avec les utilitaires en ligne de commande bibcop, checkcites et biber --tool que TeX Live a déjà installés.

Obtenir du BibTeX depuis un DOI ou un identifiant arXiv

Si un article porte un DOI, son entrée .bib est à une commande de distance. Le mécanisme s’appelle négociation de contenu : on indique à doi.org, via un en-tête HTTP, que l’on veut du BibTeX, et l’agence qui a enregistré le DOI — le plus souvent Crossref pour les articles scientifiques — met ses métadonnées en forme de notice BibTeX et la renvoie. Nul besoin d’ouvrir la page de l’éditeur : le DOI est lui-même l’interface.

# fetch BibTeX for a DOI; -L follows the redirect to the registration agency
curl -LH "Accept: application/x-bibtex" \
  "https://doi.org/10.1145/3186893" >> refs.bib

Sans -L, rien ne revient. doi.org n’est qu’un guichet qui détermine quelle agence détient les métadonnées et vous y redirige ; sans suivre la redirection, la requête n’aboutit à rien. Si la ligne de commande rebute, il suffit de coller le DOI dans doi2bib.org, qui emballe la même négociation de contenu dans une page web (les identifiants arXiv et PubMed sont aussi acceptés). Un preprint arXiv propose « Export BibTeX citation » sur sa page de résumé, et Google Scholar cache la même chose derrière « Cite → BibTeX » sur chaque résultat. Quelle que soit la voie, on ne tape presque rien.

Pourquoi le BibTeX importé n’est presque jamais utilisable tel quel

Parce qu’un exportateur se contente de recracher les chaînes présentes dans sa propre base ; il ignore tout des exigences de LaTeX. Récupérez le même article sur le site de l’éditeur, sur Crossref et sur Google Scholar : vous obtiendrez trois notices BibTeX différentes. Ce sont toujours les quatre mêmes choses qui cassent, et chacune ne se révèle qu’au moment de la composition.

• Les majuscules ne sont pas protégées. Sans accolades dans le titre — {DNA}, {Fourier} —, les styles de la famille plain les passent en minuscules : « dna », « fourier ». La page sur la base bibliographique en détaille le mécanisme.
• Les noms de revues sont abrégés, ou pas. La même revue arrive une fois en Comput. J. et une fois en The Computer Journal, et la liste de références se contredit elle-même. Les consignes aux auteurs exigent presque toujours l’un ou l’autre.
• Le type d’entrée est faux. Les communications de conférence sont souvent exportées en @article ou @misc, et un @inproceedings sans booktitle se compose en charabia.
• La version arXiv est prise pour la version publiée. Le BibTeX d’un preprint n’a en général ni journal ni doi : on continue donc de citer l’ancienne notice longtemps après la parution dans une revue à comité de lecture.

Vérifier et normaliser un .bib : bibcop et biber --tool

Plutôt que de traquer ces quatre points à l’œil, autant confier le travail à un linter. TeX Live embarque déjà bibcop, un linter écrit pour les fichiers .bib : aucune installation supplémentaire, il suffit de lancer bibcop refs.bib. Ce qui revient n’est pas une colonne de numéros de ligne mais des reproches en phrases complètes — par exemple Do not shorten the words in the journal, such as Comput., All major words in the title must be capitalized, A mandatory doi tag for @article is missing. Se faire réprimander en langage lisible ne laisse aucun doute sur ce qu’il faut corriger.

# lint a database in place
bibcop refs.bib

# reformat and sort every entry; also reports duplicate keys
biber --tool --output-align --output-fieldcase=lower \
  --output-file=clean.bib refs.bib

Le reformatage lui-même revient à biber --tool. Outre le mode ordinaire qui traite un document, biber possède un mode tool fonctionnant comme un filtre autonome : .bib en entrée, .bib en sortie. Il réaligne les champs en colonnes, trie les entrées et, si deux entrées partagent une clé, avertit Duplicate entry key: ... skipping et en écarte une. Un piège s’y cache toutefois. La sortie du mode tool est par défaut normalisée aux noms de champs de biblatex : year devient date et journal devient journaltitle. Pour un document biblatex, c’est exactement ce qu’on souhaite ; mais faites passer un .bib destiné au BibTeX d’origine et les années comme les noms de revues disparaissent de la bibliographie.

Repérer les entrées en double et les clés de citation orphelines

Quand la même clé apparaît deux fois, BibTeX annonce Repeated entry---line 8 of file refs.bib et jette la seconde ; biber, lui, avertit Duplicate entry key. Le cas le plus retors est le doublon aux clés différentes mais au contenu identique, dont rien ne prévient. Fusionnez les exports Zotero de deux coauteurs et le même article figure deux fois, sous smith2020 et sous Smith2020a — un accident que l’on découvre en général en voyant la même ligne apparaître deux fois dans la bibliographie composée.

Pour la comparaison par contenu, l’indice le plus fiable est le DOI. Les noms d’auteurs et les titres varient, mais deux entrées partageant un DOI sont le même article, point final. C’est exactement ce qu’implémente bibtex-tidy : on choisit le critère avec --duplicates doi (ou key, abstract, citation) et --merge fond l’une dans l’autre. Le problème inverse — citer une clé absente du .bib, d’où un [?] dans le texte — relève de checkcites. --undefined liste les clés citées mais jamais définies ; --unused liste les entrées définies que personne ne cite.

# BibTeX projects read the .aux; biblatex projects read the .bcf
checkcites paper.aux
checkcites --backend biber paper.bcf

# keys cited but missing from the database
checkcites --undefined paper.aux

Quel gestionnaire de références choisir : Zotero, JabRef, BibDesk

Jusqu’à quelques dizaines d’entrées, éditer le .bib à la main suffit ; à quelques centaines, un gestionnaire s’impose. La bifurcation tient à une question : le .bib est-il l’original ou un export ? JabRef et BibDesk ouvrent et enregistrent le .bib lui-même, et cohabitent donc avec l’édition directe dans un éditeur de texte. Zotero considère sa propre bibliothèque comme l’original, et le .bib devient un produit dérivé qu’il engendre.

• Zotero — la référence gratuite et open source. Un connecteur de navigateur capture un article en un clic, enregistre le PDF et prend en charge les bibliothèques de groupe partagées. Pour qui écrit en LaTeX, l’extension Better BibTeX est à considérer comme quasi obligatoire.
• Better BibTeX (extension Zotero) — engendre les clés de citation à partir d’un motif et propose l’auto-export, qui répercute chaque modification de la bibliothèque directement dans le .bib. C’est tout son intérêt : le .bib devient un artefact toujours à jour.
• JabRef — un gestionnaire open source qui travaille nativement sur .bib. Sans format interne distinct, il récupère des entrées depuis un DOI, un identifiant arXiv ou un ISBN et propose un nettoyage groupé des entrées sélectionnées. Il tourne sous Windows, macOS et Linux.
• BibDesk (macOS) — une interface BibTeX pour Mac, livrée avec MacTeX (/Applications/TeX/BibDesk.app). Elle édite directement le .bib et gère le classement automatique des PDF ainsi que la recherche dans des bases externes.
• Mendeley — l’ancien Mendeley Desktop a été retiré le 1er septembre 2022, et la synchronisation automatique d’un .bib a disparu avec lui. Le successeur, Mendeley Reference Manager, exporte toujours du BibTeX, mais seulement de façon manuelle.
• Paperpile — service payant, très intégré à Google Docs, qui exporte lui aussi du BibTeX.

Du côté de Zotero, tout a bougé en 2026. Zotero 8 a fait de la clé de citation un champ natif de Zotero, supplantant l’emplacement que détenait Better BibTeX. Les clés sont désormais toujours épinglées et se synchronisent entre machines : le rituel consistant à faire « Pin BibTeX Key » sur chaque référence a disparu. Mais Zotero ne génère pas les clés lui-même — les fabriquer à partir d’un motif et tenir le .bib à jour par auto-export reste le travail de Better BibTeX. À noter aussi : Better BibTeX a cessé de prendre en charge Zotero 7, ce montage suppose donc de garder Zotero à jour.

Figer les clés de citation et partager un .bib avec des coauteurs

Une clé de citation est l’interface entre le manuscrit et la base bibliographique ; c’est donc la seule chose qui ne doit jamais bouger. Si l’export est réglé pour recalculer les clés à chaque fois, tous les \cite{...} du corps cessent d’un coup de se résoudre et le PDF se remplit de [?]. La convention elle-même importe peu, mais nom + année + titre abrégé — quelque chose comme knuth1984literate — entre rarement en conflit, avec ce bénéfice annexe que la clé seule indique de quel article il s’agit.

Pour le partage, le montage le moins accidentogène consiste à placer le .bib dans le même dépôt Git que le manuscrit. C’est du texte brut : les diffs se lisent, et l’historique garde trace de qui a ajouté quelle entrée. Laissé à lui-même, le fichier entrera pourtant sans cesse en conflit ; le remède est de figer l’ordre de sortie. Que tout le monde passe biber --tool avant de committer, ou que l’auto-export de Better BibTeX vise un chemin convenu — dans les deux cas, dès que l’ordre des lignes se stabilise, les conflits de fusion s’effondrent. Ce qu’il ne faut surtout pas faire : s’envoyer par courriel ses .bib locaux. Deux semaines plus tard, il existe quatre .bib différents.

# ship only the entries this paper actually cites
pdflatex paper.tex
bibexport -o submission.bib paper.aux

Juste avant la soumission, le sens s’inverse : il faut découper un .bib. La plupart des revues réclament les sources complètes du manuscrit, et il est hors de question d’y joindre une base personnelle de 800 entrées. bibexport lit le .aux et n’écrit dans un nouveau .bib que les entrées réellement citées par \cite, ce qui correspond exactement au besoin (bibtool sait analyser le .aux et faire de même). Pour la même raison, tenir un gros .bib maître et en découper une tranche par manuscrit s’avère au quotidien plus commode.

Transmettre le même .bib à qui n’utilise pas LaTeX : CSL et pandoc

Même si un coauteur écrit sous Word, il n’y a pas à renoncer au .bib. CSL (Citation Style Language) est un format XML décrivant l’apparence des citations et des bibliographies, et sa propriété déterminante est d’être indépendant du moteur de composition. Un .bst BibTeX ne fonctionne qu’avec BibTeX et un style biblatex qu’à l’intérieur de LaTeX ; un .csl, lui, n’est lié à rien. La mise en forme est assurée par un processeur citeproc, et Zotero, les extensions Word et divers convertisseurs lisent le même .csl chacun via sa propre implémentation de citeproc. Le dépôt de styles de Zotero compte des milliers de styles de revues, librement utilisables.

pandoc paper.md --citeproc \
  --bibliography=refs.bib \
  --csl=ieee.csl \
  -o paper.pdf

L’outil qui exploite le plus CSL est pandoc. Convertissez un manuscrit Markdown avec --citeproc et les clés de citation du corps, comme [@knuth1984], deviennent des citations mises en forme, avec une bibliographie ajoutée à la fin. --bibliography accepte le .bib tel quel (et peut être répété pour en fusionner plusieurs) ; sans --csl, c’est Chicago author-date qui s’applique. Bref : le même .bib alimente une sortie directement de Markdown vers PDF, Word ou HTML, sans LaTeX sur le chemin.

Au fond, tous les outils de cette page reposent sur la même prémisse : le patrimoine, c’est le .bib, pas la voie de sortie. Dès lors qu’existe une base unique — alimentée par des DOI, sermonnée par bibcop, lissée par biber --tool, aux clés figées, déposée dans Git —, produire un PDF via biblatex ou remettre un fichier Word à un coauteur via pandoc n’est plus qu’un choix de sortie. Garder la base unique rapporte bien davantage que d’empiler des outils.