Chapitre 26 / 39

Agent computer-use — hors périmètre

Statut : Hors-périmètre / différé. Ce chapitre documente une capacité qui n’est explicitement pas incluse dans la livraison. Il existe pour qu’un futur lecteur du manuel comprenne ce qui a été envisagé, ce qui a été décidé, et ce qu’il faudrait pour y revenir.

Ce que décide le principe de la boîte noire.

Le chapitre 14 pose la règle : Sodiwin est en lecture seule pour tout ce que Sodimo fait tourner en dehors. Le seul canal entre Sodiwin et le reste de la pile est le dump CSV quotidien (chapitre 24). Il n’existe pas de chemin d’écriture. Les commandes saisies aujourd’hui le sont encore par un humain, dans l’interface Windows de Sodiwin, sur le poste Windows de Gennevilliers. Rien à ce sujet ne change pendant la mission.

Ce qu’aurait été un agent computer-use.

Un agent computer-use est un programme qui pilote une application graphique comme le ferait une personne — déplacer un curseur, cliquer sur des champs, taper dans des zones de saisie, lire l’écran en retour. Parce que Sodiwin n’offre ni API, ni surface de scripting, ni import en lot que Sodimo puisse utiliser en sécurité, un chemin d’écriture vers Sodiwin passe nécessairement par son interface.

La forme concrète, si elle existait, serait :

Une VM Windows — distincte du poste Sodiwin existant — faisant tourner le client Sodiwin, accessible depuis le harness Fedora via Tailscale. La VM est Windows parce que Sodiwin est Windows ; Fedora ne peut pas faire tourner le client nativement.
Un adaptateur planifié par Paperclip qui lit une commande dans une file et la rejoue comme actions GUI contre la VM.
Un job de smoke-test quotidien à 03:00 UTC — un chemin canary contre une file de commandes vide — qui capture des captures d’écran d’un flux connu-bon et alerte sur une dérive au niveau pixel. Sans cela, une mise à jour de l’interface de Sodiwin casse silencieusement l’adaptateur.
Un modèle d’identité : l’agent s’exécute sous un compte de service Sodiwin unique ; l’attribution d’exécution pour le registre unifié (chapitre 15, Principe 2) vient de la couche adaptateur, pas de Sodiwin lui-même.

Pourquoi ce n’est pas dans le périmètre.

Trois raisons, par ordre de poids.

La valeur est spéculative. Sodimo saisit environ 20 commandes par jour. Un agent à chemin d’écriture qui réussit 90 % du temps est pire que le processus actuel, parce que le mode d’échec à 10 % est une commande mal saisie invisible qui remonte des jours plus tard dans une réclamation client. Les smoke-tests quotidiens détectent la dérive de l’adaptateur ; ils ne détectent pas les erreurs de contenu de commande. Le seuil de confiance pour que l’automatisation soit net-positive est élevé, et l’atteindre coûte plus de temps de mission qu’il n’en économise.

La charge de maintenance n’appartient à personne. L’interface de Sodiwin change sans avertissement quand son éditeur pousse une mise à jour. Chaque changement risque de casser un chemin de clic. Après la livraison, Sodimo n’a personne pour maintenir l’adaptateur. La mission se termine avec un système qui fonctionne ou elle ne se termine pas ; un agent computer-use est un système qui pourrait fonctionner un matin donné, et personne chez Sodimo n’est en position de le vérifier.

Le test statique-à-la-livraison échoue. Le chapitre 15 Principe 1 demande si un composant fonctionne encore si l’ingénieur disparaît demain et que l’upstream publie un changement cassant. Un agent computer-use échoue ce test par construction — l’upstream (Sodiwin) publie des changements d’interface, et le seul correctif est une maintenance manuelle que l’équipe ne peut pas faire.

Ce qu’un futur ingénieur devrait avoir pour revisiter cela.

Si un futur ingénieur décide que le chemin d’écriture vaut la peine d’être construit — peut-être parce que le volume a augmenté et que la saisie manuelle est le goulot d’étranglement — voici la surface de départ.

Un adaptateur Paperclip. Paperclip (chapitre 44) possède déjà les runs d’agents planifiés et le registre d’exécution. Un nouveau type d’adaptateur sodiwin_write s’inscrit dans le pattern existant : lecture de file, exécution d’action, écriture dans le registre.
Un runner Windows. Une VM Windows dédiée, distincte du poste de Florian. Isoler l’agent du flux de travail humain est obligatoire — un hôte partagé signifie qu’une action humaine et une action d’agent peuvent entrer en collision en milieu de flux, avec des résultats indéfinis.
Un smoke-test quotidien à 03:00 UTC. Le smoke-test exécute le chemin canary de bout en bout contre une file vide, capture des captures d’écran, les compare à une baseline versionnée, et alerte en cas d’écart. Sans cela, la dérive est invisible jusqu’à ce qu’une vraie commande tourne mal.
Une surface de rollback dans Sodiwin lui-même. Les commandes saisies par l’agent doivent être identifiables — un tag dans le champ notes ou un code commercial dédié — pour qu’un opérateur puisse interroger et annuler les lignes originaires de l’agent si l’adaptateur se comporte mal.
Deux semaines de mode shadow. Avant que l’adaptateur soit autoritaire, il s’exécute en parallèle avec un humain qui saisit les mêmes commandes, et les deux sont comparés quotidiennement. La parité sur deux semaines est le critère d’entrée.

Effort approximatif : deux à trois semaines d’ingénierie pour un développeur solo qui connaît déjà la pile, plus un mois de stabilisation sous trafic réel.

Traçabilité des décisions. D-091 verrouille le périmètre : nice-to-have, VM Windows (pas Fedora), ne fait pas partie de cette mission. D-141 diffère le choix du modèle cloud-vs-local à une réévaluation post-livraison. D-092, D-142, D-143 esquissent la rampe pilote, la question du mainteneur post-mission, et le smoke-test quotidien — tous différés. Le chapitre 55 (annex des décisions) contient les annotations complètes.