Avant que ton goulot d'étranglement lié à l'IA ne s'aggrave : ce qu'il faut mettre en place dès maintenant

Tes ingénieurs ont des agents qui tournent. Pas un seul agent, mais plusieurs, répartis dans toute l’équipe. Certains tournent dans un terminal sur un ordinateur portable, d’autres sont intégrés à tes tâches d’intégration continue, et d’autres encore sont intégrés à l’outil de codage que chacun préfère. Chacun a été configuré séparément, par celui qui en avait besoin, de la manière qui fonctionnait cette semaine-là.

C’est la situation dans laquelle se trouvent la plupart des équipes en ce moment. Le code a cessé d’être le maillon faible depuis un certain temps déjà. Ce qui est lent aujourd’hui, c’est tout ce qui l’entoure, et la question sur laquelle presque personne n’a pris le temps de se pencher, c’est de savoir où tout ça s’exécute réellement. Ça s’est accumulé par défaut, un agent et une tâche d’intégration continue à la fois. Personne n’a choisi cette organisation. Elle s’est simplement développée toute seule.

La couche que tu ne savais pas que tu choisissais

Chaque équipe qui utilise des agents repose sur une couche de plateforme : c’est ce qui détermine où les agents s’exécutent, quels modèles ils utilisent, comment ils accèdent à ton infrastructure, et qui peut voir ce qu’ils ont fait. Tu en utilises une, que tu l’aies choisie ou non.

Il y a deux façons courantes de se retrouver avec une telle couche sans l’avoir choisie.

La première consiste à étendre ce que tu as déjà. Les agents sont intégrés à ton système d’intégration continue (CI) existant, celui-là même qui exécute tes builds et tes tests. Ça marche au début. Mais le fournisseur de CI a conçu ce système pour exécuter des pipelines, pas pour gérer une équipe d’agents, et l’étendre signifie en hériter les hypothèses : les modèles qu’il rend pratiques, la puissance de calcul sur laquelle il tourne, le chemin de déploiement qu’il prévoit, et sa vision de ce à quoi devrait ressembler le processus d’un agent. Tu n’as pas évalué ces hypothèses. Elles étaient fournies avec l’outil que tu avais déjà.

La deuxième option, c’est de ne rien faire de délibéré du tout. La couche s’assemble toute seule à partir de ce que chaque ingénieur a mis en place localement : la configuration du terminal de l’un, le script d’un autre, l’expérience d’intégration continue d’un troisième. Il n’y a pas vraiment de couche, mais plutôt un tas de couches, et personne n’a une vue d’ensemble.

Ce sont deux choix. Aucun n’a été fait exprès. C’est là le problème. La couche de la plateforme est déterminée d’une manière ou d’une autre, et en hériter n’est pas la même chose que la choisir.

Ce que la couche détermine

Une couche de plateforme, c’est l’ensemble des décisions qui sous-tendent chaque agent que ton équipe exécute : quel modèle répond à une tâche donnée, sur quelle machine l’agent tourne, comment il accède à ton code et à ton infrastructure, et quelle trace il laisse derrière lui. 

Que tu aies choisi cette couche ou que tu l’aies héritée, elle détermine discrètement trois choses qui t’importeront plus tard. Ça vaut le coup de les voir concrètement.

1. Quels modèles peux-tu utiliser ?

Frontier Labs brûle de l’argent, et ses tarifs vont évoluer. Si tu lies ta couche à un seul fournisseur, c’est à toi d’absorber ce changement. Une couche qui te permet d’associer chaque tâche au modèle qui lui convient et de changer de fournisseur lorsque la situation économique change, sans avoir à reconstruire ce qui se trouve au-dessus. La plupart des tâches de codage n’ont de toute façon pas besoin du plus gros modèle, et un modèle plus petit, bien configuré, coûte bien moins cher.

2. Où ça tourne

Une couche héritée s’exécute là où le fournisseur l’exécute, selon ses propres conditions. Une couche choisie s’exécute là où se trouve déjà ton infrastructure. Upsun Dispatch™ est un produit autonome précisément pour cette raison : il ne nécessite pas Upsun Cloud pour exécuter tes agents et ton cycle de vie de développement. Tu apportes ta propre configuration plutôt que d’adopter celle de quelqu’un d’autre.

3. Ce que tu peux voir et contrôler

C’est ce qui fait le plus mal quand ça manque. Des agents dispersés entre les ordinateurs portables et les tâches d’intégration continue (CI) empêchent quiconque d’avoir une vue d’ensemble de l’organisation : on ne sait pas pourquoi un agent a dépensé des milliers de dollars, ni ce qu’un changement a affecté, ni qui l’a approuvé.

 Une couche de gestion délibérée rend le travail des agents observable et contrôlable, avec des contrôles humains, l’imputation des coûts au processus qui les a générés, et une piste d’audit des demandes, des différences et des validations. Le travail dont tu ne peux pas rendre compte est un risque qui augmente à chaque nouvel agent que tu ajoutes.

Quand la couche héritée suffit

Toutes les équipes n’ont pas encore besoin de prendre cette décision, et ça vaut le coup d’être honnête là-dessus.

