L'accès de l'agent ne relève pas de la confiance du processus

La tendance qui se dessine dans tout le secteur

Point clé à retenir : plusieurs plateformes proposent désormais des agents capables d’analyser les problèmes, de proposer des solutions et de les déployer, avec de véritables modèles d’autorisation et un environnement sandbox en arrière-plan. C’est une véritable prouesse technique, pas juste une démo.

Si tu passes en revue les annonces récentes concernant les plateformes et les harnais, un thème revient sans cesse : un agent capable de lire les journaux et les métriques, de remonter à la cause première d’un problème, de proposer ou d’appliquer une correction, et d’agir en production, selon un plan que tu approuves au préalable.

Et ça ne concerne pas que les éditeurs de plateformes. Demande à n’importe quel ingénieur quel agent de codage il utilise et tu auras une réponse différente à chaque fois. Patrick Dawkins, ingénieur principal chez Upsun, a récemment estimé à environ 22 le nombre d’outils majeurs actuellement en circulation, et ce chiffre change d’une semaine à l’autre. 

Certains de ces outils sont vraiment bien conçus. Les agents fonctionnent sous leur propre identité, demandent des autorisations limitées à un plan spécifique plutôt qu’un accès permanent, et testent le code généré dans un environnement isolé (sandbox) par rapport à de véritables builds et tests avant que quoi que ce soit n’atteigne un humain.

C’est une réponse sérieuse à une vraie question : comment laisser un agent opérer à proximité de l’environnement de production sans parier que l’entreprise ne subira jamais d’erreur de sa part ? La réponse, de plus en plus souvent, réside dans une bonne infrastructure sous-jacente à l’agent, et non dans une confiance aveugle dans le modèle.

Quand cette réponse atteint ses limites

Point clé : ces agents sont conçus pour fonctionner sur l’infrastructure propre à une plateforme, pour la personne qui évolue déjà dans le tableau de bord de cette plateforme. La plupart du travail concret ne se limite pas à une seule plateforme, et la plupart des décisions prises en cours de route ne sont pas prises par un ingénieur.

Voici ce qu’on ne dit pas à voix haute : la plupart de ces agents fonctionnent au sein de la plateforme qui les a créés, sur les déploiements, les journaux et le tableau de bord propres à cette plateforme. Ils sont conçus pour la personne qui s’y sent déjà à l’aise, ce qui, aujourd’hui, signifie généralement l’ingénieur.

Mais une fonctionnalité est rarement livrée via un seul outil. Un ticket est créé dans un outil de suivi que ton équipe utilise déjà. Le travail s’effectue dans un dépôt hébergé quelque part. Une revue de conception a lieu dans un outil de conception. Quelqu’un du service de sécurité doit donner son feu vert avant que ça n’atteigne les clients. Un responsable veut avoir une vue d’ensemble sans ouvrir de terminal. Rien de tout ça ne se trouve dans le tableau de bord d’une seule et même plateforme, et rien de tout ça n’est résolu en rendant l’agent de cette plateforme plus intelligent.

La question n’est pas de savoir si un agent peut agir en toute sécurité une fois qu’il est déjà intégré à la plateforme de ton choix. C’est de savoir si l’ensemble du parcours, à travers tous les outils impliqués et toutes les personnes qui doivent consulter ou valider une étape, est quelque chose que toi et ton équipe pouvez réellement gérer et en lequel vous pouvez avoir confiance ensemble.

On s’est retrouvé face à ce problème nous-mêmes

Point clé : un agent dédié à une seule tâche et utilisant un seul outil est vraiment utile. C’est aussi un aperçu précis des limites de cette approche, qui ne couvre pas l’ensemble du tableau.

Avant qu’Upsun Dispatch n’existe, un de nos ingénieurs a mis au point un agent interne pour examiner les pull requests dans GitLab. Il remplit bien sa fonction : lire une demande de fusion et signaler ce qui nécessite une attention particulière. Il a également développé une deuxième version qui analyse les demandes en masse, en triant celles qui sont correctes et prêtes à être fusionnées, celles qui sont encore en cours d’examen et celles qui présentent des conflits.

