Automatisations dans Sharkly : stand-ups, triage des bugs et rapports qui se génèrent tout seuls

Chaque équipe d'ingénierie traîne une couche de travail récurrent que personne n'a planifié et que tout le monde finit par payer. Quelqu'un assemble le résumé du standup. Quelqu'un lit chaque rapport de bug entrant et le route. Quelqu'un compile le rapport de statut du vendredi à partir de six onglets d'informations éparpillées. Rien de tout cela n'est difficile. Tout cela est de la corvée : prévisible, répétable et discrètement coûteuse, parce que ça retombe toujours sur la première personne qui s'en aperçoit.

C'est exactement le genre de travail qu'un Agent IA gère bien, à condition que quelque chose démarre l'Agent au bon moment sans qu'une personne ait à taper un prompt. Ce mécanisme de démarrage, ce sont les Automations dans Sharkly. Une Automation est une définition rattachée à un Space pour du travail répétable confié à un Agent ou une Crew : des instructions écrites, un responsable de l'exécution, un ou plusieurs déclencheurs, et un historique des exécutions consultable.

L'objectif n'est pas d'automatiser le jugement. Sharkly le formule sans détour : l'automatisation s'arrête là où le jugement de l'équipe est requis. Une Automation peut rédiger le résumé du standup, faire une première lecture d'un bug et assembler le rapport hebdomadaire. C'est toujours une personne qui décide ce que l'équipe fait de tout cela. Si vous découvrez Sharkly, commencez par ce qu'est Sharkly et revenez ensuite.

TL;DR

Une Automation dans Sharkly est une règle rattachée à un Space qui lance un Agent ou une Crew avec un ensemble fixe d'instructions dès qu'un déclencheur se produit. Il existe quatre types de déclencheurs : une planification (expression cron à cinq champs avec un fuseau horaire), un changement de statut de tâche, un commentaire contenant une phrase configurée, et une URL de webhook secrète pour les services externes, plus un bouton « Exécuter maintenant » pour les tests manuels. Chaque exécution est enregistrée dans l'historique avec sa source, son résultat et la raison d'un éventuel échec, et une Automation peut être mise en pause puis réactivée pendant que vous la modifiez. Utilisez les Automations pour du travail récurrent bien défini : résumés de standup, premier passage de triage des bugs, rapports périodiques. L'Agent lit et rédige ; une personne relit le résultat et tranche.

Ce qu'est une Automation, et ce qu'elle n'est pas

Une Automation stocke la définition courte et complète d'un seul travail répétable : un nom et des instructions décrivant l'objectif, les étapes, les contraintes et le résultat attendu ; le Space qui la porte ; un responsable, c'est-à-dire l'Agent ou la Crew qui exécute le travail ; une priorité ; un statut Actif ou En pause ; un ou plusieurs déclencheurs ; et un historique des exécutions consignant pour chacune sa source, son résultat, l'exécution de l'Agent et la raison d'un éventuel échec.

Deux limites pourraient sinon vous surprendre.

Premièrement, une Automation ne crée pas de Tâche à chaque exécution. Elle lance directement une exécution d'Agent ou de Crew. L'exécution, son résultat et tout échec se retrouvent dans l'historique des exécutions de l'Automation plutôt que dans votre liste de tâches, de sorte que votre tableau ne se remplit pas de Tâches générées par une machine chaque matin à neuf heures.

Deuxièmement, les Automations ne sont pas le canevas de workflows de Sharkly. Un Space dispose de deux surfaces d'automatisation : les Automations, la règle unique décrite ici, et les workflows d'automatisation, un canevas de nœuds de déclenchement et d'action capable d'appeler des connecteurs tiers. Utilisez une Automation quand un Agent ou une Crew doit exécuter un ensemble d'instructions en réponse à un événement prévisible. Utilisez un workflow quand vous avez besoin d'actions multi-étapes ou inter-applications avant que l'Agent n'intervienne.

