Modèles ouverts : quand la souveraineté devient une décision d'architecture
Modèles ouvertsSouverainetéArchitectureCoût2024-07-029 min
Faire tourner un modèle chez soi n'est pas une position de principe. C'est un arbitrage qui se calcule, et qui se retourne selon le volume et le type de données.
Sortir du débat idéologique
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 chiffres tranchent presque toujours, 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.
Les quatre cas où l'hébergement interne s'impose
- Les données ne peuvent pas sortir. Contrainte contractuelle, secret professionnel, ou classification interne. C'est le seul cas où la décision n'est pas é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 compte plus que la qualité. Un modèle plus petit, hébergé près de l'usage, bat un modèle excellent à trois cents millisecondes de distance.
- Le comportement doit être figé. Une API met à jour son modèle quand elle veut ; un modèle hébergé ne change que si vous le décidez.
Ce que l'hébergement coûte vraiment
Le calcul qu'on me présente s'arrête en général au prix du matériel. C'est la partie facile, et de loin la plus petite.
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.
L'architecture qui évite d'avoir à choisir
La décision la plus utile que j'aie prise sur ce sujet n'est pas de choisir un camp, mais de rendre le choix réversible.
Cela suppose une seule chose : que le reste du système ne sache pas quel modèle il appelle. Une couche d'abstraction mince, un contrat d'appel stable, et un jeu de tests qui permet de comparer deux modèles sur les mêmes cas. À ce moment-là, passer d'une API à un modèle hébergé, ou l'inverse, devient une décision d'exploitation, pas une refonte.
Je considère cette réversibilité comme une exigence de base, au même titre que la journalisation.
Le piège de la démonstration locale
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 se consomme par requête concurrente, pas par modèle chargé. C'est la mesure la plus souvent oubliée, et celle qui fait exploser le budget matériel en fin de projet.
Ce que je recommande par défaut
Commencer par une API pour établir la valeur d'usage, avec la couche d'abstraction dès le premier jour. Mesurer le volume réel pendant trois mois. Puis rejouer le calcul complet, avec les chiffres constatés plutôt qu'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.
Ce que les trois années suivantes ont confirmé
L'écart de capacité entre modèles ouverts et fermés s'est refermé sur les tâches structurées et subsiste sur le raisonnement long, ce qui rend l'arbitrage plus fin qu'un choix global. La bonne configuration est devenue mixte.
Extraction, classification, reformulation, anonymisation : un modèle ouvert de taille moyenne les traite au niveau d'un modèle propriétaire, et ces tâches représentent l'essentiel du volume d'appels d'un système documentaire.
Analyse contractuelle, synthèse de dossier volumineux, raisonnement à contraintes multiples : l'écart demeure et il est substantiel.
La répartition qui en découle traite en interne tout ce qui touche aux données protégées et recourt à une API pour l'analyse complexe sur le reste. Le détail figure dans l'écart se resserre sur les tâches structurées.
Les quatre charges que la publication de poids ne couvre pas
La mémoire vidéo, la supervision, la redondance et la montée de version constituent l'essentiel du coût réel, 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 est la seule que l'on chiffre correctement. La supervision est permanente : quelqu'un doit surveiller la disponibilité et diagnostiquer les ralentissements. La redondance double le matériel si le service est critique. La montée de version revient tous les six mois.
Ces trois derniers postes dépassent souvent le premier, et le calcul complet est détaillé dans ce que télécharger des poids ne fournit pas.
L'option qui a changé la conversation
Un modèle qui tourne sur le poste de travail règle la question du transfert par construction, sans aucune infrastructure centrale à exploiter. Cette voie n'existait pas quand le débat s'est ouvert.
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 suffit désormais. Rien ne quitte la machine, donc il n'y a rien à encadrer.
Le principal obstacle n'est plus la capacité mais l'hétérogénéité du parc : un même traitement prend quelques secondes sur un poste récent et une minute sur un poste ancien. Les conditions de déploiement sont détaillées dans petits modèles sur poste.
Questions fréquentes
- Quand l'hébergement interne s'impose-t-il ?
Quand les données ne peuvent pas sortir pour une raison réglementaire ou contractuelle. C'est le seul argument qui ne se remplace ni par une clause de contrat ni par une baisse de tarif.
- Que coûte réellement un modèle hébergé ?
Le matériel, la supervision permanente, la redondance si le service est critique et la montée de version tous les six mois. Ces trois derniers postes dépassent souvent le premier.
- Faut-il choisir entre ouvert et propriétaire ?
Non. La configuration la plus économique combine les deux : un modèle ouvert pour les tâches structurées à fort volume, un modèle propriétaire pour le raisonnement complexe.
- Le poste de travail est-il une alternative crédible ?
Pour l'extraction, la classification, l'anonymisation et le résumé court, oui : rien ne quitte la machine. L'obstacle est l'hétérogénéité du parc, pas la capacité du modèle.