Le 23 juillet 2026, Google Cloud a ajouté à Agent Registry la gestion de compétences autonomes pour agents IA, avec contrôle d’accès, historique des versions et recherche sémantique, selon ses notes de version officielles. Cette annonce technique pose une question très concrète aux dirigeants : faut-il acheter un agent intégré, assembler une plateforme managée, développer son propre système ou rester sur un workflow classique ?
Notre article sur le passage de l’assistant à l’agent qui agit expliquait l’évolution fonctionnelle. Il s’agit ici de trancher une décision d’architecture, de budget et de dépendance fournisseur.
Le choix qui se pose
La décision réelle n’est pas de choisir « la meilleure IA ». Elle consiste à déterminer quelle couche technique votre entreprise veut posséder et exploiter.
Un agent peut consulter une base documentaire, appeler une API, mettre à jour un logiciel ou demander une validation humaine. Mais plus il agit, plus il faut décider qui gère ses droits, ses instructions, ses versions, ses journaux d’exécution et son arrêt d’urgence.
Lundi matin, le dirigeant doit donc poser cette question au responsable métier et au responsable informatique : avons-nous besoin d’une réponse intelligente, d’une exécution encadrée ou d’un composant stratégique différenciant ? La réponse détermine le niveau d’investissement acceptable et les compétences à conserver en interne.
Cette décision doit rester cohérente avec votre gouvernance de l’IA en PME : une architecture sophistiquée ne compense ni des responsabilités floues ni des données mal maîtrisées.
Les options en présence
Le workflow déterministe sans agent
Le système exécute des règles définies à l’avance : lorsqu’un événement survient, il contrôle des conditions, appelle les applications prévues et produit un résultat attendu.
Cette option convient lorsque les règles métier sont stables, les exceptions identifiables et la sortie précisément définie. Elle utilise éventuellement de l’IA pour classer ou extraire une information, mais ne lui délègue pas le choix du chemin d’exécution.
L’agent intégré à une suite existante
L’entreprise étend un environnement déjà déployé, par exemple Microsoft 365 avec Copilot Studio. L’agent accède aux connaissances autorisées, utilise des connecteurs et déclenche des actions dans l’écosystème de l’éditeur. La documentation de Copilot Studio présente notamment les sources de connaissances, les outils, les connecteurs et les workflows disponibles.
Cette option réduit l’effort d’intégration lorsque les identités, documents et applications sont déjà concentrés dans la même suite. Elle augmente toutefois la dépendance envers son modèle de licences, ses connecteurs et ses règles d’administration.
La plateforme d’agents managée
Une plateforme cloud fournit l’exécution, le registre, les droits, l’observabilité et la gestion des composants réutilisables. Google Agent Registry peut ainsi enregistrer automatiquement certains agents Google Cloud, mais aussi référencer manuellement des agents externes, hébergés sur site ou exposés par une API REST, selon la documentation d’enregistrement d’Agent Registry.
Cette architecture devient pertinente lorsque différents métiers doivent réutiliser des outils, compétences ou agents sans reconstruire chaque intégration. Elle exige en contrepartie une administration cloud structurée.
Le développement sur mesure
L’entreprise construit l’orchestration, les connexions, les règles d’approbation et l’interface autour d’API ou de kits de développement. L’OpenAI Agents SDK fournit par exemple des outils, des transferts entre agents, des garde-fous, une intervention humaine et des traces d’exécution.
Cette option offre le contrôle fonctionnel le plus poussé. Elle transfère aussi à l’entreprise la responsabilité de maintenir le code, les évaluations, les intégrations, les secrets techniques et la supervision.
Les critères qui comptent vraiment
| Critère | Workflow déterministe | Agent intégré à une suite | Plateforme managée | Développement sur mesure |
|---|---|---|---|---|
| Coût | Intégration et maintenance généralement prévisibles | Licence et consommation liées à l’éditeur | Consommation cloud, exploitation et administration | Développement, hébergement, supervision et maintenance |
| Délai | Court si les règles sont déjà documentées | Court à intermédiaire selon les connecteurs | Intermédiaire, car la plateforme doit être configurée | Long, surtout pour sécuriser les actions |
| Dépendance | Faible à moyenne selon les connecteurs | Forte envers la suite choisie | Forte envers le runtime cloud, plus modérée si les interfaces sont standardisées | Liée au modèle, au SDK et aux choix d’architecture |
| Compétences internes | Connaissance métier et intégration | Administrateur de la suite et profil low-code | Architecture cloud, identités et exploitation | Développement logiciel, sécurité et opérations |
| Réversibilité | Bonne si les règles et interfaces sont documentées | Moyenne, car les agents utilisent des services propriétaires | Moyenne à bonne avec des API et protocoles ouverts | Théoriquement forte, mais coûteuse si le code est peu modulaire |
Le coût d’un agent intégré ne se limite pas à sa licence. Microsoft précise que la consommation de Copilot Studio varie selon la conception de l’agent, sa fréquence d’utilisation et les fonctions appelées ; une même interaction peut consommer différentes catégories de crédits, comme l’explique la documentation de facturation Copilot Studio.
La réversibilité ne doit pas non plus être confondue avec la localisation des données. Le choix du runtime, des identités, des journaux et des clés de chiffrement doit compléter les questions abordées dans notre article sur le contrôle réel d’un cloud dit souverain.
Dans quel cas choisir quoi
Choisissez un workflow déterministe si le chemin métier peut être décrit par des règles explicites, si chaque sortie doit être reproductible et si les exceptions peuvent être envoyées à une personne identifiée. Le responsable métier doit alors fournir la table de décision et la liste des exceptions ; l’équipe technique livre le diagramme d’exécution et le journal attendu.
Choisissez l’agent intégré à votre suite si l’essentiel des documents, identités et actions se trouve déjà dans cet environnement, et si ses connecteurs couvrent les applications critiques. Avant validation, l’administrateur doit produire une simulation de consommation, une matrice des permissions et la procédure de désactivation de l’agent.
Choisissez une plateforme managée si différents services doivent partager des compétences, si les versions doivent être centralisées et si l’équipe cloud sait administrer les identités, les politiques d’accès et les journaux. Le livrable attendu n’est pas seulement un agent : c’est un catalogue exploitable précisant le propriétaire, la version active et les applications autorisées pour chaque composant.
Choisissez le sur-mesure si l’agent fait partie de votre avantage concurrentiel, si ses décisions suivent des règles propres à votre métier ou si vous devez connecter des environnements hétérogènes sans dépendre d’une suite unique. Exigez alors une architecture modulaire séparant le modèle, les outils, les règles d’autorisation, la mémoire et l’interface utilisateur.
Ne choisissez pas encore un agent si personne ne peut formuler l’action qu’il sera autorisé à réaliser ni les conditions imposant une reprise humaine. Commencez par documenter cette frontière de responsabilité plutôt que de financer une démonstration spectaculaire mais inexploitable.
Les pièges de chaque option
Le workflow déterministe : l’empilement silencieux des exceptions
Son coût caché apparaît lorsque chaque cas particulier ajoute une branche, une règle ou une intervention manuelle. Sans propriétaire métier, le workflow devient difficile à modifier et personne ne sait quelles règles peuvent être supprimées.
L’agent intégré : une facture difficile à anticiper
La simplicité de construction peut masquer la complexité de consommation. Une réponse, une recherche dans les données de l’entreprise et une action peuvent relever de compteurs distincts. Le test doit donc reproduire les parcours réels, et non se limiter à vérifier que l’agent répond correctement.
L’autre risque est fonctionnel : choisir la suite avant de définir les droits de l’agent conduit à adapter le besoin aux connecteurs disponibles.
La plateforme managée : construire une usine avant le premier usage
Un registre, une recherche sémantique et une gestion centralisée des compétences apportent de la valeur lorsqu’il existe réellement des composants à partager. Pour un périmètre isolé, cette couche peut ajouter de l’administration sans réduire le risque métier.
La nouvelle gestion des compétences de Google reste en phase de prédisponibilité générale, proposée « en l’état » avec un support potentiellement limité, comme l’indique la documentation de gestion des compétences. Elle doit donc être testée avec une stratégie de sortie avant d’accueillir une fonction critique.
Le sur-mesure : sous-estimer l’exploitation
Le prototype visible n’est qu’une partie du système. Il faut aussi gérer les changements de modèle, les autorisations, les erreurs d’outils, les coûts d’API, les traces et les reprises humaines. Sans corpus de test ni responsable d’exploitation, chaque mise à jour peut modifier le comportement attendu.
Comment nous procédons chez D1 Consulting
Nous commençons par une note d’arbitrage, pas par le choix d’un modèle.
- Le sponsor métier définit l’autorité de l’agent : actions permises, actions interdites, validation humaine et résultat attendu. Le livrable est une matrice de responsabilité utilisable pendant les tests.
- Le propriétaire du processus fournit des dossiers réels anonymisés : entrées, sorties, exceptions et applications concernées. Le livrable décrit le chemin actuel, les données consultées et chaque point de décision.
- D1 Consulting compare les architectures : coûts fixes et variables, dépendances, compétences requises, mode dégradé et réversibilité. Le livrable est une grille d’arbitrage accompagnée d’un modèle de coût fondé sur l’usage prévu.
- L’équipe informatique prépare un environnement isolé et limite les droits de l’agent. Les métiers exécutent le corpus de test ; la sécurité contrôle les secrets et les journaux. Le livrable est une décision de mise en production, de modification ou d’abandon, assortie d’une procédure de retour arrière.
- Le dirigeant valide le modèle d’exploitation : propriétaire fonctionnel, responsable technique, traitement des incidents et revue des changements. L’architecture n’est retenue que si ces rôles sont nommés.
Lorsque le workflow déterministe ou l’agent appliqué aux tâches métier est le meilleur choix, notre offre Automatisation & Optimisation couvre la conception et l’intégration. Pour une initiative impliquant plusieurs applications, des fournisseurs et une recette structurée, notre offre de Direction de projet IT sécurise l’arbitrage et la mise en œuvre.
👉 Réservez votre diagnostic gratuit de 30 minutes : nous qualifierons votre scénario, ses dépendances et l’architecture à instruire en priorité.
