Application Programming Interface (API)

API est l’abréviation de Application Programming Interface (interface de programmation d’applications). Une API est une connexion standard entre des systèmes informatiques qui leur permet d’échanger des données et de collaborer facilement. Tout comme les gens doivent parler la même langue pour se comprendre, une API garantit que la communication de base entre les systèmes informatiques est bien gérée. Grâce aux API, nous pouvons rapidement ajouter de nouvelles fonctions aux systèmes et/ou connecter de nouveaux systèmes.

Dans cet « API pour les nuls », nous répondrons d’abord à la question « Qu’est-ce qu’une connexion API ? » et nous vous en dirons un peu plus sur la façon dont une telle API est structurée et utilisée. Ensuite, nous donnerons quelques exemples de la manière dont les API contribuent à la numérisation dans divers secteurs. Nous décrivons également les différents types d’API et leurs caractéristiques. Enfin, nous expliquons les avantages d’une API et montrons comment les API sont utilisées pour connecter de manière flexible notre plateforme HelloID aux différents systèmes sources et cibles de nos clients.

Qu’est-ce qu’une API ?

Aujourd’hui, nous gérons de plus en plus de choses en ligne. En un seul clic sur votre smartphone ou votre ordinateur portable, vous pouvez par exemple d’accéder aux actualités, consulter vos médias sociaux, réserver un vol, etc. Pour rester sur ce dernier exemple, une application ou un site web de voyage ne peut pas fonctionner de manière autonome. Par le biais d’une telle application, vous indiquez où vous voulez aller, avec combien de personnes vous voulez voyager et quand. L’application doit ensuite avoir accès à diverses compagnies aériennes pour trouver les vols adéquats et vous les présenter.

De nos jours, il existe un nombre incalculable de compagnies aériennes et d’applications de voyage. La dernière chose que nous souhaitons, c’est de devoir rédiger des spécifications détaillées de manière individuelle pour chaque compagnie aérienne ou agence de voyage. C’est la raison pour laquelle des API ont été développées afin que les applications de voyage puissent demander des informations à ces systèmes de réservation d’une façon centralisée. De la même manière, des sites comme Booking.com utilisent des API pour inclure des loueurs de logements individuels dans leur plateforme. Un autre exemple est celui des assureurs qui utilisent les API pour connecter facilement les établissements de santé. Quant aux banques, elles permettent à leurs clients de relier leur compte bancaire à leur progiciel de comptabilité en ligne grâce à une API. Les API sont des connexions standardisées qui nous permettent de connecter et de faire collaborer des systèmes informatiques rapidement, en toute sécurité et de manière fiable dans le monde en ligne actuel. Mais comment fonctionne une telle API ?

Comment fonctionne une API dans la pratique ?

Tout d’abord, vous devez vous mettre d’accord sur certaines questions techniques et pratiques dans le cadre d’une telle connexion API pour que la communication entre les systèmes soit possible. Par exemple, nous convenons d’envoyer toutes les informations en utilisant le protocole HTTP sur l’internet. Et que nous utilisions un certain format pour les données, tel que XML ou JSON. Il existe plusieurs formats d’API techniques standard (tels que l’API REST) dans lesquels de tels accords généraux ont déjà été définis. Il n’est donc pas nécessaire de consacrer beaucoup de temps à la conception d’une API ; il s’agit principalement de faire le bon choix. Dans la suite de ce blog, nous expliquerons plus en détail certains de ces formats d’API techniques (les API REST, SOAP, RPC et GraphQL).

Ce qui rend chaque API unique, ce sont les données et les instructions que les systèmes peuvent s’envoyer les uns aux autres par l’intermédiaire d’une API. Il existe également des accords sur ce que le système récepteur fera de ces données. Avec une telle API, vous pouvez en fait commander à distance un autre système. D’où le terme d’interface de programmation d’applications : Vous pouvez en quelque sorte programmer une application à distance à l’aide d’instructions que vous envoyez à ce système par l’intermédiaire d’une interface.

La meilleure métaphore pour décrire une API est de la comparer au serveur d’un restaurant. Vous commandez un bol de soupe au serveur. Le serveur se rend ensuite à la cuisine et transmet la commande au chef. Vous n’avez pas besoin de vous rendre vous-même auprès du chef, ni de lui expliquer comment préparer une soupe.

