Automatiser des KPI cachés dans des centaines d'emails

Le projet en 30 secondes

Illustration du fonctionnement, interface, données et indicateurs présentés à titre d'exemple

1. Le problème : mesurer une performance cachée dans des emails

Le point de départ de ce projet est un besoin assez classique dans le transport.

Un client souhaitait mesurer précisément la performance de ses prestataires

Pour savoir si une prestation logistique est réellement performante, il ne suffit pas de savoir qu'un colis a finalement été livré.

Il faut pouvoir reconstruire ce qui s'est passé.

À quelle heure la demande a-t-elle été envoyée ?

À quelle heure l'équipe a-t-elle répondu ?

Quand le colis a-t-il été récupéré ?

Quand a-t-il été livré ?

Existe-t-il une preuve de livraison ?

Sur le papier, les KPI sont relativement simples.

Le problème est que les informations permettant de les calculer n'étaient pas toutes rangées dans quatre belles colonnes d'une base de données.

Une grande partie de l'histoire du dossier se trouvait dans Outlook et les emails sont excellents pour communiquer mais ils sont beaucoup moins pratiques lorsqu'il faut reconstruire automatiquement plusieurs centaines d'histoires opérationnelles.

2. Quelques timestamps qui peuvent demander des heures de recherche

Prenons un dossier simple:

Une demande arrive.

L'équipe répond.

Une collecte est confirmée.

Puis la livraison est annoncée avec une preuve.

Un humain peut ouvrir la conversation et comprendre assez rapidement ce qui s'est passé.

Maintenant, répétons l'exercice dossier après dossier.

Et ajoutons la réalité:

Plusieurs personnes répondent.

Certains messages reprennent l'intégralité des emails précédents.

Des informations apparaissent dans des signatures ou des citations.

Les formats changent.

Une heure peut correspondre à l'envoi d'un email, à une heure annoncée dans son contenu ou à un événement réellement réalisé.

Des messages sont en HTML.

Certains dossiers sont beaucoup plus complexes que d'autres.

Des fuseaux horaires différents peuvent également intervenir.

Et parfois, même pour un humain, il faut chercher.

C'est d'ailleurs encore visible aujourd'hui : les dossiers que le système ne parvient pas à traiter automatiquement sont généralement les plus compliqués.

Les reprendre manuellement peut encore représenter plusieurs heures de travail.

C'est précisément pour cela que l'automatisation avait autant de valeur.

Le but n'était pas de faire disparaître quelques copier-coller.

Il fallait éviter qu'une personne passe une grande partie de son temps à lire des conversations pour transformer du texte en quatre ou cinq informations structurées.

3. Pourquoi Power Automate ?

Je connaissais encore assez peu Power Automate lorsque j'ai commencé ce projet.

Et les premiers retours que j'avais entendus n'étaient pas spécialement rassurants.

On me l'avait présenté comme quelque chose d'assez complexe à prendre en main dès que les workflows devenaient sérieux.

Mais en regardant mon problème, il y avait une raison évidente de l'essayer.

Tout mon environnement était déjà là: Outlook. Excel. Microsoft 365.

Power Automate savait communiquer avec ces outils.

Et surtout, il pouvait orchestrer les différentes étapes dont j'avais besoin.

Lire une donnée.

Chercher des emails.

Transformer du contenu.

Appeler un service externe.

Récupérer sa réponse.

Écrire le résultat dans Excel.

La technologie paraissait donc adaptée au processus et je me suis lancé.

Comme souvent dans mes projets, la première version était loin d'être la bonne.

4. Première idée : commencer là où se trouve l'information

Mon raisonnement initial semblait logique, les informations sont dans Outlook.

Commençons par Outlook.

Il fallait d'abord identifier les emails correspondant au client et aux dossiers recherchés.

J'ai donc travaillé avec différents critères et mots-clés permettant de réduire le périmètre de recherche.

À partir d'un email identifié, le workflow devait ensuite retrouver les autres messages correspondant au même dossier.

C'était nécessaire parce que je ne récupérais pas directement une conversation parfaitement reconstruite et prête à analyser.

