Sécuriser l’IA appliquée aux appels d’offres : droits d’accès et confidentialité

01Un même dossier combine des données qui n’autorisent pas le même traitement

Confier un dossier d’appel d’offres à un système d’intelligence artificielle ne revient pas à transférer un simple ensemble de fichiers. Le même espace de travail peut réunir un règlement de consultation déjà public, des prix encore confidentiels, des curriculum vitæ, des références clients, des coordonnées nominatives et une stratégie de réponse. Une autorisation générale accordée au nom de la productivité ignore ces différences et rend le risque impossible à gouverner.

La première décision consiste à déterminer quelles catégories de données peuvent entrer dans quel environnement, sous l’autorité de quelles personnes et pendant combien de temps. Les recommandations relatives à l’IA générative insistent sur le choix de la solution, la gouvernance des usages, la documentation et la maîtrise du cycle de vie.^[3][8][10]

La sécurité attendue doit rester vérifiable. Une charte interne ne suffit pas si les comptes sont partagés, si les journaux mélangent plusieurs consultations, si le fournisseur peut réutiliser les contenus ou si le système possède les identifiants donnant accès au profil d’acheteur. L’autorisation utile relie une catégorie documentaire, un environnement précis, des identités nominatives, des règles de conservation et une procédure de retrait.

L’analyse documentaire assistée par l’IA peut rechercher, classer, extraire et synthétiser des informations dispersées.^[9] Ces capacités augmentent aussi le nombre de rapprochements possibles entre des données qui, auparavant, restaient séparées. La protection ne peut donc pas se limiter au fichier chargé. Elle doit couvrir les index, les résultats générés, les historiques, les traces techniques, les sauvegardes et les copies exportées.

Un dossier peut contenir des données personnelles et de la documentation sensible ou stratégique qui exigent un mode de traitement adapté.^[3][1][2] Les documents de la consultation décrivent le marché et les conditions de réponse. Le dossier de candidature ajoute des renseignements sur les capacités économiques, techniques et professionnelles. La préparation de l’offre introduit ensuite des prix, des choix d’organisation, des références, des profils et des arguments qui ne figuraient pas nécessairement dans les pièces publiées par l’acheteur.

Une classification exploitable distingue au minimum les documents publics de la consultation, les informations internes ordinaires, les données personnelles et les contenus stratégiques. Ces catégories ne forment pas une échelle abstraite de gravité. Elles déterminent les environnements admissibles, les personnes habilitées, les durées de conservation et les précautions à prendre avant tout transfert.

Le document public peut rester sensible par son contexte d’usage. Une annotation révèle parfois une décision interne. Un extrait isolé paraît banal alors que son association avec un prix, un nom de client ou une appréciation commerciale expose la stratégie de réponse. La classification doit donc examiner le fichier, ses annotations, les données ajoutées par les contributeurs et les résultats produits à partir de lui.

Le responsable du dossier doit aussi distinguer la donnée source de ses dérivés. Une synthèse, une liste de risques, une comparaison ou une requête enregistrée peut restituer une information confidentielle sans reprendre le document d’origine. Déplacer ce résultat dans un espace moins protégé contournerait le classement initial. La catégorie retenue suit l’information contenue, pas le format du fichier.

Le classement avant le transfert

Le classement intervient avant le chargement. Une étiquette ajoutée après l’envoi ne répare ni une exposition initiale ni une réutilisation déjà permise par le contrat. Le responsable doit pouvoir établir la provenance du document, son propriétaire métier, sa catégorie, les personnes concernées et l’usage autorisé. Si l’un de ces éléments reste inconnu, le transfert demeure suspendu jusqu’à clarification.

Les données personnelles appellent une attention particulière. Un curriculum vitæ, une signature, une adresse électronique, un numéro de téléphone ou une appréciation portant sur une personne ne se traite pas comme une clause technique. La nécessité de conserver chaque donnée doit être examinée. Une version expurgée peut suffire pour certaines analyses, tandis que la version complète reste dans un espace plus restreint.