Comment cela fonctionne-t-il avec la connexion entre le système de réservation et l’application de voyage ? Tout d’abord, ils peuvent convenir d’utiliser une API REST. Grâce à cette API, les éléments suivants peuvent être échangés, par exemple :

• L’application de voyage envoie les détails du voyage (destination, date, nombre d’enfants/d’adultes) à plusieurs systèmes de réservation via l’API.
• Les systèmes recherchent, sur la base des données reçues, les vols pertinents, vérifient s’il y a de la place et quels sont les prix. Ces données sont ensuite renvoyées à l’application.
• L’application de voyage présente au client tous les vols disponibles.
• Si le client a choisi un vol, l’application de voyage envoie une demande de réservation au système de réservation concerné. Le système traite cette demande et réserve le vol.
• Le système de réservation envoie une confirmation et fournit des instructions de paiement. Etc. etc.

Grâce à cette API, nous savons comment l’application de voyage et les systèmes de réservation fonctionnent techniquement ensemble. Et ce qui est pratique, c’est que si les compagnies aériennes reçoivent de nouvelles demandes de connexion de la part d’autres applications de voyage, elles peuvent utiliser la même API. Tous les détails sont déjà définis dans l’API, et c’est presque « plug and play » (prêt à l’emploi).

Exemples d’API

Comme dans le cas des agences de voyages, on trouve d’innombrables API dans tous les secteurs. Il s’agit parfois d’API utilisées à l’échelle du secteur pour connecter des applications. Mais il existe aussi des API plus universelles dont l’utilisation est beaucoup plus large. Par exemple, si vous souhaitez utiliser Google Maps sur un site web ou dans une application, vous pouvez le faire avec l’API Google. Vous trouverez ci-dessous quelques exemples d’API utilisées dans différents secteurs.

API dans le secteur de la Santé

Le secteur de la santé se numérise à un rythme très rapide. Les établissements de santé utilisent de nombreux systèmes, allant de la bureautique classique aux applications spécifiques aux soins de santé et aux systèmes médicaux. Il s’agit souvent de logiciels standard utilisés dans différentes organisations et qui doivent pouvoir être connectés de diverses manières à d’autres systèmes. Les systèmes de DPI (dossier patient informatisé) comme par exemple Easily, Hopital Manger, les systèmes Dedalus, Cariatides, etc sont des solutions logicielles complètes destinées à la gestion du parcours du patient. Pour connecter ces systèmes à d’autres systèmes nous pouvons utiliser des API afin de gérer par exemple leur accès par le personnel médical soignant.

API dans le secteur Publique

Les municipalités sont des organisations complexes dotées d’une multitude de systèmes. De nombreuses tâches concernent des questions à long terme telles qu’une demande de permis, une demande de subvention ou le renouvellement d’une pièce d’identité. Ces questions sont gérées par ce que l’on appelle un système de dossiers, dans lequel sont stockées toutes les données pertinentes relatives à un dossier. Un système de dossiers nécessite de nombreuses interfaces. Par exemple, avec France Services afin de pouvoir répondre rapidement et de manière adéquate aux questions des citoyens. D’autres systèmes TIC municipaux consultent également des informations provenant d’un tel système. C’est pourquoi il est désormais prescrit que les systèmes de gestion des dossiers utilisent ce que l’on appelle les « API pour le travail orienté dossier ». Les municipalités ne doivent plus copier les données entre les systèmes ; elles peuvent simplement consulter les données directement dans le système source. Il s’agit d’un exemple d’API municipale visant à accélérer la numérisation des municipalités.

API dans le secteur Privié

Le service des ressources humaines (RH) joue progressivement un rôle de plus en plus important dans les entreprises. Auparavant, il s’agissait principalement d’un « service du personnel » administratif. Aujourd’hui, son rôle consiste davantage à trouver et à conserver les talents. De plus, dans un nombre croissant de processus, de la paie à l’émission de comptes utilisateurs, le système RH est utilisé comme système source principal. C’est pourquoi les systèmes de ressources humaines modernes, disposent d’API permettant de transmettre les données de ressources humaines à d’autres systèmes.

