Le rapport de tests du matin peut être prêt avant d’ouvrir Open WebUI

Lundi à 8 h 30, une développeuse ouvre les résultats des tests de la nuit. Trois tâches sont en rouge. La première a perdu sa connexion à la base de test, la deuxième a rencontré un dépassement de délai intermittent et la troisième a échoué sur une assertion dans le code modifié vendredi. Trier ces résultats prend plus de temps que repérer les indicateurs rouges. Un agent de code exécuté régulièrement pourrait laisser un bref rapport dans le chat, avec l’assertion en échec et son extrait de journal en tête.

Open WebUI, interface de discussion auto-hébergeable pour modèles et outils d’IA, prend en charge les agents de code dans les automatisations planifiées à partir de la v0.13.3. GitHub date la publication du 8 novembre 2026 à 23 h 48 UTC. Une automatisation peut enregistrer un terminal, un répertoire de travail et un agent disponible dans ce terminal, puis transmettre ses résultats à un chat. Le calendrier démarre ainsi une tâche dans un environnement précis, ce qui rend le rapport matinal réalisable. Notes de version d’Open WebUI v0.13.3

Le premier travail à planifier peut être un rapport vérifiable en quelques minutes. L’automatisation réunit les éléments de preuve et laisse la décision suivante à la personne responsable du projet. Une fois ce rapport répétable et utile, il devient un point de référence pour décider si une permission de plus se justifie.

L’automatisation mémorise l’environnement de travail de l’agent

Open WebUI prend déjà en charge les consignes récurrentes. Une exécution démarre un chat via le processus normal de génération. Les réglages du modèle, les outils, les filtres et les paramètres de mémoire applicables peuvent donc intervenir. La version 0.13.3 ajoute la sélection d’un agent de code détecté dans un terminal. Après choix du terminal, le sélecteur affiche les combinaisons disponibles au format agent/modèle. Changer de terminal ou de dossier peut modifier cette liste. Open WebUI vérifie que le terminal et l’agent enregistrés sont disponibles avant le lancement. Si l’un a disparu, l’exécution échoue et le propriétaire peut consulter le journal. Documentation des automatisations Open WebUI

Le planificateur lance un chat avec les paramètres enregistrés. Illustration originale de Telli.sh d’après les notes d’Open WebUI v0.13.3.

Le répertoire de travail répond à une question banale aux conséquences parfois coûteuses. Quelle copie du dépôt l’agent doit-il lire lorsque deux projets ont des noms de fichiers semblables, ou qu’un projet a une branche de fonctionnalité et une branche de publication sur le disque ? Un chemin explicite fait démarrer le travail au bon endroit et donne une référence à contrôler. Il reste un point de départ. Les permissions, les fichiers accessibles, les variables d’environnement, le réseau et le comportement de l’agent déterminent ce que l’exécution peut atteindre ensuite.

Les résultats ont aussi une destination définie. Les automatisations d’agents de code publient dans le chat. Les notes de version les distinguent des automatisations de modèles ordinaires, qui peuvent viser des canaux. Un historique et un chat suffisent à une personne pour relire le rapport du matin. Une équipe qui souhaite une alerte commune doit décider quelles informations partager, où et avec qui, y compris pour les journaux d’origine. Il faut aussi une personne responsable qui sait où regarder si le travail planifié échoue. Notes de version d’Open WebUI v0.13.3

Fournir au premier travail des entrées modestes et vérifiables

Pour le rapport du lundi, commencez avec une copie du dernier résumé nocturne, un identifiant de commit généré automatiquement et quelques journaux d’échec. Un export d’artefacts de CI ou une copie manuelle dans un dossier temporaire donne une entrée stable. Chaque fichier doit contenir assez de contexte pour rattacher l’échec à une tâche et à un commit. Retirez les secrets évidents et les journaux sans rapport. Un nom de fichier convenu et un horodatage vérifiable évitent à l’agent de deviner la version la plus récente.

