IntégrationApplication métierPMEBudget
API, c'est quoi ? L'explication simple pour un dirigeant, avec des exemples concrets
10 min de lecture
Une API (pour Application Programming Interface, interface de programmation) est une porte d'entrée qu'un logiciel ouvre aux autres logiciels. Elle leur permet de lui demander une information ou de lui faire exécuter une action, selon des règles écrites à l'avance, sans qu'un humain ait à cliquer sur un écran. Pour un dirigeant, l'essentiel tient en une idée : une API, c'est ce qui évite la ressaisie entre deux outils.
Cet article explique le principe sans jargon, avec des exemples que vous croisez déjà : la facture électronique, la banque, votre logiciel comptable, le paiement en ligne. Puis il répond aux questions qui comptent pour une décision : ce que cela change pour un logiciel métier, ce qui fait le coût d'une intégration, et quoi demander avant de signer.
L'image la plus juste : un guichet avec un formulaire
Imaginez un service administratif qui ne reçoit le public qu'à un guichet. Pour obtenir quelque chose, il faut remplir un formulaire précis, présenter un justificatif, et la réponse revient toujours dans le même format. Vous n'entrez jamais dans les bureaux, vous ne voyez pas comment le dossier est traité : vous savez seulement quoi demander et quoi recevoir.
Une API fonctionne exactement ainsi :
- le formulaire, c'est la requête : ce que votre logiciel demande, dans un format imposé ;
- le justificatif, c'est la clé d'accès (ou un jeton), qui prouve que votre logiciel a le droit de demander ;
- la réponse normalisée, ce sont les données renvoyées, toujours dans la même structure, que votre logiciel sait lire ;
- le règlement affiché au guichet, c'est la documentation : la liste de ce qu'on peut demander, et comment.
Le logiciel qui ouvre son API garde la main : il décide de ce qu'il expose, à qui, et dans quelles limites.
Un exemple réel, que vous pouvez tester vous-même
L'État publie l'API Recherche d'entreprises, ouverte à tous et sans clé. Un logiciel lui envoie un nom ou un numéro SIREN, et reçoit en retour la dénomination, l'adresse du siège, le code d'activité et d'autres informations publiques. La requête ressemble à une simple adresse web, terminée par ce que l'on cherche :
https://recherche-entreprises.api.gouv.fr/search?q=boulangerie
La réponse est un texte structuré, lisible par un programme, qui reprend
pour chaque société trouvée les mêmes rubriques, toujours dans le même
ordre : siren, nom_complet, siege, activite_principale, et ainsi de
suite. Votre logiciel sait donc exactement où lire chaque information.
Dans un logiciel de devis, cela permet de taper le nom d'un nouveau client et de voir sa fiche se remplir toute seule, SIREN compris. Au relevé du 6 novembre 2026, cette API est limitée à 7 appels par seconde, et l'administration se réserve le droit de baisser ce plafond en cas de surcharge. Voilà, en miniature, tout ce qu'est une API : une demande, une réponse, des règles d'usage.
Quatre exemples que vous croisez déjà
La facture électronique
Avec la réforme de la facturation électronique, les factures entre entreprises transitent par des plateformes agréées par l'administration. Pour qu'un logiciel de facturation ou un logiciel métier envoie ses factures sans que personne ne les télécharge puis les redépose à la main, il se connecte à l'API d'une de ces plateformes. C'est ce que nous avons construit pour Izi-Devis, le logiciel de devis et de factures pour artisans que LPR Studio édite et exploite lui-même : la connexion à une plateforme agréée est en recette sur l'environnement de test de la plateforme. Le détail du calendrier et des formats est dans notre article facturation électronique : ce qui change pour votre logiciel métier.
La banque
Depuis la deuxième directive européenne sur les services de paiement (DSP2, directive 2015/2366), les banques doivent ouvrir un accès aux comptes de paiement à des prestataires réglementés : les agrégateurs (qui lisent les soldes et les opérations) et les initiateurs de paiement (qui déclenchent un virement avec l'accord du titulaire). C'est par ces accès que votre logiciel comptable récupère vos relevés chaque matin. Pour un logiciel métier, la voie normale n'est pas de se brancher seul sur chaque banque, mais de passer par l'un de ces prestataires, qui expose sa propre API.
Le logiciel comptable
Prenons Pennylane. Sa documentation développeur décrit une API qui couvre les factures clients et fournisseurs, les fiches clients, les écritures comptables, les transactions bancaires et leur rapprochement, avec des webhooks pour être prévenu d'un changement. L'accès se fait par un jeton d'entreprise ou par OAuth, avec des droits limités à ce qui est nécessaire (lecture seule des factures, par exemple). Concrètement : une facture validée dans votre application métier peut arriver dans la comptabilité sans ressaisie, et le statut « payée » revenir dans l'autre sens.
Le paiement en ligne
Stripe décrit son API comme organisée autour de REST, avec des adresses prévisibles et des réponses en JSON. Un point compte beaucoup pour un dirigeant : Stripe propose des environnements de test (sandboxes) qui n'affectent ni vos données réelles ni les réseaux bancaires. On peut donc tout essayer, paiements refusés et remboursements compris, avant le premier euro encaissé. Notre article sur la facturation d'abonnements avec Stripe détaille ce que Stripe fait, et ce qui reste à la charge de votre logiciel.
Les cinq mots à connaître, et pas plus
| Terme | Ce que c'est, en clair |
|---|---|
| API REST | Le style le plus courant : chaque ressource (client, facture) a son adresse web |
| JSON | Le format texte le plus répandu pour les réponses |
| Clé ou jeton | Le justificatif qui prouve que votre logiciel a le droit de demander |
| Webhook | Une notification envoyée automatiquement quand un événement se produit |
| Environnement de test | Une copie de l'API où l'on peut tout essayer sans conséquence |
Le reste relève de vos prestataires. Ce qui relève de vous, ce sont les questions de la fin de cet article.
Ce que les API changent pour un logiciel métier
Ce qu'elles apportent
- Plus de ressaisie : une donnée saisie une fois circule entre les outils. Moins de temps perdu, et surtout moins d'erreurs de copie.
- Une seule vérité par donnée : le client existe dans un seul outil maître, les autres le lisent. Fini les trois adresses différentes pour le même client.
- Un logiciel métier plus petit : inutile de refaire la comptabilité, le paiement ou la signature électronique. Votre application fait ce qui vous est propre et s'appuie sur des outils spécialisés pour le reste.
- Des traitements en temps réel : un paiement reçu débloque une commande à la seconde, sans attendre que quelqu'un consulte le relevé.
Ce qu'elles imposent
- Une dépendance : si l'éditeur change ou ferme son API, l'intégration doit suivre. Les bons éditeurs annoncent leurs changements de version et laissent un délai ; d'autres moins.
- Des limites d'usage : nombre d'appels par seconde ou par jour, parfois payant au-delà d'un seuil.
- Des données qui circulent : chaque échange de données personnelles vers un service tiers doit être prévu dans votre registre RGPD et couvert par un contrat avec ce prestataire.
- Des clés à protéger : une clé d'API qui fuit, c'est une porte ouverte sur vos données. Elle se stocke côté serveur, jamais dans un tableur ni un e-mail.
Ce qui fait le coût d'une intégration
Il n'existe pas de prix public d'une « intégration par API », et nous n'en inventerons pas : le même connecteur peut prendre deux jours ou deux mois. Ce qui fait la différence :
| Facteur | Intégration simple | Intégration complexe |
|---|---|---|
| Documentation | Complète, à jour, avec exemples | Partielle, obsolète ou absente |
| Environnement de test | Fourni par l'éditeur | Inexistant : on teste sur des données réelles |
| Correspondance des données | Mêmes notions des deux côtés | Statuts, unités ou référentiels à traduire |
| Sens des échanges | Lecture seule | Lecture et écriture, dans les deux sens |
| Cas d'erreur | Rares et bien signalés | Doublons, coupures, données partielles à rattraper |
| Volume | Quelques dizaines d'échanges par jour | Gros volumes, proches des plafonds de l'API |
Le premier poste est presque toujours le traitement des cas d'erreur : que fait-on si la plateforme ne répond pas, si un client existe en double, si une facture est rejetée ? Un devis qui ne parle que de « brancher l'API » sous-estime le travail. Notre article sur l'intégration avec un ERP existant détaille ces questions, qui valent pour n'importe quel outil.
Le second poste, souvent oublié, est la maintenance : une API évolue, et une intégration se surveille. Prévoyez des alertes en cas d'échec et quelqu'un pour les lire.
Quand une API n'est pas nécessaire
Une intégration sur mesure n'est pas toujours la bonne réponse :
- un export de fichier une fois par semaine suffit quand la donnée n'a pas besoin d'être fraîche ;
- un connecteur sans code (Zapier, Make, n8n) relie très bien deux logiciels du marché qui y sont déjà proposés, pour des règles simples. Notre article n8n, Make ou développement sur mesure aide à choisir ;
- un outil sans API ne s'intègre pas proprement. Si l'échange est indispensable, c'est peut-être l'outil qu'il faut changer.
Les questions à poser avant d'acheter un logiciel
Avant de souscrire à un logiciel du marché, posez ces six questions. Elles décideront de ce que vous pourrez en faire demain :
- Existe-t-il une API publique et documentée ? Demandez le lien.
- Est-elle incluse dans votre formule, ou réservée à une offre supérieure ?
- Couvre-t-elle la lecture et l'écriture des données qui vous intéressent ?
- Y a-t-il des webhooks pour être prévenu des changements ?
- Un environnement de test est-il fourni ?
- Peut-on exporter la totalité de ses données en partant ? Notre article sur la réversibilité explique pourquoi c'est vital.
Et si vous faites développer un logiciel métier, posez la question inverse : votre application aura-t-elle sa propre API, documentée, pour que vos futurs outils puissent s'y brancher ?
Par où commencer
- Listez les ressaisies de la semaine : quelle donnée, copiée de quel outil vers quel outil, par qui.
- Désignez l'outil maître de chaque donnée (clients, produits, factures).
- Vérifiez les API des outils concernés avec les six questions ci-dessus.
- Commencez par un seul flux, celui qui coûte le plus d'erreurs.
Si ce flux passe par une application à construire, voyez-la avant de payer. Nous réalisons un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés : vous voyez où chaque donnée arrive et d'où elle vient. Notre article voir son logiciel avant de le payer explique la démarche.