Il fallait donc la fabriquer.

Chercher les différents messages.

Identifier ceux appartenant au même dossier.

Les rassembler.

Les remettre dans le bon ordre.

Puis préparer leur contenu.

À ce stade, j'étais encore persuadé que la principale difficulté serait de faire comprendre les conversations à l'IA.

En réalité, mon plus gros problème se trouvait une étape avant.

5. Transformer une conversation en quelque chose qu'une machine peut lire

Les emails récupérés depuis Outlook contenaient notamment du HTML.

Les envoyer tels quels aurait ajouté beaucoup de contenu inutile.

J'ai donc intégré une transformation permettant de convertir le contenu en texte.

J'ai également essayé d'aller plus loin en nettoyant les signatures, supprimant les parties répétitives, réduire le bruit au maximum.

Sur le papier, c'était une bonne idée.

Moins de texte inutile devait signifier une analyse plus simple et moins coûteuse.

Sauf qu'en pratique, certains nettoyages étaient trop agressifs.

En essayant d'enlever du bruit, je supprimais parfois aussi de l'information utile.

Une séparation mal détectée pouvait couper une partie du message.

Une signature pouvait se retrouver proche d'une information importante.

Un ancien email cité pouvait finalement apporter le contexte nécessaire à l'interprétation.

J'ai donc fini par faire quelque chose qui peut sembler contre-intuitif :

moins nettoyer.

Transformer le HTML vers du texte, oui, mais conserver davantage de contenu plutôt que risquer de détruire une information nécessaire.

C'est une leçon qui m'est restée.

Une donnée imparfaite mais complète peut être plus utile qu'une donnée parfaitement nettoyée dans laquelle on a supprimé ce qu'on cherchait.

6. Ajouter une IA au milieu du workflow

Une fois la conversation reconstruite et transformée en texte, il restait le problème principal :

comment retrouver automatiquement les événements importants ?

Une suite de règles classiques aurait été extrêmement difficile à maintenir.

Les personnes n'écrivent pas toutes :

« Heure de collecte : 14:32 »

L'information peut être formulée de dizaines de manières différentes.

C'est ici que l'utilisation d'un modèle de langage avait réellement du sens.

Pas pour « mettre de l'IA dans le projet ».

Mais parce que j'avais précisément un problème que les méthodes classiques géraient mal :

comprendre du langage humain non structuré et le transformer en données structurées.

J'ai donc ajouté une action HTTP dans Power Automate permettant d'appeler directement l'API OpenAI.

Le workflow envoyait la conversation accompagnée d'instructions précises.

Le modèle devait rechercher uniquement les informations présentes et retourner une structure définie.

La réponse revenait en JSON.

Power Automate pouvait ensuite interpréter ce JSON et écrire les différents champs dans un tableau Excel.

Dans cette architecture, l'IA n'était donc pas le système, elle était une brique spécialisée chargée de lire et le reste du workflow restait déterministe.

7. Techniquement, ça fonctionnait. Mais le résultat n'était pas assez bon.

J'ai travaillé longtemps sur cette première approche.

Recherche des emails.

Filtres.

Reconstruction.

Prompts.

Formats.

Sorties.

Rapprochement avec les données de l'ERP.

À force d'améliorations, le système fonctionnait techniquement.

Mais lorsque je regardais le résultat global, j'avais un problème beaucoup plus gênant :

je ne retrouvais qu'environ la moitié des dossiers attendus.

Autour de 50 %.

Et après plusieurs mois à travailler sur le projet en parallèle d'autres sujets, c'était difficile à accepter.

Je pouvais continuer à améliorer le prompt.

Changer le modèle.

Ajouter des règles.

Nettoyer davantage les emails.

Mais quelque chose me gênait.

Parce que l'IA ne pouvait analyser que ce que mon workflow réussissait à lui envoyer.

Et si je ne retrouvais pas correctement le dossier au départ, avoir le meilleur modèle du monde à la fin du pipeline ne changerait rien.

J'étais en train d'essayer d'améliorer les performances d'un système dont le point de départ était mauvais.

8. Une question a complètement changé le projet

