Ce que le mot « intégration » ne dit pas dans votre devis

Ligne 7 de la proposition : « Intégration avec votre outil de facturation ». Colonne de droite : inclus. Vous relisez la ligne, elle vous paraît claire, vous hochez la tête. Les deux personnes en face de vous hochent la tête également. On passe à la ligne 8.

Personne dans la pièce ne ment. Personne dans la pièce ne parle exactement de la même chose.

Quelques mois plus tard, un client vous appelle : il n'a jamais reçu sa facture. Vous vérifiez, il n'est pas le seul, et la situation dure depuis plusieurs semaines. Rien ne s'est affiché en rouge. Aucune alerte n'est partie. Votre prestataire ne l'a pas vu non plus, parce que personne ne lui avait demandé de regarder.

Cette ligne de votre devis recouvre au moins quatre situations qui n'engagent ni le même travail, ni le même risque, ni la même personne le jour où l'échange s'interrompt. Le flou n'est presque jamais un mensonge : c'est un terrain d'entente commode. Votre prestataire n'a pas envie de détailler, vous n'avez pas envie de demander, et la réunion avance.

Vous n'avez pas besoin de comprendre la technique. Vous avez besoin d'une dizaine de mots et de trois questions, posées calmement, sur la ligne du devis.

Trois questions décrivent n'importe quel échange entre deux logiciels

Deux logiciels qui se parlent, cela se raconte entièrement avec trois informations. Chacune tient en une ligne, et ensemble elles suffisent à vous écrire un devis lisible.

Qui appelle qui. L'un des deux outils prend l'initiative, l'autre répond. Ce n'est pas symétrique. Si votre site interroge votre logiciel de facturation, ce logiciel doit être joignable depuis l'extérieur et accepter d'être interrogé. Dans l'autre sens, les conditions changent. Retenez surtout ceci : celui qui appelle est celui qui constate la panne. Vous posez donc une question de responsabilité, pas une question d'ingénierie.

Dans quel sens circule la donnée. Trois cas, pas un de plus. Le premier outil lit ce que détient le second sans jamais y écrire. Il y écrit. Ou les deux s'écrivent mutuellement — et vous devez alors décider lequel a raison quand les deux versions divergent. Ce troisième cas est le plus coûteux pour vous, et c'est celui que le mot « synchronisation » désigne sans le nommer.

Qui déclenche l'échange. Soit vous demandez, à un rythme que quelqu'un a fixé. Soit on vous prévient, au moment où l'événement se produit. Deux mécanismes, deux façons de tomber en panne, deux lignes de devis distinctes.

Une intégration décrite par ces trois réponses est une intégration dont vous pouvez discuter. Une intégration décrite par le mot « intégration » n'est pas encore une commande.

Quatre choses très différentes portent le même nom

« Intégré » est le mot le plus coûteux de votre devis, et ce n'est pas le plus technique. Il ne s'oppose à rien : personne ne vous proposera jamais du « non intégré ». Il ne se mesure pas, et vous le vérifiez mal. Voici les quatre réalités qu'il recouvre, de la plus légère à la plus engageante.

Un bouton qui ouvre l'autre outil. Vous cliquez, un nouvel onglet s'affiche, et vous voilà dans l'autre outil. Aucune donnée ne circule. C'est utile, c'est honnête, et ce n'est pas une intégration. Le test tient en une phrase : si vous coupez le lien entre les deux, rien ne change chez vous.

Un export d'un côté, un import de l'autre. Quelqu'un sort un fichier du premier outil et le charge dans le second. Votre résultat existe, mais il dépend d'une personne, d'une date et d'un fichier. Une procédure écrite n'est pas un automatisme, et l'appeler intégration vous coûtera cher le jour où cette personne quittera votre entreprise.

Une lecture. Le premier outil affiche ce que détient le second, sans jamais y écrire. C'est souvent tout ce dont vous avez besoin, le cas le plus simple à réparer, et celui à demander par défaut tant que rien ne vous impose davantage.

