Mise à jour Entergram, semaine du 25 juin 2026 : stabilité, outils proxy et plus de 25 correctifs

Cette semaine a été une semaine d'ingénierie en profondeur chez Entergram. Nous avons livré deux nouvelles fonctionnalités d'infrastructure, nettement amélioré la stabilité pour les espaces de travail à fort volume, et fermé plus de 25 bugs touchant la messagerie, la gestion des connexions, l'onboarding, la facturation et la table CRM. Voici tout ce qui a atterri en production.

Les administrateurs peuvent désormais attribuer le trafic proxy à des routes et à des comptes connectés précis, ce qui donne une visibilité sur les connexions qui consomment le plus de bande passante. En parallèle, vous pouvez assigner des proxys statiques dédiés à des routes individuelles. C'est utile lorsque vous avez besoin d'une IP stable et prévisible pour certains comptes Telegram plutôt que de laisser le pool tourner.

DEV-149 sur Linear

Un worker en arrière-plan sonde maintenant périodiquement chaque proxy et met à jour son état de santé. Le panneau d'administration reflète donc l'état réel de la connectivité : vous repérez un proxy dégradé avant qu'il n'affecte silencieusement vos utilisateurs, au lieu de découvrir le problème par un ticket de support.

DEV-151 sur Linear

Les grands espaces de travail, ceux qui comptent des centaines de chats répartis sur de nombreux comptes connectés, subissaient un blocage important du thread principal et une latence visible dans le navigateur. Cette semaine, nous avons revu le moteur de connexion ws-v2 pour lisser les rafales de account.bind et cadencer les appels folder.chats.fetch. Résultat : une session de QA qui produisait auparavant 692 tâches longues et environ 166 secondes de blocage du thread principal se charge désormais proprement.

DEV-191 sur Linear

Dans les espaces de travail chargés, des comptes affichaient des badges « Reconnexion requise / Déconnecté » alors que la session MTProto côté backend était bien vivante et servait le trafic. Les opérateurs qui cliquaient sur Reconnecter déclenchaient des reconnexions inutiles et, dans certains cas, atteignaient des limites FLOOD_WAIT de Telegram sur le numéro de téléphone. Le badge n'apparaît plus qu'en cas de vrai problème de connexion.

DEV-177 sur Linear

Les messages audio se lisent à nouveau. Les messages vocaux entrants échouaient silencieusement, le bouton de lecture ne faisait rien. Corrigé sur tous les types de chat. (DEV-133)

Les erreurs « Socket closed » sont résolues. Plusieurs espaces de travail subissaient des déconnexions brutales avec une erreur de contexte chat.subscribe. La logique de reconnexion du socket sous-jacent est désormais stable. (DEV-120)

L'historique des supergroupes et des canaux se charge correctement. La navigation dans les supergroupes déclenchait des erreurs « Invalid realtime command payload » sur le chemin history.around quand le frontend envoyait des indices de peer (entity_class_name) que la passerelle ne reconnaissait pas. Corrigé au niveau de la passerelle. (DEV-168, PRODUCT-121)

La page ne se fige plus pendant une conversation ou un transfert. Toute une classe de blocages qui forçaient l'opérateur à rafraîchir en pleine conversation est résolue. (DEV-143)

Le statut en ligne est cohérent. L'indicateur de présence dans la table des chats et celui de l'en-tête de conversation lisaient deux sources différentes. Ils partagent maintenant un seul état de présence résolu. (DEV-186)

Noms d'expéditeur corrects en groupe. Les bulles de message dans les fils de groupe affichaient parfois le mauvais pseudo Telegram au-dessus du contenu. Corrigé à la fois sur les chemins chat_list.window.snapshot et live_chat_list.delta. (DEV-192)

Les compteurs de non-lus restent justes. Plusieurs scénarios faisaient surcompter le badge de non-lus : par exemple, envoyer 2 messages et en voir 5 marqués non lus. Le compteur se réconcilie maintenant correctement à travers les reconnexions. (DEV-135)

Bulles de message dupliquées corrigées. Quand deux comptes connectés ou plus partageaient le même chat, un même message pouvait apparaître deux fois dans le fil ouvert. Il s'agissait d'un bug de déduplication au rendu côté frontend, pas d'un problème de fusion entre comptes. Corrigé. (DEV-183)

Expéditeur de repli et auteurs de réactions résolus. L'historique affichait parfois other comme libellé d'expéditeur pour les messages entrants, et les popovers de réactions restaient bloqués sur « Loading reactions ». Les deux points sont corrigés. (DEV-156)

Les chats restent dans la vue dossier après votre réponse. Les dossiers portant l'option « Exclure les chats lus » éjectaient un chat dès qu'un opérateur envoyait une réponse, faisant disparaître la conversation en pleine session. Les dossiers conservent maintenant les chats auxquels vous avez répondu jusqu'à ce que vous quittiez la vue. (DEV-178)

Le MCP écrit à de nouveaux contacts. L'intégration MCP renvoyait une erreur lorsqu'elle tentait d'envoyer un message à un contact Telegram avec qui vous n'aviez jamais échangé. Les premiers envois fonctionnent désormais correctement. (DEV-141)

Les sessions mortes se rétablissent automatiquement. Un bug dans la logique de capacité de route de l'agent de session (observeRoutes) empêchait certaines sessions de redémarrer après leur arrêt. Les comptes concernés renvoyaient nats: no responders à chaque requête d'historique ou de dossier, et redémarrer l'agent n'aidait pas. Le problème de famine est résolu, les sessions mortes se relancent d'elles-mêmes. (DEV-139)

La fenêtre de connexion ws-v2 n'inonde plus d'erreurs 400. Un problème de timing poussait la boucle de polling de connexion de compte à interroger un identifiant de session d'authentification inexistant, produisant des centaines de notifications API request failed: 400 en une seule session. Corrigé au niveau du cycle de vie du polling. (DEV-181)

