My Geocode

Migration

Migrer une automatisation Zapier ou Make vers un nouvel hôte de géocodage

· 3 min de lecture · My Geocode · #zapier#make#automatisation#no-code#géocodage#migration

Les automatisations construites dans Zapier ou Make comportent souvent une étape de géocodage nichée dans un workflow plus large : un nouveau prospect arrive via un formulaire, son adresse est géocodée pour vérifier l'attribution du secteur, et le résultat déclenche une décision de routage plus loin dans la chaîne. Ces workflows sont souvent construits par une personne sans formation en génie logiciel, avec le connecteur d'application prêt à l'emploi ou le module HTTP générique que la plateforme proposait à l'époque, ce qui change la forme réelle d'une migration par rapport à un code sur mesure.

Si votre étape de géocodage actuelle utilise un connecteur d'application dédié, c'est-à-dire une intégration officielle construite par Zapier ou Make spécifiquement pour le fournisseur en question, migrer vers un fournisseur sans connecteur dédié équivalent implique de remplacer cette étape par un module HTTP ou webhook générique, configuré pour appeler directement l'API du nouveau fournisseur. C'est un vrai changement dans la construction de l'automatisation, et pas un simple remplacement d'identifiants, et il vaut la peine de tester minutieusement l'étape de remplacement dans un scénario de test isolé avant de toucher à une automatisation de production active dont dépendent d'autres parties de l'entreprise.

Étapes précises pour effectuer ce changement :

  1. Dupliquez l'automatisation existante dans l'éditeur de la plateforme au lieu de la modifier directement, afin que la version fonctionnelle continue de tourner jusqu'à ce que la version de remplacement soit entièrement testée
  2. Remplacez l'étape de géocodage par un module HTTP générique, configuré avec l'endpoint et l'authentification du nouveau fournisseur, car une clé en paramètre de requête ou un en-tête Authorization: Bearer (tous deux pris en charge ici) se configure simplement dans un module HTTP générique, sans connecteur dédié
  3. Faites correspondre manuellement les champs de la réponse dans l'étape de mappage des données de l'automatisation, car un module HTTP générique renvoie des données de réponse brutes qui doivent être explicitement associées aux champs qu'attendent les étapes suivantes de l'automatisation, contrairement à un connecteur dédié qui effectue souvent cette correspondance automatiquement
  4. Testez avec un éventail d'entrées réelles, y compris des cas limites comme des adresses partielles ou un formatage inhabituel, car c'est exactement le type de test facile à négliger dans un outil no-code où le « code » lui-même n'est pas visible pour une relecture comme le serait un script
  5. Basculez le déclencheur de la version de test vers l'automatisation dupliquée et vérifiée, puis ne désactivez l'originale qu'après avoir confirmé que la nouvelle fonctionne correctement sur des données réelles pendant une courte période

Comme un hôte compatible reproduit le format de réponse exact d'un fournisseur familier, si l'étape de géocodage de votre automatisation d'origine appelait un fournisseur pour lequel il existe ici un hôte compatible correspondant, la correspondance des champs de l'étape 3 ci-dessus peut ressembler de près à celle que votre connecteur d'origine utilisait déjà en interne, ce qui peut sensiblement raccourcir cette migration. La liste complète des hôtes compatibles se trouve sur /compatibility/ ; consultez-la avant de supposer qu'une correspondance des champs à partir de zéro est nécessaire.

Pour une automatisation critique pour l'activité, la prudence supplémentaire consistant à tester dans une copie plutôt qu'à modifier la version active vaut le peu de temps de configuration en plus, car une automatisation de routage des prospects défaillante est généralement remarquée rapidement, et par des personnes extérieures à l'équipe technique.

Plus d'articles sur la migration