orchestration

En profondeur

Dès qu’un système fait travailler plus d’une pièce, quelqu’un doit répondre à des questions qui n’ont rien à voir avec le modèle : dans quel ordre appeler, que faire quand un appel échoue ou traîne, combien de fois réessayer, comment éviter de refaire deux fois la même chose, et où reprendre si tout s’arrête au milieu. Ces questions sont celles de n’importe quel système distribué, et elles se posent identiquement que la pièce coordonnée soit un modèle ou une base de données. C’est pourquoi l’orchestration relève de l’ingénierie ordinaire, et non d’une spécificité de l’IA.

Ce qui change avec un modèle, c’est que les appels sont lents, chers et non déterministes. Une reprise mal conçue ne coûte pas seulement du temps : elle repaie l’intégralité du contexte, et peut produire une réponse différente de la première tentative. L’orchestration doit donc savoir ce qui a déjà été fait, ce qui peut être rejoué sans dommage, et ce qui ne doit surtout pas l’être, comme un paiement ou un envoi. Cette distinction se conçoit avant l’incident, pas pendant.

La confusion fréquente consiste à croire qu’ajouter une couche d’orchestration rend un système agentique, ou l’inverse, qu’un système agentique se dispense d’orchestration. Les deux sont faux. Un enchaînement écrit à l’avance et parfaitement orchestré reste un workflow, puisque personne ne choisit la prochaine étape à l’exécution. Et un agent a d’autant plus besoin d’orchestration qu’il enchaîne des tours imprévisibles : c’est elle qui pose les limites de temps, de dépense et de nombre de tentatives.