Fais passer tes agents des ordinateurs portables à une infrastructure partagée

Il y a un moment précis et identifiable où l’utilisation des agents IA par une équipe prend une nouvelle forme. Pas quand ils adoptent les agents ; la plupart des équipes l’ont déjà fait. C’est quand les agents cessent de tourner sur l’ordinateur portable de quelqu’un et commencent à tourner sur une infrastructure que toute l’équipe peut voir.

C’est un véritable changement technique, pas un simple changement de politique ou un score de maturité. Voici précisément ce qui change d’un côté et de l’autre.

À quoi ressemble concrètement un agent qui tourne sur un ordinateur portable ?

Point clé : un agent sur un ordinateur portable est lancé manuellement, n’est visible que par la personne qui l’exécute et s’arrête dès que l’ordinateur se ferme.

Un développeur ouvre un terminal ou son éditeur et lance un agent sur une tâche. Il regarde l’agent travailler, ou pas, et revient vérifier plus tard. S’il ferme son ordinateur portable ou si la connexion est coupée, l’agent s’arrête là où il en était. Personne d’autre dans l’équipe ne sait ce qui a été exécuté, ce que ça a touché ou ce que ça a coûté, à moins que ce développeur ne le partage explicitement.

Ce n’est pas une critique à l’encontre du développeur. C’est une description du fonctionnement par défaut. Rien dans cette façon d’exécuter un agent n’a été conçu pour être visible par qui que ce soit d’autre, car l’outil a été conçu autour de l’éditeur d’une seule personne, et non autour d’une infrastructure partagée par toute une équipe.

Ce qui change lorsque les agents s’exécutent sur une infrastructure partagée

Point clé : le déclenchement passe de manuel à basé sur des événements ou planifié, l’environnement passe d’un ordinateur portable à un bac à sable éphémère, et l’historique passe de rien à un journal centralisé.

Trois éléments précis changent, pas seulement un.

1. Le déclencheur. Au lieu qu’une personne décide de lancer un agent sur-le-champ, un processus se déclenche à la suite d’un événement (ouverture d’une pull request, mention dans un ticket) ou selon un calendrier (analyse récurrente des dépendances, tâche de maintenance nocturne). L’agent n’a besoin de personne pour démarrer.
2. L’environnement. Au lieu de tourner sur la machine du développeur lui-même, l’agent s’exécute dans un bac à sable isolé et éphémère, créé spécialement pour cette exécution et supprimé une fois celle-ci terminée. Il a accès à ce dont l’exécution a besoin, et rien d’autre.
3. Le journal. Au lieu de rien, ou de ce que le développeur a pu partager après coup, chaque exécution génère un journal centralisé : ce qui l’a déclenchée, ce qu’elle a fait et ce qu’elle a coûté, lié à cette exécution spécifique et visible par tous les membres de l’équipe qui y ont accès.

Tout ça ne demande pas au développeur de changer sa façon d’écrire du code au quotidien. Ça change juste l’endroit où une certaine catégorie d’agents, ceux qui tournaient avant en silence sur une seule machine, s’exécute réellement.

Pourquoi c’est l’étape la plus difficile, et pas la plus évidente

Point clé : Adopter des agents, c’est la partie la plus facile. Les faire sortir des machines individuelles, c’est l’étape où la plupart des équipes calent, parce que ça implique de faire confiance à une infrastructure qu’elles n’ont pas construite elles-mêmes pour toute l’équipe.

La plupart des équipes en arrivent rapidement à « on utilise des agents IA ». Passer à « nos agents tournent sur une infrastructure partagée, et n’importe qui dans l’équipe peut voir ce qu’ils ont fait » est une étape différente et plus difficile, car ça implique de faire confiance à quelque chose qui dépasse le jugement et la configuration d’un seul développeur.

Cette confiance doit être méritée par l’infrastructure elle-même, elle ne va pas de soi. Un bac à sable éphémère doit être réellement isolé, pas seulement décrit comme tel. Un journal centralisé doit réellement enregistrer ce qui s’est passé, pas seulement prétendre le faire. Une exécution planifiée ou déclenchée par un événement doit se dérouler de manière prévisible sans que personne ne la surveille en direct, puisque c’est justement le but de ne pas avoir besoin d’une personne présente.

Comment ça se passe avec Upsun Dispatch

Point clé : Upsun Dispatch exécute les agents de cette manière par défaut. Déclenchés par de vrais événements, exécutés dans des environnements de test isolés, consignés de manière centralisée, non pas comme une mise à niveau, mais comme ça fonctionne dès le départ.

Upsun Dispatch™ fonctionne ainsi dès le départ, plutôt que de considérer cela comme une configuration avancée. PR Review, le processus natif disponible aujourd’hui, se déclenche lors d’un événement de pull request, et non parce qu’une personne décide de le lancer. Il s’exécute sans qu’il soit nécessaire que l’ordinateur d’un développeur reste allumé. Et il génère un enregistrement, lié à cette exécution spécifique, visible par l’équipe, et non reconstitué plus tard à partir des souvenirs de celui ou celle qui se souvient de ce qui s’est passé.

Ça se connecte à un dépôt sur GitHub SaaS ou sur GitLab auto-hébergé. L’agent fonctionne de la même manière, que l’ordinateur portable du développeur soit allumé ou éteint à ce moment-là.

Crée un espace de travail pour voir par toi-même comment une exécution se déclenche dans une infrastructure partagée.

Foire aux questions (FAQ)

Est-ce que ça veut dire que les développeurs ne peuvent plus exécuter d’agents en local ?
Non. Il s’agit d’un type spécifique de processus, celui qui doit s’exécuter indépendamment de la machine d’une personne en particulier, d’une révision, d’une maintenance planifiée ou de tout autre élément dont dépend toute l’équipe. Ça ne nécessite pas de changer la façon dont tu écris ton code au quotidien.

Qu’est-ce qui rend un bac à sable «éphémère» ?
Il est créé pour une exécution spécifique et supprimé une fois celle-ci terminée. Il ne persiste pas d’une exécution à l’autre et ne partage pas d’état avec quoi que ce soit d’autre sur la plateforme.

Pourquoi est-ce particulièrement important pour les tâches planifiées ou déclenchées par un événement ?
Parce que ces tâches sont conçues pour se dérouler sans que personne ne les surveille en direct. Si rien n’enregistre ce qui s’est passé, une exécution planifiée qui échoue ou qui fait quelque chose d’inattendu ne laisse aucune trace que quelqu’un puisse vérifier par la suite.

Est-ce que ça ne concerne que les grandes équipes ?
Ce manque de visibilité existe quelle que soit la taille de l’équipe, mais ça devient un vrai problème dès qu’il y a plus d’une personne qui compte sur les résultats d’un agent sans avoir pu les observer en direct.