Le statut de connexion proxy s'affiche correctement dans les Réglages. L'indicateur de proxy restait bloqué sur « chargement » à chaque visite de la page Réglages, même pour des connexions saines. Il reflète maintenant l'état réel. (DEV-154)

Les utilisateurs rejoignent les espaces de travail de façon fiable. Un crash React de profondeur de mise à jour maximale (#185) se déclenchait dès qu'un nouvel utilisateur arrivait sur la table de chats CRM après avoir rejoint l'espace. La cause racine était une référence de tableau constamment réinstanciée dans la définition CHAT_PAGE_SIZE_OPTIONS ; elle est désormais sortie du cycle de rendu. (DEV-165, DEV-167)

Acceptation des invitations corrigée pendant l'onboarding. Les utilisateurs qui collaient un lien d'invitation pendant l'onboarding pouvaient terminer le parcours sans rejoindre réellement l'espace de travail cible. Ils atterrissaient dans un espace personnel vide, puis provoquaient un crash en naviguant vers Réglages puis Table de chats. La logique d'acceptation et de redirection est maintenant correcte. (DEV-170)

Les utilisateurs retirés ne réapparaissent plus. Les membres retirés ou partis étaient réintégrés à chaque rafraîchissement via une session de lien d'invitation obsolète. Le point d'entrée /api/onboarding vérifie désormais le statut d'adhésion avant de réinscrire quelqu'un. (DEV-175)

Les demandes de changement d'e-mail peuvent être annulées. Le bouton d'annulation d'un changement d'e-mail en attente n'était relié à aucune action, cliquer dessus ne faisait rien. Il annule maintenant correctement la demande. (DEV-137)

La sélection de chats est visible en thème clair. Sélectionner des lignes de chat dans le thème blanc produisait des surbrillances invisibles ou quasi invisibles à cause d'un jeton de contraste manquant. Corrigé. (DEV-157)

Les propriétaires en période d'essai achètent des sièges sans impasse. Appeler purchaseSeat() avant que le propriétaire ait un abonnement payant actif renvoie 400 OWNER_SUBSCRIPTION_REQUIRED. Les propriétaires en essai voient désormais une invitation claire à souscrire d'abord, avec un chemin direct vers la page d'abonnement. (DEV-174)

Les achats d'abonnement fonctionnent de façon fiable. Une classe de conflits d'authentification 401/403 au paiement, déclenchés par l'invalidation de session pendant la redirection Stripe, est résolue. (DEV-172)

Les médias et vidéos se lisent sans erreur de limitation. Le point d'entrée /api/realtime/media était soumis à un limiteur générique de 20 requêtes par minute. Le streaming vidéo du navigateur émet plusieurs requêtes de plage d'octets pour le même fichier, ce qui déclenchait le limiteur en moins d'une seconde. Les requêtes média contournent désormais ce limiteur générique. (DEV-152)

La recherche est complète et cohérente. Certaines recherches renvoyaient des résultats partiels ou l'erreur « Telegram Search is unavailable » à la première requête. Les recherches suivantes sur le même terme fonctionnaient. Corrigé : les résultats reviennent correctement dès la première requête. (DEV-136)

« Temps depuis le premier message entrant » compte à partir de Telegram, pas de l'ouverture de l'application. Cette colonne spéciale démarrait son horloge au moment où vous ouvriez Entergram plutôt qu'à la réception du message par Telegram. La source de l'horodatage est maintenant correcte. (DEV-162)

Une liste de correctifs reste abstraite tant qu'on ne la traduit pas en gestes quotidiens. Voici comment tirer parti de cette semaine si vous administrez un espace de travail Entergram.

Vérifiez vos proxys avant votre prochaine campagne. Avec la consommation par route et le moniteur de santé, ouvrez le panneau d'administration et repérez les routes marquées comme dégradées avant de lancer une diffusion. Un compte qui passe par un proxy instable est un compte dont les envois ralentissent. Si certains comptes portent vos conversations les plus sensibles, assignez-leur un proxy statique dédié plutôt que de les laisser dans le pool rotatif.

Ré-entraînez le réflexe « Reconnecter ». Pendant des semaines, les opérateurs ont appris à cliquer sur Reconnecter dès qu'un badge apparaissait. Ce réflexe est maintenant contre-productif, parce que le badge ne s'affiche plus que lors d'un vrai problème et qu'une reconnexion superflue peut déclencher une limite FLOOD_WAIT côté Telegram. Dites à votre équipe de signaler le badge plutôt que de le cliquer en boucle.

Revoyez vos dossiers qui excluent les chats lus. Si vous aviez contourné le bug d'éjection en désactivant l'option « Exclure les chats lus », vous pouvez la réactiver. C'est souvent le meilleur réglage pour une file de support, car un dossier ne contient alors que ce qui attend encore une réponse.

Relancez les automatisations MCP qui ciblaient de nouveaux contacts. Les scénarios qui écrivaient à un contact jamais contacté auparavant échouaient. Si vous aviez mis en pause un flux de prospection pour cette raison, il peut reprendre. Pour rappel, le MCP Entergram couvre tous les comptes Telegram rattachés à votre siège.

Contrôlez vos colonnes de temps. La correction de « Temps depuis le premier message entrant » modifie les valeurs affichées : elles reflètent désormais l'horodatage réel de Telegram. Si vous utilisiez cette colonne comme indicateur de réactivité dans la table CRM, attendez-vous à des chiffres différents, et plus justes, que la semaine précédente.

Le changelog complet de la v0.16.0 et de toutes les versions précédentes est disponible sur la page des nouveautés Entergram.