La différence entre les API et les Webservices

Les termes API et Webservice sont parfois utilisés de manière interchangeable. Il est donc bon de clarifier ce terme. Avec un Webservice, vous pouvez rendre des applications accessibles à des systèmes externes via l’internet. Une boutique en ligne, par exemple, ne doit pas créer ses propres fonctions de paiement. Elle peut facilement être reliée à un prestataire de services de paiement qui gère les paiements à l’aide d’un Webservice.

Un Webservice agit donc comme une API entre le fournisseur de paiement et les boutiques en ligne connectées. Mais il s’agit d’un type d’API très spécifique. Un tel Webservice est purement destiné à la communication via l’internet, son utilisation est définie dans un format spécifique (Web Service Definition Language, WSDL) et il utilise toujours certaines normes telles que SOAP, HTTP et XM.

Un Webservice est donc l’un des différents types d’API utilisés aujourd’hui. Il existe également de nombreuses API qui fonctionnent différemment. Par exemple, elles utilisent d’autres types de réseaux, d’autres normes ou d’autres formats de données. Il existe également des API qui n’utilisent pas du tout de réseau et qui servent à connecter directement des systèmes. Enfin, il existe également des API qui permettent à différentes applications d’un même système de fonctionner ensemble. Par exemple, un système d’exploitation comme Windows possède d’innombrables API qui permettent à différentes applications, périphériques, etc. de fonctionner ensemble sur votre ordinateur. Un webservice est donc une API, mais toutes les API ne sont pas des Webservices.

Les différents types d’API et leurs avantages

Qu’est-ce qu’une API REST (JSON, XML, HTML) ?

REST signifie Representational state transfer (transfert d’état représentationnel). L’API REST – ou plus exactement : RESTful API – a été développée en 2000 et est populaire en raison de sa flexibilité. Les informations peuvent être envoyées par le biais de différents protocoles, même si – en particulier dans les environnements web – le protocole HTTP est généralement utilisé, de sorte qu’aucun logiciel API supplémentaire n’est nécessaire pour l’utiliser. Les méthodes HTTP standard telles que GET, POST, PUT et DELETE peuvent être utilisées et, comme les messages sont courts, les API REST sont relativement rapides. Une API REST est également sans état ; elle ne stocke aucune information de session, de sorte que chaque demande adressée à un système doit contenir toutes les informations nécessaires.

Les API REST prennent en charge différents formats de données. Il n’y a pas que le format JSON (JavaScript Object Notation) qui, avec sa structure relativement légère et simple, est populaire dans les environnements web. Mais aussi le format XML (eXtensible Markup Language), plus structuré, qui est principalement utilisé pour les données plus complexes. En outre, le HTML (HyperText Markup Language), le langage de balisage des pages web, est une option. Les API REST sont particulièrement adaptées aux API « légères » et sont utilisées dans un large éventail de services en ligne, de X à Spotify.

Qu’est-ce qu’une API SOAP (XML) ?

Le protocole SOAP (Simple Object Access Protocol) est déjà un vétéran parmi les protocoles ; il existe depuis 25 ans. Les API SOAP sont principalement utilisées pour les services web et utilisent le protocole HTTP. Toutefois, il existe également des connexions SOAP héritées qui transportent les informations via le protocole SMTP (Simple Mail Transfer Protocol).

SOAP utilise XML. Comme indiqué ci-dessus, il s’agit d’un format d’information plus structuré, qui allonge les messages et ralentit l’échange de données. SOAP est un peu « lourd » pour les applications web simples, mais il convient parfaitement à la prise en charge d’échanges de données et de processus complexes dans les environnements d’entreprise. SOAP offre également des mesures de sécurité plus avancées. Grâce à ces propriétés, SOAP est largement utilisé, par exemple, dans les services de paiement et la communication entre les banques et d’autres environnements métier importants.

Qu’est-ce qu’une API RPC (TCP, UDP) ?

