D'un agent unique à une flotte coordonnée
Piloter un agent isolé prend quelques réglages : une consigne, un jeu d'outils, des garde-fous. Dès qu'on en déploie plusieurs, la difficulté change de nature. Les agents se coordonnent, se passent des tâches, attendent des réponses, se marchent parfois dessus. Un problème réglé pour un agent prend une autre ampleur à l'échelle d'un ensemble : une boucle coûteuse qui durait une minute se répète mille fois, une petite erreur de routage devient une avalanche. Huit agents simples à l'unité forment un système complexe dont le comportement d'ensemble, lui, n'a été prévu par personne.
La première décision de scaling ne concerne donc pas la puissance de calcul, mais l'architecture. Qui décide de la répartition des tâches ? Un agent coordinateur, une répartition entre pairs, une file d'attente ? Ces choix se payent plus tard, quand la flotte grandit et que les rôles flous deviennent des points de blocage. Il vaut mieux les trancher tôt, sur des hypothèses explicites, que de les découvrir sous la pression, quand les coûts en production interdisent les refontes. Structurer avant d'accélérer évite de construire une machine impossible à gouverner. Ces choix se révisent mal une fois la flotte en service, car chaque agent déployé devient une dépendance dont la refonte coûte cher à arracher.
Coordonner sans créer d'engorgement
Passer par un agent coordinateur unique paraît simple et fonctionne bien jusqu'à un certain point, tant que la charge reste modérée. Ensuite, il devient un goulot : tout le trafic le traverse, sa latence contraint l'ensemble, et sa panne arrête la flotte. Répartir les décisions entre plusieurs nœuds réduit ce risque, mais fait apparaître d'autres problèmes, notamment la cohérence. Deux agents qui prennent des décisions concurrentes sans se voir peuvent se contredire. La coordination se joue donc sur un équilibre entre centralisation, qui garantit la cohérence, et distribution, qui garantit la robustesse sous charge.
La ressource rare n'est pas seulement le calcul. Les appels à un modèle, l'accès à une base, l'usage d'une interface tierce ont leurs propres limites, souvent plus contraignantes que la puissance brute. Une flotte qui grandit multiplie ces appels et rencontre des plafonds de débit, des files saturées, des temps d'attente qui s'accumulent en cascade. Anticiper ces goulots, prévoir des réserves, répartir la charge dans le temps font partie du travail de scaling au même titre que l'ajout de machines. Sous-estimer un quota partagé suffit à faire s'écrouler une flotte pourtant bien conçue.
Tenir la charge quand le nombre grimpe
Augmenter le nombre d'agents modifie la nature des pannes. Un agent isolé se casse de façon lisible ; une flotte échoue souvent en silence, par dégradation progressive. Une latence qui monte, un taux de succès qui baisse lentement, un coût qui dérape sans qu'aucune alerte ne se déclenche : ces signaux passent inaperçus si l'on se contente de surveiller les erreurs franches. Le dimensionnement doit donc reposer sur des mesures, pas sur des intuitions. On observe les temps de réponse, l'occupation des files, le nombre d'appels par tâche, et l'on découvre où se logent les vraies limites.
La résilience compte davantage à mesure que la flotte grandit. Ce qui était une gêne à trois agents devient un incident à trente. Il faut décider du comportement quand un agent échoue : le remplacer, le mettre de côté, réduire le périmètre. Il faut aussi prévoir la reprise après incident, sans reprendre des tâches déjà terminées ni en perdre. Ces mécanismes s'ajoutent à la complexité, mais ils évitent qu'une défaillance locale se propage à l'ensemble. Une flotte solide se juge moins à sa vitesse de pointe qu'à sa manière de traverser une panne sans tout entraîner. Ces mécanismes s'éprouvent en amont, sur des scénarios provoqués volontairement, plutôt que le jour où une panne réelle impose de les improviser sous pression, sans marge d'erreur.
Surveiller et gouverner une flotte en croissance
Ce que fait un seul agent reste, à la rigueur, inspectable à la main. À cinquante, il faut des traces agrégées et des tableaux qui montrent ce qui se passe sans qu'on ait à ouvrir chaque dossier. On veut connaître la répartition des tâches, le nombre d'agents actifs, les échecs par type, le coût par opération réussie. Sans cette vue, on pilote à l'aveugle et l'on ne découvre les dérives qu'au moment où elles coûtent cher. La supervision n'est pas un luxe de fin de projet ; dès que la flotte compte, elle devient la condition pour la comprendre.
Gouverner va au-delà de la surveillance technique. Une flotte qui manipule des données clients tombe sous le RGPD, avec les obligations de minimisation, de sécurité et de durée de conservation. Plus les agents sont nombreux, plus les points d'accès aux données se multiplient et plus le contrôle devient difficile. Il faut donc limiter ce que chaque agent peut lire, tracer ce qui circule, et savoir couper un agent sans désorganiser le tout. La croissance d'une flotte est une croissance de surface d'exposition : ce qui gagne en capacité gagne aussi en risque à maîtriser.
Aller plus loin
Orchestrer plusieurs agents demande une architecture réfléchie et des garde-fous dès les premiers prototypes. Pour maîtriser ces systèmes, parcourez notre catalogue des 31 formations.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations