Pourquoi loqy commence en local et en quoi le cloud peut être complémentaire

Une directrice financière prépare une note pour son comité de direction. Deux prévisions internes se contredisent. Elle veut comparer leurs hypothèses, rechercher des signaux publics qui pourraient les remettre en cause, puis livrer une recommandation dont chaque conclusion peut être vérifiée.

Le travail mêle trois besoins. Les fichiers sont confidentiels. La recherche nécessite Internet. Certaines étapes demandent peut-être un modèle plus puissant que celui qui tient sur son Mac. Faut-il tout garder en local, tout envoyer dans le cloud, ou découper le problème autrement ?

La réponse de loqy tient en une règle : le local est le point de départ complet, le cloud est un complément explicite et l’utilisateur choisit selon ses besoins.

Le travail commence sous l’autorité de l’utilisateur. Lorsqu’une étape demande une capacité extérieure, loqy indique le modèle ou le service concerné et les données nécessaires. Le local fixe ainsi le point de départ, et l’utilisateur décide quand une capacité extérieure vaut l’échange de données qu’elle suppose.

En bref

Une base locale complète, des capacités cloud explicites

Le terme local-first, que l’on peut traduire par priorité au local, vient d’une réflexion plus large sur les logiciels qui donnent la priorité aux données de l’utilisateur, au fonctionnement hors ligne et à la pérennité du travail. Ink & Switch en a formulé les principes pour des logiciels capables de collaborer sans faire d’un serveur central le propriétaire implicite des données.

Un agent IA fait davantage qu’ouvrir un document. Il assemble du contexte, sollicite un modèle, appelle des outils, produit des fichiers et peut proposer une action dans le monde extérieur. Son autorité dépend de l’ensemble de ces chemins.

Quatre questions permettent de décrire cette autorité :

1. où le travail de référence est conservé ;
2. où le moteur de l’agent s’exécute ;
3. où le modèle produit sa réponse ;
4. quelles données et permissions franchissent chaque frontière.

Dans loqy V1, le moteur de l’agent est local. Le Core, le noyau de contrôle de l’application, conserve l’autorité sur l’état du travail, les permissions, les outils et les effets. Le modèle peut être local ou hébergé. Ce sont deux choix différents : changer de modèle ne déplace pas le moteur de l’agent. La carte d’exécution V1 suit cette séparation composant par composant.

Un compte et une infrastructure distante ne sont donc pas nécessaires pour disposer de l’application complète. Une ressource extérieure reste néanmoins accessible lorsqu’elle apporte une capacité utile et que l’utilisateur accepte la frontière.

Le local-first fournit un point de départ autonome. L’isolation et la protection viennent de contrôles concrets, tandis que les capacités extérieures restent visibles.

Ce que le local change concrètement

Pour la directrice financière, commencer en local produit des effets immédiats.

Les documents restent près de leur source. Elle peut ouvrir les deux prévisions, les comparer et préparer une première structure sans les transmettre à un fournisseur de modèle. Le travail reste possible hors ligne tant qu’il n’appelle pas une ressource externe.

Les opérations répétitives ne créent pas de facture par jeton. Une fois le Mac et le modèle installés, lire à nouveau un tableau, reformuler un passage ou extraire une série de montants consomme de l’énergie et du temps machine, mais ne déclenche pas une facturation à chaque génération.

La latence ne dépend pas d’un aller-retour réseau. Pour une extraction courte, un classement ou une transformation structurée, un modèle local adapté peut répondre immédiatement. Le gain dépend du matériel, du modèle et de la tâche.

Une panne distante ne supprime pas le socle de travail. Le moteur local, l’historique et les outils disponibles hors ligne ne disparaissent pas si une API est indisponible. Une recherche web ou un modèle hébergé peut bien sûr devenir momentanément inaccessible, mais la conversation et les éléments déjà produits restent sur le Mac.

Ce contrôle a des limites. La mémoire unifiée restreint la taille des modèles. Une analyse nouvelle ou un contexte très long peut bénéficier d’un modèle hébergé plus capable. Une génération intensive peut solliciter le processeur graphique, réduire l’autonomie et ralentir d’autres applications. Le coût réel du local et de l’hébergé dépend donc du travail, du matériel et du taux de réussite.

Choisir le modèle tandis que l’application reste locale

Moteur et modèle ont des responsabilités différentes.

Le moteur local organise l’exécution. Il maintient le fil de travail, prépare le contexte, vérifie les permissions, attribue les outils et enregistre les résultats. Il décide si une proposition du modèle correspond à une capacité réellement accordée.

Le modèle produit une réponse à partir du contexte qu’il reçoit. Il peut s’exécuter sur le Mac ou chez un fournisseur hébergé. Le Core traite cette réponse comme une proposition. Une demande comme « envoie ce courriel » traverse encore la permission précise qui autorise l’envoi.

La directrice financière peut ainsi utiliser un modèle local pour extraire les hypothèses de deux fichiers, puis sélectionner un modèle hébergé pour confronter plusieurs scénarios. La conversation, les sources, les règles et le livrable ne changent pas de propriétaire entre ces deux générations.

Le modèle attribué à l’exécution ne change pas en cours de route. S’il échoue, loqy ne redirige pas silencieusement le contexte vers un autre fournisseur. L’utilisateur sait ainsi qui a reçu quoi.

