Intégrer un outil SaaS : gardez votre système interne comme orchestrateur

Deux façons de brancher un outil SaaS à votre système, une seule qui tient dans la durée

Intégrer un outil SaaS externe à un système interne se joue toujours sur la même décision d'architecture : qui déclenche l'action, votre système ou l'outil externe ? Un outil d'automatisation marketing, un CRM, un service de notification, peut techniquement piloter lui-même le déclenchement d'une action via un webhook qu'il appelle quand bon lui semble. L'alternative consiste à faire l'inverse : un mécanisme interne, un cron job qui interroge régulièrement la base de données, appelle l'outil externe au moment choisi, jamais l'inverse.

La première option est plus rapide à mettre en place. La seconde est plus lourde à développer, elle impose de maintenir une couche de service supplémentaire. C'est pourtant la seconde qui protège durablement votre capacité à comprendre votre propre système.

Cette décision se prend rarement de façon explicite. La plupart du temps, elle se règle par défaut, au fil de la documentation technique de l'outil SaaS choisi : si le mode webhook est mis en avant comme la solution « simple » et l'API interrogeable reléguée en option avancée, l'équipe qui intègre l'outil suit naturellement le chemin le plus court. Personne n'a tranché consciemment que l'outil externe deviendrait le déclencheur. C'est arrivé parce que c'était le chemin de moindre résistance au moment de l'intégration, pas parce que c'était le bon choix d'architecture pour les mois suivants.

Le chef d'orchestre : pourquoi le contrôle compte plus que la simplicité apparente

Face au choix entre laisser un outil tiers orchestrer des notifications automatiques ou garder cette orchestration dans son propre backend, l'option la plus lourde techniquement a été préférée, pour une raison qui n'a rien à voir avec la performance ou la simplicité de mise en œuvre. Si l'orchestration est déléguée à l'outil externe, l'équipe perd la capacité de loguer, diagnostiquer et expliquer un dysfonctionnement depuis un seul endroit. Le risque n'est pas technique, il est dans l'incapacité à rendre des comptes quand quelque chose ne fonctionne pas.

« J'aime bien penser que Customer.io, c'est une source de données, c'est un trigger ou une réaction. J'aime bien garder le fait que notre app soit au centre, parce que si jamais il y a un souci, on va pouvoir loguer et tracer tous les soucis. »

Ce qui se passe le jour où l'intégration casse

Un système distribué ne se juge pas sur son fonctionnement en conditions normales, il se juge sur ce qu'il devient le jour d'un incident. Si l'outil externe pilote le déclenchement, la première question en cas de problème est « est-ce que le webhook est bien parti, et où ? », une question à laquelle seul le support du prestataire peut répondre, avec ses propres délais. Si le système interne pilote l'appel, la même question se résout en consultant ses propres journaux, immédiatement, sans dépendre d'un tiers.

Cette différence se mesure directement en délai de résolution. Un incident diagnostiqué en interne se règle en général dans l'heure, parce que la personne qui investigue a accès à l'intégralité de la chaîne de logs. Un incident qui dépend d'un ticket ouvert chez un prestataire externe suit le rythme du support de ce prestataire, souvent quelques heures dans le meilleur des cas, parfois plusieurs jours si le sujet sort des cas standards documentés. Pour un client qui attend une confirmation ou une notification, cette différence de délai se voit, et se retient.

Concevoir l'intégration comme un cron job, pas un webhook subi

Ce principe, que l'on peut nommer le chef d'orchestre, ne consiste pas à refuser tout webhook entrant par principe. Il consiste à décider consciemment, pour chaque intégration qui déclenche une action métier, qui doit rester le point de départ : votre système, qui sait pourquoi et quand une action doit se produire, ou l'outil externe, qui ne connaît que sa propre logique interne, souvent optimisée pour son cas d'usage générique, pas pour le vôtre.

Ce que ce choix coûte, et pourquoi ça vaut le coup

