Le copilote

Il lit l’écran. L’interrupteur est à toi.

Delta peut regarder une session comme le ferait un second technicien : lire l’erreur à l’écran, dire quoi essayer, rédiger le compte rendu après coup. Chacun de ces regards quitte la machine par une seule fonction — et cette fonction ne démarre pas tant que tu n’as pas dit oui.

Une seule sortie

Cinq surfaces. Une porte.

Le copilote, le lecteur d’écran, l’avant-après, les repères sur la frise et le compte rendu écrit n’ouvrent pas chacun leur connexion. Ils appellent la même fonction, et le contrôle du consentement vit à l’intérieur — pas dans le bouton qui les a lancés.

  1. Le contrôle est à la sortie

    Une surface qui oublie de demander est refusée quand même. Et une écrite l’an prochain par quelqu’un qui n’a jamais lu cette page aussi. Il y a exactement un endroit par lequel le contenu de l’écran peut quitter la machine, et c’est là que la porte est boulonnée.

  2. Le consentement dure un lancement

    C’est une valeur en mémoire, volontairement jamais écrite sur le disque. Ferme Delta et elle disparaît ; le lancement suivant redemande. Ce que tu as accepté le mois dernier ne vaut plus rien.

  3. L’extinction est attendue

    La révocation est attendue, pas lancée puis oubliée. Si le client ne peut pas confirmer que la porte s’est fermée, il le dit — au lieu de te montrer un interrupteur sur « éteint » au-dessus d’une porte ouverte.

  4. L’autre partie est prévenue

    La première fois que l’IA touche une session, une ligne arrive dans le chat de cette session pour le dire. Tu te déconnectes et la session suivante reçoit son propre avis : un accord donné il y a une heure ne peut pas couvrir en silence un inconnu.

Ce qu’il fait

Cinq choses, et les chiffres qui sont dessous.

Rien de tout cela n’est « propulsé par l’IA » dans l’abstrait. Chaque surface est une procédure fixe avec un budget fixe, et le budget est écrit dans le client où on peut le lire, pas dans une promesse à laquelle il faut croire.

  1. Il regarde la session

    Une image toutes les huit secondes, et seulement si plus de douze pour cent des pixels ont changé depuis la précédente — un écran immobile ne coûte rien. L’image est réduite à 1024 px de large avant d’aller où que ce soit, et les trois lectures précédentes voyagent avec elle comme contexte. Vingt suggestions sont gardées ; la plus ancienne tombe.

  2. Il lit l’erreur sur l’écran

    Une capture revient sous forme du texte qui était à l’écran, des codes d’erreur qu’il contient, et pour chaque code d’une marche à suivre avec un indice de confiance. Le texte est cherchable, donc un mur de journal devient une question plutôt qu’un défilement.

  3. Avant, et après

    Prends un relevé de la machine, fais le travail, prends-en un autre. Ce qui a changé entre les deux revient rédigé — pour que « ça marche maintenant » ait derrière lui quelque chose qu’un collègue pourra lire demain.

  4. Il marque les moments

    Un enregistrement est échantillonné toutes les dix secondes, jusqu’à cinquante repères, et les erreurs et changements d’état se posent sur la frise. Tu vas au moment au lieu de regarder l’heure entière.

  5. Il rédige la session

    Un enregistrement terminé devient un compte rendu : ce qui n’allait pas, ce qui a été fait, dans l’ordre où c’est arrivé — construit sur le journal de la session elle-même, pas sur la mémoire de quelqu’un.

Où ça part

Par une seule passerelle, et elle est à nous.

Le contenu de l’écran d’une session d’assistance, ce sont les données de quelqu’un d’autre. Les envoyer vers un service généraliste hors de l’UE casserait la promesse que fait tout le reste de ce produit, donc cette adresse n’est même pas compilée dans le client.

Une adresse
Chaque requête part vers ai.altovar.net — notre passerelle, sur nos machines, dans l’UE. Les clés de ce qu’il y a derrière restent sur la passerelle ; le client tient une clé vers la passerelle et rien d’autre.
Ou la tienne
Pointe le client vers une passerelle que tu exploites et il utilisera celle-là. Il n’existe pas de seconde adresse vers laquelle il pourrait revenir en silence si la tienne ne répond pas.
Quatre voies, pilotées depuis le serveur
Une surface demande un niveau d’effort, pas un moteur. Quel moteur sert cette voie, c’est une table publiée par la passerelle qui le décide, relue toutes les dix minutes par le client — la flotte se réoriente donc par une modification là-bas, jamais par une version ici.
Et un plancher dessous
Si la table ne peut pas être récupérée, la dernière vue s’applique. Si aucune n’a jamais été vue, quatre voies compilées dans le client s’appliquent. Le routage se dégrade en silence : il ne s’ouvre pas et il ne se bloque pas.

Une image est plafonnée à 2 Mo avant d’être envoyée — et sans consentement, une requête n’atteint jamais le point où ce plafond compterait.

Les réglages AI Copilot de Delta : analyse d’écran pendant les sessions de support, une clé API stockée en local et jamais partagée, et la passerelle ai.altovar.net.Les réglages AI Copilot de Delta : analyse d’écran pendant les sessions de support, une clé API stockée en local et jamais partagée, et la passerelle ai.altovar.net.
Réglages → AI Copilot
Sur la version que tu peux télécharger

Construit, et pas encore atteignable.

Sur la version que tu peux télécharger, aucune des cinq surfaces ci-dessus ne s’ouvre. Voici exactement pourquoi, mesuré sur l’artefact dont notre page de téléchargement publie l’empreinte.

  1. Tous les panneaux d’IA vivent dans la session partagée

    Le copilote, le lecteur d’écran, l’avant-après et les commandes d’enregistrement sont montés dans une seule vue : la session qui démarre depuis « Share Link ». La fenêtre ordinaire de bureau à distance n’en a aucun.

  2. La version Linux n’ouvre pas cette session

    Nous avons lancé l’AppImage publiée et appuyé sur Share Link. Elle s’arrête sur « le partage de session n’est pas configuré sur cette installation ». Derrière se dresse un second mur : le webview que l’AppImage transporte n’a pas de WebRTC du tout — nous avons lu la valeur dans la bibliothèque que l’application charge elle-même, pas dans celle du système.

  3. Le correctif est écrit, pas publié

    Une version qui embarque un webview avec WebRTC activé est déjà dans le tronc du produit. Tant qu’une publication ne l’emporte pas, cette page décrit une architecture que tu peux lire et non une fonction que tu peux utiliser — et nous préférons que tu l’apprennes ici plutôt qu’après le téléchargement.

Deux affirmations ont quitté ce site le jour où nous les avons mesurées. Les commandes vocales : l’interface de reconnaissance dont elles ont besoin est absente du webview que nous livrons, et là où elle existe, l’audio partirait par le service d’un tiers. La base de connaissances : la vue existe et sait chercher, mais rien dans le produit ne sait écrire les articles qu’elle chercherait.

Lis aussi le reste.

Le copilote est une pièce. La poignée de main qui est dessous, et les trente-huit choses que le client fait sans aucune IA, méritent le même examen.