Un assistant IA qui n’envoie aucune donnée à l’extérieur et fonctionne entièrement sur la machine sur laquelle il est exécuté.
Il y a des données qui ne devraient jamais quitter l’endroit où elles sont produites.
Les plans d’une installation. Les procédures de maintenance. Les anomalies d’une machine qu’aucun concurrent ne devrait jamais voir.
Et pourtant, aujourd’hui, lorsque nous voulons demander à une intelligence artificielle de les lire, de les interpréter ou de les interroger, le réflexe est presque automatique : ouvrir un navigateur et les envoyer dans le cloud.
Je me suis demandé s’il était vraiment nécessaire de faire sortir ces données.
De cette question est né LOCUS : un assistant IA entièrement local, hors ligne par conception et non par limitation technique, pensé pour les environnements où les données et les documents doivent rester au sein de leur propre infrastructure, pour des raisons de sécurité, de confidentialité ou de propriété intellectuelle.
Je pense avant tout à l’industrie, mais le principe est plus large.
Pourquoi le cloud ne suffit pas toujours
Ce n’est pas une position idéologique contre le cloud.
C’est simplement que, dans certains contextes, le cloud n’est pas forcément la solution la plus adaptée. Une installation industrielle, un environnement réglementé ou un réseau sans connexion stable peuvent avoir des contraintes qui rendent nécessaire le maintien des données et des processus au sein de leur propre infrastructure.
LOCUS part du principe inverse : tout fonctionne localement, sur un modèle de langage qui vit sur la même machine que celle qui fournit les réponses.
Aucun appel réseau pendant l’inférence. Aucune donnée ne sort de la machine.
La seule fois où une connexion est nécessaire, c’est pour télécharger le modèle initialement. Ensuite, tout fonctionne hors ligne. Par choix.
Ce que j’ai réellement construit
La partie facile aurait été de prendre un modèle, de construire une interface autour et d’appeler cela une IA locale.
Ce n’est pas ce que je voulais.
Je voulais construire une base qui puisse devenir un produit, pas une expérience de week-end. J’ai donc séparé les responsabilités en composants indépendants, testables et remplaçables.
Il y a une couche de configuration centralisée, où la langue, le domaine et le modèle sont déclarés au lieu d’être dispersés dans le code.
Il y a un model registry, qui traite chaque modèle local comme une ressource avec ses propres métadonnées : version, quantification, taille et checksum. Le modèle n’est jamais simplement un chemin écrit en dur quelque part dans le code.
Il y a les Domain Packages : des dossiers autonomes qui spécialisent LOCUS pour un contexte donné. Aujourd’hui, c’est le domaine industriel. Demain, cela pourrait être n’importe quel autre contexte, sans modifier le cœur de l’application.
Il y a un System Prompt Builder, qui assemble l’identité, la langue, le domaine et le style selon un ordre déterministe. Toujours de la même manière, toujours vérifiable.
Et il y a une Context Architecture qui sépare déjà ce qui deviendra le contexte système, la conversation, les connaissances récupérées, la mémoire et les outils.
Le RAG, la mémoire et les agents ne sont pas encore là.
Mais l’interface nécessaire pour les accueillir a été conçue avant les fonctionnalités elles-mêmes.
Cela me semble important : si l’on sait déjà où l’on veut aller, on peut éviter de devoir construire une nouvelle route à chaque fois.
La leçon à laquelle je ne m’attendais pas
Il y a un épisode qui, plus que toute l’architecture, raconte ce que signifie construire quelque chose comme ça.
À un moment donné, j’ai choisi le modèle le plus léger et le plus rapide parmi ceux dont je disposais.
Il était trois fois plus petit et deux fois plus rapide selon les métriques que j’avais mesurées avec mon benchmark.
Des chiffres impeccables.
Puis j’ai essayé de lui parler en italien.
Grammaire incorrecte. Mots inventés. À la demande la plus simple, « présente-toi en une phrase », il répétait la question au lieu d’y répondre.
Trois essais sur trois.
Le benchmark mesurait la vitesse et la taille. Il ne mesurait pas quelque chose de beaucoup plus simple : si le modèle savait réellement parler la langue que je lui avais demandé de parler.
Je suis revenu en arrière et j’ai conservé le modèle plus lourd comme modèle par défaut.
Depuis, je garde une règle simple en tête :
un chiffre qui gagne sur une métrique ne gagne pas automatiquement sur le problème réel.
Cela vaut pour les modèles d’IA. Probablement pour beaucoup d’autres choses aussi.
L’objectif n’est pas simplement de faire tourner un modèle en local
LOCUS est aujourd’hui un noyau, pas un produit fini.
Il ne fait pas encore de RAG. Il n’a pas de mémoire persistante. Il n’oriente pas encore des agents. Il ne communique pas avec des outils externes via MCP.
Mais il est conçu pour que ces fonctionnalités puissent être ajoutées sans devoir réécrire ce qui existe déjà.
C’est la différence entre concevoir des fondations et ajouter des pièces une par une en espérant que la maison tienne.
L’objectif n’est pas de démontrer qu’il est possible de faire tourner un LLM sur un ordinateur portable.
Cela, désormais, est relativement simple.
L’objectif est de comprendre s’il est possible de construire une IA sérieuse, spécialisée et réellement multilingue. Pas multilingue simplement parce qu’une liste de langues est prise en charge, mais parce que la langue et le domaine font partie de la conception elle-même.
Et surtout, une intelligence artificielle qui n’a pas besoin de demander la permission à un serveur que l’on ne contrôle pas.
Je me demande si, dans quelques années, une IA qui ne quitte jamais l’usine nous semblera être un choix évident, plutôt qu’une solution particulière qu’il faut justifier à chaque fois.
Pour l’instant, je continue à la construire.
Une couche à la fois.
P.-S. Si vous êtes curieux d’essayer LOCUS dans sa version expérimentale, écrivez-moi à contact@rheorix.com
