Accès prestataires : qui surveille l’usage de vos données ?

Le 5 octobre 2026, le registre danois CPR annonce un accès non autorisé aux données d’environ 8,8 millions de personnes enregistrées. Le passage s’est effectué via une entreprise disposant d’un accès légal. Ce chiffre inclut des personnes décédées ou expatriées ; selon le CPR, les noms et adresses protégés sont exclus du périmètre concerné.

Pour un dirigeant, le point décisif tient à cette porte d’entrée : un prestataire peut être autorisé à consulter des données sans que chaque consultation soit justifiée. Quand vous lui ouvrez votre fichier clients, qui vérifie ce qu’il consulte, extrait ou transmet ? Et qui peut interrompre l’accès ?

Au Danemark, la facture a rendu l’anomalie visible

Selon DR, une facture anormalement élevée a contribué à découvrir l’incident, un élément confirmé par les autorités auprès du média. Une conséquence financière a donc participé à rendre l’usage suspect visible. Cela ne permet pas de conclure qu’aucune supervision technique n’existait.

Pays ApS a reconnu l’incident, selon les informations de TV2/Ritzau. D’autres détails appellent une attribution précise : d’après Politiken, au moins trois comptes, dont un compte administrateur, utilisaient le mot de passe « 123456 ». Ce point relève des révélations du journal, sans constituer une conclusion officielle sur l’ensemble des protections.

Le pirate présumé a également déclaré avoir utilisé un script réalisé avec l’aide d’une IA. Des experts interrogés par le journal jugent cette explication plausible. Elle ne démontre aucun contournement de sécurité par l’IA.

La question à reprendre dans votre entreprise est concrète : si le compte d’un prestataire extrait soudain beaucoup plus de données que prévu, qui le voit et qui peut agir ? Attendre une facture laisse la détection dépendre d’un signal indirect, potentiellement tardif.

Le contrat autorise une mission ; les droits déterminent l’exposition

Un contrat peut limiter une intervention à une campagne commerciale. L’outil, lui, peut donner accès à toute la base. Cet écart entre mission et capacité technique détermine les données exposées si un compte est compromis ou si son titulaire abuse de ses droits.

Prenons un exemple entièrement fictif. Une PME confie à un prestataire CRM la préparation d’une campagne destinée à un segment de clients inactifs. Son compte permet pourtant de consulter tous les clients et d’exporter le fichier complet. La mission concerne un segment ; l’accès expose l’ensemble.

La PME souhaite ensuite ajouter un agent IA chargé des relances. Si celui-ci hérite des mêmes droits et peut envoyer des messages, il cumule consultation, extraction et action sortante. Une erreur de ciblage peut alors se répéter rapidement. Il faut examiner séparément les autorisations de lecture, d’export et d’envoi.

Pour décomposer ces capacités, notre article sur les permissions, extensions et règles de gouvernance des agents IA aide à identifier ce qu’un outil connecté permet réellement d’exécuter.

Huit contrôles à demander avant d’étendre un accès

Les contrôles suivants sont des recommandations. Leur mise en œuvre dépend des outils et de la sensibilité des données ; chacun doit néanmoins produire une réponse vérifiable.

1. Identifier chaque intervenant. Demandez des comptes nominatifs pour les personnes, plutôt qu’un identifiant partagé. Pour un agent, prévoyez une identité technique distincte, rattachée à un responsable. Vous devez pouvoir attribuer une action sans confondre salarié, prestataire et automatisation.

2. Exiger une authentification renforcée. Activez l’authentification multifacteur, qui demande une preuve supplémentaire au mot de passe, idéalement résistante à l’hameçonnage lorsque l’outil le permet. Elle réduit certains risques de connexion frauduleuse. Elle n’arrête ni l’abus de droits déjà accordés ni nécessairement l’utilisation d’une session volée.

3. Réduire les droits à la mission. Listez les objets consultables et les opérations permises : lire un segment, modifier un champ, déclencher un envoi. Réservez l’administration aux interventions qui l’exigent et pour leur durée. Demandez pourquoi chaque permission supplémentaire est nécessaire.

4. Borner les volumes et les exports. Définissez ce qu’un usage normal peut consulter ou extraire, sur quelle période et vers quelle destination. Interdisez l’export global lorsqu’il n’est pas requis. Si l’application ne permet aucun plafond, consignez cette limite et choisissez une restriction compensatoire.

5. Surveiller des écarts utiles. Conservez des traces de consultation et d’export lorsqu’elles sont disponibles. Recherchez des anomalies liées à la mission : volume inhabituel, téléchargement massif, activité hors créneau prévu. Une alerte doit arriver à une personne capable de l’interpréter ; une accumulation de journaux ne suffit pas.

6. Nommer le responsable et l’escalade. Écrivez qui examine l’alerte, dans quel délai et qui peut suspendre le compte. Prévoyez le cas où le contact habituel est absent. Un prestataire peut enquêter sur son service ; votre entreprise doit garder un interlocuteur responsable de la décision.

7. Prévoir l’expiration et la révocation. Fixez une date de fin ou de révision. Identifiez les comptes, clés techniques et sessions à désactiver quand la mission s’arrête. Révoquer l’accès peut empêcher de nouvelles extractions ; cela n’annule pas une fuite et ne récupère pas les copies déjà sorties.

8. Demander une preuve d’exercice. Sur un périmètre de test autorisé, vérifiez qu’une action interdite est bloquée, qu’un événement anormal atteint le responsable et qu’une suspension fonctionne. Conservez la date, le résultat et les corrections. Une procédure écrite ne prouve pas que cette chaîne fonctionne.

Un agent augmente la cadence et change la validation

Ces contrôles s’appliquent aussi à un prestataire humain. Avec un agent, la vitesse d’exécution oblige à préciser davantage les limites : combien de dossiers peut-il traiter avant une revue ? Quel envoi nécessite une validation humaine ? Que fait-il si le segment demandé est introuvable ?

Dans notre exemple fictif, un agent de relance pourrait préparer les messages sur le seul segment autorisé, puis attendre une validation avant l’envoi. Une demande portant sur toute la base devrait déclencher une décision distincte. Ce choix réduit l’exposition sans supposer que l’agent interprétera toujours correctement une consigne ambiguë.

Les sept questions de sécurité à poser avant un projet d’IA agentique permettent de préparer cet échange avec la direction informatique : responsabilités, accès et validations doivent être décidés avant la mise en service.

Commencez par un accès qui existe déjà

Choisissez un prestataire ayant accès à des données sensibles. Demandez au responsable interne de rapprocher la mission contractuelle des droits effectivement ouverts, puis de montrer une trace d’activité et le mécanisme de suspension. Les réponses manquantes deviennent les priorités de correction.

Avant d’ajouter un agent métier, vous pouvez cadrer avec Amplify les premiers accès et les validations nécessaires. Cet échange sert à définir le périmètre de départ et les décisions à conserver côté entreprise. Il ne remplace ni un audit de sécurité ni l’examen de vos obligations par les professionnels compétents.

Références institutionnelles et presse

• CPR, communiqué du 5 octobre 2026 : ampleur, accès via une entreprise autorisée et précisions sur les personnes concernées.
• DR, découverte de l’incident : facture anormalement élevée et confirmation auprès des autorités.
• Ritzau, reprise sur dk-ai : informations TV2/Politiken, reconnaissance par Pays ApS et déclarations relatives au script assisté par IA.

Manon · Amplify

Manon écrit chez Amplify sur les agents IA, leurs usages métier et les décisions nécessaires à leur mise en service.

Senior AI Writer chez Amplify16 octobre 2026