La réduction du contenu envoyé est souvent plus robuste qu’une promesse générale de prudence. Extraire les seules clauses nécessaires, masquer les identifiants inutiles ou travailler sur une copie expurgée diminue la quantité d’informations confiées au système. Cette réduction ne dispense ni du contrat ni du contrôle des accès, mais elle limite les conséquences d’une erreur de configuration.

Le classement produit une décision lisible : autorisé dans l’environnement désigné, autorisé après expurgation, soumis à validation spécifique ou interdit. Une catégorie sans conséquence opérationnelle ne protège rien. La règle doit être comprise par la personne qui prépare le dossier et appliquée par les contrôles techniques.

Le registre associé à cette décision indique qui a classé le document, à quelle date et selon quelle règle. Il conserve aussi les restrictions utiles, telles que l’interdiction d’exporter, la suppression à la fin de la consultation ou l’obligation d’utiliser une version expurgée. Cette trace rend les décisions cohérentes lorsqu’un dossier change de responsable ou accueille un nouveau contributeur.

02Le mode de déploiement se choisit à partir des données, pas du confort d’accès

Le choix entre service grand public, API, cloud et déploiement sur site dépend des données d’entrée, des contrats et des responsabilités.^[3] Une interface agréable, une connexion immédiate ou une fonction réputée performante ne prouvent rien sur la réutilisation des contenus, l’emplacement du traitement, les sous-traitants, les journaux ou la capacité de supprimer les données.

Le mode de déploiement déplace les responsabilités. Dans un service grand public, l’organisation maîtrise peu de paramètres et dépend fortement des conditions proposées. Une API peut donner davantage de contrôle sur l’application et les flux, sans effacer la responsabilité liée au fournisseur du modèle ou à l’hébergement. Un cloud administré offre des mécanismes d’identité et de journalisation plus riches, à condition qu’ils soient configurés et compris.

Un déploiement sur site accroît la maîtrise directe de l’infrastructure, mais transfère aussi à l’organisation la charge de sécuriser, maintenir et surveiller le système. La localisation interne ne prouve ni la bonne gestion des comptes, ni la maîtrise des sauvegardes, ni l’absence de flux sortants. L’environnement doit être évalué sur des contrôles observables, pas sur une impression de proximité.

La bonne question est ce que chaque environnement permet de prouver pour la catégorie de données concernée. La revue examine les conditions contractuelles, le stockage, les flux sortants, les accès d’administration, la conservation, la suppression, les journaux et les sauvegardes. Elle identifie également la personne qui assume chaque contrôle et celle qui peut interrompre l’usage.

Une certification ou une offre professionnelle ne suffit pas si le contrat autorise une réutilisation incompatible avec le dossier. À l’inverse, un serveur interne mal administré, accessible par un compte générique et sauvegardé sans règle peut exposer davantage de données qu’un service externe correctement contractualisé et configuré. Le vocabulaire commercial ne remplace jamais la vérification des paramètres réels.

Quatre environnements, quatre niveaux de contrôle

Le service grand public convient uniquement aux contenus dont le transfert est expressément admis par la politique interne et par les conditions du fournisseur. La simplicité d’ouverture du compte ne modifie pas la nature des données envoyées. Une interdiction doit être soutenue par des contrôles adaptés lorsque l’enjeu le justifie, car une consigne isolée résiste mal à l’urgence d’une remise.

L’API sépare généralement l’interface métier du service de génération. Elle facilite le contrôle des entrées, des identités et des traces, mais oblige à examiner plusieurs couches : application, hébergement, fournisseur du modèle et éventuels intermédiaires. Les clés techniques doivent rester protégées, rattachées à une application et limitées aux fonctions nécessaires.

Le cloud d’entreprise peut centraliser les identités, les rôles, les journaux et les politiques de conservation. Cette capacité n’a de valeur que si les paramètres sont effectivement activés. Une configuration par défaut non examinée ne constitue pas une décision de sécurité. Le responsable doit savoir qui administre l’espace, qui peut exporter les contenus et comment les droits sont retirés.

Le déploiement sur site garde davantage de composants sous contrôle direct. Il demande toutefois des compétences de maintenance, de surveillance, de sauvegarde et de réponse aux incidents. Le choix local est pertinent lorsque les exigences documentaires justifient cette maîtrise et que l’organisation peut réellement l’exercer dans la durée.