Demandez trois éléments dans une réponse. D’abord les échecs qui méritent une intervention. Ensuite les problèmes d’environnement ou les échecs dont la cause reste ouverte. Enfin un lien ou un chemin vers la source de chaque élément. Gardez un format court à comparer avec la vue CI. Un travail qui crée six copies du même ticket parce qu’un test apparaît dans six exécutions de la matrice transforme une petite lecture en un gros problème de relecture.

Une consigne utile décrit ce que la sortie doit préserver. Voici un exemple avec des fichiers de test, une référence de commit et un résumé exporté. Le dossier et les fichiers servent d’illustration.

Lisez le résumé de tests exporté et les extraits d’échec du dossier de projet attribué. Commencez par l’identifiant d’exécution, le commit et l’horodatage issus de l’entrée. Regroupez les échecs répétés dans la matrice. Pour chaque échec distinct, donnez le nom du test, le plus court extrait utile et le chemin de la source. Distinguez les échecs explicites des causes possibles. Si le résumé manque, est périmé ou incomplet, indiquez l’entrée manquante et arrêtez-vous. Laissez les fichiers tels quels.

Ces instructions réduisent l’ambiguïté. Le terminal doit encore avoir les permissions adaptées. Si le travail se limite à la lecture, donnez-lui une vue en lecture seule ou une copie temporaire sans accès au dépôt. Un test en échec peut imprimer n’importe quel texte provenant d’un fichier source, d’une dépendance ou de données de test. Ce texte fait partie des éléments à examiner. Il n’a pas à devenir une instruction pour l’agent. Cette séparation compte davantage lorsqu’une exécution démarre avant le réveil de sa responsable.

Le même dispositif peut servir à une deuxième tâche régulière. Une responsable technique fournit un inventaire daté des dépendances et un flux d’avis obtenu séparément, puis demande de relever les versions potentiellement concernées et de citer les fiches correspondantes. La sortie utile est une liste indiquant le paquet, la version et la source. Un outil de confiance peut faire les rapprochements déterministes et la personne chargée de relire peut vérifier si le chemin concerné est accessible. Des fichiers stables facilitent aussi la reproduction lorsque l’explication varie d’une exécution à l’autre.

Une courte configuration révèle l’essentiel du travail

Open WebUI documente un interrupteur global pour les automatisations et une permission distincte pour les comptes non administrateurs. Vérifiez que l’instance utilise la v0.13.3 ou une version ultérieure compatible, que la fonction est activée et que le compte y accède. Le terminal doit être connecté et autorisé dans le contexte des automatisations. Il peut apparaître dans l’éditeur de modèles tout en étant exclu des tâches automatiques par sa configuration. Cela peut expliquer pourquoi le travail fonctionne en chat ordinaire et échoue sur son calendrier. Automatisations Open WebUI · Documentation de connexion à Open Terminal

1. Préparer des données de test. Placez une exécution réussie, un échec représentatif et un manifeste avec commit et horodatage dans un espace temporaire. Gardez des entrées courtes et laissez hors de l’espace les clés de production, la configuration cloud et les fichiers personnels.
2. Ouvrir les automatisations et créer une tâche. Renseignez le titre, la consigne, le modèle et le calendrier. Dans l’éditeur, choisissez le terminal, indiquez le répertoire de travail et sélectionnez l’agent de code. Laissez à l’environnement le temps d’annoncer les agents disponibles dans le dossier.
3. Lancer une fois depuis l’éditeur. Ouvrez le chat obtenu et le journal d’exécution. Contrôlez le commit, les fichiers sources, le regroupement des doublons et les permissions. Comparez le résultat à l’artefact original et vérifiez que l’arborescence source reste propre.
4. Tester un cas négatif. Retirez le manifeste d’un autre jeu d’essai ou utilisez une entrée volontairement ancienne. Le rapport doit montrer ce qui manque. Vérifiez qu’un terminal indisponible pour les automatisations apparaît comme un échec dans l’historique.
5. Fixer le créneau et relire les premiers résultats. Comparez le calendrier avec l’heure de fin de l’export CI. Un rapport qui démarre trop tôt et relit les résultats de la veille a un problème de calendrier même si son texte paraît actuel. Mettez la tâche en pause si les entrées changent ou si les résultats commencent à dériver.

