Alternatives à l'API Frankfurter en 2026 : une comparaison honnête pour développeurs

Si vous cherchez des alternatives à l'API Frankfurter, vous avez probablement déjà mis quelque chose en production avec elle. Frankfurter est l'API de taux de change gratuite par défaut de toute une génération de projets personnels : pas de clé d'API, pas d'inscription, pas de quota, une surface REST propre et un code open source qui se lit en un après-midi. Puis quelque chose change — une question de conformité, un bug du week-end, un client qui a besoin de taux intrajournaliers — et vous commencez à vous demander ce qui existe d'autre.

Ce guide porte un regard honnête sur cette décision. Il détaille ce que Frankfurter fait réellement en 2026 (la plupart des articles comparatifs s'appuient sur des informations périmées), les cinq limites précises qui poussent les équipes à partir, et les trois voies réalistes : l'auto-héberger, migrer vers une API commerciale à clé, ou monter un système hybride. Un exemple de migration figure à la fin.

Ce qu'est réellement Frankfurter en 2026

Presque tous les comparatifs « meilleures API de devises gratuites » décrivent encore Frankfurter comme « les taux de la BCE, une trentaine de devises, pas de données le week-end ». C'était vrai pendant des années. Ça ne l'est plus.

L'API v2 sur frankfurter.dev suit les taux quotidiens de 84 banques centrales, couvre 201 devises, avec un historique remontant à 1948. Elle est réellement gratuite pour un usage commercial, ne demande aucune authentification, ne publie aucun quota mensuel ou journalier, et propose des sorties CSV et NDJSON en plus du JSON. Il existe une spécification OpenAPI, un llms.txt et un serveur MCP pour les workflows d'agents. Vous pouvez l'auto-héberger avec Docker.

C'est un produit plus solide que ce que les comparatifs laissent entendre, et il faut le dire clairement : pour un grand nombre de projets, Frankfurter est la bonne réponse et vous ne devriez pas migrer. Si vous construisez un suivi de finances personnelles, une page de référence des devises, un outil de facturation qui fixe les taux une fois par jour, ou un notebook de data science qui télécharge dix ans de moyennes mensuelles, Frankfurter le fait bien et ne coûte rien.

Le reste de cet article traite des cas où elle ne suffit pas.

Cinq limites qui poussent les équipes à chercher des alternatives à l'API Frankfurter

1. Des taux de référence quotidiens ne sont pas des taux en direct

C'est la limite structurelle, et ce n'est pas un défaut : c'est la nature même de la source. Les taux de référence des banques centrales sont publiés une fois par jour ouvré. La BCE, par exemple, publie ses taux de référence de l'euro chaque jour ouvrable vers 16h00 CET. Frankfurter expose fidèlement ces chiffres.

Autrement dit, un taux récupéré à 09h00 et un taux récupéré à 15h00 sont le même nombre, même si le marché a bougé de 1,2 % entre-temps. Pour un convertisseur d'affichage, personne ne le remarque. Pour une page de paiement, un calcul de reversement, ou tout ce que le client compare avec Google, ce décalage devient un ticket de support.

Si votre produit a besoin de taux qui bougent dans la journée, il vous faut une source de données de marché plutôt qu'une source de taux de référence. L'API Finexly se rafraîchit chaque minute pendant les heures de marché sur plus de 170 devises : c'est un modèle de données différent, pas une meilleure version du même. Notre article sur d'où viennent les données des API de taux de change approfondit la distinction.

2. Il n'y a pas de lignes pour les week-ends ni les jours fériés

Les banques centrales ne publient pas le samedi, le dimanche ni les jours fériés nationaux. Une requête sur 2026-08-23 ne renvoie donc rien d'exploitable, et une série temporelle sur un mois compte environ 21 lignes, pas 31.

Toutes les équipes se prennent le mur de la même façon : un traitement nocturne s'exécute le dimanche, obtient un résultat vide ou décalé, et soit plante, soit — bien pire — écrit silencieusement un null dans le grand livre. Si vous vous appuyez sur des taux quotidiens issus d'une banque centrale, il vous faut une politique explicite de report de la dernière valeur, et il faut l'écrire noir sur blanc, car « utiliser le dernier taux publié » et « sauter la ligne » produisent des états financiers différents.

3. Les taux mixés peuvent bouger après publication

Par défaut, Frankfurter mélange les taux de tous les fournisseurs contributeurs. Sa propre FAQ est d'une franchise rafraîchissante sur la conséquence : les dernières décimales peuvent changer à mesure que de nouvelles données arrivent, et pour la conformité, il faut filtrer sur un fournisseur précis.

C'est un choix de conception tout à fait raisonnable pour un usage général. Cela devient un problème si vous stockez un taux, l'affichez à un utilisateur, puis le rapprochez plus tard d'une nouvelle récupération : vous trouverez de petits écarts très difficiles à expliquer à un auditeur. Le correctif côté Frankfurter est de passer providers=ECB (ou l'autorité dont vous dépendez) plutôt que d'accepter le mélange. Le correctif dans votre propre système est de persister le taux réellement utilisé au moment de la transaction et de ne jamais le recalculer. Cette règle vaut pour tous les fournisseurs, et nous la détaillons dans le guide taux de change et déclaration fiscale.

