Intelligence artificielle / Cas d’usage / Courriels
Une boîte de réception partagée qui se trie, se prépare et se trace
Comprendre la demande, préparer la réponse, ouvrir le dossier au bon endroit — et laisser un humain envoyer.L’adresse info@, commandes@ ou support@ reçoit deux cents courriels par jour. Trois personnes la lisent, chacune à sa façon ; la même demande arrive deux fois ; rien ne dit qui a répondu quoi. Le traitement automatique des courriels lit chaque message, comprend ce qui est demandé, prépare la réponse et crée le dossier là où il doit vivre — dans Customer Service, dans l’ERP, dans Teams. La personne relit et envoie. Rien ne part sans elle.
Trois situations que connaît toute boîte de réception partagée
Ce n’est pas un problème de volume, c’est un problème de forme : une boîte de réception partagée n’a ni file, ni propriétaire, ni trace.
Trois personnes lisent la même messagerie, et personne ne sait qui a pris quoi
Le message est lu par l’une, traité par l’autre, et répondu deux fois — ou aucune. Le client relance, on cherche dans les envoyés, on trouve la réponse d’un collègue en vacances. La boîte de réception partagée est un espace de travail sans règles de travail.
Une messagerie n’est pas une file.
La demande simple prend autant de temps que la compliquée
« Où en est ma commande ? », « Quel est votre horaire ? », « Pouvez-vous me renvoyer la facture ? » : la réponse est dans un système, la personne la cherche, la recopie, la met en forme. Vingt fois par jour. Pendant ce temps, la réclamation qui méritait une heure attend.
Le simple encombre, le compliqué attend.
Rien n’est tracé là où le dossier vit
La conversation est dans Exchange ; le client est dans Dynamics 365 ou l’ERP ; l’engagement pris par courriel n’est nulle part. Six mois plus tard, personne ne retrouve ce qui a été promis. L’audit demande la preuve, et la preuve est dans une messagerie que quelqu’un a archivée.
Ce qui n’est pas dans le dossier n’a pas existé.
Ce que fait la solution, dit en langage courant
Six gestes, du message qui arrive au dossier qui se ferme. Le cinquième — préparer sans envoyer — est celui qui rend le reste acceptable.
Le système lit le message et ses pièces jointes
Le texte, la signature, le fil précédent, le PDF attaché. Il identifie l’expéditeur dans vos systèmes — client connu, fournisseur, inconnu — et le sujet réel, pas seulement la ligne d’objet.
Le système reconnaît la demande et en extrait les données
Une réclamation sur la commande 4521, une demande de facture, une question sur un délai, une offre de fournisseur. Le numéro de commande, la date, le produit, l’urgence exprimée.
Le système envoie le message à la bonne file, avec sa priorité
Le service client, la comptabilité, les achats, le technicien de l’agence de Sion. Une réclamation d’un client important passe devant une demande d’horaires. Les règles sont les vôtres, écrites.
Le système crée ou complète le dossier dans l’outil qui le porte
Un ticket dans Dynamics 365 Customer Service, une ligne dans l’ERP, une tâche dans Teams — lié au client, avec le message et ses pièces jointes. La trace est là avant qu’un humain ait lu.
Le système rédige un brouillon de réponse, avec ses sources
Le statut de la commande lu dans l’ERP, la facture retrouvée, la procédure citée, le ton de l’entreprise. Le brouillon attend dans la messagerie de la personne, qui relit, corrige et envoie.
Le système garde la conversation dans le dossier
La réponse envoyée, l’engagement pris, le délai promis : dans le dossier client, pas dans une messagerie. Ce que l’audit demandera est déjà là.
Un exemple concret, étape par étape
Un client écrit à service@ : « Bonjour, la commande livrée hier est incomplète, il manque deux cartons, c’est urgent pour notre chantier de lundi. » L’entreprise tient ses clients dans Dynamics 365 et ses commandes dans l’ERP.
Ce qui reste humain
Le traitement lit, comprend, prépare et trace. Il n’engage jamais l’entreprise. Quatre décisions restent à des personnes nommées, et la première est la plus importante.
Les décisions qui ne se délèguent pas
Écrites avant la mise en service, testées, et revues chaque mois. Un traitement qui enverrait seul une réponse à un client engagerait l’entreprise sur une lecture faite par un modèle. Nous ne le réglons pas ainsi.
- Envoyer. Toute réponse vers l’extérieur est relue et envoyée par une personne. Le brouillon accélère ; il ne remplace pas.
- Engager. Un délai, un remboursement, un geste commercial, une remise : jamais dans un brouillon, toujours dans la main de quelqu’un qui a le droit de le promettre.
- Arbitrer l’ambigu. Un message que le traitement ne comprend pas avec assez de confiance va dans une file « à qualifier », lu par un humain. Il ne devine pas.
- Décider des règles. Les files, les priorités, le ton des brouillons, les seuils de confiance : décidés par le service, relus chaque mois sur les erreurs constatées.
Les données utilisées, et ce qu’elles exigent
Le message ne suffit pas à répondre : c’est ce que vos systèmes savent du client et de sa commande qui fait la qualité du brouillon.
Les sources
- Exchange Online : la boîte de réception partagée, le fil de la conversation, les pièces jointes.
- Dynamics 365 : le client, son contrat, ses dossiers ouverts, son historique.
- L’ERP : la commande, la livraison, la facture, le stock.
- La base de connaissance : les procédures, les horaires, les conditions — ce que les réponses répétitives citent.
- Les réponses passées : le ton de l’entreprise, appris sur ce que vos équipes ont déjà écrit.
Ce qu’elles doivent avoir
- Un client identifiable : une adresse de courriel connue dans Dynamics 365 ou l’ERP. Un référentiel client en trois exemplaires rend l’identification hasardeuse.
- Une base de connaissance à jour, avec un propriétaire. Un brouillon qui cite un horaire faux est pire qu’un brouillon vide.
- Des files et des rôles définis : qui traite quoi, dans quel délai. Sans eux, le routage n’a nulle part où aller.
- Un échantillon réel pour le prototype : les cinq cents derniers messages, pas les cinquante plus simples.
- La rétention : combien de temps les messages sont conservés dans le dossier, et selon quelle règle légale.
Où la solution fonctionne, et laquelle nous étudierions d’abord
Pour ce cas, la réponse est presque toujours la même : là où la messagerie et le dossier sont déjà.
Chez Microsoft
RecommandéeLa messagerie est dans Exchange Online, le dossier dans Customer Service, l’orchestration dans Power Automate, l’agent dans Copilot Studio. Tout est déjà là ; le premier flux sort en quelques semaines.
Dans vos locaux
RarementSeulement si la messagerie est encore sur un serveur Exchange dans vos locaux et doit y rester. Le traitement s’adapte ; il perd l’intégration native.
Une partie chez Microsoft, une partie dans vos locaux
PossibleQuand les pièces jointes sont sensibles — dossiers médicaux, données bancaires — leur lecture s’exécute dans vos locaux, l’orchestration reste chez Microsoft.
À côté de la machine
À éviterUn courriel n’a besoin ni de millisecondes ni d’atelier.
Pourquoi en ligne, et quand nous dirons autre chose
Trois critères décident pour ce cas d’usage, et les trois pointent dans la même direction — ce qui est rare.
| Critère | Ce qui fait pencher | Vers quoi |
|---|---|---|
| Où est la messagerie | Dans Exchange Online pour la plupart des entreprises. Le traitement s’y branche nativement ; le déplacer ailleurs ajouterait une copie de chaque message. | En ligne |
| Où vit le dossier | Dans Dynamics 365 Customer Service, dans l’ERP, dans Teams. L’écriture du dossier et la lecture du client se font par des connecteurs qui existent déjà. | En ligne |
| La sensibilité des pièces jointes | Un message est rarement confidentiel au point d’exclure le service ; ses pièces jointes le sont parfois. Leur lecture peut alors s’exécuter dans vos locaux, le reste ne bouge pas. | Hybride, pour les pièces jointes seulement |
Les fonctions d’intelligence artificielle de Copilot Studio et de Dynamics 365 se consomment à l’usage — par message traité, par réponse préparée. Nous chiffrons sur votre volume réel avant, et quelqu’un regarde la facture après.
Ce à quoi la solution se raccorde
C’est un cas d’usage d’intégration avant d’être un cas d’intelligence artificielle : lire un message est facile, écrire au bon endroit est le travail.
L’infrastructure : aucune, pour ce cas
Un traitement de courriels dans Microsoft 365 ne demande ni serveur ni processeur graphique. C’est un des cas d’usage les plus rapides à mettre en service.
Des pièces jointes qui ne peuvent pas être lues en ligne
Dossiers médicaux, données bancaires, documents sous contrat : leur lecture s’exécute en conteneurs dans vos locaux, sur Azure Local, et le reste du traitement ne bouge pas. Le cas rejoint alors celui du traitement des documents, qui décrit cette variante.
Comment nous réalisons le projet
Cinq temps. Le prototype tourne en parallèle de votre messagerie réelle, sans rien envoyer, pendant deux semaines : c’est la seule façon de connaître le vrai taux de messages compris.
Le cadrage : la messagerie telle qu’elle est
Qui la lit, comment les messages se répartissent, combien reviennent, où finit chaque type de demande, ce qui est promis par courriel et jamais tracé. Et l’état du référentiel client.
Les règles et les brouillons
Ce que le traitement fait de chaque type de demande, ce qu’il ne fait jamais, le ton des brouillons, les seuils de confiance, la file « à qualifier ». Écrit avec le service, pas pour lui.
Le prototype, en parallèle de la messagerie réelle
Deux semaines sur les messages entrants, sans rien envoyer ni écrire dans les systèmes de production. On mesure le taux de demandes comprises, la justesse du routage, la qualité des brouillons jugée par ceux qui les auraient envoyés.
Le raccordement et la mise en service
Customer Service, l’ERP, Teams, la base de connaissance. Un type de demande d’abord — les questions de statut de commande, souvent — puis les autres.
Le maintien
Les messages mal compris relus chaque mois, les brouillons corrigés souvent réécrits, la base de connaissance complétée, la consommation suivie.
Hypothèse de durée : six à dix semaines du premier assessment à la mise en service pour une boîte de réception partagée et deux ou trois types de demandes. C’est un ordre de grandeur, pas un engagement : la mesure fait partie du travail.
Périmètre et limites
Ce que le traitement ne fait pas, et ce que nous ne promettons pas.
Le système comprend mal une partie des messages
Un message ambigu, trois demandes dans un seul courriel, une ironie, un fil de vingt réponses : le traitement se trompe parfois sur la demande, et il le fait avec assurance. La file « à qualifier » et le seuil de confiance existent pour cela. Le taux réel se mesure au prototype, sur vos messages.
Le brouillon cite ce que vos systèmes disent — y compris quand c’est faux
Un statut de commande périmé, un horaire non mis à jour, une procédure ancienne : le brouillon les reprend. La qualité de la base de connaissance et des référentiels décide de celle des brouillons.
L’automatisation ne remplace pas la relation
Un client en colère, une réclamation qui engage, un fournisseur stratégique : le traitement prépare et trace, la personne appelle. Le gain est sur le simple et le répétitif, pour libérer du temps sur ce qui compte.
Le coût se consomme au message
Chaque message compris, chaque brouillon préparé se facture à l’usage. À deux cents messages par jour, c’est un budget qui se calcule — et qui se compare au temps humain qu’il libère. Nous le chiffrons avant.
Ce que nous ne réglerons pas
L’envoi automatique d’une réponse à un client sans relecture. C’est possible techniquement ; nous le déconseillons, et nous l’écrivons. Le jour où vous le voudrez quand même, ce sera votre décision, sur un type de demande précis, avec un journal.
Les cas voisins, et les pages qui vont avec
Quand un autre cas d’usage est le bon, et les technologies derrière celui-ci.
Service client et centre de contact
Quand la même demande arrive aussi par téléphone et par chat : l’agent aidé pendant l’appel, le dossier unique.
Voir le cas Cas voisinTraitement intelligent des documents
Quand la pièce jointe est le sujet : la facture, le contrat, le formulaire à extraire et à contrôler.
Voir le cas TechnologieDynamics 365 Customer Service
Le dossier comme unité de travail, les délais tenus et mesurés, la base de connaissance qui sert aux deux côtés.
Voir la page TechnologieCopilot Studio
L’agent qui comprend et prépare, avec une fiche de poste : ce qu’il sait, ce qu’il a le droit de faire, quand il passe la main.
Voir la page TechnologieExchange : la messagerie où tout commence
En ligne ou sur vos serveurs, et ce que chaque option change pour un traitement automatique.
Voir la page ArticleLes cas d’usage rentables dès le premier mois dans Microsoft 365
Ce qui se met en service sans projet, dans les licences que vous avez déjà.
Lire l’articleParlons de ce cas d’usage
Dites-nous ce qui arrive dans votre boîte de réception partagée
Combien de messages par jour, quels types de demandes reviennent, qui les traite, et où finit le dossier. Nous revenons avec les demandes que nous traiterions en premier, les règles que nous proposerions, et ce qu’un prototype de deux semaines en parallèle de votre messagerie permettrait de mesurer.
Ce que nous offrons, c’est la rencontre des ingénieurs qui feront le travail. Assessment, prototype et raccordement font partie du projet. La discussion qui les précède, elle, ne coûte rien.
Renens, Sion, Châtel-Saint-Denis
Microsoft Solutions Partner. La messagerie, le dossier, l’agent et le raccordement à l’ERP, avec la même équipe qui tient votre tenant.
Renens VD +41 21 806 37 15
Sion VS +41 27 552 00 22
Châtel-Saint-Denis FR +41 26 322 59 05