L’expression « IA privée » recouvre des réalités très différentes, depuis « nous avons désactivé l’entraînement sur notre compte SaaS » jusqu’à « nous exécutons des modèles à poids ouverts sur notre propre infrastructure ». Ces deux situations n’offrent pas le même périmètre de contrôle.
Pour une PME, la bonne architecture d’IA privée dépend des données, de la tâche, du niveau de qualité requis et de la capacité de l’équipe à exploiter une infrastructure. La solution la plus privée n’est pas toujours la meilleure. La plus performante n’est pas toujours acceptable au regard des données. La moins chère peut devenir coûteuse si elle exige une attention technique constante.
Cet article propose une grille de décision. Utilisez-la avec le texte du RGPD, le cadre de gestion des risques liés à l’IA du NIST, les contrats et la documentation des fournisseurs sur la maîtrise des données, ainsi que les recommandations de sécurité du moteur d’inférence choisi, par exemple celles de vLLM.
Commencez par classer les données, pas par choisir votre modèle préféré. Un modèle moins performant, mais exécuté dans le bon périmètre de confidentialité, vaut mieux qu’un modèle de pointe auquel vous transmettez des données qu’il ne devrait pas recevoir.
Les cinq modes de déploiement
| Architecture | De quoi s’agit-il ? | Cas d’utilisation pertinent | Limite principale |
|---|---|---|---|
| SaaS d’entreprise | Offre professionnelle avec administration, SSO, gestion de la conservation et exclusion des données d’entraînement | La plupart des tâches courantes de l’entreprise | Les données quittent tout de même votre environnement |
| VPC ou cloud privé | Point de terminaison géré dans un environnement cloud contrôlé | Charges confidentielles exigeant un cloisonnement plus strict | Coût et configuration plus élevés |
| Inférence auto-hébergée | Vous exécutez des modèles ouverts sur votre propre infrastructure | Données restreintes, modèles personnalisés, économies d’échelle | Charge d’exploitation |
| Modèles exécutés localement | Le modèle s’exécute sur un ordinateur portable, une station de travail ou un appareil en périphérie | Tâches étroites, hors ligne, sensibles ou exigeant une faible latence | Modèles plus petits et limites du matériel |
| Routage hybride | Chaque cas d’usage est acheminé vers le périmètre adapté | Portefeuilles associant plusieurs niveaux de sensibilité | Exige une classification rigoureuse des données |
Les comptes grand public n’offrent généralement pas la gestion centralisée des identités, de la conservation, des connecteurs, des engagements contractuels et de la configuration d’audit dont l’organisation a besoin. La politique de l’entreprise doit préciser s’ils sont autorisés et, le cas échéant, pour quelles données.
Une organisation peut avoir besoin d’une seule architecture ou d’un portefeuille gouverné. L’objectif est de choisir puis de réexaminer le périmètre de chaque cas d’usage approuvé, au lieu de considérer l’étiquette d’un produit comme une garantie permanente.
Classez les données en premier
Les quatre catégories ci-dessous constituent une taxonomie indicative de départ. Alignez les noms et les règles de traitement sur le classement réel des informations de l’organisation et ses exigences légales :
| Données | Exemples | Limite IA par défaut |
|---|---|---|
| Publiques | Contenu du site web, documents publiés, recherches publiques | Outil approuvé après vérification des droits, de l’authenticité, des risques d’injection de prompt et des conditions d’utilisation |
| Internes | Notes de processus, exemples anonymisés, brouillons non sensibles | SaaS d’entreprise |
| Confidentielles | Données clients, contrats, code source, données financières, stratégie | SaaS d’entreprise avec contrôles, VPC ou auto-hébergement |
| Restreintes | Données de santé, informations couvertes par le secret professionnel, enquêtes RH, dossiers réglementés | Revue juridique et de sécurité ; une solution locale, dans un VPC, auto-hébergée ou sans IA peut être requise |
Ce classement permet d’éviter une erreur courante : utiliser le même assistant pour des brouillons de blog publics et des dossiers clients confidentiels par commodité.
Les identifiants de connexion, les clés privées, les jetons d’authentification et les codes de récupération ne constituent pas une catégorie de données à acheminer vers un modèle. Excluez-les des prompts, des corpus documentaires, de la télémétrie et des outils accessibles au modèle. Lorsqu’une intégration déterministe exige un identifiant, utilisez un gestionnaire de secrets et injectez-le à l’exécution avec des droits strictement limités.
Architecture 1 : le SaaS d’entreprise par défaut
Le SaaS d’entreprise peut être la solution la moins complexe à exploiter. Les noms de produits, les droits associés aux offres et les conditions contractuelles évoluent ; pour chaque offre présélectionnée, vérifiez :
- Les conditions d’utilisation des données et d’entraînement du modèle dans le contrat.
- Les contrôles administratifs.
- Le SSO et la gestion des accès.
- Les paramètres de conservation.
- Les journaux d’audit.
- La documentation de sécurité.
- L’assistance du fournisseur.
Ces contrôles peuvent permettre des usages approuvés, mais l’achat d’une offre ne prouve pas qu’une catégorie de données ou un flux de travail particulier est licite ou sûr.
La configuration est déterminante. Souscrire l’offre destinée aux équipes ne suffit pas. Définissez la durée de conservation, le partage, l’accès aux connecteurs, les espaces de travail approuvés et les règles relatives aux données.
Architecture 2 : VPC ou cloud privé
Une architecture VPC ou cloud privé peut convenir lorsque les données peuvent quitter l’application, mais doivent rester dans un périmètre cloud et contractuel défini. La mention « dans un VPC » ne prouve pas que le plan de contrôle, le service de modèle, les journaux, l’assistance et les sauvegardes y restent tous. Cartographiez et testez l’intégralité du flux de données.
- Assistant du service client travaillant sur des demandes confidentielles.
- Assistant de connaissances internes sur des documents sensibles.
- Extraction de documents pour les contrats ou les factures.
- Assistant spécifique au domaine où vous avez besoin d’une isolation des données plus forte que celle du SaaS.
Avantages potentiels à vérifier :
- Isolation renforcée selon la conception du service sélectionné.
- Contrôle accru sur le réseau et les journaux.
- Éléments probants susceptibles de satisfaire aux exigences d’achat définies.
- Répartition différente des responsabilités d’exploitation par rapport à un auto-hébergement complet.
Limites potentielles à chiffrer et tester :
- La tarification peut dépasser celle d’un plan SaaS partagé pour la charge mesurée.
- Travail d’intégration et de plateforme supplémentaire.
- Le choix des modèles peut être plus restreint.
- Vous dépendez toujours de l’infrastructure du fournisseur.
Considérez cette architecture comme une solution intermédiaire possible, pas comme le choix par défaut de toutes les PME.
Architecture 3 : inférence auto-hébergée
L’auto-hébergement signifie que vous exploitez l’environnement d’exécution du modèle : vLLM, TGI, SGLang, llama.cpp, Ollama ou une autre pile d’inférence. Ce choix peut être pertinent lorsque :
- Les données ne peuvent pas quitter votre environnement.
- Vous avez besoin d’un modèle ouvert personnalisé ou affiné.
- Le volume d’inférence est suffisamment élevé pour justifier l’infrastructure.
- Les besoins en latence ou disponibilité exigent un contrôle direct.
- Vous disposez de personnes capables de l’exploiter.
N’optez pas pour l’auto-hébergement simplement parce qu’il paraît plus « pur ». Son coût d’exploitation est réel : capacité GPU, surveillance, mises à jour, correctifs de sécurité, évaluation des modèles, mise à l’échelle et réponse aux incidents.
L’auto-hébergement est un choix solide pour la bonne organisation. Pour une petite équipe sans expérience en infrastructure ML, cela peut devenir un projet secondaire fragile.
Architecture 4 : modèles sur appareil local
Les modèles locaux peuvent convenir à des tâches individuelles sensibles lorsque l’appareil dans son ensemble, les mises à jour, la télémétrie, les sauvegardes et le périmètre d’accès sont maîtrisés :
- Résumés de notes locales.
- Rédaction à partir de documents privés.
- Classification d’extraits internes.
- Travaux sur le terrain hors ligne.
- Flux exécutés en périphérie lorsque la latence est déterminante.
Le compromis de qualité dépend de la tâche et du modèle. Évaluez la solution locale sur des tâches représentatives de synthèse, de classification, d’extraction ou de rédaction au lieu de présumer qu’elle sera équivalente ou inférieure.
N’utilisez un modèle local que s’il réussit l’évaluation prévue pour la tâche et si l’ensemble du périmètre local est approuvé. Le simple fait qu’un modèle « s’exécute sur l’appareil » ne garantit pas la confidentialité.
Architecture 5 : routage hybride
Une architecture hybride peut acheminer les charges de travail selon leur classe de données approuvée :
- Les tâches publiques et à faible risque sont envoyées vers le SaaS d’entreprise.
- La recherche documentaire confidentielle s’effectue dans un système RAG privé.
- L’extraction de données restreintes emprunte uniquement une voie locale, dans un VPC, auto-hébergée ou sans IA, expressément approuvée après examen de l’ensemble du flux de données.
- La rédaction finale peut utiliser un modèle de pointe une fois les champs sensibles retirés.
- Les journaux et les évaluations permettent de vérifier le bon fonctionnement de chaque voie.
Le routage hybride peut associer différents enregistrements à différents périmètres approuvés. Il exige une politique applicable par des contrôles techniques, et non une simple classification confiée à un prompt :
- Classification des données avant le routage.
- Masquage des données sensibles lorsque cela est possible.
- Liste d’autorisation explicite pour les modèles et les outils.
- Journaux indiquant quel périmètre a été utilisé.
- Solution de repli lorsque le modèle privé ne peut pas effectuer la tâche.
Cadre décisionnel
Posez six questions :
- Quelles données entrent dans le modèle ? Publiques, internes, confidentielles, restreintes.
- Quel est l’impact des sorties ? Brouillon, recommandation, décision, action visible par les clients.
- Quelle qualité est requise ? Définissez des objectifs propres à la tâche pour la précision, la sûreté, la latence, le refus et la revue humaine, plutôt que des qualificatifs tels que « niveau expert ».
- Quelle latence est requise ? Mode interactif, traitement par lots, temps réel ou hors ligne.
- De quels moyens opérationnels disposez-vous ? Aucune équipe d’infrastructure ; équipe applicative ; équipe plateforme ; équipe d’exploitation ML.
- De quels éléments probants les clients ou les autorités de contrôle ont-ils besoin ? Documents du fournisseur, journaux, localisation des données, piste d’audit, cloisonnement.
Choisissez ensuite l’architecture la moins complexe qui satisfait aux exigences relatives aux données et à la qualité.
Ne faites pas cela pour l’instant
N’optez pas pour l’auto-hébergement avant d’avoir mesuré la charge de travail et défini le niveau de qualité requis.
N’envoyez pas de données restreintes à des outils grand public.
Ne supposez pas qu’« open source » signifie « privé ». Le système n’est privé que si le déploiement, les journaux, les accès et le flux de données le sont eux aussi.
Ne déployez pas de passerelle d’IA sans classification des données tenant compte de l’identité, appliquée par des règles techniques et fondée sur un refus par défaut. Une passerelle centralisée peut faire respecter la politique, mais seulement si les contournements, les solutions de repli, les journaux et le comportement en cas d’échec sont testés.
N’ignorez pas les évaluations. Un résultat privé mais erroné reste erroné.
Point de départ pratique pour les PME
Voici une séquence de démarrage possible pour une PME, sous réserve de revue :
- Approuvez un seul assistant SaaS d’entreprise pour les tâches générales.
- Rédigez une règle de classification des données.
- Bloquez les données restreintes tant que leur usage n’a pas été examiné.
- Créez un seul flux RAG privé ou dans un VPC pour le cas d’usage confidentiel qui apporte le plus de valeur.
- Utilisez des modèles locaux pour des tâches sensibles étroites où la qualité est acceptable.
- Revenez sur l’auto-hébergement uniquement lorsque la confidentialité, la personnalisation ou le coût le justifient clairement.
Cette séquence crée un parcours de décision progressif. La protection des données dès la conception et par défaut exige toujours des décisions documentées sur la finalité, la minimisation, l’accès, la conservation, la suppression, les sous-traitants, les transferts et la sécurité (orientations de la Commission européenne).
Une architecture adaptée aux données, aux risques et à l’exploitation
L’IA privée est une architecture adaptée aux données, aux risques et aux capacités d’exploitation. Un portefeuille de solutions peut être pertinent, mais chaque voie doit avoir un responsable désigné et un périmètre vérifié.
Choisissez selon les données, l’impact, la qualité, la latence, les capacités d’exploitation et les éléments probants requis.
