Comment faire écrire des rapports et analyser du code à GitHub Actions en texte brut

Imaginez que vous arriviez au travail le matin, ouvriez GitHub, et qu'une Issue bien rangée vous y attende déjà avec un résumé de toutes les discussions de la veille, une liste des bugs critiques, et même un plan de travail pour la journée. Et tout cela n'a pas été fait par votre stagiaire, mais par un agent automatisé à qui vous avez simplement écrit une note en Markdown.

Ça ressemble à un scénario du futur ? En réalité, c'est déjà une réalité que GitHub teste activement dans le cadre du projet gh-aw (Agentic Workflows). Comprenons pourquoi cela pourrait changer à jamais la façon dont nous écrivons les pipelines CI/CD.

Que sont les Agentic Workflows et pourquoi en avons-nous besoin

D'ordinaire, configurer GitHub Actions implique d'écrire des configs YAML où vous instruisez le système étape par étape : « télécharger le dépôt », « installer les dépendances », « exécuter le script ». Cela fonctionne très bien pour les tâches prévisibles, mais s'avère insuffisant face à quelque chose de créatif ou d'analytique.

Le projet gh-aw propose une approche différente. Au lieu d'écrire un algorithme rigide, vous décrivez la tâche en langage naturel. Une extension CLI spéciale convertit votre fichier Markdown en un Workflow complet, où un agent IA (par exemple Copilot ou Claude) travaille en coulisses. Il décide seul quelles données du dépôt il doit lire, comment les analyser, et quel résultat produire.

C'est l'outil idéal pour ceux qui veulent automatiser les routines « humaines » : rédaction de rapports, vérification de la pertinence de la documentation, ou tri initial des tickets.

Comment ça fonctionne en pratique

Le meilleur ici, c'est la faible barrière à l'entrée. Vous n'avez pas besoin d'être expert en Prompt Engineering ni de connaître profondément l'API GitHub.

Voici un exemple de ce à quoi ressemble une description de tâche :

---
on:
  schedule: daily
permissions:
  contents: read
  issues: read
  pull-requests: read
safe-outputs:
  create-issue:
    title-prefix: "[team-status] "
    labels: [report, daily-status]
    close-older-issues: true
---

## Daily Issues Report

Создай бодрый ежедневный отчет для команды в виде GitHub issue. 
Проанализируй открытые задачи и выдели самые важные.

Quand ce workflow s'exécute, l'agent entre dans votre dépôt, « lit » les derniers événements, et crée une Issue. Notez qu'en bloc safe-outputs nous limitons clairement les permissions de l'agent : il peut créer des tickets, mais seulement avec un préfixe et des tags spécifiques. Ce n'est pas une « boîte noire » avec un accès complet, mais un assistant contrôlé.

Les trois piliers de la sécurité : pourquoi l'agent ne supprimera pas votre prod

Quand nous donnons à un réseau neuronal l'accès au code, la première question qui vient est « Est-ce que ça ne va pas causer des problèmes ? ». Les développeurs de GitHub Next ont accordé une attention considérable à cela :

1. Principe du moindre privilège : par défaut, l'agent n'a que des permissions en lecture. Pour qu'il puisse écrire quelque chose (créer une PR ou une Issue), vous devez l'autoriser explicitement dans la config.
2. Sandboxing : toutes les actions sont exécutées dans des conteneurs isolés. L'agent ne peut pas simplement « s'échapper » vers votre infrastructure.
3. Firewall réseau (AWF) : dans l'écosystème du projet, il y a un composant spécial — Agent Workflow Firewall. Il contrôle vers où l'agent essaie d'envoyer des données vers le monde extérieur, prévenant ainsi les fuites.

Ce que l'écosystème gh-aw peut encore faire

Le projet ne se limite pas au simple CLI. C'est une infrastructure entière pour créer des assistants intelligents :

• MCP Gateway : permet de connecter des outils externes via le Model Context Protocol. Cela signifie que votre agent peut non seulement lire GitHub, mais aussi regarder dans d'autres services si vous lui en donnez la capacité.
• The Agentics : une collection de composants et de templates prêts à l'emploi. Pas besoin de réinventer la roue — vous pouvez prendre des « blocs de construction » tout faits pour les tâches typiques.
• Validation à la compilation : le système vérifie votre fichier Markdown avant l'exécution pour s'assurer que l'agent comprend les instructions et dispose des permissions nécessaires.

Qui trouvera cela utile dès aujourd'hui

Dans ma pratique, je rencontre souvent des tâches qui sont « trop complexes pour Bash, mais trop ennuyeuses pour un humain ».

Par exemple :

• Maintenance de la documentation : un agent peut vérifier chaque semaine si les signatures de fonctions dans le code ont changé, et si le README est obsolète — suggérer des modifications.
• Analyse de sentiment : dans les grands projets Open Source, un agent peut surveiller les commentaires et mettre en évidence pour les mainteneurs les discussions où le niveau de toxicité ou d'insatisfaction augmente.
• Génération de changelog : au lieu de tenter douloureusement de se souvenir de ce qu'on a programmé pendant le mois, on peut demander à l'agent de compiler une belle liste de changements basée sur les merge requests.

Conclusion : est-ce que ça vaut le coup d'essayer ?

Les GitHub Agentic Workflows sont encore un territoire expérimental (comme l'avertit honnêtement la bannière WARNING dans le dépôt). Cependant, c'est sans doute l'approche la plus mature d'intégration de l'IA dans la CI/CD aujourd'hui.

Si vous êtes fatigué des rapports répétitifs ou voulez ajouter un peu de « cervelle » à votre dépôt, ça vaut définitivement le coup d'installer gh aw et d'essayer d'exécuter au moins un rapport simple. C'est un excellent moyen de sentir comment l'IA passe de jouet à véritable outil de travail pour développeur.

Prêt à déléguer une partie de votre travail à un bot ? Jetez un œil à Peli's Agent Factory — il y a de nombreux exemples inspirants de ce que ces agents peuvent déjà faire.