Une écriture. Le premier modifie ce qui se trouve chez le second, ou les deux se modifient mutuellement. Une question devient alors inévitable, et elle n'a rien de technique : quand vos deux systèmes ne disent pas la même chose, lequel fait autorité, et qui l'a décidé ?

Une cinquième formule circule beaucoup : faire passer l'échange par une plateforme d'automatisation intermédiaire, qui relie vos deux outils sans qu'aucun ne soit modifié. Elle est légitime, souvent la plus rapide. Elle ajoute simplement un troisième fournisseur à votre chaîne, avec ses conditions et sa date de fin.

Ce qu'on vous vend sous le nom d'API est un contrat écrit par quelqu'un d'autre

Un logiciel qui accepte d'être interrogé par d'autres logiciels publie un mode d'emploi : voici les questions que vous pouvez me poser, voici la forme de mes réponses, voici ce que je refuse. Ce mode d'emploi porte un nom. La Commission d'enrichissement de la langue française, dont les travaux paraissent au Journal officiel, l'appelle depuis le 30 avril 2022 une interface de programmation d'application. Vous l'entendrez sous son sigle anglais : API.

La même fiche porte une précision que personne ne cite, et qui est pourtant le cœur de votre sujet : c'est le fournisseur qui détermine les conditions d'accès, gratuites ou payantes, ouvertes ou réservées. L'existence de l'interface ne dit donc rien de votre droit à l'utiliser, ni de la durée de ce droit.

Le glossaire de MDN Web Docs, documentation de référence des technologies du web, en donne la bonne image : un contrat entre le logiciel qui propose l'interface et ceux qui s'en servent. Un contrat que vous n'avez pas négocié, et que l'autre partie peut réécrire seule.

Retenez-en la conséquence, elle vous servira en réunion. Quand votre prestataire vous annonce qu'il utilise l'interface officielle d'un service, il vous annonce une méthode propre. Il ne vous annonce aucune durée.

« On vous prévient » et « vous demandez » ne tombent pas en panne de la même façon

Revenez à la troisième question, celle du déclencheur. Deux réponses possibles, et l'écart entre les deux explique la plupart de vos mauvaises surprises.

Dans le premier cas, votre outil demande. Toutes les cinq minutes, toutes les heures, chaque nuit : quelqu'un a choisi l'intervalle. Et cet intervalle est la valeur réelle du « temps réel » qui figure sur votre devis. Demandez-le en minutes, faites-le écrire.

Dans le second cas, vous ne demandez rien. Vous fournissez une adresse au fournisseur, et il vous envoie un message à cette adresse chaque fois que l'événement se produit. Ce mécanisme porte un nom que votre prestataire emploiera devant vous : un webhook, parfois rendu en français par adresse de rappel.

Le W3C, l'organisme qui normalise les technologies du web, décrit ce mécanisme dans une recommandation du 23 janvier 2018, et en tire une phrase que vous devriez garder : celui qui émet ignore qui l'écoute, et ignore même si quelqu'un l'écoute.

Relisez-la. Elle explique votre facture jamais reçue du début de cet article. Le fournisseur a envoyé. Personne n'a reçu. Et personne n'a été prévenu que personne n'avait reçu.

Une intégration ne tombe pas en panne, elle s'arrête sans bruit

C'est la propriété la plus désagréable du sujet. Rien ne s'affiche en rouge, aucun de vos écrans ne change, et vous l'apprenez par un client mécontent, plusieurs semaines après. Quatre causes reviennent.

La version expire, et le comportement change tout seul. Le fournisseur dont vous dépendez ne maintient pas indéfiniment la version de son interface sur laquelle votre prestataire a travaillé. Meta, pour Facebook et Instagram, s'engage à tenir chaque version au moins deux ans, publie ses dates d'expiration des années à l'avance, et indique ce qui se passe ensuite : les appels adressés à une version échue ne reçoivent pas d'erreur, ils sont basculés vers une version encore utilisable. Votre programme continue donc de fonctionner, en dialoguant avec une version que personne chez vous n'a demandée. C'est là que les comportements inattendus commencent.

