API critique : cadrer la continuité avant la première panne

Une API peut fonctionner correctement pendant des mois puis devenir le point de blocage d’un processus métier : commandes non transmises, statuts non actualisés, synchronisation interrompue ou équipe support sans moyen de distinguer un incident réseau d’une erreur de données. Le problème ne se résout pas uniquement avec un meilleur composant technique. Il faut décider à l’avance ce que l’entreprise accepte de perdre, de retarder ou de traiter autrement lorsque l’API n’est plus disponible.

Le scénario suivant est volontairement hypothétique : une PME utilise une API pour transmettre des demandes entre son application commerciale et un outil d’exploitation. Une coupure de quelques heures ne met pas nécessairement l’activité à l’arrêt, mais elle peut créer des doublons, des demandes oubliées et des écarts entre les deux systèmes. Le cadrage doit donc porter sur le flux, les responsabilités et la reprise, pas seulement sur le point d’accès réseau.

Étape 1 : nommer le service réellement dépendant de l’API

Commencez par décrire le service métier qui dépend du flux. « L’API doit rester disponible » est trop vague pour arbitrer un budget ou une prestation. Il faut préciser ce que la panne empêche, ce qui peut attendre et ce qui doit continuer sous une autre forme.

• Quel événement déclenche l’appel : commande, création de client, mise à jour de stock ou demande d’intervention ?
• Quelle donnée fait foi pendant l’indisponibilité : le système émetteur, le système récepteur ou un registre temporaire ?
• Quel délai maximum est acceptable avant reprise du flux ?
• Quelles opérations peuvent être mises en attente sans bloquer l’utilisateur ?
• Quelles actions exigent une intervention humaine ou une validation avant rejeu ?

Cette première description évite de confondre disponibilité technique et continuité métier. Une API peut répondre à une requête tout en transmettant une donnée incomplète ou obsolète. Le cadrage doit donc associer chaque flux à un résultat attendu et à une personne capable de décider en cas d’écart.

Étape 2 : choisir un mode dégradé compréhensible

Un mode dégradé est une manière prévue de poursuivre tout ou partie du service lorsque le flux nominal ne peut plus être utilisé. Il ne signifie pas forcément conserver toutes les fonctions. Dans une PME, trois options sont généralement à comparer.

Le choix dépend du coût de l’erreur et de la capacité à reconstituer l’historique. Une file d’attente convient mieux à un flux répétitif et traçable. Un traitement manuel peut dépanner un faible volume, mais devient risqué si personne ne sait comment rapprocher les données après la reprise. Un fonctionnement partiel doit être explicite : l’utilisateur doit savoir ce qui a été accepté, différé ou refusé.

Étape 3 : cartographier les responsabilités du flux

Un incident d’API traverse souvent plusieurs périmètres : réseau, authentification, application émettrice, gestionnaire d’API, système récepteur et support métier. Le contrat de prestation doit identifier qui observe chaque étape et qui peut prendre une décision.

• Le propriétaire métier confirme l’impact et la priorité du flux.
• Le propriétaire applicatif vérifie la cohérence des données et l’état des traitements.
• L’équipe réseau contrôle les routes, filtrages, certificats et dépendances de connectivité.
• Le gestionnaire d’API suit les quotas, les erreurs, la disponibilité et les accès.
• Le support coordonne l’information des utilisateurs et l’escalade.

La recommandation de la CNIL sur les API rappelle que les rôles techniques des acteurs ne suffisent pas à déterminer leur responsabilité juridique. Dans le cadrage, cette distinction se traduit par une matrice simple : qui possède la donnée, qui exploite l’interface, qui autorise l’accès, qui détecte l’incident et qui valide la reprise.

Étape 4 : définir les contrôles réseau et les limites d’usage

Le réseau ne doit pas être traité comme une boîte noire. Pour chaque flux, le prestataire doit rendre visibles les zones traversées, les points de filtrage, les identités techniques, les certificats, les dépendances DNS ou VPN et les chemins de sortie prévus.

