« IA souveraine » est en train de devenir un argument commercial qu'on colle sur tout et n'importe quoi. Alors posons le sujet autrement : depuis plusieurs mois, trois de nos applications de production (l'assistant de notre CRM, un back-office associatif et un outil de qualification de prospects) fonctionnent sur un modèle de langage que nous hébergeons nous-mêmes, sur notre propre machine. Pas une démo, pas un POC : de la production, avec ses pannes possibles et ses pièges découverts. Voici ce que ça donne réellement.
Pourquoi s'infliger ça ?
- Les données, d'abord. Un assistant de CRM voit passer votre fichier clients ; un outil de qualification lit des offres et des réponses commerciales. Envoyer ça à une API américaine pose les questions de sous-traitance et de transfert qu'on a détaillées à propos du Cloud Act. En local : rien ne sort, la question disparaît.
- Le coût prévisible. Une API facture au jeton, et un assistant bavard branché sur un CRM consomme vite. Une machine amortie coûte pareil qu'elle traite dix ou dix mille requêtes.
- L'indépendance. Pas de modèle déprécié du jour au lendemain, pas de conditions qui changent, pas de quota surprise. Le modèle que nous avons validé est celui qui tourne, point.
Et l'honnêteté impose le contrepoint : un modèle open-weights d'une trentaine de milliards de paramètres n'est pas un grand modèle commercial de dernière génération. Pour du raisonnement complexe ou de la rédaction exigeante, les modèles frontière restent devant. L'auto-hébergement gagne sur les tâches cadrées (résumer, extraire, classer, qualifier, appeler des outils), qui constituent, en pratique, l'essentiel des besoins IA d'une application métier.
L'architecture : une machine, une passerelle, trois consommateurs
Le montage tient en trois étages. Une machine GPU dédiée fait tourner le modèle via llama.cpp (llama-server), qui expose une API compatible OpenAI, le standard de fait que tous les clients savent parler. Devant elle, une passerelle (OpenWebUI en ce qui nous concerne) centralise ce que le serveur de modèle ne gère pas : comptes et clés API par application, liste d'accès stricte (un appelant inconnu reçoit un 404, pas une mire de connexion) et journalisation. Les applications ne connaissent que la passerelle, jamais la machine GPU : on peut changer de modèle, de machine ou de moteur sans toucher au code des consommateurs.
Les pièges que la théorie ne prédit pas
Les sorties structurées qui rendent le modèle fou
Le tool-calling (un LLM qui appelle les fonctions de votre application) repose sur des schémas JSON. Or llama.cpp convertit ces schémas en grammaire formelle (GBNF) qui contraint physiquement chaque caractère généré. Et certains schémas parfaitement valides produisent des grammaires piégées : un sous-schéma vide additionalProperties: {} (que génèrent des bibliothèques de validation très répandues) est interprété comme « objet obligatoire » : le modèle devient incapable d'émettre un entier ou un tableau à cet endroit, renvoie des appels absurdes, l'application les rejette, le modèle réessaie… boucle infinie. Diagnostic : des heures. Correctif : un filtre sur la passerelle qui réécrit les schémas avant qu'ils n'atteignent le moteur. Moralité : en auto-hébergé, la frontière entre vos schémas et le moteur de génération vous appartient, pour le meilleur et pour le pire.
La température compte plus que le prompt
Notre outil de qualification note des opportunités commerciales. Premier constat en production : deux exécutions sur la même donnée s'écartaient en moyenne de 30 points sur 100, de quoi faire basculer une décision. Nous avons d'abord raffiné le prompt, sans grand effet. Le vrai levier était ailleurs : la température de génération, passée de 0,2 à 0. Écart moyen après : moins d'un point. Pour toute tâche d'évaluation reproductible, ce réglage d'une ligne pèse plus que des heures d'ingénierie de prompt, et c'est le genre de chose qu'on ne découvre qu'en mesurant.
Le SPOF, assumé et surveillé
Une seule machine GPU = un point de défaillance unique. Nous l'assumons, parce que le mode dégradé est acceptable : si le modèle tombe, le CRM perd son assistant, pas ses données ni ses fonctions. C'est un arbitrage explicite : supervision dessus, criticité documentée, et pas de fonction vitale branchée sur le LLM. La règle générale : l'IA auto-hébergée doit enrichir vos applications, jamais conditionner leur fonctionnement.
Par où commencer
- Une tâche cadrée à valeur claire : résumé de fiches, extraction de champs, tri d'emails, qualification. Pas « un chatbot qui fait tout ».
- Un seul modèle bien choisi, évalué sur vos données, plutôt qu'un zoo de modèles impossibles à maintenir.
- Une passerelle dès le premier jour : authentification, allowlist, journalisation, et l'indirection qui vous permettra de tout changer derrière.
- Des mesures : la reproductibilité, la latence et le taux d'erreur se constatent, ils ne se supposent pas.
C'est exactement le périmètre de notre offre d'intégration IA & LLM : brancher un modèle (auto-hébergé chez nous en France, ou API quand c'est le bon choix) sur vos applications existantes, avec les garde-fous ci-dessus. Une tâche répétitive qui mériterait un essai ? Décrivez-la nous.
