Imagine demander à une IA d’améliorer ton code et recevoir une pull request qui modifie 200 fichiers. C’est la promesse… et le danger de gh-aw, la nouvelle extension CLI de GitHub qui veut remplacer tes fichiers YAML par du langage naturel.
GitHub vient de lâcher ce « prototype de recherche » et le verdict est déjà clair pour moi. Une idée géniale, une exécution dangereuse : fascinant mais à ne surtout pas utiliser en production pour l’instant.
Le mode ‘YOLO’ pour ta CI/CD : pourquoi l’absence de garde-fous est une folie
On va aller droit au but, sur le point qui fait le plus mal. L’outil n’a aucun mode « dry-run ».
Un « dry-run », c’est une simulation. C’est le standard absolu en DevOps qui te permet de voir ce qu’un script va faire avant qu’il ne le fasse. C’est la sécurité qui t’empêche de supprimer la base de données de prod un vendredi soir. Et ici, il n’y en a pas.
Quand tu lances une commande, l’IA exécute. Point. Elle ne te demande pas ton avis, ne te montre pas un aperçu des changements. Tu lui donnes une instruction vague comme « améliore le code », et tu peux te retrouver avec une pull request monstrueuse qui touche à 200 fichiers sans aucune forme de validation préalable.
C’est un déploiement à l’aveugle, piloté par une IA. Donner les clés de ton dépôt à un agent autonome sans pouvoir prévisualiser ses actions, c’est l’équivalent de sauter en parachute sans vérifier s’il est bien plié.
GitHub a beau le qualifier de « prototype de recherche », ce n’est pas une excuse. C’est un avertissement lumineux clignotant en rouge que tu dois prendre au pied de la lettre.
OK, mais concrètement, comment ça marche ?
Le principe est séduisant, il faut l’avouer. Fini de te battre avec l’indentation et la syntaxe obscure du YAML pour tes GitHub Actions.
Avec gh-aw, tu écris simplement ce que tu veux faire dans un fichier Markdown, en langage naturel. Par exemple, au lieu de configurer 50 lignes de YAML pour un linter, tu pourrais écrire « Lance ESLint sur tous les fichiers JavaScript et corrige les erreurs automatiquement ».
L’extension prend alors ton instruction, la file à un agent IA (Copilot, Claude d’Anthropic, etc.), qui analyse le code de ton dépôt et génère directement une pull request avec les modifications. C’est simple, c’est direct.
Petit détail qui n’en est pas un : ce n’est pas magique et ce n’est pas gratuit. C’est à toi de fournir tes propres clés d’API pour les modèles d’IA que tu utilises, et donc de payer la facture. L’outil n’est qu’une interface.
Voici un exemple simple et (relativement) sans danger :
# Corrige les fautes de frappe dans le README
gh-aw -f "Fix any typos in the README.md file and commit the changes."
Et maintenant, l’exemple qui devrait te faire peur :
# L'instruction vague qui peut mettre le feu à ton projet
gh-aw -f "Refactor the user authentication module to be more performant and add better error handling."
Avec la deuxième commande, bonne chance pour relire la PR de 200 fichiers et t’assurer que l’IA n’a pas introduit une faille de sécurité majeure.
La vraie question : est-ce le début de la fin pour le YAML ?
Même si gh-aw est aujourd’hui un jouet dangereux, il faut regarder plus loin. La vraie révolution n’est pas l’outil lui-même, mais l’idée qu’il représente : abstraire la complexité des pipelines CI/CD.
Soyons honnêtes, qui aime vraiment écrire et maintenir des fichiers YAML de 500 lignes ? C’est une tâche rébarbative, source d’erreurs, que beaucoup de développeurs détestent. Cet outil s’attaque à un vrai point de douleur.
Il ne faut donc pas voir gh-aw comme la solution finale, mais comme un signal fort envoyé par GitHub. L’avenir de l’automatisation et du DevOps passera de plus en plus par des interfaces en langage naturel. On va vers un futur où tu pourras « discuter » avec ton pipeline pour le configurer.
Une démo technique brillante, un outil irresponsable
Honnêtement, je suis partagé. D’un côté, la vision me passionne. L’idée de piloter ma CI/CD avec de simples phrases est excitante. De l’autre, la mise en œuvre actuelle me fait froid dans le dos.
Alors soyons clairs : n’utilise JAMAIS cet outil sur un dépôt important. Considère-le comme un jouet, un truc à tester sur un projet perso que tu es prêt à casser pour voir ce qu’il se passe. C’est une expérience de pensée, rien de plus.
Le vrai game-changer, ce n’est pas gh-aw. Ce sera l’outil qui reprendra cette idée, mais en y intégrant les garde-fous indispensables : un mode « dry-run » obligatoire, des validations, une interface de prévisualisation claire. Le jour où cet outil existera, on pourra vraiment commencer à parler de la mort du YAML.
Pour l’instant, gh-aw est surtout une preuve de concept qui montre tout ce qui peut mal tourner quand on donne les clés du code à une IA sans aucune surveillance.
