Crafting a better work experience

Passer d’une application à l’autre pour réunir toutes les informations dont vous avez besoin est contre-productif.

C’est souvent le cas quand il faut jongler entre votre CRM et votre client de messagerie pour retrouver les informations d’un client.

Ne serait-il pas idéal d’accéder rapidement à toutes ces informations directement depuis vos e-mails ?

Si vous utilisez Missive pour gérer vos e-mails personnels et vos e-mails d’équipe, et que vous voulez afficher des données issues de votre propre base de données ou d’une feuille Google Sheets, Retool est un bon outil.

Voici un tutoriel pour utiliser l’intégration Retool et ajouter ces données à Missive.

Qu’est-ce que Retool ?

Retool est un outil puissant et flexible qui vous aide à créer rapidement et facilement des applications internes sur mesure. Son interface en glisser-déposer, simple mais puissante, vous permet d’ajouter n’importe quelle source de données à vos applications et de les partager avec votre équipe.

Comment utiliser Retool avec Missive ?

Retool est un excellent moyen de créer une intégration sur mesure qui relie une source de données à une application utilisée par votre équipe. Grâce à cette solution low-code, vous créez facilement les outils internes dont vous avez besoin pour donner un coup de fouet à la productivité de votre équipe.

Dans ce tutoriel, nous allons voir comment utiliser Retool pour afficher les données d’une feuille Google Sheets à côté de vos e-mails dans Missive.

1. Créer nos requêtes dans Retool

Pour voir les données d’une feuille de calcul Google à côté des conversations, nous devons interroger notre document Google Sheets depuis une application Retool intégrée à Missive.

Nous devons d’abord créer trois requêtes dans notre application Retool. Pour cela, connectez-vous à Retool et créez une nouvelle application en cliquant sur Create new > App. Si vous n’avez pas encore de compte, créez un compte Retool.

Ensuite, nous devons créer nos requêtes de données :

1. La première interroge les données de l’application Missive.
2. La deuxième interroge les données d’une feuille Google Sheets.
3. La troisième fusionne ces deux sources de données et affiche les bonnes données dans l’application Retool (la barre latérale de Missive).

Pour ajouter une source de données à votre application Retool, cliquez sur l’icône + et sélectionnez Resource query. Nous allons d’abord créer la requête qui récupère les données de la conversation sélectionnée dans Missive.

Pour ajouter une source de données à votre application Retool, cliquez sur l’icône + dans le panneau inférieur gauche nommé Code et sélectionnez Resource query.

Commençons par créer une requête qui récupère les données de la conversation sélectionnée dans Missive.

Ci-dessous, nous appelons la requête getCurrentConversation, mais vous pouvez la renommer si vous le souhaitez. Le champ Resource doit être réglé sur ParentWindow et le champ Selector sur conversation.

La deuxième requête connecte notre feuille Google Sheets à Retool. Pour la créer, ajoutez une nouvelle requête comme précédemment. Dans Resource, sélectionnez + Create a new resource. Choisissez ensuite Google Sheets et suivez les instructions.

De là, vous pouvez sélectionner la feuille de calcul à connecter.

Vous pouvez faire un test avec une feuille qui a les mêmes colonnes que celle-ci :

Enfin, nous devons créer la requête qui fusionne les données de Missive avec la feuille de calcul. Nous l’appellerons simplement query. Pour celle-ci, sélectionnez Query JSON with SQL comme Resource.

La requête doit être la suivante :

select * from {{ googleSheet.data }} where Email = ANY({{getCurrentConversation.data.email_addresses.map(x => x.address.toLowerCase())}})

En résumé, elle trouve toutes les lignes de la feuille de calcul dont l’adresse e-mail correspond à au moins une des adresses de la conversation sélectionnée dans Missive.

2. Créer une interface pour Missive

Maintenant que nous avons les bonnes données, nous pouvons créer une interface simple pour les afficher. Dans le panneau de droite de l’éditeur Retool, sélectionnez l’onglet Create, puis glissez-déposez le composant Key Value dans votre application.

Sélectionnez ensuite le composant ajouté puis, dans l’onglet Inspect du panneau de droite, collez {{ query.data[0] }} dans le champ Data.

Et voilà ! Nous avons une application simple, mais fonctionnelle.

Avant de l’essayer dans Missive, apportons quelques retouches de style à l’application Retool pour qu’elle s’affiche mieux dans la barre latérale droite de Missive.

Pour cela, ouvrez le menu More en haut à droite, puis sélectionnez l’option Scripts and styles.

Collez ensuite ce code CSS :

._retool-container-table1 {
   width: 100% !important;
}

._retool-container-keyValue1 {
   width: 100% !important;
}

Le nom de classe ._retool-container-keyValue1 dépend du nom de votre composant. Pensez à l’adapter au nom de votre composant.

