Méthodologie du radar

Comment nous structurons notre démarche de veille

Deux axes principaux

La maturité (axe vertical)

Cet axe mesure la profondeur et la robustesse d’une solution aujourd’hui, selon trois dimensions :

  • Capacités : La solution peut-elle réellement planifier, raisonner et s’adapter de manière autonome ? Va-t-elle au-delà de l’interaction conversationnelle pour exécuter des actions dans des environnements dynamiques ?
  • Fiabilité : La solution est-elle stable en production ? Est-elle scalable lorsqu’on passe de 10 à 10 000 utilisateurs, résiliente lorsqu’une API externe tombe ? Les erreurs sont-elles gérées avec grâce plutôt que de provoquer des cascades de défaillances ?
  • Confiance : La solution est-elle déployable dans un environnement réglementé ? Les décisions de l’agent sont-elles explicables ? Les données sont-elles sécurisées ? Des garde-fous existent-ils pour prévenir les dérives ?

Le momentum (axe horizontal)

Cet axe mesure la vélocité d’une solution, sa capacité à engager une communauté d’utilisateurs, à se déployer dans les entreprises et à être reconnue sur le marché.

  • Vélocité : Quel est le rythme de release ? Quelle qualité de support et de documentation technique ? Quelle fréquence et profondeur des contributions dans les dépôts publics ?
  • Engagement : Y a-t-il une communauté active de développeurs contributeurs ? Combien d’intégrations tierces disponibles ? Quelle qualité des écosystèmes de plugins et d’outils ?
  • Traction : Combien de clients en production réelle (pas seulement des POCs) ? Quels partenariats stratégiques ? Quelle reconnaissance par les analystes indépendants ?

Quatre zones principales

En bas à gauche, les Innovateurs : à la frontière entre la recherche académique et les premières implémentations expérimentales. Ces solutions présentent une haute vélocité de publication et d’expérimentation — commits fréquents, articles arXiv, preuves de concept publiques — mais leur maturité de production est faible : APIs instables, documentation partielle, gestion des erreurs insuffisante pour un déploiement en conditions réelles. Ce sont les solutions qui façonneront les Builders et les Drivers de demain.

Zone médiane inférieure, les Builders : Les solutions en zone Builders ont franchi le seuil de la viabilité technique. Mais toutes les solutions en construction ne se ressemblent pas — le radar distingue deux sous-profils aux implications très différentes.

  • Les Maturity Builders ont du momentum mais investissent principalement dans la profondeur : ils consolident leur architecture interne, renforcent la gestion des erreurs, étoffent leur documentation technique, construisent les fondations de la production-readiness. Leur communauté est plus restreinte mais plus qualifiée (contributeurs core, architectes enterprise).
  • Les Momentum Builders, à l’inverse, capitalisent sur l’adoption rapide : intégrations multiples, écosystème de plugins qui s’étend, star count en progression rapide, releases fréquentes — mais chaque release peut introduire des breaking changes, et la gestion de la dette technique est secondaire par rapport à l’acquisition d’utilisateurs.

La Zone médiane supérieure, les Drivers : ces solutions ont atteint le seuil critique où maturité et momentum se renforcent mutuellement. Ici aussi, le radar distingue deux sous-profils stratégiquement distincts.

  • Les Maturity Drivers ont construit leur position depuis la maturité : historiquement robustes, battle-tested en production critique, avec des processus de release conservateurs qui préservent la stabilité mais ralentissent l’adoption des nouvelles capacités. Leur momentum est réel mais prudent.
  • Les Momentum Drivers ont construit leur position par l’adoption et le consolident par la maturité : communauté large, écosystème riche, mais ils ont su traverser le mur de la production-readiness sans perdre leur vélocité.

En haut à droite, les Leaders : Ces solutions combinent une maturité de production démontrée à grande échelle et un momentum suffisamment fort pour maintenir leur avance technologique. Elles supportent les contraintes des systèmes critiques — scalabilité, résilience, auditabilité, conformité réglementaire — tout en continuant à intégrer les nouvelles capacités au rythme du marché. Ce sont les valeurs sûres des portefeuilles technologiques enterprise.

Le processus d’évaluation

Quatre piliers

