Modèles ouverts : quand la souveraineté devient une décision d’architecture

Un modèle à poids ouverts publie des paramètres exécutables sur une infrastructure choisie, mais sa licence et les composants disponibles déterminent les usages réellement autorisés et possibles. Il faut distinguer cette disponibilité d’une ouverture complète du code, des données et de la chaîne d’entraînement.

Concrètement, une organisation peut appeler un modèle propriétaire par une API, chez un fournisseur, ou télécharger un modèle ouvert et le faire tourner sur ses serveurs, dans un nuage privé ou sur un poste de travail. La licence fixe ce qu’on a le droit d’en faire, point qui pèse autant que la qualité du modèle, comme le montre Llama 2 : la licence compte autant que le modèle.

La question des modèles ouverts est souvent posée en termes de souveraineté, avec la charge symbolique que cela suppose. En cadrage, je la ramène systématiquement à trois chiffres : le volume de requêtes, la sensibilité des données, et le coût complet d’exploitation.

Ces trois grandeurs éclairent l’arbitrage, et ils ne donnent pas la même réponse d’une organisation à l’autre : ni d’un cas d’usage à l’autre dans la même organisation.

L’hébergement interne mérite une évaluation lorsque les contraintes de données, le volume, la latence ou le contrôle des versions justifient les charges supplémentaires de service et de maintenance.

• Les données ne peuvent pas sortir. Contrainte contractuelle, secret professionnel, ou classification interne. Cette contrainte peut exclure une option avant même le calcul économique.
• Le volume est élevé et stable. À partir d’un certain débit continu, le coût par requête d’une API dépasse celui d’une machine amortie.
• La latence est contraignante. Un hébergement proche de l’usage peut réduire le transport réseau ; le délai total dépend aussi du calcul et de la file d’attente.
• Le comportement doit être contrôlé. Vérifier les versions proposées par l’API ; un modèle hébergé reste stable seulement si poids, logiciel et paramètres sont maîtrisés.

Le choix entre une API et un modèle ouvert hébergé se décide sur quatre critères mesurables : sensibilité des données, volume et régularité des appels, exigence de latence et besoin de stabilité du comportement. Aucun de ces critères n’est idéologique.

Le dernier critère est souvent sous-estimé. Un fournisseur d’API peut modifier le modèle derrière un même nom, et ce changement silencieux se paie en régressions difficiles à diagnostiquer, comme le raconte le jour où le modèle a changé sans prévenir.

L’hébergement d’un modèle ouvert coûte bien plus que le matériel : il faut ajouter l’exploitation, la redondance et le temps de relecture humaine qu’impose l’écart de qualité. Le prix des machines est une ligne visible, dont le poids relatif dépend du service.

Le calcul qu’on me présente s’arrête en général au prix du matériel. Il faut y ajouter l’exploitation : quelqu’un qui surveille, qui met à jour, qui gère les incidents, qui refait la mesure quand on change de version. Il faut ajouter la redondance, parce qu’une machine unique n’est pas une production. Et il faut ajouter le coût de l’écart de qualité : si le modèle interne exige deux fois plus de relecture humaine, ce temps de relecture est une ligne du calcul.

Quand ce calcul complet est fait honnêtement, l’hébergement interne reste souvent pertinent, mais pour des raisons différentes de celles avancées au départ.

La mémoire vidéo, la supervision, la redondance et la montée de version constituent l’essentiel du coût réel d’un modèle ouvert, et aucune n’apparaît dans la comparaison de tarifs qui motive la décision. C’est l’écart le plus fréquent entre le dossier et la réalité.

La mémoire doit être chiffrée avec les autres postes, sans réduire l’hébergement à l’achat du matériel. La supervision est permanente : quelqu’un doit surveiller la disponibilité et diagnostiquer les ralentissements. La redondance dépend du niveau de service demandé. Les montées de version se planifient selon les besoins, les correctifs et les tests, sans périodicité universelle.

Ces trois derniers postes dépassent souvent le premier. Publier des poids ne garantit d’ailleurs pas une chaîne de service, d’évaluation et d’exploitation prête pour votre usage, ce que montrait déjà Grok : des poids publiés ne sont pas des poids exploitables. Lecture complémentaire sur les charges d’hébergement : ce que télécharger des poids ne fournit pas.

Une démonstration locale ne valide pas la production parce que les requêtes simultanées, la longueur des contextes et le niveau de disponibilité changent les besoins en mémoire et en calcul.