Ce CSS permet au composant de s’adapter dynamiquement à la largeur de la barre latérale de Missive.

3. Ajouter notre application Retool dans Missive

Place à l’essai dans Missive ! Copiez le lien View de votre application :

Dans Missive, ouvrez Paramètres > Intégrations, ajoutez une intégration Retool et collez le lien copié dans le champ URL publique Retool :

Enfin, ajoutez ?_embed=true à la fin de l’URL collée. L’en-tête Retool disparaît alors de l’intégration, pour un rendu bien plus propre.

Veillez aussi à désactiver l’option Enable mobile layout dans les paramètres de votre application Retool :

Et voici le résultat final !

‍

Utiliser l’API JS de Missive depuis Retool

Vous pouvez aussi tirer parti de l’API JS de Missive depuis votre application Retool. Voici comment faire :

1. Activer la communication avec la fenêtre parente

Par défaut, Retool bloque toute communication entre l’application et sa fenêtre parente (Missive). Vous pouvez l’activer dans vos paramètres Beta :

2. Ajouter la bibliothèque missive-retool.js à votre application Retool

Ajoutez ce script dans la section Scripts and styles de votre application Retool :

https://integrations.missiveapp.com/retool/missive-retool.js

3. Utiliser l’API JS de Missive

Vous pouvez désormais utiliser l’API JS de Missive depuis votre application Retool. Vous pouvez par exemple ajouter un lien qui ajoute de nouveaux commentaires et de nouvelles tâches à la conversation sélectionnée :

Tout logiciel a besoin de limites. Presque chaque partie d’un logiciel a besoin d’une limite stricte. Du moins, chaque partie qui manipule des listes. Dans la plupart des langages et des bases de données, cela veut dire des tableaux et des chaînes de caractères.

Cela paraît évident, mais je suggère à chaque ingénieur qui lit ces lignes d’ouvrir sa base de code et de jeter un œil. Vous avez sûrement des validations de longueur ici et là, mais si vous n’avez jamais consacré une demi-journée à passer en revue toutes vos listes pour fixer une limite à chacune, il vous reste probablement plusieurs failles.

Je ne parle pas des limites évidentes, visibles par les utilisateurs, comme le plafond de 5 utilisateurs du forfait Starter ou de 25 utilisateurs de notre essai gratuit. Je parle des limites que 99 % des utilisateurs n’atteindront jamais. Par exemple, coller plusieurs paragraphes dans l’objet d’un e-mail au lieu du corps. Ou, de la même façon, saisir les « Notes » d’un contact dans le champ « Prénom ». Ou encore ces boucles infinies qui vous tomberont dessus dès que vous lancerez une API publique.

Le seul cas où vous n’avez pas besoin de limite stricte, c’est quand une liste est toujours lue avec une pagination. Après tout, qui dit pagination dit LIMIT déjà en place.

Adoptez les limites strictes

J’adore les limites strictes. J’adore savoir qu’elles sont là. J’adore en ajouter de nouvelles à chaque nouvelle fonctionnalité. Les limites strictes sont la clé pour que je dorme sur mes deux oreilles.

Elles demandent aussi peu d’efforts : pas besoin de documentation publique. Vous prévoyez naturellement des messages d’erreur corrects pour les rares cas extrêmes qui les atteindront, mais personne n’a besoin de les garder en tête pour savoir si elles vont affecter son activité.

Vous devriez même vous imposer de ne pas avoir à les communiquer. Si vous commencez à voir un nombre significatif d’exceptions, c’est sûrement que la limite est trop basse. Le but n’est pas d’agacer ou de brider les utilisateurs, mais d’éviter les plantages. Passer une limite de 500 à 1 000 ne fera pas planter votre app, mais cela peut faire la différence entre un utilisateur qui l’atteint une fois par mois et un utilisateur qui l’atteint tous les jours.

C’est aussi l’occasion de se rappeler que le monde est divers. Restez humble, acceptez et embrassez le fait que certains de vos clients auront des usages que vous n’aviez jamais imaginés. Ne tombez pas dans le piège d’accuser les gens de mal utiliser votre logiciel.

Un jour, une organisation s’est heurtée à une limite et nous a écrit. Elle avait besoin de plus de 25 champs personnalisés sur un contact. Lui avons-nous demandé d’expliquer sa situation et de voir comment adapter son usage ? Bien sûr que non. Nous avions fixé cette limite de 25 arbitrairement au départ, nous pouvions donc tout aussi bien la passer à 50. Problème réglé !

Évitez les débats futiles

Je vous suggère de vous limiter à une courte liste de nombres pour toutes vos limites :

1 • 5 • 10 • 50 • 100 • 500 • 1000 • 5000