Le plafond de requêtes est atteint. Tout fournisseur limite la fréquence à laquelle vous pouvez l'interroger, et publie cette limite. Stripe, l'un des services d'encaissement en ligne les plus répandus, documente ainsi un plafond de cent requêtes par seconde pour un compte en production. Au-delà, vous recevez un refus : trop de demandes en trop peu de temps. Si vous avez demandé du « temps réel » sans autre précision, votre intégration interroge trop souvent, et elle rencontre ce mur un jour de forte activité. Le bon critère n'est jamais la vitesse souhaitable, c'est la décision qui dépend du délai : si personne ne regarde le résultat avant le lendemain matin, le temps réel n'est pas un besoin, c'est une préférence, et elle se paie en fragilité.

Le message n'arrive pas, et la fenêtre pour le rattraper se referme. Les fournisseurs sérieux réessaient, un temps. Stripe indique tenter la livraison pendant trois jours, puis autorise un renvoi manuel pendant quelques semaines. Passé ces délais, l'événement est perdu pour vous. Et trois opérations parfaitement banales, de votre côté, suffisent à provoquer cet échec sans qu'aucun message ne s'affiche : changer l'adresse de votre site et poser une redirection, car une redirection est comptée comme un échec de livraison ; laisser expirer le certificat de sécurité de votre site, celui qui affiche le cadenas dans le navigateur ; héberger sur un serveur qui répond trop lentement, votre adresse étant alors traitée comme indisponible.

La donnée disparaît chez le fournisseur. Celle-ci n'est pas une panne, c'est une décision, et le précédent le plus net vous concerne peut-être déjà : Universal Analytics, l'ancien outil de mesure d'audience de Google, a cessé d'enregistrer quoi que ce soit le 1er juillet 2023, et l'accès aux données historiques a été coupé l'année suivante. Les entreprises qui avaient exporté ont gardé leur historique. Les autres l'ont perdu en une fois, sans faute de leur part.

En Algérie, brancher le paiement par carte a son propre calendrier

Un exemple local vous montre l'écart entre le mot et la chose, parce que le vocabulaire n'y est pas seulement technique, il est administratif.

Pour accepter le paiement en ligne, la SATIM — l'organisme qui traite en Algérie les transactions par carte entre les banques — décrit un chemin en trois temps : un contrat de vente par internet avec la banque qui encaissera pour vous, l'autorisation du groupement interbancaire, le GIE Monétique, puis une certification technique accordée si votre site respecte les exigences publiées.

Ce même GIE Monétique détaille la procédure d'autorisation d'un site marchand, et la fait varier selon un critère qui est exactement votre sujet : construisez-vous votre propre module de paiement, ou reprenez-vous un module déjà certifié ? Dans le premier cas, huit étapes, de l'ouverture d'un profil jusqu'à la notification de l'autorisation, en passant par des essais donnant lieu à un procès-verbal. Dans le second, quatre.

Huit étapes contre quatre, pour la même ligne de devis. Trois enseignements valent bien au-delà du paiement. Votre intégration peut avoir un calendrier propre, indépendant du développement, et qui ne se comprime pas. Réutiliser un composant homologué et en construire un sont deux projets différents : sachez lequel vous achetez. Enfin, votre site livré n'est pas un site en service — entre les deux, il y a une vérification faite par un tiers.

Ces procédures sont publiées et ont été relevées le 10 août 2026. Elles ne constituent pas un avis juridique : leur application à votre situation relève d'un professionnel compétent.

Huit lignes suffisent à transformer une promesse en commande

Aucune de ces huit lignes n'exige de compétence technique, et toutes se relisent un an plus tard.

1. Le nom exact du service tiers et sa version, avec le lien vers la page où le fournisseur publie ses dates d'expiration.