L’arbitrage peut s’inscrire dans un audit des usages et de la gouvernance IA lorsque les catégories documentaires, les flux et les responsabilités restent dispersés entre plusieurs équipes. La suite utile consiste à produire une règle d’autorisation exploitable pour chaque environnement, sans déplacer la décision vers une simple comparaison de fonctions.

Le test doit porter sur un dossier représentatif, sans utiliser immédiatement les données les plus sensibles. Il vérifie les chemins de chargement, de recherche, d’export, de suppression et de révocation. Un environnement qui ne permet pas d’expliquer clairement l’un de ces chemins reste limité aux catégories pour lesquelles cette inconnue est acceptable.

03Un compte partagé efface précisément la responsabilité qu’il faudrait prouver

Les comptes, rôles, autorisations, mécanismes d’authentification et traces d’accès constituent des contrôles essentiels.^[5][4] Un compte partagé empêche d’attribuer une consultation, un export, une modification de paramètre ou une suppression. Il transforme une action individuelle en activité anonyme et affaiblit aussi bien la prévention que l’enquête après incident.

Chaque personne doit utiliser une identité nominative rattachée à son rôle réel. Cette identité ne donne pas accès à toutes les fonctions disponibles. Le responsable d’offre peut gérer le dossier sans administrer la plateforme. Un contributeur peut consulter certaines pièces sans exporter l’ensemble du corpus. Un administrateur technique peut maintenir le service sans lire systématiquement les contenus métier.

Le principe du moindre privilège consiste à n’accorder que les droits nécessaires, pour la durée nécessaire. Il impose de distinguer lecture, ajout, modification, export, administration, gestion des utilisateurs et suppression. Un rôle trop large crée un raccourci permanent autour des contrôles. Un rôle trop étroit peut conduire les utilisateurs à contourner le dispositif. La conception doit donc suivre le travail réel sans confondre commodité et autorisation.

L’authentification protège l’entrée, tandis que l’autorisation détermine ce que la personne peut faire après connexion. Les deux contrôles sont complémentaires. Une authentification renforcée n’empêche pas un utilisateur légitime d’accéder à un dossier qui ne relève pas de lui si les rôles sont mal définis.

La traçabilité complète ce modèle. Le journal doit relier une identité, une action, une ressource et un moment. Il devient utile lorsqu’il permet de répondre à une question précise : qui a consulté le dossier, qui a ajouté un fichier, qui a modifié les droits ou qui a exporté un résultat. Accumuler des événements non exploitables ne produit pas une preuve suffisante.

La journalisation doit aussi distinguer les actions humaines des opérations automatiques. Une indexation, une sauvegarde, un appel applicatif ou une suppression planifiée ne doit pas apparaître comme l’action d’un utilisateur générique. Les comptes de service restent identifiables et leurs privilèges sont limités au traitement qui leur est assigné.

Qui accède à quoi, quand et comment

La matrice d’habilitation commence par les fonctions métier et techniques, puis attribue les droits nécessaires à chacune. Elle inclut les titulaires, les suppléants, les administrateurs et les comptes de service. Ces derniers ne doivent pas devenir des identités humaines déguisées. Leur usage reste limité à une tâche, protégé par un secret géré et visible dans les journaux.

L’arrivée, le changement de poste et le départ d’une personne doivent entraîner une mise à jour des droits. Un accès qui survit au dossier ou à la mission crée une exposition silencieuse. La revue périodique ne consiste pas à faire confirmer une liste entière sans examen. Elle demande au responsable de justifier chaque droit encore actif.

Les accès exceptionnels méritent une procédure distincte. Une urgence ne devrait pas conduire à transmettre un mot de passe ou à élargir définitivement un rôle. Un droit temporaire, approuvé, journalisé et retiré automatiquement répond mieux au besoin. La date de fin fait partie de l’autorisation dès sa création.

Le mécanisme d’authentification doit être proportionné au risque. L’authentification multifacteur réduit l’effet d’un mot de passe compromis, particulièrement pour les administrateurs et les personnes pouvant exporter des dossiers. Elle ne remplace ni la séparation des rôles ni la surveillance des actions sensibles.