4. Pas de clé d'API signifie pas de quota — ni de visibilité

« Aucune clé d'API requise » est la meilleure caractéristique de Frankfurter et son risque le plus sous-estimé. Comme il n'y a pas de clé :

• Vous n'avez aucun quota par application. Vous partagez un limiteur public avec l'internet entier, y compris avec celui qui le martèle en ce moment depuis une boucle mal écrite.
• Vous n'avez aucune télémétrie d'usage. Aucun tableau de bord ne vous dira que votre volume d'appels a triplé mardi dernier.
• Vous n'avez aucune relation de support. Il y a une page de statut et un suivi d'issues GitHub, ce qui est déjà mieux que beaucoup de services gratuits, mais pas de SLA et personne à alerter.

La recommandation du projet lui-même est explicite : pour un usage à fort volume, mettez les réponses en cache, auto-hébergez, ou interrogez directement les jeux de données. C'est un conseil honnête, et c'est aussi le moment où beaucoup d'équipes se mettent à évaluer des alternatives à l'API Frankfurter — non pas parce que les données sont fausses, mais parce qu'elles ont pris une dépendance de production sans aucun contrat derrière.

5. Il n'y a pas d'endpoint de conversion

Frankfurter le documente délibérément : récupérez le taux et multipliez. Trois lignes de code.

Ce sont aussi trois lignes de code qui finissent écrites légèrement différemment à six endroits de votre base, dont l'un divise là où il devrait multiplier. Un endpoint convert dédié n'est pas une nécessité technique ; c'est une façon de n'avoir qu'une seule implémentation des règles d'arrondi et de sens. Si vous avez déjà livré un bug où EUR→USD et USD→EUR divergeaient de 0,3 %, vous savez pourquoi c'est important. Notre guide sur l'arrondi et les décimales monétaires couvre le reste de ce champ de mines.

Alternatives à l'API Frankfurter : comparatif

Les détails des offres gratuites ci-dessous sont ceux publiés par chaque fournisseur au moment de la rédaction. Vérifiez-les avant de vous engager : les offres gratuites changent plus souvent que la documentation.

Deux constats. D'abord, personne ne bat Frankfurter sur le quota, parce que Frankfurter n'en a pas. Si votre contrainte est le volume brut d'appels sur des taux quotidiens, la réponse est d'auto-héberger Frankfurter, pas d'acheter un quota plus petit ailleurs. Ensuite, les offres payantes ne vendent pas les mêmes données mieux emballées : elles vendent une fréquence de mise à jour différente et une relation de support. Si aucune des deux n'est votre problème, migrer est une régression.

Nous détaillons plusieurs d'entre elles côte à côte dans le comparatif des API de devises et dans notre comparatif des API de taux en temps réel.

Option 1 : auto-héberger Frankfurter

La réponse la plus sous-utilisée. Frankfurter publie une image Docker, et l'exécuter vous-même supprime les deux choses qui inquiètent vraiment les équipes en production : le limiteur partagé et l'absence de contrôle.

