Choisir l’hébergement IA : examiner les flux de données

Choisissez le mode d’exploitation de l’IA pour un processus précis. Un modèle sur votre propre serveur et un service de modèle géré diffèrent par le traitement et l’exploitation. Le choix adapté n’apparaît qu’en suivant le parcours complet, de la saisie au résultat enregistré.

Définir la tâche et le périmètre des données

Une entreprise de logiciels fictive souhaite résumer des notes internes dans son portail de projets. Une personne ne peut lire que les notes du projet auquel elle a accès et vérifie le brouillon avant de l’enregistrer. Le modèle n’a pas pour tâche d’envoyer des messages ou de modifier les droits du projet.

Pour le projet d’exemple P-72, une règle interne s’applique : les notes clients non traitées ne doivent pas être transmises à des services de traitement externes. C’est une hypothèse de cet exemple. Elle ne remplace pas l’examen des données et besoins réels de votre entreprise.

Comparer le parcours complet des données

Le tableau décrit des flux prévus, pas une installation testée. Ici, « serveur de modèle autogéré » désigne un serveur exploité par l’entreprise dans l’environnement approuvé. Un serveur loué peut également être autogéré ; son intégration à cet environnement doit être examinée séparément. L’emplacement ne décrit pas à lui seul le partage des responsabilités.

Le journal d’exploitation prévu contient par exemple requestId et status, sans le texte complet de la note ni la réponse du modèle. Ces attributs d’exemple propres à l’application ne définissent pas un journal de sécurité complet. La gestion des erreurs, les exports destinés au support et les sauvegardes doivent aussi respecter le périmètre défini.

Examiner l’environnement d’exécution réellement utilisé

La FAQ d’Ollama distingue par exemple le traitement local des modèles cloud et décrit la désactivation des fonctions cloud. Cela concerne cet environnement d’exécution. Une interface, une extension ou un service d’erreurs distinct peut avoir d’autres connexions. Le nom du logiciel installé ne prouve donc pas le parcours complet des données.

Dans un pilote approuvé, examinez les destinations utilisées, le contenu des journaux produits et le fonctionnement en cas de panne. Une simple liste de destinations réseau ne prouve ni le contenu des transferts chiffrés ni la conservation chez le prestataire. Pour un service externe, il faut également ses informations précises de traitement et de conservation ; une affirmation générale sur le cloud ne suffit pas.

Décider ensemble de l’exploitation et de l’adéquation

Pour un serveur de modèle autogéré, des responsables doivent prendre en charge les mises à jour, les accès, la capacité, la surveillance et la restauration. Avec un service de modèle, le prestataire assure l’exploitation convenue du modèle ; les droits du portail, l’intégration et vos propres journaux restent à la charge de votre équipe. Comparez d’abord les deux avec les mêmes entrées synthétiques et résultats attendus. Cela n’autorise pas le traitement de véritables notes clients. La qualité et les temps d’attente à la charge requise sont établis dans le pilote, pas déduits de l’emplacement.

Selon la règle de l’exemple, l’appel au modèle externe n’est pas encore autorisé. Le serveur autogéré est envisageable une fois son parcours de données, la qualité des résultats et son exploitation vérifiés. Sans équipe d’exploitation responsable, cette option n’est pas prête non plus. Une autre catégorie de données ou l’autorisation d’un parcours externe précis peut modifier la décision.

Sources

• Ollama — FAQ

• OWASP — LLM02:2025 Sensitive Information Disclosure

• OWASP — Logging Cheat Sheet