API entre logiciels d’entreprise: exigences, contrôles et données personnelles

Ce que relie réellement une API entre deux logiciels d’entreprise

Une API (Application Programming Interface, interface de programmation d’applications) est un pont logiciel qui permet à des applications différentes de communiquer et d’échanger des données. En entreprise, elle sert à exposer des flux d’intégration et à relier applications, systèmes, processus et données. Il ne suffit pas de faire dialoguer deux programmes: il faut faire circuler l’information le long d’un parcours défini, avec un point qui la fournit et un autre qui la consomme.

L’impact opérationnel concerne ceux qui gèrent les processus et les systèmes. Les opérations sont simplifiées, les workflows répétitifs automatisés et les informations mises à jour en temps réel, sans copier-coller d’un écran à l’autre ni recharger un fichier. Une commande saisie dans l’ERP peut mettre à jour simultanément la logistique, la facturation et le service clientèle. Une modification des données de base peut se propager à tous les systèmes qui les utilisent.

En pratique, la différence entre un appel unique et une gestion structurée des intégrations est déterminante. La première résout un cas ponctuel: un système lit une donnée provenant d’un autre, une seule fois. La seconde constitue un ensemble organisé de flux, impliquant plusieurs systèmes, avec des formats convenus, des responsabilités définies et un suivi dans le temps. On bascule dans ce second scénario chaque fois que l’intégration relie plus de deux applications, touche des données alimentant des processus critiques ou doit supporter des changements de version, de nouvelles fonctionnalités ou des remplacements de logiciels. Ce sont les situations où un appel isolé devient une intégration à concevoir, documenter et maintenir.

Intégration isolée vs intégration structurée: différences clés

Les exigences qui rendent une intégration durable dans le temps

La première exigence est la clarté du flux. Pour chaque intégration, il convient d’établir qui expose la donnée et qui la consomme, avec quel format, à quelle fréquence et dans quelle direction. Un flux décrit de manière ambiguë génère des intégrations qui fonctionnent lors des tests et échouent en production. Les deux parties interprètent différemment les champs obligatoires, les valeurs admises et les cas limites (enregistrements manquants, doublons, corrections ultérieures).

Sur le plan technique, une intégration durable prévoit quatre éléments récurrents. Le versionnement, pour introduire des modifications sans interrompre les consommateurs existants. La documentation destinée aux développeurs, avec les points de terminaison (endpoints), les paramètres acceptés et les réponses d’erreur attendues. La gestion des accès entre systèmes: qui peut appeler quelle interface et avec quelles identifiants. La gestion du cycle de vie des API, de la publication au retrait, y compris les versions dépréciées.

Sécurité des API: quels contrôles prévoir avant d’ouvrir un canal

La sécurité des API consiste à mettre en œuvre des contrôles et des protocoles pour empêcher les attaques ou les accès non autorisés. Chaque endpoint exposé constitue une surface d’attaque: c’est un canal accessible depuis l’extérieur de l’application, conçu pour transférer des données. Il peut donc être exploité par quiconque souhaite les lire, les altérer ou les bloquer.

Les contrôles à concevoir avant d’ouvrir le canal se divisent en quatre domaines. Authentification: l’appelant doit prouver son identité avec des identifiants dédiés au système, non partagés avec des utilisateurs humains. Autorisation: une fois l’appelant identifié, il faut déterminer à quelles ressources et opérations il a droit, en appliquant le principe du moindre privilège plutôt que d’accorder un accès généralisé.

Protection des endpoints: limitation du nombre d’appels, validation des données reçues, gestion contrôlée des réponses d’erreur. L’objectif est de ne pas transformer l’endpoint en porte ouverte ou en source d’informations utiles aux attaquants. Observabilité: journalisation des appels et de leurs résultats, afin de reconstituer les anomalies et les tentatives suspectes.