Comme le responsable est un Agent Sharkly à part entière, tout ce que vous avez déjà configuré sur cet Agent s'applique : ses instructions, son Runtime, ses Skills, ses dépôts et ses paramètres d'exécution. Si vous n'en avez pas encore créé, les Agents dans Sharkly expliquent comment une configuration de travail enregistrée devient quelque chose qu'une équipe peut réutiliser. Une Automation est, en pratique, un rendez-vous récurrent avec cet Agent.

Les quatre types de déclencheurs

Une Automation peut avoir plusieurs déclencheurs, chacun activé ou désactivé indépendamment. Une même définition peut servir plusieurs points d'entrée : les mêmes instructions de triage peuvent se déclencher sur un changement de statut et sur une slash command, sans rien dupliquer.

Planification utilise une expression cron standard à cinq champs et un fuseau horaire, avec des préréglages courants (horaire, quotidien, jours ouvrés, hebdomadaire). C'est le déclencheur à privilégier pour le travail qui doit avoir lieu parce qu'on est mardi, et non parce que quelque chose a changé.

Changement de statut de tâche démarre l'Automation lorsqu'une tâche passe dans un statut d'Organisation sélectionné. Un détail compte : les statuts sont des définitions d'Organisation réutilisables, et la correspondance des événements se fait actuellement à l'échelle de l'Organisation. Si plusieurs Spaces utilisent le même statut « Needs Triage », une transition correspondante dans n'importe lequel d'entre eux peut déclencher votre Automation. Rédigez donc les instructions pour que l'Agent vérifie la tâche à l'origine du déclenchement avant d'agir.

Phrase dans un commentaire démarre une exécution lorsqu'un commentaire de tâche contient une phrase configurée. La correspondance ignore la casse, cherche n'importe où dans le commentaire et écoute elle aussi à l'échelle de l'Organisation. Le conseil de la documentation : préférez une slash command distinctive comme /triage-bug plutôt que « check », et faites valider la tâche déclencheuse par les instructions.

Webhook crée une URL secrète qui accepte un POST provenant d'un service externe. L'URL complète est affichée lors de la création ou de la régénération du déclencheur et n'est plus consultable ensuite, car par défaut l'URL elle-même fait office de secret porteur. Si vous configurez un secret de signature, les requêtes doivent également passer la vérification de signature, le même schéma que GitHub utilise pour ses propres webhooks. Gardez ces secrets hors du contrôle de version et régénérez-les en cas d'exposition. Pour scripter Sharkly au-delà des webhooks, voir la CLI et l'API Sharkly.

Il existe encore une façon de lancer une exécution, qui n'est pas un déclencheur : « Exécuter maintenant » démarre directement l'Automation, ce qui permet de tester les instructions et la disponibilité du responsable avant de confier la tâche aux quatre déclencheurs.

Ce qu'une Automation exécute réellement

Quand un déclencheur se produit, Sharkly lance l'Agent ou la Crew assigné avec les instructions de l'Automation. Ces instructions constituent tout le contrat ; la documentation est donc précise sur ce qu'elles doivent énoncer : le résultat à produire, les entrées à examiner, les étapes à suivre, l'endroit où consigner le résultat, les modifications autorisées, et les cas où une personne doit relire ou décider.

Ce dernier point mérite d'être souligné. Une Automation bien rédigée nomme son propre point d'arrêt. « Rédige le résumé et consigne-le ; ne modifie aucun statut de tâche » est une meilleure instruction qu'une phrase plus longue qui laisse l'autorité ambiguë. Les recommandations de déploiement de la documentation sont tout aussi claires : commencez par du travail observable et réversible, et relisez plusieurs exécutions avant d'élargir le périmètre.

Trois corvées à automatiser en premier

Chacune de ces corvées reste dans les limites que le produit prend en charge : l'Agent lit, rédige et consigne ; les décisions restent aux personnes.