Le déclic n'est pas venu d'une nouvelle technologie.

Il est venu d'une discussion.

En présentant les difficultés du projet à la manager qui suivait le sujet, elle m'a posé une question extrêmement simple :

« Pourquoi tu ne pars pas des dossiers terminés ? »

Et là, tout devenait beaucoup plus évident.

Mon principal problème était d'essayer de découvrir dans Outlook quels dossiers existaient.

Mais l'entreprise possédait déjà cette information.

Elle était dans l'ERP.

L'ERP pouvait me donner la liste des dossiers correspondant au périmètre et à la période recherchés.

Donc pourquoi demander à Outlook de me dire quels dossiers je devais chercher ?

Je pouvais déjà connaître la réponse avant même d'ouvrir Outlook.

C'est probablement la décision la plus importante de tout le projet.

Je n'ai pas amélioré la V1.

J'ai inversé le pipeline.

9. V2 : partir de la source de vérité

La nouvelle logique commence dans l'ERP.

Je récupère d'abord la liste des dossiers correspondant au périmètre à analyser.

Chaque dossier possède un identifiant connu.

Power Automate peut alors parcourir cette liste.

Pour chaque dossier :

je sais exactement ce que je cherche.

Le workflow prend l'identifiant, il recherche un email contenant cette référence et à partir de ce point d'entrée, il retrouve les éléments nécessaires pour reconstruire la conversation.

Puis seulement, il envoie le contenu à l'analyse.

Ce changement paraît presque évident une fois qu'on le voit, mais il a transformé les performances du système.

Parce que je ne demandais plus au workflow de résoudre deux problèmes en même temps :

découvrir les dossiers + comprendre leur contenu.

L'ERP résolvait le premier, Outlook et le modèle pouvaient se concentrer sur le second.

10. Reconstruire correctement le thread

Connaître le dossier ne suffisait évidemment pas.

En effet, il fallait toujours reconstruire son histoire.

Power Automate devait rechercher les messages correspondants et les remettre dans un ordre permettant de comprendre la chronologie.

Cette partie est importante parce que le modèle n'analyse pas simplement des phrases isolées.

Il doit comprendre une séquence d'événements.

Une demande.

Une réponse.

Une information de collecte.

Une confirmation de livraison.

Éventuellement une preuve.

Le contexte compte.

J'ai donc conservé la logique permettant de récupérer les différents messages et de construire un contenu textuel suffisamment complet.

Et contrairement à mes premières tentatives, je n'ai plus cherché à rendre artificiellement le texte « parfait ».

Le contenu HTML était transformé.

Mais les signatures, citations et répétitions pouvaient rester lorsqu'elles contribuaient à préserver le contexte.

Le modèle s'est révélé bien meilleur pour ignorer du bruit que mes règles ne l'étaient pour décider avec certitude ce qui constituait du bruit.

11. Changer de modèle, sans faire exploser les coûts

Au fil du projet, j'ai également fait évoluer le modèle utilisé.

Les premières versions reposaient sur un modèle léger choisi notamment pour maintenir un coût d'exploitation faible.

Lorsque de nouveaux modèles plus performants sont devenus disponibles, j'ai pu améliorer la compréhension du contexte tout en conservant une architecture très économique.

C'était important pour moi.

Une automatisation n'est réellement intéressante que si le coût de la solution reste cohérent par rapport au travail qu'elle supprime.

Ici, le volume de texte et le choix du modèle permettent de maintenir un coût API très faible à l'échelle du processus.

Cela crée un contraste assez intéressant :

derrière, il existe de la reconstruction de conversations, une API, un modèle de langage et une extraction structurée.

Mais le coût marginal de l'analyse automatisée reste minime face au temps nécessaire pour reconstruire manuellement les mêmes informations.

12. Je ne voulais plus seulement une réponse. Je voulais savoir pourquoi.

Un autre problème est apparu pendant les tests, l'IA pouvait me retourner une heure.

Mais comment vérifier rapidement qu'elle ne l'avait pas mal interprétée ?

Si le système dit :

Livraison : 14:32