RPC signifie Remote Procedure Call (appel de procédure à distance). Il s’agit d’une approche un peu plus ancienne et l’on peut se demander s’il s’agit vraiment d’une API. Nous avons comparé l’API au serveur du restaurant, une sorte d’homme du milieu. Si vous élargissez cette comparaison, vous pouvez mieux comparer RPC à un visiteur de restaurant qui crie directement au chef qu’il veut de la soupe. Avec la RPC, une application peut appeler directement des fonctions dans le système récepteur. Cela présente des avantages – c’est direct, rapide et puissant – mais la communication n’est pas sécurisée de manière standard et n’est pas non plus très flexible. Si vous voulez que le système fasse autre chose, vous devez à nouveau adapter l’interface. La communication se fait via TCP (Transmission Control Protocol) ou UDP (Datagram Protocol).

Qu’est-ce qu’une API GraphQL (HTTP) ?

GraphQL a été développé par Facebook et est intéressant en raison des options de filtrage étendues et de la possibilité d’envoyer des commandes à différents systèmes simultanément. En fait, vous pouvez déjà filtrer exactement les informations que vous recherchez dans une requête au système, et seules ces données sont ensuite renvoyées. La complexité de plusieurs systèmes connectés vous est épargnée et vous recevez les résultats cohérents de votre requête.

Tableau récapitulatif

	REST API	SOAP API	RPC API	GraphQL API
Général	Basé sur les méthodes HTTP standard (GET, POST, PUT, etc.)	Utilise XML, normalement via HTTP	Appels de procédures simples via des appels de fonctions directs	Langage de requête pour les systèmes distribués
Formats de données	JSON, XML or HTML. Autres options possibles	XML	XML, JSON. Autres options possibles	Généralement JSON, mais peut prendre en charge d'autres formats
Protocoles	Normalement protocoles HTTP, autres options possibles	Peut utiliser différents protocoles, tels que HTTP, SMTP, etc.	Généralement TCP ou UDP	Utilise HTTP, le protocole sous-jacent peut varier
Flexibilité	Plus de souplesse dans les URL des "end point" et les formats de données	Moins flexible, nécessite une définition explicite des structures de données et des actions	Moins flexible, car il appelle directement des méthodes	Offre un haut degré de flexibilité et permet au client de spécifier les données requises.
Vitesse	Généralement plus rapide en raison d'une moindre surcharge.	Il peut y avoir de la surcharge ce qui peut le rendre plus lent	Peut être rapide grâce à des appels directs à l'application cible	Efficace car il ne récupère que les données nécessaires
Securité	Prise en charge, mais attention à la mise en œuvre de l'authentification et de l'autorisation.	Peut offrir des options de sécurité complexes (par exemple, WS-Security)	Nécessite des mesures de sécurité supplémentaires	Fournit une sécurité au niveau de chaque champ

Les avantages de l’utilisation d’une API

Avec l’aide des API, vous pouvez facilement combiner les fonctions de différents systèmes pour créer de nouvelles applications. Vous réutilisez autant que possible les applications et les fonctions existantes afin de pouvoir vous concentrer sur les nouveaux sujets. Dans l’exemple de l’application de voyage, le développeur ou responsable peut se concentrer sur le développement de l’application tandis qu’il utilisera autant que possible les fonctionnalités existantes et les connexions API standard pour les données de vol des systèmes de réservation. De cette manière, il pourra se concentrer sur ce qu’il souhaite vraiment développer de nouveau, tandis que la mise en œuvre de la solution dans son ensemble est gérable, sûre et flexible. Nous expliquons cela plus en détail ci-dessous..

Le sentiment de contrôle

L’innovation numérique dépend de la capacité à faire fonctionner facilement différents systèmes ensemble. Ainsi, vous pouvez facilement réutiliser des fonctionnalités existantes ou consulter des données provenant d’autres systèmes. En même temps, cela doit se faire de manière contrôlée. Si vous établissez des connexions ad hoc entre toutes sortes de systèmes et que vous puisez directement dans les logiciels et les données des uns et des autres, vous vous retrouvez rapidement avec une « architecture spaghetti » ; une architecture dans laquelle le moindre ajustement fait vaciller la fonctionnalité, la fiabilité ou la sécurité.

