Quiconque estime le coût du développement d’une API sur mesure à partir du nombre de points de terminaison se trompera, en général d’un facteur trois. Les points de terminaison sont la partie la moins chère. Une douzaine d’entre eux, qui lisent et écrivent des données que vous détenez déjà, représentent quinze jours de travail pour un développeur back-end compétent.

Ce qui coûte de l’argent, c’est tout ce qui transforme ces points de terminaison en quelque chose sur quoi une autre entreprise bâtira son activité : une authentification qui survit à un audit de sécurité, un versionnage qui vous laisse changer d’avis plus tard, une documentation assez bonne pour que personne ne vous écrive, et l’appareillage opérationnel qui vous dit quel client passe une mauvaise matinée. C’est entre « nous avons une API » et « nous avons une API dont d’autres dépendent » que vit le budget.

Les fourchettes en un coup d’œil : une API interne consommée uniquement par vos propres applications coûte généralement de 10 000 à 30 000 livres. Une API partenaire utilisée par une poignée d’intégrateurs nommés se situe le plus souvent entre 40 000 et 100 000 livres. Une API publique qui fait partie de votre produit, avec inscription en libre-service et contrat publié, démarre autour de 100 000 livres et continue de coûter après le lancement.

Ce que vous achetez réellement

Une API est un produit avec des utilisateurs, et elle a besoin de ce dont les produits ont besoin. Confronter cette liste à un devis est le moyen le plus rapide de voir ce qui en a été retiré.

Conception et contrat. Quelqu’un doit décider du modèle de ressources, des conventions de nommage, du format d’erreur, de la pagination et de la syntaxe de filtrage, puis l’écrire sous forme de spécification avant que l’implémentation ne commence. Sauter cette étape produit une API où trois points de terminaison résolvent le même problème de trois façons différentes, et les consommateurs le remarquent immédiatement.

Authentification et autorisation. Les clés d’API sont simples et conviennent à un usage interne. Les API partenaires et publiques ont généralement besoin d’un vrai flux à base de jetons, avec portées, expiration et rotation, ainsi que de permissions par consommateur vérifiées à chaque requête plutôt que déduites de la clé.

Limitation de débit et quotas. Des limites par consommateur protègent votre infrastructure du traitement par lots emballé d’un intégrateur. Elles doivent aussi être annoncées dans les en-têtes de réponse pour que les clients bien élevés lèvent le pied, et prévoir une dérogation pour celui qui a légitimement besoin de plus.

Ce sur quoi les consommateurs vous jugent

La documentation. Une référence générée est le minimum. Ce dont les consommateurs ont réellement besoin, c’est d’un guide de démarrage, d’un parcours d’authentification, d’exemples travaillés dans deux ou trois langages et d’un journal des modifications. Une bonne documentation est un livrable à part entière, qui se mesure en semaines, et elle fait la différence entre une API qui s’adopte toute seule et une API qui génère des tickets de support à perpétuité.

Un bac à sable. Les partenaires ne testeront pas contre la production, et vous ne devriez pas le souhaiter. Un environnement de test avec des données réalistes, un état réinitialisable et les mêmes règles de validation est l’une des lignes les plus souvent omises d’un devis d’API, et l’une des fonctionnalités les plus réclamées après le lancement.

L’observabilité. Vous devez voir les volumes de requêtes, les taux d’erreur et la latence ventilés par consommateur, car « l’API est lente » n’est exploitable que si vous savez de qui viennent les requêtes lentes. Des identifiants de corrélation qui permettent de suivre l’appel défaillant d’un client à travers vos journaux se remboursent dès le premier mois de support.

Les tests. Au-delà des tests unitaires, une API a besoin de tests de contrat qui font échouer la construction lorsqu’une forme de réponse change involontairement. C’est ce filet de sécurité qui vous permet de continuer à développer sans casser les intégrateurs qui vous ont fait confiance.

Les trois niveaux, et pourquoi ils diffèrent autant

Le même ensemble de points de terminaison coûte des sommes très différentes selon qui les consomme, parce que le public détermine la tolérance à l’imperfection.

Les API internes servent vos propres applications. Votre équipe contrôle les deux bouts, les changements cassants se coordonnent, la documentation peut rester laconique et l’authentification peut s’appuyer sur les frontières réseau. Coût typique : de 10 000 à 30 000 livres pour un service bien construit, avec des tests et une supervision raisonnables.

