Intégration de données
Un parc d’API nécessite une architecture, des règles de gouvernance et des outils adaptés. Cet article présente les principaux risques et les composants utilisés pour sécuriser et maintenir les interfaces.
L'idée d'une interface de programmation applicative remonte aux débuts de l'informatique. Ce qui a changé, c'est le poids qu'on lui fait porter. Les bibliothèques et les systèmes d'exploitation exposaient des routines et des protocoles dans les années 1960 et 1970. Les API ont gagné en capacité au cours des années 1980 et 1990, et l'arrivée de l'internet public en a fait le moyen par lequel les systèmes dialoguent au-delà des frontières des organisations.
SOAP et REST ont facilité les échanges entre applications. Leur utilisation doit être accompagnée de règles d’architecture et de gestion du cycle de vie des API.
Nous travaillons depuis des années sur l'intégration de données à travers les plateformes B2B, la SOA, l'ESB, le message queuing, la transformation et les API. Les mêmes problèmes reviennent.
Quand un parc d'API se construit sans outillage de gestion ni processus de contrôle, les organisations se retrouvent avec des milliers d'API dont l'existence n'est pas toujours connue et que personne n'ose modifier parce que les conséquences sont incertaines. Le compte augmente, les doublons se multiplient, et des API parallèles font presque le même travail sans que personne ne gouverne leur évolution.
La gestion des versions doit préserver la compatibilité avec les applications consommatrices. Une politique de versioning et de dépréciation permet de planifier les évolutions et de maîtriser les dépendances.
La maintenance des API couvre la correction des défauts, la sécurité, les performances et les évolutions fonctionnelles. Ces activités nécessitent un budget et une planification.
Les dépendances cycliques entre API créent des boucles où A a besoin de B et B a besoin de A. Le débogage comme la montée de version deviennent difficiles, et des processus se bloquent d'une manière pénible à diagnostiquer.
La montée en charge nécessite de suivre les temps de réponse, les volumes et les pics de trafic. L’architecture doit répondre aux objectifs de performance et de disponibilité.
Une documentation à jour facilite l’adoption des API et réduit les erreurs d’implémentation. Elle doit préciser les contrats, les formats, les erreurs et les modalités de versioning.
Notre approche associe API management, sécurité, gestion des données et processus de développement. Les composants ci-dessous sont sélectionnés selon les besoins du projet.
Contrôler et exposer les API pour que les consommateurs soient identifiés et l'usage mesuré. Utiliser une plateforme de gestion pour superviser, protéger, distribuer et analyser. Le résultat est une meilleure sécurité, une visibilité réelle sur les usages et un cycle de vie pilotable. Bien menée, cette démarche permet aussi de monétiser l'usage et de conduire les relations partenaires sur des éléments factuels.
Découpler la consommation des API des sources de données situées derrière, avec une couche intermédiaire entre les API et les applications. On y gagne de la modularité, une maintenance plus simple et des services réutilisables.
Donner accès à l'information nécessaire dans le respect de la réglementation, des règles de sécurité et du traitement des données sensibles. La virtualisation supprime le besoin d'extraire et de dupliquer. Les coûts de stockage et de traitement baissent, les obligations de confidentialité sont tenues, et l'accès s'améliore. Elle supprime aussi le réflexe d'écrire une API pour chaque besoin interne de court terme.
Déplacer la donnée de manière sûre et efficace à travers les protocoles que les partenaires utilisent réellement dans le monde, sans renoncer au débit. Meilleure sécurité des données, meilleure absorption du volume de transactions, plus d'interopérabilité.
Sortir la complexité du traitement de données de l'API elle-même et la placer dans des outils conçus pour cela. La performance des API s'améliore, la complexité baisse, et l'intégration devient plus facile à maintenir.
Définir comment une API est créée et maintenue avant que le parc ne grossisse. C'est ce qui arrête la prolifération et la duplication, et cela réduit le coût de développement en évitant le travail plutôt qu'en le rattrapant après coup.
Notre approche combine API management, SOA, data virtualisation, échanges B2B et outils de transformation. Un processus de développement commun permet de gérer leur évolution et leurs dépendances.
Blog
Intégration de données
La transformation de messages SWIFT et EDI nécessite des mappings, des règles de validation et une exploitation adaptée. Le modèle as a service permet de regrouper ces capacités dans un service dédié.
Solutions IBM
La migration des messages SWIFT MT vers MX concerne les formats, les mappings, les interfaces et les tests avec les contreparties. Notre approche couvre la conversion et l’intégration dans le SI existant.
Groupe et événements
Les appels d’offres publics IT demandent des références, des compétences techniques et une organisation de delivery adaptée. L’écosystème Alan Allman Associates permet d’associer des expertises complémentaires.
Nos experts peuvent analyser votre contexte et définir les prochaines étapes : échange technique, assessment ou accompagnement projet.
