Une API IA ferme : le plan de continuité en 10 étapes

Pourquoi une fermeture doit être préparée comme une interruption

Un fournisseur peut retirer un modèle, une fonction ou une API pour des raisons techniques, économiques, réglementaires ou stratégiques. Même avec un préavis, le risque ressemble à une interruption programmée : certaines tâches s’arrêtent, des données deviennent difficiles à exporter et les coûts de changement se concentrent sur quelques jours.

Le NIST définit la planification de continuité comme un ensemble coordonné de procédures et de mesures permettant de récupérer systèmes, opérations et données après une perturbation. Une TPE n’a pas besoin d’un classeur de cent pages, mais elle doit savoir ce qui est critique, combien de temps l’arrêt est acceptable et comment reprendre en mode dégradé.

Un second fournisseur inscrit dans un tableau n’est pas encore un plan B. Il faut avoir testé la bascule, la qualité, les données et le retour arrière.

1 — inventorier les tâches plutôt que les marques

Listez chaque usage : résumé de documents, extraction, génération d’images, rédaction, agent de code, classement ou support. Pour chacun, indiquez l’application qui appelle l’API, le propriétaire, les utilisateurs, le volume, la fréquence et le livrable attendu.

Cherchez aussi les dépendances invisibles : automatisation no-code, extension, modèle nommé dans un script, clé stockée dans un secret, tâche planifiée ou sous-traitant. L’inventaire doit pouvoir être compris par une personne autre que son créateur.

2 — mesurer l’impact et fixer des priorités

Attribuez une criticité selon la conséquence d’un arrêt : revenu perdu, client bloqué, délai, risque légal, charge manuelle ou simple inconfort. Fixez un délai maximal de reprise, souvent appelé RTO, et la quantité de travail que vous acceptez de perdre ou de reconstruire, appelée RPO.

Pour une newsletter hebdomadaire, un jour d’interruption peut être acceptable. Pour une fonction vendue en temps réel, une heure peut être déjà trop longue. Ces objectifs orientent le budget et évitent de construire une architecture complexe autour d’un usage sans enjeu.

1. Vert : arrêt sans conséquence importante pendant plusieurs jours
2. Orange : mode manuel possible avec capacité limitée
3. Rouge : livraison, sécurité ou revenu bloqués rapidement
4. RTO : délai maximal de reprise
5. RPO : travail ou données que l’on accepte de reconstruire

3 — cartographier données, contrats et droits

Décrivez ce qui entre dans le service, ce qui en sort, où les fichiers sont conservés, qui y accède et comment les supprimer. Distinguez données personnelles, secrets professionnels, contenus sous licence et matériaux publics. Une migration technique peut devenir impossible si les droits ou formats n’ont pas été documentés.

Relisez l’offre exacte : API, abonnement individuel et contrat entreprise peuvent avoir des conditions différentes. Vérifiez préavis, export, conservation, région de traitement, sous-traitants, propriété des sorties et procédure de fermeture. Pour les données sensibles ou les engagements contractuels, demandez un avis compétent adapté à votre situation.

4 — exporter et vérifier avant l’urgence

Conservez les prompts importants, gabarits, paramètres, résultats nécessaires, journaux techniques utiles et métriques dans des formats indépendants. Ne stockez pas votre seule copie dans le tableau de bord du fournisseur. Testez l’archive : fichiers ouvrables, encodage, pièces jointes, métadonnées et correspondance avec l’inventaire.

Une sauvegarde non restaurée est une hypothèse. Programmez un contrôle trimestriel pour les services critiques et après toute annonce de retrait. Limitez toutefois les copies : ne multipliez pas des données personnelles sans règle de conservation et de sécurité.

5 — définir un mode dégradé honnête

Avant de choisir une autre IA, demandez comment continuer sans elle pendant quelques heures ou jours. Une personne peut traiter les cas prioritaires, un formulaire peut mettre les demandes en attente, une ancienne version peut rester active ou une fonction non essentielle peut être désactivée.

Écrivez le message utilisateur, la limite de capacité et la personne qui décide du retour à la normale. Le mode dégradé ne doit pas transformer silencieusement une validation humaine en publication automatique ni contourner des contrôles de sécurité.

6 — présélectionner deux alternatives au maximum

