Agents no-code : Google et Microsoft se disputent l’automatisation en entreprise

L’agent d’intelligence artificielle est devenu l’une des promesses les plus concrètes de la vague générative : non plus seulement répondre à une question, mais consulter une base de connaissances, retrouver une information dans un outil métier, déclencher une action et restituer un résultat. La compétition qui se joue entre Google et Microsoft, au 26 avril 2025, porte donc sur une ambition très pratique : permettre à davantage d’entreprises de créer ces assistants sans devoir développer chaque brique logicielle à partir de zéro.

Le terme « no-code » résume cette ambition, parfois un peu trop vite. Derrière une interface visuelle et des réglages en langage naturel, il faut encore choisir les données auxquelles l’agent a droit d’accéder, définir les actions qu’il peut accomplir et vérifier qu’il répond correctement. Mais en abaissant la barrière technique, les grands fournisseurs de cloud espèrent installer leurs plateformes au cœur des processus métier, de la relation client aux recherches documentaires internes.

Un agent no-code, qu’est-ce que cela change vraiment ?

Un agent IA se distingue d’une simple fenêtre de discussion par sa capacité à combiner plusieurs éléments. Un grand modèle de langage interprète la demande, mais il s’appuie aussi sur des instructions, des sources de données et des outils externes. Par exemple, un agent interne peut répondre à une question sur une procédure, retrouver le bon document, puis transmettre une demande dans un logiciel de gestion.

Les outils no-code cherchent à assembler ces composants à l’aide de formulaires, de connecteurs prêts à l’emploi et de blocs visuels. L’objectif n’est pas de faire disparaître les équipes informatiques. Il est plutôt de leur éviter de construire systématiquement les fondations techniques, tout en donnant aux équipes métier une place plus directe dans la conception des assistants.

La difficulté centrale consiste à relier de manière fiable le raisonnement probabiliste d’un modèle de langage à des actions concrètes. Un modèle peut suggérer une démarche plausible, mais un outil professionnel doit savoir précisément quelle base consulter, quelle information afficher et à quel moment s’arrêter. C’est dans cette orchestration que Google et Microsoft cherchent à se différencier.

Google privilégie l’orchestration et les connexions aux outils

Côté Google, Vertex AI Agent Builder constitue l’une des principales portes d’entrée pour concevoir des agents. La plateforme s’inscrit dans l’environnement cloud de Google et vise à faciliter l’intégration d’API, c’est-à-dire les interfaces qui permettent à des logiciels d’échanger des données et d’exécuter des commandes. Cette capacité est décisive : un agent utile en entreprise ne doit pas rester isolé dans une conversation, il doit pouvoir se connecter aux outils existants.

L’approche de Google met ainsi l’accent sur l’orchestration. Dans ce contexte, orchestrer signifie coordonner les différentes étapes d’une requête : identifier la bonne source, appeler un service externe si nécessaire, récupérer une donnée, puis présenter une réponse adaptée. La publication d’origine cite également Agent Designer, ainsi que l’offre Agentspace, destinée à élargir les possibilités de connexion avec des services et des données d’entreprise.

Cette stratégie peut attirer les organisations déjà fortement présentes dans l’écosystème Google Cloud. La promesse est de réduire les frictions entre l’agent, les données internes et les services tiers. Elle ne dispense toutefois pas d’un travail de cadrage. Connecter beaucoup d’outils ne garantit ni la pertinence des réponses, ni une gouvernance claire des accès.

Google cherche donc moins à vendre un simple robot conversationnel qu’une couche capable d’organiser des expériences personnalisées. Pour une entreprise, cette orientation soulève une question simple : peut-elle relier l’agent à ses systèmes réels sans multiplier les développements spécifiques ?

Microsoft mise sur une prise en main plus familière

Microsoft avance avec Copilot Studio et le service d’agents d’Azure. La complémentarité est importante. Copilot Studio s’adresse notamment aux professionnels qui souhaitent bâtir ou personnaliser un agent dans une interface accessible, tandis que l’environnement Azure offre des possibilités plus poussées pour les équipes de développement et les organisations ayant des besoins de déploiement, de contrôle ou d’intégration plus complexes.

L’un des atouts mis en avant est la possibilité de connecter des agents à des bases de données et à des applications largement déployées dans les entreprises, notamment Salesforce et SAP. Dans les faits, cette promesse répond à une attente forte des directions métier : éviter de créer un nouvel espace de travail séparé, et rapprocher l’IA des outils où se trouvent déjà les informations commerciales, financières ou opérationnelles.

Microsoft cherche ainsi à couvrir un large éventail d’usages. Un responsable métier peut concevoir un premier assistant pour guider des salariés ou répondre à des questions récurrentes. Une équipe technique peut, de son côté, aller plus loin dans la personnalisation, les connexions aux systèmes internes et la mise en production.