Concrètement, un cron job interne qui interroge la base de données à intervalle régulier, puis appelle l'API de l'outil externe seulement quand une condition métier est remplie, demande une couche de service supplémentaire à concevoir, tester et maintenir. Ce coût d'développement initial se rembourse à la première anomalie : retrouver, dans ses propres journaux, qu'une notification n'est pas partie parce qu'une donnée attendue était absente, prend quelques minutes. Reconstituer la même information depuis l'historique d'un outil tiers, sans accès à sa logique interne, peut prendre des jours, voire rester tout simplement impossible.

Cette même logique de maîtrise s'applique à la donnée elle-même, pas seulement au déclenchement : notre article sur la délégation de la capture de données sensibles à un prestataire SaaS détaille où, à l'inverse, laisser un outil externe faire le travail plutôt que de le recréer en interne.

Le bon test avant de choisir entre les deux architectures n'est pas la simplicité de mise en œuvre, c'est la question de la partie responsable en cas d'échec. Si un client ne reçoit pas une confirmation attendue, qui doit expliquer pourquoi : votre équipe, ou le support d'un éditeur tiers qui n'a jamais rencontré ce client ? Poser cette question avant de choisir l'architecture d'intégration évite de la découvrir a posteriori, au moment où un client mécontent attend justement une réponse rapide.

Ce que ce principe exclut

Garder le système interne comme orchestrateur ne veut pas dire recoder soi-même toutes les fonctions qu'un outil SaaS propose déjà. Un outil de marketing automation reste plus pertinent qu'un développement interne pour construire des scénarios de relance ou gérer des templates d'emails. Le principe porte uniquement sur le point de déclenchement des actions qui touchent une donnée métier ou un client, pas sur l'ensemble des fonctionnalités de l'outil. Confondre les deux mène à sur-développer en interne des fonctions que l'outil externe fait déjà très bien, ce qui annule l'intérêt même de l'avoir choisi.

La frontière se trace au niveau de la responsabilité métier, pas au niveau technique. Un outil SaaS peut composer un email, choisir un moment d'envoi, gérer un template visuel : ce sont des compétences que peu d'équipes internes ont intérêt à reconstruire. Mais la décision de savoir si cet email doit partir, pour quel client, à quel instant précis en fonction d'un état métier propre à votre activité, reste une question que seul votre système peut trancher correctement, parce que lui seul détient la donnée qui justifie la décision. Le coût caché de ce type d'arbitrage mal posé est détaillé dans notre article sur le coût caché de l'interopérabilité entre outils.

Le signal qui indique que vous avez perdu la main sur votre système

Le signal n'est pas le nombre d'outils SaaS connectés à votre système, c'est votre capacité à répondre, en moins de cinq minutes, à la question : pourquoi cette action ne s'est-elle pas déclenchée pour ce client précis ? Si la réponse nécessite d'ouvrir un ticket de support chez un prestataire externe, votre système a perdu son rôle d'orchestrateur, même s'il reste techniquement au centre de votre activité. Ce type de zone d'ombre se retrouve aussi fréquemment lors d'une intégration API mal préparée en amont, un sujet approfondi dans notre article sur les pièges classiques d'une intégration API.

Ce test se répète naturellement à chaque nouvel outil SaaS ajouté au système, et c'est précisément là que le principe s'use le plus vite. La première intégration se pense avec soin. La cinquième, ajoutée dans l'urgence pour répondre à un besoin ponctuel, hérite souvent du mode webhook par défaut, parce que personne ne prend le temps de revenir sur une décision d'architecture déjà posée ailleurs. Au bout de quelques outils connectés de cette manière, le système censé orchestrer l'activité ne sait plus lui-même qui déclenche quoi, et chaque nouvel incident redevient une enquête à mener de zéro.

Avant votre prochaine intégration avec un outil SaaS qui déclenche une action pour vos clients, tranchez explicitement qui appelle qui, et documentez ce choix comme une décision d'architecture à part entière, pas comme un détail technique laissé à l'appréciation de celui qui code l'intégration.