Une PME moderne échange en permanence des données avec l’extérieur sans que son dirigeant s’en rende toujours compte : le logiciel de facturation qui interroge la banque, la boutique en ligne qui transmet les commandes au transporteur, le CRM qui synchronise les contacts avec l’outil d’emailing, ou encore l’assistant IA qui interroge une base de connaissances interne. Chacun de ces échanges repose sur une API (interface de programmation applicative), littéralement une porte d’entrée numérique permettant à deux logiciels de communiquer automatiquement. Une porte mal verrouillée, et c’est l’ensemble des données qui transitent par elle qui se retrouve exposé.
Cet article détaille les risques concrets liés aux API, illustrés par des incidents réels survenus en France en 2026, les bonnes pratiques techniques et organisationnelles pour les sécuriser, et la manière dont ce sujet technique s’inscrit directement dans vos obligations réglementaires.
Pourquoi les API sont devenues un enjeu de sécurité pour les PME ?
Il y a dix ans, une PME échangeait rarement des données automatiquement avec l’extérieur : les fichiers s’envoyaient par email, se ressaisissaient manuellement, ou transitaient par des exports/imports ponctuels. Aujourd’hui, l’écosystème logiciel d’une PME (comptabilité, CRM, e-commerce, banque, facturation, outils d’intelligence artificielle) fonctionne comme un réseau de briques interconnectées en temps réel via des API, une approche moins coûteuse et plus flexible qu’un ERP monolithique, mais qui multiplie mécaniquement les points d’accès à sécuriser.
La CNIL a enregistré 6 167 violations de données en France en 2025, un record en hausse de 9,5 % par rapport à 2024, avec plus de 2,6 milliards de données compromises identifiées sur l’année, en progression de 23 %. Une part croissante de ces incidents trouve son origine dans une API mal sécurisée ou mal configurée plutôt que dans une attaque sophistiquée : la porte n’a pas été forcée, elle avait simplement été laissée ouverte.
Ce sujet rejoint directement l’actualité réglementaire : la généralisation de la facturation électronique impose désormais à chaque entreprise française de faire transiter ses factures par une plateforme tierce, une interopérabilité qui repose entièrement sur des échanges API, comme détaillé dans notre article sur le choix d’une plateforme agréée sécurisée pour la facturation électronique.
Le secteur bancaire illustre bien cette généralisation : depuis l’entrée en application de la directive européenne DSP2, les banques françaises sont tenues d’exposer des API permettant à des prestataires tiers autorisés (agrégateurs financiers, outils de comptabilité, solutions de paiement) d’accéder, avec le consentement du client, à ses données de compte ou d’initier des paiements en son nom. Une PME qui connecte son logiciel de comptabilité à son compte bancaire professionnel utilise très concrètement ce type d’API réglementée, ce qui ne dispense pas pour autant de vérifier la robustesse de l’intégration mise en place par son éditeur logiciel.
Les risques : le Top 10 OWASP de la sécurité des API
L’OWASP (Open Worldwide Application Security Project), référence mondiale en matière de sécurité applicative, publie depuis 2019 un classement dédié spécifiquement aux API, distinct de son classement plus général sur les applications web. Sa dernière édition, publiée en 2023, reflète l’évolution des usages : les API exposent désormais autant de logique métier sensible qu’une interface web classique, avec des mécanismes de contrôle souvent moins matures.
BOLA : la faille la plus fréquente, responsable de 40 % des attaques
La vulnérabilité « Broken Object Level Authorization » (BOLA), qui occupe la première place du classement, représenterait à elle seule environ 40 % des attaques recensées contre des API. Le principe est presque trivial : un utilisateur légitimement authentifié modifie un identifiant dans sa requête (par exemple le numéro d’un dossier client dans une URL) pour accéder aux données d’un autre utilisateur, sans qu’aucun contrôle ne vérifie s’il en a réellement le droit. Cette même famille de faille, aussi appelée IDOR (Insecure Direct Object Reference), est l’une des plus anciennes de la cybersécurité, ce qui ne l’empêche pas de rester la plus exploitée en 2026.
Authentification cassée et clés API mal protégées
Deuxième risque majeur, l’authentification cassée permet à un attaquant d’exploiter des jetons volés, des attaques par force brute ou du bourrage d’identifiants pour usurper un accès légitime. Un piège fréquent chez les PME consiste à confondre clé API et authentification robuste : une clé API identifie l’application qui appelle le service, pas la personne qui l’utilise réellement. Pour toute API traitant des données sensibles, la clé API seule doit être complétée par un protocole d’autorisation comme OAuth 2.0 et par une vérification des droits au niveau de chaque ressource demandée.
| Risque | Ce que cela signifie concrètement | Exemple d’impact |
|---|---|---|
| Broken Object Level Authorization (BOLA) | Aucune vérification que l’utilisateur a le droit d’accéder à la ressource demandée | Accès aux données d’un autre client en modifiant un identifiant |
| Authentification cassée | Jetons volés, mots de passe faibles, clé API utilisée seule | Usurpation de compte ou d’application |
| Broken Object Property Level Authorization | Exposition de champs de données non destinés à l’utilisateur, ou modification de champs protégés | Fuite d’informations sensibles ou fraude sur des données modifiables |
| Consommation de ressources non maîtrisée | Absence de limitation du nombre de requêtes (rate limiting) | Saturation du service ou extraction massive de données |
| Mauvaise gestion de l’inventaire des API | API oubliées, obsolètes ou non documentées toujours actives | Point d’entrée invisible pour un attaquant |
L’édition 2023 a également introduit deux nouveaux risques : le Server Side Request Forgery (SSRF), où une API est manipulée pour effectuer des requêtes vers des systèmes internes normalement inaccessibles, et la consommation non sécurisée d’API tierces, qui rappelle qu’une API n’est jamais plus sûre que les services externes auxquels elle fait elle-même confiance, un principe qui rejoint directement les enjeux traités dans notre article sur les attaques par supply chain.
La fuite de l’ANTS : une leçon grandeur nature
L’incident survenu en 2026 sur l’un des services de l’Agence Nationale des Titres Sécurisés (ANTS) illustre parfaitement le risque BOLA à grande échelle. La faille était d’une simplicité déconcertante : il suffisait de modifier un identifiant dans l’URL d’une requête API pour consulter le profil d’un autre usager, sans qu’aucun contrôle d’autorisation ne soit effectué côté serveur. Un attaquant a ainsi pu enchaîner des requêtes sur des identifiants incrémentés pour collecter, à grande échelle, des données d’identité, adresses postales, numéros de téléphone et identifiants de connexion concernant plus de 11,7 millions de profils.
Trois défaillances structurelles ressortent de cet incident, et concernent tout aussi directement une PME qu’une administration : l’authentification fonctionnait normalement, mais la vérification des droits d’accès à chaque ressource avait été négligée ; aucune surveillance n’a détecté des milliers de requêtes séquentielles suspectes visant des identifiants consécutifs ; et l’absence d’inventaire centralisé des API en service a empêché toute réaction rapide une fois la faille découverte. Ces mêmes défaillances se retrouvent dans des incidents touchant directement des entreprises françaises : une fintech française d’épargne a ainsi confirmé en juin 2026 une cyberattaque détectée via une clé d’accès technique compromise sur l’une de ses API, exploitée pour interroger massivement ses données.
Les bonnes pratiques pour sécuriser vos API
Sécuriser ses API ne nécessite pas de réinventer des mécanismes complexes : la plupart des bonnes pratiques reposent sur des standards éprouvés, encore trop rarement appliqués de bout en bout.
- Vérifiez systématiquement les droits d’accès à chaque ressource demandée, jamais uniquement au moment de la connexion
- Combinez clé API et protocole d’autorisation OAuth 2.0 pour toute API exposant des données sensibles
- Limitez la durée de vie des jetons d’accès au strict nécessaire et pratiquez une rotation régulière des clés API
- Mettez en place une limitation du nombre de requêtes (rate limiting) pour empêcher l’extraction massive de données
- Chiffrez systématiquement les données sensibles en transit (TLS) et au repos
- Tenez un inventaire à jour de toutes vos API actives, y compris celles jugées mineures ou temporaires
- Journalisez les accès et surveillez les schémas de requêtes anormaux (volumes, identifiants séquentiels)
Pour une PME sans équipe technique dédiée, un API Gateway (passerelle API) permet de centraliser une grande partie de ces contrôles, authentification, limitation de débit, journalisation, sans devoir les redévelopper pour chaque intégration. Ces principes recoupent directement ceux détaillés dans notre guide sur la gestion des identités et des accès sans DSI et dans notre article sur le déploiement du MFA en PME, deux fondamentaux qui s’appliquent aussi bien aux comptes utilisateurs qu’aux accès applicatifs via API.
La gestion des secrets (clés API, jetons, certificats) mérite une attention particulière : ils ne doivent jamais être stockés en clair dans le code source ou partagés par email, un réflexe qui rejoint directement les bonnes pratiques détaillées dans notre comparatif des gestionnaires de mots de passe pour PME.
Enfin, ces contrôles théoriques ne valent que s’ils sont testés en conditions réelles. Un test d’intrusion ciblé sur vos API expose souvent des failles d’autorisation invisibles lors d’une revue de code classique, notamment sur les intégrations développées rapidement ou héritées d’un ancien prestataire. Notre article sur le pentest pour PME détaille comment préparer ce type d’audit, y compris pour un périmètre limité aux seules API exposées.
NordPass : stockez vos clés API et secrets techniques hors du code source
Coffre-fort partagé pour votre équipe technique, avec des notes sécurisées dédiées au stockage de clés API, jetons et identifiants de service, et un scanner de fuites de données pour détecter tout secret déjà compromis.
Ce que recommande la CNIL sur le partage de données par API
La CNIL a publié des recommandations spécifiques sur la sécurisation des API dès lors qu’elles partagent des données à caractère personnel, en distinguant trois rôles : le détenteur des données, le gestionnaire de l’API, et le réutilisateur des données. Elle invite chaque organisation à évaluer plusieurs facteurs de risque avant d’ouvrir une API : le type d’accès accordé (lecture seule ou écriture), le niveau de sécurité des techniques d’authentification utilisées, la sensibilité des données concernées (données de santé, données bancaires), et la granularité des habilitations accordées à chaque partenaire.
Sur le plan pratique, la CNIL recommande de documenter systématiquement chaque API avec des outils comme Swagger, de valider le format des données échangées, de journaliser les accès, et de formaliser contractuellement les responsabilités de chaque partie impliquée dans le partage. Ces recommandations recoupent directement les obligations plus larges détaillées dans notre article sur les obligations RGPD concrètes des PME : une API qui traite des données personnelles reste soumise à l’ensemble du règlement, y compris lorsque cette API relie deux prestataires plutôt que l’entreprise et un utilisateur final.
API et NIS2 : une brique de la sécurité de la chaîne d’approvisionnement
Pour les entreprises entrant dans le champ d’application de la directive NIS2, la sécurité des API n’est pas qu’une bonne pratique technique facultative : elle s’inscrit directement dans la mesure obligatoire relative à la sécurité de la chaîne d’approvisionnement, détaillée dans notre guide de mise en conformité NIS2. Chaque interface exposée à un prestataire, un client ou un partenaire constitue un point d’interconnexion à cartographier et à sécuriser au même titre que le réseau interne de l’entreprise.
Même pour les entreprises non directement soumises à NIS2, cette approche de cartographie et de contrôle des interconnexions reste pertinente : elle rejoint les principes de segmentation réseau déjà recommandés pour isoler les systèmes sensibles, appliqués cette fois aux interfaces logicielles plutôt qu’aux seuls équipements physiques.
Calculez votre score de conformité NIS2 en 10 minutes
Répondez aux questions et obtenez votre gap analysis personnalisée avec les priorités d’action.
- Auto-diagnostic EE / EI
- Score par domaine de mesures
- Identification des lacunes critiques
- Priorisation des actions correctives
- Résultat immédiat et détaillé
- 100 % gratuit, sans inscription
Ressource recommandée
Guide de mise en conformité NIS2 pour PME 2026
Évitez jusqu’à 10 M€ de sanctions. Auto-diagnostic EE/EI, gap analysis et plan d’action sur 6 mois, dont la sécurisation des interconnexions et des API avec vos prestataires. Sans jargon juridique, actionnable dès la première lecture.
Souveraineté numérique : où sont hébergées vos API ?
Une API n’existe pas dans le vide : elle est hébergée sur une infrastructure, et les données qui transitent par elle héritent du régime juridique de cette infrastructure. Une API hébergée par un fournisseur américain reste, en théorie, exposée au CLOUD Act, cette loi de 2018 qui autorise la justice des États-Unis à réquisitionner des données hébergées par une entreprise américaine, y compris sur des serveurs situés en Europe. Notre guide sur la cybersécurité souveraine pour PME détaille ce risque et les alternatives disponibles poste par poste.
Cette question devient particulièrement concrète avec la multiplication des API d’intelligence artificielle (agents conversationnels, extraction automatique de documents, détection d’anomalies) que de nombreuses PME intègrent désormais à leurs outils métier. Choisir un fournisseur d’API IA hébergé en Europe plutôt qu’aux États-Unis limite l’exposition juridique de ces échanges, sans sacrifier la qualité de service.
Partenaire affilié
Infomaniak AI Tools : une API d’intelligence artificielle hébergée en Suisse
Intégrez des modèles d’IA à vos outils métier via une API entièrement hébergée en Suisse, sans transfert de données vers les États-Unis, une alternative souveraine aux API IA américaines pour vos échanges de données sensibles.
Les ressources gratuites et l’accompagnement
La sécurisation des API reste un sujet technique où l’accompagnement d’un professionnel se justifie souvent, en particulier pour auditer les intégrations existantes. Le dispositif Cybermalveillance.gouv.fr propose une mise en relation avec des prestataires de proximité labellisés ExpertCyber, un repère fiable pour un audit ciblé sur vos intégrations logicielles.
Un premier état des lieux gratuit reste toujours utile avant d’engager un audit approfondi : l’outil Audit Cyber PME de SIAC Media permet d’obtenir un diagnostic rapide de votre exposition en quelques minutes. Si votre entreprise intègre des API d’intelligence artificielle à ses outils métier et que plusieurs collaborateurs sont amenés à configurer ou utiliser ces connexions, le générateur de charte IA de SIAC Media permet de cadrer gratuitement cet usage, y compris la question des clés API partagées entre collaborateurs.
Ressource recommandée
Guide Cybersécurité PME & IA 2026
Protégez votre PME des cyberattaques grâce à l’intelligence artificielle. 41 pages, 6 chapitres, un plan d’action 90 jours. Sans jargon technique, actionnable dès la première lecture.
La checklist complète
Avant de refermer cet article, vérifiez que chacun des points suivants est bien en place pour vos intégrations logicielles.
- Vous disposez d’un inventaire à jour de toutes les API actives dans votre écosystème logiciel
- Chaque accès à une ressource fait l’objet d’une vérification d’autorisation, pas uniquement la connexion initiale
- Vos API sensibles combinent clé API et protocole OAuth 2.0, jamais une clé API seule
- Vos clés API et secrets techniques sont stockés dans un coffre-fort dédié, jamais dans le code source
- Une limitation du nombre de requêtes (rate limiting) est en place sur vos API exposées
- Les accès à vos API sont journalisés et surveillés pour détecter des schémas de requêtes anormaux
- Vous savez où sont hébergées les API tierces (facturation, IA, paiement) que vous utilisez
- Le partage de données via vos API respecte les recommandations RGPD et CNIL applicables
Checklist Cybersécurité PME – Gratuit
29 actions prioritaires pour protéger votre entreprise.
PDF à imprimer · Conformité RGPD & NIS2
Gratuit · Désabonnement en 1 clic
Conclusion
Les API sont devenues le système nerveux de la PME numérique, reliant comptabilité, CRM, paiement, facturation électronique et outils d’intelligence artificielle en un flux continu de données. Cette dépendance impose de traiter leur sécurité avec le même sérieux que celle du réseau interne de l’entreprise : vérification systématique des droits d’accès, authentification robuste au-delà de la simple clé API, limitation des requêtes, inventaire à jour et surveillance des accès. La fuite de l’ANTS, qui a exposé 11,7 millions de profils via une faille aussi ancienne qu’élémentaire, rappelle qu’il ne s’agit pas de menaces théoriques mais de failles concrètes, encore massivement présentes en 2026.
Pour objectiver votre niveau de sécurité actuel, l’outil gratuit Audit Cyber PME de SIAC Media permet d’obtenir un diagnostic en quelques minutes, et notre guide complet de la cybersécurité pour PME en 2026 ainsi que notre panorama complet des technologies IA en cybersécurité pour PME approfondissent chacun des sujets abordés ici pour qui souhaite structurer durablement sa démarche.