Traitez le jeu d’essai et la consigne de rapport comme une paire. Si vous renommez le dossier, changez de convention de branche ou déplacez un test, mettez les données d’essai à jour avec la tâche. Cela évite de perdre silencieusement les éléments qui servent au regroupement. Lorsqu’une personne modifie la consigne, gardez l’ancien exemple et comparez les deux sorties sur la même entrée. La correction la moins coûteuse est souvent un manifeste plus précis, surtout si deux travaux planifiés doivent s’accorder sur la dernière exécution.

Choisir un terminal revient à définir une limite d’accès

Une interface auto-hébergée peut appeler un modèle ou un agent fourni par un tiers. Examinez le fournisseur de l’agent choisi, les données qu’il reçoit et les identifiants de service à sa disposition. Une copie du dépôt dans un conteneur ou un espace jetable permet de limiter le travail. Le répertoire de départ protège peu si le même compte accède au reste de la machine ou si l’agent dispose d’un droit d’écriture sur le dépôt. La documentation du terminal décrit plusieurs contextes d’utilisation, dont celui des automatisations. Les administrateurs peuvent ainsi limiter l’exposition avant le démarrage. Documentation de connexion du terminal Open WebUI

Un rapport en lecture seule sépare les preuves, les permissions d’exécution et la décision de relecture. Illustration originale de Telli.sh.

Le gain est le temps entre l’ouverture des résultats et le moment où l’on sait où regarder. Une commande fiable peut faire une grande partie du travail. Faites-lui produire l’identifiant et l’état de l’exécution, puis laissez l’agent expliquer les échecs entre plusieurs types de sorties. Ce partage facilite le diagnostic. Comparez l’identifiant annoncé au manifeste pour vérifier l’entrée avant d’essayer un autre agent.

Le coût fait partie du même contrôle. Les tâches planifiées peuvent consommer un quota payant si l’agent appelle un modèle facturé. De longs journaux gonflent les entrées et des échecs répétés peuvent provoquer des analyses répétées. Mesurez d’abord l’utilité d’un extrait limité sur quelques exécutions. Si chaque exécution traite les mêmes gros fichiers, faites consigner les changements par une étape déterministe peu coûteuse. Une exécution quotidienne devient prévisible lorsque le volume d’entrée a une limite connue.

Pour une petite équipe, la responsabilité compte autant que le terminal. La documentation indique qu’une automatisation appartient à la personne qui l’a créée et lui reste privée. Un rapport personnel peut y rester. Une validation de publication utilisée par plusieurs personnes a besoin d’un processus visible pour transmettre les preuves et la responsabilité en cas d’absence. L’historique d’une automatisation peut aider une personne à diagnostiquer une panne. Un contrôle CI partagé rend la décision visible à l’équipe qui publie. Contrôles d’accès des automatisations Open WebUI

Le rapport du matin doit faire ses preuves à la relecture

Après la première semaine, regardez les rapports qu’une personne a vraiment ouverts. Vérifiez le lien ou l’extrait de chaque point urgent. Comptez les résumés qui ont raté un échec, répété un cas connu ou cité le mauvais commit. Demandez si le rapport a aidé à trouver le prochain test à examiner. Cela renseigne davantage sur le calendrier que le nombre de réponses automatiques.

Si la sortie reste utile, ajoutez un type de preuve à la fois. Donnez au terminal un emplacement stable, limitez les identifiants et laissez les modifications de code ou d’infrastructure passer par la revue habituelle de l’équipe. Le meilleur signe de progrès est un rapport assez fiable pour agir et assez simple à vérifier dès qu’un résultat paraît douteux.

Sources

• Notes de version d’Open WebUI v0.13.3
• Configuration, permissions et historique des automatisations Open WebUI
• Connexions et contextes des terminaux Open WebUI

---

Pour retrouver les conversations et décisions qui ont guidé votre travail, créez un compte Telli.sh.