S5 · Service

Une API que vos clients et vos partenaires peuvent utiliser sans vous appeler

Vos partenaires veulent se brancher, une application mobile a besoin d’un backend, une autre équipe doit lire vos données. Je conçois et développe des API REST en ASP.NET Core avec un contrat écrit, versionnées, documentées, et qui restent stables quand tout le reste bouge.

Livrables
Contrat OpenAPI
Versionnement
Authentification
Quotas
Tests de contrat

Quand vous avez besoin d’une API

Des partenaires doivent passer des commandes, lire des stocks ou recevoir des événements sans passer par un humain.
Une application mobile ou un site doit s’appuyer sur vos données et vos règles métier, sans les dupliquer.
Une autre équipe ou un autre prestataire construit quelque chose qui dépend de votre système, et il lui faut une interface stable plutôt qu’un accès à votre base.
Une API interne a été ouverte à l’extérieur sans contrat, et chaque correctif casse quelqu’un.

Ce qui fait une API qu’on peut faire évoluer

Un contrat qui fait autorité

Une description OpenAPI écrite avant le code, relue avec les consommateurs, et à partir de laquelle la documentation et les tests sont générés. Le contrat est la source de vérité ; le code le respecte, pas l’inverse.

Un versionnement annoncé

Les changements compatibles s’ajoutent sans rien casser. Les changements incompatibles vont dans une nouvelle version, avec une période de cohabitation et une date de fin annoncée. Vos partenaires planifient au lieu de subir.

Des erreurs typées et une idempotence assumée

Une erreur doit dire ce qui s’est passé et ce qu’il faut faire, dans un format constant. Et une requête rejouée (parce que le réseau a coupé) ne doit pas créer deux commandes : l’idempotence est prévue dès la conception, pas rajoutée après le premier incident.

Des quotas et des tests de contrat

Chaque consommateur a une limite, pour qu’un partenaire qui boucle ne fasse pas tomber les autres. Et à chaque livraison, une suite de tests vérifie que le contrat est toujours respecté, avant que quiconque ne s’en aperçoive en production.

Sécurité et authentification

Clés d’API pour les systèmes, OAuth 2 pour les utilisateurs, validation stricte de tout ce qui entre, journalisation des accès, secrets hors du code. Deux années passées en cybersécurité m’ont laissé une habitude utile : concevoir chaque point d’entrée en me demandant qui essaiera d’en abuser.

Livrables

Le contrat OpenAPI et sa documentation navigable.
L’API en ASP.NET Core, ses tests, son déploiement.
Un guide d’intégration pour vos partenaires, avec des exemples d’appels.
La politique de versionnement écrite.

Consommer les API des autres, plutôt qu’exposer la vôtre ? C’est l’objet de la pageinterconnexion d’applications.

Questions fréquentes

REST ou GraphQL ?: REST dans la grande majorité des cas : c’est ce que vos partenaires savent consommer, ce que les outils documentent le mieux, et ce qui se met en cache. GraphQL a du sens quand les consommateurs ont des besoins de lecture très variés et que vous contrôlez les clients. On décide sur votre cas, pas sur la mode.
Comment éviter de casser nos partenaires à chaque évolution ?: Un contrat écrit qui fait autorité, une politique de versionnement annoncée, des tests de contrat qui tournent à chaque livraison, et des changements incompatibles regroupés dans une nouvelle version annoncée à l’avance. Une rupture devient une décision datée, plus un accident.
Et la sécurité ?: Authentification adaptée aux consommateurs (clés d’API pour des systèmes, OAuth pour des utilisateurs), quotas par client, validation stricte des entrées, journal des accès. Mon passage par la cybersécurité sert précisément ici : je conçois l’API en pensant à qui essaiera d’entrer.
Travaillez-vous à distance ?: Oui, avec des entreprises de toute la France. Sur site en Nouvelle-Aquitaine quand le projet le demande, ponctuellement ailleurs.
Je n’ai pas de cahier des charges. C’est un problème ?: Non. La première étape d’une mission consiste précisément à comprendre le besoin et à l’écrire. Décrivez le problème avec vos mots, le reste est mon travail.
Qui possède le code ?: Vous. Le code, la documentation et les accès vous sont remis au fil de la mission, pas à la fin. Vous pouvez confier la suite à quelqu’un d’autre à tout moment.
Comment facturez-vous ?: Au forfait quand le périmètre est clair, à la journée quand il ne l’est pas encore. Dans les deux cas, un devis écrit avant de commencer, et pas de surprise après.