Outlook → Excel Robot

Du macro-script au système de jobs

La première décision est de séparer l’écoute Outlook du traitement. Le contrôleur maître transforme chaque demande admissible en job. Des workers prennent ensuite les jobs selon les règles de routage. Le résultat, les logs et les verrous sont des objets distincts.

OUTLOOK LISTENER
      ↓
     JOB ──→ ROUTAGE ──→ WORKER 1 / 2 / 3
      ↓                     ↓
     LOCK                 RESULT
      └──────────────→      ↓
                         LOG / RÉPONSE

Capture d’email et normalisation

Le robot lit le corps HTML et cherche la structure métier plutôt qu’une mise en forme précise. Les valeurs sont normalisées avant tout contrôle : espaces, numéros, identifiants et colonnes attendues. Un cas incomplet est mis de côté avec une raison lisible au lieu d’être traité avec des colonnes décalées.

Anti-doublon

Un message possède un identifiant Outlook mais la logique métier peut aussi utiliser une clé de demande. Le contrôleur vérifie les traitements récents, pose un verrou temporaire puis ne marque le job terminé qu’après production du résultat. Un crash ne doit donc ni dupliquer la réponse ni bloquer définitivement le message.

Autorisation et quotas

Les demandes ne suivent pas toutes la même politique. Une première couche détermine l’autorisation par utilisateur, domaine ou règle par défaut. Une deuxième couche applique créneaux, limites par minute, cooldown, volume maximal et éventuelles exceptions explicitement configurées.

Workers et observabilité

Chaque worker écrit un résultat indépendant de la feuille d’interface. Le journal contient job, worker, étape, date, code d’erreur et décision. Cela permet de comprendre un incident sans afficher une succession de boîtes de dialogue à l’utilisateur.

Réponse Outlook

La réponse est construite à partir du message reçu afin de conserver le fil. Le robot utilise une réponse au thread, contrôle les destinataires puis injecte un corps HTML structuré. Les données techniques destinées au diagnostic restent dans le log et ne polluent pas le mail envoyé.

Pourquoi cette architecture est utile

Elle rend possible l’ajout de nouveaux types de demandes et de nouveaux workers sans transformer le classeur principal en bloc monolithique. Le système peut être testé en rejouant un job connu et en comparant le résultat attendu, ce qui est beaucoup plus fiable qu’un test manuel de bout en bout à chaque modification.

Contrats de données entre les étapes

Chaque worker reçoit un job normalisé au lieu de relire librement la boîte Outlook. Le job contient les champs nécessaires, l’identifiant de corrélation, la catégorie détectée et la règle d’autorisation appliquée. Le résultat indique succès, échec récupérable, échec définitif et données de sortie. Cette frontière permet de remplacer un worker sans modifier le listener.

Tests de non-régression

• Rejouer exactement le même email deux fois.
• Lancer deux workers sur la même file.
• Interrompre Excel après acquisition du lock.
• Recevoir un tableau HTML dont une colonne facultative manque.
• Dépasser le quota d’un utilisateur puis vérifier le cooldown.
• Tester ReplyAll avec To et CC réels de la demande de test.

Le test n’est réussi que si le deuxième passage ne reproduit pas l’effet métier et si le journal explique précisément pourquoi il a été ignoré ou reporté.