Les systèmes multi-agents butent presque tous sur le même mur.
Un axe de recherche sur l'orchestration d'agents, et ce qui reste à démontrer.
Holoboard est un travail de recherche. Il n'est pas déployé en production, il n'équipe aucune mission client, et nous n'avons pas de résultats chiffrés à publier. Cette page décrit ce que nous cherchons, pourquoi nous y consacrons du temps, et ce qui reste à démontrer.
Trois obstacles que nous avons rencontrés
Ils sont bien identifiés par ceux qui construisent réellement ces systèmes, et beaucoup moins par ceux qui en parlent.
Les rôles sont interdépendants. Ajouter une capacité oblige généralement à reprogrammer la mémoire, les rôles ou les descriptions des agents déjà en place, pour qu'ils apprennent à interagir avec la nouvelle entité. Le coût d'une fonctionnalité croît donc avec la taille du système — exactement ce qu'une architecture est censée éviter.
L'enchaînement d'outils se fait à un niveau trop bas. On assemble à la main des micro-fonctions, et l'on obtient des chaînes rigides, difficiles à modifier et fragiles à l'exécution.
Tout confier au modèle de langage n'est pas raisonnable. Là où un algorithme déterministe ferait le travail plus vite, pour un coût nul et un résultat prévisible, un appel de modèle ajoute de la latence, de la dépense et de l'incertitude.
Ce que nous essayons
Des agents qui ne se connaissent pas. Dans notre approche, aucun agent n'a besoin de savoir que les autres existent : leur description ne mentionne pas le reste du système. C'est la couche d'orchestration, elle seule, qui connaît les capacités disponibles et décide de les mobiliser. Si l'hypothèse tient, ajouter ou retirer une fonctionnalité n'oblige plus à toucher aux agents en place.
Trois natures d'exécutants, pas une. C'est le cœur de notre approche, et le point sur lequel nous nous écartons le plus des architectures courantes. L'orchestrateur choisit, selon la tâche :
- des agents codés en dur, quand la vitesse, la prévisibilité et le coût comptent plus que la souplesse ;
- des agents fondés sur un modèle de langage, quand il faut raisonner, synthétiser ou produire du code à la volée ;
- des agents humains, intégrés nativement dans la boucle pour les validations critiques et les arbitrages.
L'humain n'est pas un recours de secours quand la machine échoue : c'est une catégorie d'exécutant à part entière, prévue dans l'architecture.
Une abstraction de haut niveau. L'utilisateur soumet une demande unique. La couche d'orchestration l'évalue, la découpe, délègue et contrôle l'exécution — en laissant aux agents la latitude d'écrire ou d'exécuter du code selon le contexte, plutôt qu'en leur imposant une séquence figée.
Ce que nous n'avons pas encore
Nous n'avons pas de mesure comparative face aux architectures existantes. Nous n'avons pas de déploiement en conditions réelles. Et nous ne savons pas encore si le découplage des agents tient à grande échelle, ni ce qu'il coûte en performance d'orchestration.
Ce sont précisément les questions sur lesquelles porte la suite du travail. Nous publierons ce que nous mesurerons, y compris ce qui infirmera nos hypothèses.
Pourquoi une entreprise de vingt-cinq personnes fait de la recherche
Parce que les questions posées par Holoboard sont exactement celles que nous rencontrons en mission : jusqu'où déléguer à un modèle, où placer le contrôle humain, comment garder un système modifiable dans deux ans.
Cette recherche n'a pas encore produit de logiciel utilisable par nos clients. Elle a déjà produit une conviction, et celle-ci se retrouve dans notre manière de développer : ne pas confier au modèle ce qu'un algorithme fait mieux, et garder l'humain dans la boucle par conception plutôt que par précaution.
Un second axe : un moteur de reconnaissance de motifs générique
Nous explorons par ailleurs l'hypothèse qu'une séquence d'ADN et une matrice de pixels partagent les mêmes fondements mathématiques dès lors qu'il s'agit d'y repérer des régularités. Détecter une mutation génétique — insertion, délétion, substitution — et reconnaître une forme dans une image bruitée relèveraient alors d'une même abstraction.
Un premier prototype fonctionne. Nous n'en publions pas encore les résultats : le périmètre testé est trop étroit pour en tirer une conclusion. Les travaux se poursuivent sur le passage à l'échelle et la parallélisation sur processeurs graphiques.
Ces questions traversent aussi nos missions
Ce que nous cherchons en recherche, nous le pratiquons chez nos clients. Parlons de votre contexte.