IntégrationSur-mesureCahier des chargesBudget
Développement d'API sur mesure : quand en faire construire une, et comment la cadrer
11 min de lecture
Faites développer une API sur mesure quand d'autres programmes doivent accéder à vos données ou déclencher vos traitements de façon fiable : votre application mobile, le logiciel d'un partenaire, le portail d'un client, ou vos propres outils internes. Si vous cherchez seulement à faire parler deux logiciels du marché, un connecteur existant ou un outil d'intégration suffit souvent. Une API sur mesure est un produit à part entière : elle se conçoit, se documente, se sécurise et se maintient.
Si le mot API reste flou pour vous, commencez par notre article une API expliquée à un dirigeant. Celui-ci s'adresse à ceux qui ont déjà un projet et veulent savoir quoi demander à un prestataire.
Trois situations où une API sur mesure se justifie
Ouvrir vos données à des partenaires ou à des clients
Un distributeur veut consulter vos stocks en temps réel. Un client grand compte veut envoyer ses commandes depuis son ERP plutôt que par e-mail. Un prescripteur veut suivre l'avancement des dossiers qu'il vous confie. Dans ces cas, l'API remplace des échanges de fichiers, des ressaisies et des appels téléphoniques. Elle devient aussi un argument commercial : un client qui a branché son système sur le vôtre change plus rarement de fournisseur.
Servir votre propre application ou portail
Une application mobile, un portail client ou un back-office ne lisent pas directement la base de données : ils passent par une API. Elle centralise les règles de gestion et les droits d'accès, pour que chaque écran applique les mêmes. C'est l'architecture standard d'une application métier moderne, et la condition pour ajouter plus tard un nouvel écran sans tout réécrire.
Relier des logiciels internes qui n'ont pas prévu de se parler
Votre ERP ancien n'expose qu'une base de données, votre outil de planning ne sait qu'importer des fichiers, votre CRM a une API mais pas les champs qu'il vous faut. Une API intermédiaire, développée pour vous, devient le point de passage unique : elle traduit, contrôle et journalise. Notre article sur l'intégration d'une application à un ERP existant détaille cette situation.
Quand vous n'en avez pas besoin
- Les deux logiciels ont déjà un connecteur natif maintenu par l'un des éditeurs : commencez par lui.
- Les flux sont simples et peu nombreux : un outil d'intégration comme n8n, Make ou Power Automate suffit souvent. Notre comparatif n8n, Make ou développement sur mesure montre où ces outils cassent.
- Un échange de fichier quotidien répond au besoin : un export planifié bien construit est plus robuste qu'une API mal conçue.
- Personne n'appellera l'API : construire une API « pour plus tard » sans premier utilisateur produit un contrat que personne n'a validé.
Ce que doit contenir une API professionnelle
Une API qui « fonctionne » en démonstration n'est pas une API prête à être ouverte. Voici ce qui fait la différence.
| Élément | À quoi il sert |
|---|---|
| Contrat OpenAPI | Décrire chaque point d'accès, ses paramètres et ses réponses |
| Authentification | Savoir qui appelle : clés d'API, OAuth 2.0 pour les tiers |
| Contrôle d'accès par objet | Vérifier que l'appelant a droit à CETTE commande, pas seulement aux commandes |
| Versionnement | Faire évoluer l'API sans casser les intégrations existantes |
| Limites de débit | Protéger le service d'un appelant trop gourmand ou malveillant |
| Pagination et filtres | Éviter de renvoyer cent mille lignes d'un coup |
| Idempotence | Qu'une commande envoyée deux fois ne soit créée qu'une fois |
| Webhooks | Prévenir les partenaires d'un changement au lieu qu'ils interrogent sans cesse |
| Erreurs explicites | Un message clair et un code stable pour chaque cas d'échec |
| Journalisation | Savoir qui a appelé quoi, quand, avec quel résultat |
| Environnement de test | Permettre aux partenaires de développer sans toucher la production |
| Documentation publique | Exemples, guide de démarrage, changements annoncés |
Le contrat OpenAPI mérite une mention particulière. C'est un standard ouvert, dont la version 3.2.0 a été publiée le 19 septembre 2025 (spécification officielle). Écrit avant le code, il sert de cahier des charges technique : vos partenaires peuvent le relire, des outils génèrent la documentation et des tests à partir de lui, et il se transmet facilement à un autre prestataire si vous en changez.
REST, GraphQL, webhooks ou fichiers
| Mode d'échange | Quand le choisir |
|---|---|
| REST | Le cas général : ressources claires, partenaires variés |
| GraphQL | Beaucoup d'écrans différents, besoins de lecture très variables |
| Webhooks | Prévenir un tiers qu'un événement a eu lieu |
| Fichiers planifiés | Gros volumes, systèmes anciens, aucune urgence |
| Messages (file d'attente) | Flux internes à fort volume, besoin de reprise sur erreur |
Une API réelle combine souvent plusieurs modes : du REST pour consulter et créer, des webhooks pour notifier, un export de fichier pour l'historique.
La sécurité : les failles qui reviennent le plus
L'OWASP, fondation de référence en sécurité applicative, publie un Top 10 des risques propres aux API (édition 2023). Les cinq premiers, traduits en langage de dirigeant :
- Contrôle d'accès par objet défaillant : un partenaire change un numéro dans l'adresse et lit la commande d'un autre client.
- Authentification défaillante : jetons qui n'expirent jamais, mots de passe testables à l'infini.
- Contrôle d'accès par propriété défaillant : l'API renvoie des champs qui ne devraient pas sortir (marge, notes internes) ou en accepte qui ne devraient pas être modifiables.
- Consommation de ressources sans limite : un seul appelant sature le service ou fait exploser la facture d'hébergement.
- Contrôle d'accès par fonction défaillant : un compte de lecture parvient à supprimer.
Ces failles ne se voient pas en démonstration. Elles se préviennent par la conception (droits vérifiés à chaque requête, réponses limitées au strict nécessaire), par des tests automatiques, et par un test d'intrusion avant l'ouverture à des tiers. Pour le reste de l'application, voyez la sécurité d'une application métier.
API et données personnelles
Dès qu'une API transporte des noms, des e-mails ou des adresses, le RGPD s'applique à chaque échange. Trois règles simples réduisent le risque : n'exposer que les champs nécessaires à chaque partenaire, journaliser les accès pour pouvoir répondre à une demande ou à un incident, et encadrer par contrat chaque partenaire qui reçoit les données. Notre article sur le RGPD dans une application métier détaille ces obligations.
Ce qui fait le coût d'une API sur mesure
Les fourchettes de prix publiées en ligne divergent fortement, parce qu'elles ne parlent pas de la même chose. Le prix dépend de six facteurs :
- le nombre de ressources et d'opérations (consulter un stock n'est pas créer une commande avec ses règles de validation) ;
- la complexité des règles métier que l'API doit appliquer ;
- le nombre et l'état des systèmes à relier derrière elle ;
- le niveau de sécurité attendu : partenaires externes, données sensibles, tests d'intrusion ;
- la documentation et l'accompagnement des partenaires ;
- l'exigence de disponibilité : une API qui sert des commandes la nuit ne se supervise pas comme une API de consultation interne.
Au coût de construction s'ajoute le coût de fonctionnement : hébergement, supervision, mises à jour de sécurité, nouvelles versions. Pour la méthode de chiffrage, lisez le prix d'une application métier sur mesure.
Une API vit après sa livraison
Une API ouverte à des tiers crée un engagement de fait : d'autres entreprises ont construit sur elle. Trois chantiers continuent donc après la mise en service.
- La supervision : temps de réponse, taux d'erreur, volume d'appels par partenaire. Une alerte doit partir avant que le partenaire ne vous appelle.
- Les mises à jour de sécurité des composants utilisés, au fil des failles publiées, sans attendre la prochaine évolution fonctionnelle.
- Les évolutions : nouveaux champs, nouvelles opérations, versions successives. Chaque changement incompatible s'annonce, se date et s'accompagne d'une période pendant laquelle l'ancienne version reste disponible.
Ce suivi se budgète dès le départ, comme pour toute application en production. Notre article sur la maintenance d'une application métier détaille ce qu'il recouvre.
Les questions à poser à votre prestataire
- Écrivez-vous le contrat OpenAPI avant le code, et me le soumettez-vous ?
- Comment vérifiez-vous les droits d'accès à chaque objet, à chaque requête ?
- Quelle politique de versions et de dépréciation proposez-vous ?
- Quels tests automatiques livrez-vous avec l'API ?
- Qui surveille l'API en production, et comment suis-je prévenu d'un incident ?
- Que récupérons-nous en cas de changement de prestataire : code, spécification, scripts de déploiement, accès ? Les droits sont définis au cas par cas dans le contrat : lisez-le sur ce point.
Les erreurs fréquentes
- Calquer l'API sur la base de données. Exposer les tables telles quelles fige votre structure interne : vous ne pourrez plus la modifier sans casser les partenaires. L'API doit refléter le métier (une commande, un dossier), pas le stockage.
- Ouvrir sans environnement de test. Les partenaires testent alors en production, avec vos vraies données.
- Oublier les cas d'erreur. Que se passe-t-il quand le partenaire envoie une commande sur un article supprimé ? C'est là que se joue la qualité, pas dans le cas nominal.
- Ne pas documenter les changements. Un champ renommé sans préavis coupe une intégration un vendredi soir.
- Construire seul, sans premier utilisateur. Le premier partenaire ou la première application qui consomme l'API doit participer à la conception du contrat.
Par où commencer
- Nommez le premier consommateur : quelle application ou quel partenaire appellera l'API, pour faire quoi.
- Listez les opérations indispensables à ce premier usage, pas plus.
- Faites rédiger le contrat OpenAPI et faites-le relire par ce premier consommateur.
- Construisez, testez, ouvrez à ce seul consommateur, puis élargissez.
Quand l'API sert un portail, une application mobile ou un back-office, le plus sûr est de voir les écrans qui l'utiliseront avant de la construire. Nous réalisons un prototype visuel gratuit, présenté en visio sous 5 jours ouvrés : il fait apparaître les données dont chaque écran a besoin, donc le contrat de l'API.