Modèles ouverts ou API fermées : comment choisir

Le débat « modèles ouverts contre API fermées » prend vite des allures de querelle de religion. D’un côté, ceux pour qui tout ce qui n’est pas hébergé chez soi est une fuite de données en puissance. De l’autre, ceux pour qui l’auto-hébergement est une perte de temps face à des services qui marchent d’emblée. Les deux camps ont raison sur une partie du problème, et tort de croire qu’il n’y en a qu’une.

Mieux vaut traiter la question comme n’importe quel choix d’architecture : quelques critères, des compromis, et une décision qui peut changer.

Ce que « ouvert » veut dire, et ne veut pas dire

Le mot est trompeur. La plupart des modèles dits ouverts sont en réalité des modèles à poids ouverts : on peut télécharger le fichier des paramètres et le faire tourner chez soi. Le code d’entraînement et les données utilisées ne sont pas toujours publiés, parfois pas du tout. Ce n’est donc pas toujours de l’open source au sens où on l’entend pour un logiciel.

Surtout, la licence varie beaucoup. Certains modèles sont publiés sous des licences permissives bien connues, comme Apache 2.0 ou MIT. D’autres le sont sous des licences maison, qui autorisent l’usage commercial mais l’encadrent : seuil d’utilisateurs, interdiction d’utiliser les sorties pour entraîner un autre modèle, politique d’usage acceptable à respecter. Lire la licence avant de bâtir un produit dessus est un réflexe à prendre, pas une formalité.

Les cinq critères

1. Le coût réel

Une API se paie à l’usage, généralement au volume de texte lu et produit. Le coût est proportionnel à la consommation, sans investissement de départ, et il est facile à estimer sur un prototype. Un modèle auto-hébergé se paie en matériel ou en location de GPU, en temps d’exploitation et en supervision, que vous l’utilisiez ou non.

La conséquence est connue : à faible volume ou à volume très irrégulier, l’API est presque toujours moins chère. À volume élevé et régulier, avec des machines bien remplies, l’auto-hébergement peut devenir intéressant. Le piège est de comparer le prix du jeton d’un côté et le prix du GPU de l’autre en oubliant le taux d’utilisation réel, le temps des personnes qui maintiennent le système et le coût de la panne.

2. La confidentialité

Avec une API, vos données quittent votre périmètre pour être traitées chez un tiers. Les fournisseurs sérieux proposent des engagements contractuels : pas d’entraînement sur vos données, durée de conservation limitée, hébergement dans une région donnée. C’est suffisant pour beaucoup de cas d’usage, et insuffisant pour d’autres, par exemple des données de santé ou des secrets industriels soumis à des règles strictes.

L’auto-hébergement garde tout chez vous, ce qui simplifie la conformité sur le papier. Il déplace aussi la responsabilité : c’est à vous de sécuriser l’accès, de gérer les journaux (qui contiennent les prompts) et de mettre à jour le serveur.

3. La latence et la disponibilité

Un modèle local évite un aller-retour sur Internet et ne dépend pas de la charge d’un tiers. Cela ne le rend pas rapide pour autant : un GPU modeste fait tourner un grand modèle bien plus lentement qu’une infrastructure dimensionnée pour cela. À l’inverse, une API peut avoir des pics de latence, des limites de débit et des pannes sur lesquelles vous n’avez aucune prise.

Ce qui compte, c’est la latence dont votre produit a besoin. Un traitement de nuit ou un assistant interne tolèrent beaucoup. Une complétion en cours de frappe, non.

4. La capacité

Les modèles les plus capables sur les tâches difficiles, raisonnement long, programmation complexe, consignes subtiles, sont souvent des modèles fermés. L’écart avec les modèles ouverts varie selon la tâche et il évolue vite, dans les deux sens. Pour beaucoup d’usages courants, classer, extraire, résumer, reformuler, des modèles ouverts de taille moyenne suffisent largement.

La seule manière de le savoir est de tester sur vos données. Un classement général publié quelque part ne vous dit pas comment un modèle se comporte sur vos documents, dans votre langue, avec votre vocabulaire.

5. La dépendance

Une API peut changer sans vous demander votre avis : un modèle est retiré, son comportement évolue avec une nouvelle version, les prix et les conditions bougent. Cela casse des produits qui reposaient sur un comportement précis. Un modèle ouvert téléchargé ne change plus : vous le figez, vous le testez, vous le gardez aussi longtemps que vous voulez. C’est un vrai avantage pour la reproductibilité.

Il existe aussi une dépendance de l’autre côté : à une pile logicielle d’inférence, à un type de matériel, à une compétence rare dans l’équipe.

Une méthode qui évite de s’enfermer

La décision se prend moins souvent sur un principe que sur une série de petites questions. En voici une version courte.

• Les données traitées peuvent-elles légalement et contractuellement sortir de chez vous ?
• Quel volume mensuel, et de quelle régularité, à un an ?
• Quelle latence maximale votre produit tolère-t-il ?
• Un modèle de taille moyenne réussit-il votre tâche sur un échantillon réel ?
• Qui exploiterait le système auto-hébergé, et que se passe-t-il quand cette personne est absente ?

Dans la pratique, la stratégie la plus robuste est presque toujours la même : cacher le fournisseur derrière une interface. Votre code appelle une fonction « générer », « classer » ou « calculer un embedding », et un seul endroit décide quel modèle répond. Changer de fournisseur, ou en faire cohabiter deux, devient alors une affaire de configuration plutôt qu’une réécriture.

Choisir un modèle est une décision réversible, à condition de l’avoir rendue réversible.

Les approches hybrides

Rien n’oblige à choisir un camp pour tout. Une organisation raisonnable peut envoyer les données non sensibles à une API pour les tâches difficiles, garder en local les documents confidentiels avec un modèle plus petit, et utiliser un modèle d’embeddings local pour l’indexation. Un routage selon la sensibilité des données ou la difficulté de la tâche fait souvent mieux qu’un choix unique.

Par où commencer

Pour un nouveau projet, prototyper avec une API est presque toujours le chemin le plus court : vous apprenez ce que votre produit demande vraiment au modèle avant d’investir dans de l’infrastructure. Une fois la tâche comprise, rejouez vos tests avec un ou deux modèles ouverts et regardez l’écart. S’il est acceptable, et si vos contraintes de volume ou de confidentialité le justifient, la migration est un projet précis plutôt qu’un pari.

Et dans tous les cas, gardez un petit jeu d’exemples réels pour comparer. C’est la seule chose qui rende la discussion concrète.