L’automatisation n’est pas le travail du créateur d’agent
Je crois que je me suis trompé.
Et cela fait probablement quelques années que je me trompe.
Pas sur Power Automate. Je continue au contraire à penser que Power Automate est l’une des briques les plus importantes de l’écosystème Microsoft lorsqu’il s’agit de transformer concrètement les processus d’une organisation.
Je me suis trompé sur les personnes auxquelles nous essayons d’apprendre Power Automate.
Et l’arrivée des agents rend cette erreur beaucoup plus visible.
Pendant longtemps, j’ai considéré qu’une personne capable de comprendre son processus métier pouvait progressivement apprendre à l’automatiser. C’était finalement une grande partie de la promesse du low-code : rapprocher la technologie de celles et ceux qui connaissent réellement le métier.
Puis nous avons ajouté les agents.
Et j’ai naturellement prolongé le raisonnement : si quelqu’un est capable de construire un agent, il devrait également pouvoir construire les automatisations dont cet agent a besoin.
Je n’en suis plus convaincu.
Je pense même aujourd’hui que nous mélangeons plusieurs métiers, plusieurs niveaux de responsabilité et plusieurs formes de gouvernance qui devraient être clairement séparés.
Et surtout, je crois qu’il manque un rôle essentiel entre l’administrateur de la Power Platform et le créateur d’agent :
l’intégrateur d’automatisations.
Un agent n’est pas une automatisation !
Commençons par une distinction qui paraît évidente lorsqu’on l’écrit, mais qui l’est beaucoup moins lorsque l’on construit réellement des solutions.
Un agent et une automatisation ne répondent pas à la même question.
L’agent doit être capable de comprendre une intention, de mobiliser un contexte, de raisonner sur une demande, de sélectionner un outil et éventuellement de décider qu’une action doit être exécutée.
L’automatisation, elle, doit exécuter cette action de manière fiable, prévisible, sécurisée et observable.
Prenons quelque chose de très simple :
« Envoie un courriel au client pour confirmer que sa demande a été acceptée. »
Pour l’agent, le problème consiste notamment à comprendre :
- de quel client nous parlons ;
- quelle demande est concernée ;
- si elle est effectivement acceptée ;
- quel message doit être transmis ;
- et à quel moment l’action doit être déclenchée.
Mais une fois la décision prise, quelque chose doit réellement envoyer le courriel.
C’est là que commence un autre problème.
Quel compte expédie le message ?
Quelle adresse est utilisée ?
Quel modèle organisationnel doit être respecté ?
Comment construit-on l’objet ?
Quelle signature utilise-t-on ?
Peut-on inclure certaines données personnelles ?
Doit-on conserver une trace de l’envoi ?
Que se passe-t-il si Exchange refuse le message ?
Faut-il réessayer ?
Combien de fois ?
Qui est averti après trois échecs ?
Comment retrouve-t-on l’exécution six mois plus tard lors d’un audit ?
Tout cela n’est pas réellement le problème de l’agent.
C’est le problème du service d’automatisation qu’il consomme.
Et c’est précisément là que ma réflexion a changé.
Nous demandons trop au créateur d’agent
Nous sommes en train de reproduire avec les agents une erreur que nous avons déjà faite avec le low-code.
Nous confondons accessibilité de l’outil et simplicité de l’architecture.
Parce qu’une interface permet de construire quelque chose graphiquement, nous en déduisons parfois que la responsabilité architecturale qui se cache derrière cette construction est devenue simple.
Elle ne l’est pas.
Créer cinq actions dans Power Automate est simple.
Construire une automatisation d’entreprise exploitable pendant cinq ans ne l’est absolument pas.
Il faut penser aux identités, aux connexions, aux autorisations, aux environnements, aux politiques de données, aux solutions, aux variables d’environnement, aux références de connexion, au déploiement, à la supervision, aux erreurs, aux propriétaires, aux dépendances, aux changements d’API et au cycle de vie.
Microsoft recommande d’ailleurs de gérer les automatisations destinées à devenir des composants structurés dans des Solutions Power Platform. Une solution peut contenir le flow lui-même, mais également ses références de connexion, ses variables d’environnement et les éventuels child flows dont il dépend.
Nous ne parlons donc déjà plus d’un simple dessin constitué de rectangles reliés par des flèches.
Nous parlons d’un composant logiciel.
Le problème n’est pas Power Automate
Power Automate souffre parfois d’une réputation paradoxale.
D’un côté, l’outil paraît extraordinairement simple.
On sélectionne un déclencheur.
On ajoute quelques actions.
On teste.
Cela fonctionne.
Fantastique.
Mais cette facilité masque le véritable problème.
Faire fonctionner une automatisation une fois est facile. La faire fonctionner correctement mille fois par jour pendant trois ans est une autre discipline.
Et lorsque cette automatisation devient un outil utilisé par un agent, cette distinction devient fondamentale.
Car l’agent introduit une nouvelle échelle.
Un utilisateur peut déclencher une automatisation quelques fois dans sa journée.
Un agent peut potentiellement décider de l’appeler continuellement.
Microsoft permet justement aux agents Copilot Studio d’utiliser des agent flows comme outils : l’orchestrateur peut les appeler au moment de l’exécution pour récupérer de l’information ou effectuer une action.
Cela change complètement notre manière de considérer l’automatisation.
Elle n’est plus simplement un petit workflow attaché à une personne.
Elle devient une capacité opérationnelle mise à disposition d’autres systèmes.
Je ne veux plus apprendre Power Automate à tout le monde
C’est probablement le changement le plus important dans ma manière d’aborder aujourd’hui la formation.
Pendant longtemps, j’ai essayé d’expliquer Power Automate aux utilisateurs.
Je continue évidemment à penser qu’il est utile qu’ils comprennent ce qu’est une automatisation.
Mais je ne pense plus que chaque créateur d’agent doive devenir créateur d’automatisations.
Ce sont deux compétences différentes.
Une personne métier peut parfaitement être capable d’expliquer :
« Lorsque le dossier est accepté, nous devons prévenir le client. »
Elle connaît le processus.
Elle connaît les exceptions.
Elle sait pourquoi le message doit partir.
Elle sait quelles informations doivent apparaître.
Elle sait peut-être même parfaitement décrire le résultat attendu.
Mais cela ne signifie absolument pas qu’elle doit savoir comment gérer OAuth, une référence de connexion, un compte de service, une politique DLP, une variable d’environnement ou le déploiement d’une solution Power Platform.
Et il n’y a rien de péjoratif là-dedans.
C’est simplement un autre métier.
Il faut donc séparer les rôles
Je commence désormais à considérer l’automatisation d’entreprise selon plusieurs responsabilités distinctes.
Le consommateur
Il utilise une capacité.
Il ne sait pas nécessairement qu’un flow existe.
Il demande simplement :
« Préviens le client. »
Pour lui, l’automatisation est invisible.
Le créateur d’agent
Il construit l’expérience agentique.
Il définit les instructions, les connaissances, les comportements, les outils disponibles et les conditions dans lesquelles ceux-ci doivent être utilisés.
Il doit comprendre ce que fait l’automatisation.
Mais il ne devrait pas nécessairement avoir à comprendre comment elle le fait.
L’intégrateur d’automatisations
Voilà, à mon avis, le rôle qui nous manque aujourd’hui.
L’intégrateur prend un besoin métier et le transforme en capacité technique réutilisable et gouvernée.
Il ne construit pas nécessairement toute la plateforme.
Il ne l’administre pas nécessairement non plus.
Mais il sait transformer :
« envoyer un courriel »
en quelque chose comme :
SendCustomerEmail()
avec un contrat parfaitement défini.
Entrées :
recipienttemplateIdlanguagecustomerNamecaseIdparameters
Sorties :
statusmessageIdtimestamperrorCode
Le créateur d’agent n’a alors plus besoin de connaître la mécanique interne.
Il consomme une capacité.
L’administrateur Power Platform
Lui travaille encore à un autre niveau.
Il administre les environnements, les stratégies de sécurité, les accès, les politiques de données, les capacités, les connecteurs autorisés et les règles globales de gouvernance.
Microsoft définit justement les environnements Power Platform comme les conteneurs permettant de stocker, gérer et séparer les applications, les données et les flows selon leurs rôles, leurs exigences de sécurité ou leurs populations cibles.
Nous avons donc quatre préoccupations très différentes :
consommer → orchestrer → intégrer → administrer.
Les confondre crée de la dette.
« Envoyer un courriel » ne devrait pas être réinventé 200 fois
C’est probablement l’exemple qui illustre le mieux mon raisonnement.
Combien de flows Power Automate contenant une action « Send an email » existe-t-il dans votre organisation ?
Dix ?
Cent ?
Mille ?
Et pourquoi ?
Pourquoi chaque créateur devrait-il réinventer la manière d’envoyer un courriel ?
Dans une entreprise suffisamment mature, « envoyer un courriel à un client » devrait devenir une capacité organisationnelle.
Pas une action technique que chacun reconstruit.
Imaginons un flow gouverné :
Send Customer Email
Il accepte des paramètres.
Il vérifie les destinataires.
Il applique le bon modèle.
Il utilise l’identité d’expédition appropriée.
Il ajoute la signature officielle.
Il applique éventuellement les règles de conformité.
Il journalise l’opération.
Il gère les erreurs.
Il retourne un résultat normalisé.
À partir de là, cinquante agents peuvent l’utiliser.
Cent applications peuvent l’utiliser.
D’autres automatisations peuvent l’utiliser.
Et si demain la politique de l’entreprise change, nous ne corrigeons pas 150 agents.
Nous corrigeons une capacité.
Voilà la différence entre automatiser et industrialiser l’automatisation.
Power Automate devrait devenir une couche de services
C’est probablement la conséquence architecturale la plus importante de cette réflexion.
Je pense que nous devons arrêter de considérer Power Automate uniquement comme :
« l’outil avec lequel chacun construit ses workflows ».
Dans une architecture d’entreprise mature, Power Automate peut devenir une couche de services métier réutilisables.
Nous pourrions avoir :
SendCustomerEmail
CreateCustomerCase
RequestApproval
CreateProjectWorkspace
ArchiveDocument
GenerateContract
NotifyManager
RegisterCustomerInteraction
CreateTeamsMeeting
PublishDocument
Chaque capacité possède :
un propriétaire ;
une documentation ;
un contrat d’entrée et de sortie ;
une version ;
des tests ;
des connexions maîtrisées ;
une politique de sécurité ;
une stratégie de journalisation ;
un SLA éventuellement ;
une procédure de support ;
un cycle de vie.
À ce moment-là, le catalogue Power Automate commence presque à ressembler à un catalogue interne d’API métier.
Et c’est exactement ce que je veux.
Le créateur d’agent ne devrait voir que le contrat
Reprenons notre agent.
Il a besoin d’envoyer un courriel.
Je ne veux pas que son créateur ait besoin de connaître :
Exchange Online → connexion → compte → HTML → gestion des erreurs → journalisation → retry → politique organisationnelle.
Je veux qu’il voie :
Envoyer un courriel client
Description : envoie un courriel conforme aux standards de communication de l’organisation.
Entrées :
destinataire, modèle, langue, paramètres.
Retour :
succès/échec, identifiant du message.
Point.
C’est le principe fondamental de l’abstraction.
Et l’ironie est assez amusante : nous appliquons ce principe depuis des décennies dans le développement logiciel.
Personne ne demande à un développeur qui consomme une API de comprendre l’intégralité de son implémentation interne.
Pourquoi demanderions-nous cela à un créateur d’agent ?
Et Power Automate sait déjà faire une partie de cela
Nous n’avons même pas besoin d’attendre une hypothétique évolution technologique.
Une bonne partie des mécanismes existent.
Les child flows permettent par exemple de construire des flows réutilisables appelés par d’autres flows. Microsoft demande qu’ils soient placés dans une solution et documente explicitement le modèle parent/enfant.
Les Solutions permettent de regrouper les composants nécessaires à leur cycle de vie.
Les connection references permettent de dissocier davantage le composant de la connexion concrète utilisée dans un environnement.
Les environment variables permettent d’éviter de coder certaines configurations directement dans l’automatisation.
Les mécanismes de partage distinguent également les personnes qui modifient un flow de celles qui ne font que l’exécuter. Microsoft recommande notamment de privilégier l’accès run-only lorsqu’une personne doit exécuter un flow sans participer à sa conception.
Tout cela raconte finalement la même histoire :
un flow de production n’est pas simplement le flow de son créateur.
C’est un actif organisationnel.
Et surtout : arrêtons de faire dépendre l’entreprise de Nicolas
Ou de Julie.
Ou de Karim.
Ou de Jennifer.
Vous voyez certainement le problème.
Quelqu’un construit un flow.
La connexion utilise son compte.
Le flow devient utile.
Puis important.
Puis critique.
Deux ans plus tard, Nicolas change de poste.
Ou quitte l’entreprise.
Et soudain quelqu’un découvre qu’un processus métier utilisé quotidiennement repose sur :
nicolas@entreprise.com
Ce n’est pas un détail.
C’est un problème d’architecture.
Pour les flows critiques ou destinés à fonctionner durablement, Microsoft recommande notamment l’utilisation d’un service principal lorsque le scénario le permet afin de réduire la dépendance à une personne particulière. Les comptes utilisateurs restent pertinents lorsque l’automatisation doit réellement agir dans le contexte personnel de cet utilisateur.
Autrement dit :
l’identité d’exécution doit être une décision d’architecture, pas le résultat accidentel de la personne qui a cliqué sur « Create ».
Dev, Test, Prod : Power Automate est du logiciel
Il faut également accepter une autre réalité.
Une automatisation importante doit avoir un cycle de vie.
Développement.
Test.
Production.
Cela implique des environnements adaptés, des solutions, des configurations différentes selon les environnements et une procédure de déploiement.
Cela implique aussi de savoir quelle version fonctionne actuellement en production.
Et de pouvoir répondre à quelques questions extrêmement simples :
Qui a changé le flow ?
Pourquoi ?
Quelle demande métier justifiait le changement ?
Quels tests ont été effectués ?
Quand a-t-il été déployé ?
Quelle était la version précédente ?
Peut-on revenir en arrière ?
Si personne ne peut répondre à ces questions, nous n’avons pas réellement industrialisé Power Automate.
Nous avons simplement beaucoup de flows.
Ce n’est pas la même chose.
La supervision devient une responsabilité à part entière
Il y a ensuite une question dont nous parlons beaucoup trop peu :
qui surveille les automatisations ?
Parce qu’elles vont échouer.
Pas nécessairement parce qu’elles sont mal construites.
Une API peut devenir indisponible.
Une authentification peut expirer.
Un schéma peut évoluer.
Une donnée inattendue peut apparaître.
Un connecteur peut être limité.
Un service tiers peut ralentir.
Une capacité peut être dépassée.
La bonne question n’est donc pas :
« Est-ce que le flow va échouer ? »
Mais :
« Que se passe-t-il lorsqu’il échoue ? »
Microsoft fournit désormais un rôle Operator permettant notamment d’observer pour les flows concernés le statut des exécutions, leur durée et certaines informations d’erreur. Cette visibilité est notamment liée aux cloud flows intégrés à des solutions pour les données d’exécution exposées via Dataverse.
Ce détail est important.
Il renforce encore l’idée qu’un flow d’entreprise doit être opéré, pas simplement créé.
Administrer n’est pas intégrer
C’est également une distinction que je veux désormais rendre beaucoup plus explicite.
L’administrateur Power Platform n’est pas forcément la personne qui doit construire SendCustomerEmail.
Son rôle est plutôt de garantir que la plateforme dans laquelle cette automatisation existe est maîtrisée.
Il travaille sur les environnements.
Les groupes.
Les rôles.
Les stratégies.
Les politiques de données.
Les connecteurs.
La sécurité.
La capacité.
Les règles de gouvernance.
Microsoft positionne d’ailleurs les Managed Environments, les groupes d’environnements et les règles associées comme des mécanismes permettant d’appliquer une gouvernance cohérente à l’échelle de plusieurs environnements.
Et Microsoft recommande également la mise en place d’une fonction ou d’un Center of Excellence capable d’encadrer l’administration, la gouvernance et l’adoption de Power Platform à l’échelle de l’organisation.
L’intégrateur, lui, travaille dans ce cadre.
L’administrateur construit et protège les routes.
L’intégrateur construit les véhicules autorisés à les emprunter.
Le créateur d’agent décide lequel utiliser.
Et l’utilisateur dit simplement où il veut aller.
La gouvernance des agents ne remplace donc pas celle de Power Platform
Voilà un autre piège que l’arrivée des agents pourrait nous faire commettre.
Nous construisons actuellement de nouveaux modèles de gouvernance des agents.
Très bien.
Nous parlons de :
- propriétaires ;
- instructions ;
- sources de connaissances ;
- identités ;
- permissions ;
- outils ;
- tests ;
- évaluation ;
- publication ;
- observabilité ;
- cycle de vie.
Tout cela est nécessaire.
Microsoft fournit d’ailleurs désormais des contrôles spécifiques pour les agents Copilot Studio autour des sources de connaissances, actions, connecteurs, requêtes HTTP, canaux de publication, triggers et autres capacités.
Mais lorsqu’un agent appelle une automatisation, nous changeons de couche.
Nous entrons dans la gouvernance de la Power Platform et du système exécutant l’action.
Et ces deux gouvernances doivent se rencontrer sans être confondues.
Je pourrais résumer cela ainsi :
Gouvernance de l’agent : peut-il décider de faire cette action ?
Gouvernance de l’automatisation : comment cette action est-elle exécutée correctement ?
Ce ne sont absolument pas les mêmes questions.
Et c’est là que Power Automate devient encore plus important avec les agents
On pourrait penser que l’arrivée des agents rend Power Automate moins important.
Je pense exactement l’inverse.
Plus nous donnerons de capacités d’action aux agents, plus nous aurons besoin d’une couche d’exécution extrêmement maîtrisée.
L’agent apporte quelque chose d’extraordinaire :
la compréhension de l’intention.
Mais comprendre une intention ne suffit pas à exécuter correctement un processus d’entreprise.
Entre :
« Je comprends ce que Nicolas veut faire »
et :
« Je vais modifier le système de l’entreprise »
il doit exister une frontière extrêmement solide.
Cette frontière, ce sont les outils opérationnalisés.
Power Automate peut en constituer une partie importante dans l’écosystème Microsoft.
Mais ce pourrait également être une API.
Une Azure Function.
Une Logic App.
Un microservice interne.
Une fonction exposée par un ERP.
Un service SaaS.
Une action provenant d’une autre plateforme d’automatisation.
Et c’est précisément pour cela que le créateur d’agent ne devrait pas être dépendant de Power Automate lui-même.
Il devrait être dépendant d’un contrat de capacité.
Le catalogue d’automatisations
J’en arrive donc progressivement à une architecture qui me paraît beaucoup plus saine.
Je voudrais qu’une entreprise puisse disposer d’un véritable catalogue d’automatisations certifiées.
Imaginez :
Communication
SendCustomerEmailSendInternalNotificationSendSMSPublishTeamsMessage
Documents
CreateDocumentConvertToPDFArchiveDocumentRequestSignature
Collaboration
CreateTeamCreateProjectWorkspaceCreateMeetingAddProjectMember
CRM
CreateLeadUpdateOpportunityRegisterInteraction
Finance
CreatePurchaseRequestSubmitExpenseRequestFinancialApproval
RH
CreateEmployeeRequestStartOnboardingNotifyManager
Chaque automatisation possède son contrat.
Chaque automatisation possède son propriétaire.
Chaque automatisation est testée.
Chaque automatisation est surveillée.
Chaque automatisation est versionnée.
Chaque automatisation possède une documentation.
Et surtout :
chaque automatisation peut être consommée par plusieurs agents.
À partir de là, nous cessons de construire des agents comme des îlots technologiques.
Nous construisons une plateforme de capacités organisationnelles.
Le vrai rôle du créateur d’agent change alors complètement
Et c’est probablement là que ma propre approche de la formation va évoluer le plus.
Je veux continuer à montrer Power Automate dans une formation sur les agents.
Mais je ne veux plus nécessairement apprendre au créateur d’agent à devenir spécialiste Power Automate.
Je veux lui apprendre à comprendre :
- ce qu’est une automatisation ;
- quand en demander une ;
- comment exprimer son besoin ;
- comment comprendre son contrat ;
- quelles données lui transmettre ;
- quel résultat attendre ;
- comment gérer l’erreur retournée ;
- quelles permissions sont nécessaires ;
- et surtout quand ne pas construire lui-même cette automatisation.
Ce changement est fondamental.
Nous passons de :
Comment construire un flow ?
à :
Comment consommer une capacité opérationnelle ?
Et pour certaines personnes, notamment celles qui occupent le rôle d’intégrateur, nous proposons alors une formation Power Automate beaucoup plus poussée.
Parce que ce sont elles qui en ont réellement besoin.
Le nouveau « qui fait quoi »
Je vois donc désormais l’organisation autour des agents et de l’automatisation selon quatre étages.
1. L’utilisateur métier exprime l’intention.
Il connaît le besoin.
2. Le créateur d’agent construit l’orchestration intelligente.
Il permet à l’agent de comprendre quand et pourquoi utiliser une capacité.
3. L’intégrateur d’automatisations industrialise la capacité.
Il transforme un processus métier réutilisable en service fiable, documenté, paramétrable, testable et observable.
4. L’administrateur Power Platform gouverne la plateforme.
Il garantit que l’ensemble fonctionne dans un environnement sécurisé, administrable et conforme.
Et évidemment, dans une petite organisation, une même personne pourra porter plusieurs rôles.
Ce n’est pas un problème.
Un rôle n’est pas nécessairement une personne.
Mais les responsabilités doivent rester distinctes.
C’est cela qui compte.
Et peut-être est-ce là notre vieille erreur avec Power Automate
Depuis des années, nous essayons de gouverner Power Automate.
Nous créons des politiques.
Nous expliquons les environnements.
Nous installons des Center of Excellence.
Nous surveillons les flows orphelins.
Nous essayons de contrôler les connecteurs.
Nous faisons de la formation.
Et pourtant, beaucoup d’organisations continuent de découvrir des centaines ou des milliers d’automatisations dispersées.
Microsoft recommande d’ailleurs explicitement aux administrateurs de surveiller les ressources inutilisées ou sans propriétaire, les applications et flows fortement utilisés et les connecteurs présents dans l’environnement par défaut.
Peut-être que le problème n’a jamais été uniquement technique.
Peut-être avons-nous surtout laissé entendre que chaque personne devait construire sa propre automatisation.
Alors que certaines automatisations ne devraient précisément plus appartenir à des individus.
Elles devraient appartenir à l’organisation.
De l’automatisation personnelle à la capacité d’entreprise
Cela ne signifie évidemment pas la disparition du citizen development.
Il existera toujours une place pour :
« Quand je reçois ce type de message, crée-moi une tâche. »
C’est une automatisation individuelle.
Très bien.
Mais :
« Lorsqu’un contrat client est signé, créer le dossier officiel, enregistrer le contrat, mettre à jour le CRM, prévenir Finance et déclencher la facturation »
n’est plus une automatisation individuelle.
C’est un processus d’entreprise.
Et :
« permettre à n’importe quel agent autorisé de déclencher ce processus »
est encore un niveau supplémentaire.
Nous devons donc être capables de faire progresser une automatisation entre plusieurs niveaux de maturité :
expérimentation → automatisation locale → automatisation partagée → capacité organisationnelle → service critique.
Et les exigences de gouvernance augmentent à chaque étape.
L’agent devient finalement un (autre) consommateur
Et voilà probablement la phrase qui résume le mieux ma nouvelle manière de voir les choses :
Un agent ne devrait pas être propriétaire de l’automatisation. Il devrait en être consommateur.
L’agent raisonne.
Il sélectionne.
Il orchestre.
Il appelle.
Mais la capacité opérationnelle doit pouvoir exister indépendamment de lui.
Si demain je remplace mon agent Copilot Studio par une application Power Apps, la capacité SendCustomerEmail devrait continuer à fonctionner.
Si je construis un deuxième agent, il devrait pouvoir utiliser la même capacité.
Si un processus Power Automate classique en a besoin, lui aussi.
Et si demain une autre technologie agentique doit l’utiliser, nous devrions pouvoir exposer cette même logique par une interface adaptée sans réinventer le processus métier.
C’est ainsi que nous découplons l’intelligence qui décide de l’automatisation qui exécute.
Je me suis donc trompé. Et tant mieux.
Je pensais que nous devions apprendre aux créateurs d’agents à construire leurs automatisations.
Je pense aujourd’hui que nous devons surtout leur apprendre à collaborer avec ceux qui construisent les automatisations.
Je pensais que Power Automate était une compétence supplémentaire du créateur d’agent.
Je commence à le considérer comme une discipline à part entière.
Je pensais qu’un flow était quelque chose que l’on attachait à un agent.
Je préfère maintenant considérer une automatisation comme une capacité d’entreprise que l’agent vient consommer.
Et cela change beaucoup de choses.
Cela change la formation.
Cela change les rôles.
Cela change la gouvernance.
Cela change l’architecture.
Et surtout, cela remet Power Automate exactement là où il devrait être.
Pas caché à l’intérieur d’un agent.
Pas abandonné entre les mains de milliers de créateurs isolés.
Mais au centre d’une véritable couche d’automatisation gouvernée, industrialisée et réutilisable.
Parce que l’avenir des agents ne dépendra probablement pas seulement de leur capacité à raisonner.
Il dépendra de notre capacité à leur fournir des outils auxquels nous pouvons faire confiance.
Et cette partie-là n’est pas une affaire d’intelligence artificielle.
C’est une affaire d’ingénierie, d’intégration et de gouvernance.