La qualité du modèle d’identité se mesure aussi à sa capacité de retrait. Si personne ne sait révoquer rapidement un compte, une clé ou un rôle, l’autorisation n’est pas réellement maîtrisée. La sécurité se vérifie autant au moment où l’accès prend fin qu’au moment où il est accordé.

Une revue utile part des dossiers, pas seulement de l’annuaire. Pour chaque consultation active, le responsable identifie les personnes qui doivent encore accéder aux pièces, les privilèges nécessaires et la date de retrait prévue. Cette lecture révèle les droits hérités d’un groupe trop large et les accès techniques qui ne correspondent plus à une fonction réelle.

04Séparer les dossiers empêche une recherche légitime d’accéder à des données hors périmètre

La séparation des dossiers, la maîtrise des journaux, de la conservation et des sauvegardes doivent être vérifiées avant usage.^[4][6] Le risque ne vient pas uniquement d’un accès manifestement malveillant. Une recherche parfaitement légitime peut ramener un extrait provenant d’une autre consultation si les index, espaces de travail ou droits ont été mélangés.

Le cloisonnement suit le périmètre métier. Deux appels d’offres concernant des clients différents ne partagent pas automatiquement le même corpus, même si la même équipe y travaille. Les références réutilisables peuvent être conservées dans une bibliothèque distincte, après décision explicite. Les pièces propres à une consultation restent dans son espace et suivent sa durée de vie.

La séparation logique doit être testée depuis le point de vue d’un utilisateur ordinaire. Il ne suffit pas que l’interface affiche deux dossiers. Une recherche transversale, une fonction de suggestion, un historique commun ou un export administrateur peut recréer le croisement. Le contrôle couvre les chemins visibles et les fonctions moins fréquentes.

Les résultats générés appartiennent eux aussi au périmètre. Une synthèse peut contenir des données issues de plusieurs fichiers et révéler davantage que chaque document pris isolément. Sa classification reflète les informations qu’elle contient, non le format sous lequel elle a été produite. Copier la synthèse vers un espace moins protégé contournerait le classement initial.

Les journaux peuvent contenir des noms de fichiers, des extraits de requêtes, des identifiants, des erreurs ou des paramètres. Ils deviennent alors des données sensibles à part entière. Leur accès doit être restreint, leur conservation justifiée et leur export contrôlé. Un journal utile à la sécurité ne doit pas créer une seconde copie incontrôlée du dossier.

Le test de séparation comprend une requête volontairement proche de plusieurs consultations. Il vérifie que la recherche, les suggestions et les résultats restent confinés au dossier autorisé. Il examine également les vues administratives et les fonctions d’export, car un cloisonnement correct dans l’usage quotidien peut disparaître dès qu’un privilège plus large est mobilisé.

Le cloisonnement inclut les journaux et les sauvegardes

Les sauvegardes prolongent souvent l’existence des données après leur suppression de l’espace actif. La politique précise leur fréquence, leur emplacement, leurs protections, leur durée et les modalités de restauration. Une suppression opérationnelle peut être immédiate dans l’application tout en restant différée dans une sauvegarde. Cette limite doit être connue et contractualisée.

La restauration mérite un test. Une sauvegarde protégée mais jamais restaurée ne prouve pas que le dossier pourra être récupéré sans réintroduire des droits obsolètes ou des fichiers qui devaient rester supprimés. Le scénario de restauration respecte le cloisonnement et produit une trace de l’opération.

La conservation se décide par catégorie et par finalité. Les documents utiles pendant la préparation ne doivent pas rester indéfiniment accessibles au même cercle. La fin de la consultation, l’expiration d’une obligation ou la disparition d’une finalité peut déclencher suppression, archivage restreint ou réexamen.

La suppression doit produire une preuve proportionnée. Le responsable doit pouvoir établir quel dossier a été supprimé, par qui, à quelle date et selon quel périmètre. Cette preuve ne doit pas recopier le contenu effacé. Elle décrit l’opération et les éventuels délais applicables aux sauvegardes.

