Pas de bureau Linux classique à entretenir. La plateforme est rendue en plein écran par un navigateur durci, sur un compositeur graphique minimaliste. L'environnement utilisateur est généré par IA et optimisé pour ce mode d'affichage unique. Démarrage en une dizaine de secondes sur un poste standard.
Une cinquantaine de capacités machine — écran, fichiers, audio, Wi-Fi, caméra, micro, presse-papier, sessions web isolées, porte d'administration à la demande — sont mises à disposition directement dans la page de la plateforme, sans passer par le réseau. Le contrat est strictement aligné avec Boréal pour Windows : les applications agentiques sont portables d'un côté à l'autre.
Le même système peut, depuis l'interface, basculer du rôle de client à celui d'hôte ProductivIA local — pour servir la plateforme à une équipe, une classe ou une organisation entière. Si le matériel le permet, Matania peut être servi avec la plateforme.
Distribution Linux LTS récente, dépouillée du superflu — aucun environnement de bureau, aucun gestionnaire de paquets manipulable depuis le poste, aucun service tiers laissé en place « au cas où ». L'image disque tient sur quelques dizaines de gigaoctets et adopte un schéma de partition simple, identique sur tous les déploiements d'une même version.
Chaîne de démarrage moderne, unique et linéaire — un seul chemin, caché à l'utilisateur, qui amène directement à la session graphique. Pas de menu, pas de dual-boot, pas de mode legacy. La simplicité de cette chaîne fait partie intégrante de la posture de sécurité du produit.
Un compositeur léger choisi pour faire une chose : afficher une fenêtre plein écran de la plateforme. Détection automatique du GPU disponible (NVIDIA, Intel, AMD), avec une priorité de sélection raisonnable et un mode de repli logiciel quand aucun accélérateur 3D natif n'est utilisable.
Un navigateur de la famille Chromium, récent, préchargé en mémoire dès le démarrage pour atteindre la plateforme en une dizaine de secondes. Démarré dans une posture délibérément restrictive : il est l'environnement d'exécution de la couche applicative ProductivIA, et rien d'autre.
Démarrage plein écran sur ProductivIA, capacités hôte injectées dans la page, profil utilisateur persistant. C'est le mode poste de travail.
Le mode serveur s'active explicitement depuis l'interface. La machine sert alors la plateforme ProductivIA localement, sans dépendre d'un poste tiers ni d'un OS serveur généraliste.
Si un GPU compatible dispose d'au moins 16 Go de mémoire dédiée, Matania peut être servi avec la plateforme localement. Sans ce seuil, le serveur fonctionne et délègue l'inférence aux ressources distantes.
En mode client, la machine n'écoute strictement rien sur le réseau extérieur. Les capacités exposées à la plateforme circulent par des canaux internes au poste, et seul un endpoint de supervision peut être activé volontairement par l'administrateur. Aucun service serveur n'est ouvert tant que l'utilisateur ne l'a pas explicitement décidé.
Le mode serveur, qui s'active depuis l'interface, ouvre alors — et seulement alors — la surface réseau nécessaire pour servir la plateforme aux autres postes de l'organisation. La posture restrictive du client reste celle par défaut ; le rôle serveur demeure un choix conscient, pas un état latent.
Au cœur du système : un service qui amène la machine de l'écran de démarrage à la plateforme, en plein écran, en quelques secondes. Redémarrage automatique en cas d'incident, mode diagnostic en repli si une étape critique échoue.
Un point d'accès interne, désactivé par défaut, qui permet — quand vous le décidez — à votre propre outil de supervision d'observer l'état du poste depuis votre réseau. Protégé par jeton, refermable à tout moment.
Un mécanisme événementiel qui synchronise, à chaque changement significatif, le profil utilisateur que la session tient en mémoire vive vers le disque. L'arrêt brutal n'entraîne aucune perte d'état et aucune corruption de base.
La porte d'administration distante reste fermée par défaut. Elle peut être ouverte à la demande, pour une durée déterminée, après quoi elle se referme d'elle-même.
Capture du bureau entier ou d'une zone précise, lecture des bornes de la fenêtre courante. C'est ce qui donne à l'agent la vision de ce que l'utilisateur regarde.
Parcourir le système de fichiers de l'utilisateur, lire, écrire, déplacer, copier, supprimer — avec une protection systématique des emplacements sensibles du système.
Exécuter une commande locale, déplacer la souris à la manière d'un humain, taper du texte, déclencher un raccourci clavier.
Découvrir les sorties audio disponibles, choisir la sortie active, ajuster le volume, couper le son, tester la chaîne audio.
Lister les adaptateurs, scanner les réseaux disponibles, se connecter, se déconnecter, lire l'état courant.
Énumérer les périphériques, capturer une image, lister les entrées micro, enregistrer un échantillon de test.
Vérifier l'état de la porte d'administration, l'ouvrir pour une durée déterminée, la refermer à la demande.
Ouvrir une session de navigation isolée, naviguer, en capturer le résultat, la refermer — utile aux agents qui doivent agir sur un autre site sans interférer avec celui de l'utilisateur.
Passer en plein écran, lire les bornes de la fenêtre courante, lire et écrire le presse-papier, ouvrir une fenêtre privée à la demande.
Une voie d'accès classique à ces capacités passerait par un service réseau auquel n'importe quel programme pourrait théoriquement parler, moyennant un mécanisme d'authentification à concevoir, à maintenir et à durcir indéfiniment. Surface d'attaque cumulative, et risque qu'une page tierce de votre navigateur — publicité, iframe, contenu embarqué d'un autre site — finisse par appeler ces capacités à votre insu.
L'approche retenue inverse la logique. Les capacités hôte ne vivent pas sur le réseau : elles sont injectées directement dans la page de la plateforme, par un mécanisme local que seul votre navigateur sur votre poste peut activer, et uniquement pour les domaines explicitement reconnus. Une page tierce n'a même pas à se voir refuser l'accès — pour elle, l'interface n'existe simplement pas.
Les mêmes capacités agentiques, ajoutées par-dessus un Windows existant. Vous gardez votre environnement habituel — et tout ce qui vient avec : télémétrie permanente, mises à jour subies, plusieurs gigaoctets de services système, démarrage long, surface d'attaque héritée, dérive cumulative inévitable. C'est le bon point d'entrée pour évaluer la plateforme sans changer d'OS.
Les mêmes capacités agentiques, sur un système conçu pour les porter. Pas de couche Windows entre la plateforme et la machine. Pas de télémétrie sortante. Pas de mises à jour subies. Démarrage en une dizaine de secondes. Surface d'attaque réduite à la mission. Boréal OS peut rester client ou devenir serveur ProductivIA depuis l'interface. Et, sur poste équipé d'un GPU compatible, Matania en résidence locale — l'inférence devient un service système. L'écart entre les deux est philosophique et architectural, pas fonctionnel.
La surface offerte à la plateforme est strictement la même sous Boréal OS et sous Boréal pour Windows. Tout ce qu'un agent peut faire d'un côté — voir l'écran, lire ou écrire des fichiers, piloter le navigateur, manipuler l'audio, la caméra, le réseau, le presse-papier — il peut le faire de l'autre, avec le même contrat de réponse.
Quelques détails diffèrent en arrière-plan : le système se présente à la plateforme comme « Linux » ou « Windows », ce qui permet à une application d'adapter quelques conventions de surface (séparateurs de chemin, raccourcis clavier). Sur la version actuelle de Boréal OS, une poignée d'interactions n'ont pas encore d'équivalent natif sous le compositeur graphique utilisé et sont traitées via un mécanisme de repli ; la plateforme s'en charge sans intervention de l'utilisateur.
Conséquence pratique : une application développée pour l'écosystème agentique fonctionne indifféremment sur les deux distributions. Le choix entre Boréal pour Windows et Boréal OS ne se joue donc pas sur ce que l'agent sait faire — il se joue sur le système qui le porte.
Une fois ce contrat respecté, les deux mondes n'ont en réalité rien à voir. Sous Boréal pour Windows, la couche agentique vit par-dessus un OS d'éditeur tiers : télémétrie permanente, mises à jour subies, empreinte mémoire et temps de démarrage hérités du système, surface d'attaque étendue, dérive cumulative inévitable. L'écosystème agentique y fonctionne pleinement — c'est le bon point d'entrée pour évaluer la plateforme — mais le système d'exploitation lui-même reste celui d'un autre.
Sous Boréal OS, le système a été conçu pour cette mission précise. Pas de télémétrie sortante. Pas de mises à jour silencieuses : chaque version est une image signée que l'on adopte à son rythme. Empreinte mémoire et temps de démarrage réduits au strict nécessaire, le reste de la machine revenant à la plateforme et, si activé, à Matania en résidence. Une surface de services réduite et documentée. Un durcissement produit par passes agentiques sous supervision humaine, et la garantie que tous les postes d'une même version sont strictement identiques à l'instant t — ce qui rend le diagnostic et le support immédiatement scriptables.
C'est aussi côté Boréal OS qu'on bascule d'un client vers un rôle serveur — pour servir la plateforme à toute une organisation depuis vos propres locaux — et que Matania peut tourner en local quand la machine dispose du GPU nécessaire. Conclusion : pour utiliser la plateforme, Boréal pour Windows suffit ; pour aligner l'OS lui-même avec les exigences de confidentialité, de sobriété, de non-obsolescence et de souveraineté, Boréal OS est la seule option cohérente.
N'existent qu'à l'intérieur du poste, injectées dans la page de la plateforme. Aucune surface réseau n'est ouverte pour les exposer, aucun service tiers ne peut s'y connecter, aucune autre page que celle de la plateforme ne peut les atteindre.
Si vous l'activez, un point d'accès interne devient joignable sur votre réseau, protégé par jeton à régénérer en production. Désactivable à tout moment.
Disponibles strictement en local, et proxifiés au travers du canal de supervision quand celui-ci est ouvert. Aucun port additionnel n'est exposé directement sur le réseau.
Fermée par défaut. Activable à durée déterminée, refermeture automatique. Plus de détails dans la FAQ.
Cartes NVIDIA récentes (GeForce, Quadro, RTX) — pilote prioritaire intégré à l'image.
GPU intégrés et cartes Intel modernes (Skylake et au-delà, Intel Arc).
AMD Radeon récents (RDNA) et legacy.
Mode de repli logiciel disponible quand aucun pilote 3D natif n'est utilisable.
Ethernet : pratiquement toute carte prise en charge par les noyaux Linux 6.x récents.
Wi-Fi : adaptateurs Intel, MediaTek, Realtek, Atheros et Broadcom courants, en WPA2 et WPA3.
Chaîne audio simple et déterministe, sans démon intermédiaire. Cartes son intégrées, USB et HDMI courantes. Préférence par défaut pour la sortie analogique du poste.
Webcams USB UVC standards et caméras intégrées de portable. Micros listés et testables individuellement, avec un enregistrement de test en qualité CD.
Périphériques USB et PS/2 standards, Bluetooth si appairé en dehors de la plateforme. Saisie et clic synthétiques disponibles via les capacités agentiques. Écrans tactiles courants pris en charge nativement.
NVMe, SATA (SSD et HDD), eMMC. À l'installation, les périphériques amovibles et le disque sur lequel le système est en train de tourner sont systématiquement exclus de la liste des cibles candidates.
Pendant la session, le profil du navigateur — historique, cookies, données locales — vit intégralement en mémoire vive. Réponses instantanées, aucune écriture parasite sur le disque, aucune fragmentation cumulative.
Lorsqu'un élément à persister change, le système le copie sur le disque, dans un format atomique : on écrit à côté, puis on substitue. Une coupure brutale ne laisse jamais de fichier corrompu derrière elle, et la session repart proprement au démarrage suivant.
Matania observe l'usage local, ajuste le système, et prend en charge les inférences courantes — résumé, reformulation, lecture d'image, analyse de document, génération de texte court. Aucune donnée n'a besoin de quitter la machine pour ces tâches. Lorsqu'une requête dépasse ses capacités, il bascule en orchestrateur et délègue à un fournisseur partenaire, si tel est votre choix.
En mode serveur, et avec une cible matérielle d'au moins 16 Go de mémoire dédiée, Matania peut être servi à toute l'organisation depuis le même hôte que la plateforme. La cohérence devient verticale : un seul poste sert l'application et le modèle, tout reste à l'intérieur du périmètre.
Aucune capacité hôte exposée sur le réseau. Origines autorisées explicitement listées. Porte d'administration distante fermée. Supervision distante désactivée par défaut, jeton à régénérer si elle est activée.
Confirmations textuelles pour toute opération destructive. Validation systématique de l'origine et des chemins demandés. Aucun contournement possible depuis une page tierce ou un cadre embarqué. Aucune télémétrie sortante du navigateur ou du système.
Compatibilité matérielle, sécurité, mises à jour, supervision, mode serveur, exécution locale de Matania.
Procédure complète : préparation de la clé USB, BIOS, installation, premier démarrage.