Comment j'ai automatisé un flux de travail d'e-mails en 13 langues en utilisant uniquement l'IA et les outils Microsoft

La localisation des campagnes d'e-mails à travers plusieurs régions était autrefois une tâche lente et répétitive comportant de nombreuses étapes manuelles. Plusieurs réviseurs travaillaient sur des versions séparées, le même contenu était réécrit plusieurs fois, et la gestion de la cohérence dans jusqu'à 13 langues nécessitait une coordination importante.

Au lieu d'introduire de nouvelles plateformes ou des outils externes, j'ai mené une expérience interne : \n La localisation pourrait-elle être automatisée en utilisant uniquement les outils déjà disponibles dans un environnement Microsoft d'entreprise standard ?

Le prototype s'appuyait principalement sur SharePoint, Power Automate et Teams, avec un composant supplémentaire - GPT-4.1 mini accessible via Azure OpenAI - utilisé strictement pour une étape de contrôle qualité contrôlée. Cela a permis au processus de bénéficier du raisonnement basé sur les LLM tout en conservant toutes les données dans le même environnement d'entreprise.

Pour soutenir ce flux de travail, j'ai mis en place une bibliothèque SharePoint structurée appelée Email translations avec des dossiers représentant chaque étape du cycle de vie de la localisation :

| Dossier | Objectif | |----|----| | 01IncomingEN | Fichiers source en anglais ; déclencheur Power Automate | | 02AIDrafts | Brouillons traduits automatiquement par Copilot + GPT | | 03InReview | Fichiers en attente de révision régionale | | 04Approved | Traductions finales approuvées | | 99Archive | Versions archivées ou rejetées |

Les fichiers se déplaçaient automatiquement entre ces dossiers en fonction de leur état.

L'objectif n'était pas de construire un système de localisation parfait - seulement de voir jusqu'où un prototype pourrait aller en utilisant des outils internes.

Cela a fini par éliminer une grande partie du travail répétitif et a créé un processus de révision beaucoup plus structuré.

Le problème : le processus, pas la langue

La localisation manuelle du contenu à travers de nombreuses régions créait plusieurs problèmes constants :

• Chaque région modifiait son propre fichier, donc plusieurs versions différentes existaient en même temps.
• Lorsque le texte source changeait, toutes les régions ne mettaient pas à jour leur version, ce qui conduisait à un contenu non concordant.
• Les fichiers étaient enregistrés à différents endroits et avec des noms différents, ce qui rendait difficile l'identification de la version actuelle.
• Les révisions prenaient du temps, surtout lorsque les équipes se trouvaient dans des fuseaux horaires différents.
• La répétition des mêmes modifications dans de nombreux fichiers augmentait le risque de petites erreurs

Tentative 1 : Traduction uniquement par Copilot

Bien que Copilot fonctionne maintenant sur des modèles plus récents de la série GPT-5, ce prototype a été construit sur une version antérieure, et le comportement de traduction reflétait ces capacités antérieures.

La première version du flux de travail était simple :

1. Un fichier était téléchargé dans 01IncomingEN.
2. Power Automate se déclenchait automatiquement.
3. Copilot générait une traduction pour chaque région.

