Réversibilité d’un assistant IA : préparer une sortie sans perdre ses données

Intelligence artificielle

Changer d’assistant IA ne se résume pas à exporter des conversations. Un inventaire des éléments à reprendre et un essai de restauration permettent de préparer une sortie vérifiable.

La réversibilité d’un assistant IA consiste à préparer la reprise des données et du fonctionnement utile lorsqu’on change de solution, de modèle ou de prestataire. Elle se vérifie par un essai de restauration, pas seulement par la présence d’un bouton « Exporter ». Le dossier de sortie doit préciser ce qui sera récupéré, dans quel format, avec quels droits et ce qui devra être reconstruit.

Ce guide concerne un assistant documentaire ou administratif. Il propose une méthode de cahier des charges, sans valider un système clinique ni remplacer une analyse juridique. Le choix entre IA locale et cloud traite l’architecture d’accueil ; la question ici est différente : comment éviter que le travail accumulé devienne inutilisable au départ du fournisseur ?

Définir la sortie avant de connecter les premiers documents

Choisissez un scénario précis : reprise par votre équipe, migration vers un autre prestataire ou arrêt de l’assistant avec retour à la recherche documentaire habituelle. Les livrables diffèrent selon cette destination. Récupérer des fichiers pour les archiver ne demande pas les mêmes vérifications que remettre un service en fonctionnement.

La règle 4 de la doctrine cloud de la DINUM prévoit, pour les administrations concernées, des conditions de sortie soutenables et des moyens préparés dès le lancement. Cette règle ne s’impose pas indistinctement à toute organisation ; elle fournit ici un repère utile pour anticiper l’effort de reprise.

Nommez un responsable de la sortie, un destinataire autorisé et les personnes qui vérifieront le résultat. Prévoyez aussi le fonctionnement pendant la transition : quels utilisateurs seront informés, quelles opérations pourront être suspendues et quelle méthode restera disponible si la reprise échoue ?

Inventorier ce qui fait réellement fonctionner l’assistant

Le dossier ne se limite pas aux conversations. Une réponse peut dépendre d’un document, de sa version, d’une instruction, d’un droit d’accès et d’un service extérieur. Le tableau suivant est une proposition originale de préparation, à compléter selon le projet. Les formats indiqués sont des demandes à instruire, pas des capacités garanties chez tous les fournisseurs.

Inventaire de réversibilité : livrables à demander et contrôles de reprise
ÉlémentLivrable ou format à préciserContrôle attendu
Documents sourcesFichiers originaux et inventaire CSV ou JSON : identifiant, version, propriétaire, droits.Ouvrir les fichiers et rapprocher leur nombre de l’inventaire.
Consignes et promptsTextes versionnés, variables, paramètres et règles d’utilisation.Retrouver la consigne active et ses dépendances.
Recherche documentaire RAGSources, métadonnées, règles de découpage et procédure de reconstruction de l’index.Retrouver un passage autorisé avec sa référence.
Conversations et tracesExport structuré documenté, périmètre et dates ; conservation limitée aux besoins justifiés.Lire les échanges retenus et interpréter leurs horodatages.
Utilisateurs et habilitationsCorrespondance des rôles, groupes et accès, sans diffuser de secrets.Refuser un document à un rôle non autorisé.
Modèles et intégrationsRéférences, versions, réglages, licences et description des interfaces utilisées.Identifier ce qui peut être repris, remplacé ou doit être redéveloppé.

Pour le RAG, prévoir la reconstruction plutôt que supposer la compatibilité

Un index de recherche n’est pas le document source. Demandez si sa reprise est possible dans l’environnement cible ; sinon, faites décrire sa reconstruction. Conservez les règles de préparation, les métadonnées et la référence du modèle de représentation des textes. Garder uniquement un dossier de fichiers peut faire perdre les versions et les autorisations associées.

Le guide RAG ou fine-tuning explique le choix de méthode. Pour la sortie, l’enjeu est de transmettre assez d’informations pour reconstruire la recherche et vérifier ses résultats, sans présumer qu’un index sera transférable tel quel.