Le résumé quotidien du standup. Déclencheur : une planification, préréglage jours ouvrés, dans le fuseau horaire de l'équipe. Responsable : un Agent de reporting ayant un accès en lecture au contexte pertinent. Instructions : examiner les tâches du Sprint en cours, relever ce qui a avancé, ce qui est bloqué et ce qui attend une revue, puis consigner un résumé court là où l'équipe le lit, sans modifier aucune tâche. L'Agent se charge de la partie du standup que personne n'apprécie, à savoir reconstituer la vue d'ensemble, et le standup devient une conversation sur les deux points qui demandent du jugement. Si votre équipe gère son rythme via Sharkly, les Sprints fournissent la structure que l'Agent examine.

Le premier passage de triage des bugs. Déclencheur : un déclencheur de changement de statut sur votre statut d'entrée des bugs, ou un déclencheur de commentaire sur une phrase distinctive comme /triage, ou les deux. Responsable : un Agent de triage dont les dépôts couvrent le code concerné. Instructions : vérifier que la tâche déclencheuse est bien un bug dans le Space visé, lire le rapport, examiner la zone pertinente du code, puis consigner ce que le bug semble toucher, si le rapport contient assez d'éléments pour agir, et une priorité suggérée avec son raisonnement. Recommander ; ne pas décider. L'étape de vérification n'est pas décorative : comme la correspondance des statuts et des commentaires s'applique à l'échelle de l'Organisation, ce sont vos instructions qui font office de filtre de périmètre. Le bénéfice : chaque bug bénéficie de la même première lecture soignée dans les minutes qui suivent son arrivée. La même répartition des rôles vaut lorsque le travail arrive de l'extérieur de Sharkly ; voir comment un ticket Jira devient le travail d'un Agent.

Le rapport périodique. Déclencheur : une planification, préréglage hebdomadaire. Responsable : le même type d'Agent de reporting, avec des instructions portant sur une fenêtre plus longue : résumer ce qui a été terminé, ce qui a glissé et ce qui est bloqué. La différence avec le cas du standup tient uniquement au périmètre et au public visé, et c'est précisément pour cela que ce travail a sa place dans une Automation. Le rapport qui existe chaque vendredi avec la même qualité vaut mieux que le meilleur rapport qui n'existe que quand quelqu'un a le temps.

Dans les trois cas, remarquez ce qui n'apparaît jamais dans les instructions : accepter, approuver, livrer, clôturer, décider.

Historique des exécutions, état de santé, et mise en pause et reprise

Une automatisation que vous ne pouvez pas inspecter est une automatisation en laquelle vous ne pouvez pas avoir confiance ; c'est pourquoi chaque exécution est enregistrée. L'historique des exécutions indique pour chacune un état Running, Completed, Failed ou Skipped, et le détail permet d'ouvrir la charge utile du déclencheur, l'exécution de l'Agent, la sortie et la raison d'échec enregistrée. Au-dessus des exécutions individuelles, un signal de santé résume le dernier état utile : jamais testé, en cours, sain, ignoré ou nécessite attention.

Une précision à garder en tête, en gras : un statut Completed décrit l'exécution de l'Automation, et ne garantit pas que tous les résultats en aval étaient corrects. Completed signifie que la mécanique a fonctionné. Que le résumé ait été exact ou que l'appréciation de triage ait été pertinente relève toujours d'une lecture humaine.

La mise en pause et la reprise existent exactement pour les moments que vous imaginez. Mettez une Automation en pause pour arrêter les nouvelles exécutions déclenchées pendant que vous révisez ses instructions, ses déclencheurs ou son responsable, puis réactivez-la lorsque la configuration est prête ; entre-temps, la définition et son historique restent en place. La suppression est le seul moyen de retirer une Automation : réservez-la aux définitions dont vous n'avez plus besoin de l'historique. Et avant d'archiver un Agent, vérifiez si des Automations en dépendent encore.