docker run -d -p 8080:8080 --name frankfurter \
  lineofflight/frankfurter

Ce que vous gagnez : des appels internes illimités, la maîtrise de votre disponibilité, et la possibilité de figer un fournisseur. Ce que vous assumez : un conteneur, une base de données, de la supervision, et quelqu'un qui remarque quand la collecte en amont casse un jour férié bancaire. C'est un coût réel — c'est en gros l'argument de notre analyse construire ou acheter, appliqué à un code que quelqu'un d'autre a déjà écrit.

L'auto-hébergement est le bon choix quand votre volume est élevé, vos exigences de latence strictes, et que des taux de référence quotidiens suffisent réellement. Il n'aide en rien si le problème est le besoin de taux intrajournaliers : vous ferez tourner votre propre copie des mêmes données quotidiennes.

Option 2 : migrer vers une API à clé avec des taux intrajournaliers

Si vous êtes ici pour la fraîcheur des taux, la couverture de paires exotiques, ou le besoin que quelqu'un réponde à un e-mail, une API commerciale à clé est la réponse honnête.

Voici la même tâche des deux côtés. Frankfurter d'abord :

curl "https://api.frankfurter.dev/v2/rate/USD/EUR"

Et l'équivalent Finexly :

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.finexly.com/v1/rate?from=USD&to=EUR"

{ "pair": "USD_EUR", "rate": 0.9215 }

Correspondance des endpoints

Le principal changement de forme concerne l'appel multi-paires. Frankfurter utilise une base et une liste de devises cotées ; Finexly prend une liste de paires BASE_QUOTE explicites, ce qui permet de récupérer USD_EUR et GBP_JPY dans la même requête sans division croisée.

Un wrapper de migration

Ne dispersez pas un nouveau client dans toute votre base. Placez les deux derrière une interface unique, pour que revenir en arrière soit un simple changement de configuration :

import os
import requests

FINEXLY_KEY = os.environ["FINEXLY_API_KEY"]

def get_rate(base: str, quote: str, provider: str = "finexly") -> float:
    """Return the mid-market rate for base->quote."""
    if provider == "frankfurter":
        r = requests.get(
            f"https://api.frankfurter.dev/v2/rate/{base}/{quote}",
            timeout=5,
        )
        r.raise_for_status()
        return float(r.json()["rate"])

    r = requests.get(
        "https://api.finexly.com/v1/rate",
        params={"from": base, "to": quote},
        headers={"Authorization": f"Bearer {FINEXLY_KEY}"},
        timeout=5,
    )
    r.raise_for_status()
    return float(r.json()["rate"])

print(get_rate("USD", "EUR"))

Deux détails à copier. La clé d'API vient de l'environnement, jamais du code source — la documentation Finexly note que les clés passées en paramètre d'URL peuvent fuiter via les journaux d'accès serveur et les en-têtes HTTP Referrer, donc l'en-tête Authorization est la voie de production. Et chaque appel a un timeout, parce que la valeur par défaut de la plupart des clients HTTP est « attendre indéfiniment ».

Surveillez les en-têtes de réponse X-RateLimit-Limit, X-RateLimit-Used et X-RateLimit-Units pour suivre la consommation de quota en temps réel. Cette télémétrie est exactement ce qu'une API non authentifiée ne peut pas vous donner, et c'est souvent la vraie raison pour laquelle les équipes migrent.

Option 3 : l'hybride — mettre l'une en cache, basculer sur l'autre

Le schéma vers lequel convergent la plupart des systèmes en production. Utilisez votre fournisseur principal, mettez agressivement en cache, et gardez l'API gratuite non authentifiée comme ultime recours :

const CACHE = new Map();
const TTL_MS = 60_000;