Une architecture avec des API bien développées et documentées donne aux systèmes un accès contrôlé aux fonctionnalités et aux données des autres systèmes. Le propriétaire du système garde toujours le contrôle sur la manière dont ces éléments peuvent être utilisés et les autres systèmes n’ont jamais un accès direct au code. En outre, les ajustements/mises à jour du système ne posent aucun problème. Grâce aux API existantes, les fonctions et données existantes restent accessibles, tandis que de nouvelles fonctionnalités peuvent être proposées, si nécessaire, par une mise à jour de l’API en question. Le système dans son ensemble est « sous contrôle ».

La sécurité de l’API

Il est important de noter que les API modernes font partie intégrante de la sécurité de vos informations. Avant que nous ne commencions tous à travailler à distance et de manière hybride, les réseaux d’entreprise étaient souvent sécurisés comme un château. Dans un tel château, les murs et la porte assurent la sécurité, mais derrière, il n’y a pas grand-chose de plus pour arrêter les intrus. De la même manière, les responsables informatiques se concentraient entièrement sur la sécurité de l’accès à leur réseau d’entreprise. Une fois à l’intérieur de ce réseau, il n’y avait que peu de contrôle sur le comportement des utilisateurs et les connexions entre les systèmes étaient souvent complètement « ouvertes ». Maintenant que nous travaillons tous à distance et dans le cloud, cette sécurité d’accès traditionnelle n’est plus viable.

Le principe de la confiance zéro

Les utilisateurs peuvent accéder à distance aux applications informatiques et les systèmes sont également en contact avec des systèmes extérieurs à leur propre organisation via l’internet. C’est pourquoi les réseaux informatiques modernes doivent être basés sur le principe de la confiance zéro, qui consiste à ne jamais faire aveuglément confiance à quelque chose ou à quelqu’un. Pour chaque session d’utilisateur – et donc aussi pour l’échange d’informations entre les systèmes – il faut se demander qui demande l’accès, quel est son rôle et quels sont les droits d’accès du système. Les API web modernes rendent cela possible. Nous expliquons ci-dessous comment utiliser une API en toute sécurité.

Le Flexibilité

Les organisations dans leur ensemble doivent être en mesure de réagir plus rapidement aux nouvelles évolutions sociétales, aux tendances du marché et aux innovations technologiques. Les technologies de l’information doivent également être plus agiles. Les applications doivent pouvoir être reliées rapidement ou simplement déconnectées. Avec les API modernes, nous y contribuons. La connexion de systèmes nécessite rarement un long projet d’intégration de systèmes ; en général, une API peut être configurée et activée rapidement.

Les systèmes modernes de gestion des ressources humaines en sont un exemple. Ils sont reliés à d’autres systèmes de l’entreprise via des API. Souvent, après quelques années, un autre progiciel RH est choisi. Si un autre progiciel est choisi, une telle migration peut être effectuée rapidement grâce aux API disponibles. Non seulement vous pouvez rapidement connecter la nouvelle application via une API, mais le transfert des données vers le nouveau système peut également être organisé efficacement via des APIs.

Comment déployer une API en toute sécurité ?

Comme expliqué précédemment, les API modernes doivent fonctionner selon le concept de confiance zéro. Nous ne devons donc jamais supposer aveuglément qu’elles sont dignes de confiance dans une interface entre deux systèmes. Tout comme les utilisateurs, les applications doivent s’authentifier (à qui ai-je affaire ?) lorsqu’elles demandent l’accès à une autre application. De même, un système connecté doit disposer de la bonne autorisation (que peut faire quelqu’un ?) pour pouvoir donner des ordres à cet autre système. Il est de plus en plus important de ne donner aux personnes et aux systèmes que l’accès aux fonctions et aux données dont ils ont réellement besoin. D’autant plus que de plus en plus de données personnelles sont envoyées d’un système à l’autre.

Les règles RGPD (Règlement général sur la protection des données)

Le RGPD fixe des règles strictes en la matière. Les systèmes ne peuvent traiter les données à caractère personnel que pour des finalités claires et justifiées. C’est ce qu’on appelle la limitation des finalités et, dans une bonne API, vous pouvez définir la sélection des données de sorte que seules les données dont l’application réceptrice a besoin puissent être partagées. Si vous reliez, par exemple, un système de ressources humaines à un outil de formation, ce système n’a pas besoin de données sur les absences. Ces données doivent donc être exclues pour cette application.

