« Il suffit de le connecter au système de paiement » est la phrase qui précède le plus souvent un retard de trois semaines. Le codage est rarement le problème ; ce sont le compte, l’approbation et les différences entre les environnements de test et de production qui le sont.
Pourquoi une intégration n’est pas une petite tâche
La connexion à un service externe implique davantage qu’un simple appel :
- Création et vérification du compte auprès du fournisseur, nécessitant souvent des documents commerciaux.
- Approbation ou examen avant l’octroi de l’accès à la production — en particulier pour les prestataires de paiement.
- Gestion des identifiants, séparément pour les environnements de test et de production.
- Gestion de tous les modes d’échec que le fournisseur peut générer : rejet, délai d’expiration, succès partiel, soumission en double.
- Rapprochement — faire correspondre ce que le fournisseur indique avec ce que votre application a enregistré.
- Tests sur un environnement sandbox qui se comporte différemment de la production.
Ce sont les deux derniers points qui demandent le plus d’efforts, et ils sont invisibles dans une liste de fonctionnalités.
Délais de démarrage : commencez tôt
Il s’agit de tâches liées au calendrier, et non au développement ; elles doivent commencer dès le début du projet :
- Prestataires de paiement. Les demandes de comptes marchands nécessitent une immatriculation de l’entreprise, des coordonnées bancaires et parfois un examen du modèle économique. Le délai va de quelques jours à quelques semaines, et un rejet est possible pour certaines catégories d’activités — il est donc utile de confirmer l’acceptation avant de concevoir autour d’un fournisseur.
- Services de messagerie. Les SMS nécessitent, sur de nombreux marchés, l’enregistrement de l’identifiant de l’expéditeur et l’approbation préalable des modèles, selon une procédure formelle avec sa propre file d’attente.
- Intégrations de plateformes. La connexion à un écosystème établi nécessite généralement un compte vérifié et peut impliquer un examen de votre mode d’utilisation.
- Systèmes d’entreprise. La connexion au système existant d’un client implique un accès, une documentation et un environnement de test fournis par un tiers dont vous ne contrôlez pas le calendrier. C’est régulièrement le principal facteur de retard.
La sandbox n’est pas la production
Les environnements de test sont simplifiés. Voici des différences qui apparaissent régulièrement lors du déploiement :
- Les limites de débit sont souvent absentes ou généreuses dans la sandbox, et strictes en production.
- La latence est plus faible dans la sandbox ; des délais d’expiration qui ne surviennent jamais pendant les tests peuvent donc apparaître en production.
- La variété des erreurs est plus limitée : les sandboxes produisent une poignée de scénarios, tandis que la production en produit de nombreux.
- La validation des données est parfois moins stricte dans la sandbox ; de vraies données peuvent donc être rejetées pour des raisons que les tests n’ont jamais révélées.
La mesure pratique consiste à effectuer un test de bon fonctionnement en production avant le lancement : un petit nombre de transactions réelles, avec de vrais identifiants, vérifiées de bout en bout, rapprochement compris.
Concevoir pour les défaillances qui surviendront
Une dépendance externe sera indisponible à un moment ou à un autre. La façon de réagir doit être une décision de conception, et non un accident :
- L’action de l’utilisateur échoue-t-elle ou est-elle mise en file d’attente ? Un paiement doit échouer clairement. Une notification peut être mise en file d’attente et faire l’objet de nouvelles tentatives.
- Que voit l’utilisateur ? Un message précis est bien préférable à une erreur générique et réduit la charge du support.
- L’opération peut-elle être relancée sans risque ? Les API de paiement et de messagerie prennent généralement en charge une clé d’idempotence afin qu’une requête relancée ne déclenche pas deux débits. Son utilisation n’est pas facultative pour toute opération impliquant de l’argent.
- Comment le découvrir ? Les erreurs d’une intégration doivent être consignées et signalées, et non ignorées silencieusement.
Versionnement et modification non effectuée
Les fournisseurs modifient leurs API. Les versions sont obsolétées avec un préavis, et celui-ci est envoyé par e-mail à la personne qui a enregistré le compte — une raison supplémentaire pour laquelle le client devrait en être propriétaire.
Deux habitudes permettent d’éviter la panne qui en découle : verrouiller une version précise de l’API plutôt que de suivre automatiquement la dernière version, et s’assurer que l’adresse de notification du compte parvient à une personne qui interviendra. Une intégration qui cesse de fonctionner parce qu’une version obsolète a été retirée selon un calendrier publié constitue une défaillance évitable.
Coût
Les services tiers facturent généralement à l’usage, ce qui représente souvent le coût récurrent le plus important d’une petite application. Il est utile d’établir au préalable :
- Le modèle tarifaire — par transaction, par message, par appel API, par utilisateur actif.
- L’existence éventuelle d’une offre gratuite et ce qui se passe lorsqu’elle atteint sa limite.
- La manière dont le coût évolue avec dix fois le volume d’utilisation actuel.
- L’existence éventuelle de minimums ou d’engagements mensuels.
Une intégration d’IA ou de messagerie peu coûteuse à l’échelle d’un pilote peut devenir le principal coût d’exploitation à grande échelle ; le découvrir à l’avance peut donc modifier le choix du fournisseur.
Services Manboo associés
- Développement d’applications Flutter pour les MVP iOS et Android.
- Développement de logiciels métier pour les CRM, les systèmes de réservation, de gestion des stocks et de gestion des workflows.
- Développement de panneaux d’administration pour les tableaux de bord opérationnels et la gestion du backend.
- Intégration d’API d’IA lorsque votre produit est prêt pour la recherche intelligente, le chat ou l’automatisation.
- Demander un examen du périmètre et une estimation du projet lorsque vous êtes prêt à planifier la première version.