· Nolwen Brosson · Blog  · 6 min read

De 0 à 1 : construire un agent Ops qui synchronise Tickets, Slack, Notion et GitLab

Un agent “ops” utile, ce n’est pas un chatbot qui “répond”. C’est un système qui exécute proprement des actions : créer et mettre à jour des tickets, notifier sur Slack, tenir une page Notion à jour, ouvrir ou commenter une issue/MR GitLab, et surtout garder la cohérence entre tout ça.

Le vrai challenge n’est pas l’IA. C’est l’orchestration, la fiabilité, et la gestion des effets de bord. Et pour bien mettre cela en place, avoir une méthodologie clair change tout.

Définir le périmètre de l’agent Ops

Avant de coder, listez clairement ce que l’agent a le droit de faire.

Cas d’usage typiques

  • Incident : un message Slack “P1 API down” crée un ticket, une page Notion “Incident”, une issue GitLab et alimente un fil Slack avec les mises à jour.
  • Support : un ticket “bug” passe en “In progress” quand une issue GitLab est liée, puis en “Done” au merge.
  • Runbook : l’agent propose des étapes et coche automatiquement dans Notion ce qui a été fait.

Règle d’or : un seul “source of truth”

Choisissez une vérité centrale par type d’objet :

  • Statut de travail : souvent le ticket (Jira/Linear, ou autre).
  • Documentation / post-mortem : Notion.
  • Travail de dev : GitLab issues/MR.
  • Communication : Slack.

Vous pouvez synchroniser, mais évitez d’avoir 4 endroits qui “décident” du statut.

Architecture recommandée d’un agent Ops

Pour tenir dans la durée, pensez “produit” : observabilité, audit, sécurité, et retries.

Un moteur d’événements, pas un script

L’idée est d’éviter un long script qui risque de planter réguliérement. Des solutions comme Make ou n8n sont parfaitement adaptées. Une architecture simple et robuste ressemble à ça :

  1. Ingestion : webhooks (GitLab), events Slack, API tickets, Notion.
  2. Normalisation : convertir tout en événements internes (“TicketUpdated”, “MRMerged”, “SlackMessageTaggedP1”).
  3. Décision : règles + éventuellement LLM (pour classer, extraire, résumer).
  4. Exécution : actions idempotentes vers Slack/Notion/GitLab/tickets.
  5. Traçabilité : journal d’exécution, état, corrélation.

Schéma minimal des données

  • event_id (unique) + source (slack/gitlab/notion/ticketing)
  • correlation_id (ex : incident-2026-001)
  • entity_map (table de correspondance) :
    • incident-2026-001 ↔ ticket #123 ↔ notion page id ↔ slack thread ts ↔ gitlab issue #456
  • execution_log : action, timestamp, résultat, retry_count

Cette “entity_map” est souvent le cœur du système. On peut stocker ces informations sur une base de donnée postgres ou mongoDB par exemple.

Intégrations : comment relier Slack, Notion, GitLab et vos tickets

Slack : le point d’entrée humain

  • Utilisez des slash commands (ex : /incident P1 API down) ou des réactions (emoji) pour déclencher.
  • Répondez dans un thread unique pour éviter le bruit.
  • Stockez le thread_ts comme identifiant de discussion.

GitLab : l’automatisation côté dev

Gagner quelques minutes à chaque fois qu’un bug se produit.

  • Webhooks : issue created/updated, MR opened/merged, pipeline status.
  • Bonnes pratiques :
    • Ajoutez un label ou un champ “correlation_id”.
    • Commentez automatiquement avec un résumé court + lien vers Notion + lien ticket.

Notion : la mémoire et le suivi

  • Créez une page “Incident” ou “Projet” avec un template.
  • Mettez à jour des propriétés structurées (statut, owner, sévérité) plutôt que d’écrire du texte partout.
  • Ajoutez un bloc “Timeline” alimenté par l’agent (événements horodatés).