Astuce : Testez votre API
L’autorisation est souvent basée sur la norme OAuth 2.0. Et c’est précisément parce que l’attention est naturellement portée sur l’authentification et l’autorisation des utilisateurs humains qu’il est particulièrement important de tester la sécurité des API.

Des Connexions API efficaces pour la gestion des identités et des accès

Comment utiliser les API au sein d’une plateforme de gestion des identités et des accès (IAM) et quelles sont ces API ? Nous expliquons cela à l’aide de notre plateforme HelloID basée sur le cloud. En tant que plateforme IAM, nous avons des connexions avec ce que l’on appelle des systèmes sources et des systèmes cibles.

• Les Systèmes source sont principalement des systèmes de ressources humaines, tels que People Inc et SAP. Ils alimentent la plateforme IAM en informations sur les nouveaux employés, les changements de fonction, les mobilités internes et les départs. Sur la base de ces informations, nous créons de nouveaux comptes, nous gérons les droits d’accès et, éventuellement, nous désactivons/supprimons les comptes.
• Les Systèmes cible sont les systèmes auxquels nous envoyons ensuite des informations. Une fois que nous avons enregistré un compte d’utilisateur dans HelloID et déterminé les droits d’accès associés, nous créons également les comptes dans, par exemple, l’Active Directory ou Entra ID. Nous envoyons également des informations et des paramètres de compte à des applications métiers telles que Easily/Cariatides/etc. – des systèmes de soins de santé largement utilisé – et à des systèmes de gestion d’incidents tels que Glpi/EasyVista/ServiceNow/Jira/etc.

D’ailleurs, de nombreux systèmes sources, comme CPAGE, ASTRE, ADP.ILUCCA, sont également des systèmes cibles. Pour les nouveaux employés, HelloID crée un compte sur le système RH afin de gérer leurs données personnelles et de consulter leurs congés.

200 connexions logicielles

L’IAM agit donc comme une araignée dans la toile entre tous les systèmes. Pour connecter les systèmes, nous proposons aujourd’hui plus de 200 connecteurs aux systèmes existants. Un aspect fondamental de ces connecteurs est leur capacité à s’intégrer à un large éventail d’API, chacune ayant ses propres caractéristiques et formats spécifiques. Comme expliqué plus haut dans l’article, la nature de ces API varie considérablement – certains systèmes utilisent REST, d’autres SOAP ou GraphQL. En outre, la manière dont les données sont échangées et les exigences en matière d’interrogation des données peuvent varier considérablement d’une API à l’autre. Par exemple, un système RH peut fournir d’un seul coup toutes les données relatives aux employés, tandis qu’un autre système exige d’abord une liste de tous les employés, suivie de requêtes unitaires (appels API) pour chaque employé.

Dans ce paysage complexe, la fonction principale d’un connecteur est de normaliser ces divers flux de données. Indépendamment de la diversité des API et des formats dans lesquels elles fournissent des données, le connecteur les transforme en un format uniforme. Cela garantit la cohérence et la rationalisation de l’échange de données entre les différents systèmes. Outre la conversion des données, un connecteur peut également contenir une logique et des contrôles supplémentaires qui contribuent à une intégration efficace et fiable. Grâce aux connecteurs, HelloID est en mesure de lire les données personnelles et contractuelles, et de créer des comptes et des droits d’accès. L’approche adoptée par HelloID garantit une flexibilité maximale et ne nécessite généralement pas d’adaptation des systèmes connectés. Le connecteur constitue donc un pont entre la diversité des API et les besoins standardisés de notre plateforme IAM.

Le traitement des modifications des l’APIs

Si lee fournisseur d’un système connecté modifie quelque chose dans son API, nous adaptons alors le connecteur. Cela peut également s’avérer nécessaire si l’API d’un système offre davantage de possibilités. Avec certains systèmes cibles, HelloID ne peut plus créer ou supprimer qu’un compte de base en raison des limitations de l’API. Les droits d’accès spécifiques doivent alors toujours être gérés par le système lui-même. Par exemple, dans un système de soins de santé, il faut définir dans le système lui-même qui a accès à quelles données du patient. Dès qu’une telle API est développée par le fournisseur, nous pouvons adapter notre connecteur et dès lors gérer également ces paramètres détaillés directement à partir de HelloID.