Les API partenaires servent un ensemble connu d’organisations externes. Il vous faut désormais une authentification réelle, des messages d’erreur utiles, un bac à sable, une documentation écrite et une politique de versionnage, car vous ne pouvez pas déployer un changement cassant un mardi après-midi en espérant que tout le monde suive. Coût typique : de 40 000 à 100 000 livres selon le nombre de ressources et la sévérité des exigences de sécurité.

Les API publiques ou produits servent quiconque s’inscrit. Inscription en libre-service, gestion des clés, limites de débit publiées, page d’état, comptage à l’usage, documentation complète et processus de support deviennent tous nécessaires. Si la facturation dépend de l’usage, vous avez aussi ajouté un système de mesure et de réconciliation. Coût typique : à partir de 100 000 livres, et le lancement marque le début de la dépense plutôt que sa fin.

Décider honnêtement quel niveau vous construisez est la demi-heure la plus rentable du projet. La plupart des dépassements dans cette catégorie viennent d’une API cadrée comme interne, avant de découvrir trois mois plus tard qu’un partenaire allait de toute façon l’utiliser.

Où part réellement le coût de développement d’une API

Pour une API de qualité partenaire, l’effort se répartit de façon assez prévisible, et rarement comme les décideurs l’imaginent.

Environ un cinquième va à la conception et à la spécification, y compris les discussions sur le nommage des ressources qui semblent du gaspillage et évitent des mois d’incohérence. Un autre cinquième environ va à l’implémentation des points de terminaison eux-mêmes, c’est-à-dire la partie que tout le monde se représente au moment d’approuver le budget.

L’authentification, l’autorisation et la limitation de débit prennent couramment quinze à vingt pour cent à elles trois, davantage si vous vous branchez sur un fournisseur d’identité existant qui a ses opinions. La documentation, le bac à sable et les éventuelles bibliothèques clientes prennent une part comparable, ce qui surprend jusqu’au jour où l’on essaie d’écrire un bon guide de démarrage.

Les tests, l’observabilité et le déploiement consomment le reste. Ce dernier quart est la portion la plus susceptible d’être coupée à l’approche d’une échéance, et c’est cette coupe qui transforme un coût de construction ponctuel en charge de support permanente.

Pour situer cela dans un budget de livraison plus large, notre guide du coût du développement logiciel sur mesure détaille les lignes qui l’entourent.

Les décisions qui font bouger le chiffre

Une poignée de choix explique l’essentiel de l’écart entre deux devis.

Synchrone ou asynchrone. Si une opération dépasse une seconde ou deux, il vous faut un modèle de tâche : accepter la requête, renvoyer une référence, et laisser le consommateur interroger ou recevoir un rappel. C’est une construction nettement plus lourde qu’une simple requête-réponse, et proposer des webhooks signifie que vous exploitez désormais votre propre système de livraison, avec reprises, vérification de signature et file de messages non délivrés.

La multilocation. Garantir qu’un client ne verra jamais les données d’un autre se décrit facilement et se rate subtilement tout aussi facilement. Le faire correctement, avec une autorisation vérifiée à la couche d’accès aux données plutôt que dans chaque contrôleur, coûte plus cher et n’est pas optionnel.

Les obligations de conformité. Traiter des données personnelles, des informations de paiement ou des données de santé apporte journalisation d’audit, règles de conservation, exigences de chiffrement et collecte de preuves. Ces éléments figurent rarement dans une estimation initiale et ne sont jamais négociables plus tard.

Les engagements de niveau de service. Une API assortie d’un objectif contractuel de disponibilité exige de la redondance, des alertes et quelqu’un d’astreinte. C’est un coût d’exploitation et non de construction, et il doit être chiffré séparément pour que personne ne soit surpris.

Les fondations existantes. Bâtir sur une base de code qui possède déjà l’authentification, les traitements de fond et la supervision revient nettement moins cher que de partir de zéro. S’il vous faut aussi la plateforme sous-jacente, notre tutoriel sur la création d’une API serverless avec Cloudflare Workers montre une approche qui maintient le coût d’infrastructure bas.

Les coûts qui arrivent après le lancement

Une API est une promesse, et les promesses ont un coût de fonctionnement.

Le versionnage est le plus lourd. Dès que des consommateurs externes dépendent de vos formes de réponse, vous ne pouvez plus les modifier librement. Maintenir deux versions en parallèle pendant que les intégrateurs migrent est normal, et cela signifie que chaque correction doit être appliquée deux fois pendant un temps. Une politique de dépréciation publiée avec un préavis généreux rend la chose gérable ; son absence transforme chaque amélioration en négociation.

