Automatisations

​

Concepts de base

​

Types d’action

​

Sources de déclenchement

​

Créer une automatisation

​

Depuis la page automatisation

1. Accédez à automatisation dans la barre latérale
2. Cliquez sur Créer une automatisation et choisissez Create pour ouvrir un éditeur vierge (si vous n’avez encore aucune automatisation, cliquez plutôt sur Create manually sur la page d’accueil). Le même menu propose également modèle (ouvre la galerie de modèles) et Generate with Devin (démarre une session qui crée l’automatisation avec vous)
3. Configurez le déclencheur, les conditions et l’action
4. Cliquez sur Créer une automatisation

​

À partir d’un modèle

1. Accédez à Automatisations dans la barre latérale
2. Cliquez sur Créer une automatisation > Modèle (si vous n’avez encore aucune automatisation, cliquez plutôt sur Créer à partir d’un modèle sur la page d’accueil), ou accédez directement à /automations/templates
3. Parcourez la galerie de modèles — chaque modèle est une automatisation préconfigurée pour un workflow courant
4. Cliquez sur un modèle pour préremplir l’éditeur avec son déclencheur, son action et les limites suggérées
5. Personnalisez la configuration (p. ex., sélectionnez votre canal Slack ou votre repo), puis cliquez sur Créer une automatisation

​

Utilisation du langage naturel

​

Configurer les déclencheurs

​

Déclencheurs Slack

• Message Slack : Se déclenche à la publication de nouveaux messages. Une condition de canal est ajoutée par défaut ; vous pouvez la supprimer pour prendre en compte les messages de tous les canaux, mais chaque groupe de conditions doit alors comporter au moins un autre filtre (par exemple le texte du message ou le type d’expéditeur — Include thread replies seul ne suffit pas).
• Groupe d’utilisateurs mentionné : Se déclenche lorsqu’un groupe d’utilisateurs Slack (par exemple @oncall) est mentionné. Sélectionnez le groupe ou saisissez son ID Slack (qui commence par S), puis, si besoin, limitez le déclencheur à des canaux spécifiques.
• Réaction Slack : Se déclenche lorsqu’une réaction emoji spécifique est ajoutée à un message (p. ex. 🚨 pour les incidents). Vous pouvez filtrer par nom de réaction et par canal.

​

Déclencheurs GitHub

• Problème : S’active lors d’événements liés aux problèmes (ouverture, fermeture, réouverture, modification, ajout de libellé).
• Commentaire sur un problème : S’active lorsqu’un commentaire est publié sur une issue GitHub. Généralement utilisé avec une condition starts_with "/devin" pour permettre aux utilisateurs de saisir /devin sur n’importe quel problème afin de déclencher Devin.
• Pull request : S’active lors d’événements de PR (ouverture, synchronisation, etc.).
• Revue de pull request : S’active lorsqu’une revue est soumise sur une PR.
• Commentaire de revue de pull request : S’active pour chaque commentaire de revue.
• Check run (CI) : S’active lorsqu’une vérification CI se termine. Filtrez par conclusion = failure pour corriger automatiquement les builds en échec.
• Push : S’active lors des pushs vers une branche.

​

Déclencheurs GitLab

• Merge request : s’active lors des actions sur une MR (ouverture, fermeture, merge, réouverture, approbation, mise à jour).
• Commentaire de MR : s’active lorsqu’un commentaire (note) est publié sur une merge request, y compris dans les threads de review de diff.
• Problème : s’active lors des actions sur un problème (ouverture, fermeture, réouverture, mise à jour).
• commentaire sur un problème : s’active lorsqu’un commentaire est publié sur un problème.
• Push : s’active lors des pushs vers une branche.
• Pipeline : s’active lorsqu’un pipeline atteint un statut donné — filtrez par statut (par exemple failed) pour corriger automatiquement les pipelines en échec.

​

Déclencheurs Linear

• Problème créé : Se déclenche lorsqu’un nouveau problème est créé dans l’équipe sélectionnée.
• Libellé ajouté : Se déclenche lorsqu’un libellé est appliqué à un problème (p. ex. bug, devin).
• Statut modifié : Se déclenche lorsque le statut d’un problème change (p. ex. déplacement vers “In Progress”).
• Priorité modifiée : Se déclenche lorsque la priorité d’un problème change.
• Assigné : Se déclenche lorsqu’un problème est attribué à quelqu’un.
• Problème déplacé : Se déclenche lorsqu’un problème est déplacé vers une autre équipe — le filtre d’équipe du déclencheur correspond à l’équipe de destination.

