Maîtrise
Maîtriser son travail : portabilité, formats ouverts et liberté de sortie
Un travail reste sous votre contrôle si vous pouvez le relire, le reprendre et l’emporter ailleurs.
Une équipe prépare un dossier d’investissement pendant dix-huit mois. Le projet contient des contrats, des tableaux, des sources publiques, trois versions du modèle financier et les raisons qui ont conduit à la recommandation finale. Puis le service qui organisait ce travail devient indisponible.
L’équipe possède encore le PDF présenté au comité. Mais peut-elle retrouver les sources, comprendre les calculs, reprendre une version antérieure, changer de modèle d’IA et continuer le projet avec un autre logiciel ?
Ce test distingue l’accès de la maîtrise. Un travail reste réellement sous contrôle lorsque sa copie de référence, ses représentations lisibles, ses preuves et son chemin de sortie restent accessibles à l’utilisateur.
Cinq couches de maîtrise
La propriété juridique d’un fichier, l’accès technique et l’autorité exercée par un logiciel sont trois sujets différents. Pour évaluer un produit de travail, il faut regarder cinq couches.
- Accès. La personne peut ouvrir et récupérer son contenu sans abonnement actif ni interface distante.
- Autorité. Elle peut modifier, versionner, exporter et supprimer la copie dont elle a la maîtrise.
- Représentation lisible. Le contenu utile ne se réduit pas à une base de données opaque ou à une capture d’écran.
- Remplaçabilité. Un modèle, un fournisseur ou un outil peut être changé sans perdre l’historique du projet.
- Sortie. Si le produit disparaît, le travail, les preuves et les formats nécessaires permettent de poursuivre ailleurs.
Chaque couche corrige une faiblesse de la précédente. Un accès en lecture seule ne donne aucune autorité. Une exportation propriétaire peut déplacer les octets sans les rendre exploitables. Un fichier lisible sans sources ni historique conserve le résultat, mais pas le raisonnement qui permet de le réviser.
Le point de départ de loqy : une copie de travail locale
Dans loqy V1, le moteur de l’agent, l’historique canonique et l’autorité sur le travail résident sur le Mac. L’application fonctionne sans compte et son fonctionnement principal ne dépend pas d’un serveur loqy. Le principe local et ses compléments hébergés explique les limites exactes de cette fondation.
Cette fondation locale s’organise en quatre espaces distincts :
- un dossier connecté, choisi explicitement, dont les fichiers ordinaires restent à leur emplacement ;
- un espace de projet pour les sources et résultats partagés dans ce projet ;
- un espace privé par conversation qui exécute du travail ;
- un espace temporaire pour une exécution, supprimable sans perdre l’état durable.
Cette séparation borne l’accès de l’agent au disque et conserve l’origine des sources admises. Les révisions, les publications dans le projet, les livrables et les liens vers les sources gardent une identité distincte.
Une action sur un fichier réel reste explicite. Produire une nouvelle version dans l’espace privé conserve l’original. La mise à jour d’un fichier lié suit un chemin différent, avec contrôle de conflit. Cette différence est moins visible qu’un bouton d’exportation, mais elle est au cœur de la maîtrise : le logiciel sait quelle copie fait autorité et l’utilisateur décide quand cette autorité change.
Un export utile préserve le travail au-delà de sa base de données
Les données d’une application encodent des choix d’implémentation. Une base Turso, un index vectoriel ou le répertoire interne d’un agent peut être local tout en restant difficile à relire hors du logiciel qui l’a créé.
L’export logique de loqy sépare donc le contenu de ses moteurs de stockage. L’action Tout exporter… écrit un dossier local daté. Les conversations sont représentées en Markdown. Les livrables gardent leur format natif. Les projets, la mémoire, le profil et les compétences utilisent JSON ou Markdown selon leur structure. Les objets importants conservent leur identité, leurs relations et les références de provenance nécessaires pour comprendre leur rôle.
L’export préserve la structure native de chaque format. Un classeur reste un classeur, avec ses feuilles et ses formules qualifiées. Un document, une présentation ou un PDF conserve la révision effectivement livrée. Markdown, CSV, JSON, JSONL, XML, YAML et les autres formats textuels qualifiés restent directement inspectables. Les fichiers fournis par l’utilisateur sont conservés lorsqu’ils sont nécessaires pour comprendre ou reconstruire le travail.
Les secrets suivent une règle différente. Les jetons d’API et les identifiants restent dans le Trousseau macOS. Un rapport d’export signale leur réintroduction comme une étape d’authentification auprès du service suivant.
Les références de conversation ont une portée précise
loqy sait également importer des exportations actuelles de Claude et ChatGPT dans un périmètre borné, puis exporter certaines conversations sous forme de fichiers de référence versionnés. Ces fichiers transportent les messages et leur provenance. Leur périmètre couvre la référence de conversation ; les exécutions, autorisations, pièces jointes, outils et effets externes restent propres à l’application d’origine.
La portabilité précise ce qui est transféré et ce que le logiciel destinataire peut interpréter. Le fichier permet de relire une conversation ou de reprendre son contenu, avec un périmètre explicite pour l’historique natif.
Changer de modèle sans changer de projet
Un verrouillage peut venir du stockage, mais aussi du modèle d’IA. Si les instructions, les sources, les résultats d’outils et les livrables n’existent qu’à l’intérieur d’une conversation propre à un fournisseur, changer de modèle revient à recommencer.
Dans loqy, le modèle est un composant choisi pour une exécution. Le moteur local de l’agent garde la conversation, le plan, les règles, les appels d’outils, les preuves et les livrables. Un modèle local ou hébergé reçoit le contexte admis pour la demande, pas l’autorité sur l’ensemble du projet.
Le modèle exact reste attaché au résultat. Passer de Qwen local à Claude, Mistral, Umans ou un autre fournisseur configuré conserve l’historique et l’attribution des anciennes réponses. La route reste fixe pendant l’exécution ; un échec est signalé à l’utilisateur.
La remplaçabilité préserve le projet lorsque les modèles diffèrent. Le produit conserve l’autorité, attribue chaque résultat au modèle, au fournisseur et à la configuration exacts, puis permet un nouveau choix explicite sans déplacer la copie de référence.
Relier le code source au binaire distribué
Le code de loqy est ouvert selon une répartition de licences documentée : MPL-2.0 pour le cœur ouvert et Apache-2.0 pour les paquets d’interopérabilité explicitement publics. Cela permet d’inspecter la conception, de proposer des changements et de reconstruire les parties couvertes.
La vérification relie ensuite l’application téléchargée à ce code, à ses dépendances et à ses options de construction.
La chaîne source vers application fournit ses propres preuves : entrées de construction verrouillées, nomenclature logicielle, licences, provenance, signature et comparaison reproductible de la charge utile non signée. La signature Apple identifie le distributeur et protège l’intégrité du téléchargement ; la provenance rapproche l’artefact du code publié.
La maîtrise gagne ainsi une propriété transversale : la vérifiabilité. Un chemin de sortie crédible repose sur des formats documentés, des condensats, des manifestes et des outils capables de les relire. La chaîne de preuves d’un agent applique la même exigence à chaque révision du travail.
Le test de continuité après disparition du service
Le scénario est volontairement sévère. Le site, les mises à jour et les services de loqy ne répondent plus. L’équipe possède encore son Mac et son dossier d’export.
Un chemin de sortie complet suit cinq opérations :
- récupérer les fichiers de travail, les livrables, les conversations et les preuves ;
- vérifier les formats, les manifestes et les éventuelles omissions ;
- choisir un autre modèle, un autre fournisseur ou un autre outil ;
- utiliser un lecteur compatible ou reconstruire le logiciel à partir des sources et des dépendances documentées ;
- continuer le projet sans demander au service disparu de réautoriser les données.
La continuité dépend des formats : un tableur complexe utilise des fonctions précises, une page interactive demande son code et ses dépendances, et une source Web peut disparaître. L’export conserve assez d’information pour identifier ces dépendances. La souveraineté européenne étend ce test de sortie aux données, au logiciel, aux modèles, à l’infrastructure, au droit et aux compétences.
Les droits accompagnent aussi le périmètre : un document partagé par une organisation, un abonnement tiers ou une base sous licence conserve ses propres règles. La portabilité porte sur les données que l’acteur est autorisé à exporter et produit un rapport explicite sur les omissions.
Six questions pour évaluer un produit de travail
Avant de confier un projet durable à un logiciel, il est utile de demander :
- Où se trouve la copie de référence et qui peut la modifier ?
- Puis-je exporter sans maintenir un abonnement ou contacter le support ?
- Les contenus sont-ils lisibles indépendamment des bases internes du produit ?
- Les sources, révisions et preuves restent-elles liées aux livrables ?
- Puis-je changer de modèle ou de fournisseur sans perdre l’historique ?
- Quel logiciel, quelle documentation et quelles preuves me permettent de poursuivre si le vendeur disparaît ?
La maîtrise exige les six réponses. Le stockage local devient solide avec des formats lisibles, un binaire vérifiable et des services remplaçables.
Pour loqy, la sortie influence dès le départ la séparation des espaces de travail, l’identité des révisions, les formats de livrables, le choix des modèles, la conservation des preuves et la chaîne de construction. Le critère est concret : après la disparition du fournisseur, l’équipe doit pouvoir comprendre ce qu’elle possède et reprendre le travail.
Sources
- Exigences V1 de loqy
- Expérience de l’application : données et export
- Architecture des données locales et de l’export logique
- ADR sur l’archive ouverte et portable
- ADR sur l’import et l’export de conversations de référence
- Constructions reproductibles, provenance et nomenclature logicielle
- Licence du dépôt