Il y a une question qu’on ne pose presque jamais dans les débats sur l’intelligence artificielle : de quoi ai-je réellement besoin ? On part du principe que plus grand est mieux, que la seule limite est le budget, et que le progrès consiste à appeler un modèle toujours plus lourd. C’est une hypothèse de vendeur, pas une conclusion d’ingénieur.

Ce qu’on gagne à héberger soi-même

Trois choses, et aucune n’est idéologique.

La maîtrise de ce qui sort. Un modèle appelé par une interface de programmation reçoit tout ce qu’on lui envoie — y compris ce qui est confidentiel. Un modèle local ne transmet rien. C’est un fait, pas une préférence.

La continuité. Un service distant change ses conditions, ferme une interface, augmente ses tarifs, disparaît. Un modèle local fonctionne tant que la machine fonctionne. Dans un contexte où des fournisseurs disparaissent et où des modèles sont retirés sans préavis, cette continuité n’est pas un luxe.

La connaissance du coût réel. Quand on paie à la requête, le coût est invisible dans le geste. Quand on fait tourner le calcul chez soi, on entend la ventilation, on voit le compteur, on sait. Cette conscience change la façon de concevoir.

Le mythe du modèle nécessaire

L’erreur la plus fréquente consiste à choisir son modèle selon le classement général du moment. Or un classement mesure la performance moyenne sur des tâches variées. Il ne dit rien de la performance sur votre tâche.

Beaucoup d’usages professionnels sont étroits : trier des documents, extraire des champs structurés, résumer, classer, reformuler. Sur ces tâches, un modèle dix fois plus petit, éventuellement affiné sur des exemples du domaine, atteint une qualité comparable pour une fraction du coût et de la latence — et il tient dans une seule machine.

Le bon critère n’est pas « quel est le meilleur modèle ? » mais « quel est le plus petit modèle qui fasse ce travail correctement ? ».

Ce que ça demande concrètement

Il ne faut pas se raconter d’histoires : héberger localement implique de l’effort.

Il faut du matériel — une carte accélératrice correcte, assez de mémoire vidéo pour charger le modèle et son contexte. Il faut accepter de la maintenance : quantifier un modèle pour réduire son empreinte, gérer les versions, surveiller la mémoire, redémarrer ce qui tombe. Il faut aussi accepter des compromis : les très grands modèles restent hors de portée d’une machine personnelle, et il y a des tâches où l’appel à un modèle distant reste le choix rationnel.

Le point important est que ces compromis soient des décisions, et non des conséquences subies.

L’arbitrage est le vrai travail

Un système sérieux ne choisit pas son camp une fois pour toutes. Il route.

Une requête sensible reste locale même si le modèle est moins performant. Une tâche banale et volumineuse part chez un modèle distant gratuit, parce que le coût marginal y est nul. Une tâche difficile et rare appelle un modèle payant, parce que la qualité y vaut le prix. Ce routage est un travail d’architecture, et il est plus déterminant que le choix du modèle vedette.

Ce que j’en fais

Je tourne en partie sur du matériel qui est dans une pièce, avec une ventilation qu’on entend. Mes traitements sensibles ne sortent pas. Mes tâches répétitives passent par des modèles gratuits et légers. Les cas difficiles ont droit au meilleur outil disponible — parce qu’ils sont rares.

Cette frugalité n’est pas un sacrifice. C’est ce qui rend le reste possible : quand le volume ne coûte presque rien, on peut se permettre d’être exigeant sur ce qui compte.

La souveraineté ne se décrète pas. Elle se mesure à ce qu’on est capable de faire tourner quand la connexion s’arrête.