Nous pensons que l'essentiel du travail quotidien d'une entreprise avec l'IA finira par tourner sur son infrastructure, et non chez un fournisseur. Ce n'est pas un pari moral sur la souveraineté, même si elle compte. C'est un pari sur l'économie, et il repose sur une propriété technique précise que nous allons détailler.
Nous allons aussi donner le chiffre qui contredit la version simpliste de notre thèse, parce que le publier est notre méthode.
Trois choses vont dans le même sens.
Le coût marginal d'une requête locale est nul. Une fois la machine payée, la millième requête coûte la même chose que la première, c'est-à-dire de l'électricité. Chez un fournisseur, chaque requête est facturée. À usage intensif, les deux courbes se croisent, et ce croisement arrive plus tôt qu'on ne le croit dès que plusieurs personnes utilisent le système.
Les données de travail ne veulent pas voyager. Ce n'est pas une position de principe, c'est un constat d'usage : les documents qui ont le plus de valeur pour un assistant sont précisément ceux qu'on hésite le plus à envoyer dehors. Un assistant utile est un assistant à qui l'on donne les vrais dossiers, ce que personne ne fait sereinement avec un service en ligne. C'est le sujet du CLOUD Act, que l'hébergement européen ne règle pas.
Les petits modèles progressent plus vite que les besoins réels. La plupart des tâches d'entreprise ne demandent pas un modèle capable de tout. Elles demandent un modèle qui connaît vos documents et vos procédures.
Ce troisième point est celui que nous avons voulu mesurer plutôt que d'y croire.
Sur un banc de 82 cas figé avant toute mesure, sur les 231 outils réels de notre assistant, un modèle local de 2,9 milliards de paramètres atteint le score d'un modèle cloud de 30 milliards après 53 centimes d'entraînement. La version de 7,2 milliards le dépasse ensuite dans sa configuration de production, 69 contre 58.
Tout est public : le juge, les sorties brutes, les recettes, les empreintes. Le protocole complet est ici, et la suite de la campagne aussi, y compris neuf tentatives qui n'ont rien donné.
Voici celui qu'un article promotionnel omettrait. Nous avons soumis un transformer de 7 milliards de paramètres au même banc, sans aucun entraînement :
| brut | après notre recette | |
|---|---|---|
| Notre RNN de 2,9 Md | 28 | 61 |
| Notre RNN de 7,2 Md | 29 | 69 |
| Un transformer de 7 Md | 69 | 51 |
Il fait 69 sans rien apprendre. Autant que notre meilleur RNN entraîné. Et notre recette, appliquée telle quelle, le dégrade de 18 points.
Ce chiffre interdit une affirmation que nous ne ferons donc pas : non, un RNN n'est pas « meilleur » qu'un transformer. Sur la qualité brute, à taille comparable, le transformer était devant.
Notre thèse est ailleurs.
Un transformer conserve en mémoire un cache de tout ce qui a été dit. Ce cache grandit avec la conversation. Deux conséquences pratiques que tout le monde découvre en déployant :
Un réseau récurrent maintient au contraire un état de taille fixe. Une conversation de trois heures occupe la même mémoire qu'une conversation d'une minute, et le dernier mot coûte le prix du premier.
Sur une infrastructure élastique facturée à l'usage, cette différence se dilue. Sur une machine que vous avez achetée, elle décide de tout : combien d'utilisateurs simultanés tiennent, jusqu'où une session peut durer, et si votre serveur suffit encore dans six mois.
C'est pour cette raison, et pas pour un supposé avantage de qualité, que nous avons investi sur cette famille d'architectures.
Notre thèse a des limites que nous préférons annoncer.
Un assistant conversationnel généraliste sur un serveur sans carte graphique n'est pas viable. Le goulot n'est pas la génération mais la lecture du contexte, qui se compte en minutes sur un processeur dès qu'on envoie beaucoup de documents. Ce calcul se mesure, nous l'avons fait, et il ne pardonne pas.
Le local impose de choisir son architecture avant son matériel. Ce qui tient sur un processeur, c'est un système conçu pour lui : modèle compact, recherche stricte qui n'envoie que les extraits nécessaires, restitution directe quand le document se suffit. Sortez de ce cadre et il faut une carte graphique.
Sur les tâches les plus difficiles, les gros modèles cloud restent devant. À échafaudage égal, le modèle de 30 milliards conserve l'avantage sur notre banc, 71 contre 69. Nous le publions parce que c'est vrai.
Oui, pour le travail répétitif adossé aux documents de l'entreprise : recherche interne, réponses sourcées, extraction, rédaction cadrée. Un assistant généraliste qui doit tout faire vite demande soit une carte graphique, soit des appels ponctuels à un modèle distant. Une architecture honnête combine les deux, requête par requête.
Dès que l'usage est fréquent, oui. Une requête locale a un coût marginal nul, quand un abonnement facture chaque siège et un fournisseur chaque requête. Le point de croisement dépend du volume : à quelques personnes qui s'en servent tous les jours, il se compte en mois, pas en années.
Pas pour la qualité brute : à taille égale, le transformer garde l'avantage, nos propres chiffres le montrent. L'intérêt du RNN est structurel, mémoire constante et coût par mot stable, donc une capacité d'accueil prévisible sur une machine achetée. C'est un choix d'infrastructure, pas un dogme.
Le local ne gagnera pas parce qu'il serait moralement supérieur, ni parce que les petits modèles égaleraient les gros en tout. Il gagnera là où le travail est répétitif, adossé à vos documents, et suffisamment fréquent pour que le coût marginal compte. C'est-à-dire la majorité du travail réel d'une entreprise.
Le reste continuera de passer par des modèles distants, et c'est très bien ainsi. Une plateforme honnête vous laisse arbitrer requête par requête plutôt que de choisir un camp à votre place. C'est ce que nous construisons avec Gungnir, et ce que nous installons et opérons chez nos clients.
Si cette thèse est fausse, nos chiffres sont publics et vous pouvez la démonter avec. C'est le but.