je peux accepter l'information ou je peux retourner dans les emails et chercher moi-même d'où elle vient. Mais dans ce deuxième cas, je recommence une partie du travail que j'essayais justement d'automatiser.

J'ai donc modifié le format demandé au modèle.

Je ne voulais plus uniquement :

la valeur.

Je voulais aussi :

la justification.

Le modèle devait expliquer quelle information présente dans la conversation l'avait amené à retenir cette valeur.

Cela rend la vérification humaine beaucoup plus rapide.

Et surtout, cela change la relation avec l'IA.

Je ne lui demande pas :

« Donne-moi la réponse et je te crois. »

Je lui demande :

« Donne-moi la réponse et montre-moi pourquoi tu l'as choisie. »

13. Les détails qui peuvent casser un bon système

À mesure que la couverture augmentait, des problèmes beaucoup plus petits sont devenus visibles.

Par exemple : les fuseaux horaires.

Une heure techniquement correcte mais interprétée dans le mauvais fuseau peut rendre un KPI complètement faux.

Il a donc fallu normaliser les timestamps et gérer correctement les décalages entre les heures présentes dans les différents systèmes.

Autre problème :

que se passe-t-il si je relance le workflow plusieurs fois pendant le mois ?

Je ne voulais évidemment pas payer et attendre pour réanalyser les mêmes dossiers à chaque exécution.

J'ai donc ajouté une information très simple dans le tableau de suivi :

déjà analysé : oui / non.

Avant de lancer le traitement d'un dossier, le workflow peut vérifier son état.

S'il a déjà été traité correctement, il passe au suivant.

Ce n'est pas la partie la plus spectaculaire du projet.

Mais ce sont exactement ces petites sécurités qui transforment un prototype intéressant en outil réellement utilisable.

14. L'IA n'est toujours pas le dernier maillon

Une fois les conversations analysées, les résultats sont écrits sous forme structurée dans un tableau Excel.

Mais je ne voulais pas créer une nouvelle base complètement déconnectée de la réalité opérationnelle.

Il fallait reconnecter le résultat à la donnée ERP.

C'est là que Power Query revient dans le système.

D'un côté :

les dossiers issus de l'ERP.

De l'autre :

les informations retrouvées automatiquement dans les conversations.

Les deux peuvent être rapprochés grâce à leurs identifiants.

C'est seulement après ce rapprochement que l'information devient réellement utile pour le calcul et le contrôle des KPI.

Encore une fois, l'IA est une brique, elle résout le morceau du processus pour lequel elle est particulièrement adaptée : transformer une conversation humaine en informations structurées.

15. De 50 % à environ 80–90 %

Le changement d'architecture a complètement changé les résultats.

La première approche plafonnait autour de la moitié des dossiers correctement retrouvés et exploitables.

Avec l'approche basée sur les dossiers ERP comme point de départ, le système atteint désormais environ 80 à 90 % de couverture selon les exécutions.

Je trouve ce résultat particulièrement intéressant parce qu'il n'a pas été obtenu en ajoutant toujours plus d'IA.

Le gain principal est venu de la compréhension du processus.

Avant :

je demandais à mon système de découvrir quels dossiers existaient.

Après :

je lui donnais la liste exacte des dossiers à chercher.

C'est beaucoup plus simple.

Et les bons systèmes sont souvent comme ça.

Ils ne deviennent pas meilleurs parce qu'on ajoute de la complexité.

Ils deviennent meilleurs parce qu'on retire une ambiguïté.

16. Pourquoi je ne cherche pas forcément à automatiser les 100 %

Il reste des dossiers que le système ne traite pas correctement.

Évidemment, ma première réaction pourrait être :

il faut atteindre 100 %.

Mais lorsqu'on regarde les dossiers restants, on comprend vite pourquoi ils sont encore là.

Ce sont souvent précisément les cas les plus difficiles.

Conversations atypiques.

Informations ambiguës.

Dossiers particuliers.

Chronologies difficiles à reconstruire.

Et ce qui est intéressant, c'est que ces dossiers ne sont pas seulement difficiles pour la machine.

Ils sont aussi difficiles pour moi.

Lorsque je reprends manuellement les cas restants, plusieurs heures peuvent encore être nécessaires.