Comparez les solutions sur l’intention réelle : qualité en français, formats, contexte, outils, latence, limites, disponibilité européenne, confidentialité, hébergement, licence et exigences matérielles. Pour un modèle local, ajoutez mémoire, énergie, mises à jour et exploitation. Pour une API, ajoutez quotas, région, support et stabilité des versions.

Évitez un concours généraliste. Deux candidats suffisent pour une première preuve. Si aucun ne respecte un besoin obligatoire, envisagez de retirer la fonction ou de la reconstruire autrement au lieu d’abaisser silencieusement la qualité.

7 — créer un jeu de tests de contrat et de qualité

Les tests de contrat vérifient l’authentification, les entrées, les sorties, le streaming, les outils, les erreurs, les délais et l’annulation. Les tests de qualité utilisent des exemples représentatifs, anonymisés et notés avec des critères écrits avant l’essai.

Mesurez le taux de réussite, les faits exacts, le respect du format, les refus attendus, le français, la latence, les jetons ou unités facturées et le temps de correction. Répétez les cas critiques : une seule bonne réponse ne prouve pas la stabilité.

8 — isoler le fournisseur dans l’architecture

Centralisez l’adresse, le modèle, l’authentification et la conversion des réponses. Votre code métier doit demander une capacité — par exemple extraire cinq champs — plutôt qu’un modèle précis. Ajoutez un identifiant de version et une trace de validation sans enregistrer de secrets ni de contenu inutile.

Cette couche d’adaptation ne rend pas les fournisseurs identiques. Elle localise les différences et permet de tester la bascule. Pour les fonctions propriétaires, définissez explicitement un comportement de repli : alternative, traitement manuel, file d’attente ou refus clair.

9 — basculer progressivement et préparer le retour

Commencez avec des données fictives, puis un petit groupe et des tâches à faible risque. Augmentez la part seulement si les seuils restent respectés. Ne dupliquez pas automatiquement toutes les données vers deux fournisseurs : la comparaison doit rester proportionnée et conforme à vos règles.

Conservez la configuration précédente pendant une période définie. Déclenchez le retour selon des critères visibles : erreurs, coût, latence, incident de sécurité ou baisse de qualité. Exercez réellement le retour avant la mise en production complète.

1. 1 % ou groupe interne
2. Contrôle humain renforcé
3. Comparaison aux seuils écrits
4. Montée progressive
5. Exercice de retour arrière
6. Validation finale et retrait des accès inutiles

10 — surveiller les annonces et entretenir le plan

Abonnez-vous aux pages de statut, changelogs, avis de dépréciation, tableaux de versions et communications contractuelles. Acheminez ces signaux vers une personne responsable et une échéance. Une alerte lue sans propriétaire ni tâche n’est pas traitée.

Rejouez les tests chaque trimestre ou après une modification importante. Mettez à jour contacts, clés, modèles, conditions, coûts et procédure manuelle. Le plan doit rester assez court pour être utilisé sous pression.

Cas pratique : une TPE qui classe des demandes clients

Une petite agence utilise une API pour classer les demandes en quatre catégories et proposer un brouillon. L’inventaire révèle que le classement accélère le travail, mais qu’un humain valide toujours la réponse. Le RTO est fixé à une journée et le mode manuel consiste à utiliser les mêmes quatre catégories dans la boîte de réception.

L’équipe exporte les exemples anonymisés, écrit vingt tests et place le fournisseur derrière un adaptateur. Elle teste une seconde API puis un petit modèle local sans envoyer de données réelles. Le remplacement obtient une qualité proche mais coûte davantage ; il reste donc en secours, testé chaque trimestre. La continuité vient du processus mesuré, pas d’un abonnement dormant.

La fiche d’une page à conserver

Résumez service, propriétaire, criticité, RTO, RPO, données, contrat, export, mode manuel, solution de secours, tests, seuils, procédure de bascule, retour et contacts. Ajoutez la date du dernier exercice et le résultat. Cette fiche suffit souvent à une petite structure si les liens vers les détails sont accessibles.

Après chaque incident ou retrait, faites un retour d’expérience : signal reçu, délai, surprise, coût, erreur et amélioration. Le but n’est pas d’éliminer toute dépendance, ce qui serait irréaliste, mais de rendre ses conséquences visibles et maîtrisables.