Un chargé de compte cherche dans son CRM la correction convenue plusieurs mois plus tôt avec le support. La conversation Intercom est bien rattachée au client, sa dernière réponse est présente et le connecteur annonce une synchronisation réussie. Pourtant, l’échange qui justifiait la décision ne figure plus dans la copie. Ce blocage ne vient pas nécessairement d’un webhook perdu : la lecture d’une conversation peut ne restituer qu’une partie de son historique.
Paradoxalement, le compteur peut rester stable pendant une perte locale. En pratique, le défaut apparaît quand le traitement considère la dernière réponse de l’API comme le remplacement complet de ce qu’il connaissait. Une ancienne référence disparaît de la base locale, une nouvelle entre, et le compteur reste à 500. Les contrôles de disponibilité et de volume passent alors que le dossier a perdu un repère utile. Relancer exactement la même collecte ne suffit pas à retrouver ce qui manque.
Nous allons examiner la limite des parties d’une conversation Intercom, distinguer risque de troncature et omission démontrée, puis exécuter un laboratoire Python et SQLite de 48 contrôles. Il utilise seulement des identifiants fictifs. Les opérations SQL sont réelles, en mémoire ; aucun compte Intercom, message client, CRM ou ERP n’est appelé. Le résultat permet de revoir une synchronisation, sans prétendre reconstituer les textes absents.
Le raccordement général des contacts et conversations reste traité dans notre analyse de la synchronisation Intercom vers le CRM. Ici, l’enjeu est la profondeur d’une seule conversation. Une intégration Intercom avec votre CRM doit distinguer « dernière lecture reçue » et « historique couvert », au sein de vos échanges API entre support et logiciels métier.
Partir de la décision manquante dans le dossier client
Choisir une conversation qui a réellement traversé plusieurs reprises
Le bon cas de recette n’est pas toujours le ticket ouvert hier. Prenez, avec les autorisations nécessaires, un dossier qui a vécu une réouverture, une escalade ou plusieurs interventions. Demandez au métier quel échange ultérieur au message initial doit rester retrouvable : une correction d’adresse, un accord de remplacement ou une réserve formulée pendant le traitement. Cette référence donne une question vérifiable au contrôle.
Évitez de confondre ancienneté et taille. Une conversation ancienne peut être courte ; une conversation très active peut atteindre une limite rapidement. Le nombre de conversations synchronisées ne renseigne pas sur les parties présentes dans chacune. Le diagnostic doit pouvoir descendre du client à la conversation concernée, puis à la référence recherchée, sans transformer chaque incident en export de tout le support.
Décider si le CRM a besoin du texte ou seulement d’un accès au contexte
Un commercial qui peut ouvrir Intercom avec ses propres droits n’a pas forcément besoin d’une seconde copie intégrale. Un processus de reprise ou de traitement hors du support peut, lui, exiger un périmètre de données décidé. Définissez l’usage avant de promettre une archive. Un inventaire d’identifiants, un lien consultable et une copie de contenu répondent à trois besoins différents.
Le coût caché apparaît quand le chargé de compte doit rouvrir le dossier avec le support pour retrouver une décision déjà prise. Suivez ces reprises et le délai de traitement qu’elles ajoutent. Cette distinction change aussi la responsabilité de maintenance. Si le CRM affiche une chronologie partielle, son libellé doit le dire. S’il sert à instruire une décision, les limites de couverture et le moyen de revoir la source doivent être explicites. Compter les réponses HTTP réussies ne permet pas au chargé de compte de savoir si l’échange qui l’intéresse a réellement été repris.
Ce que signifie la limite de 500 parties Intercom
Lire le contrat de récupération d’une conversation
La référence de récupération d’une conversation indique une limite de 500 parties et précise que les 500 plus récentes sont renvoyées lorsqu’il en existe davantage. L’opération concernée est GET /conversations/{conversation_id}. Une réponse réussie ne constitue donc pas, à elle seule, une garantie de reprise de toute la conversation.
Le message initial apparaît dans l’objet source, séparément de conversation_parts. Il serait inexact de traduire la limite par « 500 réponses client » ou d’annoncer que le message d’ouverture disparaît nécessairement. Notre scénario vise, par exemple, la référence d’un accord enregistré après l’ouverture de la conversation. Le contrôle distingue la source initiale de l’inventaire des parties, sans attribuer la même nature à tous les éléments.
Ne pas inventer une page suivante à l’intérieur de la conversation
Paginer une liste de conversations permet de parcourir plusieurs dossiers ; cela ne prouve pas qu’un curseur donne accès aux parties antérieures d’un dossier précis. Les paramètres utilisables doivent venir du contrat de l’opération et de la version retenue. Ajouter un numéro de page imaginé au même appel ne constitue pas une stratégie de récupération des échanges plus anciens.
La référence en version 2.10 consultable actuellement décrit également cette limite. Nous utilisons cette version comme profil explicite du laboratoire. Cette page vivante n’est pas une capture historique : elle ne permet pas de dater l’introduction du plafond. Pour comparer deux relevés, notez la version réellement demandée par le connecteur plutôt que celle affichée par défaut dans la documentation.
500 éléments : un signal à examiner, pas une omission déjà prouvée
Comparer deux histoires qui produisent la même fenêtre
Construisons deux histoires fictives pour ce premier scénario. La première contient exactement les références p002 à p501. La seconde contient aussi p001 avant elles. En ne regardant que les 500 dernières parties, le lecteur obtient la même observation dans les deux cas. Il ne peut pas déduire, depuis ce seul résultat, laquelle de ces histoires existe derrière la réponse.
Le laboratoire réalise cette comparaison sur deux séquences Python. Les noms numérotés servent à construire notre exemple ; ils ne définissent aucune règle de tri des identifiants natifs Intercom. Dans une collecte réelle, il faut conserver les repères de contexte et les champs temporels qualifiés. Trier des identifiants comme s’ils constituaient une horloge peut créer une chronologie que l’éditeur ne garantit pas.
Utiliser une connaissance antérieure sans la confondre avec tout l’historique
Si une observation précédente a enregistré p001, son absence de la fenêtre suivante devient un écart identifiable. Vous savez nommer une référence autrefois observée et non renvoyée cette fois-ci. Vous ne savez pas encore si le contenu demeure disponible par un autre parcours, a été modifié ou relève d’une autre condition d’accès. L’écart appelle une qualification, pas une suppression automatique dans la copie.
Le champ total_count du modèle Conversation Parts ne doit pas recevoir une signification historique supplémentaire sans contrat vérifié. Dans notre exercice, sa valeur est reçue mais n’autorise aucune certification d’exhaustivité. Une fenêtre de 499 parties ou une fenêtre vide ne reçoit pas non plus un certificat par défaut : droits, collecte et périmètre restent à examiner.
Erreurs fréquentes : remplacer l’historique par la dernière fenêtre
Observer la faute dans une base distincte
Dans le second scénario fictif, le laboratoire prépare deux bases identiques avec 500 références connues, de p001 à p500, ainsi qu’une source initiale séparée. Il reçoit ensuite p002 à p501. Dans la base du contre-exemple, une vraie instruction DELETE retire les anciennes parties absentes de cette fenêtre, puis les nouvelles références sont insérées. Le total des parties reste à 500, mais p001 a été effacée.
Cette perte locale ne démontre pas une suppression chez Intercom. C’est le traitement qui a transformé une absence dans sa dernière observation en ordre d’effacement. Un tableau de bord limité au nombre de lignes ou au dernier succès réseau peut manquer ce défaut. La mesure utile compare les références connues, reçues, nouvellement observées et absentes de la fenêtre, dans un périmètre stable.
Séparer réception incrémentale et décision d’effacement
Dans l’autre base, la réception ajoute les références observées sans déduire de suppression. Le résultat contient 501 parties connues : p001 reste présente et p501 est ajoutée. Ce résultat conserve une connaissance antérieure ; il ne reconstitue ni les mots échangés ni les pièces d’un échange manquant et ne prouve pas que les 501 références représentent tout ce qui a existé.
Ce choix pédagogique ne définit pas une politique de conservation illimitée. Les corrections, restrictions d’accès et demandes d’effacement demandent un traitement distinct, autorisé et vérifiable. La règle étroite est de ne pas utiliser la seule absence dans une fenêtre plafonnée comme preuve de suppression native. La recette du système réel doit aussi démontrer comment une suppression confirmée est appliquée à ses copies concernées.
Fixer le workspace et le profil de lecture avant de rapprocher les références
Éviter la collision entre deux espaces Intercom
Le journal des changements non versionnés signale depuis avril 2023 que les identifiants de parties ne sont pas uniques entre tous les workspaces. Un index global construit sur le seul identifiant de partie peut donc rapprocher à tort deux espaces. Le workspace doit accompagner la référence dans le contrat de stockage et de rapprochement.
Notre clé SQL comprend workspace, conversation, version, profil de visibilité, nature de référence et identifiant. La version et le profil sont des frontières d’observation locales ; ils ne prétendent pas créer des identités natives différentes. Une même référence fictive dans WORKSPACE-A et WORKSPACE-B produit deux lignes distinctes. La source et les parties restent également séparées dans la clé.
Retenir une observation qui ne correspond pas au périmètre demandé
Le programme refuse un workspace, une conversation, une version ou un profil différents de ceux demandés. Il exige aussi deux qualifications explicites : accès et transport. Ces indicateurs sont fournis par la simulation, pas obtenus par authentification. Les mettre à vrai ne vérifie aucun droit Intercom. L’adaptateur REST réel doit établir leur signification avant de remettre les données au rapprochement.
Un changement de credentials ou de version ne doit pas devenir silencieusement une baisse du nombre d’échanges. Comparez d’abord les conditions de lecture. Le contrat de journalisation doit garder l’étape, le périmètre et la raison d’une observation retenue ; le monitoring doit distinguer ces attentes des écarts de références. Ni les secrets ni le corps des conversations n’ont besoin d’apparaître dans ces journaux de contrôle.
Exercice corrigé : exécuter 48 contrôles avec Python et SQLite
Lancer un fichier autonome, sans accès au support
Téléchargez le laboratoire des fenêtres de conversation Intercom et lancez-le avec Python dans un répertoire de travail. La version effectivement vérifiée est Python 3.14.8 avec SQLite 3.51.2. Le fichier utilise la bibliothèque standard, dont le module sqlite3 documenté par Python. Il ne demande ni jeton, ni URL de serveur, ni export client.
python3 conversation_tail_inventory.py
# Résultat de l’exécution vérifiée :
# checks_passed : 48
# good_known_parts : 501
# bad_known_parts : 500
# known_older_reference_lost_by_bad_sql : true
# initial_source_counted_separately : 1
# native_history_completeness_certified : falseQuatre bases sont créées avec :memory: et le stockage temporaire est demandé en mémoire. Le script exécute réellement les créations de tables, insertions, transactions, lectures et le contre-exemple de suppression. Aucun fichier SQLite persistant n’est créé. Ces écritures locales en mémoire ne sont pas des écritures dans Intercom ou dans un logiciel métier ; aucun corps de message n’entre dans l’expérience.
Lire les différences plutôt que célébrer le nombre de tests
Commencez par first_merge : une nouvelle référence est nommée, une ancienne référence absente de la fenêtre est signalée, et history_complete reste faux. Comparez ensuite les bases correcte et destructive. Le test intéressant est la disparition effective de p001 dans la seconde, malgré un volume plausible. Les assertions rendent cette différence reproductible ; leur nombre ne mesure ni la couverture de votre compte ni la fiabilité d’un futur connecteur.
La trace SQL contient 5 588 instructions lors de l’exécution vérifiée, dont une suppression dans le seul contre-exemple. Ce chiffre inclut les tentatives d’insertion qui rencontrent une clé existante ; il ne représente pas 5 588 lignes modifiées ni un test de performance. Le programme distingue précisément les effets de base et les conclusions qu’il n’a pas les moyens d’établir à distance.
| Situation exécutée | Résultat à contrôler |
|---|---|
| Fenêtre décalée de 500 parties | 501 références connues, ancienne préservée |
| Remplacement destructif | 500 références, ancienne effacée localement |
| Rejeu identique | Aucune ligne ajoutée, aucune nouvelle référence |
| Fenêtre vide ou sous le plafond | Pas de suppression ni preuve d’exhaustivité |
| Périmètre ou observation non qualifiés | Traitement retenu avant toute écriture |
Les autres cas vérifient notamment les identifiants dupliqués, vides ou booléens, une collection dépassant le profil de 500, un changement d’ordre et l’absence de source initiale dans l’observation fournie. Ils exercent un format Python normalisé. Le fichier n’est pas un parseur des réponses natives, ne collecte pas de webhook et ne prétend pas valider toutes les formes possibles d’un payload Intercom.
Rendre le rejeu stable sans transformer l’inventaire en archive
Vérifier l’idempotence sur les lignes réellement ajoutées
La réception utilise des paramètres SQL et une clé unique composite. L’insertion ON CONFLICT DO NOTHING, décrite dans la documentation UPSERT de SQLite, laisse les références déjà présentes en place. Au rejeu identique, le compteur de modifications de la base n’augmente pas. L’idempotence vérifiée porte sur cet inventaire précis, pas sur l’envoi d’un commentaire ou la création d’un dossier CRM.
À l’entrée du traitement, le contrat de mapping doit nommer le compte métier associé à la conversation ; cette responsabilité reste extérieure au laboratoire. Une clé locale correcte ne corrige pas un client mal associé. Dans un middleware réel, l’acquittement de réception, la décision de projection et les reprises doivent conserver leurs propres repères. Un retry ne doit ni remplacer l’historique connu par une fenêtre partielle, ni redéclencher une action commerciale simplement parce qu’une référence a été relue.
Qualifier les textes manquants séparément des références conservées
Une ligne contenant p001 permet de signaler une absence ; elle ne contient pas la correction recherchée par le chargé de compte. Pour restituer les mots échangés, il faut un parcours autorisé et vérifié, ou une copie déjà conservée selon le périmètre convenu. L’inventaire aide à localiser l’écart et à éviter une perte supplémentaire. Il ne transforme pas un identifiant en contenu récupérable.
Le dossier d’écart doit relier la référence recherchée, sa dernière observation connue et le contenu nécessaire à la décision. Attribuez sa résolution à une personne capable de comparer la source autorisée et la copie CRM. Si le contenu reste indisponible, faites qualifier la décision métier à prendre ; la conservation d’un identifiant ne doit pas fermer automatiquement cette attente.
Approfondir la collecte et la réception des données de support
Le même principe apparaît dans les reprises de messages Microsoft Graph vers un CRM : un signal reçu ne garantit pas tout le contenu attendu en aval. Pour cadrer votre middleware Intercom et CRM, la question concrète est de savoir quelle preuve rend chaque étape terminée, puis qui traite les dossiers dont la couverture demeure inconnue.
Le passage du résultat d’export à une pièce exploitable demande encore une réception et un rapprochement. Notre diagnostic des pièces Zendesk accessibles à l’agent mais refusées au connecteur approfondit cette autre frontière. Dans les deux cas, l’existence d’une référence ou d’un lien ne remplace pas la preuve que la donnée attendue est disponible pour le processus destinataire.
Vérifier le contenu d’un export avant d’en faire une solution de reprise
Le nom « Data Export » peut suggérer un export intégral des conversations. La référence Intercom de cette API d’export décrit des données de diffusion et d’engagement des contenus sortants. Elle précise que les corps bruts des messages ou des conversations ne sont pas exportés par cette opération. L’appeler ne constitue donc pas une solution de récupération du contenu des parties anciennes.
Les possibilités d’export présentées dans l’aide Intercom doivent être qualifiées par parcours et par périmètre. L’export individuel texte ou PDF indiqué dans l’Inbox exclut les notes internes. Un CSV de reporting et un transcript ne sont pas interchangeables. Aucun de ces intitulés ne suffit à promettre une reprise exhaustive de toutes les parties et de toutes les données utiles à votre dossier.
Sur un pilote, choisissez la référence ancienne attendue, contrôlez sa présence dans l’alternative autorisée et notez les catégories exclues. Vérifiez également les droits, les conditions disponibles sur le compte et le rattachement au dossier métier. Si l’alternative ne restitue pas le contenu demandé, gardez cet écart visible. Annoncer une migration complète parce qu’un fichier a été produit déplace le problème jusqu’à la première recherche métier qui échoue.
Plan de recette : révéler les pertes silencieuses avant la bascule
Réunissez une petite cohorte autorisée : conversation courte, conversation au plafond, cas avec référence ancienne connue et deux workspaces si votre service en utilise plusieurs. N’inventez pas un grand historique dans le compte client pour atteindre la limite. Les données réelles nécessaires à la recette doivent être choisies avec le responsable du support, et les cas artificiels rester identifiés comme tels.
- Fixer workspace, conversation, version et identité de lecture.
- Nommer la référence métier ancienne recherchée et son usage attendu.
- Distinguer source initiale, parties reçues et références déjà connues.
- Comparer la réception incrémentale au comportement actuel de remplacement.
- Rejouer la même observation et vérifier les effets locaux et aval.
- Attribuer les écarts non résolus avant d’annoncer la couverture du dossier.
Les seuils d’alerte doivent répondre à des situations différentes : fenêtre au plafond à examiner, référence connue absente, observation retenue ou contenu attendu non récupéré. Mesurez le nombre de dossiers concernés et leur ancienneté plutôt qu’un seul volume de messages. Un système peut recevoir toutes ses notifications récentes et conserver une lacune historique que les nouveaux événements ne combleront jamais.
La décision de bascule doit inclure un cas où l’historique reste non démontré. L’écran métier, le journal d’exploitation et la procédure de reprise doivent alors exprimer la même limite. Le pilote est acceptable quand les équipes savent ce qui a été observé et ce qui nécessite une action, avec des effets aval contrôlés ; il ne l’est pas parce que toutes les réponses de collecte portent un statut réussi.
Conclusion : décider ce que couvre réellement la copie CRM
La première correction est souvent de retirer l’équivalence entre dernière fenêtre et historique complet. Ensuite viennent l’inventaire contextualisé, la conservation des écarts et la qualification d’un parcours de contenu adapté au besoin. Ces étapes permettent de discuter d’un dossier précis avec le support et le métier, au lieu d’opposer un tableau de bord vert à une recherche qui ne retrouve pas la décision attendue.
Le périmètre de votre connexion Intercom au CRM doit préciser les conversations reprises, les écarts connus et les usages permis de la copie. Une référence conservée donne un point de contrôle ; un contenu absent demande encore une solution qualifiée. Le support et les utilisateurs du CRM doivent partager ces critères avant de clore la reprise.
Dawap peut cadrer ce travail dans votre projet d’intégration API entre logiciels métier : examiner le connecteur, définir la responsabilité du rapprochement et construire une recette sur vos dossiers autorisés. La livraison doit rendre vérifiables les effets d’un rejeu et les limites de récupération, pour que vos équipes sachent expliquer un manque avant qu’une décision client ne dépende de la copie.
