Agent IA de point de sprint : votre dépôt GitHub résumé chaque matin dans un wiki

Un point de sprint utile est court, daté et comparable d'un jour à l'autre. Il est aussi pénible à produire : il faut ouvrir le dépôt, compter les pull requests fusionnées, repérer celles qui attendent une revue, parcourir les issues, vérifier si une release approche, puis rédiger deux paragraphes que personne n'a le temps de peaufiner. Résultat habituel, soit le point n'existe pas, soit il est fait à la va-vite avant la réunion, avec les blocages découverts trop tard. C'est une tâche idéale pour un agent IA autonome : elle se répète à l'identique, elle repose sur des données déjà structurées, et elle se vérifie en un coup d'œil.

L'inspiration : le point du matin que personne n'a compilé

Le point de départ est un usage décrit dans des témoignages d'utilisateurs d'agents autonomes : des agents qui lisent les outils de l'équipe technique, comptent ce qui s'est passé et déposent chaque matin un compte rendu de sprint. Ce qui revient dans ces récits n'est pas le volume de données, mais la régularité : le point existe tous les jours, avec la même structure, ce qui permet de voir les tendances au lieu de réagir à un chiffre isolé.

Atako reprend cette idée avec un seul agent, un seul résultat. L'agent lit GitHub, calcule, rédige et publie. Il ne modifie rien dans le dépôt, et le rapport est la seule chose qu'il produit.

Ce que fait l'agent

L'analyste delivery lit le dépôt dans GitHub, celui que vous lui indiquez sous la forme propriétaire/nom. À chaque passage, il suit une méthode fixe.

Il compte d'abord, sur sept jours glissants depuis la date du jour, les pull requests fusionnées, celles encore ouvertes avec leur âge, celles en attente de revue depuis plus de trois jours, les issues ouvertes, les issues fermées et les releases publiées. Il repère ensuite les blocages : pull requests ouvertes depuis plus de cinq jours, issues qui s'accumulent sur un même sujet, release en retard au vu des commits. Il nomme chacun avec son lien et son auteur. Il compare enfin avec les sept jours précédents et dit ce qui a bougé.

Il rédige alors une nouvelle page « Point de sprint - » suivie de la date du jour dans le wiki du projet. Si la page du jour existe déjà, il la met à jour au lieu d'en créer une seconde. La structure ne change pas : les trois ou quatre chiffres qui comptent, l'avancement par rapport à la période précédente, les blocages et les pull requests qui traînent, puis les décisions à envisager. Il commence par la conclusion, tient en deux minutes de lecture, et en résume l'essentiel dans le chat.

Ce que l'agent ne fait pas

L'analyste lit, il n'écrit jamais dans GitHub : pas de commentaire, d'étiquette, de revue, de fusion ni de fermeture. Il ne pousse aucun code. Il ne contacte personne : le rapport est son seul canal de sortie, avec le chat. Il n'invente jamais un chiffre ou un lien, et un nombre absent s'écrit « non disponible ».

Chaque jour a sa page : l'agent n'écrase jamais un jour précédent, ce qui laisse un historique que l'équipe peut relire. Les faits sont séparés de l'interprétation, et l'interprétation est signalée comme telle. Le rapport propose des priorités, il n'en impose pas : c'est le principe d'une conception avec validation humaine.

Comment le mettre en place dans Atako

Depuis la page de ce cas d'usage, le déploiement tient en quatre étapes.

1. Connecter GitHub. Donnez à Atako un accès en lecture sur le dépôt à suivre quand il le demande. La connexion est vérifiée avant que quoi que ce soit ne soit créé.
2. Renseigner votre contexte. Indiquez le dépôt, sous la forme propriétaire/nom, et les lecteurs du rapport, pour que le ton leur soit adapté.
3. Déployer. Une seule action crée l'agent et le projet « Point de sprint ». L'agent est provisionné et reçoit seul ses premières consignes.
4. Premier point, puis rythme quotidien. L'analyste produit le premier rapport sur les sept derniers jours, puis planifie lui-même son passage de 8 h, chaque matin.

Si vous n'avez pas encore de compte, sa création démarre votre essai et le scénario se configure juste après. Si votre administrateur ne vous a pas autorisé à créer des agents, le déploiement vous le dit et s'arrête là.

Où voir les résultats

Le rapport vit dans le wiki du projet « Point de sprint », une page par jour, du plus récent au plus ancien. Le résumé de l'agent arrive aussi dans son chat, ce qui permet de lire l'essentiel depuis un téléphone avant d'ouvrir la page. Sur le plateau Atako, l'analyste apparaît avec son activité : on voit quand il lit le dépôt et quand il rédige, sans avoir à demander où en est le point.

Vous pouvez lui parler dans son chat. Demandez d'où vient un chiffre, de détailler un blocage, de suivre un autre dépôt ou de refaire le point avec un autre angle. L'agent garde la mémoire de ses passages précédents.

Garde-fous

L'accès est volontairement étroit et en lecture seule : huit outils GitHub, pour lister les dépôts, lire un dépôt, lister et lire les pull requests, lister et chercher des issues, lister les commits et les releases. Un agent qui voit une courte liste d'outils les utilise plus fiablement qu'un agent perdu dans un catalogue de centaines. Rien n'est accordé par défaut, et chaque accès peut être retiré à tout moment depuis Atako.

La validation humaine se place sur la décision. Le rapport signale les blocages et les pull requests qui traînent ; c'est à l'équipe de choisir de relancer un relecteur, de découper une pull request ou de décaler une release. L'agent ne voit que ce que GitHub lui donne : une pull request sans description ou un dépôt dont les issues ne sont pas étiquetées donnera un point moins précis, et le rapport le dit au lieu de le masquer.

À quoi s'attendre

Attendez-vous à un premier point utile mais encore générique, qui devient précis quand vous avez ajusté les lecteurs et les seuils dans le chat, par exemple en demandant de signaler les pull requests en attente de revue depuis deux jours plutôt que trois. La valeur vient de la répétition : au bout de deux semaines, les pages successives permettent de comparer, de voir quel blocage dure et quelle tendance se dessine. Pour une petite équipe technique, c'est la différence entre un bilan reconstitué de mémoire avant la réunion et un point quotidien qui existe tout seul, avec les mêmes définitions chaque jour.

Si votre besoin est plus large, qu'il s'agisse de relire les pull requests ou de trier les issues, ce cas d'usage reste volontairement borné au reporting. Il se combine ensuite avec d'autres agents sans rien changer à son fonctionnement : il continue de lire, de compter et de publier.