Deux façons d'utiliser un modèle
Quand une application métier intègre un modèle de langage, il faut décider où ce modèle s'exécute :
- dans le cloud, via l'API d'un fournisseur (Anthropic, Mistral, OpenAI…) : votre application envoie une requête, le fournisseur renvoie la réponse ;
- en local, sur un serveur que vous contrôlez (dans vos locaux ou chez votre hébergeur), avec un modèle à poids ouverts que vous téléchargez et faites tourner vous-même.
Ce n'est pas une question de mode, ni de principe. Les deux approches ont des forces très différentes, et le bon choix dépend de votre cas.
L'IA dans le cloud
C'est la voie la plus rapide pour démarrer.
- La qualité. Les modèles les plus performants, notamment pour le raisonnement, la rédaction et les consignes complexes, ne sont disponibles que par API.
- Rien à héberger. Pas de serveur à dimensionner, pas de mise à jour du modèle à gérer : on paie à l'usage.
- Des options de confidentialité. Les offres professionnelles permettent en général d'exclure vos données de l'entraînement et, chez certains fournisseurs, de choisir une région d'hébergement européenne. Il faut lire les conditions de près, et les relire quand elles changent.
Les points de vigilance : vos données transitent par un tiers, et la facture suit le volume. Une fonctionnalité très utilisée peut coûter cher si elle n'a pas été pensée pour limiter la quantité de texte envoyée.
L'IA locale
Des outils comme Ollama ont rendu l'installation d'un modèle sur un serveur beaucoup plus simple, et des éditeurs, dont le français Mistral, publient des modèles à poids ouverts de bonne qualité.
- Les données restent chez vous. C'est souvent l'argument décisif pour des documents sensibles : santé, juridique, données personnelles, secrets industriels.
- Un coût prévisible. Une fois le serveur en place, on ne paie plus à la requête.
- Très bien pour les tâches ciblées. Classer, extraire des champs, résumer, reformuler : les modèles qu'on peut faire tourner sur place s'en sortent souvent très bien.
En contrepartie, il faut une machine adaptée (en pratique, avec une carte graphique), quelqu'un pour la maintenir, et accepter une qualité en retrait sur les tâches les plus exigeantes.
Une grille de décision
| Critère | Plutôt cloud | Plutôt local |
|---|---|---|
| Sensibilité des données | Faible ou modérée | Forte, ou contrainte contractuelle |
| Complexité de la tâche | Raisonnement, rédaction libre | Tâche ciblée et répétitive |
| Volume de requêtes | Faible à moyen, ou irrégulier | Élevé et régulier |
| Délai de mise en route | Court | Plus long (serveur à préparer) |
| Compétences en interne | Aucune exigée | Quelqu'un pour maintenir le serveur |
Si vos réponses tombent toutes dans la même colonne, le choix est vite fait. Sinon, l'approche hybride mérite d'être regardée.
Les approches hybrides
Rien n'oblige à tout mettre au même endroit. Quelques combinaisons courantes :
- Tri en local, cas difficiles dans le cloud. Un modèle local traite la majorité des demandes simples ; seules celles qu'il ne sait pas traiter partent vers un modèle plus puissant.
- Anonymiser avant d'envoyer. Les noms, adresses et numéros sont remplacés localement avant l'appel au modèle distant, puis restitués dans la réponse.
- Index local, génération distante. Pour un assistant documentaire, seuls les quelques passages utiles à une question quittent vos serveurs. C'est le cas que je décris dans l'article sur la documentation interne.
Comment je tranche avec mes clients
Plutôt que de comparer des classements génériques, je prends un échantillon de vos vrais cas (une trentaine de documents ou de demandes, avec la réponse attendue) et je fais passer le même test à plusieurs modèles, locaux et distants. On compare alors trois choses concrètes : la qualité des réponses, le coût mensuel estimé à votre volume, et les contraintes d'hébergement.
C'est rarement long, et ça évite de découvrir après coup qu'un modèle local ne suffit pas, ou qu'un modèle cloud était surdimensionné pour la tâche.