Tickets (côté Produit)

  • Le ticket doit contenir les liens vers Slack/Notion/GitLab.
  • Les transitions de statut doivent être déterministes (ex : “MR merged” → “Ready for QA”).

Le rôle du LLM

L’IA est top pour :

  • classifier (incident vs question vs bug)
  • extraire des champs (sévérité, service impacté, client)
  • résumer un thread Slack en 5 lignes
  • proposer une checklist de runbook

Mais ne lui déléguez pas trop de décisions. La logique d’état (statuts, transitions, permissions) doit rester dans votre code.

Pièges classiques à éviter

Là où la plupart des agents “marchent en démo” mais cassent en prod.

Piège 1 : les boucles de synchronisation

Exemple :

  • GitLab envoie “issue updated” → l’agent met à jour le ticket → le ticket envoie “ticket updated” → l’agent met à jour GitLab… et ça tourne.

Solutions

  • Ajoutez un champ “updated_by=agent” ou un tag “automation=true”.
  • Filtrez les événements entrants qui portent votre signature.
  • Utilisez des règles : “Slack ne met à jour que le ticket”, “GitLab ne met à jour que le champ dev”, etc.

Piège 2 : les doublons (événements répétés, retries, webhooks)

Les webhooks peuvent être livrés plusieurs fois. Vos workers vont retry. Slack peut renvoyer des events.

Solutions

  • Déduplication par event_id (stockez-les 7 à 30 jours).
  • Déduplication métier : “si le commentaire GitLab existe déjà, ne pas le republier”.
  • “Entity map” obligatoire : si l’incident existe, on met à jour, on ne recrée pas.

Piège 3 : l’idempotence (la compétence qui sépare un POC d’un produit)

Une action idempotente peut être rejouée N fois sans créer d’effets indésirables.

Exemples concrets

  • “Créer une page Notion” n’est pas idempotent par défaut (ça recrée).
  • “Mettre à jour une propriété de page Notion” peut l’être si vous ciblez l’ID.
  • “Poster un message Slack” n’est pas idempotent, sauf si vous utilisez un message “upsert” (ex : stocker le ts et éditer).

Patterns d’idempotence

  • Upsert : “si l’objet existe, update, sinon create”.
  • Idempotency key : action_key = correlation_id + action_type + target.
  • Compare-and-set : ne modifiez que si la valeur cible est différente.
  • Outbox pattern : enregistrez l’intention avant d’exécuter, puis marquez “done”.

Piège 4 : l’ordre des événements

GitLab peut envoyer “pipeline failed” puis “MR merged” selon latences et retries.

Solutions

  • Traitement asynchrone + état final calculé.
  • Stockez un “last_seen_at” par source.
  • Recalculez le statut à partir de l’état global, pas uniquement de l’événement courant.

Checklist “De 0 à 1” pour livrer un agent fiable

MVP solide (à viser)

  • Déclenchement Slack (commande ou réaction)
  • Création ticket + page Notion + issue GitLab
  • Liens croisés partout
  • Thread Slack unique pour les updates
  • Table de mapping (correlation_id) + logs d’exécution
  • Déduplication + idempotency keys

V2 (qui change la vie)

  • Résumés automatiques (thread Slack → Notion)
  • Mise à jour bidirectionnelle contrôlée (sans boucle)
  • Playbooks/runbooks par type d’incident
  • Observabilité : métriques, alertes, dead-letter queue

Conclusion

Construire un agent Ops, c’est surtout construire un système de synchronisation fiable entre outils. Si vous prenez au sérieux boucles, doublons et idempotence dès le début, vous évitez 80% des “phantom updates” et des tickets fermés trop tôt.

Chez Fenxi Technologies, on voit souvent la même trajectoire : un POC en 2 jours, puis 2 mois à rendre le système sûr et maintenable. La bonne nouvelle : avec une architecture événementielle simple, une table de mapping, et des actions idempotentes, on peut passer de 0 à 1 sans se tirer une balle dans le pied.

    Share:
    Back to Blog