On l’a vu dans ce dernier article, la multiplication des outils numériques et logiciels en entreprise nécessite de lier ces outils entre eux, en développant des connecteurs. Ces connecteurs permettent de synchroniser les données entre plusieurs outils, d’automatiser des tâches, et d’une manière générale, de gagner en productivité et en performance.
Vous avez identifié un besoin de connecteur au sein de votre entreprise : mais par où commencer ? Comment s’y prendre pour concevoir ce connecteur ? On fait le point dans cet article.
- Identifier et cartographier les processus
- Déterminer les données à transmettre
- Ne pas vouloir être universel
- Développer par itérations
- Pour conclure…
Identifier et cartographier les processus
Pour qu’un connecteur soit pertinent et bien conçu, il faut avant tout prendre le temps d’identifier son rôle au sein d’un processus plus macro.
Par exemple, si vous souhaitez connecter votre logiciel CRM et votre logiciel de facturation, il faut prendre le temps de lister les processus métiers, les règles de gestion, les impacts pour les utilisateurs de ce nouveau connecteur.
Il faut donc lister toutes les actions et utilisateurs liés à ce connecteur, les opérations réalisables par les utilisateurs, les autres outils potentiellement impactés… C’est absolument nécessaire pour ne pas passer à côté d’un besoin essentiel, ou à côté d’un effet de bord important.
De plus, cette approche permet de maximiser l’impact du connecteur auprès des utilisateurs. Lorsque deux outils qui ne l’étaient pas sont reliés, il faut faire avec les usages déjà en place et appliquer la conduite du changement adaptée. Impliquer les utilisateurs dès la conception est la clé d’un connecteur utile et utilisé.
Déterminer les données à transmettre
Transmettre des données, c’est avant tout en connaître la structure pour savoir ce qui est envoyé, d’un côté, et ce qui est attendu de l’autre côté.
Ces données, dans les outils numériques, sont généralement renseignées sous forme de tables, ayant chacune des champs et des relations à d’autres tables.
Pour bien exploiter un connecteur, il faut déterminer quels champs sont importants, et les traduire dans le format attendu par l’autre application. Nous appelons “mapping” l’ensemble de ces correspondances à déterminer.
Par exemple, pour transmettre un contact sur une application, nous pourrions avoir plusieurs champs correspondant aux numéros de téléphone : “Phone_1” et “Phone_2”.
Imaginons maintenant que sur l’autre outil, nous ayons des champs “personnal_phone_number” et “professional_phone_number”.
Dès lors, il faudra indiquer explicitement au connecteur si la donnée du champ “Phone_1” doit être synchronisée avec “professional_phone_number”, pour être sûr de bien retrouver sa fiche contact correctement renseignée !
Cet exemple parmi d’autres le montre : il faut bien identifier en amont de quelle donnée nous avons besoin. Quel que soit son usage, vouloir tout transmettre n’est pas une solution efficace, comme nous le verrons plus loin.
Ne pas vouloir être universel
L’écueil “classique” lors de la mise en place d’un connecteur, est de vouloir tout transmettre, en temps réel, avec toutes les composantes du système.
Alors que bien souvent, 90% de l’utilité d’un connecteur ne provient que de la transmission de certaines données bien choisies, dans des cas précisément identifiés.
On s’imagine que tout transmettre fait gagner du temps, puisqu’on économise la réflexion sur les données utiles ou pas. Mais est ce que ce temps gagné couvrira le temps (ou budget) utilisé à développer ou configurer le connecteur ? Rien n’est moins sûr.
De plus, un connecteur doit être maintenu régulièrement, puisqu’il fait le lien entre des applications susceptibles d’évoluer aussi.
Par exemple, lors du rachat d’une application par un groupe, il est courant de voir l’application utiliser le système d’authentification du groupe pour que les comptes soient uniques. Il est alors nécessaire de modifier le connecteur pour prendre en compte le changement.
Ainsi, on comprend bien la problématique : plus le connecteur est complexe, plus les données transmises sont nombreuses, et plus les risques de bugs ou de problèmes de compatibilité augmentent (et donc les coûts associés à la maintenance).
Si vous éditez votre propre logiciel, il peut être intéressant aujourd’hui d’exposer une API bien documentée et sécurisée, et de la lier à des outils d’intégrations comme Zapier via un connecteur, plutôt que de supporter vous-même les risques associés aux connecteurs dédiés à chaque application cible : on en reparlera dans un prochain article.
Développer par itérations
En entrepreneuriat comme en méthodologie agile, le MVP (désignant le “Produit minimal viable”) est de plus en plus plébiscité.
Issu de la méthodologie Lean Startup, le principe du MVP est de séparer le produit final en plusieurs lots à réaliser les uns après les autres, de façon à ce que le résultat soit viable et utile à la fin de chaque étape. L’important ici est bien l’identification de la première version, et cela s’applique d’autant plus à un connecteur.
En effet, relier plusieurs plateformes implique généralement une mise en place technique, se chargeant notamment de la connexion aux outils ou de la gestion des erreurs éventuelles. Si cette base est relativement incompressible, la quantité de données à transmettre, leur type, la fréquence etc. sont autant de paramètres pouvant faire varier la complexité. Plus elle sera élevée, plus il sera long de livrer le produit, et plus celui-ci présentera des risques de fonctionnements inadaptés au besoin.
En développant par itérations, vous faites le choix de vous appuyer à chaque fois sur une base stable et éprouvée. Vous commencez par une première itération, et vous pouvez ensuite choisir les développements suivants en fonction des retours terrain ou de l’évolution de votre business : l’impact de votre connecteur sera donc maximisé.
Ajoutons qu’un connecteur, contrairement à un logiciel ou une application, n’a pas besoin de nombreuses fonctionnalités pour être utile. Il peut servir dès la première itération, si celle-ci a été définie avec soin ! Ainsi, dès que le connecteur est mis en place, il fonctionne et commence à apporter de la valeur ajoutée.
Pour conclure…
Pour un connecteur comme pour tout développement informatique, la phase de conception est capitale.
Connecter des applications entre elles, c’est avant tout vouloir améliorer ses processus : cela nécessite de bien les connaître, et de bien connaître les utilisateurs. On se place ici bien en amont des contraintes techniques, sur lesquelles nous reviendrons dans un prochain article.
Il faut approcher l’ensemble des systèmes comme un produit auquel nous ajouterions une ou plusieurs nouvelles fonctionnalités. Cette approche produit, centrée sur l’utilisateur, peut faire l’objet d’un accompagnement externe. Bien souvent, avoir un regard neuf sur ses processus et ses acteurs, permet de mieux identifier ce qui pourrait être amélioré, au-delà d’un éventuel connecteur.
Le sujet vous intéresse ?
Découvrez les autres articles de cette série :
