La proposition du fournisseur paraît rassurante. Elle arbore un drapeau suisse, qualifie le service de « souverain » et promet de ne jamais utiliser les données clients pour l’entraînement. L’associé qui l’examine ne peut pourtant pas répondre à trois questions pratiques : les collaborateurs du support peuvent-ils ouvrir un dossier client ? Où part la trace d’une erreur ? Que peut récupérer le bureau si le service prend fin ?
Ces questions sans réponse ne doivent pas empêcher un petit bureau professionnel d’utiliser l’IA. Elles doivent modifier sa manière d’acheter. Des fichiers sensibles peuvent alimenter une recherche documentaire, une rédaction et une assistance aux processus utiles dès que le bureau transforme des promesses générales en contrôles qu’un fournisseur peut démontrer et tester.
L’achat d’une IA souveraine est un processus d’acceptation portant sur les flux de données, les accès, l’exploitation et la sortie. L’option gagnante est celle qui respecte les exigences du bureau dans la configuration livrée et peut être exploitée pendant la durée attendue.
Une mission de développement IA peut transformer la grille ci-dessous en une courte preuve menée avec des documents synthétiques ou caviardés. Pour des questions d’achat plus larges, l’acquisition d’agents IA aborde le dossier économique et l’adéquation du fournisseur. Ici, l’attention porte sur une question plus précise : vérifier les affirmations concernant le contrôle des informations sensibles.
Commencer par le travail que le bureau veut rendre possible
L’achat devient plus simple lorsque l’équipe part d’un processus concret. Un cabinet d’avocats peut vouloir obtenir des réponses citées dans un dossier. Une fiduciaire peut chercher une liste de pièces manquantes pour un client et une période. Un cabinet de conseil peut vouloir préparer un premier projet à partir des fichiers autorisés d’un projet.
Notez les documents concernés, les personnes autorisées à les consulter, les actions que l’assistant peut effectuer et l’approbation humaine qui subsiste. Vous obtenez ainsi une base de contrôles que chaque fournisseur doit respecter. Elle empêche aussi une architecture séduisante de recevoir davantage d’autorité que le travail ne l’exige.
Appliquez cette même base à trois options :
- Une appliance locale qui exécute l’inférence et la recherche dans le bureau
- Un service privé hébergé en Suisse avec des ressources dédiées ou isolées logiquement
- Un service d’entreprise géré avec des contrôles contractuels et techniques
Une appliance locale peut réduire les transferts habituels vers le point de terminaison d’un modèle et donner au bureau un contrôle direct des règles réseau et des mises à jour. Elle ajoute aussi la responsabilité des correctifs, de la sauvegarde, de la surveillance et de la reprise. Un service géré mature peut mieux exploiter ces fonctions. L’achat doit comparer les preuves et la capacité opérationnelle plutôt que classer les options uniquement selon leur distance physique.
Cette distinction sépare cet article de la décision plus large concernant l’achat d’une IA sur site. La question posée ici est de savoir comment le bureau vérifie ce que chaque option contrôle réellement.
Transformer chaque promesse de souveraineté en preuve
Le discours d’un fournisseur devient utile lorsqu’il renvoie à un document, une configuration ou un test. Toute étiquette « souveraine » doit être étayée par des preuves précises pour la version et le déploiement achetés.
| Affirmation du fournisseur | Preuve à demander | Contrôle d’acceptation |
|---|---|---|
| L’inférence s’exécute localement | Inventaire d’exécution, architecture réseau et configuration des mises à jour | Observer le trafic sortant pendant l’inférence et l’indexation |
| Les données restent en Suisse | Lieux de traitement, du support, des sous-traitants et des sauvegardes | Suivre chaque catégorie de données stockée ou transmise |
| Le client contrôle les accès | Rôles privilégiés nommés, propriété des clés et journaux d’accès | Tester séparément les comptes du bureau, du fournisseur et d’urgence |
| Le système est isolé du réseau | Architecture physique et logique du réseau | Démontrer le fonctionnement habituel ainsi que les procédures de mise à jour et de support |
| Les données ne servent jamais à l’entraînement | Conditions contractuelles et configuration de chaque usage des données | Vérifier séparément la surveillance, le débogage, les journaux et le support |
L’inférence locale indique où le modèle s’exécute. La résidence en Suisse indique où une étape de traitement ou de stockage se produit. La souveraineté opérationnelle concerne le contrôle des identités, de la politique réseau, des fichiers du modèle et de l’index, de la suppression, du calendrier des mises à jour et de l’accès du support. Le fonctionnement isolé décrit une topologie sans chemin réseau habituel. Chaque propriété peut compter et exige une preuve différente.
Un fournisseur peut satisfaire certaines exigences par contrat et d’autres par configuration. Consignez les deux. Si une affirmation ne peut pas être démontrée pendant la preuve, traitez-la comme une exigence ouverte avec un responsable et une échéance au lieu de combler le vide par un label ou l’adresse de l’entreprise.
Cartographier l’ensemble des flux, support compris
Demandez au fournisseur de cartographier tous les emplacements où un prompt, un document, un embedding, un résultat, un identifiant de compte, un événement de télémétrie ou une trace d’erreur circule ou réside. Le schéma doit inclure le navigateur, le connecteur, le service OCR, la base vectorielle, l’environnement d’exécution du modèle, la journalisation, la surveillance, le service de mise à jour, le support à distance, la sauvegarde et la reprise après sinistre.
Pour chaque composant, consignez :
- L’entité qui l’exploite et le pays où le traitement ou le stockage a lieu
- Les catégories de données reçues, leur finalité et leur durée de conservation
- Les rôles privilégiés et la possibilité pour le personnel du bureau de désactiver l’accès à distance
- Les sous-traitants, les flux facultatifs et le comportement en cas d’indisponibilité d’une dépendance externe
La grille du PFPDT pour le traitement des données dans le cloud demande aux responsables d’évaluer les conditions du prestataire, les pays de traitement, les inventaires, les sous-traitants, la suppression ou la restitution, la sécurité et la coopération en cas de demande d’exercice des droits ou d’enquête. Ces questions s’appliquent aussi aux services cachés derrière l’interface d’une appliance. Un appareil dans les locaux peut toujours contacter un serveur de licences externe, envoyer de la télémétrie ou ouvrir un tunnel de support.
La mention « sans entraînement » doit occuper une ligne de cette cartographie. L’utilisation pour l’entraînement se distingue de la surveillance des abus, du débogage, du support, des journaux, de la sauvegarde et de la conservation légale. Le fournisseur doit expliquer séparément le traitement de chaque chemin.
Observez ensuite le système livré. Capturez les connexions sortantes pendant l’inférence, l’indexation, les mises à jour et une session de support. Documentez les destinations attendues et bloquez un flux non approuvé afin de confirmer le comportement du produit. Un schéma décrit une intention. Le test réseau montre le chemin configuré.
Tester les accès administratifs et les droits des clients
Le dossier d’acceptation doit nommer chaque rôle privilégié. Séparez l’administrateur du bureau, le compte de support du fournisseur et le compte d’urgence. Consignez qui autorise l’accès, comment il expire, quelles actions sont journalisées et si le bureau peut désactiver le chemin du fournisseur hors d’une fenêtre de maintenance.
Demandez qui contrôle les clés de chiffrement, les fichiers du modèle, les instantanés de l’index et les certificats d’administration à distance. Une appliance locale reliée en permanence au fournisseur par un tunnel lui donne une position opérationnelle différente d’un appareil sur lequel le client ouvre une fenêtre de support limitée dans le temps et journalisée.
Les droits des utilisateurs méritent la même attention. L’assistant doit recevoir l’identité actuelle de l’appelant et appliquer ses droits par utilisateur, groupe, client ou dossier avant toute recherche. Testez la recherche, l’historique de conversation, les citations, les exports, les journaux et les vues administratives. Si le service d’identité ou de politique est indisponible, la demande doit échouer de manière sûre.
La révocation doit prendre effet immédiatement dans l’autorisation de la requête. Un index ou un cache peut avoir besoin de temps pour se mettre à jour. La copie périmée doit donc rester inaccessible pendant cet intervalle. Les fichiers déjà téléchargés ou exportés échappent à ce contrôle. Leur contrôle continu requiert un mécanisme géré précis et un test propre.
Les directives du PFPDT sur l’externalisation du traitement de données indiquent qu’un responsable reste chargé de sélectionner, instruire et surveiller ses sous-traitants, de gérer la confidentialité et la sécurité, puis de vérifier les transferts transfrontaliers. Les rôles exacts de responsable et de sous-traitant dépendent du mandat professionnel et du flux de données. Le contrat doit attribuer les obligations au lieu de les déduire du type de produit.
Examiner la chaîne d’approvisionnement des modèles et logiciels
La souveraineté peut échouer à cause de composants absents de la page marketing. Demandez le nom et la version du modèle, sa licence, la source des poids, les empreintes ou signatures, les dépendances de l’environnement d’exécution, le processus de gestion des vulnérabilités et le canal de mise à jour. Identifiez les composants téléchargés à l’exécution et toute fonction qui cesse lorsque le fournisseur devient inaccessible.
Le même examen doit couvrir l’OCR, les modèles d’embedding, la base vectorielle, l’authentification, les agents de surveillance et le logiciel de sauvegarde. Demandez quels éléments sont open source, propriétaires ou liés à un abonnement. Un modèle local peut encore dépendre d’un service d’identité hébergé ou d’un contrôle de licence distant.
Définissez qui peut remplacer le modèle et comment le changement est approuvé. Un nouveau modèle ou analyseur peut modifier la qualité des réponses, la gestion du contexte et les flux de données. Le bureau a besoin d’un test de régression sur ses documents représentatifs avant toute mise à jour en production.
Le noyau du cadre de gestion des risques liés à l’IA du NIST constitue une recommandation américaine volontaire et ne relève pas du droit suisse. Il est utile ici parce qu’il demande des rôles clairs, des contrôles de la chaîne d’approvisionnement tierce, des tests fondés sur les risques, une surveillance et une mise hors service planifiée sur tout le cycle de vie. Un petit bureau peut adapter cette structure sans en faire une affirmation de certification.
Cet inventaire logiciel soutient aussi l’indépendance à l’égard du fournisseur. L’indépendance des solutions IA auto-hébergées explique pourquoi la propriété de l’environnement d’exécution laisse subsister des dépendances concernant le matériel, les frameworks et les compétences opérationnelles.
Chiffrer le modèle d’exploitation avec le produit
Le prix de licence ou de l’appliance couvre rarement toute la décision. Demandez à chaque fournisseur de chiffrer ou d’attribuer la responsabilité du stockage chiffré, de la sauvegarde, des modifications réseau, de l’intégration des identités, des mises à jour du modèle et de l’index, de la surveillance, du support, de la formation du personnel, de la réponse aux incidents et de l’aide à la sortie.
Une comparaison simple de la première année doit rendre le calcul visible :
achat ou abonnement + intégration + support + heures d’administration × coût horaire interne + heures de contrôle prévues × coût du réviseur
Chaque chiffre de la comparaison doit provenir de l’offre du bureau ou d’une hypothèse explicitement qualifiée de fictive et datée dans le registre de décision. Incluez le coût d’une panne réaliste et le travail requis pour restaurer le service. Les frais par token ne peuvent pas représenter seuls le coût total d’un système qui exige aussi une exploitation sûre et un contrôle humain.
Les responsabilités ont besoin de noms et de chiffres. Attribuez les correctifs du système d’exploitation, les mises à jour du modèle, les reconstructions de l’index, les sauvegardes, la rotation des clés, la surveillance et la notification des incidents. Définissez qui peut suspendre l’inférence, préserver les preuves et restaurer le service. Une appliance locale confie davantage de ces tâches au bureau. Sa valeur dépend donc de la capacité d’une personne à les accomplir de manière constante.
Faire réussir au fournisseur une courte preuve d’acceptation
Utilisez des documents clients synthétiques dont les réponses sont connues. La preuve doit reproduire assez fidèlement la configuration d’identité, la politique réseau et le processus de support livrés pour révéler les contrôles manquants. Consignez chaque critère de réussite, la limite observée, le responsable et la date de correction.
Incluez les tests suivants :
- Deux clients ou dossiers portant des noms similaires, avec recherche de fuites par la recherche, les citations, l’historique et les exports
- Une suppression de droits qui bloque la requête suivante pendant la mise à jour des index et des caches
- Un fichier non fiable contenant des instructions destinées au modèle, tandis que les droits de l’application et les limites des outils restent appliqués
- Une question citée dont la preuve est connue, puis une seconde question dont la réponse est absente
- Une interruption contrôlée du service et une restauration depuis une sauvegarde sur une instance de test isolée
- Une observation du trafic sortant pendant le travail ordinaire, les mises à jour et le support du fournisseur
La preuve doit aussi inclure des langues et formats de document représentatifs. Une réponse soignée sur un PDF anglais propre indique peu de choses sur un tableau allemand numérisé ou une note de frais manuscrite. Mesurez la tâche que le bureau prévoit d’acheter.
N’autorisez aucun repli automatique vers un cloud public pour les processus sensibles, sauf si la même catégorie de données et la même destination ont reçu une approbation explicite. Un processus manuel dans le système source existant constitue généralement le plan de continuité le plus clair pour un petit bureau.
Tester la sortie avant la signature
Une clause de sortie devient crédible lorsque le bureau peut l’exercer. Avant de signer, demandez un export test des documents sources lisibles, des métadonnées, des listes d’accès par client ou dossier, des prompts nécessaires, des résultats et des données d’audit utiles. Confirmez que le personnel peut ouvrir les données essentielles sans le plan de contrôle propriétaire du fournisseur.
Les embeddings doivent souvent être reconstruits, car ils dépendent d’un modèle d’embedding et d’une conception d’index particuliers. Traitez-les comme du matériel de migration facultatif au lieu de présumer leur portabilité. Consignez les configurations, les jeux d’évaluation et les règles de processus exportables, ainsi que chaque élément propriétaire qui ne peut pas l’être.
L’accord doit définir la restitution ou la suppression des copies détenues par le fournisseur et les preuves qu’il remettra. Ces preuves ont des limites pratiques pour les copies hors de son contrôle. La cartographie des flux doit donc les repérer plus tôt. Les sauvegardes peuvent aussi suivre un calendrier d’expiration au lieu d’un effacement immédiat. Indiquez précisément le processus et le délai.
Lorsque c’est possible, testez une restauration sur un deuxième environnement d’exécution. Vérifiez au minimum que les documents sources, les métadonnées, les listes d’accès et les journaux d’audit restent lisibles et suffisent pour reconstruire le service. Intégrez l’aide à la sortie et le temps de migration interne dans la comparaison des coûts.
Cet exercice améliore l’achat actuel même si le bureau ne quitte jamais le fournisseur. Il révèle les formats cachés, les responsabilités floues et les éléments manquants alors qu’il reste du temps pour négocier.
Acheter des preuves que le bureau peut exploiter
L’achat d’une IA souveraine donne à un petit bureau professionnel un chemin méthodique vers une IA utile sur des informations sensibles. Il remplace le réconfort d’une promesse générale par une décision vérifiable : quelles données circulent, qui peut y accéder, quelles dépendances subsistent et comment le bureau restaure le service ou en sort.
L’appliance locale, le service privé hébergé en Suisse et la plateforme d’entreprise gérée peuvent tous constituer un choix valable. Soumettez les trois au même processus, au même dossier de preuves et à la même preuve d’acceptation. Choisissez l’option dont les contrôles sont démontrés et dont les responsabilités opérationnelles correspondent aux capacités du bureau.
Conservez le registre de décision après la signature. Rouvrez-le lorsque le fournisseur met à jour un modèle, change de sous-traitant ou propose un nouveau chemin de support. Posez alors la même question : la configuration livrée respecte-t-elle encore les contrôles acceptés par le bureau ?
Questions fréquentes
Que signifie l’achat d’une IA souveraine pour un petit bureau ?
Acheter une IA souveraine consiste à traduire l’étiquette d’un fournisseur en exigences précises concernant l’emplacement des données, les accès administratifs, les dépendances réseau, le contrôle des identités, l’exploitation et la sortie. L’acheteur compare chaque déploiement au moyen des mêmes preuves et du même plan de test. Le matériel local peut renforcer le contrôle opérationnel, tandis qu’un service privé ou d’entreprise géré peut satisfaire les exigences par des contrats et contrôles techniques adaptés.
L’hébergement en Suisse garantit-il le contrôle des données d’IA ?
Non. L’hébergement en Suisse établit un lieu de traitement ou de stockage, mais l’acheteur doit encore vérifier l’entité juridique du prestataire, sa société mère, les lieux du support, les sous-traitants, les sauvegardes, l’administration à distance et les accès transfrontaliers. Le contrat doit préciser comment les emplacements peuvent changer et comment le bureau peut s’y opposer. Des tests techniques doivent confirmer les connexions sortantes et les chemins d’accès privilégié réels.
Quelles preuves un fournisseur d’IA souveraine doit-il apporter ?
Demandez un schéma complet des flux, les lieux de traitement nommés, une liste des sous-traitants, la définition des rôles privilégiés, les journaux d’accès, la propriété des clés de chiffrement, la provenance des logiciels et modèles, les règles de conservation, les résultats des tests, les procédures de reprise et un format de sortie. Le fournisseur doit démontrer les contrôles essentiels avec des données synthétiques, car une politique ou un schéma d’architecture ne prouve pas leur fonctionnement réel.
Une clause excluant l’entraînement suffit-elle pour les données sensibles d’un bureau ?
Non. Une clause excluant l’entraînement répond à une seule question sur l’utilisation des données. Le bureau doit aussi examiner la surveillance des abus, le débogage, l’accès du support, la télémétrie, les sauvegardes, la conservation légale, les sous-traitants et la suppression. Ces chemins peuvent conserver ou exposer des prompts et documents même sans entraînement. Exigez des réponses contractuelles distinctes et observez le réseau ainsi que les journaux du système livré.
Que doit permettre d’exporter un plan de sortie d’IA ?
Le plan de sortie doit fournir, dans des formats documentés, les documents sources lisibles, les métadonnées, les listes d’accès par client ou dossier, les prompts nécessaires, les résultats et les données d’audit utiles. Les embeddings doivent souvent être reconstruits, car ils dépendent d’un modèle et d’un index précis. Inventoriez avant signature les éléments propriétaires ou indisponibles, testez la lecture des données essentielles sans le plan de contrôle du fournisseur et définissez les preuves de restitution ou de suppression.