​

Déclencheurs Jira

• problème créé : se déclenche lorsqu’un nouveau problème est créé.
• Issue updated : se déclenche lorsque les champs d’un problème sont modifiés.
• libellé ajouté : se déclenche lorsqu’un libellé est appliqué à un problème.
• statut modifié : se déclenche lorsque le statut d’un problème change.
• assigné : se déclenche lorsqu’un problème est assigné à quelqu’un.
• Comment created or edited : se déclenche lorsqu’un commentaire est ajouté ou modifié sur un problème.

​

Déclencheurs de planification

• Récurrent : définissez la fréquence (horaire, quotidienne, hebdomadaire) et l’heure. En arrière-plan, les planifications utilisent le format RRULE d’iCalendar. Choisissez Planification personnalisée pour créer une récurrence personnalisée (répéter toutes les N minutes/heures/jours/semaines/mois) ou saisissez directement une chaîne RRULE brute (par ex. FREQ=WEEKLY;BYDAY=MO;BYHOUR=9;BYMINUTE=0) pour des cadences plus complexes.
• Exécuter une fois : se déclenche une seule fois à une date et une heure futures précises, puis se désactive automatiquement. Utile pour une tâche ponctuelle différée — par ex. « réveiller Devin dans 12 heures pour exécuter une tâche. » Sélectionnez la date et l’heure (par défaut, dans une heure) ; elles doivent se situer dans le futur.

​

Déclencheurs webhook

1. Créez une automatisation avec un déclencheur Webhook
2. Copiez l’URL du webhook et le secret affichés dans la configuration du déclencheur
3. Configurez votre système externe (PagerDuty, Datadog, Sentry ou tout outil personnalisé) pour envoyer des requêtes HTTP POST à cette URL
4. Ajoutez éventuellement un filtre de charge utile — un motif regex auquel le corps de la requête doit correspondre pour que l’automatisation se déclenche

• en-tête X-Webhook-Secret: <secret>
• en-tête Authorization: Bearer <secret>
• paramètre de requête ?secret=<secret>

​

Secret du webhook

curl -X POST '<webhook-url>' \
  -H 'Content-Type: application/json' \
  -H 'X-Webhook-Secret: <secret>' \
  -d '{"test": true}'

​

Vérifications préalables

​

LLM filter

​

Configurer et tester un script de vérification préalable

1. Créez une automatisation ou modifiez-en une existante, puis configurez ses déclencheurs et ses conditions.
2. Cliquez sur Add a step before the agent runs sous la section du déclencheur, puis sélectionnez Run a script dans la carte Before the agent runs.
3. Cliquez sur Edit script, choisissez Python, Node (JavaScript) ou Bash dans le sélecteur d’environnement d’exécution, puis modifiez le script de départ.
4. Si nécessaire, utilisez Select secrets dans l’éditeur de script pour associer des secrets de l’organisation. Seuls les secrets sélectionnés sont injectés en tant que variables d’environnement. Pour enregistrer ou tester un script auquel des secrets sont associés, vous devez disposer de l’autorisation de gérer les secrets de l’organisation.
5. Définissez Timeout (seconds) dans la carte : la valeur par défaut est de 60 secondes et la plage autorisée va de 1 à 300 secondes. Par défaut, le script utilise l’environnement Minimal environment ; si les snapshots de machine sont disponibles, le sélecteur Environment vous permet également de choisir un snapshot de l’organisation contenant vos dépendances.
6. Dans l’éditeur de script, choisissez un événement sous Test against et cliquez sur Run. Vous pouvez tester le script non enregistré sur un exemple d’événement d’un déclencheur configuré, ou sur un événement récent d’une automatisation existante. Examinez le résultat, les log et, pour les éléments émis, l’aperçu indiquant combien seraient exécutés, considérés comme des doublons ou différés.
7. Cliquez sur Save script pour appliquer les modifications de l’éditeur, puis sur Créer une automatisation ou enregistrez l’automatisation pour conserver la configuration.

