- ▸ Un dépôt GitHub publié le 4 juin 2025 pour mettre fin à une opacité tenace
- ▸ La thèse : la documentation des modèles devient un bien public
- ▸ Contexte historique : comment l'industrie est-elle arrivée à un tel niveau d'opacité ?
- ▸ Analyse technique : ce que contient Models.dev, comment c'est organisé, comment on l'utilise
Pas de référentiel unifié pour comparer GPT, Claude, Gemini, Mistral ou DeepSeek sur un pied d’égalité. Le projet Models.dev, hébergé sur GitHub depuis le 4 juin 2025 par le collectif anomalyco, ambitionne de combler ce vide documentaire en proposant une base de données open-source dédiée aux spécifications, tarifs et capacités des grands modèles d’intelligence artificielle. Trois questions structurent ce dossier : comment fonctionne le projet, qui en a besoin, et pourquoi son existence en dit long sur l’opacité du marché.
Points clés 1. Models.dev est une base de données open-source qui recense les spécifications, tarifs et capacités des modèles d’IA, accessible depuis le dépôt GitHub anomalyco/models.dev publié le 4 juin 2025. 2. La donnée est exposée via une API REST publique, ce qui permet à n’importe quel SDK ou outil tiers d’interroger la base sans authentification dédiée. 3. L’identifiant utilisé pour interroger un modèle est l’ID employé par les SDK IA officiels, ce qui garantit la compatibilité directe avec les intégrations existantes. 4. Les logos des fournisseurs sont distribués au format SVG via HTTP, ce qui simplifie leur réutilisation dans des interfaces, comparateurs ou tableaux de bord. 5. Le stockage repose sur des fichiers .toml organisés par fournisseur et par modèle dans le dépôt GitHub, ce qui rend chaque contribution lisible, traçable et révisable.
Un dépôt GitHub publié le 4 juin 2025 pour mettre fin à une opacité tenace
Le 4 juin 2025, le compte GitHub anomalyco met en ligne le dépôt models.dev. La page d’accueil pose le diagnostic sans détour : il n’existe pas de base de données unique recensant les informations sur l’ensemble des modèles d’IA disponibles sur le marché. Le projet se présente comme une réponse communautaire, contributive, à ce manque.
L’amorce paraît modeste : un dépôt de fichiers texte structurés, une API REST, des logos vectoriels. Pourtant la portée du projet dépasse la simple curiosité technique. À l’heure où chaque fournisseur — OpenAI, Anthropic, Google, Mistral, Meta, DeepSeek — publie ses propres fiches techniques dans des formats hétérogènes, l’absence de référentiel commun complique les comparaisons, les audits de coût et les décisions d’architecture. Models.dev arrive sur ce terrain non balisé avec une promesse simple : tout au même endroit, tout vérifiable, tout modifiable par pull request.
La thèse : la documentation des modèles devient un bien public
L’hypothèse implicite du projet est que la documentation des modèles d’IA relève désormais du bien commun. Lorsque les contrats d’usage se chiffrent en millions de tokens par mois et que les écarts de tarifs entre deux modèles concurrents peuvent atteindre un ordre de grandeur, la lisibilité du marché devient une condition d’efficacité. Models.dev se positionne comme la couche d’information manquante entre les pages produit des laboratoires et les intégrations SDK des développeurs.
Contexte historique : comment l’industrie est-elle arrivée à un tel niveau d’opacité ?
Pour comprendre la pertinence de Models.dev, il faut revenir sur la trajectoire documentaire du marché. Au début des années 2020, l’industrie de l’IA générative compte encore peu d’acteurs : OpenAI publie une page tarifaire unique, Anthropic démarre en accès limité, Google maintient ses modèles internes. Les fiches techniques tiennent en quelques lignes. Comparer deux modèles signifie ouvrir deux onglets.
Avec l’explosion de l’offre à partir de 2023, la situation change radicalement. Chaque fournisseur multiplie les variantes — modèle de base, modèle instruct, modèle code, modèle vision, modèle long contexte, modèle économique, modèle premium. Les noms de modèles deviennent eux-mêmes des labyrinthes : gpt-4o-2024-08-06, claude-3-5-sonnet-20241022, gemini-1.5-pro-002. Chaque chaîne encode une date de release, une famille, une version mineure, parfois une longueur de contexte.
Parallèlement, les fournisseurs ajoutent des dimensions de différenciation que la documentation publique n’absorbe pas toujours : date de cutoff de connaissances, date de première publication, modalités d’entrée et de sortie supportées, fenêtre de contexte effective, longueur maximale de génération, support du streaming, support des outils, support du JSON structuré, support du caching de prompt, support de la vision, support de l’audio. Le résultat tient en une formule : pour chaque modèle, une vingtaine d’attributs potentiellement utiles à comparer, dispersés sur cinq à dix pages web différentes par fournisseur.
Plusieurs initiatives parallèles ont tenté d’y répondre. Les agrégateurs commerciaux — OpenRouter, Together AI, Replicate — proposent des comparatifs intégrés à leur offre, mais ces vues servent d’abord leur catalogue commercial. Les leaderboards académiques — Chatbot Arena, MMLU, HumanEval — mesurent la performance mais ignorent les tarifs. Les pages de pricing des fournisseurs détaillent les prix mais omettent les capacités. La documentation des SDK officiels expose les identifiants techniques mais peu de méta-données.
Dans ce paysage fragmenté, l’idée d’une base unique, neutre, contributive, n’a longtemps eu aucune incarnation crédible. Le dépôt anomalyco/models.dev, publié sous gouvernance ouverte sur GitHub, se présente comme la première brique structurée d’un tel référentiel — du moins sous une forme dédiée et auditable.
Analyse technique : ce que contient Models.dev, comment c’est organisé, comment on l’utilise
L’architecture du projet repose sur une décision structurante : stocker la donnée sous forme de fichiers .toml versionnés, organisés par fournisseur et par modèle. Comme l’indique la documentation du dépôt anomalyco/models.dev : « La data est stockée dans le dépôt en tant que fichiers .toml organisés par fournisseur et modèle. Les logos sont stockés en tant qu’image SVG. » Ce choix tranche avec les bases de données relationnelles classiques. Il s’aligne sur la culture des projets infra-as-code : chaque modification passe par une pull request, chaque ligne est imputable à un contributeur, chaque divergence est tracée dans l’historique git.
Le schéma des fichiers .toml
Chaque fichier de modèle expose un ensemble de champs standardisés. Les citations issues du dépôt en révèlent la structure :
release_date: la date de première publication publique du modèle.last_updated: la date de dernière mise à jour ou knowledge-cutoff selon le cas.input: la liste des modalités d’entrée supportées (texte, image, audio, vidéo, etc.).output: la liste des modalités de sortie supportées.[interleaved]: la section décrivant le support de modalités entrelacées et le champ associé.npm: le nom du package SDK officiel ou, à défaut, un lien vers la documentation du fournisseur lorsque l’endpoint est compatible OpenAI.env: la liste des variables d’environnement utilisées pour l’authentification.api: le mode d’API utilisé, par exemple « # Use OpenAI-compatible SDK ».
Cette grille évite l’écueil classique des comparateurs : chaque champ a un sens fixe, documenté, et chaque contributeur sait exactement où ajouter une information.
L’API REST et l’usage en lecture
La donnée est exposée via une API REST publique. Selon la documentation du dépôt, « la data peut être récupérée via une API REST » et « l’ID du modèle » sert d’identifiant de lookup : « c’est l’identifiant utilisé par les SDK IA ». Concrètement, cela signifie qu’un développeur intégrant déjà claude-sonnet-4-6 ou gpt-4o-2024-08-06 dans son code peut interroger Models.dev avec exactement la même chaîne, sans translation, sans table de correspondance.
Les logos suivent la même logique. « Les logos des fournisseurs sont disponibles sous forme de fichiers SVG et peuvent être récupérés via une requête HTTP. » Le format vectoriel garantit que tout comparateur, tableau de bord ou outil d’observabilité peut intégrer la charte visuelle d’un fournisseur sans dégradation à l’affichage, qu’il s’agisse d’un favicon de 16 pixels ou d’une bannière de 4K. La référence W3C http://www.w3.org/2000/svg apparaît d’ailleurs explicitement dans les fichiers, confirmant l’usage du standard officiel.
Tableau comparatif des dimensions documentées par Models.dev
| Catégorie | Champs typiques | Type d’usage |
|---|---|---|
| Identité | id du modèle, fournisseur, famille | Lookup direct depuis un SDK |
| Temporalité | release_date, last_updated, knowledge-cutoff | Audit de fraîcheur des données d’entraînement |
| Modalités | input, output, interleaved | Vérification de compatibilité multimodale |
| Intégration | npm (package SDK), api (compatibilité OpenAI) | Configuration d’un client |
| Authentification | env (variables d’environnement) | Mise en place du secret management |
| Branding | logo SVG via HTTP | Affichage dans un comparateur ou un dashboard |
Ce schéma minimaliste a une vertu : il accepte aussi bien un modèle hyperscaler que la production locale d’un laboratoire académique. Comme le précise la documentation : « Si le fournisseur ne publie pas de package npm mais expose un endpoint compatible OpenAI, configurez le champ npm en conséquence et incluez l’URL de base. »
Le chiffre-phare : une douzaine de champs structurés par modèle
Sur la base des fragments de schéma publiés dans le dépôt, on dénombre au moins une douzaine de champs structurés par modèle, sans compter les sous-sections optionnelles comme [interleaved]. C’est l’ordre de grandeur qui sépare une page de marketing produit — trois à cinq attributs en moyenne — d’un référentiel technique exploitable par un agent automatisé ou un système d’observabilité.
Impact terrain : qui utilise Models.dev et pour quoi faire ?
L’usage concret de Models.dev s’organise autour de quatre profils de besoins.
Les équipes de plateforme interne
Dans les directions techniques qui exposent un proxy LLM unifié à plusieurs équipes produit, la question récurrente est : quel modèle router vers quelle requête, à quel coût, avec quelle latence cible ? Models.dev fournit une couche de métadonnées que ces équipes intégraient jusqu’ici manuellement, en parcourant les pages de tarification des fournisseurs et en maintenant un YAML interne souvent obsolète. Avec une API REST publique et des fichiers .toml versionnés, la mise à jour devient un simple git pull automatisé ou un appel API périodique.
Les comparateurs et marketplaces
Les agrégateurs commerciaux — OpenRouter, Together, ou les marketplaces internes d’éditeurs SaaS — ont un besoin similaire mais sous un angle B2B : afficher au client final un comparatif lisible des modèles disponibles. La distribution des logos SVG via HTTP est ici un détail à forte valeur. Au lieu de maintenir un dossier assets/ à jour modèle par modèle, le comparateur récupère la version canonique du logo à chaque rafraîchissement.
Les chercheurs et analystes du marché
Les laboratoires académiques et les cabinets d’analyse — IDC, Gartner, McKinsey — produisent régulièrement des panoramas comparatifs des modèles. Sans référentiel commun, ces panoramas reposent sur des collectes manuelles, souvent décalées de quelques mois par rapport à la réalité du marché. Un dépôt versionné permet de citer la donnée à une date précise — par commit hash — et de reproduire l’analyse plus tard avec exactement les mêmes valeurs.
Les agents IA eux-mêmes
L’usage le plus prospectif concerne les agents autonomes qui doivent sélectionner dynamiquement un modèle en fonction du contexte de la requête. Pour qu’un agent puisse arbitrer entre gpt-4o-mini, claude-haiku-4-5 et gemini-1.5-flash sur une base de coût, de fenêtre de contexte ou de modalité supportée, il lui faut une source structurée et fiable. Models.dev fournit précisément cela : un endpoint REST, un ID standardisé, des champs typés.
Citation d’expert
Sur l’orientation du projet, un mainteneur du dépôt anomalyco/models.dev explique dans la documentation officielle : « Pas de base de données unique avec des informations sur tous les modèles IA disponibles. Nous avons créé Models.dev en tant que projet communautaire-contribué pour répondre à ce besoin. » La formulation est sobre, mais elle pose la question politique sous-jacente : si la documentation centralisée du marché de l’IA est une infrastructure critique, faut-il la confier à un acteur commercial ou la maintenir comme un communs numérique ?
Perspectives contradictoires : les limites et les critiques recevables
Plusieurs réserves méritent d’être posées avec rigueur.
La fiabilité dépend des contributeurs
Tout projet contributif souffre du même risque : la qualité des données dépend de la diligence des contributeurs. Pour les modèles très populaires — GPT, Claude, Gemini — la pression communautaire garantit un suivi serré. Pour les modèles plus marginaux, les fiches risquent de prendre du retard sur les annonces des fournisseurs. Sans audit éditorial central, deux fiches concurrentes peuvent diverger sur des points de détail. Les défenseurs du projet répondent que git fournit déjà la traçabilité nécessaire pour identifier et corriger ces écarts, mais la question de la confiance reste ouverte.
L’absence de benchmarks intégrés
Models.dev documente les spécifications et tarifs, mais pas la performance mesurée. Un développeur cherchant à arbitrer entre deux modèles sur un benchmark précis — MMLU, HumanEval, ARC, GSM8K — devra croiser Models.dev avec une source tierce comme Chatbot Arena ou les leaderboards de Hugging Face. Cette séparation est volontaire — les benchmarks soulèvent des débats méthodologiques que Models.dev n’a pas vocation à arbitrer — mais elle limite l’usage du référentiel pour les décisions techniques qui dépendent de la qualité mesurée.
Le risque de capture par un acteur
Tout projet open-source à forte adoption finit par poser la question de la gouvernance. Si Models.dev devient l’infrastructure de référence pour la documentation des modèles, il devient aussi une cible : pour un rachat, pour un fork hostile, pour une influence éditoriale. La gouvernance contributive du dépôt, à ce stade, n’expose pas publiquement de mécanisme de décision formalisé. C’est un point que la communauté devra clarifier si l’adoption décolle.
Les limites du format .toml
Le choix du TOML offre une grande lisibilité humaine, mais ce format reste moins riche qu’un schéma JSON Schema ou Avro. Pour des cas d’usage qui demanderaient une validation stricte ou une introspection automatique, les développeurs devront ajouter une couche de validation tierce. Là encore, ce n’est pas un défaut bloquant — mais c’est une dette technique latente.
Prospective : ce que Models.dev annonce pour la suite
Trois pistes méritent d’être suivies à horizon T1 2027.
D’abord, l’extension du périmètre. Models.dev pourrait progressivement intégrer des dimensions absentes du schéma actuel : empreinte carbone par requête, latence médiane mesurée, support des fonctionnalités avancées comme le caching de prompt ou les outils typés. Chacun de ces ajouts impliquerait une discussion communautaire sur la méthodologie de mesure et sur la légitimité des chiffres reportés.
Ensuite, l’intégration native dans les SDK officiels. Si OpenAI, Anthropic ou Google publiaient un connecteur officiel pointant vers Models.dev — ou contribuaient directement aux fiches de leurs propres modèles — le projet basculerait du statut de référentiel communautaire à celui de standard de facto. Cette évolution dépend de la maturité éditoriale du dépôt et de la confiance que les fournisseurs accorderont à son comité de mainteneurs.
Enfin, le ricochet sur les comparateurs commerciaux. Plusieurs agrégateurs payants vivent aujourd’hui de la valeur de leur référentiel propre. Si Models.dev devient suffisamment exhaustif et à jour, ces acteurs devront soit s’appuyer dessus, soit justifier leur valeur ajoutée par d’autres moyens — courtage, billing unifié, observabilité, garanties SLA. La pression sur leur modèle économique pourrait se faire sentir d’ici fin 2026.
FAQ
Quelle est la finalité de Models.dev ?
Models.dev vise à offrir une base de données open-source exhaustive pour les spécifications, tarifs et capacités des modèles d’IA. Le projet a été créé pour combler le manque de données unifiées disponibles sur tous les modèles, selon la documentation du dépôt anomalyco/models.dev publié le 4 juin 2025 sur GitHub.
Comment puis-je contribuer à la mise à jour des données dans Models.dev ?
Vous pouvez aider à maintenir les données de Models.dev à jour en ajoutant de nouveaux modèles ou en corrigeant les informations existantes. Pour ajouter un nouveau modèle, commencez par vérifier si le fournisseur existe déjà dans le répertoire providers. Si ce n’est pas le cas, créez-en un et ajoutez les détails du modèle dans un fichier .toml dédié.
Comment récupérer la donnée de Models.dev dans une application ?
La donnée est exposée via une API REST. L’identifiant utilisé pour interroger un modèle est l’ID employé par les SDK officiels, ce qui simplifie l’intégration depuis un code qui consomme déjà ces SDK. Les logos des fournisseurs sont distribués au format SVG et accessibles via une simple requête HTTP, sans authentification.
Models.dev couvre-t-il les benchmarks de performance ?
Non, à ce jour. Models.dev documente les spécifications statiques (modalités, dates, tarifs, intégration SDK) mais pas les performances mesurées sur des benchmarks comme MMLU, HumanEval ou ARC. Pour ces dimensions, il convient de croiser le référentiel avec des sources spécialisées comme les leaderboards académiques ou les comparatifs publiés par les laboratoires.
À retenir
- Le dépôt anomalyco/models.dev a été publié sur GitHub le 4 juin 2025 sous gouvernance contributive.
- Une douzaine de champs structurés sont documentés par modèle, dont
release_date,last_updated,input,output,npm,envetapi. - L’API REST publique et la distribution SVG des logos rendent le référentiel directement consommable par les SDK, comparateurs et agents.
À suivre
- D’ici fin 2026, l’éventuelle adoption du référentiel par les éditeurs de comparateurs commerciaux comme signal de standardisation.
- Au T1 2027, la consolidation potentielle d’une gouvernance formalisée et l’arrivée de contributions officielles depuis les fournisseurs majeurs.
- À horizon 2027, l’extension du schéma à des dimensions comme l’empreinte carbone, la latence médiane mesurée ou le support du caching avancé.
Sources
- GitHub — anomalyco/models.dev, An open-source database of AI models, dépôt publié le 4 juin 2025. URL : https://github.com/anomalyco/models.dev
Pour aller plus loin sur les sujets connexes : Anthropic et la course aux 1M de tokens, OpenAI face à la guerre des prix par token, Mistral et la stratégie open-weight européenne, Comparer les modèles d’IA en 2026 : méthode et pièges, Gouvernance des projets open-source en IA.