Cela signifie qu'automatiser les derniers pourcents pourrait demander énormément de règles, de développement et de contrôles supplémentaires pour traiter des situations qui sont, par définition, exceptionnelles.

À un moment, il faut donc se poser une autre question :

Est-ce réellement rentable ?

Pour moi, un bon système n'est pas forcément celui qui élimine absolument toute intervention humaine.

C'est celui qui réserve le temps humain aux situations où il apporte réellement quelque chose.

17. Ce que le client voit

Le client ne voit évidemment pas tout ça.

Il ne voit pas les boucles Power Automate.

Il ne voit pas les recherches Outlook.

Il ne voit pas le HTML transformé en texte.

Il ne voit pas la requête HTTP.

Il ne voit pas le JSON.

Il ne voit pas Power Query.

Et c'est très bien comme ça.

Il voit les KPI.

Il voit les résultats.

Il peut suivre la performance opérationnelle avec un niveau de détail qui aurait demandé énormément de travail manuel autrement.

Le retour le plus satisfaisant sur ce projet a été de constater l'intérêt suscité par le niveau de détail que le système permettait de produire.

Derrière cette impression de puissance, il n'y a pourtant pas un logiciel gigantesque.

Il y a surtout plusieurs outils correctement assemblés autour d'un processus compris en profondeur.

18. Le projet que j'ai failli résoudre au mauvais endroit

Avec le recul, c'est probablement ce que je trouve le plus intéressant.

Pendant longtemps, je pensais que mon problème était :

« Comment faire mieux comprendre les emails à l'IA ? »

Donc je travaillais sur le nettoyage.

Le prompt.

Le modèle.

Les règles.

Les filtres.

Mais le problème principal n'était pas là.

Le problème était :

« Comment être certain de chercher le bon dossier avant même de demander à l'IA de le comprendre ? »

Et la réponse existait déjà dans un autre système.

L'ERP savait quels dossiers avaient réellement existé.

Il suffisait de lui redonner son rôle de source de vérité.

C'est ce changement qui a transformé le projet.

19. Ce que je retiens de ce projet

Ce projet m'a appris quelque chose que je retrouve maintenant dans énormément de sujets d'automatisation.

Quand un système ne fonctionne pas suffisamment bien, la première réaction est souvent d'améliorer la technologie.

Ajouter une règle.

Changer de modèle.

Écrire un meilleur prompt.

Ajouter un contrôle.

Parfois, c'est exactement ce qu'il faut faire.

Mais parfois, on est simplement en train d'automatiser le mauvais chemin.

J'ai passé des mois à améliorer un pipeline qui partait d'Outlook parce que l'information que je cherchais était dans Outlook.

Puis une simple question a changé mon raisonnement :

pourquoi chercher dans les emails quels dossiers existent alors que l'ERP le sait déjà ?

À partir de là, tout est devenu plus simple.

L'ERP me dit quoi chercher.

Outlook me donne l'histoire du dossier.

Le modèle transforme cette histoire en données structurées.

Power Query reconnecte ces données au reste du système.

Et Excel permet finalement de les exploiter.

Chaque outil fait ce qu'il sait faire.

C'est probablement la principale leçon que je retiens :

le meilleur gain de performance du projet n'est pas venu d'un meilleur modèle d'IA. Il est venu d'une meilleure compréhension du flux.

Avant d'automatiser une tâche, êtes-vous certain d'avoir choisi le bon point de départ ?

Quand une tâche prend plusieurs heures, la tentation est naturelle :

automatisons exactement ce que fait aujourd'hui la personne.

Mais reproduire plus rapidement un mauvais processus ne crée pas forcément un bon système.

Il faut parfois commencer ailleurs.

Changer la source.

Inverser le flux.

Utiliser une information déjà disponible.

Supprimer une étape plutôt que chercher à l'accélérer.

C'est la partie des projets d'automatisation que je trouve la plus intéressante.

La technologie permet ensuite de construire.

Mais le plus gros gain vient souvent de la question posée juste avant :

pourquoi faisons-nous les choses dans cet ordre ?