​

Entrée et production du script

import json
import os

with open(os.environ["EVENT_FILE"]) as f:
    event = json.load(f)

text = event.get("payload", {}).get("text", "")
should_run = "urgent" in text.lower()

with open(os.environ["OUTPUT_FILE"], "w") as f:
    json.dump({"run": should_run, "reason": "Urgency filter"}, f)

​

Éléments du script, état et limites

• Prévention des doublons : l’id d’un élément identifie une unité de travail au sein de cette automatisation, et pas seulement une entité. {"id": "INC-1"} n’est traité qu’une seule fois ; ajoutez une version, par exemple l’horodatage de la dernière mise à jour en amont, pour traiter une nouvelle occurrence de cet incident. Sans id, Preflight identifie l’élément par un hash de son contenu : modifier ce contenu peut donc déclencher une nouvelle exécution.
• Plafond d’éléments par exécution : par défaut, 10 nouveaux éléments au plus sont distribués par exécution ; le plafond maximal du système est de 50. Les éléments au-delà de ce plafond ne sont pas traités et ne sont pas replanifiés automatiquement. La prochaine exécution de votre script doit donc les émettre à nouveau. N’avancez pas un curseur au-delà du travail différé au seul motif qu’il figurait dans votre production.
• Résultats précédents : utilisez LAST_RUN_FILE pour distinguer le travail en cours, réussi, échoué ou ignoré. Un élément dont l’exécution échoue est libéré, de sorte qu’une exécution ultérieure du script puisse l’émettre à nouveau.
• État persistant : pour une même automatisation, les exécutions réelles du script s’effectuent l’une après l’autre. Un script en échec ne fait pas avancer l’état enregistré et ne marque pas les éléments comme traités. Clear state efface à la fois l’état JSON enregistré et l’historique des éléments déjà traités ; après cette réinitialisation, les éléments précédemment traités peuvent de nouveau être exécutés.
• Limites de taille : la source et la production du script sont chacune limitées à 256 Kio, l’état enregistré à 64 Kio et les log capturés à 1 Mio.
• Échecs : un code de sortie non nul, un délai d’expiration dépassé, une production ou un état invalide, ou une défaillance d’infrastructure interrompt cet événement avant l’exécution de ses actions. Le script n’est pas relancé automatiquement pour cet événement ; un déclencheur ultérieur pourra l’exécuter à nouveau.
• Accès réseau : la VM du script applique les restrictions réseau de l’automatisation et le profil de sécurité en vigueur. Par exemple, pour interroger périodiquement un service d’alertes externe, son hôte doit être autorisé. Associer un secret n’accorde pas d’accès réseau.

​

Configurer les actions

​

Démarrer une session

• Prompt : Les instructions que Devin suit. Rédigez-le comme vous rédigeriez un prompt Devin classique.
• Playbook (facultatif) : Utilisez @playbook-name dans votre prompt pour inclure un playbook avec des instructions supplémentaires.
• Tags (facultatif) : Ajoutez des tags aux sessions créées par cette automatisation pour en faciliter le filtrage.

​

Envoyer un message à une session

​

Triage Devin (moniteur)

​

Notification par e-mail

• Toujours — à chaque exécution
• En cas d’échec — uniquement lorsque la session échoue ou rencontre une erreur
• En cas de réussite — uniquement lorsque la session se termine avec succès

​

Limites et garde-fous

​

Limite d’ACU

​

Limite des invocations

​

Mise en file d’attente

• Concurrent runs : nombre maximal d’exécutions simultanées de cette automatisation. Les événements excédentaires sont placés en file d’attente. Une exécution n’est plus comptabilisée dans la limite dès que sa session est terminée et en attente de nouvelles instructions.
• Queue depth : nombre maximal d’événements pouvant être placés en file d’attente. Les événements qui arrivent lorsque la file est pleine sont abandonnés.

​

Politique réseau

​

Intégrations MCP

​

Accès aux outils Slack

​

Activité et suivi

• Les invocations récentes avec leurs horodatages
• Si chaque invocation a réussi ou a été ignorée
• Les liens vers les sessions Devin créées
• Les messages d’erreur des invocations ayant échoué

​

Activation et désactivation

​

Modèles