La séparation est validée lorsque l’organisation sait démontrer qu’un utilisateur habilité sur un dossier ne peut ni rechercher, ni afficher, ni exporter les éléments d’un autre dossier. Le test comprend les contenus actifs, les résultats, les traces et les opérations de restauration.

Le cloisonnement couvre aussi les journaux, sauvegardes et délais d’effacement.

05La promesse de confidentialité ne remplace pas les clauses sur la réutilisation

Le contrat doit préciser les responsabilités, accès autorisés, réutilisations, sous-traitants et éventuels transferts hors de l’Union européenne.^[3] Une page commerciale affirmant que les données sont protégées ne permet pas de savoir qui peut y accéder, à quelles fins, pendant combien de temps ni selon quelles instructions.

La revue commence par identifier les parties. L’organisation doit savoir qui fournit l’application, qui héberge les données, qui exploite le modèle et quels sous-traitants interviennent. Une chaîne de services peut répartir le traitement entre plusieurs acteurs. Examiner uniquement le fournisseur visible laisse des responsabilités sans réponse.

La réutilisation mérite une clause explicite. Les données du dossier, les requêtes et les résultats peuvent-ils servir à entraîner, améliorer ou évaluer un service partagé ? Le refus doit couvrir les différentes formes de réutilisation pertinentes. Une option dans l’interface ne remplace pas une condition contractuelle stable si cette option peut changer ou dépendre du type de compte.

Les accès autorisés doivent être définis par fonction. Le personnel du fournisseur peut avoir besoin d’intervenir pour le support, la sécurité ou la maintenance. Le contrat décrit les circonstances, les contrôles, la traçabilité et les engagements applicables. Une possibilité d’accès non bornée affaiblit la confidentialité, même si le fournisseur affirme ne pas l’utiliser habituellement.

Les transferts hors de l’Union européenne ne se déduisent pas de l’adresse du siège commercial. Il faut examiner les lieux de traitement, les sous-traitants et les mécanismes juridiques applicables. Le responsable ne doit pas confondre localisation annoncée du stockage et absence de tout accès depuis un autre territoire.

La revue tient compte des différences entre les offres d’un même fournisseur. Les garanties d’un compte d’entreprise ne s’appliquent pas nécessairement à une version gratuite ou à un compte personnel. Le nom du service ne suffit donc pas. L’autorisation désigne l’offre, le type de compte et les paramètres examinés.

Les clauses applicables aux données

La durée de conservation couvre les entrées, les résultats, les historiques, les journaux techniques et les sauvegardes. Une suppression manuelle disponible dans l’interface ne démontre pas l’effacement de toutes les copies. Le fournisseur doit expliquer ce qui est supprimé, dans quel délai et quelles exceptions subsistent.

Le contrat traite aussi la fin de service. L’organisation doit pouvoir récupérer les éléments utiles, retirer les accès et obtenir la suppression des données restantes. Une dépendance technique qui rend l’export impossible peut prolonger artificiellement la conservation ou conduire à abandonner des informations chez le fournisseur.

La notification d’incident indique le canal, le délai prévu, les informations transmises et les personnes à contacter. Une formule générale sur la sécurité ne suffit pas à organiser la réaction. Le responsable doit savoir comment déterminer les dossiers touchés et révoquer les accès concernés.

Les modifications contractuelles demandent une surveillance. Un environnement autorisé sur la base de conditions données ne le reste pas automatiquement si la politique de réutilisation, la liste des sous-traitants ou les lieux de traitement changent. L’autorisation prévoit les événements qui imposent une nouvelle revue.

Une absence de réponse ne devient pas une garantie implicite. Si le fournisseur ne permet pas d’établir la réutilisation, les sous-traitants, les transferts, la conservation ou la suppression, les catégories sensibles restent exclues. Le bénéfice fonctionnel ne compense pas une condition de confidentialité invérifiable.

La preuve contractuelle conserve la version applicable lors de l’autorisation. Un lien vers des conditions susceptibles d’évoluer sans historique ne suffit pas. La date, l’offre concernée, les annexes pertinentes et les paramètres dépendant du compte doivent pouvoir être retrouvés lorsque l’autorisation est réexaminée.

