Quand l’IA devient indisponible : préparer la continuité et le changement de fournisseur

Une application d’IA utile peut rapidement s’intégrer à un processus de travail. Une nouvelle question finit alors par se poser : que devient ce processus si l’application est indisponible demain ou doit être remplacée définitivement ? La réponse concerne les achats, les responsables métier, l’informatique et les personnes qui effectuent réellement le travail.

Ce guide propose un exercice collectif délimité. Il clarifie le fonctionnement minimal, les dépendances importantes et le retour organisé à l’activité habituelle. Il s’agit d’une aide à l’organisation. Les procédures d’urgence cliniques, techniques et opérationnelles existantes doivent être considérées séparément par les personnes qui en sont responsables.

Partir du résultat qui reste nécessaire

Prenons un exemple fictif. Une entreprise pharmaceutique utilise une application d’IA pour rassembler des documents internes autorisés en vue d’une réunion hebdomadaire de direction. Le service tombe en panne le matin, avant la réunion. Savoir qui peut contacter le fournisseur ne suffit pas. La direction doit décider quelles informations doivent rester disponibles et quelles tâches peuvent attendre.

La première question collective est donc la suivante : quel résultat doit rester disponible pendant l’interruption ? Dans cet exemple, une courte liste des décisions déjà confirmées pourrait suffire. De nouvelles analyses peuvent attendre la réunion suivante. Cet accord délimite la procédure de secours et explicite la réduction de service acceptée.

Depuis 2010, le document NIST SP 800-34 décrit une démarche qui relie les conséquences d’une interruption, les ressources nécessaires et les priorités de reprise. Il concerne les systèmes d’information fédéraux américains. J’utilise ses mécanismes comme référence professionnelle ; ils ne créent pas d’obligation juridique allemande pour l’entreprise fictive. [1]

Rendre visibles quatre dépendances

Dessinez le processus sur une page : réception des informations, traitement, vérification et transmission. Ajoutez les dépendances de chaque étape. Quatre catégories suffisent pour une première discussion : informations nécessaires, services techniques, personnes autorisées et règles de travail obligatoires.

Dans l’exemple, les documents d’origine peuvent être conservés dans un espace autorisé distinct. L’application d’IA contient aussi l’ordre dans lequel ils sont assemblés. Une personne expérimentée connaît les exceptions. Cette courte description révèle déjà quels éléments restent accessibles en cas de panne et lesquels devraient être reconstitués.

Examinez également les dépendances techniques communes. Deux applications différentes peuvent utiliser le même service d’IA sous-jacent, le même système d’authentification ou le même espace de données. Les informations du fournisseur et l’architecture de l’organisation permettent de le vérifier. Une seconde interface ne démontre pas, à elle seule, l’existence d’une solution de secours indépendante.

L’exercice n’exige aucune liste publique des systèmes internes. Ses résultats appartiennent à la documentation protégée appropriée. Les identifiants d’accès, les clés et les informations confidentielles doivent rester dans les procédures autorisées, y compris pendant une interruption.

Éprouver la procédure de secours sur une tâche concrète

Pour la réunion fictive, une personne désignée pourrait rassembler les décisions confirmées directement depuis l’espace documentaire autorisé. Une seconde vérifierait la période couverte et la sélection. Les destinataires seraient informés des analyses complémentaires absentes cette fois-ci. On dispose ainsi d’un processus limité dont les exigences peuvent être examinées.

Demandez à une personne suppléante désignée de l’exécuter avec des documents fictifs. Elle doit pouvoir trouver les informations nécessaires, comprendre l’enchaînement et effectuer la transmission prévue. Notez les endroits où elle doit poser une question. Cela peut révéler une dépendance à des connaissances jamais explicitées.

La durée de l’exercice est une observation dans ces conditions. Elle ne constitue pas un délai de reprise garanti pour toutes les pannes. Un incident réel peut toucher simultanément les effectifs, les accès ou d’autres systèmes. Les responsables doivent donc préciser le type d’interruption auquel la procédure est destinée.

Le profil volontaire du NIST sur l’IA générative, publié en 2024, recommande de prendre en compte les dépendances envers des tiers, les dispositions de secours, les responsabilités et les exercices d’incident. C’est un cadre de gestion des risques. Il ne démontre pas l’efficacité de l’exercice proposé ici. [2]

La reprise suppose aussi de rapprocher les travaux en cours

Lorsque le service fonctionne à nouveau, la tâche organisationnelle reste inachevée. Dans l’exemple, des décisions ont été rassemblées manuellement pendant la panne. L’application pourrait ensuite traiter à nouveau les mêmes documents. Sans rapprochement des travaux, des doublons ou des versions contradictoires peuvent apparaître.

Convenez à l’avance de la personne qui autorise le retour au fonctionnement habituel. Elle doit identifier le travail déjà accompli, les résultats encore manquants et les versions intermédiaires qui peuvent être écartées. Une courte liste indiquant l’état d’avancement et les responsabilités peut suffire si elle convient à l’ampleur de l’activité.

Les destinataires doivent également savoir quand le processus habituel reprend. Une notification de réussite technique ne répond pas automatiquement à cette question organisationnelle. La personne responsable décide si les vérifications nécessaires ont été effectuées et si le traitement peut redémarrer.

Préparer séparément un changement durable de fournisseur

Une transition plus longue demande davantage qu’une solution provisoire. Elle concerne les informations transférables, les règles de travail documentées, les droits sur les contenus utilisés et les conditions d’utilisation futures. Ces questions doivent être abordées tôt avec les achats, les responsables métier et les fonctions juridiques et de protection des données concernées.

Demandez un exemple de ce qui peut être exporté dans un format exploitable pour le processus considéré. Vérifiez que les personnes compétentes peuvent en reconstituer le sens. Une collection d’anciennes conversations peut être incomplète : elle peut contenir de nombreuses réponses sans règle actuelle fiable. Il faut confronter les possibilités du produit réel au service convenu.

Une application de remplacement exige aussi sa propre évaluation métier. Des entrées identiques et des sorties aux formulations voisines ne garantissent pas un traitement équivalent. Des tâches d’exemple déjà autorisées peuvent préparer la comparaison ; la responsabilité de l’utilisation future doit être attribuée à nouveau.

Un changement planifié exige aussi un point de passage explicite. Pendant la transition, l’organisation doit savoir quel système fait autorité pour chaque travail. Une coexistence temporaire peut être nécessaire, mais les personnes doivent disposer d’une règle claire pour départager les versions concurrentes et orienter les nouvelles tâches.

La décision après l’exercice

L’exercice doit aboutir à quelques résultats clairs : un fonctionnement minimal accepté, la responsabilité de son activation, une procédure de secours répétée, les conditions de reprise et les dépendances non résolues. Chaque question ouverte doit avoir une personne responsable et une prochaine étape.

La direction peut alors décider délibérément quelles précautions supplémentaires justifient leur coût. Pour moi, la valeur de l’exercice tient à cela : il transforme une inquiétude vague sur la dépendance en décisions concrètes sur la capacité de l’organisation à continuer d’agir lorsque les conditions changent.