Comme les déclencheurs SharePoint peuvent s'activer avant qu'un fichier ne finisse de se télécharger, le flux incluait une vérification de la taille du fichier (attendre jusqu'à ce que la taille soit > 0 avant de continuer).

Cependant, le problème principal est rapidement devenu évident : les traductions de Copilot n'étaient pas assez fiables pour une localisation de bout en bout.

Les problèmes courants incluaient :

• Des CTA traduits trop littéralement
• Le ton et le style variant entre les langues
• Des espaces réservés supprimés ou modifiés
• Des différences de formatage dans les listes, l'espacement et la structure

Cela rendait Copilot utile uniquement pour générer une première ébauche. \n Une deuxième couche de contrôle qualité était nécessaire.

Tentative 2 : Ajout de GPT-4.1 Mini pour le contrôle qualité

La version suivante a ajouté une étape de révision :

1. Copilot → traduction initiale
2. GPT-4.1 mini (Azure) → Contrôle qualité et vérification de cohérence

GPT-4.1 mini a amélioré :

• la cohérence du ton
• la préservation des espaces réservés
• la stabilité du formatage
• l'alignement avec le sens de la source

Les prompts nécessitaient des ajustements pour éviter des réécritures inutiles, mais après ces ajustements, les résultats sont devenus suffisamment cohérents pour être utilisés dans le flux de travail.

Travail d'ingénierie : Rendre le flux de travail fiable

L'architecture était simple, mais plusieurs problèmes sont apparus lors de l'utilisation réelle et ont nécessité des corrections.

Comportement de la plateforme :

• Les déclencheurs SharePoint ne démarraient pas toujours immédiatement, donc des vérifications et des nouvelles tentatives ont été ajoutées.
• Le routage Teams échouait lorsque les canaux étaient renommés, donc le mappage a dû être mis à jour.

Problèmes de conception :

• Certaines étapes parallèles échouaient lors de la première exécution, donc une logique de nouvelle tentative a été introduite.
• Les réponses JSON manquaient parfois des champs attendus, donc une validation a été ajoutée.
• Les noms de fichiers étaient incohérents, donc un format de nommage unique a été défini.

Après ces ajustements, le flux de travail fonctionnait de manière fiable dans des conditions normales.

Architecture finale du prototype

Ci-dessous se trouve la structure de travail complète du système.

1. Téléchargement et réception SharePoint

Le processus commençait lorsqu'un fichier était téléchargé dans Email translations / 01IncomingEN

Power Automate ensuite :

• vérifiait que le fichier était entièrement téléchargé (protection contre les fichiers vides)
• récupérait les métadonnées
• extrayait le texte
• identifiait les régions cibles

SharePoint agissait comme source unique de vérité pour toutes les étapes.

2. Orchestration Power Automate

Power Automate contrôlait chaque partie du flux de travail :

• lecture de la source anglaise
• appel à Copilot pour la traduction préliminaire
• envoi du brouillon à GPT-4.1 mini pour le contrôle qualité
• création d'une branche par région
• envoi par e-mail des résultats aux équipes locales
• publication de cartes d'approbation Teams
• capture des réponses "approuver" ou "demander des modifications"
• sauvegarde des fichiers approuvés dans 04_Approved
• sauvegarde des versions mises à jour dans 03InReview
• archivage des anciennes versions dans 99_Archive

Tout le routage, les nouvelles tentatives et les transitions d'état étaient gérés par Power Automate.

3. Passage de traduction Copilot

Copilot traduisait le contenu extrait et préservait la plupart de la structure de l'e-mail - listes, espacement et formatage - mieux que GPT seul.

4. Passage de contrôle qualité GPT-4.1 Mini

GPT-4.1 mini vérifiait :

• la cohérence du ton
• l'alignement du sens
• la stabilité du formatage
• l'intégrité des espaces réservés

Cela créait un brouillon plus fiable pour la révision régionale.

5. Révision régionale (E-mail + Teams)

Pour chaque région, Power Automate :

• envoyait le fichier traduit par e-mail
• publiait une carte adaptative Teams avec Approuver / Demander des modifications

Si des modifications étaient soumises, le fichier mis à jour retournait dans 03InReview et réintégrait le flux de travail.

6. Stockage final

Les traductions approuvées étaient stockées dans 04_Approved en utilisant un format de nommage cohérent.

Les versions rejetées ou obsolètes étaient déplacées vers 99_Archive. Cela assurait une piste d'audit complète et propre.

Résultats

Après avoir testé le prototype dans des flux de travail réels :

• le temps de traduction est passé de jours à minutes
• moins de conflits de version
• réécriture manuelle minimale
• cycles de révision plus rapides
• toutes les données traitées dans l'environnement Microsoft

Cela n'a pas remplacé les systèmes de localisation dédiés, mais a éliminé une quantité importante de travail manuel répétitif.

Limitations

• certaines langues nécessitaient encore des ajustements stylistiques
• les approbations Teams dépendaient des temps de réponse des réviseurs
• le flux nécessitait une logique de nouvelle tentative pour les erreurs transitoires
• la cohérence du ton variait sur les e-mails longs ou complexes

Ces limitations étaient acceptables pour un prototype.

Prochaine étape : Mémoire de terminologie

La prochaine amélioration prévue est une bibliothèque de terminologie basée sur des vecteurs contenant :

• glossaire
• noms de produits
• termes restreints
• formulations spécifiques à la région
• groupes de synonymes
• règles de ton

Les deux modèles utiliseraient cette bibliothèque avant de produire ou de vérifier les traductions.

Réflexions finales

Ce projet était une expérience interne pour comprendre quelle partie du flux de travail de localisation pourrait être automatisée en utilisant uniquement des outils Microsoft standard et un LLM hébergé sur Azure. Le prototype a considérablement réduit l'effort manuel et amélioré la cohérence entre les régions sans ajouter de nouveau logiciel.

Ce n'est pas une plateforme de localisation complète - mais cela montre ce qui peut être réalisé avec un flux de travail simple et bien structuré au sein de la pile d'entreprise existante.

\