Vous classez un mail Outlook, le connecteur ouvre un second dossier CRM

Un client envoie une demande de devis à votre boîte ADV. Le connecteur l’associe à un dossier du CRM. Une collaboratrice classe ensuite le mail dans « Devis traités » et, au prochain passage, l’application crée un second dossier. Le contenu n’a pas changé, personne n’a envoyé une nouvelle demande et le commercial reçoit pourtant une nouvelle tâche. Avant de renforcer le filtre anti-doublon, vérifiez ce que votre intégration appelle l’identité du message.

En pratique, le risque vient du modèle de correspondance : une référence utilisée pour retrouver un mail ne devient pas automatiquement la clé durable du dossier métier. Le format d’identifiant reçu, son contexte de boîte et les correspondances déjà enregistrées doivent former un contrat explicite. Changer le format pour les prochains appels ne répare pas les anciens rattachements ; mélanger les deux populations peut même rendre la panne intermittente.

Ce diagnostic concerne les éditeurs de CRM, les applications de gestion et les équipes qui relient Outlook à un processus de devis, d’intervention ou de support. Le coût caché apparaît dans la charge support : dossiers ouverts deux fois, historiques répartis et reprises manuelles pour retrouver le bon lien. Notre travail d’intégration API reprend ces échanges avec le système métier qui les consomme.

Le cas se traite depuis le parcours du connecteur Microsoft Graph vers votre application : un mail initial, son classement et le dossier qui doit rester accessible. Treize entrées fictives montrent ensuite comment conserver une correspondance, attendre une traduction ou refuser un contexte incomplet. La démonstration porte sur cette décision locale, avec des identifiants inventés et aucune opération sur Microsoft 365.

Pour qui : le dossier se multiplie après le classement des mails

Reconnaître le défaut avant de supprimer un doublon

Demandez au support de retrouver un mail et les deux dossiers associés. Comparez les dates de réception, de classement et de création dans le CRM. Conservez les références techniques telles qu’elles ont été reçues, avec leur format connu. Un objet différent et une nouvelle réponse du client ne doivent pas être confondus avec la réapparition du même message sous une autre référence.

Un signal faible utile est une panne limitée aux utilisateurs qui rangent rapidement leur boîte. Un autre est une recherche CRM correcte depuis une vue, mais impossible depuis une notification récente. Ces observations orientent l’enquête vers plusieurs chemins de lecture ou plusieurs conventions d’identité. Elles ne prouvent pas, seules, que Graph a causé le doublon : la règle de création du connecteur reste à examiner.

Garder une seule question pendant la première recette

La première question est : « Cette observation appartient-elle au dossier déjà connu ? » Elle précède la fusion de dossiers, la relance commerciale et la publication d’une notification. Le responsable ADV fournit le parcours attendu ; l’équipe d’intégration retrouve les références ; le mainteneur du CRM précise les opérations de rattachement admises. Le nom du fournisseur ne remplace aucune de ces décisions.

Si le besoin consiste seulement à consulter des mails dans Outlook, ce défaut de correspondance externe peut ne pas exister. Si deux mails différents demandent des devis pour le même client, ils peuvent légitimement partager un dossier ou en créer deux selon votre règle métier. L’identité technique permet de reconnaître un message ; elle ne décide pas combien d’opportunités commerciales l’entreprise doit ouvrir.

Anatomie : la clé du message et la clé du dossier n’ont pas le même rôle

Lire le contrat Microsoft avant de modifier la base

La documentation des identifiants Outlook immuables, consultée le 14 octobre 2026, précise le mécanisme : la préférence Prefer: IdType="ImmutableId" s’applique à chaque requête qui la porte. L’identifiant reste stable lors d’un changement de dossier dans la même boîte. Il peut changer lors d’un passage vers une boîte d’archive ou après export et réimportation. Les comparaisons sont sensibles à la casse.

