B2Shift · Publié le 3 août 2026 · Mis à jour le 14 août 2026
La plupart des incidents liés à l’IA en entreprise ne sont pas des défaillances de modèle. Ce sont des défaillances d’accès : un système qui pouvait atteindre plus de données que la tâche ne l’exigeait, agissant sans point de contrôle, sans laisser de trace. Les mesures qui l’empêchent relèvent de l’ingénierie ordinaire, appliquée délibérément.
Commencez par la minimisation et une finalité documentée
Une automatisation attentive au RGPD commence avant la première ligne de code : écrivez à quoi sert le flux, quelles données personnelles il lui faut réellement, et combien de temps elles doivent être conservées. Puis faites correspondre le système. Seuls les champs et systèmes dont le flux a effectivement besoin doivent être accessibles — pas tout le CRM parce que c’était plus simple à ouvrir.
C’est aussi le contrôle le moins coûteux à mettre en place et le plus coûteux à rattraper. Élargir un accès plus tard est un changement de configuration ; le restreindre après un an d’exploitation revient à découvrir ce qui en dépendait discrètement.
Verrouillez ce qui ne peut pas être défait
Toutes les étapes n’ont pas besoin d’une validation, et les traiter à l’identique apprend aux gens à cliquer machinalement. Séparez les actions selon leur réversibilité. Lire, classer, rédiger et orienter peuvent généralement s’exécuter sans surveillance. Envoyer de l’argent, publier des prix, répondre à une réclamation, supprimer des enregistrements et tout ce qui atteint un client en votre nom mérite une validation humaine, ou au minimum un délai pendant lequel une personne peut intervenir.
L’accès par rôle fait partie de la même conversation. L’automatisation doit agir avec sa propre identité et ses propres droits, non en empruntant les identifiants d’un administrateur — ce qui est à la fois un problème de sécurité et de traçabilité, puisque ensuite plus personne ne distingue l’humain de la machine dans les journaux.
Rendez chaque décision reconstituable
Chaque action doit laisser une trace d’audit : ce qui l’a déclenchée, quel contexte a été utilisé, ce que le système a décidé, avec quelle confiance, si un humain a validé, et ce qui a changé en conséquence. Cela ressemble à une contrainte de conformité jusqu’au jour où un client conteste quelque chose ; c’est alors la seule chose qui vous sépare d’une supposition.
La gestion de la confiance appartient au même chapitre. Un flux doit avoir un chemin explicite pour les cas peu fiables : vers une personne nommée ou une file d’attente, pas silencieusement vers la meilleure hypothèse. Le mode d’échec souhaitable est « c’est parti chez un humain », pas « c’est parti de travers et personne ne l’a vu pendant trois semaines ».
Sachez où tourne le modèle et ce qu’il conserve
Posez trois questions à tout fournisseur : où les données sont-elles traitées, sont-elles conservées, et servent-elles à l’entraînement ? Les réponses diffèrent sensiblement entre les produits grand public et les offres professionnelles d’un même éditeur, et entre déploiements hébergés et privés. Pour des données réglementées, le choix de déploiement — régions UE, hébergement privé ou modèles ouverts auto-hébergés — est une décision de conformité, pas une préférence.
L’avis du Comité européen de la protection des données sur les modèles d’IA est la référence à lire avant de figer une architecture ; il traite des cas où les sorties de modèles et les données d’entraînement engagent réellement des obligations de protection des données.
Ce que les contrôles techniques ne peuvent pas faire
Tout ce qui précède réduit le risque. Rien n’établit une base légale de traitement, ne rédige votre politique de confidentialité, ne décide si une analyse d’impact est requise, ni ne tranche vos responsabilités de responsable de traitement ou de sous-traitant. Cela dépend de votre cas d’usage précis et des parties impliquées, et relève d’une revue juridique plutôt que technique. De bons contrôles rendent cette revue simple ; ils ne la remplacent pas.
Discuter de votre flux