2. Le sens de chaque flux, un par ligne. Qui lit, qui écrit, et en cas d'écriture des deux côtés, quel système fait autorité en cas de désaccord.

3. Le déclencheur de chaque flux. Un événement précis, ou un intervalle exprimé en minutes. « Temps réel » ne s'écrit pas dans un devis.

4. Le sort de votre existant. Ce qui est repris à la mise en service, ce qui ne l'est pas, et à quelle date de coupure.

5. Le comportement en cas d'échec. Qui vous alerte, par quel moyen, et comment on rejoue un échange manqué. Une intégration sans alerte est une intégration dont vous découvrirez la panne par un client.

6. La détention des accès. Au nom de quel compte l'accès est ouvert, et qui détient les identifiants. Ce qu'il advient de cet accès en fin de relation se règle au contrat.

7. La recette — la vérification par laquelle vous acceptez la livraison — définie comme un fait observable. Une donnée réelle, partie d'un bout, arrivée à l'autre, constatée devant témoin avant que vous ne signiez la réception.

8. Ce qui vous reste si l'intégration s'arrête. Quelles données demeurent chez vous et sous quelle forme elles vous sont récupérables. Là encore, la réponse s'écrit au contrat.

Cette page ne rend pas votre intégration solide. Elle rend la conversation possible, et déplace la discussion du terrain de la confiance vers celui de la description.

Trois réflexes vous coûtent cher

Accepter « on se connecte à votre outil » sans demander le sens. La phrase reste vraie dans les quatre cas décrits plus haut. Une formulation qui reste vraie quoi qu'il arrive ne vous informe pas.

Prendre une démonstration pour une recette. Une démonstration se prépare : données choisies, environnement contrôlé. Elle prouve que le mécanisme peut fonctionner. Elle ne prouve pas qu'il fonctionne avec vos données, vos volumes et vos cas particuliers.

Traiter le silence comme une preuve de bon fonctionnement. Un échange fondé sur des notifications ne signale pas son propre arrêt. Sans un contrôle qui vérifie périodiquement que quelque chose est bien arrivé, l'absence de nouvelles ne vous apprend rien.

Questions fréquentes

Mon prestataire parle d'une intégration « native ». Est-ce mieux ?

Le mot signifie que l'éditeur de l'outil a construit lui-même la liaison et la maintient. C'est une bonne nouvelle sur la durée : quand il modifie son interface, il adapte sa propre intégration. Cela ne répond pas pour autant à vos trois questions : une intégration native peut se limiter à une lecture, ou ne se déclencher qu'une fois par nuit.

Que désigne le back office dont on me parle en réunion ?

La même commission qui a traduit API le rend, depuis le 16 septembre 2014, par arrière-guichet : le support informatique et logistique du guichet. Le guichet, c'est ce que voit votre client. L'arrière-guichet, c'est l'endroit depuis lequel vos équipes traitent ce qu'il a produit. Demandez toujours de quel côté se trouve la fonction qu'on vous décrit.

Puis-je exiger de voir l'intégration fonctionner avant de payer ?

Oui, c'est le septième point de la liste ci-dessus. Formulez-le comme un fait observable : une réservation réelle créée devant vous, et la facture correspondante retrouvée dans l'autre outil le même jour, sans aucune intervention manuelle.

Combien de temps mon intégration restera-t-elle valable ?

Personne ne peut vous répondre par une durée. Ce qui se décide, en revanche, c'est qui surveille les annonces du fournisseur et qui paie l'adaptation le jour où il change ses règles. Une expiration de version n'est la faute de personne : soit elle relève d'une maintenance déjà couverte, soit elle donne lieu à une intervention à commander. Un devis muet sur ce point tranchera en votre défaveur, non par mauvaise foi, mais parce que rien n'était écrit.

Faut-il passer par une plateforme d'automatisation intermédiaire ?

