Intégrations API

Intégrations API et systèmes WordPress

WordPress est rarement seul. Dans la plupart des plateformes que nous construisons, il est la couche de présentation et d’édition par-dessus des données qui font autorité ailleurs : un CRM, un système de membres, une plateforme interne, l’API d’un partenaire. Bien poser cette relation est ce qui garde le site exact sans demander à personne de tenir deux fois le même enregistrement.

  • Écrites sur des API documentées, dans du code que nous possédons et pouvons déboguer
  • Mise en cache, limites de débit et comportement défini quand l’autre système est hors service
  • Authentification faite correctement : comptes de service et échange de jetons, pas d’identifiants en base
  • Une seule source qui fait autorité par donnée, par conception
Parler de votre projet
Le principe

Un seul système de référence, pas deux copies

Le mode d’échec en intégration n’est presque jamais la connexion. C’est la duplication. Les données sont copiées dans WordPress « pour la performance », la copie est modifiée, les deux versions divergent, et en un an plus personne ne peut dire laquelle est juste. L’intégration devient alors une chose que les gens contournent plutôt qu’une chose sur laquelle ils s’appuient.

La première décision de toute intégration est donc de savoir quel système possède chaque donnée, et elle est écrite. WordPress met en cache ce qu’il lit et le présente ; il ne devient pas discrètement une seconde source de vérité. Là où WordPress fait réellement autorité (contenu éditorial, structure des pages, ce que les rédacteurs créent) il écrit vers l’extérieur aux mêmes conditions.

La deuxième décision est ce qui se passe quand l’autre système est indisponible. Toute dépendance externe sera un jour hors service, lente, limitée en débit ou renverra quelque chose d’inattendu. Une intégration qui fonctionne est ordinaire ; une qui se dégrade de façon prévisible fait la différence entre une plateforme et une démonstration.

Ce que nous connectons

Des intégrations que nous avons construites

La liste ci-dessous vient de travaux livrés plutôt que d’une matrice de compétences. Le schéma se généralise : si un système a une API documentée, il peut être intégré correctement.

API de plateformes clientes et CRM

Répertoires de courtiers, de bureaux et de franchises, données de produits et de taux, et renseignements de compte lus depuis le CRM du client et présentés sur le site public, mis en cache, paginés et tenus à jour sans ressaisie.

Paiements

Flux de paiement basés sur Stripe intégrés à des fonctions de commerce et d’abonnement sur mesure, sans pile d’extensions de commerce générique derrière.

Calendriers et prise de rendez-vous

Intégration de Google Calendar et interfaces de calendrier complètes pour des plateformes de membres et de communauté, y compris les événements récurrents et une visibilité contrôlée.

Cartes et géolocalisation

Intégrations Google Maps pour des répertoires, des zones de service et des localisateurs, construites pour se charger sans dégrader la performance ni l’accessibilité de la page.

Flux de données externes

Données tierces tirées sur un horaire par WP-Cron et présentées dans l’interface. Les données météo et de conditions dans un portail de membres en sont un exemple livré.

Recherche, analytique et consentement

Intégrations Google Search Console par compte de service, gestion des balises, et plateformes de gestion du consentement câblées pour que l’analytique respecte l’état du consentement au lieu de l’ignorer.

Calculateurs et outils

Calculateurs de taux, de paiement et d’admissibilité construits sur des données en direct plutôt que sur des tableaux codés en dur, pour que les chiffres changent quand la source change.

Points d'accès REST sur mesure

Quand une autre application doit lire ou écrire, un espace de noms sur mesure avec authentification, validation et versionnage, plutôt que d’exposer les routes par défaut en espérant.

Génération de documents

Documents PDF produits à la demande à partir des données du site, comme des factures, des confirmations et des relevés, plutôt que tenus à la main ou assemblés hors de la plateforme.

Démarrer un projet

WordPress doit parler à autre chose?

Dites-nous quels systèmes sont en jeu, lequel possède les données, et ce qui doit se passer quand l’un d’eux est indisponible. Cette conversation détermine généralement toute la forme de la construction.

Parlez-nous de votre projet
Comment nous les construisons

Les parties qui ne sont pas l’appel d’API

Des API documentées plutôt que des piles d'extensions

Un connecteur prêt à l’emploi par système devient un graphe de dépendances impossible à maintenir et une surface d’attaque. Nous écrivons sur l’API publiée, dans du code qui peut être lu, testé et débogué.

Une stratégie de cache avec invalidation

Décidée délibérément par type de donnée : ce qui est mis en cache, pour combien de temps, et ce qui le vide, pour qu’un service amont lent ne devienne jamais un site lent.