Ce radar s’appuie sur des recherches profondes à base d’IA appuyées par des humains : documentation technique, discussions sur Discord et GitHub, publications scientifiques, suivi des commits. L’IA accélère la veille en parsant des milliers de messages de forums, extrayant les tendances et identifiant les signaux faibles. Les publications académiques — notamment sur arXiv — constituent une source d’anticipation précieuse, révélant les architectures qui feront les frameworks d’après-demain.

Nous y ajoutons les retours terrain de nos experts : lorsque des frameworks comme LangGraph ou Strands Agents ont été implémentés chez des clients, les architectes et développeurs apportent une expérience concrète irremplaçable — ce qui fonctionne vraiment, ce qui est difficile à maintenir, où sont les pièges. Ces retours terrain rééquilibrent les évaluations qui pourraient être biaisées par le marketing des éditeurs.

Nous enrichissons les analyses par des mini-POCs ciblés, pilotés par IA, supervisés par humains : des agents testent des fonctionnalités spécifiques — gestion de raisonnement multi-étapes, robustesse de la gestion d’erreurs, comportement sous charge. Les promesses sont validées empiriquement. Les benchmarks ciblés comparent les mêmes tâches avec les mêmes contraintes pour mesurer performance, stabilité et consommation de tokens de manière objective.

Enfin, nous effectuons des benchmarks sur des scénarios standardisés : même tâche, mêmes contraintes, mêmes ressources allouées. Cette rigueur comparative est d’autant plus importante que certains modèles ont démontré une capacité à identifier quand ils sont en cours d’évaluation — un cas réel a été documenté lorsqu’un modèle a explicitement reconnu être en cours d’analyse comparative après avoir trouvé le protocole de test en ligne.

Principes d’intégrité

Deux principes gouvernent le processus. D’abord, les critères exacts de notation ne sont pas publiés : dans un monde où les solutions agentiques peuvent elles-mêmes accéder aux benchmarks en ligne, la publication des critères exacts introduirait un biais, en incitant les solutions à se calibrer sur l’évaluation plutôt qu’à démontrer leur maturité réelle. Ensuite, le radar est développé, mis à jour et alimenté par un outil 100% interne nommé Elio, une plateforme d’agents à destination de nos talents. Ceci élimine tout biais de préférence et conflit d’intérêts.

Ces principes s’inspirent directement des meilleures pratiques d’évaluation indépendante en vigueur dans d’autres secteurs (audit financier, tests pharmaceutiques). Un framework qui évalue lui-même les frameworks — en utilisant l’un d’eux comme outil d’évaluation — introduirait un biais structurel difficile à quantifier et impossible à corriger après coup.

Typologie des solutions

Distinction des types de solutions agentiques Afin de distinguer les nuances dans les fonctionnalités techniques des différentes solutions disponibles, nous distinguons trois types de solutions :

  1. Les agents individuels : unités fonctionnelles autonomes capables de percevoir leur environnement, raisonner, prendre des décisions et agir. Leur architecture intègre des modules de perception, de mémoire (court terme / long terme), de raisonnement (LLMs) et d’action via des outils. Les patterns d’implémentation des agents individuels se retrouvent autour de quelques architectures stables — ReAct, Plan-and-Execute, Reflection — qui font office de primitives de conception.
  2. Les frameworks d’orchestration : structurent la logique de coordination entre agents. Les patterns d’architecture — agents hiérarchiques, réseaux pairs-à-pairs, systèmes collaboratifs — se définissent à cette couche. Un système multi-agent bien conçu s’apparente à une architecture microservices : chaque agent spécialisé (Parser, Critic, Dispatcher, Executor) possède un périmètre de responsabilité défini, et la coordination émerge de leurs interactions protocolisées. Les décisions prises ici ont un impact direct sur la maintenabilité, la testabilité et la scalabilité à long terme.
  3. Les « Managed Agent Runtime » : orchestrent l’exécution à grande échelle, avec des capacités d’observabilité, de traçabilité, de FinOps et de gouvernance. Souvent fournie par des hyperscalers (Azure AI Foundry, AWS Bedrock AgentCore, Google Cloud Vertex AI) ou des plateformes SaaS (Salesforce Agentforce, ServiceNow AI Agents), cette couche concentre les principaux enjeux de lock-in. IDC projette que d’ici 2027, 80% des cas d’usage agentiques nécessiteront un accès aux données, en temps réel, et contextuel, ce qui rend le choix de la couche runtime encore plus stratégique.