Outils de code agentique par IA, sans le chaos

« Agentique » est le mot que l'industrie a retenu pour les outils de code IA qui font plus que de l'autocomplétion. Un outil agentique ne se contente pas de suggérer la ligne suivante — il reçoit un objectif, planifie une séquence d'étapes, modifie des fichiers, exécute des commandes, lit les résultats et continue jusqu'à ce que l'objectif soit atteint ou qu'il soit bloqué.

La différence pratique, c'est l'autonomie dans la durée. Un outil de complétion vous aide à taper. Un agent travaille pendant que vous faites autre chose : il peut passer dix minutes ou une heure à transformer une description de travail en une branche, un diff et souvent une pull request.

Ce basculement — d'une assistance à la frappe à la prise en charge d'une tâche — est ce qui rend la catégorie intéressante, mais aussi ce qui la rend difficile à gérer. Dès qu'un outil peut travailler sans surveillance, la question passe de « cette suggestion est-elle bonne ? » à « était-ce la bonne tâche, faite de la bonne façon ? »

Les outils de code agentique se répartissent grossièrement en trois formes, et la plupart des configurations sérieuses les combinent. Quelques exemples de chacune, sans ordre particulier :

La frontière entre ces formes s'estompe : les outils en CLI lancent désormais aussi des sessions cloud — claude --cloud confie une tâche depuis votre terminal à Claude Code on the web. [2] Les agents cloud comme celui de Cursor exécutent chaque tâche dans une VM isolée et vous permettent d'en faire tourner plusieurs en parallèle. [1] Les produits de cet espace changent souvent de nom, donc vérifiez la documentation actuelle de chaque éditeur. Notre guide sur Cursor background agents traite en détail un exemple d'agent cloud.

Demandez à quiconque a utilisé des agents de code pendant un mois ce qui ne va pas, et vous entendrez la même courte liste. L'agent résout un problème légèrement différent de celui voulu. Il touche des fichiers en dehors du périmètre prévu — comme cette pull request de 400 lignes qui a réécrit le flux de réinitialisation de mot de passe alors que le correctif était une faute de frappe dans un message d'erreur. [4] Deux agents en parallèle sur un même checkout écrasent les fichiers l'un de l'autre ou raisonnent sur des changements à moitié faits. [3] Et d'après notre propre expérience, un agent « termine » parfois en affaiblissant un test plutôt qu'en corrigeant le code.

Rien de tout cela n'est un échec de modèle au sens traditionnel. Ce sont des échecs de spécification. Un agent est extrêmement bon pour faire exactement ce que la tâche implique — et impitoyablement littéral sur les zones floues. Une entrée vague ne produit pas un résultat vague ; elle produit un résultat sûr de lui, plausible, et faux.

C'est le goulot d'étranglement dont personne ne vous prévient : une fois que les agents peuvent tourner en parallèle, votre débit est limité par la vitesse à laquelle vous pouvez écrire de bonnes tâches et relire ce qui revient. Les agents sont rarement la partie lente. C'est vous.

La solution n'est pas un meilleur prompt tapé plus vite. C'est traiter la description de la tâche comme un artefact dans lequel il vaut la peine d'investir — tout comme les bonnes équipes traitent un ticket bien écrit.

Une story bien délimitée donne à un agent trois choses qu'un simple prompt n'apporte généralement pas : une définition claire du « terminé », des limites explicites sur ce qu'il ne faut pas toucher, et assez de contexte sur le système environnant pour qu'il ne réinvente pas des conventions déjà existantes. Les équipes qui planifient dans Linear ont déjà l'habitude et l'endroit pour cela. Plus de détails dans notre guide sur les stories pour les agents de code.

Le gain se démultiplie avec le parallélisme. Un agent avec une tâche vague gaspille dix minutes. Dix agents avec des tâches vagues gaspillent ces mêmes dix minutes dix fois, et vous laissent dix diffs à démêler. Dix agents avec des stories précises se comportent comme une équipe qui a lu le même brief — tant que les stories ne se chevauchent pas.

Faire tourner des agents en parallèle, c'est là où va la catégorie, et cela change encore le workflow. Vous arrêtez de travailler en binôme avec un agent et commencez à superviser une flotte : mettre du travail en file, vérifier les statuts, débloquer ceux qui sont coincés, et relire les résultats par lots.

Le point précédent qui fait le plus mal en pratique, c'est la visibilité. Dès que vous faites tourner plus de deux ou trois agents cloud, la question « qui fait quoi, et pour quel ticket ? » vous dévore la journée. La vue Agents d'Aerunit y répond en un seul endroit : une liste unique de chaque session Cursor Cloud Agent en cours, chacune liée à son issue Linear. Vous pouvez envoyer un message à plusieurs sessions à la fois, archiver celles qui sont terminées, et les sessions disparaissent de la liste quand leur issue est traitée.

Aerunit fonctionne actuellement avec Cursor Cloud Agents. Derrière cette liste, il rédige aussi les stories — en lisant chaque dépôt qu'une story touche avant de l'écrire — et démarre l'issue suivante dès que son bloqueur est fusionné, afin que la flotte reste occupée sans que vous ayez à la lancer à la main.