Bonjour à tous, j’espère que vous allez merveilleusement bien. Aujourd'hui, on va voir une solution qui s'appelle Vertify, une solution Cloud qui permet d'intégrer Marketo avec différents CRM ou différentes solutions de manière custom, mais en allant extrêmement vite puisque c'est pré-packagé et en maîtrisant votre intégration et en allant plus loin que les intégrations natives traditionnelles avec Salesforce ou Dynamics. Je vais rappeler brièvement ce qu'on a dans les intégrations natives. Je vais voir ensuite quels sont les cas d'usages où ces intégrations natives sont un peu déficientes et je ferai ensuite une démo de Vertify. On y va ! Premier sujet, petit rappel sur ce que vous avez dans les intégrations natives avec Salesforce ou Dynamics. C'est peu ou prou pareil. Je ferais une petite différence. L'intégration de Salesforce est un peu plus avancée qu'avec Dynamics. Évidemment, vous avez une intégration bidirectionnelle entre les personnes de Marketo et d'un côté les leads et les contacts de Salesforce. Sachant qu'une personne dans Marketo soit n'est pas intégrée avec cette Salesforce, soit est liée avec un lead, soit est liée avec un contact, mais pas les deux. Puisque dans Salesforce, on va avoir cette conversion de lead en contact qui va être vue et écoutée et intégrée par Marketo. La conversion dans Salesforce est bien propagée côté Marketo, il n'y a pas de souci. Ensuite, on a des objets qui sont en lecture seule dans Marketo pour utiliser dans le scoring, dans le ciblage. C'est le cas des sociétés. Toutes les sociétés de Salesforce vont être dans Marketo ainsi que toutes les opportunités et les opportunities contacts roles, donc le lien entre les opportunités et des contacts. Ça, c'est en lecture seule côté Marketo. On peut l'utiliser dans les ciblages, le scoring pour exclure certaines personnes. Par exemple, quand il y a une opportunité business en cours, on va peut-être stopper les campagnes marketing. Un autre objet qui est en lecture seule, je reviendrai sur les campagnes juste après, les users, c'est-à-dire les commerciaux, vont se retrouver dans Marketo en lecture seule. Ce qui nous permettra d'envoyer des campagnes au nom des commerciaux. Et les custom objects qu'on va créer dans Salesforce, sous réserve qu'ils soient enfants ou petits-enfants d'un compte ou d'un contact vont pouvoir être répliqués côté Marketo. Par exemple, si vous utilisez un objet projet comme moi dans votre Salesforce, qui est un objet que vous avez créé pour stocker et gérer les projets que vous avez avec vos clients, vous pouvez avoir cet objet mis à jour en temps réel côté Marketo. Et derrière, faire du ciblage ou déclencher des campagnes dès qu'une personne est ajoutée à un projet ou dès qu'on statue sur un projet change. C'est vraiment très pratique. On va avoir en double synchro bidirectionnelle les campagnes et les campagnes members. Ça, c’est très pratique, par exemple, pour répliquer tous les programmes Marketo côté Dynamics et donner de la visibilité aux sales avec pas beaucoup d'objets qui vont être synchronisés sur les campagnes, surtout le nom, le coût et la start date, je crois. Sur les campagnes members, maintenant, tous les champs d'une campagne members peuvent être synchronisés côté CM. Et enfin, on a un certain nombre d’activités qui vont s'échanger des deux côtés. Marketo va lire les activités Salesforce, que ce soient des événements ou des tâches. Et inversement, il y a un certain nombre d'activités qu'on peut pousser côté Salesforce en ayant la main sur les types d'activités qu'on va pousser. Une fois qu'une personne est synchronisée avec Salesforce, on n'a plus besoin de faire quoi que ce soit. Toute modification de part et d'autre va être propagée de l'autre côté au bout de maximum cinq minutes puisque les synchros ont lieu toutes les cinq minutes. Petit rappel juste pour préparer la phase suivante qui est : dans quels cas les intégrations natives ne sont pas suffisantes ? Il y a plusieurs cas. Le premier qui m'embête pas mal, que je vois souvent chez les clients, c'est que la réconciliation des données entre Marketo et le CRM pour cette intégration ne se fait pas sur l’e-mail, se fait sur la clé du CRM. C'est-à-dire que quand Marketo a une nouvelle personne en base, l'intégration va regarder si j'ai un Salesforce ID ou un Microsoft Dynamics ID sur cette personne. Sinon, je vais le créer en face côté CRM. Même si cette personne existait par ailleurs avec le même e-mail, c'est comme ça. Ça a un grand avantage, c'est que les ID ne changent jamais. C'est une chose assez stable, mais ça peut poser des problèmes. Par exemple, un cas qu'on rencontre assez souvent c'est : on commence à travailler dans Marketo en important son CRM par fichier plat. Les deux systèmes n'étant pas connectés au départ parce que l'IT n'est pas tout à fait prête, on repousse un peu la synchro. On fait des campagnes marketing, les gens évoluent. Et puis, au bout de six mois, on intègre les deux systèmes avec la synchro native. Et là, la synchro se dit : "Je n'ai pas d'ID Salesforce ni Dynamics côté Marketo", puisque, généralement, on ne l'a pas importé. Tous les gens qui sont aujourd'hui dans Marketo n’existent pas dans le CRM. Donc je vais réimporter tout le monde dans le CRM et on se retrouve avec des doublons massifs côté CRM qu'il faut ensuite traiter. Il y a différentes solutions pour s'en sortir un peu mieux. Mais comme le champ Salesforce ID ou Microsoft ID est un champ système côté Marketo, on ne peut pas le mettre à jour. C'est assez compliqué. Premier point qui génère pas mal de doublons. Là, ce qu’on va pouvoir faire dans Vertify, typiquement, c'est de dire : "L’ID, c'est une bonne idée, mais si tu ne trouves pas l'ID, regarde ensuite en deuxième check si tu ne trouves pas un e-mail exact. Si tu en trouves plusieurs parce qu'il y a des doublons côté CRM, il faut faire des règles de gestion un petit peu fines, mais ça permettrait de pouvoir raccrocher les personnes dans ce cas-là." Deuxième sujet qui nous embête un petit peu. On souhaite parfois filtrer un peu mieux les objets qui sont dans Salesforce. On a la main quand même dans le CRM, dans Dynamics ou dans Salesforce sur quelles sont les personnes qu'on envoie vers Marketo, voire sur quels sont les comptes grâce à des règles de visibilité ou des flags qu'on va mettre sur les personnes. Par exemple, sur les opportunities contacts roles, c'est-à-dire les contacts qui sont attachés aux opportunités. Vous savez, quand vous avez une opportunité, vous pouvez mettre différents contacts avec différents rôles sur cette opportunité. Il va y avoir le décisionnaire, le payeur, l'utilisateur métier, l'utilisateur DSI, il y a plein de rôles. Toutes ces personnes sont très importantes sur l'opportunité, puisque ça va contribuer au modèle d'attribution dans Marketo, c'est-à-dire la façon dont Marketo va lire le revenu des opportunités, le distribuer sur les personnes attachées au revenu des opportunités qui vont ensuite être distribuées sur les campagnes qui ont touché ces personnes. C'est ainsi qu’on peut ramener du revenu sur les campagnes. Ces campagnes ayant un coût, on va pouvoir ainsi calculer un ROI. Problème, typiquement dans mon CRM, j'ai tendance à ajouter beaucoup de personnes sur l'opportunité, y compris les collaborateurs ou les partenaires qui sont susceptibles de travailler sur cette opportunité. Ce qui fait que ces personnes qui participent à beaucoup de campagnes puisqu'on fait des tests sur les campagnes happent une partie du revenu des opportunités qui se retrouve enlevée des vraies campagnes. Je voudrais par exemple ne pas synchroniser sur l'opportunité contacts roles les gens qui ont un certain rôle, mais je ne peux pas le faire puisque je n’ai pas la main sur cette intégration. Troisième sujet qui peut nous embêter, c'est le fait qu’on aimerait bien parfois entre les deux systèmes, transcoder des données. Le cas typique, c'est chez Dynamics, parfois il se peut que les listes de valeurs soient stockées non pas sous forme texte en anglais par exemple, mais sous forme d'un code. On va avoir les pays qui vont s'afficher dans l'écran. Mais quand ça va être stocké en base, ce n’est pas France qu'on va voir, c'est 00013 ou Germany, ça va être 0014. Ce que Marketo va lire, lui, c'est bien ce qui est donné en base, ce n'est pas ce qui apparaît à l'écran. On va se retrouver dans Marketo dans le champ pays avec des 013, 014, 015 qui, pour le marketing, sont une horreur puisque c'est compliqué de faire des ciblages sur des champs qui ne sont pas les champs explicites "user friendly", à moins d'avoir imprimé sa liste de transcodification de pays en codes, mais c'est un petit peu plus compliqué. Ce qu'on aimerait, c'est de pouvoir transposer à la volée des codes en pays. Et vice versa, quand un pays est mis à jour, retranscoder en code. Ça, ce n’est pas possible dans la synchro native, ce n’est pas prévu. Alors que dans Vertify, on va pouvoir le faire. Idem pour parfois changer le format des choses. Par exemple, s'assurer que les e-mails sont tous en minuscules, ça va poser problème parfois. Mettre pas les noms de sociétés en majuscules à l'inverse, décider de remplacer certaines parties de texte. Typiquement dans les commentaires, à chaque fois que les gens mettent des retours chariots, on sait très bien que dans les exports de fichiers ça va poser problème. On veut pouvoir peut-être enlever des retours chariots. Il y a plein de moments où on aimerait qu'avant que la donnée rentre dans le CRM, elle soit un petit peu améliorée, enrichie et ainsi de suite. Ça, c’est une chose qu'on ne peut pas faire dans le natif, qu'on peut faire avec Vertify. Autre chose qui peut nous arriver, on veut mettre à jour ce champ seulement s’il est vide et une fois qu'il est rempli une première fois, on ne veut plus y toucher. Ça, ce n’est pas possible dans la synchro native. Dès qu'on met un champ à jour, il va écraser ce qu'il y a en face, quelle que soit la valeur qui est là. Ça, c'est particulièrement utile, par exemple sur tous les champs d'acquisition qu'on souhaite travailler d'un côté ou de l'autre. Et évidemment, comme ce sont des champs d’acquisition, on souhaite garder la première valeur qu'on a captée quand la personne est entrée et ne plus jamais la toucher. Sinon, on va perdre la donnée de la première valeur, de la première touche. On peut aussi vouloir synchroniser parfois les custom objects en bidirectionnel. Je vous ai dit juste au-dessus, les custom objects sont en lecture seule depuis le Salesforce. Qu'est-ce que c'est qu'un custom object ? Par exemple, vous pouvez avoir des intégrations avec des solutions de webinaires, des solutions de quizz, des solutions de vidéos, c'est le cas chez moi, qui vont non seulement créer des personnes dans votre base, mais ensuite, enrichir l'information autour de ces personnes. Par exemple, pour les webinaires, il se peut que la personne pendant le webinaire ait posé une question, ait tchatté et voté sur un sondage que vous avez préparé. Ces données vont être stockées non pas sur la personne sous forme de champs, mais dans un custom object, par exemple un custom object sondage, un custom object tchat, un custom object question. Puisqu'une personne peut très bien poser plusieurs questions, peut très bien voter sur plusieurs sondages, peut très bien avoir plusieurs sessions de tchat avec vous. Évidemment, les champs sur les personnes, ça ne va pas être très confortable pour stocker cette info. Il vaut mieux soit les custom activities, soit les custom objects. Cette information que vous avez collectée depuis votre webinaire, vous aimeriez la pousser aux ventes. Là, on est coincés puisque dans l'intégration native, ces objets custo ne pourront pas écrire côté CRM. C'est encore une limitation. Un éternel sujet surtout côté Dynamics. Quand l’intégration fonctionne bien, il n'y a pas de souci. Évidemment, tout va pour le mieux dans le meilleur des mondes. Mais quand ça se passe mal, parfois c'est assez compliqué de savoir ce qui se passe vraiment dans la boîte noire de l’intégration Marketo Dynamics et on a des remontées de codes d'erreur particulièrement indigestes qui font qu’on ne sait pas forcément où chercher. Parfois, c'est assez compliqué. Là, ce qu'on aimerait, c'est avoir des choses qui nous permettent, côté DSI, de, un, maîtriser sa synchro, d'avoir des alertes quand les choses se passent mal, et pouvoir traiter facilement les sujets sans s'arracher les cheveux, ce que va pouvoir faire Vertify. Dernier sujet et je suis sûr qu'il y en a d'autres, mais c'est ceux auxquels j'ai pensé immédiatement. Synchroniser deux CRM avec un Marketo. Ça peut paraître bizarre, mais il y a pas mal d'organisations d'une taille assez conséquente qui peuvent avoir plusieurs CRM. C'est particulièrement le cas quand on va avoir des BU qui sont très différentes où à l'acquisition, où on peut se récupérer deux CRM, mais on ne souhaite pas tout fusionner pour des raisons, encore une fois de business model, qui seraient trop différentes. C'est assez pertinent de pouvoir avoir deux CRM si vraiment les modèles métier sont très différents. Ça va être une horreur de gérer tout dans un seul Salesforce. Par contre, comme Marketo est relativement… On ne va pas dire pas indépendant des business models, mais dans Marketo, on fait des campagnes marketing et le modèle objet va être le même. On peut vouloir n'avoir qu'un seul Marketo, mais deux Salesforce ou deux Dynamics. Et là, les intégrations natives sont faites de telle façon qu'on ne peut connecter qu'un seul Marketo à un seul CRM. Premier point. Donc impossible de connecter nativement un Marketo avec deux Salesforce ou, inversement, un Salesforce avec deux Marketo, ça ne marcherait pas. Et deuxième point : une fois qu'on fait une connexion native entre un Marketo et un Salesforce, l'intégration native verrouille les API de certains objets, Companies, Opportunities, Opportunity Contact Role et Sales Users. Ce qui fait que, même si on voulait utiliser une intégration native pour un Marketo, un Salesforce, et faire une intégration custo entre le Marketo et le deuxième Salesforce, on ne pourrait pas puisqu'on aurait accès qu'à la personne. C'est toujours possible, mais ce serait vraiment une intégration assez dégradée qui ne serait pas idéale. Mieux vaut prévoir un Vertify au milieu qui va, pour le coup, nous donner la main, très finement, sur comment connecter un Marketo avec les deux Salesforce en faisant bien attention aux clés. Rentrons maintenant dans Vertify. Je me suis logué à une Sandbox Vertify. Vertify est une solution Cloud, dont les serveurs pour nous, européens, vont être situés en Europe. Je ne sais plus dans quel pays, si c'est l'Irlande ou les Pays-bas. On a les serveurs en Europe, pas de problème. On a le petit "EU" qui va nous dire qu'on est en Europe. Vertify va nous permettre de connecter deux solutions entre elles avec une facilité assez déconcertante. Là, pour voir le processus, on clique sur Edit. Et ici, on va avoir ces cinq étapes qui sont assez évidentes, où on va connecter le système, collecter les données, ce qui nous permet de voir les modèles objets et les champs. Mapper ensuite. Gérer les règles de transcodification, de transformation de données. Ensuite, gérer la connexion, c'est-à-dire tester unitairement chaque flux, chaque champ pour vérifier que tout est correct. Et une fois que c'est bon, on va pouvoir appuyer sur le bouton. Premier point : Vertify se connecte avec beaucoup de systèmes. Je cherche ça. Integrations, ça va être là. Évidemment, ce qui va m'intéresser, c'est Marketo. On voit qu'il se connecte avec Dynamics, PipeDrive, SugarCRM, NetSuite, Zoho, et toutes ces solutions. Côté e-commerce et Sales Engagement. J'avoue que je ne connais pas tout. Ici, on va pouvoir connecter un nouveau système. On va pouvoir choisir dans la liste les connecteurs pré-packagés qui sont ici. Ce qui est intéressant, outre toutes les connexions pré-packagées qui existent, comme HubSpot, Marketo et ainsi de suite, c'est qu'on va aussi avoir des connexions ODBC. Ça, c'est extrêmement pratique si on a un système qui est on premises, en local chez vous. On va pouvoir se connecter à la base locale et lire directement le modèle objet de la base locale. Que ce soit en ODBC Oracle, ici qui sont un peu plus précis. Et on a aussi une connexion SFTP. C'est-à-dire qu'on peut aussi imaginer l'intégration où le système CRM source met à disposition des fichiers plats. Un certain nombre de fichiers plats dont il faudra qu'on s'accorde sur le format, évidemment, les champs et le nombre. Mais on peut très bien avoir un fichier plat pour les nouvelles personnes du CRM, les personnes mises à jour, les personnes supprimées, par exemple. Idem pour les mises à jour de sociétés, les ajouts de sociétés, les opportunités, opportunités de contact role. Enfin, vous avez compris. Tous les objets de Marketo, il faudrait qu'on ait en face des fichiers plats qui soient mis à disposition, par exemple tous les jours ou toutes les quatre heures, ou toutes les demi-heures. Et inversement, toutes les modifications de Marketo vont être poussées comme fichiers plats, qui vont être intégrés par ce système. On passe par une étape intermédiaire de fichiers plats, stockés sur un serveur sécurisé, SFTP. Ça, ça peut être une autre solution quand la connexion n'est pas prévue ici. Ici, pas besoin de créer un nouveau système. Si je regarde côté Marketo, on se connecte sur Marketo de façon assez classique avec le Client ID, Client Secret, le End Point. Là, je suis sur une Sandbox Marketo Vertify. Et il y a un certain nombre de paramètres ici qui vont me permettre d'inclure ou de filtrer des activités qu'on va pousser côté CRM. Vous savez qu'évidemment, on ne veut pas envoyer tout l'Activity log de Marketo côté CRM, ce serait beaucoup trop volumineux. Et côté Marketo, on va travailler avec des Static Lists. On va faire une Static List dédiée pour les ajouts de personnes à envoyer pour la première fois dans le CRM. Et une autre Static List qu'on va mettre à jour pour toutes les modifications des personnes déjà synchronisées. C'est extrêmement classique, extrêmement simple. C'est la bonne méthode pour faire ça. Ce qui fait que Vertify va lire en permanence ces deux listes statiques. Et une fois que Vertify aura lu ces données, va effacer les Static Lists, qui devraient être régulièrement vidées. Côté Zoho, pareil. Ce n'est pas la même méthode de connexion. Chaque système a sa propre méthode de connexion, mais on a aussi un Client ID, Client Secret. Là, on a un Account URL, qui est l'équivalent du REST url, et on a un token. Pour la partie Connect, c'est relativement simple. On plug Vertify avec le système source, juste en renseignant les paramètres de connexion. Et ça fonctionne immédiatement. Deuxième étape : collect. Ici, quand on va faire la première synchro, on va voir tous les objets de la base. Ici, on voit qu'on a les tables standards Marketo. Pour ceux qui ne travaillent pas trop sur les API Marketo, ça peut paraître un peu bizarre parce que les noms des tables sont un peu bizarres. Par exemple, LeadRecord, c'est la table de la personne. Ici, on reconnaît la table des opportunités, Opportunity conctat role. Program, c'est les campagnes. SalesPerson, ce sont les commerciaux. Campaign, c'est un objet custo, je pense. Il y a pas mal d'objets custo. Par exemple, Borrower Loan, Campaign, Co Borrower Loan. Ça va être un exemple de société de crédit. On a l'objet Company. e-mail, je ne sais plus ce que c'est. Je crois que c'est une table un peu système. Là, tout bêtement, on lit les tables. Ensuite, on va pouvoir lire aussi les champs. C'est assez pratique pour exporter notamment le modèle donné exact de Marketo, et commencer son data mapping, c'est-à-dire le fichier où on va indiquer : tel objet connecte avec tel objet dans le CRM, et tel champ connecte avec tel champ. C'est un travail préparatoire qui est à faire par les métiers, généralement, pour dire : comment on veut connecter les champs, voilà quels sont les champs qui vont manquer côté Marketo, qu'il faut qu'on crée avant de connecter les deux systèmes. Voilà quels sont les champs qu'il faut qu'on crée côté CRM et qui vont manquer côté CRM. Ça, c'est l'étape où on va collecter les données et vérifier comment elles apparaissent. Par exemple, si je vais sur le lead, je vais pouvoir collecter… Ici, je peux collecter le schéma seulement. Donc il va me donner, sur le lead, tous les champs. Je peux collecter les changements de données. Je peux collecter toutes les données depuis telle date. Ou je peux faire un Collect All Data. Si on essaie de collecter les changements, par exemple… L'interface va se démarrer, il va se connecter à Marketo. Et on va voir qu'il va commencer à analyser. Comme c'est une Sandbox, il n'y a pas beaucoup de changements, je pense. Voilà, il ne se passe pas grand-chose. Si j'exporte ça, qu'est-ce que ça donne ? On voit qu'ici, il n'y a pas eu de changement. En gros, j'ai juste l'entête des champs de Vertify. Si on prend celui-là, LeadPartitionId, on reconnaît le nom du champ Marketo puisque ce sont des PartitionId. Ou ici, il va s'appeler mktoDoNotCallCause. On reconnaît le nom des champs Marketo. Mais côté Vertify, le nom des champs comporte en amont LeadAttributeList, il faut le savoir. Idem côté Zoho. On peut collecter ici l'ensemble des champs. Et on peut décider de cacher certains, avec lesquels on ne souhaite pas travailler. Parce que vous n'allez pas connecter toutes les tables de Zoho à Marketo, cela n'aurait pas trop de sens. On peut, ici, faire son petit nuage en disant : typiquement, Borrower Loan, je n'en ai pas besoin dans l'intégration pour l'instant, donc je vais le cacher. Une fois qu'on a collecté les données, on va pouvoir mapper. C'est là où on va gagner pas mal de temps puisque Vertify va nous montrer ici, à gauche, les objets sources. Ici, on a les objets cibles. Et on va pouvoir drag and dropper. Là, j'ai pris les LeadRecord de Marketo, que j'ai drag and droppé, comme ça, sur le contact de Zoho. Donc je dis : "Je veux mapper les LeadRecord de Marketo avec les contacts de Zoho." Idem, je peux mapper aussi le LeadRecord de Marketo, la personne avec le lead. Derrière, je vais pouvoir mettre un filtre, en disant : "Si je vois que sur le LeadRecord, le ZohoType, qui est un champ qu'on aura construit exprès, est Contact, je vais plutôt diriger le flux ici. Si c'est Lead ou rien du tout, je vais le diriger ici." On va mapper tous ces objets. Si on souhaite faire une intégration bidirectionnelle, comme c'est le cas sur les contacts, je vais prendre le contact de Zoho ici et, à l'inverse, je vais le mapper avec le LeadRecord de Marketo. Le fait que j'ai fait le mapping des deux côtés va créer cette intégration bidirectionnelle. Une fois que je suis content avec mes mapping, je vais pouvoir ici mapper les champs. Là, on est au niveau champ, on est sur l'objet Zoho Contact vers LeadRecord Marketo. Et je vais pouvoir mapper. Je l'ai fait pour First Name et Last Name. Je prends First Name de Zoho et je le mets sur LeadAttributeList.firstName. Donc évidemment, en fonction du mapping qu'auront fait les métiers, il y a des champs qui sont évidents, il y a des champs qui sont peut-être un peu moins évidents puisqu'on ne connaît pas forcément toutes les définitions des champs qui ont été créés. C'est extrêmement simple. C'est simple, à tel point que les équipes marketing obs peuvent avoir la main sur le mapping des champs, puisque c'est du drag and drop, c'est extrêmement explicite. On peut s'aider de la recherche ici pour réduire le nom des champs et s'aider. C'est assez évident. Et une fois qu'on est heureux avec son mapping, on peut ajouter ici des filtres pour dire : ce flux de contact vers Record, je veux filtrer un certain nombre d'enregistrements, mais typiquement, ça pourrait être que l'e-mail n'est pas vide. Est-ce qu'il y a un opérateur pas vide ? Je ne me souviens plus. Différent de NULL. Si l'e-mail n'est pas vide, je synchronise. Si l'e-mail est vide, je ne synchronise pas les contacts vers les personnes Marketo. On peut mettre ces filtres ici, donc c'est assez pratique. Et côté Merge, on va ici pouvoir dire sur quelle règle on se base pour réconcilier les enregistrements. Ici, on a un certain nombre de choix. La base, ce serait évidemment l'ID. Ici, on va spécifier les ID des deux côtés. On aura créé, côté Marketo, un Zoho ID. Et ici, on va utiliser l'ID Zoh. Donc la source ici, ce serait le champ ID de Zoho. Et ici, ce serait ce qu'on a créé, ContactInternalId. Typiquement, ce serait ce champ ContactInternalId. Si les champs ID sont identiques, ça veut dire qu'on réconcilie. Mais on peut aussi, comme je le disais tout à l'heure, choisir ID then 1 Fuzzy, 1 Exact. Ce serait, si l'ID matche, on se base sur l'ID. Sinon, on essaie de réconcilier sur la base de l'e-mail en Fuzzy. Fuzzy, c'est une règle. On va comparer les chaînes de caractères, calculer un score de similitude entre les deux, et vérifier si les deux chaînes de caractères sont semblables à plus de 85-90 %, je ne sais plus, un score assez élevé. Ce qui est intéressant ici, ce serait de faire une chaîne de caractères qui comporterait le nom, le prénom et la société par exemple. Puisque si Sylvain Davril, Merlin-Léonard est orthographié normalement d'un côté, mais par exemple avec une apostrophe à Davril et sans le slash à Merlin-Léonard de l'autre côté, on peut dire que c'est sûrement la même personne. Le score de similitude va être le même à 98 %. Donc même si je n'ai pas d'ID d'un côté ou de l'autre, le fait que cette chaîne de caractères soit semblable, ça va matcher. Ensuite, on peut ajouter en Exact l'email, par exemple. Il y a pas mal de variations possibles. Exact then 2 Exact then 3. On peut faire pas mal de choses. ID Then 2 Exact. Donc là, on peut dire ID. D'abord les ID, ensuite email plus nom, par exemple, Last Name. Ensuite, 2 Fuzzy avec deux chaînes de caractères. C'est vraiment pas mal. Et ça évite le premier problème dont je parlais. Une fois qu'on a fait nos filtres et notre réconciliation, on peut aussi mettre sur chaque champ des transformations, soit des Truncate, donc je tronque une chaîne de caractères. Par exemple, d'un côté, j'ai prévu un champ de 250 caractères, de l'autre j'ai prévu un champ seulement de 100 caractères. Je ne sais pas pourquoi. Ce n'est pas une bonne idée, mais ça arrive. Donc je veux tronquer mon 250 caractères en 100 caractères pour qu'il soit accepté de l'autre côté. Ici, on peut faire des opérations Round sur… New Transformation. Je suis allé trop vite. On peut arrondir des chiffres, on peut formater des téléphones. On peut formater les URL. On peut mettre en upper, lower title, sentence. On peut remplacer des morceaux de chaînes de caractères, ce n'est pas mal. Et il y a quelques opérations sur les dates. On peut formater les dates. Intéressant à faire et assez facile à manipuler. On peut aussi dire… Le flux de base, c'est : je fais un Insert et/ou Update. Si la personne n'existe pas en face, je l'ajoute. Et si elle existe, je l'update sur la base du Merge. On peut décider que ce flux est juste un Insert, donc je ne fais qu'insérer les gens. Et si elle existe déjà, je ne l'insère pas. Ou à l'inverse, que les update. Donc si la personne existe déjà, je la mets à jour. Sinon, si elle n'existe pas, je ne fais rien. Tout ce que je fais là, c'est sur le champ Last Name, ce n'est pas sur la personne, c'est sur le champ. On Add Update If Empty, donc je mets à jour seulement si il est vide. Translate. Ici, ça va nous permettre de créer des tas de translations, de transcodifications. Typiquement, les pays dont je parlais tout à l'heure… Imaginons qu'on ait la liste des 189 pays du monde et des codes en face, qu'il faut respecter dans le CRM, on va pouvoir charger ici sa table de transcodification qui va s'appliquer en back and forth. On pourra appliquer la table de transcodification sur certains champs. Et on pourra gérer notre table de transcodification ici, proprement. Et ici, Manage, ça va vous permettre de tester le flux. Ici, comme c'est une Sandbox, je pense qu'il n'y a pas beaucoup de… Je reviens en arrière. Je pense qu'il n'y a pas de données, donc on ne peut pas jouer avec les flux parce qu'il n'y a pas assez de données. Il n'y a rien là. Oui. Il faudrait que j'aie une table. L'étape d'après, c'est une fois qu'on a fait nos mapping, nos transcodifications, on va pouvoir déplacer des records unitairement en mettant par exemple les ID des records d'un côté ou l'autre. Là, par exemple, je mettrais l'ID d'un Lead Marketo. Je mettrais un filtre. Quand il n'y a pas de données, il n'y a pas de problème. Ici, il nous dirait combien il a réussi à déplacer de records de Marketo Person vers Zoho Contact, et combien il y a eu d'erreurs. Et on pourrait aller voir les erreurs qui sont exprimées. Juste avant, ce qu'on fait d'habitude, c'est qu'on met un filtre. Je ne sais plus où on met le filtre. On mettrait sûrement le filtre ici. On mettrait un filtre au préalable en indiquant le ou les ID qu'on souhaite travailler. Et ensuite, en déplaçant… Évidemment, on ne déplacerait que les records qu'on a soigneusement choisis. On ne déplacerait pas tout. Ce qui nous permettrait de travailler et de voir toutes les erreurs, une à une, et de les corriger. Un point intéressant ici, c'est qu'on a les vTools qui peuvent être utilisés dans l'intégration. C'est particulièrement utile, par exemple quand on va insérer une opportunité. Donc l'opportunité, quand elle va arriver dans Marketo, elle va avoir un ID Marketo. Ensuite, le flux Opportunity Contact Role doit utiliser cet ID Opportunity qui vient d'être créé et qui n'existe pas dans la table source évidemment. On va pouvoir dire : j'ai cet Opportunity Contact Role à mettre dans la table de lien entre Opportunity et Contact. Va d'abord regarder l'Opportunity que je te donne, trouve-moi l'ID Marketo. On va ainsi pouvoir créer le Record sur la table de connexion a vec l'ID de l'Opportunity qui est l'ID Marketo, quand on ne peut pas avoir connaissance avant de le regarder. Et puis, l'ID de la personne, pareil, qu'on va aller chercher Marketo. C'est assez intéressant parce que ça nous évite de rapatrier tous les ID Marketo de l'autre côté pour pouvoir créer les tables de jointure, par exemple, les foreign keys. C'est un peu technique, mais ceux qui auront déjà travaillé avec les foreign keys savent de quoi je parle. C'est assez pratique. Voilà pour la présentation. C'est assez simple. Moi, ce que j'apprécie, c'est que c'est très direct en termes de paramétrage. Évidemment, ensuite, il faut automatiser les flux, une fois qu'on est content. J'ai oublié la partie la plus importante. Donc ici, on va scheduler tous les flux. Et on va dire : voilà les flux, dans quel sens il faut les jouer, à quelle heure, tous les combien on les joue, à qui on envoie les e-mails d'alerte. Et ce qui est top, c'est que Vertify va garder en mémoire les erreurs et va tenter de rejouer les flux tant qu'il y a des erreurs. C'est assez pratique par rapport aux intégrations natives où, dès qu'il y a une erreur, on arrête et on oublie. Ce qui fait qu'il faut manuellement retrouver quelles sont les personnes qui n'ont pas été synchronisées et rejouer le flux. Ici, on a vraiment la maîtrise… Encore une fois, je suis désolé, je ne peux pas vous montrer parce que je n'ai pas de données. On va avoir la maîtrise des Records qui n'ont pas passé par flux. On pourra corriger… On aura une alerte qui nous indiquera qu'il y a eu ce souci, on pourra corriger. Et on sera assuré que Vertify passera le flux juste après. Je suis sûr que vous êtes intéressé par la partie pricing. Il y a des prix par pack. Ça commence à 13 000 dollars à l'année. C'est en fonction des personnes que vous avez en base. Jusqu'à 100 000 personnes, c'est 13 000 dollars pour une intégration de deux systèmes. Sans limite de users, et avec 20 heures d'implémentation incluses. Une fois qu'on est au-dessus, 100 000-400 000, on passe au pack au-dessus et ainsi de suite. C'est un forfait annuel. Vertify sera très heureux de discuter avec vous des différentes personnalisations des packs. Si vous avez des questions, n'hésitez pas à me contacter. Merlin-Léonard est partenaire Vertify pour la France et l'Europe. On sera très heureux de vous aider sur votre projet d'intégration si vous souhaitez avancer. À très vite !