La description de l’opération message: move fournit un autre repère : elle déplace le message dans la boîte de l’utilisateur, crée une copie à destination et retire l’original. Sa réponse réussie est un message avec un statut 201. Le consommateur doit interpréter cette opération comme un changement d’emplacement dans son parcours, plutôt que traduire mécaniquement « Created » en nouvelle demande commerciale.

Conserver le dossier métier pendant une évolution technique

Dans votre application, D001 peut rester la demande de devis même si le chemin de lecture du mail change. Une table de correspondances relie le contexte autorisé, l’identité source qualifiée et D001. Une autre relation conserve les anciennes références traduites. Ces deux fonctions peuvent partager un stockage, mais elles ne doivent pas être remplacées par une recherche du sujet du mail.

Le sujet, la date et l’expéditeur peuvent aider un agent à enquêter. Ils ne fournissent pas une preuve suffisante pour fusionner deux dossiers : un client peut reprendre le même titre, transférer une ancienne demande ou envoyer deux commandes semblables. Le contre-test utile présente deux demandes presque identiques et vérifie que le rapprochement automatique ne les absorbe pas pour faire disparaître une alerte.

Retrouver les formats réellement consommés par le middleware

Inventorier les producteurs de références

Recherchez le code qui lit le mail initial, celui qui traite le webhook, les collectes planifiées et les reprises du support. Notez le format demandé et celui qui est effectivement enregistré. Une configuration dans un client HTTP commun ne démontre pas que tous les workers, tâches de rattrapage et anciens adaptateurs utilisent ce client. Le flux critique peut encore passer par un composant oublié.

Le registre distingue le tenant, la boîte visée, l’environnement, la version du mapping et le consommateur. Il conserve aussi la provenance de la référence : réponse d’une lecture, notification ou correspondance historique. Cette provenance permet de qualifier une différence sans utiliser la longueur du texte ou son préfixe comme détecteur de format. L’identifiant reste une valeur opaque.

Mesurer la dette de correspondance plutôt que le seul trafic

Comptez les dossiers rattachés avec un format connu, ceux qui possèdent une traduction confirmée et ceux dont le format est inconnu. Ajoutez les observations en attente et leur ancienneté. Le débit d’appels peut augmenter pendant que la dette grandit ; le monitoring doit donc montrer les cas qui empêchent le support de retrouver le mail associé au dossier.

La cartographie du portefeuille d’intégrations donne le cadre pour identifier ces chemins et leurs mainteneurs. Ici, le livrable reste plus précis : une ligne de correspondance et son interprétation dans chaque consommateur. L’inventaire global ne remplace pas le contrôle de cette clé.

Exercice corrigé : treize observations, trois correspondances conservées

Préparer des références fictives et une traduction explicite

Le banc écrit les entrées dans un fichier JSON, les relit et interroge une base SQLite locale. Trois relations existent au départ : T-A/ADV/IMM-Ab vers D001, T-A/ADV/IMM-Bc vers D002 et T-A/SAV/IMM-Ab vers D003. La répétition du même texte dans deux boîtes est volontairement fictive : elle sert à éprouver notre clé composée, sans affirmer que Microsoft distribuerait ainsi ses identifiants réels.

Deux anciennes références, OLD-1 et MOVED-1, possèdent chacune une traduction fournie vers IMM-Ab dans la boîte ADV. Le programme ne calcule pas cette traduction et ne la demande pas à Graph. Une troisième référence, CONFLICT, contient volontairement deux destinations incompatibles. Le résolveur doit exposer cette ambiguïté au lieu de choisir la première ligne.

Interpréter les 59 assertions dans leur périmètre

Six observations retrouvent une relation, cinq attendent une qualification et deux sont refusées. Les trois lignes initiales restent identiques après chaque recherche ; aucun nouveau dossier n’est créé. Les contrôles comparent la décision attendue, le dossier, le contenu de la table avant et après, puis les totaux et les relations entre cas. Python et SQLite exécutent ces recherches, sans message réel ni écriture dans un CRM.