Ces deux outils sont utiles. Mais aucun des deux n’est un processus. Ils interviennent dans une partie du processus, sur une seule plateforme, et s’arrêtent là. Tout le reste de ce qui mène réellement à la mise en production — le ticket à l’origine de tout ça, la discussion autour de la conception, la personne de la sécurité qui doit donner son accord — se passe toujours ailleurs, sans être suivi par quoi que ce soit en particulier. Développer cet agent de révision n’a pas supprimé ce travail de coordination, ça a juste accéléré une partie de celui-ci. 

Ce qui change quand c’est le processus qui est à la base, et non l’agent

Point clé : considérer le processus, et non l’agent ou la plateforme, comme l’unité qui compte change ce qu’il faut développer : les outils dans lesquels il s’inscrit, qui peut y participer, et comment les coûts et la conformité sont suivis.

Upsun Dispatch part d’un principe différent : le processus est l’élément de base. 

Chaque équipe a déjà ses propres rituels et procédures autour de la livraison, les allers-retours pour faire réviser une pull request, les discussions qui ont lieu avant même que le code ne soit écrit. Plusieurs conséquences découlent du fait de considérer cela comme l’élément autour duquel il vaut la peine de concevoir, plutôt que les actions d’un agent en particulier :

• Ça fonctionne avec les outils que ton équipe utilise déjà, pas seulement avec son propre tableau de bord. GitHub, GitLab, Linear, Jira et les rituels que ton équipe suit déjà constituent la base, pas un système séparé à adopter en plus de tout ça.
• N’importe qui dans l’équipe peut intervenir sur une étape, pas seulement l’ingénieur qui a lancé l’exécution. L’approbation n’est pas réservée à celui qui se trouve justement à son bureau.
• Le coût est visible au niveau de l’équipe, pas au niveau individuel. Les agents dépensent des jetons, et sur l’ordinateur portable d’un individu, personne ne peut voir où va cet argent. Upsun Dispatch affiche le coût par exécution, par processus, par équipe.
• Il ne se limite pas à un seul modèle. Enregistre une clé Anthropic ou OpenAI, choisis une valeur par défaut et change-la quand tu en as besoin, pour que le processus n’oblige pas l’équipe à rester avec le modèle qui était le meilleur au moment de la configuration.
• Chaque exécution est consignée avec les données de conformité : le problème, le contexte de l’agent, le plan, qui l’a approuvé et combien ça a coûté.

Rien de tout ça ne remplace le jugement humain sur la marge de manœuvre accordée à un agent. Ça change juste où ce jugement s’applique.

Les domaines où les humains décident encore

Point clé : l’orchestration des processus ne signifie pas que les agents fonctionnent sans supervision. Upsun Dispatch dispose aujourd’hui d’un point de contrôle intégré, et d’autres sont à venir à mesure que Dispatch prendra en charge une plus grande partie du processus.

Le fait que le processus soit l’unité qui compte ne veut pas dire qu’il s’exécute tout seul. Aujourd’hui, ça se traduit par un point de contrôle intégré : Dispatch met en pause une implémentation déclenchée par Jira après la phase de planification et attend une décision avant d’écrire le moindre code. Toute personne pouvant commenter le ticket peut l’approuver, le renvoyer avec des remarques ou l’arrêter là : c’est le même principe de contrôle que l’étape d’approbation du plan d’un agent natif de la plateforme, mais appliqué avant l’écriture du code plutôt qu’avant sa fusion.

La différence réside dans l’orientation future de ce point de contrôle, pas seulement dans sa position actuelle. Un point de contrôle intégré au tableau de bord d’une plateforme ne couvre jamais que les parties d’un processus qui se déroulent au sein de cette plateforme. Comme Upsun Dispatch prend de plus en plus la forme d’un processus, couvrant un outil de suivi, un hébergeur de dépôt et une étape de révision, l’objectif est que des points de contrôle humains soient mis en place à chacun de ces moments, et pas seulement à l’endroit où une plateforme a par hasard mis en place une barrière. Donner plus de marge de manœuvre à un agent et garder une personne informée ne sont pas contradictoires ici. C’est justement cette barrière qui rend cette marge de manœuvre sûre.