Avant de vous appuyer sur une Automation, la documentation suggère une courte liste de vérifications : lancez-la manuellement avec « Exécuter maintenant », confirmez que l'Agent ou la Crew dispose des accès nécessaires, inspectez l'exécution et sa sortie, testez chaque déclencheur séparément, utilisez un statut étroit ou une phrase de commentaire distinctive, et gardez les secrets de webhook hors du contrôle de version.

Où l'automatisation s'arrête

Il serait facile de conclure que l'objectif est un pipeline sans intervention humaine. Ce n'est pas le cas, et la conception même du produit le dit. Les Automations n'acceptent pas leur propre sortie et elles enregistrent chaque exécution pour relecture.

La règle de décision honnête est donc la suivante. Utilisez une Automation quand le même travail bien défini doit démarrer de façon répétée ou en réponse à un événement prévisible, et quand un premier jet systématique vaut mieux qu'un excellent jet occasionnel. Assignez une Tâche directement à un Agent quand le travail est ponctuel, et laissez le travail entièrement aux personnes quand le travail en question est le jugement lui-même : un arbitrage de priorité sous pression contradictoire, une décision d'acceptation, tout ce pour quoi être systématiquement dans l'erreur est pire qu'être occasionnellement lent.

Commencez petit et sans éclat. Installez-vous, créez un Agent de reporting, écrivez une Automation avec une planification en jours ouvrés et des instructions qui se terminent par « ne modifie aucune tâche », et lancez-la une fois manuellement. Lisez la sortie. Si elle est utile, laissez la planification prendre le relais. La documentation couvre les Automations et le canevas de workflows plus en détail.

FAQ

Quels types de déclencheurs les Automations Sharkly prennent-elles en charge ?

Quatre : une planification utilisant une expression cron à cinq champs avec un fuseau horaire, un déclencheur de statut de tâche qui se produit lorsqu'une tâche passe dans un statut d'Organisation sélectionné, un déclencheur de commentaire qui se produit sur une phrase configurée, et un déclencheur webhook qui accepte un POST sur une URL secrète. Une Automation peut combiner plusieurs déclencheurs, chacun activé ou désactivé indépendamment, et « Exécuter maintenant » lance une exécution manuelle pour tester.

Une Automation crée-t-elle une Tâche à chaque exécution ?

Non. Les Automations actuelles lancent directement des exécutions d'Agent ou de Crew et ne créent pas de Tâche à chaque exécution. L'exécution, sa sortie et toute raison d'échec sont consignées dans l'historique des exécutions de l'Automation. Si vous voulez que le résultat se retrouve là où l'équipe le lit, indiquez-le dans les instructions.

En quoi les Automations diffèrent-elles des workflows d'automatisation ?

Ce sont deux surfaces distinctes dans un Space. Une Automation est une règle unique : quand démarrer, quel Agent ou quelle Crew exécute le travail, et quelles instructions il ou elle suit. Les workflows d'automatisation sont un canevas de nœuds de déclenchement et d'action capables d'appeler des applications tierces via des connecteurs. Utilisez la règle unique pour les vérifications récurrentes et les commandes par commentaire ; utilisez le canevas pour les flux multi-étapes et inter-applications.

Une Automation peut-elle gérer le triage des bugs toute seule ?

Elle peut en gérer le premier passage : vérifier la tâche déclencheuse, lire le rapport, examiner le code pertinent et consigner ses conclusions avec une priorité suggérée. La décision de triage reste à une personne, et les instructions doivent le dire explicitement. La documentation recommande de commencer par du travail observable et réversible et de relire plusieurs exécutions avant d'élargir le périmètre.

Que se passe-t-il lorsqu'une exécution d'Automation échoue ?

L'exécution est enregistrée comme Failed dans l'historique, avec la raison de l'échec lorsqu'elle est disponible, et le signal de santé passe à « nécessite attention ». Ouvrez le détail de l'exécution pour inspecter la charge utile du déclencheur, l'exécution de l'Agent et la sortie, corrigez les instructions, le déclencheur ou le responsable, puis utilisez « Exécuter maintenant » pour vérifier la correction avant de refaire confiance aux déclencheurs.