Le pire conseil que je vois donné aux petites équipes de dev est « commencez à tout automatiser ». Les équipes de cinq n'ont pas la bande passante pour construire cinq agents. Elles ont à peine la bande passante pour en construire un. Faites le mauvais choix sur le premier agent et vous passez trois semaines sur quelque chose que l'équipe utilise deux fois avant d'abandonner.
La question qui mérite une réponse : dans une équipe de 2 à 10 développeurs, quel est le premier agent que vous construisez ? La réponse dépend de ce qui fait le plus mal. Mais il y a un vrai ordre, et il y a une automatisation séduisante que je ne construirais absolument pas en premier. Laissez-moi vous la décortiquer.
Les six candidats
Voici les six qui reviennent dans la discussion. Je les classe sur deux axes : l'effort de construction, et la valeur une fois en place. Celles en haut à droite se construisent. Celles en bas à gauche se racontent et ne sortent jamais. Aucune n'exige un bon de commande pour démarrer : SonarQube Community Build, un Sentry auto-hébergé et GitHub Actions sur un plan gratuit couvrent toute la liste, avec une réserve de licence sur la première dont je parle plus bas.
Le séduisant que je sauterais : l'assistant d'onboarding
L'agent d'onboarding a l'air génial. Nouvelle recrue qui arrive, l'agent explique la codebase, répond aux questions d'architecture, suggère les premières tâches. C'est l'automatisation qui enthousiasme tout le monde. C'est le pire endroit pour commencer.
Pourquoi. L'agent d'onboarding a besoin de tout savoir. Chaque service, chaque convention, chaque pattern déprécié, chaque raison pour laquelle une décision bizarre a été prise il y a trois ans. Si la base de connaissance est fausse ou incomplète, la nouvelle recrue apprend de mauvaises choses et vous devez les lui faire désapprendre. Si la base de connaissance est complète, vous avez déjà fait 80 pour cent du travail d'onboarding, et un README aurait fait l'essentiel du boulot.
Dans une petite équipe, vous embauchez peut-être 2 ou 3 personnes par an. L'agent se déclenche 2 ou 3 fois. Toutes les autres automatisations de cette liste se déclenchent à chaque PR ou à chaque merge. Vous dépensez des semaines d'effort d'ingénierie sur un agent qui tourne une poignée de fois par an et qui se trompe si la base de connaissance n'est pas parfaite. Sautez-le. Construisez-le quand vous êtes 30 personnes, pas 8.
Commencez ici : pont SonarQube vers Copilot
Celui-là mérite son propre article. Version courte : Sonar signale des problèmes dans le code assisté par IA, les développeurs ignorent le dashboard parce que ça leur coûte des changements de contexte pour agir dessus. L'agent lit le rapport Sonar, génère un prompt Copilot prêt à coller, le dépose sur la PR. Le développeur colle, relit, commit.
Pourquoi celui-ci en premier. Il se déclenche sur chaque PR. L'entrée est une API structurée. La sortie est du texte, sans risque d'exécution. Un seul développeur peut le construire en un week-end. Chaque membre de l'équipe voit la valeur dès la première semaine. C'est la victoire la plus facile que je connaisse, et les équipes ne le construisent toujours pas.
La réserve que personne ne met dans le pitch : l'analyse de pull request exige SonarQube Developer Edition ou supérieur. Community Build rejette sonar.pullrequest.key, donc le déclencheur sur PR n'est pas gratuit. La version gratuite de cet agent tourne sur l'analyse de branche : scannez main, lisez les issues apparues depuis la dernière analyse, commentez sur le commit de merge. Vous perdez le retour avant merge et vous gardez tout le reste. Le plugin de branches communautaire (mc1arke/sonarqube-community-branch-plugin) remet le déclencheur sur PR dans Community Build, de façon non officielle et non supportée par SonarSource. Décidez ça avant de budgéter le week-end.
Deuxième : détecteur de dérive de docs
Celui-ci tourne au merge sur main. L'agent regarde quels fichiers ont changé dans la PR et vérifie si la documentation associée a été mise à jour. Sinon, il poste un commentaire ou ouvre une PR de mise à jour de doc avec un brouillon.
Pourquoi en deuxième. La dérive de documentation est universelle. Personne ne met la doc à jour de gaieté de cœur, tout le monde met la doc à jour sous pression juste avant une release ou un onboarding. Un agent qui signale la dérive au moment où elle se produit fait que vous la corrigez en 10 minutes, au lieu d'auditer 200 pages six mois plus tard.
Cicatrice des équipes avec qui j'ai travaillé : les docs deviennent obsolètes parce que la mise à jour est une PR séparée et se fait dépriorisée. La correction : rattacher la mise à jour de doc au changement de code au lieu de la laisser pour plus tard. L'agent fait ça : il ouvre la PR de doc liée à la PR de code, même sprint, même reviewer.
Troisième : bot de briefing de standup
À 9h, l'agent récupère : commits de la veille par développeur, PRs ouvertes ou mergées, changements de statut Jira, mentions de blockers sur Slack. Il poste un briefing par personne sur le canal de l'équipe. L'humain fait toujours le standup. Le bot remplace juste l'exercice de mémoire du style « laissez-moi jeter un œil à mon git log vite fait ».
Pourquoi en troisième. C'est faible risque, faible effort et haut signal. Les tech leads adorent parce que les impediments remontent sans que les gens aient à les offrir. Les gens de l'équipe adorent parce que leur démo de la veille est déjà rédigée.
Quatrième : triage de bugs
Se déclenche sur de nouveaux événements Sentry ou de nouvelles issues GitHub. L'agent classe la sévérité, cherche des incidents passés similaires dans le vector store, assigne un propriétaire basé sur l'ownership de fichier via git blame, et poste un ping Slack à la bonne personne.
Pourquoi en quatrième, pas en premier. Le triage de bugs demande deux choses que les agents précédents ne demandent pas : une mémoire déjà peuplée (vector store de bugs passés), et une logique de classification calibrée pour votre équipe. Livrez-le une fois que les deux premiers tournent, pas la première semaine. À ce moment vous aurez assez de runs du pont Sonar et du détecteur de docs pour comprendre comment construire un agent plus stateful.
Cinquième : assistant de revue de PR
Première passe de revue de PR avant que l'humain n'intervienne. Vérifie les conventions, le risque, la couverture, la probabilité de régression basée sur des bugs passés dans des fichiers liés.
Pourquoi en cinquième. La revue de PR est une tâche de jugement. Les 80 premiers pour cent sont mécaniques et l'agent les gère parfaitement. Les 20 derniers pour cent sont du contexte sur l'équipe, la roadmap, les choses qui ont cassé au trimestre dernier. Si l'agent n'est pas calibré sur les revues passées de votre équipe, il va générer du bruit. Il vous faut assez d'historique de revues à vous pour le calibrer, c'est-à-dire des mois de runs, pas des semaines, et vous ne connaîtrez pas le chiffre avant d'avoir regardé le bruit qu'il produit.
La règle de décision
Quand j'évalue un agent candidat pour une petite équipe, je pose trois questions dans l'ordre. Si une réponse est mauvaise, je saute, peu importe à quel point le pitch est excitant.
- À quelle fréquence se déclenche-t-il ? Si la réponse est moins d'une fois par jour, ce n'est pas votre premier agent.
- A-t-il besoin de mémoire ou de qualité de classification dès le premier jour ? Si oui, ce n'est pas votre premier agent. Les agents précédents peuplent la mémoire dont dépendent les agents suivants.
- S'il produit une sortie erronée, quel est le rayon d'explosion ? Du texte dans un commentaire de PR, ça va. Du code exécuté en production, non. Commencez là où le rayon d'explosion est le plus petit.
Appliquez ces règles aux six candidats et vous retombez sur l'ordre que je viens de décrire. Appliquez-les à n'importe quoi d'autre qu'on vous pitche et vous saurez si ça vaut les trois prochaines semaines de votre équipe.
Ce qui se passe après le premier agent
Le premier agent est le plus dur. Pas parce que le code est dur, mais parce qu'il faut choisir la structure, la stratégie de déploiement, l'approche d'observabilité, le layout de mémoire. Le deuxième agent est 5x plus rapide parce que vous réutilisez tout ça. Au troisième, vous avez une petite plateforme interne et l'équipe commence à proposer ses propres agents.
C'est le vrai but de commencer par le pont SonarQube. Pas le pont lui-même. La base partagée qui rend les cinq agents suivants triviaux à livrer.
Un agent que l'équipe utilise tous les jours bat cinq agents qu'elle utilise une fois et oublie. Choisissez celui qui se déclenche souvent, qui échoue sans danger, qui rend de la valeur évidente dès la première semaine.
Références
- SonarQube Web API : https://docs.sonarsource.com/sonarqube/latest/extension-guide/web-api/
- GitHub Actions : https://docs.github.com/en/actions
- Sentry API : https://docs.sentry.io/api/