Latest / M365.FM – Podcast Microsoft 365, Copilot & IA en français / Avez-vous vraiment besoin d’un agent Copilot Studio ? Quand les personas et les vrais cas d’usage décident (Doublage IA)

Transcript

Avez-vous vraiment besoin d’un agent Copilot Studio ? Quand les personas et les vrais cas d’usage décident (Doublage IA) · M365.FM – Podcast Microsoft 365, Copilot & IA en français

0:00
Speaker 2: Prêt pour 10 jours de Microsoft 365 Copilot, l'IA, Azure
0:04
Speaker 2: et les personnes qui façonnent l'avenir du travail. En janvier,
0:08
Speaker 2: la M365Con est de retour et elle va plus loin.
0:13
Speaker 2: Rejoignez-nous pour des sessions en direct, des démonstrations concrètes et
0:15
Speaker 2: des connaissances pratiques de MVP et d'experts du secteur du
0:17
Speaker 2: monde entier. Pas de diapositives génériques, pas de mots à
0:20
Speaker 2: la mode sans fin. Nous nous attaquons aux vrais défis.
0:23
Speaker 2: Copilot Studio, Agendia, Fabrique, Sécurité, Gouvernance et Automatisation. Que vous
0:30
Speaker 2: soyez un professionnel de l'informatique, un développeur ou un chef d'entreprise,
0:33
Speaker 2: des sessions sont conçues pour vous. Pendant 10 jours complets,
0:36
Speaker 2: vous pouvez explorer de multiples technologies et vous connecter à
0:39
Speaker 2: une communauté mondiale. Regardez en direct et rapportez des informations
0:43
Speaker 2: pratiques à votre organisation. Janvier 2027, 10 jours. Une communauté. Microsoft.
0:49
Speaker 2: Les inscriptions sont ouvertes et maintenant. Rendez-vous chez vous dès aujourd'hui. cm365. net
1:00
Speaker 2: Rejoignez-nous dès maintenant sur m365con. net et nous vous retrouverons en
1:03
Speaker 2: direct en janvier. Vous avez vraiment besoin de votre propre
1:06
Speaker 2: agent Copilot Studio ou est-ce juste le battage médiatique autour
1:08
Speaker 2: de l'IA qui parle? C'est la décision que prennent presque
1:10
Speaker 2: toutes les entreprises en ce moment. Si vous commencez trop
1:13
Speaker 2: vite avec le mauvais copilote, vous perdrez des mois. Si
1:15
Speaker 2: vous commencez trop lentement, vous prendrez du retard par rapport
1:17
Speaker 2: à vos concurrents qui automatisent déjà plus intelligent. Dans cette session,
1:19
Speaker 2: je vais vous expliquer comment nous avons testé cette question
1:21
Speaker 2: dans le cadre d'un projet réel et le rebondissement surprenant
1:24
Speaker 2: que nous avons découvert lorsque nous avons comparé une solution
1:26
Speaker 2: générique rapide avec une version dédiée de Copilot Studio avec
1:28
Speaker 2: une version dédiée de Copilot Studio. La solution aux fausses
1:31
Speaker 2: promesses
1:32
Speaker 2: Si le moyen le plus rapide d'ajouter l'IA était aussi
1:33
Speaker 2: le moyen le plus rapide de rester bloqué. C'est le
1:35
Speaker 2: piège dans lequel tombent de nombreuses organisations lorsqu'elles se tournent
1:37
Speaker 2: vers le premier copilot qui leur est proposé. Sur le papier,
1:40
Speaker 2: cela semble efficace. Il y a une démo soignée et
1:42
Speaker 2: un argumentaire clair. Et la promesse que vous pouvez intégrer
1:44
Speaker 2: l'IA à vos flux de travail sans avoir à trop
1:46
Speaker 2: réfléchir à la conception. Mais la rapidité n'est pas toujours
1:49
Speaker 2: l'avantage qu'elle semble être. Le problème est que ces implémentations
1:52
Speaker 2: rapides révèlent rarement les besoins plus profonds d'entreprise. Ainsi, ce
1:55
Speaker 2: qui commence comme un raccourci prometteur se termine souvent par
1:57
Speaker 2: une impasse. Pensez à la façon dont la plupart des
1:59
Speaker 2: équipes commencent. Quelqu'un voit un copilote pour la synthèse d'email
2:01
Speaker 2: ou la recherche de documents. Et il semble incroyable isolément.
2:04
Speaker 2: Les décideurs ne s'arrêtent pas toujours pour se demander si
2:06
Speaker 2: cela correspond au travail quotidien de leurs employés ou si
2:08
Speaker 2: cela se connecte au système contenant leurs données critiques
2:11
Speaker 2: Au lieu de cartographier les tâches réelles, ils s'emparent de
2:13
Speaker 2: ce qui est déjà emballé. Dans les semaines qui suivent,
2:16
Speaker 2: l'IA suscite un certain intérêt, voire de l'enthousiasme et l'adoption stagne.
2:19
Speaker 2: Les gens réalisent qu'elle ne les aide pas vraiment à
2:20
Speaker 2: résoudre les problèmes qui leur font perdre des heures chaque semaine.
2:23
Speaker 2: Vous pouvez le voir clairement avec les équipes de vente.
2:25
Speaker 2: Imaginez un groupe qui passe la plupart de son temps
2:27
Speaker 2: à rechercher des prospects, à préparer des devis et à
2:29
Speaker 2: répondre aux questions des clients. Si la direction leur donne
2:31
Speaker 2: un copilote générique conçu pour reformuler des emails ou résumer
2:34
Speaker 2: des notes de réunion, cela peut susciter des moments d'émerveillement
2:36
Speaker 2: lors d'une démonstration
2:38
Speaker 2: Mais lorsque l'équipe commence à lui demander des exceptions de tarification,
2:41
Speaker 2: ou si un client relève d'une certaine exigence de conformité,
2:43
Speaker 2: le copilote semble soudainement superficiel. Il n'a pas été connecté
2:46
Speaker 2: à des tableaux de tarification, à des données CRM ou
2:48
Speaker 2: à des manuels de vente spécifiques. Sans cette base, les
2:51
Speaker 2: réponses peuvent sembler simples mais restent inutiles en pratique. C'est
2:55
Speaker 2: là que les limites naturelles des outils d'IA génériques apparaissent.
2:58
Speaker 2: Sans connaissance spécifique au domaine, ils fonctionnent comme de brillants
3:00
Speaker 2: généralistes compétents en communication superficielle, mais incapables d'apporter de la
3:04
Speaker 2: profondeur lorsque cela est nécessaire
3:06
Speaker 2: Les utilisateurs posent des questions détaillées et le copilote se
3:09
Speaker 2: trompe ou utilise des phrases vagues et inutiles. C'est là
3:12
Speaker 2: que la confiance s'éreute. Une fois que les employés ne
3:14
Speaker 2: font plus confiance à ce que dit l'agent, ils cessent
3:16
Speaker 2: rapidement de l'utiliser. À ce stade, l'ensemble du déploiement risque
3:20
Speaker 2: d'être étiqueté comme un autre jouet d'IA plutôt que comme
3:22
Speaker 2: une fonctionnalité sérieuse. Les données sur l'adoption de l'IA le confirment.
3:26
Speaker 2: Des études de suivi des déploiements en entreprise ont montré
3:28
Speaker 2: que les projets sans personnalisation ni adaptation spécifique au rôle
3:30
Speaker 2: sont beaucoup moins utilisés six mois après le lancement. Ce
3:33
Speaker 2: n'est pas parce que la technologie elle-même cesse soudainement de fonctionner,
3:35
Speaker 2: mais parce que l'absence de contexte la rend inutile. Les
3:39
Speaker 2: entreprises confondent souvent qualité des démonstrations et valeur réelle du déploiement.
3:42
Speaker 2: Une bonne démonstration est construite autour de petits exemples bien choisis.
3:45
Speaker 2: Les opérations quotidiennes, en revanche, apportent des contributions plus désordonnées
3:48
Speaker 2: et nécessitent des connaissances de base structurées. Lorsque le copilote
3:50
Speaker 2: ne peut pas s'adapter, le décalage devient évident. Alors pourquoi
3:53
Speaker 2: les entreprises continuent-elles à faire ce terrain? C'est en partie
3:55
Speaker 2: dû au bataillage publicitaire. L'IA est commercialisé comme une fonctionnalité
3:57
Speaker 2: prête à l'emploi que l'on peut activer de la même
3:59
Speaker 2: manière qu'on active une nouvelle licence dans Microsoft 365. Les
4:03
Speaker 2: dirigeants qui sont sous pression pour montrer les progrès de
4:05
Speaker 2: l'IA privilégient souvent une visibilité rapide à un impact durable.«
4:09
Speaker 2: Il déploie quelque chose rapidement?» le souligne dans les présentations
4:11
Speaker 2: et coche la case. Mais la rapidité motivée par le
4:13
Speaker 2: bataillage publicitaire n'est pas synonyme de résultat mesurable. Les employés
4:15
Speaker 2: qui doivent réellement utiliser l'outil ressentent cet écart instantanément même
4:18
Speaker 2: si les tableaux de bord indiquent un déploiement réussi. Cette
4:21
Speaker 2: différence entre la vitesse et les progrès crée une véritable bifurcation.
4:24
Speaker 2: Plus rapide ne signifie pas toujours plus loin. Oui, vous
4:26
Speaker 2: pouvez avoir un agent opérationnel de main si la barre
4:28
Speaker 2: apparaît simplement dans Teams ou Outlook, mais le fait que
4:30
Speaker 2: cela devienne indispensable dépend entièrement de la question de savoir
4:33
Speaker 2: si cela a été adapté au rôle et au flux
4:34
Speaker 2: de travail réel. L'efficacité ne vient pas du fait de
4:37
Speaker 2: cliquer sur Equivégo. Elle vient du fait de poser la
4:39
Speaker 2: question la plus difficile dès le début. Avons-nous besoin d'un
4:41
Speaker 2: agent Copélo Studio qui reflète nos processus, notre langage et
4:44
Speaker 2: nos données? C'est le point de pivot où les projets stagnent,
4:47
Speaker 2: où évoluent, Les équipes qui s'arrêtent pour poser la question
4:50
Speaker 2: peuvent concevoir des agents que les employés veulent vraiment utiliser
4:52
Speaker 2: car ils reconnaissent leur pertinence immédiate. Les équipes qui l'ignorent
4:55
Speaker 2: continuent d'ajouter des outils qui semblent familiers mais qui ne
4:57
Speaker 2: sont pas à la hauteur. L'ironie est que le démarrage,
4:59
Speaker 2: lent et délibéré, finit souvent par être le chemin le
5:01
Speaker 2: plus rapide vers l'adoption car il évite les cycles inutiles
5:04
Speaker 2: sur des solutions qui ne conviennent
5:05
Speaker 3: pas
5:07
Speaker 2: L'étape suivante consiste à déterminer comment poser cette question plus
5:09
Speaker 2: difficile de manière structurée et le point de départ n'est
5:11
Speaker 2: pas du tout la technologie mais les personnes. Nous devons
5:14
Speaker 2: décider à qui s'adresse exactement cet agent. Les personnes. à
5:18
Speaker 2: qui s'adresse réellement l'agent. Il est facile de tomber dans
5:20
Speaker 2: le piège de concevoir quelque chose pour tout le monde.
5:23
Speaker 2: Cela semble inclusif, voire efficace, mais ce que cela produit
5:26
Speaker 2: généralement est tellement édulcoré que personne n'en tire une réelle valeur.
5:30
Speaker 2: Dans les projets d'IA, cet état d'esprit fourre tout garantit
5:32
Speaker 2: presque la déception. La première vraie question à laquelle vous
5:35
Speaker 2: devez répondre est la suivante, à qui l'agent est-il censé aider?
5:38
Speaker 2: Sans le savoir, vous ne construisez pas un copilote, vous
5:40
Speaker 2: construisez juste un bot capable de tenir des conversations informelles.
5:43
Speaker 2: Définir des personas n'est pas un exercice superficiel. C'est la
5:45
Speaker 2: base qui rend possible le reste du projet, Lorsque vous
5:48
Speaker 2: entendez parler de Persona, il ne s'agit pas de profils
5:50
Speaker 2: marketing ou de personnages fictifs avec des passe-temps et des
5:52
Speaker 2: boissons préférés. Dans ce contexte, un Persona consiste à identifier
5:55
Speaker 2: le rôle, les responsabilités et l'environnement de la personne que
5:58
Speaker 2: votre agent sert. Il définit ce que l'agent a besoin
6:00
Speaker 2: de savoir, la manière dont il répond aux questions et
6:02
Speaker 2: même le ton qu'il doit utiliser. Un employé générique n'aide
6:05
Speaker 2: pas votre IA à déterminer si elle doit extraire des
6:07
Speaker 2: données de conformité en temps réel ou donner des instructions
6:09
Speaker 2: de réparation étape par étape. Ce flou explique pourquoi tant
6:12
Speaker 2: de premiers projets se sont terminés avec des agents qui
6:14
Speaker 2: pouvaient dire bonjour de cinq manières différentes mais qui ne
6:16
Speaker 2: pouvaient pas résoudre le problème réel pour lequel les utilisateurs
6:18
Speaker 2: étaient venus. Voici la différence que cela fait en pratique.
6:21
Speaker 2: Si vous imaginez l'employé comme votre persona, vous pourriez décider
6:23
Speaker 2: que l'agent devrait vous aider avec les politiques RH, le
6:25
Speaker 2: support informatique et les demandes de documents, le tout en
6:27
Speaker 2: une seule fois. L'agent doit alors se disperser dans plusieurs
6:31
Speaker 2: domaines sans exceller dans aucun d'entre eux. Comparez cela à
6:35
Speaker 2: la définition d'un personnage comme un ingénieur de terrain qui
6:37
Speaker 2: a besoin de réponses de conformité instantanées sur les sites
6:39
Speaker 2: des clients. La conception change immédiatement. Vous savez que cette
6:42
Speaker 2: personne est souvent mobile, a peu de temps et a
6:44
Speaker 2: besoin de conseils clairs et fiables. Ce personnage vous amène
6:47
Speaker 2: à connecter le copilote aux bases de données de conformité,
6:49
Speaker 2: à formuler les réponses de manière non ambiguë et à
6:51
Speaker 2: privilégier la rapidité de livraison aux longues explications. Vous pouvez
6:55
Speaker 2: voir que l'un est vague et flou tandis que l'autre
6:57
Speaker 2: est suffisamment précis pour guider la construction réelle. La différence
7:00
Speaker 2: dans le monde réel devient encore plus claire lorsque vous
7:01
Speaker 2: examinez les rôles contrastés. Prenons l'exemple d'un agent du service
7:04
Speaker 2: d'assistance informatique. Ce groupe a besoin d'étapes de dépannage rapide,
7:07
Speaker 2: de mise à jour en cas de panne du système
7:08
Speaker 2: et de la possibilité de faire remonter l'étiquette service. Le
7:11
Speaker 2: langage est technique, les données proviennent probablement d'outils tels que
7:13
Speaker 2: ServiceNow ou Intune, et les utilisateurs attendent des instructions précises
7:16
Speaker 2: qu'ils peuvent suivre sous pression. Maintenant, comparez cela à un
7:19
Speaker 2: personnage d'analyste financier. Cet utilisateur est davantage préoccupé par l'accès
7:23
Speaker 2: au modèle financier et la compréhension de la conformité en
7:25
Speaker 2: matière d'approbation des dépenses ou la génération de rapports. Il
7:28
Speaker 2: travaille avec des chiffres, des chaînes d'approbation et une terminologie financière,
7:31
Speaker 2: et il doit avoir confiance que le copilote n'exposera pas
7:33
Speaker 2: des informations sensibles au mauvais public. Concevez pour l'employé et
7:36
Speaker 2: vous passerez complètement à côté des deux. concevait pour chaque
7:38
Speaker 2: Persona spécifique et l'agent devient non seulement utile, mais aussi
7:41
Speaker 2: digne de confiance. Un autre avantage négligé de la définition
7:44
Speaker 2: des Personas est l'alignement au sein de l'organisation. Et lorsque
7:47
Speaker 2: vous mettez un Persona clair sur la table, les équipes
7:49
Speaker 2: des RH, de l'informatique, de la conformité ou des opérations
7:51
Speaker 2: peuvent rapidement se mettre d'accord sur la portée réelle. Au
7:54
Speaker 2: lieu de débats interminables sur ce que le copilote pourrait faire,
7:56
Speaker 2: tout le monde a désormais un point de référence pour
7:58
Speaker 2: ce qu'il devrait faire. Cela devient une boussole pour la
8:01
Speaker 2: prise de décision. Si vous hésitez à ajouter une fonctionnalité,
8:04
Speaker 2: vous pouvez vérifier par rapport au Persona. Cela aide-t-il l'ingénieur
8:07
Speaker 2: de terrain à obtenir des réponses plus rapidement en matière
8:08
Speaker 2: de conformité? Si oui, tant mieux. Sinon, cela n'a probablement
8:11
Speaker 2: pas sa place dans la première version. Ce type de
8:13
Speaker 2: discipline empêche le projet de se transformer en une liste
8:15
Speaker 2: de souhaits flous. Les personas vont également au-delà de la
8:17
Speaker 2: simple orientation de la portée. Ils déterminent les exigences en
8:19
Speaker 2: matière de commun. Pour chaque persona, vous devez vous demander
8:21
Speaker 2: de quelles informations ont-ils besoin au quotidien, au quotidien. Où
8:24
Speaker 2: se trouvent ces informations actuellement? A quelle vitesse évoluent-elles? Cette
8:27
Speaker 2: analyse détermine la manière dont vous intégrez les sources de
8:29
Speaker 2: connaissances dans le copilote et dont vous le tenez à jour.
8:32
Speaker 2: Si vous ignorez les personas, vous allez soit surcharger l'agent
8:35
Speaker 2: de dénon pertinente, soit pire le priver du contenu dont
8:37
Speaker 2: il a réellement besoin. Dans tous les cas, la confiance
8:40
Speaker 2: des utilisateurs finaux s'érode. Une fois la confiance perdue, l'adoption
8:43
Speaker 2: ne se rétablit pas facilement. Un persona bien défini ne
8:45
Speaker 2: limite pas les possibilités, mais donne une direction. Sans lui,
8:48
Speaker 2: les projets d'IA errent à la poursuite de chaque fonctionnalité
8:50
Speaker 2: intéressante jusqu'à ce qu'ils s'effondrent sous leur propre ambition. Avec lui,
8:54
Speaker 2: vous avez un guide stable. Le persona devient la boussole
8:57
Speaker 2: qui maintient le projet sur la bonne voie, en veillant
8:58
Speaker 2: à ce que le copilote soit conçu pour de vraies
9:00
Speaker 2: personnes avec de vraies tâches et non pour une idée
9:02
Speaker 2: abstraite de l'employé. C'est la différence entre un agent qui
9:05
Speaker 2: est ignoré après le lancement et un agent sur lequel
9:08
Speaker 2: les gens comptent activement. Avec des personas en place, la
9:10
Speaker 2: situation devient enfin plus claire. Vous savez pour qui vous construisez.
9:14
Speaker 2: La question qui suit est que devrions-nous les aider à
9:16
Speaker 2: faire exactement? Cas d'utilisation qui comptent vraiment? Toutes les tâches
9:20
Speaker 2: ne méritent pas un copilote, même si elles peuvent techniquement
9:22
Speaker 2: en avoir un. C'est là que de nombreuses organisations s'emballent.
9:25
Speaker 2: Une fois que le brainstorming commence, on a l'impression que
9:27
Speaker 2: chaque petite frustration pourrait devenir une fonctionnalité d'IA. Quelqu'un propose,
9:30
Speaker 2: et si ça pouvait nous rappeler de soumettre nos feuilles
9:32
Speaker 2: de temps? Un autre ajoute, peut-être que ça pourrait rédiger
9:35
Speaker 2: des notes de remerciement après les réunions avec les clients.
9:38
Speaker 2: En peu de temps, la liste est si longue que
9:39
Speaker 2: personne ne se souvient du problème qu'il essayait réellement de résoudre.
9:42
Speaker 2: Le danger n'est pas d'avoir trop d'idées, mais d'essayer de
9:44
Speaker 2: rendre un agent responsable de tout tout. À ce stade,
9:47
Speaker 2: le copilote cesse de se sentir comme un spécialiste et
9:49
Speaker 2: devient plutôt un stagiaire débordé. La réalité est que les
9:52
Speaker 2: séances de brainstorming génèrent presque toujours des dizaines de directions possibles.
9:55
Speaker 2: La finance demande de l'aide pour le reporting. Les RH
9:57
Speaker 2: imaginent des flux d'intégration. Les ventes veulent des arguments. automatisés.
10:01
Speaker 2: L'informatique rêve d'un tri plus rapide des tickets. En soi,
10:03
Speaker 2: aucune de ces solutions n'est mauvaise, mais la question n'est
10:05
Speaker 2: pas« l'IA peut-elle faire ça?» C'est« est-ce important que l'IA
10:07
Speaker 2: fasse ça?» Ce petit changement, par exemple, combien d'idées semblent
10:14
Speaker 2: intelligentes mais n'offrent presque aucun retour sur investissement une fois
10:16
Speaker 2: mises en œuvre? Ce n'est pas parce que vous pouvez
10:18
Speaker 2: automatiser des questions mineures que cela vaut la peine de
10:20
Speaker 2: déployer des efforts pour créer, former et maintenir cette automatisation.
10:24
Speaker 2: Si vous avez déjà examiné le résultat de projet dont
10:26
Speaker 2: la portée est trop grande, le schéma est prévisible. L'agent
10:29
Speaker 2: se retrouve chargé de dizaines de tâches déconnectées, chacune accomplissant
10:31
Speaker 2: une tâche à un niveau médiocre, médiocre. Prenons un exemple
10:34
Speaker 2: simple comme répondre à la question de savoir si une
10:36
Speaker 2: salle de réunion dispose d'un projecteur. Bien sûr, un copilote
10:39
Speaker 2: peut gérer ce type de FAQ sans problème, mais l'impact
10:41
Speaker 2: est minime. Comparer cela à un agent qui valide si
10:43
Speaker 2: une proposition de vente répond à des critères réglementaires stricts
10:46
Speaker 2: avant même qu'elle ne soit envoyée L'un évite un peu
10:49
Speaker 2: de désagréments, l'autre prévient les risques juridiques et accélère les revenus.
10:53
Speaker 2: Ce contraste montre pourquoi l'hierarchisation des priorités est importante. Un
10:56
Speaker 2: moyen utile de faire la part des choses est d'appliquer
10:58
Speaker 2: trois critères au début, la valeur, la fréquence et la faisabilité.
11:02
Speaker 2: La valeur consiste à se demander dans quelle mesure la
11:04
Speaker 2: tâche aide réellement l'entreprise lorsqu'elle est automatisée. La fréquence examine
11:07
Speaker 2: la fréquence à laquelle elle est. Résoudre un petit problème
11:09
Speaker 2: qui survient 50 fois par jour peut l'emporter sur un
11:11
Speaker 2: défi plus important qui ne survient qu'une fois par trimestre.
11:14
Speaker 2: La faisabilité permet de tenir compte des deux premiers éléments.
11:17
Speaker 2: Si les données requises n'existent pas sous forme numérique ou
11:19
Speaker 2: ne sont pas accessibles en toute sécurité, elles ne sont
11:20
Speaker 2: pas un bon candidat pour la première phase. Lorsque les
11:23
Speaker 2: équipes évaluent chaque cas d'utilisation à travers ce prisme, les
11:25
Speaker 2: listes de souhaits surchargés se réduisent soudainement à un plan ciblé.
11:28
Speaker 2: Il est également prouvé que les projets pilotes plus modestes
11:30
Speaker 2: avec des périmètres restreints sont plus performants. Les organisations qui
11:33
Speaker 2: s'engagent sur seulement 2 ou 3 cas d'utilisation au début
11:35
Speaker 2: ont tendance à développer l'adoption en interne à un rythme
11:37
Speaker 2: plus rapide. Cela se passe comme suit. Le copilote se
11:40
Speaker 2: lance avec une valeur claire dans un ou deux domaines.
11:42
Speaker 2: Les employés gagnent en confiance et les lances construites. Comparer
11:45
Speaker 2: cela aux agents qui tentent de couvrir dix scénarios différents
11:47
Speaker 2: à la fois. Ces projets s'effondrent souvent sous le poids
11:50
Speaker 2: d'une qualité inégale et de commentaires frustrés. Il s'avère qu'un
11:54
Speaker 2: démarrage plus restreint crée une base plus solide pour se
11:56
Speaker 2: développer plus tard. Prenons l'exemple de deux équipes fictives. La
12:00
Speaker 2: première a décidé de concevoir un copilote qui prend en
12:02
Speaker 2: charge les RH, l'informatique, les finances et le service client
12:04
Speaker 2: en une seule équipe. Ils ont passé des mois à
12:07
Speaker 2: cartographier les sources de données, à créer des flux de
12:08
Speaker 2: travail complexes et à promettre qu'il s'agirait d'une solution unique
12:11
Speaker 2: pour l'ensemble de l'organisation. Le jour du lancement, les premiers
12:13
Speaker 2: utilisateurs ont découvert qu'elle ne pouvait répondre correctement à aucun
12:16
Speaker 2: des besoins du service. La plupart l'ont abandonnée en quelques semaines.
12:18
Speaker 2: La deuxième équipe, en revanche, s'est uniquement concentrée sur l'aide
12:21
Speaker 2: aux ingénieurs de terrain pour confirmer les règles de conformité
12:23
Speaker 2: avant les installations. Le lancement s'est déroulé en une fraction
12:25
Speaker 2: du temps imparti, l'adoption a été immédiate et les ingénieurs
12:28
Speaker 2: ont commencé à demander de nouveaux scénarios en fonction de
12:30
Speaker 2: leur expérience positive. Même technologie, résultat très différent. Le défi
12:34
Speaker 2: n'est donc pas de trouver suffisamment de cas d'utilisation, mais
12:36
Speaker 2: de résister à l'envie de tous les couvrir en même temps.
12:38
Speaker 2: La question qui compte est de savoir sur quel scénario
12:40
Speaker 2: il vaut la peine de miser? lesquels, s'ils étaient automatisés,
12:43
Speaker 2: deviendraient un outil quotidien auquel les gens font réellement confiance.
12:46
Speaker 2: C'est ainsi que l'on peut distinguer le bruit du signal.
12:49
Speaker 2: Les cas d'utilisation choisis sont généralement ceux où les employés
12:51
Speaker 2: ressentent une amélioration visible de leur façon de travailler et
12:53
Speaker 2: pas seulement du nombre d'étapes automatisées. Ils rendent les tâches
12:55
Speaker 2: moins frustrantes et plus fiables. Ce qu'il faut retenir ici,
12:58
Speaker 2: c'est que les meilleurs cas d'utilisation ne se contentent pas
13:00
Speaker 2: d'automatiser le travail et changent réellement la façon dont l'utilisateur
13:02
Speaker 2: final perçoit le travail. Quand quelqu'un peut enfin dire« Hag,
13:05
Speaker 2: ce copilote vient de rendre mon travail moins stressant et
13:07
Speaker 2: aiguë si vous avez trouvé la bonne solution», Maintenant que
13:09
Speaker 2: nous savons pour qui nous concevons et ce dont ils
13:11
Speaker 2: ont réellement besoin, l'étape suivante consiste à déterminer les compétences
13:14
Speaker 2: et les connaissances que nous devons enseigner à l'agent pour
13:15
Speaker 2: qu'il puisse réellement fournir ce dont il a besoin. Enseigner
13:18
Speaker 2: les compétences et les connaissances de l'agent. Un agent n'est
13:21
Speaker 2: pas intelligent tant que vous ne lui avez pas appris
13:22
Speaker 2: ce que votre équipe sait déjà. Et c'est cet aspect
13:24
Speaker 2: que de nombreux projets sous-estiment. Installer un copilote prêt à
13:26
Speaker 2: l'emploi peut vous donner quelque chose qui semble fonctionnel, mais
13:29
Speaker 2: s'il n'a pas été formé avec les mêmes connaissances que
13:30
Speaker 2: celles sur lesquelles vos employés s'appuient, il n'ira pas loin.
13:33
Speaker 2: Au mieux, il comble des lacunes superficielles avec des réponses
13:36
Speaker 2: précises mais vagues. Au pire, il donne des conseils peu
13:39
Speaker 2: fiables aux utilisateurs et sape complètement la confiance. Ce qui
13:42
Speaker 2: fait la différence, c'est l'ancrage des connaissances. Le fait de
13:44
Speaker 2: fournir à l'agent les bonnes données et de les connecter
13:45
Speaker 2: au flux de travail ou au travail réel se déroule réellement.
13:49
Speaker 2: Pensez au contraste. Un copilote sans contexte peut vous dire
13:51
Speaker 2: comment rédiger un email professionnel car il a vu des
13:54
Speaker 2: millions d'exemples. Mais si quelqu'un vous pose des questions sur
13:56
Speaker 2: les conditions spécifiques de la politique de remboursement de votre
13:59
Speaker 2: entreprise ou sur ce qui est considéré comme une dépense
14:00
Speaker 2: d'investissement dans votre système financier, ce même copilote vous semblera
14:03
Speaker 2: soudain vide. Il peut enchaîner quelque chose qui semble« raisonnable»
14:06
Speaker 2: Mais être raisonnable ne suffit pas lorsqu'une formulation incorrecte entraîne
14:09
Speaker 2: des retards, des problèmes de conformité ou une perte de revenu.
14:12
Speaker 2: Imaginez maintenant un agent qui a été connecté directement aux
14:14
Speaker 2: bases de connaissances approuvées de votre entreprise, aux processus documentés
14:17
Speaker 2: et aux systèmes à jour. Il ne se contente pas
14:20
Speaker 2: de répondre avec des termes génériques. Il peut extraire des
14:22
Speaker 2: règles précises de votre dossier de contrat, citer la bonne
14:25
Speaker 2: section de votre manuel de conformité ou acheminer la demande
14:27
Speaker 2: via un flux de travail interne. C'est à ce moment-là
14:30
Speaker 2: qu'un copilote passe du statut de nouveauté à celui de
14:32
Speaker 2: collègue de confiance. Dans Copilot Studio, il existe deux manières
14:36
Speaker 2: principales d'optimiser cette intelligence. La mise à la terre des
14:38
Speaker 2: connaissances et les compétences. La mise à la terre des
14:40
Speaker 2: connaissances est la partie où vous connectez le copilote aux
14:42
Speaker 2: sources dont votre organisation dépend déjà. Il peut s'agir de
14:45
Speaker 2: bibliothèques SharePoint où résident les politiques ou de wikis internes
14:48
Speaker 2: que le personnel consulte tous les jours. En les intégrant
14:50
Speaker 2: à l'environnement de l'agent, vous lui donnez la possibilité de
14:52
Speaker 2: récupérer et de réutiliser du contenu qui correspond exactement à
14:55
Speaker 2: vos besoins plutôt que de s'appuyer sur des modèles linguistiques
14:57
Speaker 2: vagues pour deviner son chemin. Les compétences sont ce qui
15:00
Speaker 2: rend le copilote actif au lieu d'être simplement informatif. Ce
15:03
Speaker 2: sont les connecteurs vers les API, les workflows et les
15:05
Speaker 2: applications qui permettent à l'agent d'agir plutôt que de simplement parler.
15:08
Speaker 2: Par exemple, la liaison avec la billetterie ServiceNow permet à
15:11
Speaker 2: un agent du support informatique de fixer une date ou
15:13
Speaker 2: de fermer des tickets directement. Au lieu de réécrire des
15:16
Speaker 2: extraits de politique, le copilote peut guider l'utilisateur à travers
15:19
Speaker 2: les étapes, tout en effectuant la tâche en arrière-plan. Cette
15:23
Speaker 2: combinaison de connaissances et de compétences intégrées distingue un chatbot
15:26
Speaker 2: d'un véritable assistant. Un chatbot récite et l'agent agit. Les
15:30
Speaker 2: risques de sauter cette étape apparaissent rapidement. Si un copilot
15:33
Speaker 2: donne ne serait-ce qu'une seule réponse importante qui s'avère fausse,
15:35
Speaker 2: les utilisateurs s'en souviennent. Ce souvenir perdure bien plus longtemps
15:38
Speaker 2: que toute bonne expérience, en particulier dans les secteurs très réglementés.
15:43
Speaker 2: Il suffit d'une seule assurance erronée concernant la conformité ou
15:45
Speaker 2: d'un seul état financier inexact pour entamer la confiance qu'une
15:48
Speaker 2: équipe entière a dans l'outil. Reconstruire l'adoption après ce genre
15:51
Speaker 2: de revers est bien plus difficile que d'investir dans une
15:53
Speaker 2: intégration de données appropriée dès le départ. Même lorsque les
15:55
Speaker 2: bases sont solides, le défi n'est pas terminé. Les règles
15:58
Speaker 2: métiers changent, les flux de travail évoluent et les politiques
16:00
Speaker 2: sont mises à jour. Cela signifie que la formation d'un
16:03
Speaker 2: agent n'est pas une tâche ponctuelle. C'est un processus itératif
16:05
Speaker 2: qui nécessite un ajustement au fil du temps. Un nouveau
16:08
Speaker 2: cadre de conformité peut nécessiter une refonte. Une migration de
16:11
Speaker 2: système peut impliquer une mise à jour des compétences. Même
16:13
Speaker 2: les changements de langage, comme la façon dont les équipes
16:15
Speaker 2: parlent des produits ou des processus, peuvent venir aux performances
16:17
Speaker 2: s'ils sont ignorés. Cette boucle d'amélioration continue est ce qui
16:20
Speaker 2: distingue les équipes qui voient une valeur croissante de celle
16:22
Speaker 2: dont le copilote devient obsolète après le lancement. La récompense
16:25
Speaker 2: pour s'y tenir est que votre copilote commence à travailler
16:27
Speaker 2: en temps réel avec la même profondeur que vos experts
16:29
Speaker 2: apportent à leur rôle. Un copilote RH peut fournir des
16:32
Speaker 2: détails sur les politiques sans avoir à contacter le personnel
16:34
Speaker 2: RH pour chaque petite question. Un copilote financier peut guider
16:38
Speaker 2: un analyste à travers les chaînes d'approbation tout en extrayant
16:40
Speaker 2: les bons chiffres des systèmes actuels. Il ne s'agit pas
16:43
Speaker 2: seulement de gains d'efficacité et change la façon dont les
16:44
Speaker 2: gens perçoivent l'utilisation de l'outil. Au lieu d'un système de
16:47
Speaker 2: puce avec lequel il faut se débattre, il devient le
16:49
Speaker 2: chemin le plus rapide vers des réponses fiables et des
16:50
Speaker 2: tâches accomplies. C'est pourquoi la frontière entre un chatbot et
16:53
Speaker 2: un copilote est importante. Un chatbot tient des conversations, un
16:57
Speaker 2: copilote prend le contexte, le combine avec des actions et
16:59
Speaker 2: le transforme en une assistance à laquelle Les gens font confiance.
17:02
Speaker 2: Les agents les plus efficaces sont ceux qui reflètent ce
17:03
Speaker 2: que votre équipe sait déjà et peuvent agir immédiatement sur
17:05
Speaker 2: la base de ses connaissances. Une fois la conception et
17:09
Speaker 2: la formation en place, le défi final consiste à gérer
17:11
Speaker 2: le déploiement lui-même. Car un copilote techniquement solide peut toujours
17:14
Speaker 2: échouer s'il ne passe pas l'étape de l'adoption après adoption.
17:18
Speaker 2: Évitez les pièges sur la voie de la mise en service.
17:20
Speaker 2: La raison la plus courante pour laquelle les projets de
17:22
Speaker 2: copilote échouent n'est pas le développement, mais le déploiement. Les
17:25
Speaker 2: équipes passent souvent des semaines à peaufiner les personas, à
17:27
Speaker 2: créer des cas d'utilisation et à intégrer des sources de
17:29
Speaker 2: données pour finalement voir toute l'initiative s'enliser, une fois qu'il
17:32
Speaker 2: est temps de confier l'agent aux employés. Une foyer. Ce
17:35
Speaker 2: n'est pas parce que la technologie ne fonctionne pas, mais
17:37
Speaker 2: parce que l'aspect humain du déploiement est souvent négligé. Souvent négligé.
17:40
Speaker 2: La gouvernance n'est pas définie, les attentes ne sont pas gérées,
17:42
Speaker 2: les plans d'adoption sont une réflexion après coup. Ce qui
17:45
Speaker 2: commence par l'énergie au lancement s'essouffle souvent avant que de
17:47
Speaker 2: vrais résultats n'apparaissent. Si vous avez déjà été témoin de
17:49
Speaker 2: l'excitation d'une réunion de lancement de projet, vous connaissez le sentiment.
17:52
Speaker 2: Une feuille de route est affichée sur le mur, les
17:53
Speaker 2: gens en sont convenus et tout le monde attend avec
17:55
Speaker 2: impatience la première démonstration. Le premier flux de travail est
17:57
Speaker 2: mis en œuvre, le copilote répond aux questions de test
17:59
Speaker 2: et tout semble prometteur. Entre cette démonstration et une véritable
18:02
Speaker 2: mise en service, le terrain change. Les dirigeants demandent des
18:04
Speaker 2: fonctionnalités supplémentaires en cours de projet, les utilisateurs finaux ne
18:06
Speaker 2: savent pas comment ni quand utiliser l'outil. Et les équipes
18:08
Speaker 2: de projet réalisent qu'elles n'ont jamais défini de procédure pour
18:10
Speaker 2: déterminer qu'examiner procédure pour déterminer procédure pour déterminer qu'examiner modification
18:12
Speaker 2: ou approuver les données de formation ou approuver les données
18:14
Speaker 2: de formation. C'est entre la construction et le déploiement que
18:16
Speaker 2: l'élan s'éteint tranquillement. Pensez à un agent qui a parfaitement
18:19
Speaker 2: fonctionné pendant les tests internes mais qui a trébuché lors
18:21
Speaker 2: de la publication, meuh. Les employés l'ont ouvert une ou
18:24
Speaker 2: deux fois, n'ont pas compris les problèmes qu'ils résolvaient et
18:26
Speaker 2: sont repartis peu impressionnés. Dans certains cas, l'équipe de construction
18:29
Speaker 2: s'est tellement concentrée sur la précision technique qu'elle n'a jamais
18:31
Speaker 2: préparé de plan de communication. Les utilisateurs finaux ont supposé
18:34
Speaker 2: que le copilote pouvait répondre à toutes les questions concernant
18:36
Speaker 2: leur rôle. Au lieu de cela, lorsqu'ils ont posé la
18:38
Speaker 2: première question de non détaillée, l'agent a répondu vaguement. Ce
18:41
Speaker 2: moment a suffi à éroder la confiance. L'adoption ne s'est
18:44
Speaker 2: jamais rétablie, car le déploiement n'était pas conçu pour gérer
18:46
Speaker 2: la perception et les commentaires des utilisateurs. L'adhérie des objectifs
18:49
Speaker 2: ajoute une autre rouche de problèmes. Imaginons qu'un projet ciblait
18:52
Speaker 2: initialement deux scénarios à forte valeur ajoutée pour les analystes financiers.
18:56
Speaker 2: À mi-parcours, les demandes commencent à affluer. Cela peut-il également
18:59
Speaker 2: aider les RH à intégrer de nouveaux employés ou peut-être
19:01
Speaker 2: proposer des étapes de dépannage informatique? La direction souhaite montrer
19:04
Speaker 2: l'impact sur tous les services et pourquoi ces demandes sont ajoutées. Désormais,
19:07
Speaker 2: l'équipe du projet est à bout de souffle, les délais
19:09
Speaker 2: sont dépassés et les premiers cas d'utilisation à forte valeur
19:11
Speaker 2: ajoutée finissent par être retardés. Au moment où les tests
19:13
Speaker 2: sont terminés, le copilote essaie de servir cinq directions à
19:15
Speaker 2: la fois et n'en satisfait aucune, et n'en satisfait pas.
19:18
Speaker 2: Le déploiement est à nouveau repoussé, la confiance dans le
19:20
Speaker 2: projet s'effrite et la promesse initiale ne se concrétise jamais.
19:23
Speaker 2: Pour éviter cette spirale, il faut de la structure. Une
19:25
Speaker 2: méthode éprouvée consiste à effectuer des déploiements bons. Au lieu
19:28
Speaker 2: d'imposer l'agent à toute l'entreprise en même temps, commencer par
19:31
Speaker 2: un petit groupe pilote qui représente le personnage principal, recueillir
19:34
Speaker 2: ses commentaires, surveiller les types de questions qu'il pose et
19:36
Speaker 2: mesurer les taux d'adoption dans un environnement contrôlé. Des problèmes surviennent,
19:40
Speaker 2: des ajustements peuvent être effectués discrètement avant de passer à
19:41
Speaker 2: l'échelle supérieure. Parallèlement, la définition de mesures transparentes de la
19:45
Speaker 2: réussite permet de maintenir l'enthousiasme Si la réussite est définie
19:48
Speaker 2: comme 50% des tickets résolus sans intervention humaine ou des
19:51
Speaker 2: contrôles de conformité effectués en moins de deux minutes, alors
19:54
Speaker 2: tout le monde peut voir les progrès en termes clairs
19:56
Speaker 2: plutôt que par des affirmations vagues. Les bons projets d'IA
19:59
Speaker 2: ont également des champions, des personnes qui servent de traducteurs
20:01
Speaker 2: internes entre l'équipe technique et la base d'utilisateurs quotidiens. Ces
20:04
Speaker 2: champions aident à définir les bonnes attentes en montrant au
20:07
Speaker 2: collègue ou le copilote excelle et où il n'excelle pas
20:10
Speaker 2: Au lieu de promettre que l'IA résoudra tout, ils expliquent
20:12
Speaker 2: quelles tâches spécifiques elle prend en charge et pourquoi elles
20:14
Speaker 2: ont été choisies comme priorité. Ce type de plaidoyer a
20:17
Speaker 2: plus de poids s'il vient de pair que des annonces
20:19
Speaker 2: informatiques qui apparaissent dans un bulletin d'information d'entreprise. Cela renforce
20:23
Speaker 2: la crédibilité de chaque personne, ce qui permet de faire
20:24
Speaker 2: évoluer l'adoption d'une manière qu'aucune annonce ne peut réaliser seule.
20:27
Speaker 2: L'élan qui suit la première démonstration découle de la gestion
20:29
Speaker 2: de cet équilibre entre ambition et réalité. L'agent ne doit
20:32
Speaker 2: pas être caché dans un laboratoire d'innovation sans visibilité, mais
20:34
Speaker 2: il ne peut pas non plus être présenté à l'ensemble
20:35
Speaker 2: du personnel. Les déploiements qui réussissent sont généralement assortis d'un
20:39
Speaker 2: séquençage patient. Piloté, développé puis intégré au flux de travail quotidien.