« Le cloud » recouvre trois frontières

Le mot cloud recouvre trois opérations distinctes, avec des données et une autorité différentes.

1. Solliciter un modèle hébergé

Le moteur reste local. loqy transmet au fournisseur sélectionné la requête et le contexte nécessaires à la génération, puis reçoit la réponse du modèle. Les identifiants, l’accès aux fichiers et l’autorité sur les outils restent derrière les capacités du Core.

Cette première frontière concerne l’inférence : où le modèle calcule-t-il sa réponse ?

2. Appeler un service externe

Une recherche web, un connecteur ou une API reçoit une requête propre à sa fonction. La recherche peut recevoir des termes à rechercher. Un connecteur peut recevoir une opération précise et ses paramètres. Le résultat revient sous une forme attendue par loqy.

La deuxième frontière concerne un outil. Le Core construit une requête de recherche à partir des termes utiles, tandis que le fichier financier reste dans le travail local.

3. Exécuter le travail à distance

Un moteur distant déplacerait l’état d’une exécution, ses outils et une partie de son autorité vers une infrastructure cloud. C’est une architecture différente, utile pour un accès distant ou des traitements indépendants du Mac. Le chemin V1 exécute le moteur et son autorité sur le Mac ; le modèle hébergé y déplace uniquement la génération.

Le parcours d’une demande mixte

Reprenons la note financière, étape par étape.

1. Ouverture locale. La directrice financière ouvre les deux prévisions. loqy conserve la conversation et les références de travail sur le Mac.
2. Première analyse locale. Un modèle local extrait les hypothèses, repère les divergences et prépare une liste de points à vérifier.
3. Recherche explicite. L’utilisateur autorise une recherche sur quelques signaux publics. Le service reçoit les requêtes nécessaires, pas l’intégralité des documents internes.
4. Choix du modèle. Si les scénarios demandent davantage de capacité, l’utilisateur sélectionne un modèle hébergé. Le Core construit le contexte de la génération et l’envoie au fournisseur choisi.
5. Contrôle des effets. Le modèle peut proposer une révision ou une action. Le Core vérifie les permissions et exige la décision correspondante avant tout effet conséquent.
6. Livraison locale. La note, ses sources, les résultats d’outils et les décisions restent attachés au travail pour permettre la revue.

Une recherche ou un modèle hébergé reçoit les données nécessaires à son rôle. Chaque passage possède un destinataire et une portée identifiables, ce qui rend la frontière de confidentialité précise.

Des contrôles en couches autour de l’appareil

Une machine locale peut être compromise, perdue, insuffisamment sauvegardée ou rarement mise à jour. Un processus exécuté avec trop de droits peut lire des données qui ne lui étaient pas destinées. Un document ou une page web peut contenir des instructions hostiles conçues pour détourner un agent. Un modèle téléchargé peut ne pas correspondre à l’artefact attendu.

La priorité au local optimise surtout le contrôle et la minimisation de confiance. Elle doit être complétée par des mécanismes de sécurité concrets.

Dans loqy V1 :

• le Core local est la seule autorité sur l’état métier, les permissions et les effets ;
• les modèles et moteurs gérés ont une identité et des artefacts attendus ;
• les identifiants des fournisseurs sont conservés dans le trousseau macOS et ne sont pas confiés au modèle ;
• les outils disponibles sont un ensemble fermé, propre à l’exécution ;
• le code, les scripts et les traitements non fiables s’exécutent dans un environnement isolé ;
• une action externe ou destructive traverse une permission typée et visible ;
• le choix du modèle et du fournisseur reste fixe pour l’exécution, sans repli silencieux.

Ensemble, ces protections réduisent l’autorité ambiante et rendent les frontières vérifiables. Le lieu du modèle devient ainsi une couche d’un dispositif de sécurité plus complet.

Un choix informé au bon niveau

Le contrôle reste utile lorsqu’il porte sur une décision compréhensible. loqy regroupe les opérations courantes dans des capacités précises et réserve la validation aux effets qui la nécessitent.

loqy place donc la décision au bon niveau : choix du modèle, permission d’un outil, accès à une ressource et validation d’un effet conséquent. Le produit connaît les données nécessaires au fonctionnement d’une conversation et de ses outils. Il n’oblige pas l’utilisateur à recomposer manuellement chaque enveloppe technique.

L’interface garde le passage du local aux services distants fluide et indique la frontière au moment où elle compte.

Commencer local pour pouvoir choisir

La directrice financière peut finalement rester entièrement en local. Elle peut aussi autoriser une recherche bornée et sélectionner un modèle hébergé pour une partie de l’analyse. Dans les deux cas, le moteur local conserve l’organisation du travail, les règles, les outils et les preuves.

loqy commence donc en local pour préserver ce choix. Internet et les modèles hébergés restent disponibles comme des capacités choisies par l’utilisateur, tandis que le travail garde son ancrage local.

Sources et méthode

• Ink & Switch, Local-first software
• loqy, vision et périmètre du produit
• loqy, vue d’ensemble de l’architecture
• loqy, architecture de l’inférence locale
• loqy, fournisseurs de modèles hébergés relayés par le Core
• loqy, modèle de menace

Cet article décrit le contrat produit et architectural de loqy V1. Les architectures cloud ultérieures sont documentées séparément.