Le cas concret A/B montre qu’une ancienne référence et une référence après classement peuvent retrouver D001 si leur traduction a été fournie et qualifiée. D représente l’absence de cette preuve. C et L vérifient la répétition d’une lecture ; ils ne démontrent pas l’idempotence d’une création distante. Cette dernière exige sa propre recette lorsque le connecteur appelle réellement l’application métier.

Paradoxalement, simplifier la comparaison peut casser le rattachement : E et F contredisent les raccourcis consistant à mettre tous les identifiants en minuscules, ou oublier la boîte dans la recherche. Dans notre banc, ces transformations retrouveraient un mauvais dossier ou feraient passer une identité inconnue pour une relation connue. Le résultat utile est une décision expliquée, même quand elle laisse temporairement un mail à qualifier.

Reprendre les anciennes correspondances sans ouvrir un second dossier

Séparer traduction technique et décision de fusion

Microsoft documente translateExchangeIds pour passer notamment de restId à restImmutableEntryId, avec un maximum de 1 000 références par demande. La migration doit conserver chaque paire source/destination et son contexte ; elle ne doit pas considérer l’ensemble du stock comme traduit simplement parce qu’une requête a répondu.

Dans le registre applicatif, la traduction rejoint le dossier déjà détenu par la référence source. Une destination liée à un autre dossier ouvre un conflit comme J. Le responsable métier décide ensuite si les deux dossiers représentent la même demande ; le développeur conserve le conflit et les preuves au lieu d’effacer une ligne pour satisfaire une contrainte d’unicité.

Faire un double contrôle sur les dossiers déjà ouverts

Pour une cohorte pilote, le support part de D001, retrouve la référence historique puis le message accessible au contexte autorisé. Le test repart aussi du message et cherche D001. Cette vérification dans les deux sens protège contre une table techniquement remplie mais reliée au mauvais compte, au mauvais dossier ou à une copie qui ne porte pas le parcours attendu.

Une référence introuvable garde son statut et son responsable. Un mail supprimé, un accès perdu et une traduction absente demandent des enquêtes différentes. La règle d’erreur ne doit jamais transformer automatiquement « je ne peux pas lire » en « le client a envoyé une nouvelle demande ». Le payload brut utile au diagnostic reste protégé selon les accès de l’équipe.

Aligner les nouvelles observations avec le stock conservé

Qualifier notifications et collecte séparément

La documentation Microsoft précise que les abonnements existants conservent leur format : la préférence doit être portée lors de leur recréation. Pour les requêtes delta compatibles, les liens de continuation restent utilisables avec les deux formats. Les nouvelles lectures et la migration du stockage peuvent donc être traitées séparément.

Le plan applicatif garde une fenêtre d’observation pendant cette transition. Une notification, une page collectée et une reprise manuelle passent par la même interprétation du format déclaré. La pagination conserve son curseur et le contexte de connexion ; le journal relie chaque observation au consommateur concerné. La latence du flux ne doit pas masquer une référence que ce consommateur ne sait pas résoudre.

Arrêter la création avant de perdre la correspondance

Lorsqu’une identité reste ambiguë, le connecteur peut conserver l’observation dans une file de qualification et présenter l’action attendue au support. Le dossier existant continue son parcours si ses autres informations restent disponibles. Ce choix évite que le mécanisme de reprise fabrique davantage de travail que l’incident initial.

Le contrat de reprise reçoit en entrée la référence, son format et son contexte ; sa sortie indique le dossier retrouvé ou le motif d’attente. Le retry relance une opération pour une cause identifiée, après lecture de son état. Il ne change pas l’identité de la demande à chaque tentative. Un rollback de configuration arrête les nouvelles interprétations, conserve les traductions confirmées et réconcilie les dossiers déjà touchés. Revenir à un ancien worker ne supprime pas les doublons qu’il aurait créés entre-temps.

Distinguer le dossier Archive d’une frontière de boîte

