if ( !emtpy($headline_subheadline ) ) : ?>
La conformité n’est qu’un début ; la vraie confiance vient du fait de s’assurer que les choix des clients suivent leurs données partout où elles vont.
endif; ?>
Au fil des années, j’ai appris que la confiance des clients ne se construit pas uniquement par la conformité. Cela vient de la façon dont les systèmes traitent réellement les données au quotidien. En pratique, je pense que cinq domaines comptent le plus
- Rendre l’intention du client cohérente sur tous les systèmes
- Traiter la confidentialité comme un problème de systèmes distribués
- Réduire les données inutiles
- Concevoir pour l’échec
- Comprendre comment l’IA élargit les limites de la confiance
J’aborderai chacun d’eux ci-dessous et expliquerai pourquoi ils sont importants dans les systèmes réels avec certaines de mes expériences. Pour les RSSI et autres responsables de la sécurité, ces idées peuvent également contribuer à transformer les objectifs généraux de confidentialité et de confiance en priorités concrètes en matière d’architecture, de gouvernance, de protection des données et de risque opérationnel.
J’ai appris cela en travaillant sur des systèmes de commerce numérique et de personnalisation à grande échelle. Une action client qui semble simple en apparence peut impliquer de nombreux systèmes en coulisses. Une préférence peut être stockée au même endroit, utilisée par plusieurs services, mise en cache pour les performances et également influencer les systèmes d’analyse ou d’apprentissage automatique. Cette expérience m’a appris que la confidentialité ne consiste pas seulement à avoir la bonne politique ou le bon contrôle dans un seul système. Le véritable défi est de s’assurer que le choix du client est respecté partout où les données sont utilisées.
Le premier domaine est intention du client. Si un client modifie un paramètre de confidentialité, refuse la personnalisation ou demande la suppression de certaines données, ce choix ne doit pas s’arrêter au système où elles ont été enregistrées pour la première fois. En pratique, les mêmes données peuvent déjà être utilisées par d’autres services, caches, pipelines d’événements, systèmes d’analyse ou workflows d’apprentissage automatique. Le défi consiste à s’assurer que le dernier choix du client est compris et respecté par tous, même lorsque ces systèmes ne sont pas mis à jour en même temps.
C’est là que la vie privée devient un problème des systèmes distribuéset la fraîcheur des données devient tout aussi importante que leur exactitude. Une préférence peut être mise à jour correctement dans le système source, mais un autre service peut encore avoir une valeur plus ancienne dans un cache, un événement peut déjà être en transit ou un processus par lots peut fonctionner à partir des données d’hier. En travaillant sur des systèmes de personnalisation et de recommandation, j’ai appris que des informations périmées peuvent être tout à fait exactes et néanmoins conduire à de mauvais résultats parce que l’intention du client a changé. La confidentialité fonctionne de la même manière, mais avec des conséquences plus importantes. Chaque système individuel peut fonctionner comme prévu, tandis que l’expérience globale ne reflète plus ce que le client a demandé. Pour les responsables de la sécurité, cela signifie qu’un contrôle de confidentialité ne doit pas être jugé uniquement en fonction de son existence, mais également en fonction de la rapidité et de la fiabilité avec lesquelles le dernier choix du client atteint chaque endroit où ces données sont utilisées.
La réglementation a poussé l’ingénierie dans la bonne direction. L’article 25 du RGPD a établi l’idée de protection des données dès la conception et par défaut, tandis que le cadre de confidentialité du NIST traite la confidentialité comme un problème de gestion des risques qui doit être pris en compte lors de la construction des systèmes. Je considère ces deux changements comme des changements importants, car ils rapprochent la confidentialité des décisions d’architecture et d’ingénierie. Mais dans la pratique, les programmes de protection de la vie privée peuvent toujours viser à prouver qu’un contrôle existe : le consentement a-t-il été recueilli ? Qui peut accéder aux données ? Pouvons-nous traiter les demandes de suppression ? Ces questions sont importantes, mais elles concernent toujours principalement la conformité. La question la plus difficile est de savoir si le système continue de respecter l’intention du client une fois que les données ont transité par plusieurs services, couches de stockage, pipelines et consommateurs en aval. Lors de la conception ou de l’examen d’un flux de données, je trouve une question particulièrement utile : « Si l’intention du client change ici, où l’ancienne intention peut-elle encore survivre ? Cela pousse la discussion au-delà de l’existence d’un contrôle et à la manière dont le système se comporte réellement.
La confiance se brise aux limites du système
Une demande de suppression est un bon exemple de cas où cela se complique. Pour le client, l’action est simple : il demande la suppression de ses données. En coulisses, ces informations peuvent exister dans le stockage transactionnel, les flux d’événements, les caches, les ensembles de données analytiques, les journaux ou les données dérivées utilisées par d’autres systèmes. Certaines informations peuvent devoir être supprimées rapidement, tandis que d’autres enregistrements peuvent avoir des exigences légitimes en matière de sécurité, de fraude, de conservation financière ou réglementaire. Le but n’est pas forcément de tout supprimer partout au même moment. L’important est de savoir où se trouvent les données, pourquoi elles se trouvent là, à qui elles appartiennent et ce qui doit se passer une fois que le client a fait la demande. C’est là qu’une exigence de conformité devient un problème d’ingénierie et de confiance opérationnelle.
C’est aussi pourquoi je considère la minimisation des données comme plus qu’une exigence de confidentialité. Chaque copie supplémentaire des données client crée un autre endroit qui doit être sécurisé et éventuellement nettoyé. Au fil du temps, les données collectées dans un but raisonnable peuvent devenir une dépendance pour les systèmes d’analyse, d’expérimentation ou d’apprentissage automatique et, dans la plupart des cas, pour les systèmes axés sur le commerce intensif et la personnalisation, la probabilité que cela se produise est très élevée. Amener les équipes gérant un nombre croissant de systèmes à comprendre les règles de confidentialité et de conservation. Pour les responsables de la sécurité, réduire les données inutiles peut donc réduire à la fois les risques liés à la vie privée et la complexité opérationnelle.
Les directives de la Federal Trade Commission à l’intention des entreprises vont dans le même sens : les entreprises doivent collecter uniquement les informations dont elles ont besoin et les conserver aussi longtemps qu’il existe une raison commerciale légitime de le faire. Une question utile pour la traduire en question d’ingénierie serait « Est-ce que ces données entraînent la complexité liée à leur conservation ? » Si la réponse est oui, alors le système doit avoir une propriété claire, des contrôles d’accès, des règles de conservation et un objectif défini. Si la réponse n’est pas claire, il s’agit généralement d’un signal pour remettre en question la raison pour laquelle les données sont collectées ou conservées en premier lieu, une bonne incitation à la suppression ou au respect de la politique de conservation minimale suivie par une équipe interne de sécurité des informations.
Les contrôles de confidentialité devraient être conçu pour l’échec
Une autre leçon que j’ai tirée de l’exploitation de systèmes à grande échelle est que nous ne devons pas concevoir uniquement pour le chemin du bonheur. En ingénierie de fiabilité, nous nous demandons régulièrement ce qui se passe lorsqu’une dépendance expire, qu’un message est retardé et/ou qu’un service devient indisponible. De la même manière, les contrôles de confidentialité doivent être revus. Que se passe-t-il si le système ne peut pas déterminer le dernier état de consentement ? Que se passe-t-il si une demande de suppression réussit dans la plupart des systèmes mais échoue dans un service en aval ? Que se passe-t-il si un ancien événement arrive après qu’un client a modifié ses préférences ? À grande échelle, ils deviennent des conditions de fonctionnement normales et les responsables de la sécurité doivent savoir comment le système est censé se comporter lorsqu’ils se produisent.
L’important est de rendre ce comportement d’échec intentionnel, car le choix le plus sûr peut être d’arrêter le traitement lorsque le dernier état de confidentialité ne peut pas être vérifié. Nous pouvons y voir une prévention de la fraude ou une sécurité requise sur les dossiers financiers où tous les systèmes n’ont pas besoin de la même règle. Ce qui compte, c’est que l’exception soit comprise et conçue plutôt que découverte lors d’un incident. Pour les RSSI, c’est là que la confidentialité passe de la politique au risque opérationnel, où nous devons nous demander si un contrôle existe et savoir ce que le système fera lorsque ce contrôle n’est pas disponible ou échoue.
Cela signifie également que la vie privée a besoin de sa propre observabilité. Nous déployons beaucoup d’efforts pour surveiller la disponibilité, la latence et les taux d’erreur, mais je pense que les contrôles de confidentialité devraient avoir des signaux opérationnels similaires. Combien de temps faut-il pour qu’un changement de préférence atteigne les systèmes en aval ? Où les demandes de suppression échouent-elles ? Quels systèmes dépendent encore de données qui auraient dû être retirées ? Sans cette visibilité, les équipes peuvent connaître l’existence d’un contrôle de confidentialité, mais avoir très peu confiance dans son comportement en production. Pour les RSSI, il est important de comprendre que la confidentialité doit non seulement être auditée périodiquement, mais également mesurable dans le cadre de la santé quotidienne du système.
L’IA élargit le limite de confiance
J’ai vu cette frontière de confiance grandir avec le temps. Au cours de la période 2015-2020, les systèmes de personnalisation et de recommandation sont devenus de plus en plus sophistiqués en rassemblant davantage de signaux clients pour améliorer la pertinence et l’expérience. Avec les LLM et désormais les systèmes agents, cette frontière s’étend beaucoup plus rapidement. Une application traditionnelle peut lire à partir d’une base de données connue ou appeler une API définie. Un système d’IA peut récupérer des informations à partir de documents, de dossiers clients, d’interactions précédentes ou d’autres outils, combiner ces informations et prendre de plus en plus d’actions en fonction de celles-ci. Cela rend la limite de confiance ridiculement large. Pour les RSSI, les ingénieurs, les équipes d’audit et de sécurité, la question n’est plus seulement « Qui peut accéder à ces données ? » il s’agit plutôt de « Quelles informations ce système peut-il récupérer, combiner et sur lesquelles agir ? »
L’ampleur de ce changement est déjà visible. L’étude comparative 2026 sur les données et la confidentialité de Cisco a révélé que 90 % des organisations interrogées avaient étendu leurs programmes de confidentialité grâce à l’IA, tandis que 93 % prévoyaient d’investir davantage dans la confidentialité et la gouvernance des données au cours des deux prochaines années. J’y vois le signe que la gouvernance de l’IA ne peut être séparée de la gouvernance des données. Avant de réfléchir aux modèles de contrôle, les responsables de la sécurité doivent comprendre quelles données le système d’IA peut atteindre, comment cet accès est autorisé et si les mêmes règles de confidentialité continuent de s’appliquer lorsque les informations sont récupérées, combinées ou utilisées pour entreprendre une action. Le risque va au-delà d’une trop grande quantité de données, il est également possible que les clients ne comprennent pas comment leurs informations sont utilisées une fois que l’IA est impliquée. Une interaction d’assistance, un document ou une transaction passée peuvent avoir été collectés dans un seul but, mais un système d’IA peut rendre ces informations utiles dans un contexte complètement différent et dans un lieu où la confiance peut s’éroder rapidement. Pour moi, la question pratique est de savoir si les attentes initiales du client sont toujours valables lorsque les données sont réutilisées par un système d’IA. Si la réponse n’est pas claire, l’architecture et le modèle de gouvernance nécessitent davantage de travail avant que la fonctionnalité ne évolue.
Faire de la confiance une priorité du RSSI
Je pense que ce qu’il faut retenir d’un point de vue pratique, c’est d’intégrer la confiance des clients au processus d’examen du système plutôt qu’un contrôle uniquement lors des examens de conformité. Lors de l’examen d’un nouveau flux de données, d’une capacité d’IA ou d’une fonctionnalité orientée client, je poserais quelques questions de base : quelles données client sont utilisées ? Pourquoi est-ce nécessaire ? Dans quelle mesure la préférence du client doit-elle être fraîche ? Où ces données peuvent-elles voyager ou être copiées ? Les données sont-elles classées et annotées afin que les systèmes en aval sachent comment elles doivent être traitées ? Que se passe-t-il en cas d’échec d’un contrôle de confidentialité ? Et pouvons-nous observer si le système se comporte réellement comme nous le souhaitions ? Une approche pratique qui, selon moi, fonctionne bien dans les grands systèmes distribués consiste à attacher les bonnes métadonnées de sécurité et de confidentialité aux données elles-mêmes. Par exemple, la classification peut aider à identifier les données sensibles, les métadonnées de conservation peuvent définir la durée pendant laquelle elles doivent rester et les politiques de routage peuvent déterminer où ces informations sont autorisées à se déplacer. Cela devient particulièrement utile lorsque les mêmes données circulent via de nombreux services, car le contrôle ne dépend pas entièrement de la mémorisation de l’intention initiale par chaque équipe en aval.
Ce type de contrôles permet de transformer un objectif général tel que « gagner la confiance des clients » en priorités concrètes en matière d’ingénierie et de gouvernance de la sécurité de l’information. Le travail le plus difficile consiste à s’assurer que le système continue de respecter l’intention du client à mesure que les données sont déplacées, copiées ou utilisées de nouvelles manières. Pour les responsables de la sécurité, la priorité est de prouver que les contrôles appropriés existent tout en comprenant comment ces contrôles se comportent en production et si l’architecture peut préserver l’intention du client malgré les changements, les échecs et les flux de données de plus en plus complexes basés sur l’IA, alors la conformité devient une partie d’un système auquel les clients peuvent réellement faire confiance.