Ce sont les plus faciles à retenir pour tout le monde. L’écart entre chacun est aussi assez grand pour que la décision soit facile. Inutile de perdre du temps à se demander si 100, 200 ou 300 convient. Un doute sur 100 ? Prenez 500, c’est largement suffisant !

Le « 1 » sert pour les Ko ou les Mo. Quelle doit être la taille maximale du corps HTML d’un e-mail ? Vous conviendrez sûrement que 1 Mo suffit, sachant que c’est à peu près la taille d’un tome de Harry Potter.

Quelle taille de charge utile JSON notre serveur web doit-il refuser d’analyser ? 5 Mo ou 10 Mo, les deux nous vont très bien. La seconde est la limite qu’utilise Amazon API Gateway.

Quand vous répondez à un fil d’e-mails et que nous le citons sous votre réponse, où nous arrêtons-nous ? 10 Ko de texte cité, et le tour est joué.

Combien de libellés allez-vous appliquer à cette seule conversation ? J’espère que 100 vous suffiront.

Au-delà de combien de sessions simultanées commence-t-on à flairer plusieurs utilisateurs qui rechignent à payer un prix juste par siège ? Je n’ai jamais vu personne en avoir besoin de plus de 10.

Et la liste est encore longue.

J’espère que cet article vous a plu et que vous passerez votre prochaine matinée à ajouter de jolies limites partout dans votre code. Allez-y, c’est amusant ! ✌️

Remarque : date de fin de prise en charge reportée « En raison de la situation sans précédent que nous traversons, et sachant que les priorités de nombreux clients ont changé, nous avons décidé de reporter le retrait de l’authentification de base dans Exchange Online (MC204828) pour les locataires qui l’utilisent encore activement, jusqu’au second semestre 2021. Nous communiquerons une date plus précise lorsque nous aurons une meilleure idée de l’impact de la situation. » – Microsoft

Pas d’inquiétude, Missive prend toujours en charge Office 365, Outlook et IMAP. 😅

Le 13 octobre 2020, Microsoft cessera de prendre en charge l’authentification par nom d’utilisateur et mot de passe pour les protocoles IMAP et POP3.

Concrètement, toute application de messagerie qui se connecte aux serveurs e-mail de Microsoft via IMAP ou POP3 (authentification de base) cessera de fonctionner.

L’authentification de base désigne la façon dont une application transmet le nom d’utilisateur et le mot de passe d’un utilisateur. Dans bien des cas, c’est une méthode peu sûre pour gérer des identifiants, surtout lorsqu’un tiers intervient et doit stocker les identifiants de l’utilisateur pour s’authentifier en son nom (application de messagerie dans le cloud).

Comme alternative, Microsoft a développé l’authentification moderne (un terme propre à Microsoft), basée sur une méthode d’authentification appelée OAuth 2.0. Cette méthode ne partage pas les mots de passe : elle utilise des jetons d’autorisation (voyez-les comme des mots de passe temporaires) pour prouver l’identité entre les utilisateurs et les fournisseurs de services.

Les applications qui se connectent à votre compte Microsoft ne reçoivent jamais votre vrai mot de passe. Vous pouvez aussi révoquer l’accès de ces applications depuis votre compte Microsoft. Rien que ça, c’est une bonne chose !

La fin temporaire d’IMAP

Le problème, c’est qu’en abandonnant l’authentification de base, Microsoft porte un coup fatal à de nombreux clients de messagerie qui ne prennent en charge que les protocoles IMAP/POP3. À partir du 13 octobre 2020, la seule façon pour les clients de messagerie de synchroniser les e-mails des comptes Microsoft sera d’implémenter l’API REST propriétaire d’Outlook ou le protocole Exchange.

Techniquement, le protocole IMAP prend en charge l’authentification OAuth 2.0 via une extension ; c’est ainsi que fonctionne Gmail. Il est toutefois peu probable que Microsoft la prenne en charge à temps. Cette prise en charge a été annoncée récemment, mais sans date précise :

Pour faciliter la migration de vos applications existantes vers OAuth 2.0, nous investissons massivement dans notre service, notamment dans la prise en charge d’OAuth 2.0 pour POP et IMAP, et dans la prise en charge des applications en arrière-plan pour le module MFA de PowerShell à distance. Nous partagerons plus d’informations sur ces nouvelles fonctionnalités dans les prochains mois.

Pour nos utilisateurs, ce n’est pas un problème : notre moteur de synchronisation prend désormais en charge l’authentification moderne via l’API REST d’Outlook. Pour un client de messagerie dans le cloud, ne plus avoir à stocker et à chiffrer les mots de passe des utilisateurs est une amélioration considérable. Il est simplement dommage, et contre-productif, que Microsoft n’ait pas proposé d’emblée les connexions IMAP avec l’extension OAuth 2.0.