Nommer le geste réellement effectué par l’utilisateur

La documentation Outlook sur l’archivage distingue le dossier Archive courant et Online Archive. Le bouton Archive peut déplacer le mail dans un dossier de la boîte actuelle ; il ne signifie pas automatiquement un transfert vers une boîte d’archive. Le ticket doit décrire la destination observée, pas seulement reprendre « j’ai archivé ».

La recette commence donc avec un classement ordinaire, puis examine séparément les chemins d’archivage qui existent chez le client. Elle conserve leur périmètre et les accès associés. Déduire le type de destination depuis un libellé de dossier affiché en français ferait dépendre le mapping d’un libellé utilisateur plutôt que du contexte réellement fourni par l’intégration.

Ne pas vendre une continuité qui n’a pas été testée

H et I reçoivent une frontière déclarée par le banc et restent à qualifier. Le programme ne réalise aucun archivage ou réimportation et ne découvre pas ces événements automatiquement. Ces lignes obligent notre résolveur à s’arrêter quand le contrat du scénario lui signale une limite ; elles ne prouvent pas que votre application sait observer cette limite en production.

Le support doit aussi savoir ce qui reste accessible après un changement de conservation. Retrouver D001 ne garantit pas la présence du contenu complet ni des pièces jointes. L’écran métier conserve la référence au dossier et expose l’état de lecture réellement obtenu. Une identité durable n’élargit pas les permissions et n’annule pas une suppression décidée dans la boîte.

Erreurs fréquentes : réparer le compteur en abîmant les demandes

Fusionner au sujet du mail ou normaliser les références

Un filtre « même sujet, même client » peut rendre le compteur rassurant tout en absorbant deux demandes distinctes. Le test doit conserver les dossiers témoins et comparer les liens obtenus, pas seulement le nombre d’objets. Une fusion admissible possède un motif, un décideur et une trace permettant au commercial de retrouver les deux entrées initiales.

Ne tronquez pas non plus les identifiants pour simplifier un index. Le stockage vérifie taille admissible, casse et comparaison exacte sur les formats réellement reçus. Les logs du support peuvent employer une représentation masquée ou une référence interne, à condition que la personne autorisée puisse remonter au cas complet par un chemin contrôlé.

Corriger une seule branche du connecteur

La panne peut disparaître pendant une lecture manuelle et revenir au prochain rattrapage. Une recette utile joue tous les producteurs inventoriés, avec leur configuration et leurs droits. Le responsable du flux maintient la matrice des chemins testés et la journalisation des observations ; un ancien abonnement ou une tâche indépendante ne devient pas conforme parce que le composant principal a été corrigé.

L’autre erreur est de transformer une attente en création immédiate. Le produit doit présenter un état exploitable et une action attribuée lorsque l’identité manque. La sécurité du flux inclut cette frontière métier : une identité de boîte inconnue n’autorise pas une recherche globale dans tous les tenants afin de trouver une correspondance plausible.

Plan d’action : reprendre un parcours ADV avant d’étendre le raccordement

Livrer une correction que le support peut contrôler

Choisissez une boîte autorisée et une demande déjà rattachée au CRM. Rejouez son classement dans l’environnement de recette prévu, puis comparez le message, les observations et le dossier. Le responsable ADV valide qu’aucune nouvelle tâche commerciale ne part du simple classement. Le mainteneur du connecteur conserve les preuves techniques et attribue les cas qui restent sans traduction.

Le contrat de test fixe l’entrée et la sortie attendue : pour le témoin C, le contexte T-A/ADV et IMM-Ab retrouvent D001 ; L retrouve encore D001 ; E ne reçoit aucun dossier par rapprochement approximatif. Le seuil du banc est zéro correspondance modifiée et zéro dossier créé. Si le cas K arrive sans boîte, alors le résolveur refuse le périmètre et le support demande le contexte manquant. Ce second seuil bloque toute recherche globale destinée à compenser cette absence. Pour l’installation cliente, ajoutez le résultat des écritures CRM, le détail visible et les consommateurs effectivement exercés.

