Caroline B.
Cheffe de marques
Intégration d’une API tierce
Un fournisseur, un partenaire ou une plateforme publique expose des données que vos équipes recopient encore à la main. Nous développons l'intégration d'une API tierce dans votre application, de la lecture de la documentation jusqu'au comportement de votre outil le jour où le fournisseur ne répond plus.
15 ans
d'expérience
250+
missions réalisées
+30
projets en activité
100%
sur-mesure
Ils nous font confiance
LE CONSTAT
Intégrer une API tierce, c'est hériter des règles d'un autre
Une API tierce arrive dans votre projet avec ses règles déjà écrites. Son propriétaire décide du format des données, du rythme des appels autorisés, de la durée de validité d’un accès et de la date à laquelle une version cesse d’être maintenue. Vous héritez de ces décisions sans avoir participé à aucune d’entre elles. C’est la différence de fond avec un développement interne, où chaque contrainte se négocie.
Cette dépendance se remarque rarement à la mise en service. Les premiers appels fonctionnent, les données remontent, le projet passe en production. Les difficultés arrivent plus tard, sur des événements que personne n’avait mis au planning. Un jeton d’accès arrive à échéance et le flux s’arrête sans avertir personne. Le fournisseur publie une nouvelle version et annonce une date d’arrêt pour l’ancienne. Un pic d’activité chez vous dépasse le quota d’appels et le service commence à refuser les requêtes.
Une intégration prend aussi une place particulière dans votre organisation. Elle relie deux systèmes que rien n’obligeait à se comprendre, avec deux vocabulaires différents pour désigner la même chose. Un client chez vous porte un numéro interne, chez votre fournisseur un identifiant que vous ne choisissez pas. Une commande a cinq statuts dans votre outil, trois chez lui. Cette traduction constitue le vrai contenu du travail, bien plus que l’appel technique lui-même.
Le résultat se voit pourtant très vite chez vos équipes. Un commercial voit la situation de facturation d’un client sans ouvrir le portail du prestataire. Un gestionnaire retrouve un numéro de suivi directement dans le dossier. Une adresse se vérifie à la saisie plutôt qu’à la livraison. Ces gains tiennent uniquement si l’intégration résiste aux mauvais jours, et c’est ce que nous construisons quand nous intervenons pour faire dialoguer vos outils.
Vous vous reconnaissez ?
Ce qui déclenche une intégration d'API tierce
Sept configurations où un service extérieur détient une donnée que votre outil devrait afficher.
Un partenaire vous impose son API
Un donneur d'ordre, une centrale ou une marketplace conditionne la relation commerciale au branchement sur sa propre interface, avec son calendrier.
Vos équipes travaillent dans le portail du fournisseur
L'information existe chez le prestataire, elle se consulte écran par écran, et personne ne la retrouve dans l'outil où le travail se fait vraiment.
Vous payez un accès que personne n'exploite
Votre abonnement inclut une interface programmable ouverte et jamais utilisée, sans équipe pour la raccorder à votre outil.
Une échéance réglementaire impose le raccordement
Facturation électronique, télétransmission, déclaration à un organisme : le raccordement à une plateforme extérieure arrive avec une date d'application fixée par un tiers.
Vos fiches s'enrichissent à la main depuis des sources publiques
Numéro SIREN, forme juridique, adresse normalisée, données cadastrales : quelqu'un recopie ce que des API officielles publient déjà.
Votre automatisation actuelle casse à chaque changement
Un script interne ou un scénario monté sans documentation s'arrête dès que l'éditeur modifie un champ, et personne ne sait pourquoi avant la réclamation.
Votre application doit rendre un service qu'elle ne produit pas
Paiement, signature électronique, envoi de courrier recommandé, calcul d'itinéraire : ces fonctions s'achètent chez des spécialistes et se raccordent.
Dans ces sept cas, la donnée ou le service existe déjà chez un tiers, et votre outil ne sait pas encore aller le chercher. Le travail d’intégration suppose un outil capable d’afficher la donnée reçue, de la contrôler et de la rendre exploitable. Nous concevons cet outil, une application web métier construite pour recevoir ces flux.
NOS SERVICES
Tout ce que nous développons pour intégrer une API tierce
L'appel qui récupère la donnée représente une petite part du travail. Voici les éléments que nous développons, y compris ceux qui se remarquent uniquement un jour de panne. Quand les données récupérées servent au pilotage, elles alimentent aussi votre tableau de bord sur mesure.
Étude de la documentation éditeur
Lecture complète des points d'entrée, des formats et des limites annoncées avant tout chiffrage.
Authentification et stockage des secrets
Clés d'API, OAuth2, certificats : accès chiffrés, jamais posés en clair dans le code.
Correspondance des champs
Traduction entre le vocabulaire de l'éditeur et le vôtre, dans les deux sens quand l'échange est bidirectionnel.
Réception d'événements
Webhooks entrants sécurisés, ces appels que le service déclenche vers vous dès qu'une donnée change.
Cadencement des appels
Respect des quotas annoncés, étalement des traitements lourds, mise en cache des données stables.
Reprise automatique après échec
Nouvelle tentative espacée, file d'attente des appels non aboutis, garantie qu'un même envoi ne parte pas deux fois.
Journal des appels et des réponses
Trace horodatée de chaque échange, consultable sans nous appeler, avec le détail de l'erreur renvoyée.
Environnement de test
Recette sur le bac à sable de l'éditeur quand il en propose un, avec un jeu de données proche du réel.
Mode dégradé
Comportement défini à l'avance quand le service extérieur ne répond pas, plutôt qu'un écran bloqué.
Alertes d'expiration
Notification avant échéance d'un jeton, d'un certificat ou d'un consentement, avant que le flux s'arrête.
Couche d'isolation
Vos écrans et vos traitements ignorent d'où vient la donnée, ce qui rend le changement de prestataire possible sans tout réécrire.
Restitution dans vos écrans
Les données reçues apparaissent là où le travail se fait, avec la date de dernière mise à jour.
Nos dernières réalisations
Toutes nos réalisations 4,8
CE QU'ILS EN DISENT
Nous avons aidé des dizaines de clients dans leur transformation digitale
-
Equipe très à l'écoute, dynamique, réactive, de très bons conseils, très pro, à la fois très techniques mais qui sait aussi se mettre à la place de personnes non averties.
-
Laurence V.
Directrice Marketing
Nous ne pouvons que nous féliciter de notre choix d'agence web : une équipe sympathique, à l'écoute, professionnelle, rigoureuse, technique... présente tout en respectant nos contraintes.
-
Mirela O.
Reponsable Marketing
À l'écoute, disponibles et très créatifs, ils comprennent rapidement les besoins de leurs clients et leurs conseils sont opportuns.
-
Tiffany V.
Responsable Communication
Bonne compréhension des enjeux et attentes, couplée à de la créativité : tout est fluide. J'apprécie leur accompagnement, leur prise en charge et la disponibilité des équipes.
Quel service extérieur voulez-vous raccorder à votre outil ?
Donnez-nous le nom du service et l’usage que vous en attendez, nous vous disons ce qu’il autorise réellement.
Lire la documentation de l'API avant de fixer le sens de l'échange
-
Nous lisons la documentation du fournisseur et nous listons ce qu'elle expose vraiment. Nous fixons le sens de l'échange, les données concernées, la fréquence utile et le comportement attendu en cas d'indisponibilité. Ces réponses cadrent le périmètre technique avant tout chiffrage.
-
Nous maquettons les écrans où la donnée extérieure apparaît, et surtout ceux où elle manque : information non encore reçue, échange en erreur, valeur datée de la veille. Vos utilisateurs se prononcent sur ces états pendant la maquette, quand les corriger coûte encore peu.
-
Nous distinguons visuellement ce qui vient de chez vous et ce qui vient de l'extérieur. Une donnée reprise à l'extérieur porte sa source et son horodatage, pour qu'aucun utilisateur ne la corrige dans le mauvais système.
-
Nous développons le connecteur, l'authentification, la reprise sur erreur et le journal des appels. Nous testons sur l'environnement de recette du fournisseur, puis nous ouvrons le flux en production sur un périmètre réduit avant de l'étendre. À la livraison, vous recevez le code du connecteur, une documentation de son fonctionnement et une passation avec l'équipe qui devra vivre avec au quotidien.
-
Nous surveillons les erreurs renvoyées et nous anticipons les échéances techniques. Quand le fournisseur annonce une nouvelle version ou change un format, nous adaptons le connecteur avant la date d'arrêt de l'ancienne. Une fois le connecteur livré, ce travail de veille et d'adaptation n'entre plus dans le forfait de développement : il se poursuit dans le cadre d'un contrat de maintenance et d'évolution séparé, à mettre en place si vous voulez que quelqu'un continue de s'en occuper après la mise en production.
Sept réponses avant de lancer votre intégration d'API tierce
La charge dépend de quatre facteurs, que nous évaluons avant de vous répondre. La qualité de la documentation d’abord : une API bien documentée avec un environnement de test coûte moins cher à intégrer qu’un service dont la documentation se limite à quelques exemples d’appels. Le sens de l’échange ensuite : lire des données coûte moins cher que d’en écrire, parce qu’une écriture engage la responsabilité des deux systèmes. Le volume de champs à faire correspondre compte autant, surtout quand vos statuts et les siens ne se superposent pas. Enfin, le délai d’obtention des accès dépend du fournisseur seul, et certaines habilitations demandent plusieurs semaines d’instruction. Une fois ces quatre facteurs pesés, une intégration se situe le plus souvent de l’ordre de quelques semaines à quelques mois, chiffré précisément au cadrage de votre cas.
.Ce cas se découvre à la lecture de la documentation, avant l’engagement, et c’est une des raisons pour lesquelles nous commençons par là. L’éditeur propose parfois la donnée sur un autre point d’entrée, moins visible dans sa documentation, et nous l’utilisons. Ailleurs, la donnée existe chez lui sans être exposée, et nous la demandons via son support, ce qui aboutit dans une partie des cas. Ou elle n’existe pas, et votre outil la gère alors de son côté, avec un champ que vos équipes renseignent une seule fois plutôt qu’à chaque dossier. Nous vous disons laquelle de ces trois situations s’applique avant de chiffrer.
.Souvent, oui, et cette ligne budgétaire vous revient directement. Les modèles varient : accès inclus dans votre abonnement existant, palier mensuel selon le volume d’appels, tarification à l’appel, ou gratuité totale sur les API publiques comme celles de l’administration. Nous relevons ce coût pendant l’étude et nous concevons le connecteur pour le contenir, en évitant les appels inutiles et en conservant localement ce qui bouge peu. Un connecteur mal conçu interroge le fournisseur à chaque affichage d’écran, et la facture le montre dès le premier mois.
.Cela dépend du sens de l’échange, et nous le cadrons explicitement. Une API consultée en lecture reçoit une requête et vous renvoie un résultat : vous transmettez un critère de recherche, rien de plus. Un service qui traite vos dossiers, à l’inverse, reçoit des données personnelles, ce qui fait du fournisseur un sous-traitant au sens du RGPD. Nous limitons alors les champs transmis au strict nécessaire, nous documentons ce qui sort dans votre registre de traitements, et nous vérifions ce que le contrat du fournisseur dit de la conservation et de la localisation de ces données.
.Une refonte se justifie rarement. L’ajout tient sur une application existante à deux conditions : que son code soit accessible et qu’il accepte une modification sans effet de bord incontrôlé. Nous auditons ce point avant de nous engager. Sur un logiciel du marché fermé, l’ajout passe par ce que l’éditeur autorise, et parfois par un outil intermédiaire qui parle aux deux côtés. Sur une application développée sur mesure, même par une autre équipe, le connecteur s’ajoute comme un module, sans toucher au reste du fonctionnement.
.Techniquement, oui : une plateforme de facturation se raccorde comme n’importe quel service extérieur, avec ses formats imposés et son propre calendrier. La réforme fixe une première échéance au 1er septembre 2026 : recevoir une facture électronique devient obligatoire pour toute entreprise redevable de la TVA, quelle que soit sa taille, et ce raccordement passe par une plateforme agréée. Le portail public n’assure plus l’émission ni la réception depuis la décision annoncée par la DGFiP en octobre 2024, il conserve l’annuaire des entreprises et la transmission des données à l’administration. Côté intégration, trois chantiers se distinguent : le dépôt de vos factures au format attendu, la récupération de celles qui vous arrivent, et le traitement des statuts que la plateforme renvoie document par document. Le troisième demande le plus de travail. Une facture rejetée doit revenir dans votre outil avec son motif et son numéro, sous les yeux de la personne qui l’a émise, plutôt que de finir dans un accusé que personne n’ouvre. Le choix de la plateforme et le contrat qui va avec restent les vôtres, nous raccordons celle que vous avez retenue. La fabrication des documents eux-mêmes relève d’un autre travail, détaillé sur notre page consacrée à l’application avec génération de documents PDF.
.Un outil de connexion du marché suffit tant que l’échange porte sur peu de champs et peu d’opérations. Le calcul change quand la traduction entre les deux systèmes demande vos règles métier, quand un échange raté doit se rattraper seul, ou quand le nombre d’opérations mensuelles fait grimper l’abonnement de l’intermédiaire au-dessus du coût d’un développement. Nous regardons d’abord ce que vous échangez et à quelle fréquence, et nous vous le disons quand une solution existante tient encore le besoin.
. POUR ALLER PLUS LOIN
Les contraintes d'une API tierce, et ce que nous en faisons
Le jeton qui expire, le quota qui se ferme, la version qui change et la panne du fournisseur ont déjà été nommés plus haut comme les risques d’une intégration. Voici, pour chacun, le mécanisme précis et la décision technique qu’il impose.
Ce que nous lisons dans une API avant de nous engager
La documentation d’un éditeur tient lieu de cahier des charges, écrit par quelqu’un d’autre. Nous y cherchons quatre choses en priorité : la liste réelle des points d’entrée, le format exact des données renvoyées, les limites annoncées, et la présence d’un environnement de test. Ce dernier point change le déroulé du projet. Un fournisseur qui propose un bac à sable ouvre le développement et la recette sur des données factices, à distance de vos dossiers réels et de ceux de vos clients.
Le délai d’obtention des accès, l’un des quatre facteurs qui pèsent sur la durée du projet, se vérifie au même moment. L’API Entreprise, par exemple, s’adresse aux acteurs investis d’une mission de service public et suppose une habilitation instruite dossier par dossier, là où l’API Sirene s’ouvre en accès libre en quelques minutes. Cette instruction se lance dès le début du projet, en parallèle des développements.
Les accès expirent, l’intégration doit le prévoir
Un accès à un service extérieur a une durée de vie. Un jeton OAuth2, délivré au terme d’une autorisation donnée une première fois, se renouvelle ensuite tout seul tant que son jeton de rafraîchissement reste valide, puis expire à son tour. Un certificat client arrive à échéance à une date fixe. Une clé d’API se révoque le jour où l’administrateur qui l’avait créée quitte l’entreprise.
Certains secteurs imposent une échéance supplémentaire. Sous la DSP2, quand un prestataire d’agrégation accède aux comptes bancaires de votre client, l’exemption d’authentification forte dure cent quatre-vingts jours. Passé ce délai, le client doit se ré-authentifier auprès de sa banque, sinon la récupération des opérations s’arrête. Une fois l’intégration en production, cette surveillance des échéances relève du contrat de maintenance évoqué plus haut, pas du forfait de développement initial : nous prévenons avant le terme, plutôt que de laisser une équipe découvrir la coupure en cherchant pourquoi un dossier ne se met plus à jour.
Concevoir en fonction du quota d’appels
Chaque service limite le nombre d’appels qu’il accepte. Au dépassement, elle renvoie un code 429, littéralement trop de requêtes, et refuse de répondre jusqu’à la fenêtre suivante. Ces plafonds varient fortement d’un service à l’autre : l’API Sirene de l’Insee annonce trente requêtes par minute en usage ouvert. Le compteur se tient par compte client et non par utilisateur, ce qui fait qu’un traitement de masse lancé le matin peut priver vos équipes du service dans la journée.
Nous tenons compte de ces plafonds dès la conception. Les données qui bougent peu se conservent chez vous avec leur date de récupération. Les traitements de masse s’étalent par lots, à cadence contrôlée. Les appels déclenchés par une action utilisateur passent avant les traitements de fond. Ce travail de cadencement fait partie de tout projet d’interconnexion d’outils, et il devient déterminant dès que plusieurs API se partagent la même application.
Le jour où l’éditeur change sa version
Une API évolue sans vous demander votre avis. Certains éditeurs publient une nouvelle version en maintenant l’ancienne un temps, et annoncent à l’avance la date d’arrêt de celle que vous utilisez. D’autres modifient un champ sans prévenir, et le flux s’arrête sans explication.
Contre la première, une veille régulière suffit, assurée elle aussi dans le cadre de ce même contrat de maintenance : nous lisons les annonces publiées et nous planifions la migration dans la fenêtre annoncée. Contre la seconde, nous protégeons l’outil par son architecture. Une couche d’isolation entre le service extérieur et vos propres traitements concentre l’adaptation en un seul endroit du code, au lieu de la disséminer partout où la donnée est utilisée. Le jour du changement, la correction porte sur quelques fichiers plutôt que sur l’ensemble de l’outil, et le remplacement pur et simple du fournisseur redevient une option réaliste.
Ce que devient votre outil quand l’API ne répond plus
Un service extérieur tombe, c’est une certitude à l’échelle de plusieurs années. Une question se pose alors à la conception : que fait votre application pendant ce temps ? Trois comportements existent, et le choix se fait donnée par donnée. La donnée se lit dans une copie locale, datée, avec la mention de son ancienneté. L’action attend dans une file et repart automatiquement au retour du service. Ou l’opération se bloque, parce qu’un paiement non confirmé ne doit surtout pas être considéré comme reçu.
Dans les trois cas, l’utilisateur doit savoir ce qui se passe. Un message qui annonce « donnée du fournisseur indisponible depuis dix heures ce matin » lui laisse le choix d’attendre ou de téléphoner. Devant un champ vide et sans explication, il appelle le support ou saisit une valeur approximative, et cette valeur restera dans vos dossiers longtemps après le rétablissement du service. Nous maquettons et validons ces états au même titre que les écrans nominaux.
Le connecteur est à vous, l’API reste à eux
Le connecteur développé pour raccorder cette API vous appartient intégralement, code source compris. Le détail de ce que cette propriété change concrètement, ce que vous pouvez faire évoluer seul et ce qui reste hors de votre portée, se trouve sur la page Faire dialoguer vos outils. L’API elle-même, elle, reste la propriété de son éditeur, qui garde la main sur ses règles jusqu’au bout.