Si tu développes un projet jetable, un outil interne ponctuel, une page web pour le plaisir, ou tout autre chose que tu ne maintiendras pas, le code n’a pratiquement aucune importance, pas plus que la couche sous-jacente. Assigne-lui un agent et passe à autre chose. Il en va de même pour une équipe qui en est encore aux prémices de l’adoption de l’IA, utilisant principalement la saisie semi-automatique, n’exécutant pas encore d’agents en parallèle, et ne ressentant pas encore la prolifération. Il n’y a rien à gérer, donc cette décision ne t’évite rien.

À quoi ressemble un choix réfléchi

Choisir la couche de manière délibérée, ça veut dire faire tourner tes agents sur quelque chose conçu pour les gérer, plutôt que sur quelque chose prévu pour autre chose et adapté à la va-vite.

C’est exactement ce qu’est Upsun Dispatch : une plateforme de collaboration régulée entre des agents IA et des équipes humaines interfonctionnelles. Elle se positionne en face de tes agents et de tes modèles, plutôt que d’être un énième agent dans la pile. Elle fonctionne de manière autonome, là où se trouve déjà ton infrastructure, et te permet de choisir quel modèle gère quelle tâche. Et elle t’apporte la visibilité et le contrôle qu’un système d’intégration continue (CI) surchargé n’a jamais été conçu pour t’offrir, grâce à des processus structurés, des environnements de test isolés, des contrôles humains et une piste d’audit complète.

L’important, c’est que c’est toi qui as choisi cette couche pour cette tâche, au lieu de la reprendre telle quelle d’un outil qui se trouvait déjà là.

Ce qu’il faut mettre en place dès maintenant

Dans tous les cas, la couche sera choisie. La seule question est de savoir si c’est toi qui la choisis ou si tu l’hérites. La choisir maintenant ne coûte pas cher et est réversible. Tu places la couche de plateforme choisie sous le travail de tes agents tant que la prolifération est encore suffisamment limitée pour être redirigée. En hériter une et la démanteler plus tard n’est ni peu coûteux ni réversible : tu refais la plate-forme des processus des agents dont toute ton équipe dépend désormais, selon les modèles, la puissance de calcul et les hypothèses de déploiement d’un fournisseur qui a fait ces choix à ta place.

La manière la plus simple de concrétiser ce choix délibéré est d’exécuter un processus sur une couche que tu as réellement choisie.  
 

Crée un espace de travail dans Upsun Dispatch et exécute-y un processus. Tu verras, dans ton propre travail, ce que ça signifie de maîtriser la couche plutôt que de l’hériter.

Foire aux questions (FAQ)

Qu’est-ce qu’une couche de plateforme pour les agents IA ?
C’est l’ensemble des décisions qui sous-tendent chaque agent que ton équipe exécute : quel modèle gère une tâche, sur quelle puissance de calcul l’agent s’exécute, comment il accède à ton code et à ton infrastructure, et quelle trace il laisse derrière lui. Chaque équipe qui utilise des agents en possède une, qu’elle l’ait choisie délibérément ou qu’elle l’ait héritée en étendant son CI ou en laissant les configurations s’accumuler sur les ordinateurs portables.

Est-ce que je peux simplement exécuter des agents IA sur mon pipeline CI existant ?
C’est possible, et de nombreuses équipes le font, mais les systèmes CI ont été conçus pour exécuter des pipelines, pas pour gérer une équipe d’agents. Étendre le CI, c’est hériter de ses hypothèses concernant les modèles, la puissance de calcul et le déploiement, et il n’a jamais été conçu pour te fournir une attribution des coûts, des étapes de validation humaine ou une piste d’audit pour l’ensemble des agents. Ça fonctionne au début, mais ça devient de plus en plus difficile à démêler à mesure que l’utilisation des agents se développe.

Pourquoi le modèle utilisé par mes agents a-t-il de l’importance ? Les tarifs des modèles de
pointe changent souvent, et lier ta configuration à un seul fournisseur signifie absorber directement ces changements. Une couche qui te permet d’associer chaque tâche à un modèle adapté et de changer de fournisseur lorsque la situation économique évolue évite une refonte coûteuse par la suite. La plupart des tâches de codage n’ont pas besoin du modèle le plus gros et le plus cher.

Ai-je besoin d’Upsun Cloud pour utiliser Upsun Dispatch ?
Non. Upsun Dispatch est un produit autonome. Il gère tes agents et le cycle de vie du développement sans nécessiter Upsun Cloud ; il s’adapte donc à ton infrastructure existante plutôt que de t’obliger à utiliser un hébergeur spécifique.

Quand une couche de plateforme héritée est-elle suffisante ?
Pour les projets jetables, les outils internes ponctuels ou tout ce que tu ne compte pas maintenir, la couche sous-jacente n’a pratiquement aucune importance. Il en va de même pour les équipes qui en sont aux prémices de l’adoption de l’IA et qui utilisent principalement la saisie semi-automatique sans encore exécuter d’agents en parallèle. S’il n’y a rien à gérer, cette décision ne t’apporte encore aucun avantage.