
J’ai passé 5 jours à la conférence la semaine dernière (incluant l’atelier de la veille) et j’en suis ressorti avec de bonnes idées, des réponses à mes questions et une foule de points à approfondir.
Si l’année dernière était axée sur Microsoft 365 Copilot, cette année était celle des agents. Les AI Agents ne sont pas nouveaux, mais ce qui est intéressant dans ce monde axé sur les agents, c’est qu’ils reposent sur l’utilisation de modèles de langage, qu’ils soient vastes (LLM) ou restreints (SLM), même si ce n’est pas leur tâche principale. Un agent intelligent est, par définition, une application capable d’exécuter une tâche de manière autonome. Vous lui demandez de résumer une transcription, d’exécuter un code ou simplement de vous donner l’heure, et il s’exécute. Vous n’avez pas besoin de savoir comment il fonctionne ni nécessairement quand il vous répondra, mais vous pouvez généralement compter sur l’accomplissement de la tâche. Cela ressemble beaucoup aux services ou aux API dans le monde du logiciel. En intégrant des modèles de langage, nous pouvons toutefois orchestrer et faire communiquer les agents entre eux en langage naturel, ce qui offre un potentiel incroyable pour les systèmes intelligents.
Bien que les API soient utiles, elles exigent un contrat bien défini entre les points de terminaison. Elles attendent une requête formatée précisément et fournissent une réponse tout aussi structurée. Un développeur doit connaître ces deux aspects pour utiliser le service via l’API, et si ce contrat change, tous les utilisateurs du service doivent mettre à jour leur code en conséquence. Les interfaces LLM changent la donne en offrant une plus grande flexibilité. Par exemple, je pourrais demander à un agent temporel « Quelle heure est-il ? » et il pourrait répondre « 16 h 30 », « 16 h 30 le 24 novembre 2025 » ou même « Quatre heures et demie » si l’agent a une tournure particulièrement britannique. Comme la réponse est également destinée à être traitée par un LLM, ces variantes seraient probablement prises en charge et l’agent aurait rempli sa mission.
Ce qui rend les agents passionnants, c’est leur capacité à étendre les fonctionnalités des systèmes intelligents de manière modulaire en mettant en œuvre des fonctions distinctes, ce qui évite de devoir créer une IA omnisciente et globale. Il existe également des fonctionnalités qui améliorent ice sans nécessiter de changements au produit. Il est déjà possible d’utiliser Microsoft 365 Copilot pour analyser un appel en cours dans Microsoft Teams, donc je soupçonne que le nouvel interprète (traduction en temps réel) et la compréhension de contenu (Copilot accédant au contenu partagé à l’écran) fonctionneront également dès leur sortie.
Cependant, disposer d’agents ne sert à rien sans un moyen de les trouver, et c’est là qu’intervient un orchestrateur d’agents. Un orchestrateur d’agents est en fait la « porte d’entrée » de toute conversation avec une IA et est responsable de savoir comment traiter une requête, y compris quels AI Agents doivent être sollicités. Cela signifie qu’il doit savoir quels agents existent et ce qu’ils peuvent faire. Cette complexité est accrue par le fait qu’un agent peut lui-même orchestrer d’autres agents, créant ainsi un graphique qui commence à ressembler à un organigramme.
À Ignite, plusieurs méthodes d’orchestration ont été abordées, mais toutes de manière assez sommaire. Évidemment, Microsoft 365 Copilot a été présenté comme un exemple d’orchestrateur, mais d’autres solutions s’appliquaient aux applications personnalisées. Dans l’idéal, l’orchestration des agents se ferait par une description en langage naturel de leurs capacités, par exemple « cet agent renvoie l’heure actuelle » pour un agent temporel. Certains exemples utilisaient toutefois un flux d’orchestration plus manuel, invoquant manuellement des éléments comme un agent de recherche, un agent d’annotation et un agent de personnalisation avant de composer une réponse finale. Ces deux architectures ont leur place et sembleront probablement très familières à quiconque a travaillé avec un centre de contact. Dans ice, le flux de travail est la plateforme d’orchestration des agents, et les agents sont soit des flux de travail, soit des blocs de construction, soit des agents humains pour lesquels nous définissons des règles d’implication dans les demandes de service.
Au-delà de l’architecture des agents, j’en ai appris davantage sur la façon dont le réglage fin multi-LoRA peut être appliqué pour intégrer des connaissances et du jargon. Plus important encore, j’ai discuté avec des experts des meilleures pratiques sur la façon et le moment où une approche de réglage fin est pertinente par rapport à une approche RAG (génération augmentée par récupération). Bien sûr, l’ajout d’agents permet une approche combinant les deux, ce qui s’harmonise d’ailleurs très bien avec ce que notre équipe expérimente déjà.
De plus, j’ai pu découvrir l’utilisation de chaînes d’outils dans les applications d’IA générative (qui fonctionnent elles-mêmes comme des agents), ce que je n’avais pas vraiment eu l’occasion d’expérimenter auparavant, ce qui a inspiré des idées pour de futures fonctionnalités du centre de contact ice.
Il existe également de nouvelles fonctionnalités intéressantes qui méritent d’être explorées davantage :
L’un des grands avantages d’une conférence comme Ignite est la possibilité de passer une semaine à échanger avec des personnes intéressantes, à apprendre de nouvelles choses et à réfléchir à l’avenir de notre entreprise. Changer d’environnement et recevoir de nouveaux stimuli suscite toujours de nouvelles idées, et je reviendrai l’année prochaine avec une bonne liste de choses que je souhaite essayer.
Au terme de l’événement de cette année, je suis convaincu que ComputerTalk est en excellente position concernant nos AI Insights et enthousiaste quant à ce que nous serons en mesure d’accomplir par la suite.