La surveillance continue n’est pas un ajout à la sécurité: elle en est une composante. Le comportement des API doit être surveillé dans le temps, car les conditions évoluent avec l’usage, l’évolution du logiciel et les tentatives d’abus. Ceux qui gèrent l’intégration doivent disposer d’outils pour détecter des volumes anormaux, des échecs d’authentification répétés, des appels vers des endpoints retirés ou une augmentation des réponses en erreur. Ils doivent intervenir avant que l’événement ne devienne un incident sur les données.

Lorsque des données personnelles transitent par les API: le cadre de la LPD en Suisse

La loi fédale sur la protection des données s’applique au traitement de données personnelles de personnes physiques par des privés et des organes fédéraux. Pour ceux qui intègrent des logiciels d’entreprise, la conséquence est directe. Si des données personnelles telles que le nom, l’adresse, les coordonnées, des informations sur les clients ou les employés transitent par une API, ce traitement relève du champ d’application de la loi.

La conception des flux reflète les principes généraux du traitement, qui se traduisent concrètement par des choix techniques. Décider quels champs doivent réellement transiter, en évitant d’exposer des objets entiers lorsque seuls trois attributs sont nécessaires. Déterminer où et pendant combien de temps les données sont conservées à destination. Définir qui peut interroger l’endpoint et voir la réponse. Garantir que la donnée reste correcte tout au long du parcours, de la source à la copie.

Ce sont des décisions à prendre lors de la conception de l’intégration, et non à ajouter après coup. Avec des flux actifs et des données distribuées sur plusieurs systèmes, corriger la minimisation ou la conservation nécessite des interventions sur des applications déjà en production.

Les personnes concernées peuvent faire valoir leurs droits auprès du responsable du traitement. Ce dernier doit donc être en mesure de répondre: savoir quelles données personnelles sortent de quel système, via quelle intégration, vers quel destinataire et dans quelle finalité. Un inventaire des flux passant par les API est, de ce point de vue, avant tout un outil de conformité plutôt que de documentation technique.

L’autorité de surveillance est le Préposé fédéral à la protection des données et à la transparence (PFPDT). Par décision du 17 avril 2026, devenue définitive après l’expiration du délai de recours, le PFPDT a sanctionné les entreprises du secteur de la mode Cream della Cream et Philipp Plein en relation avec le marketing direct et le droit d’opposition.

De la cartographie des flux au contrôle périodique: comment structurer le projet

Étape 1 – Cartographie. Lister les systèmes impliqués et, pour chaque flux prévu, indiquer le système qui expose, le système qui consomme, les données échangées, la fréquence et la finalité commerciale. Dès cette étape, il convient de mettre en évidence les champs contenant des données personnelles et la personne, au sein de l’entreprise, responsable de ce traitement. Le résultat constitue la base permettant de justifier tous les choix ultérieurs, y compris ceux relatifs à la sécurité.

Étape 2 – Exigences et sécurisation. Pour chaque flux, définir le format, le versionnement et la documentation destinée aux développeurs. Établir l’authentification et l’autorisation pour le système appelant, avec des permissions limitées aux opérations nécessaires. Prévoir un environnement de test séparé de celui de production. Définir dès le départ les journaux (logs) et les métriques: sans eux, la surveillance ultérieure est impossible.

Étape 3 – Données personnelles. Vérifier quelles données personnelles transitent. Appliquer la minimisation en réduisant les champs échangés à ceux strictement nécessaires. Établir les durées de conservation et les règles de suppression dans les copies en aval. S’assurer de pouvoir répondre à une demande de la personne concernée en reconstituant le parcours de la donnée. Celui qui présente le projet en interne doit pouvoir indiquer qui est le responsable du traitement et qui, entre l’informatique et la conformité, supervise cet aspect.

Étape 4 – Exploitation et contrôle périodique. Après le déploiement, l’intégration entre en phase de maintenance. Mise à jour des versions et révision périodique de la liste des flux et des champs échangés. Cela permet de vérifier qu’aucune donnée ou aucun accès non prévu n’est apparu.