Avant, les processus n’étaient guère plus qu’un mécanisme de suivi, un enregistrement du travail qu’une personne effectuait ailleurs. Ce qui a changé, ce n’est pas que le processus ait soudainement pris plus d’importance. C’est que le processus lui-même peut désormais effectuer une partie du travail, ce qui signifie que la question n’est plus de savoir quoi suivre, mais plutôt où une personne doit réellement intervenir, et où elle n’a pas besoin d’intervenir.

Tout ça n’empêche pas un agent natif d’une plateforme d’être doué pour faire fonctionner cette plateforme. Ça répond à une autre question : non pas « est-ce que cet agent peut agir en toute sécurité ici ? », mais « est-ce que ce processus, qui englobe les outils et les personnes qu’il touche réellement, est fiable et peut être audité dans son ensemble ? ».

Pourquoi cette distinction est importante maintenant, et pas plus tard

Point clé : la vague actuelle de fonctionnalités des agents s’adresse aux ingénieurs qui travaillent déjà au sein d’une seule plateforme. Les processus qui permettent réellement de livrer des logiciels impliquent davantage d’outils et de personnes que ça, et c’est dans cette lacune que les équipes se retrouvent bloquées dès qu’elles dépassent le cadre d’une tâche bien délimitée.

La plupart des équipes ne se heurtent pas à cet écart dès le premier jour. Une tâche bien délimitée, un agent qui corrige une compilation ou qui trie une alerte au sein d’une plateforme où il se trouve déjà, ça marche très bien avec la vague actuelle d’agents natifs de la plateforme. 

Le problème apparaît dès que ton travail s’étend à plusieurs outils, ou dès qu’une personne qui n’est pas ingénieur doit consulter ou valider une étape. C’est là que « l’agent peut agir en toute sécurité » cesse d’être la solution complète, car le problème ne concernait pas vraiment l’agent. Il concernait le processus dont il ne constitue qu’une petite partie.

Si ton équipe utilise déjà des processus d'agents sur plusieurs outils et qu'elle ressent des difficultés de coordination, tu peux essayer gratuitement Upsun Dispatch sur upsun.com/dispatch.

Foire aux questions (FAQ)

Un agent natif de la plateforme, bien sécurisé, ne suffit-il pas pour une livraison de logiciels assistée par l’IA ?
Pour les tâches qui restent au sein d’une seule plateforme, c’est souvent le cas. Le problème apparaît dès qu’une tâche s’étend sur plusieurs outils, comme un outil de suivi des tickets, un hébergeur de dépôts et une étape de révision, ou dès qu’une personne extérieure à l’équipe d’ingénierie doit consulter ou valider une partie du processus.

Que signifie « c’est le processus qui est l’élément fondamental, pas l’agent » dans Upsun Dispatch ?
Ça veut dire que ce qu’on conçoit et en quoi on a confiance, c’est la séquence d’étapes et de transferts qu’une équipe suit déjà, à travers les outils qu’elle utilise déjà, plutôt que les actions d’un seul agent au sein de l’infrastructure propre à une plateforme.

Est-ce qu’Upsun Dispatch remplace les fonctionnalités d’agents natifs à une plateforme, comme les agents d’espace de travail de GitHub Copilot ?
Non. Un agent de plateforme qui sait bien gérer sa propre plateforme reste utile précisément pour ça. L’orchestration des processus se situe à un niveau supérieur, pour les parties de la livraison qui n’auraient de toute façon jamais pu tenir dans le tableau de bord d’une seule plateforme.

Quelles équipes tirent le plus profit d’une orchestration par IA au niveau du processus plutôt que d’un agent sur une seule plateforme ?
Les équipes dont la livraison implique déjà plusieurs outils, car c’est là qu’un agent lié à une plateforme, aussi performant soit-il, ne couvre plus l’ensemble du parcours, de l’idée à la production.