Applications & interfaces

Réalisation d’API

Une API est un contrat : ce que vous publiez une fois sera appelé pendant des années, par des gens que vous ne connaîtrez jamais.

à partir de 6 500 € HT 4 à 9 semaines Éditeurs, PME avec un système d’information, agences

Le problème

Deux logiciels doivent se parler et personne ne sait par où commencer. Un partenaire demande un accès automatisé à vos données, et vous lui envoyez un fichier tous les lundis. Une application mobile est décidée, mais il n’existe rien derrière pour l’alimenter.
Quand l’API finit par être écrite, c’est souvent dans l’urgence : aucune version, aucune documentation, une authentification improvisée, et une panne le jour où un partenaire triple son volume d’appels sans prévenir.

Nous concevons et développons des interfaces de programmation faites pour durer : celles que vos partenaires appellent, celles qui remplacent des exports manuels entre deux logiciels, et celles qui alimentent vos applications.

La conception passe avant le code. Nous écrivons d’abord le contrat (les ressources exposées, les formats, les codes d’erreur, la pagination, la politique de version) et nous le faisons relire par ceux qui vont l’utiliser, avec un serveur d’essai pour qu’ils puissent l’éprouver. Une heure de discussion à ce stade évite une rupture de compatibilité six mois plus tard, quand douze intégrations en dépendent.

Le reste tient au sérieux plus qu’à la prouesse : une authentification standard par jetons, des quotas par client, des messages d’erreur qui expliquent ce qui ne va pas, une documentation générée depuis le code et donc toujours juste, des tests automatisés sur chaque point d’entrée, et des journaux qui permettent de répondre à « pourquoi mon appel a échoué mardi à 14 h ». L’API peut rester chez vous ou entrer dans notre hébergement managé, avec la supervision qui va avec.

Nous consommons aussi les interfaces des autres, ce qui est le cas le plus fréquent : relier votre site à un ERP, un logiciel de caisse, un transporteur ou un service de paiement, avec les reprises sur erreur et les rejeux que ces échanges exigent. Quand une application mobile est au programme, l’API est conçue en même temps qu’elle.

Ce que ça change pour vous

Un contrat écrit avant le code

Ressources, formats, erreurs et versions sont validés par les développeurs qui consommeront l’API, avant la première ligne écrite.

Une documentation toujours juste

Elle est générée depuis le code : elle ne peut pas dériver de ce que l’API fait réellement, ce qui est le défaut le plus courant.

Une montée en charge sans surprise

Quotas par client, mise en cache et test de charge avant l’ouverture. Un partenaire qui s’emballe ne fait pas tomber le service.

La compatibilité préservée

Versions et dépréciations sont annoncées à l’avance. Vos intégrateurs ne découvrent pas une rupture un lundi matin en production.

Comment nous procédons

  1. Cadrage des usages

    Qui appelle, pour quoi faire, à quelle fréquence, avec quelles données sensibles et quelles contraintes de confidentialité.

  2. Conception du contrat

    Une spécification OpenAPI relue avec les futurs intégrateurs, accompagnée d’un serveur d’essai avant tout développement.

  3. Développement et tests

    Implémentation, tests automatisés sur chaque point d’entrée, jeu de données de démonstration et test de charge.

  4. Ouverture

    Un environnement de recette ouvert aux partenaires, des quotas, la supervision, puis une ouverture progressive.

Ce que vous recevez

  • Une spécification OpenAPI complète, relue avec vos intégrateurs
  • L’API développée, testée et versionnée
  • Une authentification par jetons, avec des droits par client
  • Des quotas, une limitation de débit et une mise en cache
  • Un portail de documentation avec des exemples exécutables
  • La supervision, les journaux d’appels et les alertes en cas d’anomalie

En fonctionnement

appels d’API
Comment nous construisons

Questions fréquentes

REST ou GraphQL ?

REST dans la grande majorité des cas : tout le monde sait l’appeler, la mise en cache est simple, les outils sont matures. GraphQL se justifie quand les clients ont des besoins de données très hétérogènes, typiquement plusieurs applications sur un même socle. Nous faisons les deux et nous vous disons ce que nous choisirions.

Pouvez-vous reprendre une API existante ?

Oui, c’est fréquent. Nous commençons par en écrire la spécification, qui manque presque toujours, puis nous corrigeons ce qui est risqué sans casser les intégrations en place. La compatibilité des clients déjà branchés est une contrainte, pas une option négociable.

Qui héberge l’API ?

Vous, chez votre fournisseur actuel, ou nous, dans le cadre de l’hébergement managé. Dans les deux cas la supervision est en place dès l’ouverture : une API sans surveillance tombe en silence, et c’est le partenaire qui vous l’apprend.

Faut-il une API pour une application mobile ?

Oui, systématiquement : c’est elle qui alimente l’application. Quand nous réalisons les deux, l’API est conçue en même temps que l’application, ce qui évite les allers-retours coûteux entre deux prestataires qui se renvoient la responsabilité.

Parlons de « Réalisation d’API »

Trente minutes suffisent pour savoir si c’est adapté à votre situation, et combien ça coûte réellement chez vous.