Depuis l’interface projet, connectez le dépôt (OAuth ou installation). Vérifiez que le dépôt s’affiche et que les tokens sont présents ou que l’installation App est valide.

Demandez l’indexation/scan du dépôt. Le serveur va parcourir les fichiers autorisés, extraire le contenu pertinent et construire un index de recherche/code. :

Après l’indexation, le serveur construit un contexte global (index des fonctions/classes, cartographie du code) utile aux Agents pour compréhension et RAG. :

Lors de l’onboarding, un webhook est créé côté fournisseur (GitHub/GitLab) pointant sur le gestionnaire d’événements du projet. Vérifiez la présence du secret de webhook et les événements abonnés (push, pull_request). :

Contrôlez le journal d’indexation et confirmez que les fichiers importants ont bien été indexés. Résolvez les erreurs d’accès si certaines branches/fichiers sont manquants.

Le serveur reçoit l’événement, vérifie l’authenticité (signature / token), puis normalise l’URL du dépôt et la branche ciblée (p. ex. extraire ‘feature/x’ depuis la référence). :

Le serveur identifie le dépôt dans votre projet (configuration et tokens associés). Si le dépôt n’est pas connu, l’événement est ignoré et loggé. :

Si une branche de synchronisation est configurée pour le dépôt, comparer la branche de l’événement à celle-ci. Si elles diffèrent, arrêter le traitement. :

Le serveur obtient la différence entre commits (base → head) et extrait la liste des fichiers ajoutés ou modifiés pour la suite du traitement. :

Les fichiers modifiés sont re-indexés et synchronisés avec le moteur de recherche/vectoriel pour que le contexte soit à jour. :

Rassembler un objet événement contenant : type (push), branche, commits (messages & id), auteur, liste des fichiers modifiés, timestamp. Ce contexte est partagé avec les hooks/agents. :

Récupérer les hooks du projet configurés pour ce type d’événement (push) et les filtrer en appliquant les règles (branche, fichiers, auteur). :

Pour chaque hook, évaluer s’il doit déclencher en fonction des filtres (branche, patrons de fichiers, auteur). Ne transmettre que les hooks qui passent les filtres. :

Les hooks validés démarrent soit une exécution immédiate d’un Agent (si configuré pour exécution instantanée) soit sont mis en file pour des workers qui exécuteront le pipeline. :

Consigner l’exécution, envoyer notifications (si configurées) et mettre à jour les métriques (consommation de crédits, statut d’exécution). :

Extraire la branche source, la branche cible, l’auteur, la description du PR et la liste des commits / fichiers modifiés. :

Si le hook cible uniquement des PR vers une branche spécifique (p. ex. main), vérifier la branche cible du PR. :

Comme pour les pushs, seuls les hooks qui correspondent aux patterns de fichiers ou aux auteurs configurés sont retenus. :

Les agents peuvent produire résumés, propositions de mise à jour de documentation, checklists ou suggestions automatiques pour le PR. :

Si configuré, le résultat peut être posté comme commentaire sur la PR, envoyé par email ou envoyé vers une destination externe. :

Règle simple : si le hook a une liste de branches, l’événement doit appartenir à l’une d’elles. Si aucune branche configurée, considérer “toutes branches” par défaut. :

Les hooks peuvent contenir des patterns (globs, préfixes). L’événement doit avoir au moins un fichier modifié correspondant au pattern pour valider le hook. :

Vous pouvez limiter aux commits d’un auteur (nom, username ou email). Attention aux variations d’email/username (expliquer ci-dessous). :

Types de combinaison fréquents : AND (tous les filtres doivent passer) ou OR (un seul suffit). Vérifiez le mode combinatoire défini pour le hook. :

Pour éviter déclenchements répétés sur de très courts laps de temps, activer un mécanisme qui dé-duplique ou agrège plusieurs pushes proches avant d’exécuter les agents. :

Les fréquences sont exprimées en paire : nombre (frequency_count) + unité (frequency_duration, ex. minutes, hours, days). Le serveur calcule la prochaine date d’exécution en fonction de ces valeurs. :

Exemple : frequency_count=3 et frequency_duration=‘days’ → la prochaine exécution = maintenant + 3 jours. Le calcul se fait côté serveur pour cohérence. :

Un scheduler côté serveur identifie les hooks “dus” et crée des jobs que des workers vont consommer et exécuter. :

Les workers exécutent les agents/pipelines, mettent à jour le statut et recalculent la prochaine exécution selon la paire fréquence. :

Pour désactiver un hook : modifier sa configuration (fréquence à null) ou supprimer le hook. Les workers ignorent automatiquement les hooks supprimés. :

Chaque exécution d’agent peut consommer des crédits. Surveillez la facturation et les quotas ; ajustez les fréquences pour optimiser coûts / valeur. :

Le serveur signale les erreurs d’accès (token manquant / expiré / permissions insuffisantes) dans les logs et notifications de projet. :

Suivez la procédure d’authentification du dépôt pour rafraîchir les tokens ou ré-installer l’application fournisseur. L’interface propose généralement une action de ré-authentification. :

Après ré-authentification, relancez manuellement la synchronisation ou laissez le scheduler/workers reprendre les jobs échoués selon la configuration. :

Inspectez la liste des hooks failés et supprimez/ajustez ceux qui provoquent des erreurs récurrentes (ex : patterns incorrects ou destination invalide). :