« Est-ce qu'on part sur un modèle open source ou sur un gros fournisseur ? » C'est une des premières questions qu'on me pose, et la plupart du temps elle arrive avec un tableau comparatif : le prix au million de jetons, le classement du mois, la taille de la fenêtre de contexte.
Je vais être franc : ce tableau ne vaut pas grand-chose. Pas parce qu'il est faux, mais parce qu'il sera périmé avant que votre projet soit en production. Les prix baissent, les classements changent de tête tous les deux mois, et le modèle que vous aurez choisi sur ces critères ne sera plus le bon au moment de la mise en service. Choisir là-dessus, c'est choisir sur une photo d'un truc qui bouge.
Le seul critère qui ne bougera pas
La question qui tient dans le temps est beaucoup plus ennuyeuse, et c'est pour ça qu'elle est rarement posée : le jour où votre fournisseur double son tarif, ferme l'API que vous utilisez, ou change ses conditions d'usage. Qu'est-ce que vous faites ?
Si la réponse est « on change de modèle en une journée », le débat ouvert / fermé est secondaire, prenez le meilleur du moment. Si la réponse est « on refait le projet », alors vous n'avez pas choisi un modèle : vous avez choisi un propriétaire. Et ça, ça ne se voit pas dans le tableau comparatif.
Ce qui vous rend réversible
La bonne nouvelle, c'est que la réversibilité ne se décide pas au moment de choisir le modèle. Elle se décide dans la façon dont vous branchez votre code dessus. Trois choses suffisent, et aucune n'est du travail perdu :
- — Un seul endroit dans le code qui parle au modèle. Pas quinze appels dispersés dans l'application : une couche, une interface, et tout le reste passe par elle. Changer de fournisseur devient un fichier à réécrire au lieu d'une chasse au trésor.
- — Vos données et vos prompts chez vous, pas chez lui. Si l'historique de vos conversations, vos exemples et vos réglages ne vivent que dans la console du fournisseur, vous ne partirez jamais. Pas par attachement : par impossibilité pratique.
- — Un jeu de cas de test qui dit si un modèle fait l'affaire. Une trentaine d'exemples réels, avec la réponse attendue. C'est ce qui transforme « on pourrait essayer un autre modèle » en une décision d'une demi-journée au lieu d'un mois d'hésitation.
Un projet qui a ces trois choses peut changer de modèle. Un projet qui ne les a pas est marié, quel que soit le modèle qu'il a choisi au départ, y compris un modèle ouvert.
Ce qu'« ouvert » veut vraiment dire pour vous
Un modèle ouvert n'est pas magiquement moins cher. Vous ne payez plus au jeton, vous payez une machine, quelqu'un pour la surveiller, et les mises à jour. Pour beaucoup de TPE et PME, ça revient plus cher, pas moins. Et ça se découvre après.
Ce qu'un modèle ouvert vous donne vraiment, c'est la garantie qu'on ne peut pas vous le retirer, et la possibilité de le faire tourner là où vos données doivent rester. Si votre métier vous interdit d'envoyer certains documents à l'extérieur, ce n'est plus une préférence, c'est le sujet, et la comparaison de prix devient hors sujet. Si vous n'avez pas cette contrainte, l'argument perd beaucoup de sa force.
Ce que je recommande en pratique
Sans connaître votre contexte, je ne vais pas vous dire quel modèle prendre : ce serait vendre une réponse à une question que je n'ai pas entendue. En revanche, l'ordre dans lequel se poser les questions ne change pas :
- — Est-ce que des données ne peuvent pas sortir de chez vous ? Si oui, la question est tranchée, et tout le reste en découle.
- — Est-ce que le code est découplé du fournisseur ? Si non, réglez ça d'abord : c'est ce qui rendra le mauvais choix rattrapable.
- — Sinon : prenez le modèle le plus simple à mettre en service aujourd'hui, et gardez de quoi en changer demain.
Pour finir
La plupart des gens qui se torturent sur ce choix se trompent de risque. Le risque n'est pas de prendre le mauvais modèle. Ça arrive, ça se corrige. Le risque est de construire quelque chose qui rend la correction impossible.
Alors quand on me demande « ouvert ou fermé ? », la réponse honnête, c'est p't-être ben qu'oui, p't-être ben qu'non. Et surtout : arrangez-vous pour que ça ne soit pas définitif.