Ce qu’un export Open WebUI permet de dire, et ses limites

À la date de consultation, la documentation Open WebUI sur l’import et l’export décrit l’export des conversations en JSON depuis les paramètres, rubrique Data Controls. Elle documente aussi leur réimportation. C’est une fonction concrète de reprise de l’historique, pas la preuve qu’un autre assistant acceptera ce fichier sans adaptation.

Son guide de migration de base de données distingue la base, les fichiers joints et le stockage vectoriel. Pour une installation SQLite, copier seulement la base ne récupère pas les fichiers eux-mêmes. La procédure dépend également des composants de l’installation.

Avant de choisir un outil, demandez donc une démonstration avec la version et la configuration envisagées. Exporter une conversation ne transfère ni les poids d’un modèle distant ni, à lui seul, tous les composants du service. Les fonctions documentées ici n’ont pas été testées sur votre installation.

Écrire des clauses que l’équipe pourra effectivement vérifier

Remplacez « les données seront récupérables » par une liste de livrables et de critères de réception. Pour chaque élément, précisez le responsable, le format, sa documentation, le délai de remise et la personne autorisée à le recevoir. Convenez de la façon de signaler un fichier absent, illisible ou incomplet.

  • Complétude : définir le périmètre à restituer, y compris les pièces jointes et les relations entre objets.
  • Lisibilité : fournir un schéma de données, l’encodage, les conventions de dates et un exemple exploitable.
  • Assistance : préciser le travail du fournisseur et celui de l’équipe de reprise, ainsi que les coûts convenus.
  • Continuité : organiser le dernier export, le traitement des modifications survenues pendant la transition et le retour possible à la situation précédente.
  • Clôture : définir les vérifications, les réserves éventuelles et le traitement des copies restantes.

Le JSON ou le CSV facilite l’inspection quand sa structure est expliquée ; le nom du format ne garantit pas l’interopérabilité. Une API décrite comme compatible doit être vérifiée sur les fonctions utilisées. Une licence ou un contrat peut également limiter la reprise d’un modèle ou d’un développement spécifique. Faites examiner ces points sans supposer un droit automatique au code ou aux poids.

Les ressources de sortie appartiennent au budget complet de l’assistant. Ici, le livrable attendu n’est pas un nouveau chiffrage : c’est une procédure réalisable avec des responsabilités et des moyens identifiés.

Organiser un test de restauration dans un environnement isolé

Préparez un petit corpus fictif ou expressément autorisé, représentatif des formats et des droits. Fixez les critères avant l’essai : objets présents, documents lisibles, relations conservées, accès corrects et recherches attendues. Mesurez le temps réellement nécessaire ; n’annoncez pas une reprise « immédiate » sans l’avoir éprouvée.

  1. Figer le périmètre : dater l’export et relever les versions des composants concernés.
  2. Contrôler le paquet : comparer les fichiers à l’inventaire et vérifier leur intégrité, par exemple avec des empreintes SHA-256.
  3. Reprendre le service : importer ou reconstruire les éléments dans une cible isolée, sans envoi ni écriture en production.
  4. Rejouer les parcours : rechercher une source, ouvrir une pièce jointe et vérifier les accès avec plusieurs rôles fictifs.
  5. Documenter la décision : noter les écarts, les corrections nécessaires et les conditions d’un nouvel essai.

Une empreinte identique montre que les octets comparés n’ont pas changé ; elle ne prouve ni la complétude de l’export ni le bon fonctionnement de l’assistant. La grille d’évaluation d’un assistant IA aide à préparer les cas métier après reconstruction. Une réponse différente n’est pas automatiquement incorrecte : vérifiez les sources, les droits et les critères convenus.

Exemple fictif : un export complet en apparence

Ce scénario est entièrement fictif et ne rapporte aucun résultat client. Une équipe prépare le remplacement d’un assistant de recherche dans des consignes de formation. Elle utilise douze documents inventés, deux rôles fictifs et quelques questions de contrôle. Ces nombres servent seulement à rendre l’exercice lisible.

