Dans les coulisses de l’intégration iMessage hébergée de Notis avec LoopMessage

Une bulle de chat, c’est la partie facile. Le plus dur, c’est d’acheminer une demande jusqu’à un assistant, de faire le travail, puis de renvoyer un résultat qui appartient toujours à la même conversation. Ajoute une pièce jointe ou une réaction, et cette interface en apparence simple se met à poser de vraies questions d’architecture.

Chez Notis, nous avons implémenté un canal iMessage hébergé avec LoopMessage. Il gère les webhooks entrants et l’envoi des messages sortants, y compris les médias et les signaux conversationnels. Cet article explique cette implémentation et les choix de conception qui l’entourent.

Ce n’est pas une annonce selon laquelle l’iMessage hébergé est disponible pour tous les comptes Notis. La disponibilité et le déploiement doivent être confirmés séparément. L’intégration locale avec l’app Messages sur Mac est aussi une connexion différente, ce qui compte davantage que ne le laisse penser la ressemblance des noms.

Partir de la conversation, pas du transport

Je suis Flo, le fondateur de Notis. Notre assistant accepte le travail délégué par messages, par la voix et via une interface desktop ou web. Du point de vue de l’utilisateur, l’objet utile, c’est la tâche qu’il essaie d’accomplir. Le canal, c’est le moyen d’y accéder.

Ça paraît évident, jusqu’au jour où une intégration de messagerie traite chaque événement entrant comme une nouvelle instruction. Une réaction n’est pas forcément une demande. Une pièce jointe va avec le message qui l’accompagne. Une mise à jour de statut sortante ne prouve pas qu’une tâche est terminée.

Ces nuances expliquent pourquoi une intégration de messagerie hébergée demande plus qu’un endpoint qui accepte du texte. Il faut une traduction réfléchie entre les événements du fournisseur et la façon dont l’application comprend une conversation.

La place de LoopMessage

Le chemin entrant implémenté reçoit les webhooks LoopMessage pour les événements liés à iMessage. Il gère les messages, les réactions et les médias. Le chemin sortant utilise LoopMessage pour les réponses et prend en charge l’indicateur de saisie, la gestion de la lecture et les réactions.

La documentation de l’API de LoopMessage distingue l’envoi de messages des webhooks, des callbacks et des statuts. C’est une bonne façon de penser l’intégration : l’information entrante, la communication sortante et les preuves de ce qui s’est passé sont liées, mais pas interchangeables.

Dans notre architecture, LoopMessage est la frontière du transport hébergé. Notis reste responsable de l’interprétation de la demande par l’assistant, du travail effectué et du contenu renvoyé. Placer un assistant IA derrière une API de messagerie ne revient pas à sous-traiter ces responsabilités produit.

Exemple d’un workflow utile avec un média

Imagine que quelqu’un partage la photo d’une affiche d’événement public et demande : « Récupère les infos utiles et fais-en une note propre. » C’est un exemple inventé pour expliquer la conception, pas un échange réel avec un client ni une promesse de disponibilité.

Le message entrant contient à la fois une instruction et un média. L’application doit préserver le lien entre les deux. Lire le texte sans l’image laisserait de côté la matière première. Traiter l’image sans l’instruction laisserait de côté l’objectif de l’utilisateur.

L’assistant doit ensuite distinguer ce qu’il arrive à lire de ce dont il n’est pas sûr. Si l’heure est illisible, la réponse doit le dire. Un canal capable de transporter une image ne rend pas l’interprétation d’image infaillible.

Enfin, la réponse repart par le chemin sortant. Elle peut donner les informations extraites et renvoyer vers la note créée, si cette action était disponible et a bien été effectuée. La réponse doit rendre le résultat vérifiable, au lieu de se contenter d’un « C’est fait ».

La valeur propre du transport, c’est que la demande et la réponse peuvent rester dans une conversation familière. La valeur de l’assistant dépend de ce qui s’est réellement passé entre les deux.

Les réactions et les indicateurs de saisie doivent avoir un sens honnête

Les apps de messagerie ont habitué les gens à lire de petits signaux. Un indicateur de saisie suggère que quelque chose est en cours. Un statut de lecture dit quelque chose du message. Une réaction peut être un accusé de réception plutôt qu’une nouvelle mission.

Notre implémentation intègre ces signaux conversationnels via LoopMessage. Je les vois comme des outils d’interface à manier avec soin. Ils doivent aider à comprendre l’échange sans prétendre établir des faits qu’ils ne peuvent pas établir.

Par exemple, un accusé de réception peut dire à l’utilisateur que son message est bien arrivé. Il ne peut pas prouver qu’un fichier a été créé ou qu’une action externe a réussi. C’est la réponse finale qui doit porter cette preuve.

Quand tu conçois l’interface d’un assistant, décide de ce que signifie chaque signal avant de le brancher. Sinon, une conversation agréable en apparence peut devenir trompeuse précisément quand la tâche sous-jacente est lente ou bloquée.

L’iMessage hébergé et l’app Messages locale sur Mac sont distincts

Le chemin hébergé décrit ici utilise LoopMessage entre le réseau de messagerie et la gestion des canaux côté serveur de Notis.

L’intégration locale avec Messages sur Mac passe par l’app Messages de l’ordinateur de l’utilisateur. Elle a un chemin d’accès et un contexte d’exploitation différents. La preuve que l’une existe ne te dit pas que l’autre est connectée, configurée ou disponible pour une personne donnée.

Cette distinction est essentielle pour expliquer le produit. « Notis peut fonctionner avec les messages », c’est trop vague pour guider une configuration. Une explication utile nomme la connexion utilisée et vérifie qu’elle est disponible dans l’environnement de la personne.

J’appliquerais la même règle à tout assistant qui dispose de plusieurs chemins vers un service familier. Des interfaces similaires peuvent cacher des frontières de permissions et de livraison très différentes.

Ce que nous pouvons dire de l’implémentation

Nous avons vérifié un chemin de code pour la réception et l’envoi via LoopMessage. Ça permet de décrire l’architecture de l’intégration.

Ça ne dit rien du nombre d’utilisateurs qui s’en sont servis, du nombre de messages distribués ni d’une amélioration du temps de réponse. Nous ne présentons dans cet article ni audit des volumes chez le fournisseur, ni nouvelle analyse des accusés de livraison.

Pour valider un déploiement, je voudrais un échange complet vérifié avec un compte de test autorisé : texte entrant, média entrant, bon rattachement à la conversation, réponse sortante et statut de livraison correspondant. Les événements entrants en double et les envois ratés méritent aussi qu’on s’y intéresse. Ce sont des critères d’acceptation concrets, pas des résultats que je revendique ici.

Une interface familière exige quand même un résultat fiable

Si cette architecture m’intéresse, ce n’est pas pour la nouveauté de placer un assistant dans une fenêtre de chat de plus. C’est pour la possibilité de laisser quelqu’un demander quelque chose dans un endroit familier et d’y recevoir une réponse exploitable.

LoopMessage fournit le canal de messagerie hébergé que nous avons implémenté. Le reste de la responsabilité nous revient : préserver le contexte, interpréter correctement les événements, rendre visible le travail inachevé et décrire avec exactitude la disponibilité des canaux.

Si tu construis quelque chose de similaire, commence par suivre une demande jusqu’à son retour vers la personne qui l’a faite. Une API de messagerie est une brique solide. Une conversation complète, c’est le produit que les gens vivent vraiment.