1. D’abord : inventorier les formats reçus et geler la création sur identité inconnue.
2. Ensuite : qualifier les traductions du stock et les conflits de rattachement.
3. Avant ouverture : exercer collecte, notifications et reprise support sur la même cohorte.
4. À différer : les autres boîtes et les frontières d’archive qui n’ont pas leur recette.

Décider l’extension depuis les liens retrouvés

Le pilote suit les rattachements attendus, les dossiers effectivement créés, les conflits et l’âge des observations en attente. Une hausse des lectures réussies ne suffit pas. L’extension attend que le support retrouve les dossiers témoins sans correction directe en base, puis décrit les scénarios qui n’ont pas encore été couverts. Les seuils d’exploitation réels sont convenus avec l’équipe selon son parcours.

Un éditeur qui commercialise ce raccordement doit aussi préciser les prérequis et la maintenance. Le travail sur l’offre d’intégration d’un SaaS distingue une activation couverte d’une adaptation client. La correction d’identité devient une capacité testée du connecteur, avec une procédure de diagnostic que l’équipe produit peut financer et maintenir.

Guides liés : conventions d’identité, offre produit et contrat HTTP

Relier la correction au portefeuille et à l’offre vendue

La cartographie des intégrations réellement actives aide à retrouver les collectes et leurs consommateurs avant une modification partagée. L’offre de raccordement d’un éditeur SaaS prépare ensuite les conditions que le commerce peut annoncer. Le premier travail trouve les chemins ; le second décrit la capacité vérifiée et les adaptations encore nécessaires.

Une réparation locale de la correspondance peut être courte alors que la reprise de plusieurs clients reste exigeante. Chaque boîte, contexte et version d’adaptateur garde son état de qualification. Le produit peut afficher les opérations admises sans promettre que toutes les références anciennes de toutes les installations ont été traduites.

Contrôler aussi les données à l’entrée du connecteur

Le diagnostic du webhook Shopify réencodé avant contrôle de signature montre un autre défaut de frontière : la représentation traitée ne correspond plus à celle attendue par le contrat. Son mécanisme de signature ne s’applique pas automatiquement à Graph. L’enseignement commun est de conserver la provenance et l’interprétation exacte avant de prendre une décision métier.

Les refus de composition étudiés dans le schéma OpenAPI fermé avec allOf relèvent, eux, de la validation des données. Un payload conforme peut encore porter une identité sans correspondance. La recette doit donc distinguer acceptation du contrat, recherche du dossier et confirmation de l’effet final.

Conclusion : classer un mail doit conserver la demande déjà reconnue

Le second dossier n’est pas toujours un problème de répétition d’événement. Il peut venir d’un format d’identifiant que l’application a pris pour une clé durable, puis d’une correspondance historique qu’elle ne sait plus résoudre. L’enquête retrouve d’abord le mail, son contexte et le dossier attendu avant de fusionner quoi que ce soit.

Les treize observations locales distinguent six rattachements, cinq attentes et deux refus. Les trois correspondances restent intactes, avec 59 assertions et aucun dossier créé. Ce résultat apporte une contre-preuve sur notre résolveur fictif ; la recette cliente doit encore éprouver les réponses Graph, les droits et les écritures du système métier.

Le périmètre d’intégration Microsoft Graph relie cette correction aux collectes, aux notifications et aux reprises déjà utilisées. Le livrable attendu associe formats connus, stock repris, cas ambigus visibles et contrôle du support sur les demandes ouvertes.

Dawap peut accompagner la reprise de votre connecteur API et de ses correspondances métier avec vos équipes et le mainteneur du CRM. Le premier lot peut rester limité à une boîte et un parcours ADV, jusqu’à ce que le classement des mails conserve les dossiers que vos utilisateurs reconnaissent.