Cette accessibilité ne doit pas être confondue avec une autonomie sans limite. Plus un agent est autorisé à consulter des applications, plus les règles de sécurité, les rôles des utilisateurs et les mécanismes de validation doivent être précis. Un assistant qui lit une documentation interne ne présente pas le même niveau de risque qu’un agent susceptible de modifier un dossier client ou d’envoyer une demande dans un système de gestion.

L’intégration vaut souvent plus que la démonstration

La rivalité entre les deux groupes ne se résume pas à la qualité d’un modèle de langage. Dans un usage professionnel, l’agent le plus impressionnant en démonstration n’est pas forcément le plus utile. La valeur dépend souvent de sa capacité à retrouver une information à jour, à respecter les autorisations existantes et à s’intégrer dans les habitudes de travail.

C’est pourquoi les connecteurs, les API et les mécanismes d’orchestration prennent une place centrale. Ils déterminent si l’agent peut accéder à une base documentaire, à un logiciel de relation client ou à un progiciel de gestion, sans créer de silos supplémentaires. Ils déterminent aussi la facilité avec laquelle une entreprise peut remplacer un outil, ajouter une source ou maintenir son agent dans le temps.

Pour les utilisateurs, le choix ne doit donc pas se faire sur la seule promesse du « sans code ». Il faut regarder l’écosystème déjà en place, les logiciels critiques, le niveau de contrôle requis et les compétences disponibles en interne. Une interface intuitive est utile pour prototyper rapidement. Elle devient insuffisante si l’agent doit intervenir dans des processus sensibles sans supervision adaptée.

La rentabilité reste à démontrer face aux solutions ouvertes

La question économique reste ouverte. Selon un rapport du cabinet AI Builder cité dans la publication d’origine, les offres no-code des hyperscalers, ces très grands fournisseurs de cloud, n’avaient pas encore démontré une efficacité économique supérieure à celle de frameworks open source tels que LangChain.

La comparaison mérite d’être précisée. Un framework comme LangChain donne aux développeurs davantage de liberté pour assembler les composants d’une application d’IA. Il peut permettre un contrôle fin de l’architecture et des coûts, mais il exige aussi des compétences techniques, du temps d’intégration et des efforts de maintenance. À l’inverse, une plateforme gérée peut simplifier le déploiement, la sécurité et l’exploitation, mais son coût dépend des volumes traités, des modèles choisis, des connecteurs et du niveau de service demandé.

Il n’existe donc pas de verdict universel. Pour un prototype, le no-code peut accélérer fortement la mise en route. Pour un usage à grande échelle, l’entreprise devra examiner le coût réel par requête, les dépenses liées aux modèles, le temps de supervision humaine et les éventuels travaux d’intégration. L’automatisation ne produit un gain que si elle réduit véritablement une tâche, sans déplacer la charge vers le contrôle des erreurs.

AWS, un concurrent moins visible mais incontournable

La confrontation Google-Microsoft ne doit pas effacer AWS du paysage. Amazon conserve un rôle central grâce à sa vaste communauté d’utilisateurs et à une documentation importante pour les développeurs. Son offre Amazon Bedrock, qui permet d’exploiter des modèles d’IA générative dans le cloud, inclut des fonctions pour créer des agents personnalisés.

L’approche d’AWS apparaît principalement pensée pour un public technique. Elle met à disposition des kits de développement et des mécanismes permettant d’intégrer des outils sur mesure. Cela peut être moins immédiatement accessible qu’une interface no-code orientée métier, mais représente un avantage pour les équipes qui souhaitent garder la main sur chaque composant de leur application.

La présence d’AWS rappelle que ce marché ne se joue pas seulement entre deux plateformes. Les entreprises disposent aussi de solutions ouvertes et de fournisseurs spécialisés. Le choix dépendra donc de l’équilibre recherché entre rapidité de création, simplicité d’administration, liberté technique et intégration avec le cloud déjà utilisé.

Ce qu’il faut surveiller dans la course aux agents

Au 26 avril 2025, le marché est encore loin d’être figé. Google et Microsoft affinent leurs offres, tandis que de nouveaux acteurs tentent de se faire une place. La startup Dev Agents, dirigée par d’anciens responsables technologiques selon les informations alors disponibles, a récemment levé des fonds pour développer des agents répondant à des besoins plus spécifiques.

Les prochains mois devraient surtout départager les plateformes sur des critères très concrets. Les entreprises demanderont des connecteurs plus nombreux, mais aussi plus faciles à administrer. Elles chercheront des agents capables de travailler avec plusieurs sources sans confondre les informations, de justifier leurs actions et de limiter les erreurs. Elles évalueront enfin la capacité de chaque offre à passer d’une démonstration convaincante à un service fiable, sécurisé et économiquement soutenable.

La bataille des agents no-code est donc aussi une bataille pour le contrôle de l’environnement de travail numérique. Google mise sur l’orchestration de services et de données connectés. Microsoft s’appuie sur une expérience intégrée aux outils professionnels et sur la continuité avec Azure. Dans les deux cas, la technologie ne sera adoptée durablement que si elle tient sa promesse la plus difficile : automatiser davantage, sans rendre les processus plus opaques ni plus fragiles.