C'est souvent votre voie la plus rapide, et elle n'a rien de déshonorant. Posez-vous deux questions avant : combien de vos échanges passeront par elle chaque mois, et que se passe-t-il si elle ferme. Vous ajoutez un fournisseur à votre chaîne : il faut le savoir, et l'écrire.

Si je change de prestataire, l'intégration me suit-elle ?

Cela dépend moins de la technique que de deux points contractuels : au nom de quel compte les accès ont été ouverts, et ce que prévoit votre engagement en fin de relation. Faites écrire ces deux points avant la signature. Ensuite, ils se négocient beaucoup moins bien.

Pour aller plus loin

• Ce qu'un site affiche, ce qu'un système digital conserve — comment reconnaître, avant de signer, si l'on vous vend une vitrine ou un outil qui garde la trace de ce qui s'y passe.

• Reprendre un outil du marché ou faire construire le vôtre — les critères qui tranchent l'arbitrage, et ce que chaque option vous engage à surveiller ensuite.

• Où placer la validation humaine dans une automatisation — quand un échange se déclenche seul, qui regarde le résultat, à quel moment, et sur quel écran.

Ce soir, votre dernier devis

Ne planifiez rien. Ouvrez la dernière proposition que vous avez signée, ou celle qui attend votre signature. Cherchez le mot « intégr » : si le document est un PDF, la fonction de recherche de votre lecteur le trouve en quelques secondes ; s'il est sur papier, entourez-le au crayon.

Sur chaque ligne où il apparaît, écrivez trois mots dans la marge : qui appelle, quel sens, qui déclenche.

Vous saurez répondre pour certaines lignes. Celles où vous ne saurez pas ne sont pas un problème technique : ce sont vos trois premières questions de lundi matin.

Et si les trois réponses vous reviennent en une minute, vous parlez à quelqu'un qui a réfléchi au sujet. Si elles ne reviennent pas, ce n'est pas un mauvais signe sur la personne. C'est un signe certain que la ligne n'est pas encore une commande.

INSEN STUDIO

On regarde votre situation ensemble ?

Vous repartez avec une lecture claire, avec ou sans nous.

Demander un audit digital ↗

Sources

• Commission d'enrichissement de la langue française, FranceTerme : « interface de programmation d'application », Journal officiel du 30 avril 2022, et sa note sur les conditions d'accès déterminées par le fournisseur ; « arrière-guichet » et « guichet », Journal officiel du 16 septembre 2014. Pages consultées le 10 août 2026.

• MDN Web Docs, glossaire, entrée « API », page modifiée le 21 octobre 2025, consultée le 10 août 2026.

• W3C, WebSub, W3C Recommendation du 23 janvier 2018, sections « Abstract » et « Terminology » : adresse de rappel, et méconnaissance des abonnés par l'émetteur. Consultée le 10 août 2026.

• IETF, RFC 6585, « Additional HTTP Status Codes », avril 2012, section 4 : refus opposé à un émetteur ayant envoyé trop de requêtes en trop peu de temps.

• Meta for Developers, « Versioning » et « Versions » de la Graph API : durée de vie minimale de chaque version, calendrier public des dates de sortie et d'expiration, traitement des appels adressés à une version échue. Consultés le 10 août 2026.

• Stripe, documentation développeur : « Rate limits » (plafond de requêtes d'un compte en production) et « Receive Stripe events in your webhook endpoint » (durée des nouvelles tentatives, fenêtre de renvoi manuel, réponses de redirection comptées comme des échecs, certificat expiré, serveur trop lent). Pages consultées le 10 août 2026.

• Google, Aide Google Analytics, « Google Analytics 4 has replaced Universal Analytics » : arrêt du traitement au 1er juillet 2023 et fin de l'accès aux données à partir de la semaine du 1er juillet 2024. Consultée le 10 août 2026.

• SATIM, « Opérations de paiement en ligne », consultée le 10 août 2026.

• GIE Monétique, processus d'homologation, « Autorisation d'un web marchand », consultée le 10 août 2026.