06L’outil d’analyse ne doit jamais posséder les moyens de remettre l’offre

L’accès au profil d’acheteur et l’acte de remise doivent rester séparés des capacités d’analyse ou de génération du système.^[7][5][4] Le profil d’acheteur sert aux échanges et au dépôt électronique. Lui confier les identifiants nécessaires à la remise élargirait inutilement le périmètre du système et ferait dépendre un acte engageant d’une chaîne technique conçue pour traiter des documents.

Le système d’analyse ne possède aucun accès au profil d’acheteur. Le système d’analyse ne conserve ni mot de passe, ni facteur d’authentification, ni certificat, ni clé de signature donnant accès au dépôt. Il ne pilote pas une session déjà authentifiée et ne reçoit pas un jeton réutilisable. Sa fonction s’arrête à la production ou à l’export des éléments destinés aux personnes habilitées.

L’acte de remise appartient à un périmètre d’identité distinct. Les personnes autorisées se connectent au profil d’acheteur selon la procédure prévue, vérifient les fichiers à transmettre et accomplissent le dépôt. Cette séparation protège contre une action accidentelle, une automatisation mal configurée et l’exploitation d’un accès compromis.

La distinction ne porte pas sur la validation éditoriale de l’offre. Elle protège l’autorité d’engager l’organisation et la preuve de la personne ayant effectué la remise. Un fichier préparé par plusieurs contributeurs peut être transféré par une personne précisément mandatée. Le journal du dépôt reste alors associé à cette identité et au canal officiel.

Une intégration technique peut créer un passage indirect. Un connecteur de navigateur, une automatisation de poste ou un coffre de secrets partagé peut donner au système les moyens qu’aucune fonction visible ne revendique. La revue examine donc les extensions, les sessions persistantes, les répertoires surveillés et les comptes techniques.

Le contrôle inclut les postes de travail. Une session du profil d’acheteur laissée ouverte dans le même navigateur qu’un service d’analyse peut réduire la séparation attendue, notamment si des extensions ou automatisations disposent de droits étendus. Des profils de navigation distincts ou des environnements séparés rendent la limite plus visible et plus facile à vérifier.

Deux périmètres d’identité distincts

Le périmètre d’analyse comprend les comptes autorisés à lire, classer, rechercher et produire des résultats. Ses droits restent limités aux espaces documentaires approuvés. Le périmètre de dépôt comprend les personnes mandatées pour accéder au profil d’acheteur, utiliser les moyens d’authentification requis et remettre l’offre.

Les deux périmètres peuvent concerner certaines mêmes personnes sans devenir un seul compte. Une personne peut contribuer à l’analyse puis effectuer le dépôt sous une autre session et dans un environnement distinct. La séparation fonctionnelle demeure visible dans les traces et évite qu’un droit accordé pour une tâche ouvre automatiquement l’autre.

Le transfert entre les périmètres s’effectue par un fichier contrôlé ou un espace intermédiaire autorisé. Il ne transmet aucun secret d’authentification. La personne habilitée vérifie que le paquet correspond au dossier attendu, que les fichiers nécessaires sont présents et que les copies temporaires suivent les règles de conservation.

Les échecs doivent rester contenus. Une indisponibilité du système d’analyse ne doit pas bloquer l’accès au profil d’acheteur si les fichiers nécessaires ont été préparés. Une compromission de l’espace d’analyse ne doit pas fournir les moyens de remettre ou retirer une offre. Cette indépendance réduit la portée d’un incident.

La copie de sauvegarde et les échanges avec l’acheteur suivent les mêmes limites. Leur préparation peut mobiliser des documents issus de l’analyse, mais leur transmission reste accomplie dans le périmètre habilité. Le système ne décide pas du canal et ne possède pas les identifiants permettant de l’utiliser.

Le test le plus simple consiste à demander si la compromission complète de l’espace d’analyse donnerait accès au profil d’acheteur. Si la réponse dépend uniquement d’une consigne de prudence, la séparation est insuffisante. Les secrets, sessions et droits techniques doivent rendre ce passage impossible ou explicitement contrôlé.

