Le chef d'orchestre comme réconciliateur
- De l’état actuel à l’état cible
- Comment conserver à jour l’état d’une plateforme qui bouge tout le temps ?
- Réconcilier les deux mondes
- La théorie est bien belle — la réalité est semée d’embûches
- Une partition commune pour le Cloud et l’IA
Le point d’entrée, ce sont des besoins d’environnements dans le Cloud — avec ou sans IA — pour des projets spécifiques. Le point de sortie, c’est une plateforme dont l’état se rapproche au mieux de ce que l’utilisateur a demandé. Entre les deux se trouve l’état actuel de la plateforme, et le travail de l’orchestrateur consiste précisément à réduire l’écart.
Les projets des utilisateurs s’appuient sur des ressources variées, mais l’architecture reste généralement cohérente : un point d’entrée (web ou API), une « intelligence » chargée des traitements (qui inclut de plus en plus souvent de l’IA), et des sources de données. D’autres briques peuvent s’ajouter — cache pour accélérer certaines lectures, bus de messagerie pour les échanges asynchrones — comme nous l’avons déjà vu au niveau de l’orchestrateur lui-même.
Dans ce paysage, l’orchestrateur est la brique principale chargée de résoudre l’écart entre l’état désiré par l’utilisateur et l’état réel de la plateforme, tout en respectant les contraintes de l’un et les limites de l’autre. Pour cela, le premier élément que nous allons examiner est le control plane : le cerveau de l’orchestrateur.
De l’état actuel à l’état cible
Nous l’avons vu dans notre précédent article : un orchestrateur fonctionne comme un système déclaratif. L’utilisateur (ou le système métier qu’il utilise) déclare un état désiré ; le control plane a pour mission de faire converger le système vers cet état. L’état de la plateforme n’est lui-même que la somme des états de ses composants — machines virtuelles, stockage, réseau, mais aussi services d’intelligence artificielle (modèles, agents, applications).
Comment conserver les demandes utilisateur
Lorsque le control plane reçoit une demande, il ne peut pas toujours l’appliquer instantanément. Il doit donc mémoriser les informations le temps de les traiter.
Le premier réflexe serait de s’appuyer sur un système de cache. Ces solutions stockent efficacement des données simples pour une durée limitée. Mais une opération Cloud est rarement simple : nous manipulons des objets liés les uns aux autres (un volume monté sur une machine virtuelle, une adresse réseau associée à une instance, etc.). La complexité des relations et la nécessité de conserver ces informations durablement dépassent ce que la plupart des caches savent bien faire.
L’usage habituel est donc de s’appuyer sur une base de données. Les bases relationnelles stockent les objets sous forme de lignes et de colonnes, et gèrent explicitement les relations entre eux. Elles offrent aussi une robustesse importante : redondance, transactions fiables, capacité à ne rien perdre en cas d’incident. Des alternatives existent — bases dites « NoSQL », plus souples sur la structure des données — et le choix dépendra des besoins précis de la plateforme. L’essentiel est de retenir qu’évaluer ces différents modèles fait partie du travail de conception d’un orchestrateur.
Du côté de l’IA, une piste intéressante s’ouvre avec les bases de données vectorielles, ou avec des extensions comme pgvector pour PostgreSQL. Ces outils permettent de stocker, à côté des données classiques, des représentations numériques optimisées des segments d’information que les modèles manipulent. Nous avions déjà rencontré ces vecteurs dans nos fondamentaux de l’IA : ils offrent un moyen compact et efficace de retrouver du contexte ou de reprendre une tâche interrompue. Conserver ces représentations au sein du control plane peut donc faciliter le suivi et la reprise des traitements IA.
Comment conserver à jour l’état d’une plateforme qui bouge tout le temps ?
Les informations sur l’état réel de la plateforme sont dispersées chez chaque agent. Aller les interroger en temps réel à chaque demande (approche « pull ») générerait une charge réseau excessive et des sollicitations trop fréquentes. Une offre Cloud s’adresse à un public large : le volume de requêtes est élevé, et chaque ressource multiplie les allers-retours. Nous privilégions donc l’approche inverse : ce sont les agents qui poussent à chaque événement traité leurs informations vers une base consultable par le control plane (approche « push »).
En complément, un système de télémétrie placé au plus près des composants permet de suivre la santé de la plateforme — latences, erreurs, saturations — et d’alimenter le control plane au-delà de l’état des ressources.
Ces remontées deviennent encore plus critiques avec l’IA. Certains agents peuvent s’engager dans des traitements beaucoup plus longs que ceux auxquels le Cloud nous a habitués. Il faut alors pouvoir suivre des états d’avancement, et non plus seulement des états binaires « terminé / en cours ». Les données vectorielles mentionnées plus haut jouent ici un rôle utile : elles facilitent la reprise d’une tâche interrompue, par exemple après une erreur. Elles sont également précieuses lorsque plusieurs agents s’enchaînent (ce que nous appelons parfois « Agent-to-Agent » ou A2A) : le résultat d’un traitement doit pouvoir être transmis proprement au suivant.
L’environnement IA est souvent plus hétérogène que celui du Cloud classique. Les informations remontées peuvent provenir d’un protocole comme MCP, d’une source de données métier, ou directement de l’agent. Choisir soigneusement le modèle de stockage de l’état devient alors indispensable pour couvrir cette variété de situations.
Réconcilier les deux mondes
Nous avons beaucoup parlé d’états. Il est temps de préciser ce qu’ils contiennent réellement, et comment le control plane s’en sert pour faire converger le système.
États certes, mais états de quoi ?
L’état de la plateforme n’est rien d’autre que la collection des états de ses ressources. Chaque ressource suit un cycle de vie : une suite d’étapes ordonnées, avec des transitions autorisées entre elles.
Prenons une machine virtuelle. Elle est créée dans un état « creating », puis « created ». Nous la démarrons ensuite, soit « starting », puis « running ». Nous pouvons ensuite l’arrêter (« stopping », puis « stopped ») ou la redémarrer. Certains états sont transitoires — le temps que l’action se termine —, d’autres sont stables jusqu’à la prochaine intervention de l’utilisateur.
Un GPU — carte graphique physique ou virtuelle — suit un chemin plus simple : il s’alloue, s’attache à une machine, puis se libère. Dans le contexte de l’IA, il sert aussi bien à l’entraînement de modèles qu’à l’exécution de services d’inférence.
Dans tous les cas, l’état décrit la position de la ressource dans son cycle de vie. Il peut être déclenché par une action utilisateur, rester temporaire le temps d’atteindre la cible, ou devenir permanent jusqu’à la prochaine demande. C’est cette vision en états et en transitions qui permet au control plane de raisonner sans avoir à connaître le détail interne de chaque composant, que nous pouvons transposer sur des services IA.
Cas d’usages pour l’IA
Pour notre cas d’usage, nous distinguons trois grandes catégories de services d’intelligence artificielle. Les modèles sont déployés une fois de sorte que les utilisateurs puissent les interroger par API depuis d’autres projets. Nous pouvons nous les représenter comme des VM hébergeant un service (ce qui est finalement assez proche de la réalité) : une fois démarré, le modèle est joignable jusqu’à son arrêt.
Nous considérons les agents comme des modèles spécialisés pour des tâches précises où le traitement sémantique est pertinent. Pour cela, ils sont démarrés avec un contexte définissant leur rôle, les outils auxquels ils ont accès, et parfois une mémoire.
Enfin, nous définissons une application comme une solution complète orchestrant un ou plusieurs modèles ou agents sous forme de graphes ou de sessions multi-agents pour ses traitements — par exemple avec un outil comme LangGraph.
Ces outils pourront nécessiter des accès à des bases de connaissances hétérogènes (avec textes, images, etc.) et non structurées, pour réaliser les tâches qui leur sont soumises. Par exemple, un agent pourrait traiter la correspondance entre des CV et des offres d’emploi, même si l’un et l’autre ne respectent pas de modèle précis.
Quoi qu’il en soit, toutes ces solutions possèdent un cycle de vie identifiable.
Les états des services d’IA
Un agent peut ainsi passer par « pending » (en attente de ressources), « initializing » (chargement du modèle et des outils), « running » (exécution), « completed » ou « failed ». Un workflow multi-agents enchaîne ces états à l’échelle d’un graphe : chaque nœud a le sien, et l’état global en découle.
Ce qui compte pour le control plane, ce n’est pas le contenu sémantique de l’exécution — le raisonnement, les prompts, les outils appelés ou le texte produit. Il ne voit qu’un ensemble d’états et de transitions autorisées. Il sait que nous pouvons passer de « running » à « completed », mais pas directement de « pending » à « completed ». C’est cette machine à états, et non la signification des actions, qui lui permet de réconcilier l’état désiré et l’état réel.
Réconcilier en continu
Une fois le modèle unifié en place — ressources Cloud et entités IA partagent la même façon d’être représentées —, nous pouvons dérouler la boucle qui constitue le cœur du control plane. Elle tourne en continu, à un rythme adapté à chaque type de ressource.
1. Observer l’état réel : Le control plane consulte la base d’état (alimentée par les push des agents et par la télémétrie) pour connaître la situation actuelle de chaque ressource concernée. Pour un agent IA, cela peut inclure un pourcentage d’avancement.
2. Comparer avec l’état désiré : Il confronte cet état réel à celui déclaré par l’utilisateur. S’ils coïncident, rien à faire. Sinon, un écart — le delta — apparaît.
3. Calculer le delta : À partir de la machine à états de la ressource, le control plane détermine les transitions autorisées qui permettent de combler l’écart. Faire passer une machine de « stopped » à « running » implique une commande de démarrage.
4. Émettre des commandes : Les actions nécessaires partent via le bus de messagerie vers les agents compétents. Elles restent aussi simples et atomiques que possible : créer, démarrer, arrêter, attacher, mettre à jour…
5. Vérifier la convergence : Soit l’agent transmet des nouvelles de l’action, soit le control plane observe à nouveau après un délai donné. Si l’état réel s’est rapproché de la cible, la boucle continue. En cas d’échec, de dépassement de délai ou d’erreur, des mécanismes de nouvelle tentative, de retour arrière ou d’escalade se déclenchent.
Cette boucle transforme une déclaration d’intention (« je veux cet agent en production avec ces paramètres ») en une série d’actions concrètes et vérifiables. Elle fonctionne de la même façon pour une machine virtuelle et pour un workflow multi-agents : seules changent la durée des états et la fréquence des observations.
La théorie est bien belle — la réalité est semée d’embûches
Sur le papier, la réconciliation paraît élégante. Dans la pratique, plusieurs difficultés viennent compliquer la résolution du delta entre l’état désiré et l’état réel.
Les défis généraux de la réconciliation
L’idempotence, d’abord. Une commande doit pouvoir être émise plusieurs fois sans produire d’effets indésirables. Créer une machine qui existe déjà ne doit pas en créer une seconde ; démarrer une instance déjà démarrée ne doit rien changer. Sans cette propriété, les nouvelles tentatives automatiques deviennent dangereuses.
Les conflits entre états désirés, ensuite. Dans un environnement multi-équipes, deux projets peuvent réclamer les mêmes ressources en même temps, ou un utilisateur peut vouloir arrêter ce qu’un autre souhaite maintenir. Le control plane doit alors arbitrer : priorités (la production prime sur l’expérimentation), politiques d’attribution (premier arrivé, quotas par entité…), et, si les règles automatiques ne suffisent pas, escalade vers un opérateur humain.
L’allocation de capacité, enfin. Il ne s’agit plus seulement de distribuer des machines virtuelles. Il faut aussi répartir de la capacité de calcul spécialisée, des budgets de tokens, des créneaux d’agents, ou des priorités sur le bus de messagerie. Avant d’autoriser une transition vers « running », le control plane vérifie que les ressources composites nécessaires sont bien disponibles.
Lorsqu’une action échoue, des stratégies de retour arrière ou de compensation doivent entrer en jeu. Des mécanismes de protection — isolation temporaire d’un composant défaillant, freinage des nouvelles commandes lorsque le système sature — permettent de préserver la stabilité globale de la plateforme.
Ce que change l’IA
Le piège serait de croire que tout se comporte exactement comme une machine virtuelle. Certains aspects restent plus subtils.
Les effets de bord non idempotents deviennent plus fréquents. Un agent qui envoie un e-mail ou écrit dans une base externe produit un effet difficilement réversible. Relancer la même commande après un délai dépassé peut alors envoyer le message deux fois. Pour limiter le risque, les agents doivent détecter les commandes déjà traitées (par exemple via un identifiant unique comme un id de requête ou de session), le control plane peut marquer certaines transitions comme non rejouables, et les actions critiques peuvent passer par des confirmations intermédiaires explicitement modélisées dans la machine à états.
Certains agents peuvent nécessiter une validation humaine, ce qui ajoute une autre dimension. Cependant, ces cas de figure peuvent être traités comme un état final stable, car celui-ci correspond déjà au moment où nous rendons la main à l’utilisateur pour poursuivre son travail. Dans ces cas-là, conserver le contexte, par exemple via une base de données vectorielle, permet précisément une reprise ultérieure.
Les durées changent : certains états IA sont très brefs, d’autres s’étendent sur des heures. Les premiers se traitent comme l’allocation rapide d’un GPU ; les seconds, comme une machine virtuelle qui reste longtemps en service. Certaines actions elles-mêmes peuvent être très brèves et être traitées comme des actions ponctuelles. Dans tous les cas, la condition sine qua non reste la même : l’agent doit remonter fidèlement son état pour que le control plane reste à jour.
Une partition commune pour le Cloud et l’IA
Le control plane assure la cohérence de la plateforme en traitant l’état des ressources, qu’elles soient classiques ou issues de l’IA.
Du point de vue de ce cerveau, la plupart des entités IA peuvent être modélisées comme des ressources à cycle de vie, exactement comme une machine virtuelle ou un GPU. Elles possèdent un ensemble d’états (désiré et actuel). Le control plane n’a pas besoin de savoir comment l’agent raisonne ni quel modèle il utilise : il lui suffit de connaître l’état cible, l’état observé, et les actions autorisées pour faire converger l’un vers l’autre. La durée d’exécution change surtout la fugacité de certains états et la fréquence des remontées, pas le modèle mental de réconciliation lui-même.
Cette simplification permet de réutiliser le raisonnement classique de l’orchestration Cloud — réconciliation, idempotence, nouvelles tentatives, retours arrière, observation des états — sans inventer une logique spécifique « parce que c’est de l’IA ».
La réconciliation est le mécanisme qui compare un état désiré à un état actuel et décide des transitions. Traiter un agent, un graphe ou un workflow comme une ressource à états, c’est fournir le modèle concret sur lequel cette boucle s’applique. Sans ce modèle, la réconciliation reste vague. Avec lui, elle devient transposable.
Via le bus de messagerie — système nerveux du control plane — celui-ci communique avec les agents, qui agissent comme les terminaisons nerveuses de l’orchestrateur. Ils font l’interface avec le matériel et les hyperviseurs : d’un côté, ils remontent l’état de la plateforme ; de l’autre, ils agissent sur cet état. Nous explorerons ce maillon essentiel dans un prochain article.
Write a comment