Le support vient ensuite. Même une excellente documentation suscite des questions, et ces questions sont assez techniques pour atteindre un développeur plutôt que de s’arrêter à un guichet de service. Prévoyez du vrai temps d’ingénierie, en particulier dans les mois qui suivent la mise en production de chaque nouveau partenaire.

La maintenance de la documentation est le troisième poste et le plus négligé. Des exemples qui ne fonctionnent plus sont pires que pas d’exemples du tout, et ils érodent la confiance plus vite qu’une panne.

Comme repère de planification, comptez chaque année quinze à vingt-cinq pour cent du coût initial de construction pour maintenir en bonne santé une API partenaire ou publique. Si l’API constitue elle-même une source de revenus, notre guide des modèles de licence logicielle traite la structuration du volet commercial.

Comment éviter que le projet double

Trois habitudes maintiennent un projet d’API dans son estimation.

Écrivez d’abord la spécification et faites-la relire par un consommateur réel avant que l’implémentation ne commence. Une heure de retours de l’équipe qui intégrera vraiment épargne des semaines de reprise, et fait apparaître l’exigence que personne n’avait mentionnée.

Construisez un point de terminaison de bout en bout, en passant par l’authentification, la gestion des erreurs, la documentation, les tests et la supervision, avant de construire les vingt autres. Le premier révèle le coût réel par point de terminaison, et il le fait tant que le budget peut encore encaisser la nouvelle.

Soyez impitoyable sur la liste initiale des ressources. La plupart des API sont lancées avec plus de points de terminaison que personne n’en utilise, et chaque point de terminaison inutilisé doit malgré tout être documenté, testé, sécurisé et versionné tant qu’il existe. Livrez la plus petite surface utile et étendez-la quand l’usage réel vous dira ce qui manque.

Construisez une API que l’on a envie d’intégrer

Mecanik conçoit et construit des API dans le cadre de nos services de développement logiciel sur mesure , depuis les services internes jusqu’aux API produits publiques avec inscription en libre-service. Nous traitons la spécification, la documentation et le bac à sable comme des livrables et non comme des arrière-pensées, parce que ce sont eux qui déterminent si quelqu’un parvient à s’intégrer.

Si vous êtes de l’autre côté du problème et consommez l’API d’un tiers plutôt que d’en publier une, notre guide de l’intégration d’API tierces explique à quoi faire attention. Sinon, dites-nous qui sont les consommateurs et ce qu’ils doivent faire, et nous cadrerons le projet niveau par niveau pour que vous voyiez exactement ce que coûte chaque degré d’ambition.

Articles en relation: Externalisation du développement logiciel au Royaume-Uni , Intégration CRM et ERP : coûts, méthodes et pièges , Modernisation mainframe : rewrite, refactor ou replatform .

Questions fréquentes

Combien coûte le développement d’une API sur mesure ? Une API interne coûte généralement de 10 000 à 30 000 livres, une API partenaire de 40 000 à 100 000, et une API produit publique plus de 100 000. Le public fait bien plus varier le prix que le nombre de points de terminaison, car les consommateurs externes exigent documentation, bac à sable, versionnage et support.

Combien de temps faut-il pour construire une API sur mesure ? Un service interne demande d’ordinaire quatre à huit semaines. Une API de qualité partenaire prend généralement trois à cinq mois, documentation et bac à sable compris. Les API publiques avec inscription en libre-service et comptage à l’usage demandent couramment six mois ou plus avant le lancement.

Qu’est-ce qui rend le développement d’API plus cher que prévu ? La documentation, les environnements de bac à sable, la limitation de débit par consommateur, la prise en charge du versionnage et l’observabilité. Ces postes figurent rarement dans les premières estimations et représentent souvent, ensemble, la moitié de l’effort total sur une API partenaire ou publique.

Faut-il construire une API REST ou GraphQL ? REST reste le choix par défaut le plus sûr pour les API partenaires et publiques, car l’outillage, la mise en cache et la familiarité des développeurs y sont plus larges. GraphQL convient à l’usage interne et aux applications clientes riches, mais il déplace le coût vers les limites de complexité des requêtes et l’autorisation.

Quels coûts récurrents prévoir après le lancement d’une API ? Prévoyez chaque année quinze à vingt-cinq pour cent du coût de construction. Cela couvre le maintien de versions parallèles pendant les périodes de dépréciation, le temps d’ingénierie passé à répondre aux questions d’intégration, l’entretien de la documentation et la supervision requise pour des consommateurs externes.