FrogGPT : notre premier agent IA, quand les agents n’existaient pas encore

Début 2023, ChatGPT venait d’ouvrir son API et tout le monde découvrait à peine ce qu’un grand modèle de langage pouvait faire. Le mot « agent » n’avait pas encore le sens qu’on lui donne aujourd’hui : il n’existait ni framework, ni outillage, ni bonnes pratiques établies pour faire travailler un LLM de façon autonome sur une tâche réelle. Chez Red Froggy, nous avons eu envie de tester une idée simple en apparence : et si ChatGPT pouvait prendre un ticket Jira, comprendre la demande, écrire le code correspondant et ouvrir la merge request tout seul ?

C’est de cette expérimentation qu’est né FrogGPT, notre premier agent IA.

L’idée de départ

Le postulat était volontairement provocateur : traiter ChatGPT comme un membre de l’équipe à part entière. On lui assigne un ticket, il répond. On lui laisse un commentaire, il réagit. Et au moment de passer le ticket en développement, il produit un vrai résultat : des fichiers, une branche, une merge request.

Concrètement, FrogGPT devait :

• écouter les tickets Jira d’un projet et se déclencher à l’assignation d’un ticket à un utilisateur nommé « ChatGPT » ;
• analyser la demande — qu’elle vienne du corps du ticket ou d’un commentaire ajouté par la suite ;
• répondre directement dans le ticket, sous forme d’un commentaire, avec le code correctement formaté ;
• puis, dans un second temps, générer les fichiers, les committer dans une branche dédiée et ouvrir une merge request sur le dépôt GitLab.

Rien de tout cela n’était « clé en main » à l’époque. Il a fallu tout câbler à la main.

L’architecture : un agent 100 % serverless

Nous voulions quelque chose de léger, sans serveur à maintenir, qui ne tourne que lorsqu’un événement se produit sur Jira. L’écosystème serverless d’AWS s’y prêtait parfaitement.

Le cœur du système repose sur deux flux d’événements, déclenchés par des webhooks Jira :

1. Création d’un ticket ou ajout d’un commentaire :

Webhook Jira → API Gateway → Lambda → ChatGPT → Lambda → Jira

Quand un ticket est assigné à « ChatGPT » ou qu’un commentaire est ajouté, Jira envoie un webhook vers une API Gateway AWS, qui déclenche une Lambda. Celle-ci analyse le contenu de la demande (le corps du ticket et ses champs additionnels, ou le commentaire), construit le prompt, interroge l’API ChatGPT, puis publie la réponse directement en commentaire du ticket via l’API Jira, avec le formatage du code préservé.

2. Changement d’état du ticket :

Webhook Jira → API Gateway → Lambda → Git/GitLab → Jira

Lorsqu’on fait passer le ticket dans l’état de développement, un second flux prend le relais : une Lambda récupère les fichiers générés (stockés sur S3), crée une branche à partir du ticket, commite, pousse le code et ouvre une merge request sur le projet GitLab, affectée à l’auteur du ticket.

L’ensemble ne consomme donc des ressources qu’au moment où quelque chose se passe sur Jira — pas de serveur allumé en permanence, pas de coût à vide.

De la V1 à la V2 : du commentaire au code committé

Nous avons découpé le projet en deux versions, pour avancer par paliers.

V1 — Le dialogue dans Jira

La première version se concentrait sur la conversation. FrogGPT écoutait les tickets, analysait la demande initiale ou les commentaires, et répondait dans le ticket. L’intérêt était déjà réel : poser une question technique dans un commentaire et obtenir une réponse contextualisée, avec du code formaté, sans quitter son outil de suivi.

V2 — La génération de code autonome

La seconde version franchissait le pas vers l’autonomie. À partir de la réponse de ChatGPT, FrogGPT générait les fichiers correspondants et les stockait sur S3. Pour que le code produit soit cohérent avec le projet existant, nous indiquions la structure du projet à ChatGPT dans le prompt — une forme rudimentaire de ce qu’on appellerait aujourd’hui de la mise en contexte.

Ensuite venait l’automatisation du cycle Git : création de branche, commit, push, et ouverture d’une merge request prête à être relue. L’agent ne se contentait plus de parler, il produisait quelque chose d’exploitable dans le flux de travail de l’équipe.

Ce que l’on a appris

Avec le recul, FrogGPT ressemble furieusement à ce qu’on appelle désormais un agent IA : un modèle de langage branché sur des outils (Jira, GitLab, S3), déclenché par des événements, capable d’enchaîner des actions concrètes pour accomplir une tâche. Sauf qu’en 2023, il fallait tout inventer soi-même — le vocabulaire, les patterns, le collage entre les briques.

Plusieurs enseignements nous sont restés :

• La mise en contexte est le nerf de la guerre. Sans la structure du projet et les bonnes informations dans le prompt, le code généré était générique et peu réutilisable. C’est toujours vrai aujourd’hui.
• L’événementiel et le serverless forment un duo naturel pour les agents. Un agent passe l’essentiel de son temps à attendre un déclencheur ; ne payer que lorsqu’il travaille a du sens.
• L’humain reste dans la boucle. FrogGPT ne mergeait rien tout seul : il ouvrait une merge request, qu’un développeur relisait. L’agent accélère, il ne remplace pas la revue.

FrogGPT n’a jamais eu vocation à devenir un produit. C’était un terrain d’expérimentation, à un moment où personne ne savait vraiment ce que ces modèles avaient dans le ventre. Mais il a marqué un point de bascule : celui où nous avons compris que ces technologies allaient profondément transformer notre façon de construire des logiciels — et qu’il valait mieux apprendre à les apprivoiser tout de suite.

Ce que nous faisions à la main en 2023, des outils entiers le font aujourd’hui. Mais l’intuition de départ, elle, n’a pas pris une ride.