Le cadrage doit aussi préciser les limites d’utilisation de l’API : fréquence maximale, volume par période, comportement en cas de réponse lente, traitement des erreurs et stratégie de temporisation. Des limites mal définies peuvent transformer une indisponibilité courte en surcharge lors de la reprise. À l’inverse, une limitation trop stricte peut retarder la résorption d’un stock de demandes.

Pour les traitements critiques, la CNIL recommande de prévoir une solution alternative offrant un niveau de sécurité comparable et de mesurer la disponibilité de l’API. Cette solution peut être une file persistante, un canal temporaire contrôlé ou une procédure manuelle documentée ; elle ne doit pas devenir un contournement permanent des règles d’accès.

Étape 5 : préparer la détection, la preuve et la reprise

Une continuité exploitable repose sur des preuves courtes. L’équipe doit pouvoir répondre à quatre questions : quelle demande a été émise, a-t-elle été acceptée, quel résultat a été reçu et que reste-t-il à rejouer ?

• Un identifiant de corrélation commun aux systèmes concernés.
• Un état lisible : reçu, en cours, confirmé, rejeté, à reprendre ou abandonné.
• Un journal des tentatives, sans recopier inutilement les données sensibles.
• Une procédure de rapprochement entre les deux systèmes après rétablissement.
• Un rapport de reprise indiquant les éléments traités, échoués et vérifiés.

La recommandation technique de la CNIL insiste sur la journalisation des accès et actions, la documentation des limites de l’API, l’information lors des interruptions programmées et la révocation des accès devenus inutiles. Ces éléments sont directement transposables dans les livrables attendus d’un projet de continuité.

Étape 6 : organiser une vérification sans promettre un test fictif

Une continuité ne se prouve pas par une simple capture d’écran indiquant que l’API répond. Le prestataire doit proposer un scénario de vérification adapté au périmètre réellement disponible.

1. Déclencher une demande représentative avec une donnée de test maîtrisée.
2. Interrompre le flux selon une procédure autorisée et réversible.
3. Vérifier le comportement de l’application émettrice et du système récepteur.
4. Contrôler l’état de la demande, la conservation de la preuve et l’absence de doublon.
5. Rétablir le service puis exécuter la reprise prévue.
6. Faire valider le résultat par le métier, l’IT et l’exploitation.

Si l’environnement ne permet pas encore ce scénario, il faut le présenter comme un test à réaliser, non comme une preuve acquise. Le livrable peut alors être un protocole de vérification avec prérequis, données autorisées, critères d’arrêt et résultats attendus.

Étape 7 : demander des livrables qui permettent d’arbitrer

Une prestation de cadrage utile doit laisser des documents réutilisables lorsque le projet évolue ou qu’un autre intervenant prend le relais. Demandez au minimum :

• une cartographie des flux API et des dépendances réseau ;
• une fiche par flux avec propriétaire, criticité, délai de reprise et mode dégradé ;
• une matrice des responsabilités et des contacts d’escalade ;
• un registre des erreurs, états intermédiaires et règles de rejeu ;
• un schéma des contrôles d’accès, certificats, secrets et points de révocation ;
• un protocole de test de continuité avec critères d’acceptation ;
• un plan de reprise et de rapprochement après indisponibilité.

Le cadrage doit également préciser ce qui n’est pas couvert : flux externes non documentés, dépendance fournisseur, traitement manuel non testé ou absence de données représentatives. Ces limites évitent de transformer une hypothèse de continuité en promesse de disponibilité absolue.

Le point de décision pour une PME

Une PME n’a pas besoin de construire un dispositif complexe pour chaque API. Elle doit d’abord isoler les flux dont l’arrêt menace réellement l’activité, puis choisir un mode dégradé compréhensible, une responsabilité clairement attribuée et une preuve de reprise vérifiable. Le bon prestataire ne remet pas seulement un schéma réseau : il relie le flux à une décision métier, aux contrôles d’exploitation et aux actions attendues pendant l’incident.

Pour compléter ce cadrage, consultez aussi Mise en production sensible : préparer le jour J sans découvrir les risques en direct et Droits applicatifs : 9 décisions à cadrer avant la recette.