Développement
et intégration
d’API
Deux systèmes qui devraient partager des données, et une personne au milieu qui les recopie à la main. Cela fonctionne, jusqu’à ce que le volume augmente – ou jusqu’à l’erreur que personne ne repère pendant un mois.
* Développement et intégration d’API : API REST et GraphQL, intégration de services tiers et de systèmes existants. Nous le réalisons nous-mêmes, ou nous vous trouvons les développeurs.
Quand vos systèmes ne communiquent pas
Développement d’API sur mesure, et les intégrations qui vont avec
Une API, c’est la façon dont un système permet à un autre de l’utiliser sans personne entre les deux. Nous en développons, et nous assurons aussi l’intégration d’API qui va autour : connecter les outils que vous payez déjà, extraire des données d’un système qui n’a jamais été prévu pour les partager, et faire en sorte que l’ensemble continue de fonctionner quand l’un des deux côtés change.
L’essentiel de ce travail est peu spectaculaire et très concret. Ce qui compte, c’est qu’il soit documenté, versionné et supervisé, pour que l’intégration fonctionne encore dans deux ans et que quelqu’un d’autre que son auteur puisse la modifier.
Deux façons d’y arriver
01
Nous le développons
En tant qu’entreprise de développement d’API, nous prenons le travail en charge sous forme de projet : conception, développement, documentation et passation. La meilleure option quand le besoin est défini et que vous préférez recevoir le résultat plutôt que piloter le travail.
02
Nous vous trouvons les développeurs
Recrutez plutôt des développeurs API dans votre propre équipe, en CDI ou en mission. La meilleure option quand l’intégration est un travail continu et que le savoir doit rester dans votre entreprise.
Ce que nous développons
Ce que
nous développons
Des services de développement d’API de bout en bout – conseil, conception, réalisation et documentation – ainsi que les services d’intégration logicielle qui les accompagnent.
Voir aussi : Développement de logiciels sur mesure · Constitution d’équipes et recrutement · Blog (en anglais) : AI chatbots for business: what they can and cannot do · Blog (en anglais) : API integration: what it involves and what goes wrong
API REST et GraphQL
Conçues pour être utilisées par quelqu’un qui ne les a pas écrites
Intégration d’API tierces
Connecter les services dont vous dépendez déjà
Intégration de systèmes existants
Des services d’intégration pour des logiciels jamais prévus pour partager leurs données
Webhooks et diffusion d’événements
Avec relances, gestion de l’ordre et historique de ce qui a été envoyé
Authentification et limitation de débit
OAuth, clés, quotas et cas d’abus
Documentation et SDK
Ce qui décide si quelqu’un l’adopte ou non
Versionnage et migration
Faire évoluer une API sans casser les applications qui l’utilisent
Supervision et support
Savoir qu’une intégration est en panne avant que votre client ne vous le dise
Réponses
claires
Ce que l’on nous demande avant que tout commence – y compris ce que nous ne pouvons pas promettre.
Tout dépend de qui l’utilise. REST est généralement le bon choix par défaut pour une API publique ou destinée à des partenaires, et pour tout ce qui doit pouvoir être mis en cache simplement. GraphQL se justifie quand de nombreux clients différents ont besoin des mêmes données sous des formes différentes, et que vous ajouteriez sinon un endpoint par semaine. Nous vous dirons lequel votre situation demande, pas celui que nous avons envie de développer.
C’est l’essentiel du travail. Les systèmes hérités, et les services qui n’ont jamais été conçus pour communiquer entre eux, sont la règle plutôt que l’exception : prestataires de paiement et de CRM, bases de données internes, plateformes dont la seule interface est un dépôt de fichiers ou un écran.
Elles font partie du travail, ce ne sont pas des options. L’authentification, le versionnage, la limitation de débit, la gestion des erreurs, la documentation et les tests qui empêchent une modification de casser une application cliente : c’est cela qui décide si une API est encore utilisable dans deux ans.
À vous. Le code, la documentation et les comptes vous appartiennent par défaut, dans vos propres dépôts, et vous sont remis au fil de l’eau.
Prochaine étape
Parlons de votre
projet
Dites-nous quels systèmes doivent communiquer entre eux. Nous vous dirons ce qu’il faudrait, si vous avez besoin d’un projet ou d’une personne – et, franchement, si nous ne sommes pas les bonnes personnes pour cela.