Le paquet contient bien les douze fichiers. Pourtant, l’inventaire ne distingue pas une ancienne version de la consigne courante et ne décrit pas le rôle autorisé à consulter une annexe. La réception des fichiers pourrait sembler satisfaisante ; la remise en service ne l’est pas.

La suite à prévoir serait de compléter les métadonnées et la correspondance des droits, reconstruire la recherche puis refaire les contrôles. Cet exemple illustre une méthode de vérification, pas une démonstration technique réalisée. Le critère de réussite porte sur un service repris dans son périmètre, pas sur le seul téléchargement d’une archive.

Restituer et supprimer sans perdre les preuves nécessaires

Lorsqu’un prestataire agit comme sous-traitant, l’article 28, paragraphe 3, point g du RGPD encadre le sort des données personnelles en fin de prestation. Le guide du sous-traitant de la CNIL rappelle la restitution ou la suppression selon les instructions du client et le traitement des copies, sous réserve des obligations légales de conservation.

Préparez avec les interlocuteurs compétents le calendrier de restitution, les contrôles de réception et les instructions de suppression. Faites préciser le sort des sauvegardes, journaux et copies chez les autres intervenants. Il ne faut ni tout conserver par défaut ni supprimer des éléments avant d’avoir instruit les obligations applicables.

Une confirmation écrite de suppression constitue une pièce du dossier, pas une preuve suffisante de restauration. Conservez séparément le compte rendu de reprise et la trace de clôture. Cette méthode ne constitue ni une consultation juridique complète ni une certification.

Décider de la sortie sur des éléments vérifiés

Avant de fermer l’ancien service, rassemblez l’inventaire, les livrables reçus, les résultats de restauration et les écarts encore ouverts. Si une dépendance reste bloquante, rendez-la visible et choisissez une suite : correction, maintien temporaire encadré ou retour au fonctionnement habituel. La sortie doit rester une décision explicite.

Les services IA de DEMETER SANTÉ permettent d’aborder le cadrage des usages et la gouvernance. Pour préparer un diagnostic ou un besoin de développement sur mesure, présentez votre contexte. Les conditions de reprise sont à définir avec vos équipes et les prestataires concernés, sans présumer d’une solution ni d’une conformité acquise.

Questions fréquentes

Une sauvegarde suffit-elle pour changer de fournisseur ?

Pas nécessairement. Une sauvegarde peut permettre de restaurer la même application sans être exploitable dans une autre solution. Il faut préciser la cible, les formats et les composants à reprendre, puis tester la restauration ou la reconstruction prévue.

Faut-il récupérer tous les journaux de l’assistant ?

Non, pas systématiquement. Définissez les traces utiles, les obligations applicables, les personnes autorisées et la durée de conservation. Les journaux peuvent contenir des informations personnelles ou confidentielles. Leur export doit rester justifié et protégé.

Peut-on emporter le modèle appelé par une API ?

Un accès par API ne donne pas, à lui seul, accès aux poids du modèle ni un droit de les réutiliser. Vérifiez le contrat, la licence et les fonctions réellement disponibles. Une autre solution peut nécessiter un modèle différent et de nouveaux tests.

Qui doit valider le test de reprise ?

Désignez les responsables avant l’essai : métier pour le service attendu, informatique pour la reprise et les accès, avec les interlocuteurs sécurité et protection des données selon le périmètre. Le fournisseur peut contribuer aux vérifications sans décider seul de leur réception.

À quel moment refaire un essai de réversibilité ?

Prévoyez une fréquence adaptée et des événements déclencheurs : changement important de version, de stockage, de modèle ou de fournisseur. Un essai ancien ne valide pas automatiquement l’architecture actuelle. La périodicité reste à définir selon les risques et les moyens.

Sources et méthode

Article rédigé le 22 octobre 2026 sous la signature éditoriale de Dimitri Jorand. Sources primaires consultées à cette date. Préparation rédactionnelle assistée par IA et contrôle documentaire des références. Les exemples sont fictifs ; les grilles et propositions pratiques sont originales. Ce support d’information ne remplace pas une analyse de votre situation par les interlocuteurs compétents ni les procédures de votre structure.

Sources