Architecture de référence
Du visiteur à Teams, au flux, puis retour sous contrôle
Dans le parcours documenté, un message du widget ou d'un canal social atteint le canal Teams choisi. Un mot-clé est défini par canal dans l'onglet Power Platform. Power Automate écoute le déclencheur de mots-clés Teams puis évalue des conditions, lit des données autorisées ou publie une carte.
Le trajet retour est la preuve centrale. Une lecture CRM ne répond pas encore au visiteur. Le pilote doit séparer publication interne Teams et message @WebChat renvoyé au client, puis montrer quand l'automatisation s'arrête pour une reprise humaine. Une note interne ne doit jamais sortir par erreur.
| Composant | Rôle documenté | À vérifier |
|---|---|---|
| Canal WebChat | Entrée Teams et mot-clé par canal | Source, destination, réponse interne ou client |
| Connecteur Teams | Déclencheurs et actions messages/cartes | Équipe, canal, propriétaire, droits et limites |
| Power Automate | Conditions, requêtes, rappels et transfert | Environnement, erreurs, reprises, supervision et licence |
| CRM/ERP/helpdesk | Lire une donnée ou lancer une action autorisée | Connecteur/API, rôles, minimisation et écriture |
| AI/Adaptive Card | Suggestion, contexte structuré ou action | Sources, validation, injection, droits et repli |
Licence et identité
Premium dépend du flux réel
Le guide WebChat indique des connecteurs premium pour son exemple AI et recommande une identité Microsoft dédiée, clairement reconnaissable, pour la connexion Teams. Microsoft distingue flux automatisés, planifiés et instantanés ainsi que contextes utilisateur et Process. Affirmer qu'un seul utilisateur Premium suffit toujours ou que chaque conseiller en a besoin serait trompeur.
Inventoriez propriétaire, connexions, utilisateurs run-only, service principals, environnements développement/test/production, connecteurs premium ou personnalisés et volumes. Demandez une analyse écrite. La licence WebChat par canal et les coûts Power Platform/Azure restent deux postes TCO séparés.
Gouvernance
DLP est un garde-fou, pas une validation de conformité
- Classer chaque connecteur et endpoint personnalisé dans une politique de données approuvée.
- Séparer développement, test et production et transporter références et variables proprement.
- Limiter les droits du flux et des systèmes aux lectures et écritures indispensables.
- Journaliser déclencheurs, requêtes, cartes, réponses, transferts et erreurs sans contenu superflu.
- Définir délais, reprises, alerte et fonctionnement manuel si un composant tombe.
- Examiner conservation et suppression séparément dans Teams, Power Platform, cible, AI et WebChat.
Recette
Huit tests avant la production
- 01
Figer le périmètre
Choisir un canal, un déclencheur, un système, une lecture et un transfert.
- 02
Documenter les identités
Nommer propriétaire, connexion Teams, compte cible, administrateurs, secrets et suppléance.
- 03
Prouver le parcours nominal
Envoyer un message, lire la bonne donnée, contrôler la carte et le retour visiteur.
- 04
Tester les refus
Données non autorisées, identifiants manipulés et requêtes larges doivent échouer proprement.
- 05
Forcer la reprise
Désactiver l'automatisation, répondre humainement puis réactiver sans doublon.
- 06
Simuler les pannes
Bloquer connecteur, cible et AI séparément et contrôler alerte, reprise et réponse manuelle.
- 07
Tester la concurrence
Des messages rapides ne doivent pas doubler actions, cartes ou réponses.
- 08
Valider coûts et exploitation
Confirmer licences, Azure, limites, supervision, support et retour arrière.