07L’autorisation finale porte sur le dossier, l’environnement et la durée

Une autorisation générale accordée à un produit ne répond pas au risque réel. La décision porte sur un dossier ou une catégorie clairement définie, un environnement configuré, une population habilitée, des clauses contractuelles connues et une durée. Elle peut être restreinte, suspendue ou retirée lorsque l’une de ces conditions change.^{[3][4][5][6][7]}

Le dossier d’autorisation réunit la classification des données, le schéma des flux, les rôles, les règles d’authentification, la journalisation, la conservation, les sauvegardes et les garanties du fournisseur. Il décrit aussi la séparation du profil d’acheteur. La gouvernance du risque demande que les contrôles soient cartographiés, mesurés et suivis pendant le cycle de vie du système.^[8]

La décision doit être compréhensible sans connaître toute l’architecture. Elle précise les contenus admis, ceux qui doivent être expurgés et ceux qui restent interdits. Elle nomme les personnes pouvant administrer l’espace, les utilisateurs autorisés et le responsable capable de retirer l’accord.

L’autorisation peut être conditionnelle. Un environnement peut accepter les documents publics, mais exclure les curriculum vitæ et les prix. Un autre peut recevoir une version expurgée. Un périmètre plus maîtrisé peut traiter les contenus stratégiques sous réserve de contrôles supplémentaires. Cette gradation évite d’interdire indistinctement tous les usages ou d’autoriser tout le dossier au nom d’un service approuvé.

La date de fin est nécessaire. Elle peut correspondre à la fin de la consultation, à une échéance contractuelle ou à une revue programmée. Sans terme, les accès et les données tendent à survivre au besoin initial. Le retrait inclut les comptes temporaires, les copies de travail, les exports, les journaux selon leur politique et les sauvegardes selon leur cycle.

L’autorisation mentionne les hypothèses qui la soutiennent. Elle indique, par exemple, que la réutilisation contractuelle est exclue, que certains journaux sont activés ou que les données restent dans un territoire défini. Si une hypothèse n’est plus vraie, le responsable n’attend pas la prochaine revue périodique pour suspendre les chargements.

Une autorisation bornée et révocable

La révocation doit être possible sans négociation improvisée. Le responsable sait fermer un espace, retirer un rôle, révoquer une clé et demander la suppression au fournisseur. Un changement de sous-traitant, de lieu de traitement, de politique de réutilisation ou de configuration déclenche une nouvelle décision avant la poursuite des chargements.

La preuve ne doit pas être disproportionnée. Elle permet toutefois de reconstruire la décision : quelles données ont été admises, dans quel environnement, sur quelle base contractuelle, pour quels utilisateurs et jusqu’à quelle date. Une capture isolée d’un paramètre ne suffit pas si elle ne montre ni le périmètre ni la version applicable.

Le contrôle couvre aussi l’usage réel. Un environnement correctement autorisé peut être contourné par des comptes personnels, des exports locaux ou des copier-coller vers un autre service. Les journaux, les revues d’accès et les observations d’usage servent à détecter cet écart. La réponse associe rappel de la règle, correction technique et retrait d’accès lorsque cela est nécessaire.

L’autorisation finale n’affirme pas une sécurité absolue. Elle constate que les protections requises pour un périmètre donné sont présentes et que leurs limites sont connues. Les risques résiduels, les contrôles non disponibles et les conditions de réexamen restent consignés.

Le refus est une décision complète lorsque la classification, le contrat, l’identité ou le cloisonnement ne peuvent pas être établis. Il ne bloque pas nécessairement toute analyse. Le travail peut reprendre sur des extraits publics, des versions expurgées ou un autre environnement, à condition que cette variante fasse l’objet de sa propre autorisation.

Une révocation réussie doit être testable. Après le retrait, le compte ne peut plus ouvrir le dossier, la clé ne fonctionne plus et les copies autorisées suivent leur règle de suppression. Le responsable conserve la preuve de cette fermeture sans maintenir un accès caché au seul motif de faciliter une restauration ultérieure.

Un service n’est pas sûr en général : il est autorisé pour une catégorie de données, dans un environnement et pendant une durée définis.