La confiance ne doit pas être maximisée. Il doit être gagné, prouvé et continuellement calibré.
Presque toutes les entreprises technologiques prétendent instaurer la confiance. Mais l’expression « faites-nous confiance » révèle déjà le problème sous-jacent : elle demande de la confiance avant de la justifier suffisamment. Un fournisseur de logiciels peut prétendre que les données des clients sont sécurisées. Un client peut croire cette affirmation et décider de faire confiance au fournisseur. Cependant, la question de savoir si le fournisseur est réellement digne de confiance est une autre question. Seules les preuves concernant les contrôles de sécurité mis en œuvre, leur efficacité, leur portée et leur fonctionnement continu peuvent constituer une base rationnelle pour cette confiance. C'est là que des concepts tels que trust, trustworthiness, assurance, reliance, compliance, digital trust et Zero Trust sont souvent mélangés. Pourtant, ils décrivent différents aspects du même problème.
Comprendre ces distinctions nous aide à répondre à une question beaucoup plus vaste :
Que devrait signifier la confiance dans un monde numérique où les systèmes, les organisations et les risques évoluent continuellement ?
Dans les recherches organisationnelles et psychologiques, la confiance est généralement associée à la volonté d’accepter la vulnérabilité. Rousseau et coll. décrivent la confiance comme un état psychologique impliquant l’intention d’accepter la vulnérabilité basée sur des attentes positives concernant les intentions ou le comportement d’autrui [1]. Mayer, Davis et Schoorman définissent de la même manière la confiance comme la volonté de devenir vulnérable face à une autre partie, même lorsque cette partie ne peut pas être complètement surveillée ou contrôlée [2]. (Porte de recherche) La confiance nécessite donc au moins deux conditions : il doit y avoir une incertitude et quelque chose de significatif doit être en jeu.
Lorsqu’un résultat est totalement certain, la confiance n’est pas nécessaire. Lorsqu’il n’existe aucune perte ou dépendance potentielle, ce qui semble être de la confiance peut simplement être une commodité. La confiance devient pertinente lorsque nous dépendons d’une autre personne, d’une organisation ou d’un système et que cette dépendance crée une vulnérabilité. Cela signifie également que la confiance n’est jamais simplement une propriété universelle d’une entité. Une formulation plus précise serait :
A fait confiance à B par rapport à X, dans des conditions Y, à un moment donné.
Une entreprise peut faire confiance à un fournisseur de cloud pour stocker du matériel de marketing public, mais ne pas automatiquement faire confiance au même fournisseur pour traiter des informations de santé hautement sensibles. Un système peut être suffisamment fiable pour un cas d’utilisation tout en étant totalement inapproprié pour un autre. La confiance est donc relationnelle, spécifique au contexte et dépendante du risque.
Dans le langage courant, « fiable » et « digne de confiance » sont souvent traités comme des synonymes. Mais sur le plan conceptuel, ils décrivent deux choses différentes. Trusted signifie qu'une entité reçoit réellement confiance. Digne de confiance signifie que l'entité mérite cette confiance. On peut faire confiance à un fraudeur convaincant sans pour autant être digne de confiance. À l’inverse, un système soigneusement conçu et bien gouverné peut être fiable mais ne pas parvenir à gagner la confiance des utilisateurs car ses capacités, ses contrôles et ses limites restent invisibles. Mayer et coll. identifient trois dimensions largement utilisées de la fiabilité perçue : la capacité, l'intégrité et la bienveillance [2].
La capacité fait référence à la question de savoir si la partie de confiance est suffisamment compétente pour effectuer la tâche concernée. L'intégrité fait référence à la cohérence de ses déclarations, de ses principes et de son comportement réel. La bienveillance fait référence à la question de savoir si elle est censée prendre en compte les intérêts de la partie qui lui fait confiance plutôt que de rechercher exclusivement son propre avantage. (JSTOR) Pour les systèmes techniques, ces dimensions doivent être traduites. La capacité devient capacité technique, fiabilité, résilience et sécurité. L'intégrité se traduit par un comportement prévisible, des règles cohérentes, un traitement traçable et une communication véridique sur les limites. La bienveillance ne peut pas être simplement attribuée à une machine. Elle peut cependant être évaluée par rapport à l’organisation qui développe et exploite le système : l’organisation protège-t-elle les intérêts des utilisateurs ? Communique-t-il honnêtement les risques ? Prévoit-il des mécanismes de responsabilisation et de réparation ?
Le NIST aborde la fiabilité du point de vue de l’ingénierie des systèmes. Un système digne de confiance n’est pas seulement un système auquel les gens font confiance. Sa fiabilité doit être fondée sur la preuve qu'il peut satisfaire aux exigences critiques qui lui sont imposées. Selon le contexte, ces exigences peuvent inclure la sécurité, la sûreté, la fiabilité, la résilience, la confidentialité ou d'autres propriétés du système [3]. Cette distinction est fondamentale :
La confiance existe dans l’esprit de celui qui fait confiance. La fiabilité existe dans les qualités et le comportement de l'entité de confiance.
Les deux peuvent s’aligner, mais ils ne s’alignent pas automatiquement.
Une autre distinction importante existe entre la confiance et la reliance. La confiance est une attitude, une attente ou un jugement. La dépendance est un comportement observable. Une personne peut se méfier d’un système d’IA et néanmoins suivre ses recommandations parce qu’aucune alternative n’est disponible, parce que la pression du temps est élevée ou parce que le processus organisationnel l’exige. À l’inverse, une personne peut généralement faire confiance à un système mais ignorer intentionnellement ses recommandations dans un cas spécifique. Cette distinction est importante car les enquêtes demandant aux utilisateurs s'ils font confiance à un système ne prédisent pas nécessairement quand ces utilisateurs s'y fieront. Les recherches récentes sur l’interaction homme-IA séparent donc de plus en plus la confiance perçue, la confiance comportementale, les performances du système et la pertinence de la décision qui en résulte [8]–[10]. (Bibliothèque numérique ACM)
La conformité n'équivaut pas non plus à la fiabilité. La conformité répond initialement à une question plus précise :
Un ensemble défini d’exigences a-t-il été satisfait dans un périmètre défini ?
Une certification, un rapport d’audit ou une évaluation peut constituer un motif de confiance important. Il ne s’agit cependant pas d’une déclaration illimitée et permanente selon laquelle une organisation est sécurisée. Un audit peut confirmer qu'un système de gestion particulier a été correctement mis en œuvre dans un périmètre particulier et pendant une période particulière. Cela ne prouve pas automatiquement que chaque configuration actuelle est correcte, que chaque système nouvellement introduit est couvert ou qu'aucun incident de sécurité ne peut survenir. Le NIST met donc en garde contre le fait de considérer la conformité comme la seule base probante de l'assurance ou de la fiabilité. La conformité peut apporter des preuves précieuses, mais une approche axée uniquement sur la conformité peut établir une apparence de sécurité sans démontrer de manière adéquate l'efficacité du système sous-jacent [3]. (Publications du NIST)
La conformité est importante. Mais la conformité est un contributeur à une confiance justifiée, et ne s'y substitue pas complètement.
Entre la confiance subjective d’une partie et la fiabilité réelle d’un système se trouve un autre concept : l’assurance. Le NIST décrit l'assurance en termes de motifs de confiance justifiée selon lesquels une réclamation a été ou sera satisfaite [3]. L'assurance n'est donc ni un sentiment ni une garantie. C'est une justification structurée. Une structure d'assurance robuste doit rendre visible au moins cinq éléments : Réclamations : Qu'est-ce qui est affirmé exactement ? Arguments : Pourquoi les informations disponibles devraient-elles étayer cette affirmation ? Preuve : Quels enregistrements, observations, tests ou artefacts démontrent la mise en œuvre et l'efficacité ?
Hypothèses : Sous quelles conditions la conclusion reste-t-elle valable ? Portée : Quels systèmes, processus, données, emplacements et périodes sont couverts ? Le NIST utilise le concept de cas d'assurance pour décrire une relation structurée et révisable entre les affirmations, les arguments, les hypothèses et les preuves à l'appui [3]. Considérez la déclaration de sécurité suivante :
Toutes les données de production sont cryptées au repos.
Une politique de chiffrement d’entreprise démontre qu’une intention et une exigence existent. Cela ne prouve pas que tous les systèmes de stockage de production mettent réellement en œuvre cette exigence. Une capture d'écran d'une configuration de base de données fournit des preuves de cette base de données particulière à un moment donné. Cela ne démontre pas nécessairement une couverture complète. Un dossier d’assurance plus solide pourrait combiner :
Les différentes formes de preuve répondent à des objectifs différents. Une stratégie prend en charge la conception prévue. Une configuration prend en charge la implémentation technique. Un test ou une télémétrie continue prend en charge le fonctionnement réel. Un examen étaye la conclusion selon laquelle les preuves ont été évaluées et acceptées par une partie responsable. Aucun de ces éléments n’est nécessairement suffisant à lui seul. L'assurance découle de la relation traçable entre la réclamation initiale, la portée couverte, la mise en œuvre et les preuves disponibles. Un système d’assurance mature doit également être capable de produire des conclusions négatives. Il doit pouvoir affirmer que :
Le NIST reconnaît explicitement qu'une analyse d'assurance peut produire des résultats défavorables lorsque les preuves ne soutiennent pas l'affirmation [3]. (Publications du NIST) Un système qui ne peut générer que des coches vertes peut créer une certaine assurance. Cela ne crée pas nécessairement une assurance crédible.
À première vue, Zero Trust semble contredire l’objectif d’instaurer davantage de confiance. Ce n’est pas le cas. Zero Trust aborde un autre niveau du problème. Il ne s’agit pas essentiellement d’une philosophie psychologique ou culturelle. Il s’agit d’une approche architecturale des décisions d’accès. Dans un modèle Zero Trust, la confiance n'est pas accordée simplement parce qu'un utilisateur ou un appareil se trouve à l'intérieur d'un réseau d'entreprise, appartient à l'organisation ou a déjà été authentifié. L'accès est évalué par rapport à une ressource, une identité, un appareil, un contexte et une demande spécifiques. Les autorisations doivent être limitées, réévaluées en permanence et accordées en supposant qu'un réseau ou un système peut déjà être compromis [4].
La sécurité traditionnelle basée sur le périmètre résume souvent une décision de confiance complexe en une seule hypothèse générale :
Au sein du réseau d’entreprise signifie digne de confiance.
Zero Trust décompose cette hypothèse en décisions plus petites :
Cette identité, utilisant cet appareil, dans ces conditions, peut-elle accéder à cette ressource maintenant ?
Le Zero Trust n’est donc pas la fin de la confiance. C'est la fin de la confiance implicite, large et héritée de façon permanente. Une interprétation plus précise serait :
Zéro confiance implicite. Zéro privilège non mérité.
Une organisation peut avoir à la fois une culture de confiance élevée et une architecture Zero Trust. Les employés ne sont pas obligés de se soupçonner personnellement les uns les autres simplement parce que les décisions d'accès sont techniquement vérifiées. En fait, des contrôles bien conçus peuvent faciliter la confiance interpersonnelle. Ils réduisent la probabilité qu'une erreur individuelle, un compte compromis ou une demande malveillante entraîne des dommages illimités. Zero Trust remplace une hypothèse de confiance vaste et vague par de nombreuses décisions plus petites, contextuelles, temporaires et révocables. Cela est tout à fait compatible avec une compréhension moderne de la confiance.
La fiabilité se concentre souvent sur les qualités d’une organisation, d’un système ou d’une relation particulière. La Confiance numérique élargit la perspective à l'ensemble d'un écosystème numérique. Le Forum économique mondial décrit la confiance numérique comme l’attente selon laquelle les technologies et services numériques, ainsi que les organisations qui les fournissent, protégeront les intérêts des parties prenantes et défendront les attentes et les valeurs sociétales pertinentes. Son cadre relie la confiance numérique à des dimensions telles que la cybersécurité, la confidentialité, la transparence, l'auditabilité, l'équité, l'interopérabilité, la sécurité et les mécanismes de recours [5]. (Forum économique mondial) L'ISACA définit de la même manière la confiance numérique autour de la confiance dans l'intégrité des relations, des interactions et des transactions à travers un écosystème numérique composé de personnes, d'organisations, de processus, d'informations et de technologies [6]. (ISACA)
Cette perspective écosystémique est importante car la fiabilité d’un produit numérique dépend rarement de ce produit seul. Un fournisseur SaaS peut s’appuyer sur :
La fiabilité du produit visible dépend donc également de contrôles, d'hypothèses et de dépendances qui restent largement invisibles pour ses utilisateurs. La confiance numérique peut être comprise comme un résultat économique et sociétal plus large. La fiabilité décrit les propriétés qui rendent l'écosystème digne de confiance. L’assurance constitue le pont entre ces propriétés et la décision de confiance d’une partie prenante.
L’intelligence artificielle rend particulièrement visible la différence entre la confiance perçue et la fiabilité réelle. Un système d’IA peut communiquer de manière fluide, confiante et convaincante sans être systématiquement correct. Une interface peut signaler transparence et compétence même lorsque le modèle sous-jacent n'est pas suffisamment fiable pour la tâche prévue. Les explications, les scores de confiance ou le langage humain peuvent influencer les perceptions des utilisateurs. Ils ne constituent pas automatiquement une preuve qu’une réponse est correcte. Le NIST ne définit donc pas une IA digne de confiance à travers une seule propriété. Le cadre de gestion des risques liés à l’IA identifie plusieurs caractéristiques, notamment la validité et la fiabilité, la sûreté, la sécurité et la résilience, la responsabilité et la transparence, l’explicabilité et l’interprétabilité, la confidentialité et la gestion des préjugés préjudiciables. Le NIST souligne également que ces caractéristiques sont contextuelles et peuvent impliquer des compromis [7].
Un système peut être précis mais injuste. Cela peut être transparent mais peu sûr. Il peut préserver la vie privée mais demeure peu fiable pour l’usage auquel il est destiné. Il peut fonctionner correctement en moyenne, mais échouer de manière imprévisible dans les cas les plus importants. L’étiquette « IA digne de confiance » ne doit pas occulter ces distinctions. La recherche sur les interactions homme-IA discute donc de plus en plus de la confiance appropriée, de la confiance calibrée et de la dépendance appropriée. L’objectif n’est pas d’amener autant que possible les utilisateurs à faire confiance à un système. L’objectif est d’aider les utilisateurs à comprendre précisément les capacités et les limites du système et à s’y fier uniquement lorsque cette confiance est justifiée.
Une revue systématique de Mehrotra et al. ont constaté qu'il n'existe toujours pas de définition unique et cohérente de la confiance appropriée dans la littérature. Les études de recherche utilisent différents concepts et mesures pour la confiance, les intentions, la confiance, la capacité perçue et les performances réelles du système [8]. (Bibliothèque numérique ACM) Visser et coll. de même, distinguez la confiance, la méfiance et la confiance appropriée. Leur examen indique que la relation empirique entre l'IA explicable, la confiance des utilisateurs et la confiance appropriée reste mitigée et, dans de nombreux contextes, non concluante [9]. (ScienceDirect) Une prépublication de 2026 de Raees et Papangelis soutient encore plus directement que les mesures de confiance subjectives n'indiquent pas automatiquement si les gens s'appuient de manière appropriée sur les recommandations de l'IA. Ce travail ayant été publié sous forme de prépublication, ses conclusions doivent être traitées comme une contribution à la recherche actuelle plutôt que comme un consensus final [10]. (arXiv)
La méfiance n’est pas non plus nécessairement le contraire d’une bonne utilisation du système. Un certain degré de scepticisme peut encourager la vérification et la détection des erreurs. Mais une méfiance aveugle peut également conduire les utilisateurs à rejeter les recommandations correctes. Une étude expérimentale réalisée en 2026 par Peters, Biermeier et Scharlau a examiné si l’attention visuelle pouvait aider à identifier une « méfiance saine » dans l’interaction homme-IA. Les résultats n’étaient pas concluants et illustrent à quel point il reste difficile de mesurer si la confiance et la méfiance sont correctement calibrées [11]. (Frontières) La relation souhaitée peut être illustrée comme suit :
| Fiabilité réelle | Faible confiance des utilisateurs | Confiance élevée des utilisateurs |
|---|---|---|
| Faible | Un scepticisme justifié | Un excès de confiance dangereux |
| Haut | Méfiance ou non-utilisation inutile | Une confiance justifiée et calibrée |
L’objectif n’est pas simplement de déplacer chaque utilisateur dans le coin inférieur droit en augmentant la confiance. L’objectif est de faire correspondre le plus étroitement possible la confiance perçue et la confiance comportementale à la fiabilité réelle du système, aux conséquences d’un échec et au contexte d’utilisation. Dans un article de juillet 2026, Busuioc et Maggetti plaident pour un passage de la maximisation de la confiance à la confiance calibrée. Ils préviennent que la confiance peut se détacher de la fiabilité réelle lorsque les organisations fabriquent des signaux de confiance au lieu de s’attaquer aux conditions sous-jacentes qui justifient la confiance. Leur analyse met également l’accent sur la vulnérabilité, la responsabilité et le rôle constructif que peut jouer la méfiance [12]. (OUP Académique)
La loi européenne sur l’IA suit une logique opérationnelle connexe. Pour les systèmes à haut risque pertinents, cela nécessite des processus et une documentation concernant la gestion des risques, la gouvernance des données, la documentation technique, la journalisation, la transparence, la surveillance humaine, l'exactitude, la robustesse et la cybersécurité [13]. Ces exigences ne prouvent pas que chaque système d’IA réglementé sera digne de confiance. Ils tentent cependant de traduire une attente abstraite de fiabilité en activités de gouvernance concrètes et en preuves révisables. (EUR-Lex) Une IA digne de confiance n’est donc pas un style d’interface ou un label marketing. Il s’agit d’un problème persistant de gouvernance et d’assurance.
Chez Secani, nous ne comprenons pas la confiance comme un sentiment qui devrait simplement être accru. Nous ne le définissons pas non plus comme une certitude absolue. La sécurité absolue n’existe pas dans les vrais systèmes numériques. Même des preuves solides ne peuvent garantir qu’aucune défaillance ou attaque ne se produira jamais. Les données probantes réduisent l’incertitude et soutiennent de meilleures décisions, mais elles n’éliminent pas les risques. Si toute incertitude pouvait être supprimée, la confiance ne serait plus nécessaire. C'est pourquoi nous parlons délibérément de confiance justifiée, et non de certitude. Notre définition est :
La confiance est une confiance justifiée et spécifique au contexte selon laquelle une affirmation de sécurité est vraie maintenant parce que l'affirmation, sa mise en œuvre et les preuves actuelles s'alignent de manière vérifiable.
La chaîne sous-jacente est :
Réclamation → Mise en œuvre → Preuve → Assurance → Confiance calibrée
Une organisation revendique sa sécurité. Cette affirmation se traduit par des contrôles, des systèmes, des responsabilités et des résultats attendus spécifiques. Les preuves actuelles démontrent si et comment ces contrôles ont été mis en œuvre. Un processus d'assurance évalue si les preuves soutiennent réellement l'affirmation initiale. C’est seulement alors qu’émerge une base rationnelle de confiance. Cette définition contient cinq contraintes délibérées.
« Nous sommes en sécurité » est une expression trop large pour être vérifiée de manière significative. « Tous les magasins de données de production utilisent des configurations de chiffrement approuvées » est plus restreint et testable. Plus une affirmation devient générale, plus il devient difficile d’en identifier la portée, les preuves requises, les hypothèses et les conditions de validité.
Un contrôle peut être efficace pour un système et inefficace pour un autre. Un modèle d’IA peut être adapté pour résumer des documents internes mais inadapté pour approuver de manière autonome des exceptions de sécurité. La confiance ne peut être transférée entre les contextes sans évaluer si les conditions pertinentes restent comparables.
Les organisations changent continuellement. De nouveaux actifs sont introduits. Les configurations sont modifiées. Les employés changent de rôle. Les fournisseurs mettent à jour leurs services. Des vulnérabilités sont découvertes. Les commandes qui fonctionnaient correctement hier peuvent ne plus fonctionner correctement aujourd'hui. Les preuves perdent donc de leur valeur avec le temps. Une conclusion fiable doit communiquer non seulement ce qui a été vérifié, mais également quand cela a été vérifié et combien de temps cette conclusion doit rester valable.
Les preuves rendent l’incertitude visible et les décisions défendables. Cela ne supprime pas entièrement l’incertitude. Même les preuves solides ont leurs limites. Il peut ne couvrir qu’une partie d’un système, reposer sur des hypothèses, contenir des erreurs de mesure ou devenir obsolète. Une assurance crédible doit communiquer ces limites plutôt que de les cacher derrière un statut binaire.
Une décision de confiance doit pouvoir changer lorsque les conditions sous-jacentes changent. Lorsque de nouvelles preuves contredisent une affirmation précédente en matière de sécurité, la conclusion doit être mise à jour. Lorsque les preuves expirent, la confiance devrait diminuer. Lorsque le champ d’application couvert s’élargit, des preuves supplémentaires devraient être requises. Une confiance qui ne peut pas être révisée n’est pas une confiance calibrée. C'est une croyance détachée de la réalité.
La confiance numérique traditionnelle se construit souvent grâce à des signaux périodiques : certificats, questionnaires, rapports d'audit, documents d'évaluation et présentations de sécurité. Ces mécanismes restent importants. Mais ils ne suffisent pas à eux seuls dans un monde où les systèmes numériques peuvent évoluer chaque jour. Le futur modèle évolue dans une direction différente :
| Modèle traditionnel | Futur modèle |
|---|---|
| « Faites-nous confiance » | Vérifier une réclamation spécifique |
| De larges promesses de sécurité | Revendications définies et portée explicite |
| Collecte périodique de preuves | Des preuves constamment actualisées |
| Documents statiques | Des informations connectées et lisibles par machine |
| Statut de conformité binaire | Contexte, incertitude et périodes de validité |
| Hypothèses cachées | Hypothèses et dépendances explicites |
| Preuve positive uniquement | Lacunes visibles et preuves contradictoires |
| Une conclusion annuelle | Des conclusions révisables en permanence |
L'assurance continue ne signifie pas que chaque activité d'une organisation doit être surveillée en permanence. Il doit être fondé sur les risques et proportionné. Une réclamation critique concernant un accès privilégié, une infrastructure de production ou des données clients sensibles nécessite des preuves plus récentes et plus solides qu'une réclamation administrative à faible impact. Le changement important est que la confiance ne reste plus attachée à un seul document. Les exigences, les mises en œuvre, les preuves, les examens, les conclusions, les responsabilités et les dépendances devraient plutôt former un modèle connecté. Les structures lisibles par machine peuvent jouer un rôle important dans cette transition. Ils permettent de réutiliser les preuves dans tous les cadres et évaluations sans supprimer leur provenance, leur portée d'origine, leur durée de collecte, leur propriétaire responsable ou leurs limites.
L’avenir de la confiance n’est donc pas simplement continu. Il est granulaire, traçable, transférable et révocable.
Les différents concepts peuvent désormais être connectés. Zero Trust régit la manière dont les décisions d'accès individuelles sont prises. Fiabilité décrit si un système ou une organisation mérite la confiance. Assurance fournit une justification structurée pour cette conclusion. Preuves étayent les affirmations concernant la mise en œuvre et l'efficacité. Conformité évalue l'alignement avec les exigences définies. Reliance décrit si une personne dépend ou suit réellement un système. La confiance numérique est la confiance plus large qui peut émerger à travers l'écosystème. Le Zero Trust empêche que la confiance soit assumée sans fondement suffisant. L'assurance démontre où la confiance est justifiée.
La conformité apporte des exigences structurées et des mécanismes de révision. Les preuves relient les déclarations à la réalité observable. Ces concepts ne sont donc pas des visions concurrentes. Ce sont différentes parties d’un modèle cohérent. L’avenir n’est ni un « faire confiance à tout le monde » universel, ni un « ne faire confiance à personne » culturel. Il s'agit d'une confiance vérifiable et calibrée.
« Optimiser pour la confiance » ne doit pas signifier optimiser pour la perception de fiabilité. Cela ne devrait pas signifier produire autant de coches vertes, de badges, de certificats ou d’allégations de sécurité générales que possible. Cela ne devrait pas signifier encourager les gens à faire confiance à un système plus que ce que justifient ses propriétés réelles. Pour nous, cela signifie :
Ne pas optimiser pour être digne de confiance. Optimisez pour être digne d'une confiance justifiée.
Nous construisons Secani pour connecter en permanence les allégations de sécurité, les exigences, les implémentations et les preuves. La confiance ne doit pas résulter uniquement d’une présentation convaincante ou d’un document de conformité périodique. Elle doit découler d’une justification actuelle, révisable et traçable. L’expression la plus concise de cette idée pourrait être :
La confiance n'est pas une promesse. Il s’agit d’une conclusion constamment étayée.
Les organisations ne doivent pas simplement paraître dignes de confiance. Ils devraient être capables de démontrer pourquoi ils méritent la confiance. Et il ne faut pas simplement demander aux gens de faire davantage confiance. Ils devraient pouvoir faire davantage confiance.
[1]D. M. Rousseau, S. B. Sitkin, R. S. Burt et C. Camerer, « Pas si différent après tout : une vision interdisciplinaire de la confiance », Academy of Management Review, vol. 23, non. 3, p. 393-404, 1998, est ce que je : 10.5465/AMR.1998.926617. (DOI)
[2]R. C. Mayer, J. H. Davis et F. D. Schoorman, « Un modèle intégrateur de confiance organisationnelle », Academy of Management Review, vol. 20, non. 3, p. 709-734, 1995, est ce que je : 10.5465/amr.1995.9508080335. (DOI)
[3]R. Ross, M. Winstead et M. McEvilley, Engineering Trustworthy Secure Systems, publication spéciale NIST 800-160, vol. 1, rév. 1, National Institute of Standards and Technology, Gaithersburg, MD, États-Unis, nov. 2022, est ce que je : 10.6028/NIST.SP.800-160v1r1. (Publications du NIST)
[4] S. Rose, O. Borchert, S. Mitchell et S. Connelly, Zero Trust Architecture, NIST Special Publication 800-207, National Institute of Standards and Technology, Gaithersburg, MD, États-Unis, août 2017. 2020, est ce que je : 10.6028/NIST.SP.800-207. (Centre de ressources sur la sécurité informatique du NIST)
[5] Forum économique mondial, Earning Digital Trust: Decision-Making for Trustworthy Technologies, Genève, Suisse, nov. 2022. (Forum économique mondial)
[6]K. B. Kelley, « L'impératif de la confiance numérique : définir, établir et mesurer la confiance numérique », ISACA Journal, vol. 1er janvier. 2023. (ISACA)
[7] National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (IA RMF 1.0), NIST IA 100-1, janvier. 2023, est ce que je : 10.6028/NIST.AI.100-1. (Publications du NIST)
[8] S. Mehrotra, C. Degachi, O. Vereschak, C. M. Jonker et M. L. Tielman, « Une revue systématique sur la promotion d'une confiance appropriée dans l'interaction homme-IA : tendances, opportunités et défis », ACM Journal on Responsible Computing, vol. 1, non. 4, art. Non. 26, p. 1-45, 2024, est ce que je : 10.1145/3696449. (Bibliothèque numérique ACM)
[9]R. Visser, T. M. Peters, je. Scharlau et B. Hammer, « Confiance, méfiance et confiance appropriée dans (X)IA : une clarification conceptuelle de la confiance des utilisateurs et une enquête sur son évaluation empirique », Cognitive Systems Research, vol. 91, art. Non. 101357, 2025, est ce que je : 10.1016/j.cogsys.2025.101357. (ScienceDirect)
[10]M. Raees et K. Papangelis, « De la confiance à la fiabilité appropriée : constructions de mesure dans la prise de décision humaine-IA », arXiv : 2604.23896, avril. 2026, est ce que je : 10.48550/arXiv.2604.23896. Préimpression. (arXiv)
[11] T. M. Peters, K. Biermeier et moi. Scharlau, « Évaluer la méfiance saine dans l'interaction homme-IA : interpréter les changements dans l'attention visuelle », Frontiers in Psychology, vol. 16, art. Non. 1694367, janv. 2026, est ce que je : 10.3389/fpsyg.2025.1694367. (Frontières)
[12]M. Busuioc et M. Maggetti, « Digne de confiance ? Gouvernance de l'IA et rôle de la (méfiance) », Perspectives sur la gestion publique et la gouvernance, article n° gvag007, juil. 2026, est ce que je : 10.1093/ppmgov/gvag007. (OUP Académique)
[13] Parlement européen et Conseil de l’Union européenne, « Règlement (UE) 2024/1689 du 13 juin 2024 fixant des règles harmonisées en matière d'intelligence artificielle », Journal officiel de l'Union européenne, juil. 2024. (EUR-Lex)
Secani réunit Scopes, preuves, tâches et agents d’IA dans un espace de travail partagé.
Moins d’offres d’emploi, des restructurations dans les grands cabinets et davantage de consultants indépendants visibles : ce que révèlent les données du marché du conseil en cybersécurité.
Sept questions pratiques révèlent si une plateforme peut relier les obligations, les contrôles, les preuves, les risques et le jugement professionnel dans un système reproductible.
Les listes de contrôle ISO 27001 fournissent une orientation mais ne peuvent pas remplacer la connaissance de la norme. Un guide de leurs limites et des ressources disponibles.