async function getRate(base, quote) {
  const key = `${base}_${quote}`;
  const hit = CACHE.get(key);
  if (hit && Date.now() - hit.at < TTL_MS) return hit.rate;

  let rate;
  try {
    const res = await fetch(
      `https://api.finexly.com/v1/rate?from=${base}&to=${quote}`,
      { headers: { Authorization: `Bearer ${process.env.FINEXLY_API_KEY}` } }
    );
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    rate = (await res.json()).rate;
  } catch (err) {
    // Degrade to daily reference rates rather than failing the request
    const res = await fetch(`https://api.frankfurter.dev/v2/rate/${base}/${quote}`);
    rate = (await res.json()).rate;
  }

  CACHE.set(key, { rate, at: Date.now() });
  return rate;
}

Un cache de 60 secondes sur une offre gratuite à 1 000 requêtes couvre largement une petite application, parce que votre volume d'appels devient fonction du temps, pas du trafic. Marquez les réponses de repli dans vos journaux pour qu'une dégradation silencieuse vers le taux d'hier ne passe pas inaperçue pendant une semaine. Notre guide du cache et de la gestion des erreurs détaille le choix du TTL et le comportement des relances.

Une check-list de décision

Parcourez cette liste et arrêtez-vous au premier « oui » :

1. Les taux doivent-ils changer pendant la séance ? → Il vous faut une API de données de marché, pas de taux de référence.
2. Est-ce un flux réglementé ou audité ? → Figez un fournisseur nommé, stockez le taux utilisé, ne le recalculez jamais.
3. Volume d'appels élevé mais taux quotidiens suffisants ? → Auto-hébergez Frankfurter.
4. Avez-vous besoin que quelqu'un réponde en cas de panne ? → Il vous faut une offre à clé avec un niveau de support.
5. Rien de tout cela ? → Restez sur Frankfurter. Mettez en cache, gérez le trou du week-end, et occupez-vous d'autre chose.

La plupart des équipes parties chercher des alternatives à l'API Frankfurter découvrent à l'étape 5 que leur vrai problème était un cache manquant et un dimanche non géré.

Foire aux questions

L'API Frankfurter est-elle vraiment gratuite pour un usage commercial ? Oui. Le projet indique qu'elle est gratuite pour un usage commercial, sans quota mensuel ni journalier — les requêtes ne sont limitées que pour empêcher les abus. La contrepartie : pas de SLA ni de contrat de support, donc le risque est pour vous.

Frankfurter ne fournit-elle que les taux de la BCE ? Plus maintenant. L'API v2 mélange les données de 84 banques centrales sur 201 devises, et vous pouvez restreindre à une source unique avec le paramètre providers. La description répandue « BCE uniquement, 30 devises » renvoie à d'anciennes versions.

Pourquoi Frankfurter ne renvoie-t-elle rien le week-end ? Parce que les banques centrales ne publient pas de taux de référence les jours non ouvrés. Toute API bâtie sur des données de banques centrales a le même trou. Soit vous reportez le dernier taux publié, soit vous passez à une source de marché cotée en continu.

Quelle est la meilleure alternative gratuite à Frankfurter ? Cela dépend de ce que « gratuit » doit vous apporter. Pour des taux quotidiens illimités, rien ne bat Frankfurter — auto-hébergez-la. Pour une offre gratuite avec mises à jour intrajournalières et une vraie clé d'API, l'offre gratuite de Finexly donne 1 000 requêtes par mois sur plus de 170 devises. Voir notre guide des API de devises gratuites pour le panorama complet.

Puis-je utiliser Frankfurter et une API payante ensemble ? Oui, et c'est une architecture sensée. Routez le trafic normal vers votre fournisseur principal et basculez sur Frankfurter en cas d'erreur, comme dans l'exemple hybride ci-dessus. Veillez simplement à journaliser les réponses de repli, car elles portent des garanties de fraîcheur différentes.

Pour commencer

Si des taux de référence quotidiens suffisent à ce que vous construisez, restez sur Frankfurter — c'est un bon projet et il ne vous coûtera rien. Si vous avez besoin de taux qui bougent dans la journée, d'une couverture au-delà des jeux de référence des banques centrales, ou d'en-têtes d'usage réellement exploitables, obtenez votre clé d'API Finexly gratuite — sans carte bancaire. Démarrez avec 1 000 requêtes par mois sur plus de 170 devises et évoluez au fil de votre croissance, ou comparez d'abord les offres sur notre page tarifs.