Des pannes visibles et gracieuses

Erreurs journalisées avec assez de contexte pour diagnostiquer, réessais là où réessayer est sûr, et une interface qui se dégrade vers quelque chose de sensé plutôt que vers une page vide.

Des identifiants traités correctement

Comptes de service et échange de jetons, secrets en configuration plutôt qu’en base de données ou dans le dépôt, et accès au moindre privilège pour chaque connexion.

Des tâches planifiées observables

Travaux de synchronisation avec journalisation, historique d’exécution et alertes, pour qu’une synchronisation arrêtée il y a trois semaines ne soit pas découverte par un client.

De la documentation pour le prochain développeur

Ce qui se connecte à quoi, dans quel sens, à quelle fréquence, avec quels identifiants, et ce qui arrive en cas de panne. Écrit comme un livrable.

Preuves

Des intégrations que nous avons livrées

Un CRM comme système de référence. Sur la plateforme M3 Tech, les dossiers de courtiers, de bureaux et de franchises sont synchronisés depuis le CRM BOSS du client sur une API authentifiée, les constructions Multi-Prêts et Mortgage Intelligence documentant précisément une authentification JWT. Les données de taux sont lues par province depuis la même plateforme plutôt que tenues à la main, et la recherche de courtiers s’appuie sur Google Maps avec géocodage.

Paiements et documents. iAmEvolving® utilise Stripe PaymentIntents et Subscriptions dans deux devises, avec des factures générées en PDF à la demande plutôt que tenues à jour quelque part.

Calendriers, météo et consentement. Doolittle Lake Club lit Google Calendar via FullCalendar avec export ICS, et un widget météo appelle OpenWeatherMap derrière un cache de deux minutes pour qu’une panne tierce ne puisse pas ralentir la page. Les marques M3 utilisent Didomi pour le consentement, câblé pour que l’analytique respecte l’état du consentement.

Search Console dans l’éditeur. Ce site et la plateforme iAmEvolving® lisent tous deux l’API Google Search Console par compte de service, présentant la performance par page aux rédacteurs là où ils travaillent plutôt que dans un outil séparé.

FAQ

Questions fréquentes

  • Et si le système dont nous avons besoin n'a pas d'API?

    Alors nous le disons avant que cela devienne une ligne dans une proposition. Les options réalistes sont un échange de fichiers planifié, une lecture au niveau de la base de données si l’autre système le permet, ou la construction de la surface manquante si son propriétaire coopère. Les trois sont plus fragiles qu’une API et coûtent plus cher à maintenir, et vous devez le savoir au moment de fixer le budget plutôt qu’au moment de la première panne.

  • Que se passe-t-il quand l'autre système tombe?

    C’est prévu, parce que cela arrivera. Les données en cache continuent d’être servies, la panne est journalisée avec assez de contexte pour diagnostiquer, les réessais se font là où c’est sûr, et la page se dégrade vers quelque chose de sensé plutôt que vers une erreur ou une zone vide. Décider cela pour chaque intégration fait partie de la construction, pas d’un correctif après la première panne.

  • WordPress peut-il écrire dans notre CRM, ou seulement lire?

    Les deux, si l’API de l’autre système le permet. La décision importante n’est pas le sens mais la propriété : quel système fait autorité pour chaque donnée. Nous l’écrivons dès le départ pour que WordPress ne devienne jamais discrètement une seconde source de vérité qui divergera ensuite de la première.

  • Utilisez-vous des extensions de connexion ou des services comme Zapier?

    Rarement, et jamais comme colonne vertébrale d’une plateforme. Un connecteur par système devient un graphe de dépendances que personne ne peut raisonner, un coût récurrent et une surface d’attaque. Nous écrivons sur l’API publiée, dans du code qui peut être lu, testé, journalisé et débogué, et qui vous appartient.

  • Comment les identifiants sont-ils gérés?

    Comptes de service et échange de jetons plutôt que le mot de passe d’un utilisateur, secrets en configuration plutôt qu’en base de données ou dans le dépôt, et accès au moindre privilège limité à ce dont chaque connexion a réellement besoin. Les connexions sont documentées : ce qui parle à quoi, dans quel sens, à quelle fréquence, et avec quels identifiants.

  • Comment savons-nous qu'une synchronisation fonctionne encore?

    Les tâches planifiées sont journalisées avec un historique d’exécution et des alertes. Le mode d’échec contre lequel il vaut la peine de concevoir n’est pas une synchronisation qui échoue bruyamment, c’est celle qui s’est arrêtée il y a trois semaines et qu’un client a remarquée.