Un modèle qui tourne bien sur un poste de développement ne dit rien de son comportement à trente utilisateurs simultanés. La mémoire vidéo sert aux poids chargés et aux traitements concurrents, notamment aux caches de contexte ; les deux doivent être dimensionnés. C’est la mesure la plus souvent oubliée, et celle qui fait exploser le budget matériel en fin de projet.

Le choix entre modèle ouvert et modèle propriétaire devient réversible dès que le reste du système ignore quel modèle il appelle, grâce à une couche d’abstraction mince, un contrat d’appel stable et un jeu de tests comparatif. C’est la décision la plus utile que j’aie prise sur ce sujet.

Elle ne consiste pas à choisir un camp. À partir du moment où l’abstraction existe, passer d’une API à un modèle hébergé, ou l’inverse, devient une décision d’exploitation, pas une refonte. C’est la logique que décrivait Amazon Bedrock, la couche qui rend le modèle remplaçable.

La mise en place suit quatre étapes :

1. Définir un contrat d’appel unique : entrée, sortie attendue, paramètres, gestion des erreurs.
2. Isoler les prompts et leurs variantes par modèle, plutôt que de les disperser dans le code.
3. Constituer un jeu de tests de cas réels avec la réponse attendue, pour comparer deux modèles sur les mêmes entrées.
4. Journaliser le modèle et la version utilisés pour chaque appel, afin de pouvoir expliquer toute variation.

Je considère cette réversibilité comme une exigence de base, au même titre que la journalisation.

Un modèle à poids ouverts peut convenir à des tâches structurées telles que l’extraction ou la classification, mais la comparaison avec une API doit porter sur vos cas réels. Je n’en déduis pas une équivalence générale.

Le résultat dépend de la langue, des documents, du format attendu et du niveau de vérification. Les annonces de Mistral 7B et de Llama 3 offrent des candidats à tester, pas une preuve de réussite sur un dossier interne.

Je compare les erreurs critiques, la stabilité du format et le temps de relecture, avec le même protocole. Si une solution mixte est retenue, le routage doit respecter les droits d’accès et le contrat de transfert, avant d’optimiser le coût.

Un modèle qui tourne sur le poste de travail règle la question du transfert de données par construction, sans aucune infrastructure centrale à exploiter. Cette voie s’ouvre avec la montée en qualité des petits modèles.

Pour l’extraction, la classification, l’anonymisation et le résumé court, soit l’essentiel des besoins portant sur des données sensibles, un modèle de poste peut suffire. Le traitement ne nécessite pas de transfert au fournisseur si le fonctionnement hors ligne est effectivement vérifié ; stockage, permissions, télémétrie et mises à jour restent à encadrer.

Capacité, mémoire et hétérogénéité du parc se testent sur des machines représentatives. Lecture complémentaire : petits modèles sur poste.

L’erreur la plus fréquente consiste à choisir un modèle ouvert sur un argument de souveraineté sans avoir chiffré l’exploitation ni vérifié que les données ne peuvent réellement pas sortir. Les autres erreurs relèvent du même défaut de mesure.

• Comparer un tarif d’API au prix d’un serveur, sans compter supervision, redondance et montées de version.
• Dimensionner sur une démonstration à un utilisateur, puis découvrir la consommation de mémoire en charge.
• Lire la licence trop tard, alors qu’elle peut restreindre l’usage commercial ou la redistribution.
• Choisir un modèle unique pour toutes les tâches, au lieu de répartir entre tâches structurées et raisonnement complexe.
• Coder en dur l’appel au modèle, ce qui rend tout changement ultérieur coûteux.

Un audit IA de l’existant permet de poser ces chiffres avant d’engager un investissement matériel.

Par défaut, je recommande de commencer par une API pour établir la valeur d’usage, avec la couche d’abstraction dès le premier jour, puis de rejouer le calcul complet après trois mois de mesure réelle. Les chiffres constatés remplacent alors les chiffres estimés.

Cette séquence évite deux erreurs symétriques : investir dans du matériel pour un usage qui ne décollera pas, et rester sur une facturation à l’usage qui devient déraisonnable quand elle décolle.

Si les données ne peuvent pas sortir dès le départ, la séquence s’inverse : on commence par un modèle ouvert hébergé ou un modèle de poste, en acceptant un périmètre de tâches plus étroit, et en vérifiant ce qu’on a le droit d’envoyer avec ce qu’on a le droit de mettre dans un prompt.